Qual's é a diferença entre incluir e estender no diagrama de caso de uso?

Extender é usado quando um caso de uso adiciona passos a outro caso de uso de primeira classe.

Por exemplo, imagine "Withdraw Cash" é um caso de uso de uma ATM (Automated Teller Machine). "Avaliar Fee" estenderia o Withdraw Cash e descreveria o condicional "ponto de extensão" isso é instanciado quando o usuário do ATM não't banca no ATM'instituição proprietária do ATM. Repare que o "ponto "básico de saque; caso de uso fica por conta própria, sem a extensão.

Inclua é usado para extrair fragmentos de casos de uso que são duplicados em casos de uso múltiplo. O estojo de uso incluído não pode ficar sozinho e o estojo de uso original não está completo sem o estojo incluído. Isto deve ser usado com moderação e apenas nos casos em que a duplicação é significativa e existe por desenho (e não por coincidência).

Por exemplo, o fluxo de eventos que ocorre no início de cada caixa eletrônico (quando o usuário coloca em seu cartão ATM, digita seu PIN e é mostrado o menu principal) seria um bom candidato a um include.

Isto pode ser controverso, mas o "incluir é sempre e se estende é às vezes" é um equívoco muito comum que quase assumiu agora como o significado de fato. Aqui está uma abordagem correcta (na minha opinião, e verificada contra Jacobson, Fowler, Larmen e outras 10 referências).

As relações são dependências

A chave para incluir e ampliar as relações de casos de uso é perceber que, comum ao resto da UML, a seta pontilhada entre os casos de uso é uma relação de dependência. Vou usar os termos 'base', 'incluído' e 'estendendo' para me referir às funções dos casos de uso.

incluem

Um caso de uso básico depende do(s) caso(s) de uso incluído(s); sem ele(s) o caso de uso básico é incompleto, pois o(s) caso(s) de uso incluído(s) representa(m) sub-sequências da interação que pode(m) acontecer sempre OU às vezes. (Isto é contrário a um equívoco popular sobre isto, o que o seu caso de uso sugere sempre acontece no cenário principal e às vezes acontece em fluxos alternativos simplesmente depende do que você escolher como cenário principal; casos de uso podem ser facilmente reestruturados para representar um fluxo diferente como o cenário principal e isto não deve importar).

Na melhor prática de dependência de uma forma, o caso de uso básico conhece (e refere-se) ao caso de uso incluído, mas o caso de uso incluído não deve "conhecer" o caso de uso básico. É por isso que os casos de uso incluídos podem ser: a) casos de uso básico por direito próprio e b) partilhados por uma série de casos de uso básico.

estender

O caso de uso estendido depende do caso de uso básico; ele literalmente estende o comportamento descrito pelo caso de uso básico. O caso de uso básico deve ser um caso de uso totalmente funcional por direito próprio ('include's incluídos, é claro) sem a funcionalidade adicional do caso de uso estendido.

Casos de utilização extensiva podem ser utilizados em várias situações:

1. O caso de uso básico representa a funcionalidade "must have" de um projeto enquanto o caso de uso estendido representa um comportamento opcional (should/could/want). Aqui é onde o termo opcional é relevante - opcional se construir/entregar em vez de opcional se às vezes é executado como parte da seqüência de caso de uso básico.
2. Na fase 1, você pode fornecer o caso de uso básico que atende aos requisitos naquele ponto, e a fase 2 adicionará a funcionalidade adicional descrita pelo caso de uso estendido. Isso pode conter seqüências que são sempre ou às vezes executadas após a fase 2 ser entregue (mais uma vez, ao contrário do conceito errado popular).
3. Ele pode ser usado para extrair subseqüências do caso de uso básico, 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' comportamento em vários lugares no fluxo do caso de uso básico, e não apenas em um único lugar como um caso de uso incluído faz. Por esta razão, é altamente improvável que um estojo de extensão de uso seja adequado para estender mais de um estojo de uso básico.

Quanto à dependência, o caso de extensão de uso depende do caso de uso básico e é novamente uma dependência unidirecional, ou seja, o caso de uso básico não precisa de nenhuma referência ao caso de extensão de uso na seqüência. Isso não significa que você não possa demonstrar os pontos de extensão ou adicionar um x-ref ao caso de extensão de uso em outro lugar no modelo, mas o caso de uso básico deve ser capaz de funcionar sem o caso de extensão de uso.

SUMÁRIO

Espero ter mostrado que o equívoco comum de "incluir é sempre, às vezes se estende é" é errado ou, na melhor das hipóteses, simplista. Esta versão realmente faz mais sentido se você considerar todas as questões sobre a direcionalidade das setas que a concepção errada apresenta - no modelo correto é apenas dependência e não muda potencialmente se você refatorar o conteúdo do caso de uso.

sempre que houver pré-requisitos para uma usecase, então, vá para incluir.

para casos de usecas com autenticação, na pior das hipóteses, ou são opcionais, então vão para prorrogação...

exemplo:para um caso de uso de procura de admissão,marcação,reserva de bilhetes VOCÊ DEVE PREENCHER UM formulário (formulário de inscrição ou de feedback).... é aqui que vem o formulário...

exemplo:para um caso de uso verificando login ou login na sua conta,a sua autenticação é um must.well.think of worst case scenarios.like return book with fine..NOT getting a reservation..paying the bill AFTER DUE DATE..this is where extend comes to play...

não incluir e ampliar o uso excessivo nos diagramas.

NÃO DIGAS ASNEIRAS!!!