<Nome do Projeto>

Diretrizes de Design

Versão <1.0>

[Nota: O gabarito a seguir é fornecido para utilização com o Rational Unified Process. O texto em azul exibido entre colchetes e em itálico (style=InfoBlue) foi incluído para orientar o autor e deve ser excluído antes da publicação do documento. Um parágrafo digitado após esse estilo será automaticamente definido como normal (style=Body Text).]

[Para personalizar campos automáticos no Microsoft Word (que exibem um segundo plano cinza quando selecionados), selecione File>Properties e substitua os campos Title, Subject e Company pelas informações apropriadas para este documento. Depois de fechar o diálogo, os campos automáticos podem ser atualizados no documento inteiro, selecionando Edit>Select All (ou Ctrl-A) e pressionando F9 ou simplesmente clique no campo e pressione F9. Esse procedimento deverá ser executado separadamente para os Cabeçalhos e Rodapés. Alt-F9 alterna entre a exibição de nomes de campos e do conteúdo dos campos. Consulte a Ajuda do Word para obter informações adicionais sobre como trabalhar com campos.]

Histórico da Revisão

Data	Versão	Descrição	Autor
<dd/mmm/aa>	<x.x>	<detalhes>	<nome>

Índice

1.	Introdução	4

1.1	Objetivo	4

1.2	Escopo	4

1.3	Definições, Acrônimos e Abreviações	4

1.4	Referências	4

1.5	Visão Geral	4

2.	Orientações Gerais de Design e Implementação	4

3.	Diretrizes de Design de Banco de Dados	6

4.	Diretrizes de Design Arquitetural	7

5.	Orientações de Mecanismo	7

6.	Estereótipos UML	7

Diretrizes de Design

Introdução

[A introdução das Diretrizes de Design fornece uma visão geral de todo o documento. Ela inclui o objetivo, o escopo, as definições, os acrônimos, as abreviações, as referências e a visão geral destas Diretrizes de Design.]

Objetivo

O objetivo deste documento é comunicar os padrões de design, as convenções e os idiomas a serem utilizados no design do sistema.

[Digite qualquer descrição adicional dos objetivos das Diretrizes de Design.]

Escopo

[Uma breve descrição daquilo a que as Diretrizes de Design se aplicam; do que é afetado ou influenciado por este documento.]

Definições, Acrônimos e Abreviações

[Esta subseção fornece as definições de todos os termos, acrônimos e abreviações requeridos para interpretar adequadamente as Diretrizes de Design. Essas informações podem ser fornecidas em relação ao Glossário do projeto.]

Referências

[Esta subseção fornece uma lista completa de todos os documentos mencionados em outra parte nas Diretrizes de Design. Identifique cada documento pelo seguinte: título, número do relatório (se for o caso), data e organização responsável pela publicação. Conseqüentemente, a seção pode estar estruturada em subseções: documentos externos contra documentos internos ou documentos do governo contra documentos que não são do governo e assim por diante. Especifique as origens a partir das quais as referências podem ser obtidas. Essas informações podem ser fornecidas por um anexo ou outro documento.]

Visão Geral

[Esta subseção descreve o que o restante das Diretrizes de Design contém e explica como o documento é organizado.]

Orientações Gerais de Design e Implementação

