Histórico da Revisão

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

Índice Analítico

1.1 Finalidade

1.2 Escopo

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

1.4 Referências

1.5 Visão Geral

2. Diretrizes Gerais de Design e de Implementação

3. Diretrizes de Design de Banco de Dados

4. Diretrizes de Design de Arquitetura

5. Diretrizes de Mecanismos

6. Estereótipos de UML

Guia de Design

1. Introdução

[A introdução do Guia de Design fornece uma visão geral de todo o documento. Ela contém a finalidade, o escopo, as definições, os acrônimos, as abreviações, as referências e a visão geral deste documento Guia de Design.]

1.1 Finalidade

A finalidade deste documento é comunicar os idiomas, as convenções e os padrões de design a serem usados no design do sistema.

[Especifique qualquer descrição adicional dos objetivos do Guia de Design.]

1.2 Escopo

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

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

[Esta subseção fornece as definições de todos os termos, acrônimos e abreviações necessárias à adequada interpretação do Guia de Design. Essas informações podem ser fornecidas mediante referência ao Glossário do projeto.]

1.4 Referências

[Esta subseção fornece uma lista completa de todos os documentos mencionados em qualquer outra parte do Guia de Design. Identifique cada documento por título, número do relatório (se aplicável), data e organização de publicação. Por fim, a seção poderá ser estruturada em subseções: documentos externos versus documentos internos ou documentos do governo versus documentos que não são do governo etc. Especifique as fontes a partir das quais as referências podem ser obtidas. Essas informações poderão ser fornecidas fazendo-se referência a um apêndice ou a outro documento.]

1.5 Visão Geral

[Esta subseção descreve o que o restante do Guia de Design contém e explica como o documento está organizado.]

2. Diretrizes Gerais de Design e de Implementação

[Esta seção descreve os princípios e estratégias a serem usados quando o sistema for projetado e implementado. Na maioria dos casos, serão necessárias estratégias para efetuar o seguinte:

· Mapeamento do Design para Implementação

Você deverá especificar como o design será mapeado para a implementação; tanto em nível de pacote quanto em nível de classe.

· Especificação de Interfaces nos Subsistemas

Quando estiver desenvolvendo integralmente o sistema, é importante restringir as interfaces visíveis com os subsistemas. Isso permitirá que os desenvolvedores alterem as partes de um subsistema que não sejam visíveis externamente.

· Documentação de Operações

É importante que você escolha uma maneira padrão de descrever operações. Uma operação consiste no nome, nos argumentos, numa breve descrição e em uma especificação de implementação. É importante se perguntar o seguinte ao documentar as operações:

— Todos os argumentos (formais) serão documentados? Sugerimos que sejam, embora a experiência mostre que a manutenção dos argumentos poderá ser difícil já que eles são redundantes em relação ao código.

— Será necessário documentar o tipo de argumento? Geralmente, é recomendável documentá-lo.

— Você utilizará alguma convenção de nomeação para as operações de uma classe? Por exemplo, na linguagem C++, você poderá optar por definir prefixos diferentes para as operações públicas e privadas. Isso facilitará a compreensão das operações.

· Documentação de Mensagens

Sugerimos não documentar todos os parâmetros reais na mensagem. É redundante em relação ao código e pode dificultar a manutenção.

· Detecção, Tratamento e Relato de Erros

Você deverá ter uma estratégia de gerenciamento de erros. Sua estratégia dependerá em alto grau da linguagem de programação que você tiver escolhido. Muitas linguagens apresentam suporte ao gerenciamento de erros como, por exemplo, as "exceções" na linguagem Ada. A estratégia de gerenciamento de erros escolhida influenciará o comportamento nos objetos de design. Por exemplo, você deverá decidir se deve usar parâmetros de status em cada operação que informem se a operação foi bem-sucedida ou se deve deixar o objeto gerar uma "exceção", exatamente como na linguagem Ada.

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

· Gerenciamento de Memória

O gerenciamento de memória implica assegurar que a memória esteja sempre disponível. Para tanto, é necessário remover os objetos a que nenhum outro objeto faça referência de modo que a parcela de memória que ocupam possa ser destinada a novos objetos. A maneira como você solucionará isso dependerá da linguagem de implementação. Em alguns sistemas, isso será resolvido automaticamente, por exemplo, através de um coletor de lixo; mas em outros, você mesmo deverá executar o gerenciamento de memória na linguagem de programação. Em outras palavras, você terá que definir quando e como limpar a parte da memória ocupada por objetos aos quais não sejam feitas referências.

· Distribuição de Software

Se você tiver 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 de o design ser iniciado, prepare este trabalho especificando estratégias gerais que regulem como os objetos precisam ser distribuídos e como usar a atual tecnologia de comunicação entre processos. Se o ambiente de destino não for conhecido, poderá ser útil elaborar protótipos de soluções.

· Como Representar Componentes Reutilizáveis

Antes de iniciar o design, você deverá escolher os componentes e os sistemas de componentes reutilizáveis, as bibliotecas ou os "Produtos de Terceiros" (COTS) a serem usados. Você deverá também decidir se, e como, eles precisarão ser modelados no design.

· Projeto de Casses Persistentes

O ideal é que o sistema de gerenciamento de banco de dados escolhido por você, seja ele relacional ou baseado em objetos, não afete muito o modelo de design. A persistência deverá ser fornecida por um framework que a torne o mais transparente possível.

A maior parte do trabalho de design de persistência deverá concentrar-se na identificação e na resolução de problemas de desempenho. Para facilitar esse trabalho, faça o seguinte:

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

— Identifique as fronteiras de transações nas Realizações de Caso de Uso.

Há uma certa iteração entre o Design de Banco de Dados e o das classes persistentes: dependendo do banco de dados, algumas associações entre as classes de design se mostram ineptas, não devendo portanto ser suportadas no banco de dados, ou então geram problemas de desempenho que acabam tornando necessário que se façam adaptações no Modelo de Design.

· Gerenciamento de Transações

Esta seção discute as estratégias usadas para gerenciar transações, incluindo como será efetuado o gerenciamento de transações. Discuta a interação entre o gerenciamento de transações e o Gerenciamento de Erros, incluindo como o sistema se recuperará de falhas de transação ou de transações anuladas.

Se houver restrições especiais impostas pelo mecanismo de gerenciamento de transações (como, por exemplo, o fato de o MTS exigir objetos "sem estado") que afetem a arquitetura do sistema, será necessário discuti-las aqui.

· Uso Especial de Recursos de Linguagem

Esta seção descreve todas as restrições ou políticas referentes aos recursos de linguagem utilizados. Por exemplo, você poderá limitar o uso de ponteiros em um sistema incorporado em tempo real.

· Estrutura do Programa

Esta seção inclui diretrizes de layout de código, comentários, convenções de nomeação, empacotamento de módulos e convenções de interface.

· Diretrizes de Algoritmos

Esta seção descreve algoritmos específicos selecionados para serem usados no sistema pelo arquiteto de software. Ela também descreve as circunstâncias em que o uso dos algoritmos é apropriado. Esta seção não documenta aplicações específicas de um algoritmo no sistema — esta é a finalidade do Documento de Arquitetura de Software e do Modelo de Design — em vez disso, ela se destina a orientar e restringir as escolhas do designer.

· Criação de Interfaces de Hardware

Esta seção descreve diretrizes para criar interfaces de hardware, incluindo o uso de interrupções, memória, representação de tipos etc.

· Diretrizes de Criação e de Modificação do Sistema

Esta seção descreve as diretrizes para a modificação do software, o software ou o hardware de suporte especial necessários, diretrizes de edição, compilação e de integração etc. Ela também poderá conter diretrizes de controle de mudança e de configuração elaboradas a partir do Plano de Gerenciamento de Configuração.

· Diretrizes de Diagnóstico do Sistema

Esta seção descreve as diretrizes para que a configuração do sistema faça o diagnóstico de problemas, com base na estratégia de gerenciamento e de detecção de erros adotada. Ela descreve como qualquer hardware ou software de diagnóstico especial poderá ser usado, como disparar rastreadores e geradores de perfis, e como coletar dados de diagnóstico.]

