Qual é a diferença entre o diagrama de casos de uso de inclusão e extensão?

Qual é a diferença entre includee extendem um diagrama de casos de uso ?

Estender é usado quando um caso de uso inclui etapas em outro caso de uso de primeira classe.

Por exemplo, imagine "Retirar dinheiro" é um caso de uso de um caixa eletrônico (ATM). A "Taxa de avaliação" estenderia o saque em dinheiro e descreveria o "ponto de extensão" condicional instanciado quando o usuário do caixa eletrônico não deposita na instituição proprietária do caixa eletrônico. Observe que o caso de uso básico "Retirar dinheiro" é autônomo, sem a extensão.

Incluir é usado para extrair fragmentos de casos de uso duplicados em vários casos de uso. O caso de uso incluído não pode ficar sozinho e o caso de uso original não está completo sem o incluído. Isso deve ser usado com moderação e apenas nos casos em que a duplicação é significativa e existe por design (e não por coincidência).

Por exemplo, o fluxo de eventos que ocorre no início de cada caso de uso de ATM (quando o usuário coloca seu cartão ATM, insere seu PIN e é exibido no menu principal) seria um bom candidato para uma inclusão.

Isso pode ser contencioso, mas o “inclui sempre e se estende às vezes” é um equívoco muito comum que quase assumiu agora o significado de fato. Aqui está uma abordagem correta (na minha opinião, e comparada com Jacobson, Fowler, Larmen e 10 outras referências).

Relacionamentos são dependências

A chave para incluir e estender relacionamentos de casos de uso é perceber que, comum com o restante da UML, a seta pontilhada entre os casos de uso é um relacionamento de dependência. Usarei os termos 'base', 'incluído' e 'estendendo' para se referir às funções de caso de uso.

incluir

Um caso de uso base depende dos casos de uso incluídos; sem ele, o caso de uso básico está incompleto, pois os casos de uso incluídos representam subseqüências da interação que podem ocorrer sempre OU às vezes. (Isso é contrário a um equívoco popular sobre isso, o que seu caso de uso sugere sempre acontece no cenário principal e às vezes acontece em fluxos alternativos simplesmente depende do que você escolhe como cenário principal; os casos de uso podem ser facilmente reestruturados para representar um fluxo diferente como o cenário principal e isso não deve importar).

Na melhor prática de dependência unidirecional, o caso de uso básico conhece (e refere-se a) o caso de uso incluído, mas o caso de uso incluído não deve 'conhecer' sobre o caso de uso base. É por isso que os casos de uso incluídos podem ser: a) casos de uso de base por direito próprio eb) compartilhados por vários casos de uso de base.

ampliar

