A disciplina de Projeto

Esta disciplina é a principal responsável pela elaboração da arquitetura. Ela utiliza-se dos artefatos produzidos na fase de Análise como base para a elaboração de uma arquitetura baseada em classes de projeto, ou classes concretas. Em geral procura-se unificar os diagramas e não mais manter um para cada caso de uso. Neste estágio é preciso ter uma idéia mais ampla da arquitetura como um todo, inclusive no que diz respeito a questões como flexibilidade, expansibilidade, manutenibilidade e reuso.

A disciplina de Projeto é fundamental em uma metodologia centrada em arquitetura. Realizar bem as tarefas neste momento pode garantir um bom tempo de resposta nas atualizações do software futuramente.

Questões como distribuição de objetos e utilização de frameworks também são consideradas.

Esta disciplina possui a mesma curva de intensidade da disciplina de Análise. Realmente, a análise e o projeto orientados a objetos estão altamente relacionados e se complementam.

Dois artefatos são produzidos durante esta disciplina. São eles:

• Modelo de Projeto:


Este modelo é formado por pacotes de projeto. Cada pacote representa um agrupamento lógico de diagramas estáticos, como o diagrama de classes, e dinâmicos, como o diagrama de seqüência e o diagrama de objetos.

Os diagramas estáticos são responsáveis por discriminar os relacionamentos entre as classes de projeto. Deve-se buscar um baixo acoplamento.

Já os diagramas dinâmicos exibem como cada uma das classes de projeto se comporta em tempo de execução. Técnicas como a Inversão de Dependência só podem ser visualizadas em diagramas deste tipo.


• Modelo de Instalação:


Define a organização física do sistema em termos de nós computacionais, os quais são peças de hardware que representam um recurso, como um servidor, uma estação de trabalho ou algum outro software.

Os componentes que formam a arquitetura residem nos nós computacionais. A listagem dos componentes deve ser apresentada no interior de cada nó.

O principal artefato deste modelo é o diagrama de instalação da UML, que discrimina como os nós se relacionam. Os diagramas podem ser agrupados logicamente em pacotes, denominados pacotes de instalação.

Outro objetivo deste modelo é apresentar ao cliente qual a infra-estrutura necessária para a correta execução do software. Este tipo de informação, quando entregue ao final da fase de Elaboração, faz que o cliente tenha tempo para preparar o ambiente.

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.