[Esta seção descreve os princípios e estratégias a serem utilizados ao projetar e implementar o sistema. Na maioria dos casos, serão necessárias estratégias para o seguinte:

Mapeamento do Design para Implementação

É necessário especificar como o design é mapeado para a implementação; no nível de pacote e no nível de classe.

Especificando Interfaces em Subsistemas

Quando você está desenvolvendo o sistema do início ao fim, é importante limitar as interfaces visíveis aos subsistemas. Isso permite que os desenvolvedores alterem as partes de um subsistema que não são visíveis de fora.

Documentando Operações

É importante decidir sobre uma maneira padrão de descrever operações. Uma operação consiste no nome, argumentos, uma breve descrição e uma especificação de implementação. Faça a si mesmo as seguintes perguntas quando estiver documentando operações.

—	Todos os argumentos (formais) serão documentados? É sugerido que eles devem ser, embora a experiência mostre que pode ser difícil mantê-los porque são redundantes com o código.

—	O tipo de argumento será documentado? Geralmente, é sugerido que sim.

—	Será utilizada alguma convenção de nomenclatura para as operações em uma classe? Por exemplo, em C++ você pode escolher prefixar operações privadas e públicas de maneiras diferentes. Isso faz com que as operações fiquem mais fáceis de entender.

Documentando Mensagens

É sugerido que você não documente todos os parâmetros reais na mensagem. É redundante com o código e pode ficar difícil de manter.

Detectando, Manipulando e Relatando Falhas

É necessário ter uma estratégia para o gerenciamento de falhas. Sua estratégia depende muito da linguagem de programação escolhida. Muitas linguagens têm como característica o suporte ao gerenciamento de falhas, como "exceções" Ada. A estratégia de gerenciamento de falhas escolhida influenciará o comportamento nos objetos de design. Por exemplo, você deve decidir se utilizará parâmetros de status em cada operação que informam se a operação foi bem-sucedida ou se deixará que o objeto crie uma "exceção", como em Ada.

Se necessário, você pode aplicar diferentes estratégias de gerenciamento de falhas a diferentes partes de um sistema. O importante é ter pelo menos uma estratégia e, para todas as estratégias possíveis, que esteja claro quando utilizá-las.

Gerenciamento de Memória

Gerenciamento de memória significa garantir que a memória sempre esteja disponível. Isso implica na remoção de objetos não mencionados por nenhum outro objeto para que a memória que eles ocupam possa ser utilizada por novos objetos. Como isso será resolvido dependerá do idioma de implementação. Em alguns sistemas, isso será resolvido automaticamente, por exemplo, por um coletor de lixo; mas, em outros será necessário executar você mesmo o gerenciamento de memória na linguagem de programação. Em outras palavras, você terá que definir quando e como limpar qualquer memória ocupada por objetos não mencionados.

Distribuição de Software

Se houver um sistema que será distribuído entre vários nós físicos, seus objetos também deverão ser distribuídos entre os nós. Antes do design ser iniciado, você preparará este trabalho especificando estratégias gerais de como os objetos serão distribuídos e como utilizar a presente tecnologia de comunicação inter-processos. Se o ambiente de destino não for familiar, ele deverá ser útil para soluções de protótipo.

Como Representar Componentes Reutilizáveis

Antes de iniciar o design, você deve decidir quais componentes reutilizáveis, sistemas de componentes reutilizáveis, bibliotecas ou produtos COTS ("Commercial-Off-the-Shelf") utilizar. Você deve também decidir se e como estes serão modelados no design.

Projetando Classes Persistentes

Idealmente, o sistema de gerenciamento de banco de dados escolhido, seja relacional ou baseado em objeto, não afetará muito o modelo de design. A persistência é fornecida por uma estrutura que a torna o mais transparente possível.

A maioria dos trabalhos de design de persistência está focalizada na identificação e resolução de problemas de desempenho. Para que isso fique mais fácil, é necessário fazer o seguinte:

—	Identificar o ciclo de vida de cada objeto persistente: quando ele será criado, lido, atualizado e excluído nas Realizações de Caso de Uso.

—	Identificar limites de transações nas Realizações de Caso de Uso.

Há alguma iteração entre o Design de Banco de Dados e o design de classes persistentes: dependendo do banco de dados, algumas associações entre classes de design são difíceis de suportar no banco de dados ou de criar tal problema de desempenho que será necessário fazer alguma adaptação do Modelo de Design.

Gerenciamento de Transação

Esta seção discute as estratégias utilizadas para gerenciar transações, incluindo como o gerenciamento de transação será realizado. A interação do gerenciamento de transação e do Gerenciamento de Falhas é discutida, incluindo como o sistema se recupera de falhas de transação ou de transações abortadas.

Se houver restrições especiais impostas pelo mecanismo de gerenciamento de transação (como MTS solicitando objetos 'stateless') que afetem a arquitetura do sistema, elas deverão ser discutidas aqui.

Utilização Especial de Recursos de Idioma

Esta seção descreve quaisquer restrições ou políticas nos recursos de idioma utilizados. Por exemplo, você pode limitar a utilização de ponteiros em um sistema em tempo real incorporado.

Estrutura do Programa

Esta seção inclui orientações para layout de código, comentários, convenções de nomenclatura, pacote de módulo e convenções de interface.

Orientações de Algoritmo

Esta seção descreve algoritmos particulares selecionados para utilização no sistema pelo arquiteto de software. A seção também descreve as circunstâncias em que a utilização do algoritmo é apropriada. Esta seção não documenta aplicativos particulares de um algoritmo no sistema—que seja do domínio do Documento de Arquitetura de Software e do Modelo de Design—em vez disso, destina-se a orientar e compelir a opção do designer.

Interface de Hardware

Esta seção descreve orientações para interface de hardware, incluindo a utilização de interrupções, memória, representação de tipo e assim por diante.

Orientações de Modificação e Construção do Sistema

Esta seção descreve orientações para modificação de software, hardware ou software de suporte especial necessário, orientações de edição, compilação e integração e assim por diante. Esta seção pode conter também orientações de configuração e de controle de mudanças elaboradas a partir do Plano de Gerenciamento de Configuração.

Orientações de Diagnóstico do Sistema

Esta seção descreve orientações para a configuração do sistema diagnosticar problemas, com base na estratégia de detecção e gerenciamento de falhas adotada. Esta seção descreve qualquer hardware ou software de diagnóstico especial que possa ser utilizado, como chamar rastreios e gerenciadores de perfis e como coletar dados de diagnóstico.]