O caso de uso estendido depende do caso de uso base; literalmente estende o comportamento descrito pelo caso de uso base. O caso de uso base deve ser um caso de uso totalmente funcional por si só ('inclui os incluídos, é claro) sem a funcionalidade adicional do caso de uso estendido.

A extensão de casos de uso pode ser usada em várias situações:

1. O caso de uso base representa a funcionalidade “deve ter” de um projeto, enquanto o caso de uso estendido representa um comportamento opcional (deve / poderia / deseja). É aqui que o termo opcional é relevante - opcional se você deseja construir / entregar em vez de opcional, se às vezes é executado como parte da sequência de casos de uso base.
2. Na fase 1, você pode entregar o caso de uso básico que atenda aos requisitos naquele momento, e a fase 2 adicionará funcionalidade adicional descrita pelo caso de uso estendido. Isso pode conter seqüências que são sempre ou algumas vezes executadas após a entrega da fase 2 (novamente contrária ao equívoco popular).
3. Ele pode ser usado para extrair subsequências do caso de uso base, especialmente quando elas representam um comportamento complexo 'excepcional' com seus próprios fluxos alternativos.

Um aspecto importante a considerar é que o caso de uso estendido pode 'inserir' o comportamento em vários lugares no fluxo do caso de uso básico, não apenas em um único local, como um caso de uso incluído. Por esse motivo, é altamente improvável que um caso de uso estendido seja adequado para estender mais de um caso de uso base.

Quanto à dependência, o caso de uso estendido depende do caso de uso base e é novamente uma dependência unidirecional, ou seja, o caso de uso base não precisa de nenhuma referência ao caso de uso estendido na sequência. Isso não significa que você não pode demonstrar os pontos de extensão ou adicionar um x-ref ao caso de uso estendido em outra parte do modelo, mas o caso de uso base deve poder funcionar sem o caso de uso estendido.

RESUMO

Espero ter demonstrado que o equívoco comum de "inclui sempre é, estende-se às vezes" está errado ou, na melhor das hipóteses, simplista. Essa versão realmente faz mais sentido se você considerar todos os problemas sobre a direcionalidade das setas que o equívoco apresenta - no modelo correto, é apenas dependência e não muda potencialmente se você refatorar o conteúdo do caso de uso.

Costumo usar isso para lembrar os dois:

Meu caso de uso: estou indo para a cidade.

inclui -> dirigir o carro

estende -> encha a gasolina

"Encha a gasolina" pode não ser obrigatório o tempo todo, mas pode ser opcionalmente necessário com base na quantidade de gasolina restante no carro. "Dirija o carro" é um pré-requisito, portanto, estou incluindo.

Casos de uso são usados ​​para documentar o comportamento, por exemplo, responda a esta pergunta.

Um comportamento se estende a outro, se é um complemento, mas não necessariamente parte dele, por exemplo, pesquise a resposta.

Observe também que pesquisar a resposta não faz muito sentido se você não estiver tentando responder à pergunta.

Um comportamento é incluído em outro se fizer parte do comportamento de inclusão, por exemplo, login para empilhar troca.

Para esclarecer, a ilustração só é verdadeira se você quiser responder aqui no estouro de pilha :).

Estas são as definições técnicas das páginas 671-672 da UML 2.5 .

Eu destaquei o que acho que são pontos importantes.

Estende

Um Estender é um relacionamento de um UseCase estendido (a extensão) para um UseCase estendido (o extendedCase) que especifica como e quando o comportamento definido no UseCase estendido pode ser inserido no comportamento definido no UseCase estendido. A extensão ocorre em um ou mais pontos de extensão específicos definidos no UseCase estendido.

O Extend deve ser usado quando houver algum comportamento adicional que deve ser adicionado, possivelmente condicionalmente , ao comportamento definido em um ou mais UseCases.

O UseCase estendido é definido independentemente do UseCase de extensão e é significativo independentemente do UseCase de extensão . Por outro lado, o UseCase estendido geralmente define um comportamento que pode não ser necessariamente significativo por si só . Em vez disso, o UseCase estendido define um conjunto de incrementos de comportamento modular que aumentam a execução do UseCase estendido sob condições específicas.

...

Inclui

Include é um DirectedRelationship entre dois UseCases, indicando que o comportamento do UseCase incluído (a adição) é inserido no comportamento do UseCase incluído (o includingCase). Também é um tipo de NamedElement, para que possa ter um nome no contexto de UseCase proprietário (o includingCase). O UseCase incluído pode depender das alterações produzidas pela execução do UseCase incluído. O UseCase incluído deve estar disponível para que o comportamento do UseCase incluído seja completamente descrito.

O relacionamento Incluir deve ser usado quando houver partes comuns do comportamento de dois ou mais UseCases. Essa parte comum é então extraída para um UseCase separado, a ser incluído por todos os UseCases de base que possuem essa parte em comum . Como o uso principal do relacionamento Incluir é para reutilizar partes comuns, o que resta em um UseCase básico geralmente não é completo por si só, mas depende das partes incluídas para serem significativas. Isso se reflete na direção do relacionamento, indicando que o UseCase base depende da adição, mas não vice-versa.

...

Eu acho que é importante entender a intenção de incluir e estender:

"O relacionamento include destina-se a reutilizar o comportamento modelado por outro caso de uso , enquanto o relacionamento estendido destina-se a adicionar peças aos casos de uso existentes , bem como a modelar serviços opcionais do sistema" (Overgaard e Palmkvist, Casos de Uso: Padrões e Projetos. Addison -Wesley, 2004).

