Diretrizes: Decisões Importantes em Análise e Design

As seguintes decisões devem ser tomadas em relação ao fluxo de trabalho da disciplina Análise e Design:

Documente as decisões no Caso de Desenvolvimento, no tópico Disciplinas, Análise e Design, Fluxo de Trabalho.

Decida os artefatos a serem usados e como usar cada um deles. A tabela a seguir descreve os artefatos obrigatórios e os utilizados apenas em determinados casos. Para obter informações mais detalhadas sobre como adaptar cada artefato e conhecer as vantagens e desvantagens de cada um deles, consulte a seção "Adaptação" para cada artefato desejado.

Para cada artefato, decida como ele deverá ser usado: Obrigatório, Recomendável, Opcional ou Desnecessário. Para obter mais detalhes, consulte Diretrizes: Classificação de Artefatos.

Artefato	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.
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 caso de uso	Estabelece a conexão entre casos de uso e design.	Recomendada para a maioria dos projetos.
Interface	Normalmente, as interfaces são usadas para definir um comportamento, sejam quais forem os componentes de baixa granularidade que assumam o comportamento.	Recomendada para a maioria dos projetos. O design baseado em componentes está se tornando uma abordagem de design padrão.
Subsistemas de design	Os subsistemas de design são usados para encapsular comportamento em um "pacote" 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 os sistemas mais fáceis.
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.	Recomendada para sistemas em tempo real. Pode ser útil para sistemas que necessitem de simultaneidade e sejam controlados por eventos.
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 Implantaçã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 Implantaçã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 Arquitetural	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.
Documento de Arquitetura de Software (SAD)	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.

Decidir os Relatórios a Serem Usados

Decida que relatórios serão utilizados. Como ponto de partida, é recomendável usar os seguintes relatórios:

Decidir Como Revisar

Decida o nível de revisão de cada artefato e capture-o no caso de desenvolvimento. Consulte Diretrizes: Níveis de Revisão para obter detalhes.

Decida como revisar e aprovar os resultados de Análise e Design e qual será o grau de revisão dos resultados.

Os fatores que podem ser alterados são o escopo, os recursos e as técnicas de revisão. Aqui estão alguns exemplos do que você pode decidir fazer em seu projeto:

Para obter mais informações sobre como fazer uma revisão e sobre os diferentes tipos de revisão, consulte Orientações de Trabalho: Revisões.

Decidir se o Código Será Gerado

A maneira como você elabora o design varia dependendo se o código é ou não gerado a partir do modelo de design. Se o código for gerado a partir do modelo de design, o design precisará ser muito detalhado. Por outro lado, se o código não for gerado a partir do modelo de design, não é necessário que o design seja muito detalhado. Pelo contrário, os detalhes do design terão de ser sincronizados manualmente com o código.