3. Guia de Design de Banco de Dados

[Esta seção fornece regras e recomendações para o design de banco de dados. É necessário discutir os seguintes tópicos:

· Mapeamento de classes de persistência para estruturas de banco de dados, incluindo como solucionar possíveis conflitos como, por exemplo, associações de muitos para muitos na herança e no modelo de design.

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

· Uso da Visão de Processos para descrever os processos e a comunicação entre processos usada pelo mecanismo de persistência.

· Uso da Visão de Implantação para descrever a distribuição física dos dados pelos nós.

· Convenções de nomeação para estruturas de banco de dados; por exemplo, tabelas, procedimentos armazenados, triggers, espaços de tabela etc.]

4. Diretrizes de Design de Arquitetura

[Esta seção fornece regras e recomendações para o design de arquitetura de software. Elas estão organizadas em torno das diferentes visões de arquitetura: as Visões de Caso de Uso, Lógicas, de Implementação, de Processos e de Implantação. As regras abordam principalmente a decomposição. Por exemplo, as diretrizes da Visão de Implementação especificam as regras para empacotar módulos em subsistemas, dividir subsistemas em camadas e assim por diante. Consulte o Documento de Arquitetura de Software, especificamente a seção denominada Análise e Design.]

5. Diretrizes de Mecanismos

[Para cada mecanismo importante posicionado nas camadas de nível inferior do sistema, é necessário ter um guia para programadores que mostre a interface do mecanismo e explique como usá-la Também devem estar incluídos os guias do usuário do mecanismo de timer, do mecanismo de comunicação entre processos, do mecanismo de registro, do sistema de gerenciamento de banco de dados etc.]

6. Estereótipos de UML

[Esta seção contém ou faz referência a especificações de estereótipos de Linguagem de Modelagem Unificada (UML) e suas implicações semânticas - uma descrição textual do significado e da importância do estereótipo e de quaisquer limitações de seu uso - referentes a estereótipos já conhecidos ou que se mostraram úteis para a construção de Modelos de Design. O uso desses estereótipos pode ser simplesmente recomendado ou até mesmo obrigatório; por exemplo, quando o uso desses estereótipos é exigido por um padrão imposto, quando se considera que seu uso facilita em muito o entendimento dos modelos ou quando ele assegura que tipos comuns de entidades, papéis, relacionamentos ou padrões sejam compreendidos e modelados uniformemente. Esta seção poderá ficar vazia se não for considerado necessário nenhum estereótipo adicional além dos predefinidos pela UML e pelo Rational Unified Process.]