Isso me lê como:

Incluir = reutilização da funcionalidade (ou seja, a funcionalidade incluída é usada ou pode ser usada em outra parte do sistema). Incluir, portanto, denota uma dependência em outro caso de uso.

Estende = adicionando (não reutilizando) funcionalidade e também qualquer funcionalidade opcional . Portanto, as extensões podem indicar uma das duas coisas:
1. adicionando novos recursos / capacidades a um caso de uso (opcional ou não)
2. quaisquer casos de uso opcionais (existentes ou não).

Resumo:
Incluir = reutilização da funcionalidade
Estende = funcionalidade nova e / ou opcional

Você encontrará com mais freqüência o segundo uso (ou seja, funcionalidade opcional) de extensões, porque se a funcionalidade não é opcional, na maioria das vezes ela é incorporada ao próprio caso de uso, em vez de ser uma extensão. Pelo menos essa tem sido a minha experiência. (Julian C salienta que às vezes você vê o 1º uso (isto é, adicionando novos recursos) de extensões quando um projeto entra na 2ª fase).

Para simplificar,

para include

1. Quando o caso de uso base é executado, o caso de uso incluído é executado TODOS OS TEMPOS .
2. O caso de uso base exigiu a conclusão do caso de uso incluído para ser concluído.

um exemplo típico: entre login e verificação de senha

(login) --- << incluir >> --- > (verificar senha)

para que o processo de login seja bem-sucedido, "verificar senha" também deve ser bem-sucedido.

para extend

1. Quando o caso de uso base é executado, o caso de uso estendido é executado apenas SOMETIMES
2. O caso de uso estendido ocorrerá somente quando determinados critérios forem atendidos.

um exemplo típico: entre o login e mostrar a mensagem de erro (aconteceu algumas vezes)

(login) < --- << estender >> --- (mostrar mensagem de erro)

"mostrar mensagem de erro" só acontece algumas vezes quando o processo de login falha.

Eu acho que o que o msdn explicou aqui é bastante fácil de entender.

Incluir [5]

Um caso de uso incluído chama ou chama o incluído. A inclusão é usada para mostrar como um caso de uso é dividido em etapas menores. O caso de uso incluído está no final da ponta da seta.

Estender [6]

Enquanto isso, um caso de uso estendido adiciona metas e etapas ao caso de uso estendido. As extensões operam apenas sob certas condições. O caso de uso estendido está na extremidade da ponta da seta.

Vamos deixar isso mais claro. Usamos includetoda vez que queremos expressar o fato de que a existência de um caso depende da existência de outro.

EXEMPLOS:

Um usuário pode fazer compras on-line somente depois de fazer login em sua conta. Em outras palavras, ele não pode fazer compras até que tenha feito login em sua conta.

Um usuário não pode fazer o download de um site antes do upload do material. Portanto, não consigo fazer o download se nada tiver sido carregado.

Você entendeu?

É uma consequência condicionada. Eu não posso fazer isso se anteriormente não fiz isso .

Pelo menos, acho que é assim que usamos Include. Costumo pensar que o exemplo com laptop e a garantia logo acima são os mais convincentes!

sempre que houver pré-requisitos para um caso de uso, inclua.

para casos de autenticação com autenticação, no pior cenário, ou são opcionais, vá para extensão ..

exemplo: para um caso de uso de busca de admissão, compromisso, reserva de ingresso, VOCÊ DEVE preencher um formulário (formulário de registro ou feedback) .... é aqui que vem incluído.

exemplo: para um caso de uso que verifica o login ou o login na sua conta, sua autenticação é essencial.Também pense nos piores cenários.Como devolver um livro com multa ... NÃO obter uma reserva .. pagar a fatura APÓS DATA DATA..este é onde estender vem para jogar ...

não use demais e inclua nos diagramas.

MANTÊ-LO SIMPLES PARVO !!!

Também tenha cuidado com a versão UML: já faz muito tempo que << usos >> e << inclui >> foram substituídos por << inclui >> e << estende >> por << estende >> AND generalização .
Para mim, esse é frequentemente o ponto enganador: como exemplo, o post e o link de Stephanie são sobre uma versão antiga:

