Atividade:
| ||||||||||||
Finalidade
|
|
| Passos | |
| Artefatos Informados: | Artefatos Resultantes:
|
| Papel: Arquiteto de Software | |
| Detalhamentos do Fluxo de Trabalho: |
Antes de começar o design, adapte o Guia de Design para que englobe as áreas relevantes para o projeto. Consulte a seção "Adaptação" em Guia de Design. O caso de desenvolvimento servirá como fonte de informações, pois descreve como o projeto funcionará durante o design.
Para adaptar o Guia de Design, é preciso conhecer o ambiente de implementação. Por exemplo, sua opção de linguagem de programação afetará o modelo de design de acordo com a maneira como você documentar as operações, usar as generalizações e usar objetos e classes. Outros exemplo são os estilos arquiteturais a serem usados, a utilização de mecanismos importantes na implementação do sistema e o design de uma interface gráfica do usuário.
Todas as decisões sobre as diretrizes e estratégias para o design arquitetural, o design e sua implementação devem ser documentadas no Guia de Design.
Tome decisões sobre todas as áreas incluídas no documento Guia de Design.
Este é um exemplo das três áreas que normalmente precisam de decisões. Essas decisões devem ser incluídas no Guia de Design.
Decida como os pacotes no modelo de design devem ser mapeados para os subsistemas no modelo de implementação.
Recomenda-se um mapeamento de um para um entre os pacotes de design e os subsistemas de implementação. Esse procedimento facilitará a compreensão da rastreabilidade entre o design e a implementação.
Entretanto, em alguns casos, pode ser difícil manter o mapeamento de um para um. Para obter exemplos de situações nas quais as hierarquias de pacote para design e implementação podem diferir, consulte Atividade: Estruturar o Modelo de Implementação.
Se você preferir hierarquias de pacote distintas para o design e a implementação, minimize as diferenças o quanto puder. Não se esqueça de que as questões a serem solucionadas sobre a estrutura dos subsistemas de implementação relacionam-se principalmente ao desenvolvimento do software e ao gerenciamento de sua construção, ou seja, são pertinentes à visão de implementação da arquitetura.
Decida como cada classe deverá ser mapeada para a implementação - se uma classe de design deve ser mapeada para uma, e somente para uma, classe de implementação, ou se o mapeamento deve ser de um para muitos.
Para obter mais informações sobre como mapear classes de design para o código, consulte Conceitos: Mapeamento para Código a partir do Design.
Decida como será representado o reaproveitamento dos componentes reutilizáveis.
Há vários tipos de componentes de software reutilizáveis. Alguns devem ser modelados no modelo de design, outros no modelo de implementação e outros não terão que ser modelados. O motivo para incluir as classes dos componentes reutilizáveis no modelo de design é porque a estrutura desses componentes afeta a estrutura do sistema, e será difícil entender os cenários se as classes forem omitidas. Portanto, se os diagramas forem de fácil compreensão, crie classes proxy para os componentes reutilizáveis e use-os no modelo de design.
Exemplo de software que em geral não aparece em qualquer modelo:
Exemplo de software que em geral aparece no modelo de implementação:
Sendo assim, as decisões diferem para cada biblioteca ou sistema de componentes reutilizáveis do projeto.
|
Rational Unified Process
|
