Finalidade
  • Definir a entrada para a seleção do conjunto de cenários e casos de uso que serão analisados na iteração atual.
  • Definir o conjunto de cenários e casos de uso que representam uma funcionalidade central significativa.
  • Definir o conjunto de cenários e casos de uso que possuem cobertura arquitetural substancial (que experimentam vários elementos de arquitetura) ou que enfatizam ou ilustram um determinado ponto complicado da arquitetura.
 
Função:  Arquiteto de Software  
Freqüência: Conforme necessário, normalmente uma vez em cada iteração, iniciando com a Elaboração.
Etapas  
More Information: 
Artefatos de Entrada:    Artefatos Resultantes:   
Mentores de Ferramentas:   

Detalhes de Workflow:   

Priorizar Casos de Uso e Cenários Para o início da página

Um arquiteto de software propõe o conteúdo técnico e a ordem das iterações sucessivas, selecionando um determinado número de cenários e casos de uso para serem analisados e projetados. Essa proposta técnica é concluída e refinada pelas várias equipes de desenvolvimento, com base na disponibilidade de pessoal, nos requisitos do cliente em termos de produtos liberados, na disponibilidade das ferramentas e dos produtos de terceiros (COTS) e nas necessidades de outros projetos.

A seleção dos cenários e dos casos de uso que constituem a visualização do caso de uso baseia-se em alguns fatores de direcionamento-chave resumidos a seguir.

  • Benefícios do cenário aos investidores: crítico, importante, útil.
  • O impacto arquitetural do cenário: nenhum, estende, modifica. É possível que haja casos de uso críticos com pouco ou nenhum impacto na arquitetura e casos de uso de pouco benefício com um grande impacto. Os casos de uso de pouco benefício com grandes impactos na arquitetura devem ser revisados pelo coordenador de projeto para um possível cancelamento do escopo.
  • Os riscos a serem diminuídos (desempenho, disponibilidade de um produto e adequação de um componente).
  • A abrangência total da arquitetura (assegurando que, no final da fase de elaboração, cada parte do software a ser desenvolvido encontrou um espaço na Visão de Implementação).
  • Outros objetivos ou restrições táticas: demonstração para o usuário final, etc.

É possível haver dois cenários que atinjam os mesmos componentes e tratem de riscos semelhantes. Se A for implementado primeiro, então B não é significativo do ponto de vista da arquitetura. Se B for implementado primeiro, então A não é significativo do ponto de vista da arquitetura. Desse modo, esses atributos podem depender da ordem de iteração e deverão ser reavaliados quando a ordem for alterada, assim como quando os próprios requisitos forem alterados.

Esses fatores de direcionamento devem ser capturados como atributos dos requisitos, para que possam ser gerenciados com eficiência.

Os casos de uso significativos do ponto de vista da arquitetura que são malcompreendidos ou que têm a probabilidade de serem alterados devem ser priorizados para esclarecimento e estabilização. Em alguns casos, isso significa a necessidade de análise adicional dos requisitos antes da implementação do requisito. Em outros, seria melhor alguma forma de realização de protótipo.

Documentar a Visualização do Caso de Uso Para o início da página

A visão de casos de uso é documentada na seção correspondente do Documento de Arquitetura de Software. Essa seção contém uma listagem dos casos de uso e cenários significativos dentro de cada pacote do modelo de casos de uso, além de propriedades significativas, como as descrições do fluxo de eventos, dos relacionamentos, dos diagramas de casos de uso e dos requisitos especiais relacionados a cada caso de uso. Observe que, se a visão de casos de uso for desenvolvida no início da iteração, algumas dessas propriedades talvez não existam ainda.

 

Avaliar os Resultados Para o início da página

A visão de casos de uso deve ser verificada nesta fase, apenas para confirmar se o trabalho está caminhando bem. Não é necessária uma revisão detalhada da visão de casos de uso. Consulte principalmente os pontos de verificação da visualização de casos de uso em Atividade: Revisar a Arquitetura.



Rational Unified Process   2003.06.15