Ao pagar por um item, você pode optar por pagar na entrega, pagar usando paypal ou pagar com cartão. Todas essas são alternativas ao caso de uso "pagar pelo item". Eu posso escolher qualquer uma dessas opções, dependendo da minha preferência.

De fato, não há realmente nenhuma alternativa para "pagar pelo item"! Atualmente, na UML, "pagamento na entrega" é uma extensão e "pagamento via paypal" / "pagamento com cartão" são especializações.

"Incluir" é usado para estender o caso de uso base e é uma condição obrigatória, ou seja, a execução do caso de uso incluído deve ser executada com êxito para concluir o uso base.

Por exemplo, considere um caso de serviço de email, aqui "Login" é um caso de uso incluído que deve ser executado para enviar um email (caso de uso Base)

"Excluir", por outro lado, é um caso de uso opcional que estende o caso de uso base, o caso de uso base pode ser executado com êxito mesmo sem chamar / chamar o caso de uso estendido.

por exemplo, considere "Compra de laptop" como caso de uso base e "Garantia adicional" como caso de uso estendido, aqui você pode executar o caso de uso base "Compra de laptop", mesmo sem ter garantia adicional.

Este é um ótimo recurso, com grande explicação: O que é incluir no caso de uso? O que é o Extend no caso de uso?

A extensão do caso de uso geralmente define o comportamento opcional. É independente do caso de uso estendido

Incluir usado para extrair partes comuns dos comportamentos de dois ou mais casos de uso

Elementos do diagrama

• Atores: também conhecidos como papéis. O nome e o estereótipo de um ator podem ser alterados na guia Propriedades.

• Herança: Relações de refinamento entre atores. Essa relação pode conter um nome e um estereótipo.

• Casos de uso: eles podem ter pontos de extensão.

• Pontos de extensão: define um local onde uma extensão pode ser adicionada.

• Associações: Entre funções e casos de uso. É útil dar nomes que falem às associações.

• Dependências: Entre casos de uso. As dependências geralmente têm um estereótipo para definir melhor o papel da dependência. Para selecionar um estereótipo, selecione a dependência no diagrama ou no painel Navegação e altere o estereótipo na guia Propriedades. Existem dois tipos especiais de dependências: <<extend>>e <<include>>, para os quais Poseidon oferece botões próprios (veja abaixo).

• Estender relacionamento: um relacionamento unidirecional entre dois casos de uso. Um relacionamento estendido entre o caso de uso B e o caso de uso A significa que o comportamento de B pode ser incluído em A.

• Incluir relacionamento: um relacionamento unidirecional entre dois casos de uso. Essa relação entre os casos de uso A e B significa que o comportamento de B é sempre incluído em A.

• Borda do sistema: na verdade, a borda do sistema não é implementada como elemento de modelo no Poseidon for UML. Você pode simplesmente desenhar um retângulo, enviá-lo para o plano de fundo e usá-lo como borda do sistema, colocando todos os casos de uso correspondentes dentro do retângulo.

Ambos <include>e <extend>são dependentes da classe base mas <extend>é isto é opcional, ele é derivado a partir da classe de base, mas no ponto dos utilizadores visualizam pode ser utilizado ou não pode ser utilizado.

<include>é incorporado na classe base, ou seja, é obrigatório o uso <include>no seu caso de uso ou seria considerado incompleto.

por exemplo:

Na construção da máquina ATM (de acordo com o ponto de vista do usuário):

1: Retirada, depósito em dinheiro e verificação da conta, <extend>porque depende do usuário retirar ou depositar ou verificar. Essas são coisas opcionais que o usuário faz.

2: "Insira o pino, colocando o cartão, removendo o cartão", estas são as coisas que se encaixam <include>porque o usuário deve e deve colocar um cartão e inserir um pino válido para verificação.

Não recomendo o uso disso para lembrar os dois:

Meu caso de uso: estou indo para a cidade.

inclui -> dirigir o carro

estende -> encha a gasolina

Prefiro que você use: Meu caso de uso: estou indo para a cidade.

