• Design the Solution
• Analysis & Design

Uma realização de caso de uso mostra como um caso de uso será implementado na forma de objetos de colaboração. Este artefato pode ter várias formas. Pode conter, por exemplo, uma descrição textual (um documento), diagramas de classe com subsistemas e classes, e diagramas de interação (diagramas de comunicação e de seqüência) que ilustram o fluxo das interações entre as instancias de classes e subsistemas.

A razão de separar a realização de caso de uso de seu caso do uso é que ao fazermos isto permitimos que os casos de uso sejam controlados separadamente de suas realizações. Isto é particularmente importante para projetos maiores, ou famílias de sistemas onde os mesmos casos de uso podem ser projetados diferentemente em vários produtos dentro da família de produto. Considere o caso de uma família de switches telefônicos que têm muitos casos de uso em comum, mas que são projetados e implementados diferentemente de acordo com o posicionamento, desempenho e preço do produto.

Para projetos maiores, separar o caso de uso de sua realização permite fazer mudanças no design do caso  de uso sem afetar a versão de linha de base do próprio caso de uso.

Em um modelo, uma realização de caso de uso é representada como uma colaboração UML que agrupa os diagramas e outras informações (tais como descrições textuais) que fazem parte da realização do caso de uso.

Os diagramas UML que suportam realizações de caso de uso podem ser produzidos em um contexto de análise, em um contexto de design, ou em ambos, dependendo das necessidades do projeto. Para cada caso de uso no modelo de caso de uso, pode haver uma realização de caso de uso no modelo de análise/design com um relacionamento de realização ao caso do uso. Na UML isto é mostrado como uma seta tracejada, igual ao relacionamento de generalização, indicando que uma realização é um tipo de herança, bem como uma dependência.

Uma realização de caso de uso na fase de design pode ser rastreada ao caso de uso no modelo de caso de uso.

Diagramas de Classe de uma Realização de Caso de Uso

Para cada realização de caso de uso pode haver um ou mais diagramas de classe que descrevem suas classes participantes. Uma classe e seus objetos normalmente participam de diversas realizações de caso de uso. Ao projetar, é importante coordenar todos os requisitos em uma classe e em seus objetos que diferentes realizações de caso de uso possam ter. A figura abaixo mostra um diagrama de classe de análise para a realização do caso de uso “Receber Depósito”. Note o uso de estereótipos entidade-controle-fronteira para representar as classes de análise (veja Conceito: Padrão Entidade-Controle-Fronteira).

The use case Receive Deposit Item and its analysis-level class diagram.

Diagramas de Comunicação e Seqüência de uma Realização de Caso de Uso

Para cada realização de caso de uso pode haver um ou mais diagramas de interação que descrevem seus objetos e suas interações. Há dois tipos de diagramas de interação: diagramas de seqüência e diagramas de comunicação. Eles expressam informações similares, mas mostram-nas de formas diferentes. Os diagramas de seqüência mostram a seqüência explícita das mensagens e são melhores quando é importante visualizar a ordem temporal das mensagens, enquanto que os diagramas de  comunicação mostram as ligações de comunicação entre os objetos e são melhores para compreender todos os efeitos causados em um objeto e para o projeto de algoritmos.

Realizar casos de uso com diagramas de interação ajuda a manter o design simples e coesivo. Atribuindo responsabilidades às classes atendendo ao que o cenário de caso de uso requer incentiva o design a conter o seguinte:

• Somente a funcionalidade usada realmente para suportar um cenário de caso de uso.
• Funcionalidade que pode ser testada através de um caso de teste associado.
• Funcionalidade que é mais facilmente rastreável aos requisitos e às mudanças.
• Dependências de classe explicitamente declaradas que são mais fáceis de controlar.

Estes fatores ajudam a melhorar a qualidade geral do sistema.

• Padrão Entidade-Controle-Fronteira