segunda-feira, setembro 11, 2006

A disciplina de Análise

É comum dizer que esta disciplina do Processo Unificado tem como foco principal realizar o primeiro “corte” na arquitetura. Em geral, cada caso de uso selecionado é analisado em termos de classes de análise. Ou seja, temos uma primeira representação estática dos casos de uso, uma arquitetura candidata.

Por ainda não serem classes de projeto (ou concretas), esta estrutura estática sofrerá alterações em iterações futuras. Mas, de certa forma, o processo de desenvolvimento começa a se distanciar dos clientes e a ganhar um foco mais técnico. Este fato está ilustrado na figura 1 do post “A estrutura do Processo Unificado”. Nela podemos perceber que enquanto a curva da Análise vai se intensificando, a curva dos Requisitos perde intensidade. Neste momento, provavelmente o processo encontra-se no inicio da fase de Elaboração.

Um artefato principal é produzido durante esta disciplina:

  • Modelo de Análise


  • Este modelo é formado por pacotes de análise. Cada pacote representa um agrupamento lógico de diagramas de robustez da UML desenhados com classes de análise (ou objetos de Jacobson – Sim, ele mesmo, um dos criadores da UML!), e relacionamentos.


    Figura 1: Objetos de Jacobson.



    Cada classe de análise é classificada como Fronteira, Controle ou Entidade. Fronteira é um tipo de classe que interage com o ator. O Controle detém o conhecimento necessário para a correta execução do caso de uso, possui lógica. Já a Entidade, representa um conceito do domínio, muitas vezes é mapeada em uma tabela de banco de dados.

2 comentários:

Unknown disse...

"Diagramas de robustez da UML"?
Poderia elucidar quais diagramas são?

Otavio Ferreira disse...

Olá hlima, tudo bem?

Diagrama de Robustez realmente é um termo que não encontramos com muita frequência nos textos sobre o Processo Unificado. Podemos considerá-lo como um Diagrama de Classes. Porém, neste momento do processo, não é necessário que você descreva cada uma das classes de forma completa. Ou seja, não se preocupe em discriminar todos os atributos, operações, modificadores de visibilidade, etc. Na realidade, o importante é a identificação dos participantes deste primeiro corte da arquitetura, desta primeira visão estática do seu projeto. Como descrito no post, estes participantes são apenas classes esteriotipadas como Fronteira, Controle, ou Entidade. Adicionalmente, identifique também os relacionamentos entre as classes.

Em iterações futuras, você irá evoluir os Diagramas de Robustez, refinando cada uma de suas classes de análise. Neste momento, você estará desenhando o Modelo de Projeto, ainda uma visão estática, porém mais concreta que o Modelo de Análise. O Modelo de Projeto pode ser refinado em diversas iterações, cada uma delas poderá abaixar cada vez mais o nível de abstração considerado. Este refinamento deve acontecer até que a equipe sinta-se segura para iniciar a codificação.

É isso ai. Espero ter esclarecido sua dúvida. Fique à vontade para continuar este bate-papo. Um abraço! :-)

 
> blogblogs.com.br