Diretrizes:
|
Parte do workflow |
Comentários |
---|---|
Design da interface do usuário | Em alguns projetos, opta-se por não projetar a interface do usuário. Essa decisão pode ser decorrente da facilidade com que ela é desenvolvida. Se você decidir não executar o design da interface com o usuário, significa que um Mapa de Navegação e um Protótipo da Interface com o Usuário não serão desenvolvidos. |
Design de banco de dados | Utilizado somente se as entidades forem armazenadas em um banco de dados. Se você decidir não executar o design de banco de dados, nenhum Modelo de Dados será desenvolvido. |
Documente as decisões como parte do processo específico do projeto.
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 uma análise das vantagens e desvantagens desse artefato específico, leia a seção intitulada "Adaptação" para cada artefato.
Para cada artefato, decida como o artefato deve ser utilizado: Obrigatório, Recomendável, Opcional ou Desnecessário.
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. |
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. |
|
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). |
|
Estabelece a conexão entre casos de uso e design. |
Recomendada para a maioria dos projetos. |
|
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. |
|
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. |
|
Pode ser útil para sistemas que respondem a muitos eventos externos. | |
|
Pode ser útil para sistemas que necessitem de simultaneidade e sejam controlados por eventos. |
Recomendada para sistemas em tempo real. Pode ser útil para sistemas que necessitem de simultaneidade e sejam controlados por eventos. |
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 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:
|
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. |
Ajustar cada artefato para as necessidades do projeto. Para obter as considerações de ajuste, consulte a seção de ajuste da página de descrição dos artefatos
A decisão sobre os relatórios a serem utilizados depende das ferramentas de relatório disponíveis para o projeto. Se as ferramentas de geração de relatório estiverem disponíveis, será recomendável gerar relatórios para artefatos orientados a modelos, como Classes de Design, Realizações de Casos de Uso. Os relatórios existentes na configuração do RUP estão disponíveis nas páginas de descrição de artefato ou agrupadas sob o artefato relevante no navegador em árvore.
Decida o nível de revisão para cada artefato Decida como revisar e aprovar os resultados de Análise e Design e qual será o grau de revisão dos resultados.
As vantagens da revisão de design são:
As desvantagens da revisão de design são:
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 informações adicionais sobre revisão e sobre os diferentes tipos de revisão, consulte Diretriz de
Trabalho: Revisões.
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.
Rational Unified Process
|