A atividade de projeto de casos de uso é a transformação das classes de análise em uma ou mais classes de projeto. A representação das classes na atividade de projeto é muito mais próxima da implementação.



PROJETO

​Resultados
Os resultados da atividade de projeto de casos de uso são:
- Classes de projeto
- Operações e atributos de cada classe
- Diagramas de interação para mostrar como as classes de projeto colaboram para realizar os processos do negócio capturados nos casos de uso.
- Arquitetura de software (SAD Software Architecture Document)
- Interfaces com subsistemas específicos ou software de terceiros
- Subsistemas

Método

- Criar realizações de casos de uso: na análise, as realizações contêm classes de análise e objetos que aparecem em diagramas de classes e de interação. No projeto, são utilizados praticamente os mesmos diagramas, a diferença é que as informações são mais próximas da implementação.
- Descrever interações entre objetos e refinar diagrama de classes
- Simplificar diagramas de seqüência utilizando subsistemas (opcional)
- Descrever comportamentos associados à persistência.



CLASSES DE PROJETO

Classes de Análise x Projeto
Qual a diferença entre uma classe de análise e uma de projeto?
- Uma classe de projeto é especificada na linguagem de programação alvo (tipos de dados, operações, atributos são definidos utilizando-se a sintaxe da linguagem de programação).
- As visibilidades dos atributos e operações de uma classe de projeto são especificadas na maior parte das vezes.
- As relações entre classes num diagrama de classes de projeto influenciam diretamente na implementação destas classes. Por exemplo, associações e agregações são mapeadas para atributos das classes para que os objetos envolvidos possam se referenciar.
- Operações das classes de projeto são traduzidas de forma direta em código.



REFINAR O DIAGRAMA DE CLASSES

A partir dos diagramas de seqüência de projeto, detalham-se as relações do diagrama de classes.

Dependência

Uma relação de dependência indica que uma classe depende do auxílio de outra classe para implementar seus comportamentos. É um relacionamento utilizado prioritariamente na fase de projeto.

Implementação de associações e agregações

Não há diferença entre a implementação de uma associação e uma agregação.
Também não há diferenças significativas entre uma agregação por associação e uma agregação por composição.

Multiplicidade 1:1 e variações

Associações unidirecionais de multiplicidade 1:1 são de simples implementação: basta colocar um atributo na classe origem da relação. Se a relação for bidirecional, coloca-se um atributo em cada uma das classes que participam da associação.

Multiplicidade 1:* e variações
Quando a multiplicidade máxima é menor que infinito (e não muito grande) pode-se alocar espaço na instanciação do objeto do lado 1 e povoar o vetor neste instante ou posteriormente.

Multiplicidade *:*
A implementação de associações com multiplicidade *:* envolve a utilização de coleções.

Associações reflexivas
O mapeamento para Java de uma associação reflexiva não difere dos mapeamentos entre duas classes distintas.

​Classes associativas
Classes associativas podem ser transformadas em classes comuns e, a partir daí, as associações caem nos casos anteriores.

Agregação por composição

É uma agregação de fato, a criação/alocação de um objeto é feita dentro de outro.

Agregação por associação

A implementação é idêntica a da associação.

Realização

É uma relação que indica que uma classe realiza ou segue o contrato definido por uma classe de interface (no sentido Java).



SUBSISTEMAS

Subsistemas podem conter outros elementos de modelagem (ex. classes, pacotes) e apresentam comportamento definido pelas interfaces que realiza. Em UML, subsistemas são representados como pacotes, porém com um estereótipo <<subsistema>>.