Tópicos

Decidir Como Executar o Workflow Para o início da página

As decisões a seguir devem ser tomadas em relação ao workflow da disciplina Análise e Design:

  • Decida como executar o workflow consultando Análise e Design: Workflow. Analise o diagrama com suas ../glossary.htm#guard_condition -- This hyperlink in not present in this generated websitecondições de guarda e as diretrizes. Decida os detalhes do workflow a serem executados e em qual ordem. 
  • Decida as partes dos detalhes do workflow Análise e Design a serem executadas. As partes a seguir podem ser incluídas com certa independência em relação às demais.

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. 

  • Durante o ciclo de vida do projeto, decida quando incluir cada parte do workflow. Às vezes, é possível aguardar até a fase de Elaboração para introduzir a disciplina Análise e Design. Por exemplo, se o desenvolvimento for feito em um domínio que seja bem compreendido, não tiver requisitos que exijam desempenho (ou outros requisitos não-funcionais) e for baseado em uma arquitetura que já tenha sido testada e aprovada, praticamente não haverá necessidade de elaborar protótipos durante a Iniciação.

Documente as decisões como parte do processo específico do projeto.

Decidir Como Utilizar Artefatos Parte superior da página

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.

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 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.

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.

Sinal

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:

  • 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.


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

Decidir os Relatórios a Serem Utilizados Para o início da página

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.

Decidir Como Revisar Para o início da página

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:

  • Permite localizar problemas cuja detecção é impossível ou muito difícil nos testes. Por exemplo, problemas de estilo e de layout. 
  • É uma maneira de impor um estilo de modelagem comum e uma oportunidade para as pessoas aprenderem umas com as outras.  
  • Permite localizar defeitos que só seriam detectados muito mais tarde no projeto durante os testes.

As desvantagens da revisão de design são:

  • Demanda tempo e recursos.  
  • Se não for bem gerenciada, pode facilmente ser utilizada de maneira errada.

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:

  • Decidir que as mudanças locais em um subsistema serão revisadas apenas por uma pessoa, que realizará uma inspeção e encaminhará os resultados por escrito.
  • Decidir que partes do design não sofrerão nenhuma revisão; por exemplo, revisar apenas algumas classes para cada membro do projeto e esperar que isso assegure que a qualidade do estilo seja semelhante no restante dos resultados.
  • Decidir que o Documento de Arquitetura de Software será revisado pelo cliente durante uma reunião separada.
  • Decidir fazer reuniões de revisão formais para implementar mudanças em interfaces importantes, ou seja, interfaces que afetam o trabalho de vários membros do projeto.

Para obter informações adicionais sobre revisão e sobre os diferentes tipos de revisão, consulte ../workguid/wg_rview.htm -- This hyperlink in not present in this generated websiteDiretriz de Trabalho: Revisões.

Decidir se o Código Deve Ser Gerado Para o início da página

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   2003.06.15