estende -> dirigindo o carro

inclui -> encher a gasolina

Sou ensinado que o relacionamento estendido continua o comportamento de uma classe base. As funcionalidades da classe base precisam estar lá. A relação de inclusão, por outro lado, é semelhante a funções que podem ser chamadas. Maio está em negrito.

Isso pode ser visto em Reutilização rápida de modelos em casos de uso

A diferença entre os dois foi explicada aqui. Mas o que não foi explicado é o fato de que <<include>>e <<extend>>não deve simplesmente ser usado em tudo.

Se você lê Bittner / Spence, sabe que os casos de uso são sobre síntese, não análise. Uma reutilização de casos de uso não faz sentido. Isso mostra claramente que você cortou seu domínio incorretamente. O valor agregado deve ser único por si só. A única reutilização de valor agregado que conheço é a franquia. Então, se você está no negócio de hambúrguer, bom. Mas em qualquer outro lugar sua tarefa como BA é tentar encontrar uma USP. E isso deve ser apresentado em bons casos de uso.

Sempre que vejo pessoas usando uma dessas relações, é quando elas tentam fazer a decomposição funcional. E isso está errado.

Para simplificar: se você puder responder ao seu chefe sem hesitar "eu já fiz ...", o "..." é o seu caso de uso, pois você tem dinheiro para fazê-lo. (Isso também deixará claro que "login" não é um caso de uso.)

Nesse sentido, é muito improvável encontrar casos de uso independentes incluídos ou estender outros casos de uso. Eventualmente, você pode usar <<extend>>para mostrar a opcionalidade do seu sistema, ou seja, algum esquema de licenciamento que permita incluir casos de uso para algumas licenças ou omiti-los. Mas mais - apenas evite-os.

Extends é usado quando você entende que seu caso de uso é muito complexo. Portanto, você extrai as etapas complexas em seus próprios casos de uso de "extensão".

Inclui é usado quando você vê um comportamento comum em dois casos de uso. Portanto, você abstrai o comportamento comum em um caso de uso "abstrato" separado.

(ref: Jeffrey L. Whitten, Lonnie D. Bentley, Análise de sistemas e métodos de projeto, McGraw-Hill / Irwin, 2007)

O relacionamento de inclusão permite que um caso de uso inclua as etapas de outro caso de uso.

Por exemplo, suponha que você tenha uma Conta Amazon e deseje verificar um pedido, bem, é impossível verificar o pedido sem primeiro fazer login na sua conta. Então o fluxo de eventos gostaria que fosse ...

O relacionamento de extensão é usado para adicionar uma etapa extra ao fluxo de um caso de uso, que geralmente é uma etapa opcional ...

Imagine que ainda estamos falando da sua conta amazon. Vamos supor que o caso base seja Order e o caso de uso de extensão seja Amazon Prime . O usuário pode optar por pedir apenas o item regularmente ou, pode escolher o Amazon Prime, garantindo que seu pedido chegue mais rápido a um custo mais alto.

No entanto, observe que o usuário não precisa selecionar o Amazon Prime; isso é apenas uma opção; ele pode optar por ignorar esse caso de uso.

Eu gosto de pensar em "inclui" como um pré-requisito / acompanhamento necessário do caso de uso básico. Isso significa que o caso de uso base não pode ser considerado completo sem o caso de uso que ele inclui. Vou dar o exemplo de um site de comércio eletrônico que vende itens para os clientes. Não há como pagar por um item sem primeiro selecioná-lo e colocá-lo no carrinho. Isso implica que o caso de uso "Pagar pelo item" inclui "selecionar item".

Existem vários usos de extensões, mas eu gosto de pensar nisso como uma alternativa que pode ou não ser usada. Por exemplo - ainda no site de comércio eletrônico. Ao pagar por um item, você pode optar por pagar na entrega, pagar usando paypal ou pagar com cartão. Todas essas são alternativas ao caso de uso "pagar pelo item". Eu posso escolher qualquer uma dessas opções, dependendo da minha preferência.

Para mais clareza e as regras que envolvem os casos de uso, leia meu artigo aqui:

http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics