Uma realização de caso de uso mostra como um caso de uso será implementado na forma de objetos de colaboração. As realizações residem no design. Ao percorrer um design exercite mostrando como os elementos de design irão executar o caso de uso, a equipe recebe a confirmação de que o design está robusto o suficiente para executar o comportamento exigido.

A realização pode assumir diversas 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 instâncias 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 requisitos, na forma de casos de uso sejam controlados separadamente do design, na forma de realizações. Essa separação se torna inestimável se a arquitetura mudar muito de forma que a realização precise ser retrabalhada enquanto os requisitos permaneçam inalterados. Mesmo sem tal circunstância, a clara separação entre as preocupações dos requisitos e do design é valiosa.

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 formam a realização do caso de uso.

Como outros aspectos do projeto, os diagramas UML que suportam realizações de casos de uso podem ser produzidos em vários níveis de abstração. O primeiro passo na criação da realização pode produzir um diagrama no nível de abstração de análise, onde os participantes serão elementos de alto nível que venham a ser revisados e detalhados no nível de design em um segundo passo. Se as expressões idiomáticas da arquitetura e do design forem bem entendidas, a realização poderá ser criada imediatamente em um baixo nível de abstração, que especifique mais detalhes dos elementos e como eles irão colaborar para realizar o comportamento do caso de uso. Neste último caso, é valioso modelar padrões e mecanismos arquiteturais para reduzir a quantidade de detalhes de baixo nível, em cada realização.

Para cada caso de uso nos requisitos, pode haver uma realização de caso de uso no design com um relacionamento de realização ao caso do uso, como mostra a figura a seguir. 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 (veja a figura a seguir).

A notação UML para realização de caso de uso

Diagramas de Classe que pertencem a uma realização de caso de uso

O caso de uso Receber Depósito e o seu diagrama de classe em nível de análise

Diagramas de seqüência e de comunicação

Para cada realização de caso de uso podem existir um ou mais diagramas de interação que descrevem os objetos participantes 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 mais indicados quando é importante visualizar a ordem temporal das mensagens.
• Os diagramas de comunicação mostram as ligações de comunicação entre os objetos e são mais indicados para a compreensão de 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 os seguintes elementos:

• Somente a funcionalidade usada realmente para suportar um cenário de caso de uso
• A funcionalidade que pode ser testada através de um caso de teste associado
• A funcionalidade que é mais facilmente rastreável aos requisitos e às mudanças
• 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.