|
Produto de Trabalho
|
Finalidade
|
Adaptação (Opcional, Recomendada)
|
|
Modelo de Análise (Classe de Análise)
|
Um modelo de análise ajuda a compreender melhor os requisitos antes da tomada de decisões sobre design.
Em sistemas complexos, ele pode ser mantido para fornecer uma visão geral conceitual do sistema.
|
Opcional
Em muitos projetos, um Modelo de Design inicial é usado em lugar do Modelo de Análise.
Em projetos que efetivamente criam um Modelo de Análise, normalmente é um artefato temporário que
acaba se transformando em um modelo de design.
|
|
Mapa de Navegação, Protótipo da Interface com o Usuário
|
Projetos com uma interface com o usuário grande e complexa devem considerar o design da interface com o
usuário.
|
Opcional
O design mais informal da interface com o usuário pode ser suficiente em esforços de
desenvolvimento menores.
|
Modelo de Design
|
É recomendável que a maioria dos sistemas (mesmo os menores) sejam projetados antes de serem
implementados, a fim de evitar um retrabalho dispendioso decorrente de erros de design. Os modelos
visuais permitem que o design seja facilmente comunicado. O uso de ferramentas de engenharia direta e
de engenharia reversa pode assegurar a consistência com o modelo de implementação, além de poupar
trabalho.
|
Recomendada para a maioria dos projetos.
Em projetos menores, o uso de ferramentas automatizadas não é crítico, mas pode beneficiar a
produtividade a longo prazo.
|
Classe de Design; Pacote de Design
|
As classes e os pacotes são uma parte básica de qualquer design orientado a objetos. O design orientado
a objetos é o método de design padrão utilizado na maior parte dos projetos.
|
Recomendada para a maioria dos projetos.
Um dos principais problemas de adaptação é decidir quais estereótipos devem ser usados (isso poderá
ser abordado no Guia de Design).
|
Realização de Casos de Uso
|
Estabelece a conexão entre casos de uso e design.
|
Recomendada para a maioria dos projetos.
|
Interface
|
Normalmente, as interfaces são utilizadas para definir um comportamento, independentemente dos
componentes de grande granularidade que realizam o comportamento.
|
Recomendada para a maioria dos projetos.
O design baseado em componentes está se tornando uma abordagem de design padrão.
|
Subsistema de Design
|
Os subsistemas de design são utilizados para encapsular comportamento em um componente que forneça
interfaces. São usados para encapsular as interações de classes e/ou outros subsistemas.
|
Recomendada para a maioria dos projetos.
Em geral, os subsistemas ajudam a elevar o nível de abstração do design. Eles tornam mais fácil a
compreensão dos sistemas.
|
Evento
|
Pode ser útil para sistemas que respondem a muitos eventos externos.
|
Recomendada para sistemas em tempo real.
|
Protocolo
|
Obrigatório para sistemas em tempo real.
|
Recomendada para sistemas em tempo real.
|
Sinal
|
Pode ser útil para sistemas que necessitem de simultaneidade e sejam controlados por eventos.
Obrigatório para sistemas em tempo real.
|
Pode ser útil para sistemas que necessitem de simultaneidade e sejam controlados por eventos.
Recomendada para sistemas em tempo real.
|
Cápsula
|
Destina-se a sistemas em tempo real, mas pode ser útil na modelagem e no design de qualquer sistema com
alto grau de simultaneidade.
|
Recomendada para sistemas em tempo real.
|
|
Modelo de Dados
|
Usado para descrever a estrutura lógica e possivelmente física das informações persistentes.
|
Recomendada para projetos que utilizam um banco de dados.
|
|
Modelo de Implementação
|
Mostra a configuração de nós de processamento em tempo de execução e os vínculos de comunicação entre
eles, assim como as instâncias de componentes e os objetos que neles residem.
|
Opcional.
Muitos sistemas apresentam vários nós de processamento e, por isso, precisam utilizar o Modelo de
Implementação. No entanto, ele pode ser abordado como uma seção do Documento de Arquitetura de
Software, sem precisar existir como um artefato identificado separadamente.
|
|
Prova de Conceito de Arquitetura
|
Usada para determinar se existe uma solução que satisfaça os requisitos significativos do ponto de
vista arquitetural
|
Recomendada para a maioria dos projetos.
Muitos projetos utilizam uma Prova de Conceito Arquitetural para determinar a viabilidade dos
requisitos. Estas são algumas das muitas formas que ela pode assumir:
-
uma lista de tecnologias conhecidas que pareça adequada à solução
-
um esboço de um modelo conceitual de uma solução
-
uma simulação de uma solução
-
um protótipo executável
|
|
Arquitetura de Referência
|
As Arquiteturas de Referência aceleram o desenvolvimento e reduzem os riscos reutilizando soluções já
aprovadas.
|
Recomendada para a maioria dos projetos.
Se existir material de Arquitetura de Referência apropriado, ela pode acelerar o desenvolvimento e
reduzir os riscos consideravelmente.
|
|
SAD (Documento de Arquitetura de Software)
|
O Documento de Arquitetura de Software é usado para fornecer uma ampla visão geral da arquitetura do
sistema. Essa visão geral ajuda a compreender o sistema e a captar decisões arquiteturais importantes.
|
Recomendada para a maioria dos projetos.
Uma visão geral de alto nível da arquitetura do software é útil para todos os sistemas, exceto os
menores. Normalmente, os sistemas complexos necessitam de um nível maior de detalhes e de mais
visões que os projetos menores.
|
|
Protótipo da Interface com o Usuário
|
Usado para expor e testar a funcionalidade e a usabilidade antes do início efetivo do desenvolvimento.
É um meio eficaz de validar o design antes de desperdiçar muito tempo.
|
Recomendada para a maioria dos projetos.
|
