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.
FONTE: arezi.wordpress
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.
FONTE: arezi.wordpress
Comentários
Postar um comentário