Casos de uso: diferenças entre include, extend e generalização

Vejo muitas situações onde alguns confundem muito o uso de relacionamentos em casos de uso, principalmente com include e extend.

Diagramas de casos de uso servem para descrever cenários de uma solução a ser desenvolvida, e interações dos usuários (atores) com funcionalidades (casos de uso, conhecidos também como UC) no sistema.  Pode-se relacionar o conceito de casos de uso com o conceito de estórias de usuários em scrum/XP.

O ator, na minha opinião é uma definição incorreta, pois o termo ator representa um indivíduo, e em UC o ator seria mais uma função, um papel, ou uma responsabilidade, que pode ser exercida por mais de uma pessoa (Ex. Cliente ao invés de Zezinho). Bom, mas isso é uma outra conversa.

Os UC, geralmente se relacionam com os atores, mas podem se relacionar também com outros UC. Até o UML 1.2, existia 2 relacionamentos entre UC: <<uses>> e <<extends>>. A partir do UML 1.3, existe 3 formas de relacionamento: inclusão (esteriótipo <<include>>), extenção (esteriótipo <<extend>>) e generalização.

O uso de <<include>> veio para substituir o <<uses>> da versão 1.1, e é usado quando casos compartilham comportamento comum com outros UC. Por isso até pode, mas não faz muito sentido um UC incluir somente um UC, pois não haverá compartilhamento e o conceito de “reutilização”, pois o UC incluído terá obrigatoriamente tal comportamento incluído.

O uso de <<extend>> é a utilização inversa da inclusão, e pode (não necessariamente) alterar o comportamento do UC que foi estendido. E nesse caso não tem problema conceitual em um UC estender somente um UC.

Segue um exemplo de extend e include. No caso seria um cenário onde o Vendedor tira um pedido para um cliente e ao tirar o pedido, ele pode ou não, dependendo do valor do pedido ou forma de pagamento, consultar o SPC e ao tirar o pedido, será feito a verificação de pagamentos em atrasos do cliente. No caso o Entregador fará a entrega do pedido, mas também será feito a verificação de pagamentos em atrasos, reutilizando a especificação dessa funcionalidade.

Quanto a generalização, foi introduzida a partir do UML 1.3, que é representada pela setinha fechada, é semelhante e muito facilmente confundido com o <<extend>>, acredito eu que pelo conceito de herança das linguagens de programação. Mas a generalização indica uma variação de outro UC. Uma alternativa ao uso de generalização é descrever um outro diagrama com o novo cenário. No exemplo de generalização abaixo, retrata dois cenários de pagamentos, em um só diagrama.

É muito importante lembrar que o grande valor dos casos de usos não estão no diagrama, e sim, na especificação (conteúdo/descrição) de cada UC, e existe uma metodologia para descrever os casos de uso, mas isso é assunto para um outro artigo.