Diretrizes de Design de Banco de Dados

[Esta seção fornece regras e recomendações para o design de banco de dados. Os tópicos a seguir devem ser discutidos:

Mapeamento de classes de persistência a estruturas de banco de dados, incluindo como manipular conflitos potenciais, como associações muitos-para-muitos no modelo de design e herança.

Mapeamento de atributos de classes de design para tipos de dados primitivos de banco de dados.

Utilização da Visualização do Processo para descrever os processos e a comunicação inter-processos utilizados pelo mecanismo de persistência.

Utilização da Visualização da Implementação para descrever a distribuição física dos dados através dos nós.

Convenções de nomenclatura para estruturas de banco de dados; por exemplo, tabelas, procedimentos armazenados, acionadores, espaços de tabela e assim por diante.]

Diretrizes de Design Arquitetural

[Esta seção fornece regras e recomendações para design de arquitetura de software. Elas são organizadas acerca das diferentes visualizações arquiteturais: Visualizações de Caso de Uso, Lógicas, de Implementação e de Processo. As regras tratam principalmente da decomposição. Por exemplo, as orientações da Visualização de Implementação especificam as regras para compactar módulos em subsistemas, colocar subsistemas em camadas e assim por diante. Consulte o Documento de Arquitetura de Software, a seção intitulada Análise & Design em particular.]

Orientações de Mecanismo

[Para cada mecanismo significativo colocado nas camadas de nível baixo do sistema, você deve ter um guia de programadores que mostre a interface do mecanismo e explique como utilizá-lo. Isso inclui um guia do usuário do mecanismo de cronômetro, do mecanismo de comunicação inter-processos, do mecanismo de registro, do sistema de gerenciamento de banco de dados e assim por diante.]

Estereótipos UML

[Esta seção contém ou faz referência a especificações de estereótipos UML (Linguagem de Modelagem Unificada) e suas implicações semânticas—uma descrição textual do significado e da importância do estereótipo e todas as limitações em sua utilização—estereótipos já conhecidos ou descobertos como úteis para a construção de modelos de Design. A utilização desses estereótipos pode apenas ser recomendada ou talvez até ser obrigatória; por exemplo, quando sua utilização é requerida por um padrão imposto, quando é percebido que sua utilização torna significativamente mais fácil o entendimento dos modelos ou quando garante que tipos comuns de entidades, funções, relacionamentos ou padrões são uniformemente modelados e entendidos. Esta seção poderá ficar vazia se nenhum estereótipo adicional, diferente daqueles predefinidos pela UML e pelo Rational Unified Process, for considerado necessário.]

<Nome da Empresa>

<Nome do Projeto>	Versão: <1.0>
Diretrizes de Design	Data: <dd/mmm/aa>
<identificador do documento>

Confidencial	(<Nome da Empresa>, 2006	Página 7 de 3

Diretrizes de Design

<Nome do Projeto>

Design

Luis Tadeu Castilho

2005-11-10

Rational

Guidelines

<Company Name>