Mestrado em Informática IM/NCE - msoo.pbworks.commsoo.pbworks.com/f/Diagrama+de+Casos+de+Uso.pdf · Mestrado em Informática - IM/NCE Disciplina: MSOO 2008.2 Modelagem de Casos de

Mestrado em Informática

IM/NCEDisciplina: MSOO – 2009.2

Assunto: Casos de Uso e Diagrama de Casos de Uso

Professor: Raimundo Xavier

Mestrado em Informática - IM/NCE

Disciplina: MSOO 2008.2

Modelagem de Casos de Uso Casos de Uso

mecanismo de levantamento de requisitos descrevem o comportamento do sistema

Diagramas de Casos de Uso suportados por ferramentas que seguem a

especificação UML Descrição de Casos de Uso

representação desvinculada do modelo UML



Simplicidade x Conteúdo

“Os casos de uso são uma forma elegante de comunicar as necessidades de um negócio

ou sistema.”

Ivar Jacobson



Casos de Uso Descreve um conjunto de atividades de um sistema sob o ponto

de vista de seus atores.

Um modelo de descrição de requisitos para um sistema.

Usados informalmente, o Usuário tem que ser capaz de compreender.

Elemento primário no desenvolvimento e no planejamento do projeto.

Contam a estória de como atingir uma meta



Casos de Uso II Caso de uso é um conjunto de cenários

amarrados por um objetivo comum de um usuário.

Cenário é uma seqüência de passos que descreve uma iteração entre um usuário e um sistema.



Caso de Uso X User Story Propósito: Requisito x Narrativa Conteúdo: Consistente x Inconsistente Cenário: Coleção x Único Estruturação: Semi-formal x Informal



Processo Guiado por Casos de Uso Obter e validar um entendimento do problema

Capturar e validar um entendimento da solução proposta.

Identificar objetos candidatos para o modelo de domínio.



Requisitos da especificação através de Casos de Uso Convenções usuais para descrições de caso de uso

devem poder ser validadas com o usuário; devem servir como “contrato” entre o desenvolvimento e o

usuário devem servir aos demais envolvidos no processo de

construção do sistema forma narrativa é livre de uma representação estruturada

ou formal Jacobson, Cockburn, Fowler, Firesmith, Ambler, Armour &

Miller Choque entre requisitos: simplicidade X conteúdo



Fluxo principal e seqüência alternativa

Sistema

2. Valida o usuário e a senha.3. Realiza o login do usuário.

Alternativa ao passo 2: O usuário e senha estão inválidos. Informa o usuário sobre o erro e requisita novamente as informações de login.

Ator1. Preenche o usuário e a senha.



Diagramas de Casos de Uso Para comunicar a idéia entre usuários e

desenvolvedores Estereótipos:

Atores Caso de Uso Relacionamentos entre casos e atores



Diagrama de Caso de Uso



Atores Um ator é um papel que um usuário

desempenha em relação ao sistema.

É importante pensar nos papéis em vez de pensar nas pessoas ou em cargos.

O ator também pode ser um sistema externo que necessita de alguma informação do sistema atual.



Modelando o relacionamenteo entre Casos de Uso Existem duas situacoes onde voce deveria

considerar a adicao de detalhes ao diagrama de Casos de Uso: Para identificar tarefas comuns (e seus cenarios

associados) compartilhadas por um ou mais Casos de Uso;

Para agregar alternativas a um cenario principal.



Casos de Uso do Negócio e do Sistema Um caso de uso de sistema é uma iteração com um

software externo, eventos ou threads secundárias

Um caso de uso de negócio examina como a aplicação responde ao cliente ou a um evento externo.

O caso de uso pode ser representado com pontos de extensão. Indicam passos que são sujeitos a seguir cenários alternativos.



Associação entre Casos de Uso Inclusão: quando estiver repetindo em dois ou mais

casos de uso separados e deseja evitar a repetição.

Generalização: quando estiver descrevendo uma variação em comportamento normal e deseja descrevê-la sem muito rigor.

Extensão: quando estiver descrevendo uma variação em comportamento normal e deseja utilizar a forma mais controlada, explicando os pontos de extensão no caso de uso-base.



Stereotypes Na UML, representam formas de adicionar

detalhes a qualquer parte (elemento) do modelo.

Um forma de expressar variacao ou uso distinto que agrega mais informacoes sobre o elemento original.

Ex: <<include>> <<extend>>



Inclusão de Casos de Uso





Extensão de casos de uso





Mecanismo de TransformaçãoDescrições de Casos de Uso Estruturadas

Descrições Narrativas Simples

Descrições Narrativas Detalhadas

Cenários de Testes

Artefatos específicos da organização



Atividades de Expansão Descrever o fluxo principal Descrever fluxos alternativos



Abordagens de Caso de Uso Essencial Real



Abordagens Essenciais Apenas a “essência” das operações é

apresentada, em oposição à sua realização concreta



Sistema Atual × Sistema Futuro × Descrição Essencial Sistema Atual: “o funcionário procura a ficha

do cliente no fichário”

Sistema Futuro: “o funcionário clica no botão “procurar” digitando o código do cliente no campo X3”

Descrição Essencial: “o funcionário localiza as informações sobre o cliente”.



Casos de Uso na Análise e Projeto Na análise o objetivo é estudar o sistema

para descobrir as necessidades do cliente ∴ Casos de Uso Essenciais.

No projeto o objetivo é produzir uma solução implementada de um sistema informatizado para uso pelo cliente ∴ Casos de Uso Reais.



Níveis de Detalhamento Alto Nível Expandido



Exemplo de Caso de Uso de Alto Nível

Caso de uso: Emprestar Fitas Um cliente solicita a locação de algumas fitas. Após identificar-se e identificar as fitas ele pode levá-las para casa, ciente do prazo de devolução e do valor a ser pago.



Exemplo de Caso de Uso Expandido



Passos em um Fluxo Obrigatórios Complementares Não Recomendados



Passos Obrigatórios Indicam as entradas e saídas de informação

do sistema necessárias para realizar o caso de uso.

Na falta de qualquer um desses passos o caso de uso pode ficar sem sentido.



Exemplo de caso de uso onde falta uma entrada de informação

Caso de Uso (mal construído): Reservar um Filme 1. O cliente entra em contato com o funcionário da videolocadora (possivelmente por telefone). 2. O cliente informa seu nome. 3. O cliente solicita uma reserva.

4. O funcionário confirma a reserva.



Um diálogo impossível baseado no caso de uso anterior

Cliente: Boa tarde! Funcionário: Boa tarde! Em que posso servi-lo? Cliente: Meu nome é João e eu gostaria de reservar um filme. Funcionário: Pois não, Senhor. Acabo de efetuar a reserva.

Cliente: Grato!



Uma solução mais adequada

Caso de Uso: Reservar um Filme 1. O cliente entra em contato com o funcionário da videolocadora (possivelmente por telefone). 2. O cliente informa seu nome. 3. O cliente solicita uma reserva informando o nome do filme. 4. O funcionário confirma a reserva, informando o prazo de validade.



Tipos de passos obrigatórios Eventos de sistema – entradas. Respostas de sistema – saídas.

Obs. Não são respostas de sistema retornos do tipo “ok”. Deve ser enviada ao mundo externo algum tipo de informação que o sistema armazena.



Identificação de passos obrigatórios em um Caso de Uso

Caso de Uso: Reservar um Filme 1. O cliente entra em contato com o funcionário da videolocadora (possivelmente por telefone). 2. [EV] O cliente informa seu nome. 3. [EV] O cliente solicita uma reserva informando o nome do filme.

4. [RS] O funcionário confirma a reserva, informando o prazo de validade.



Passos Complementares Não possuem uma entrada ou saída do

sistema, mas ajudam a compreender o contexto.

Estes passos têm pouca ou nenhuma influência na complexidade do software a ser desenvolvido.



Exemplos de passos complementares “o cliente chega ao balcão com as fitas que

deseja locar” “o cliente vai embora com as fitas” “o funcionário pergunta o nome do cliente” “o sistema informa que a reserva foi

concluída com sucesso”



Passos Não Recomendados São os processos internos ao sistema . O caso de uso deve descrever a interação

entre o sistema e os atores externos, não o processamento interno.



Exemplos de passos que não deveriam constar em um Caso de Uso

“o sistema registra o nome do cliente no banco de dados”

“o sistema calcula a média das vendas”



Um exemplo de caso de uso com passos não recomendados

Caso de Uso (mal construído): Emprestar Fitas 1. O cliente chega ao balcão com as fitas que deseja emprestar. 2. O cliente informa seu nome. 3. O funcionário registra o nome do cliente. 4. O sistema verifica se o cliente tem cadastro e se o cliente não está suspenso por não pagamento de empréstimos anteriores. 5. O funcionário registra cada uma das fitas. 6. O sistema verifica no banco de dados o registro das fitas e marca cada uma como “emprestada”. Posteriormente o sistema adiciona cada fita ao empréstimo corrente e soma o valor das fitas no total do empréstimo. 7. O funcionário encerra o empréstimo. 8. O cliente vai embora com as fitas.



Tratamento de Exceções no Caso de Uso Depois de descrever o fluxo principal do caso de

uso, deve-se imaginar o que poderia dar errado em cada um dos passos descritos

Uma exceção é um evento que se não for devidamente tratado impede o prosseguimento do caso de uso

A exceção em um processo não é necessariamente algo que impede que o processo seja iniciado, mas normalmente algo que impede que ele seja concluído



Partes de um tratamento de exceção Identificador – número da linha no Fluxo

Principal (FP) e código da exceção Descrição da exceção – uma frase Ações corretivas – um fluxo alternativo Finalização – se e como retorna-se ao FP



Formas de Finalizar um Fluxo Alternativo Voltar ao início do passo que causou a

exceção Ir para algum passo posterior Voltar ao início do caso de uso Abortar o caso de uso



Forma a ser evitada no Fluxo Principal Se o cliente possui cadastro então o

funcionário registra...



Abortar o Caso de Uso Quando não for possível ou desejável

realizar um passo, o caso de uso é abortado.

Não é necessário indicar isso como exceção, pois idealmente pode ocorrer a qualquer momento e em qualquer passo.



Variantes Não são exceções, mas sub-conjuntos de

cenários distintos dentro de um caso de uso



Fluxo Principal

1. O cliente entrega as fitas que deseja devolver.

2. O funcionário identifica cada uma das fitas.

3. O funcionário indica que não há mais fitas para devolver.

4. O sistema informa o valor total a ser pago.

5. O cliente realiza o pagamento:

- Dinheiro: Ver variante 5.1.

- Cheque: Ver variante 5.2.

- Cartão: Ver variante 5.3.

6. O funcionário conclui a devolução.

Variantes

5.1: Dinheiro:

5.1.1. O cliente entrega a quantia em dinheiro.

5.1.2. O funcionário registra a quantia.

5.1.3. O sistema informa o troco.

5.1.4. O funcionário entrega o troco ao cliente.

5.2: Cheque:

5.2.1. O cliente entrega o cheque.

5.2.2. O funcionário solicita a presença do gerente.

5.2.3. O gerente dá o visto no cheque.

5.3: Cartão:

5.3.1. O cliente entrega o cartão de crédito.

5.3.2. O funcionário envia a informação sobre o cartão ao serviço de autorização, bem como o valor da compra e a identificação da loja.

5.3.3. O Serviço de autorização envia o código de autorização.

5.3.4. O cliente confirma a autorização (possivelmente com a assinatura).

Caso de Uso: Devolver Fitas



Fluxos Alternativos de Outros Casos de Uso Caso de Uso: Vender Fitas

1. O cliente se identifica. 2. O cliente entrega as fitas que deseja comprar. 3. O funcionário identifica as fitas para compra. 4. O sistema informa o valor total. 5. O cliente realiza o pagamento: - Dinheiro: Ver Caso de Uso “Devolver Fitas” variante 5.1 - Cheque: Ver Caso de Uso “Devolver Fitas” variante 5.2 - Cartão: Ver Caso de Uso “Devolver Fitas” variante 5.3 4. O cliente vai embora.



UML 1.1 (descontinuada)



Quando usar variantes? Quando uma mesma seqüência de passos é

repetida em diferentes casos de uso Quando um caso de uso é demasiadamente

complexo, e a divisão dele em variantes ajuda na sua compreensão



Cenários Cada cenário é uma realização particular do

caso de uso



Diferentes cenários devem ter passos obrigatórios distintos Contra-exemplo:

1. O cliente chega no balcão com as fitas. 2. O funcionário solicita o nome do cliente. 3. O cliente informa o seu nome. 4. [EV] O funcionário registra o nome...

1. O cliente chega no balcão com as fitas. 2. O cliente informa o seu nome. 3. [EV] O funcionário registra o nome...

(a) (b)



Consultas no caso de uso Evite:

“o sistema verifica se o usuário está cadastrado” Prefira:

“o funcionário informa a identificação do cliente” “o sistema informa os dados do cadastro do

cliente”



Outras seções de um Caso de Uso Atores Interessados Pré-Condições Pós-Condições de Sucesso Requisitos Correlacionados Variações Tecnológicas Questões em Aberto



Caso de Uso: Emprestar Fitas Atores: Funcionário e Cliente

Interessados: Gerente financeiro, Setor de compras

Pré-condições: As fitas a serem locadas estão devidamente registradas (pode-se garantir que as fitas com código identificador tenham sido previamente registradas no sistema se o código for produzido apenas após o registro).

Pós-condições: O cliente ficou de posse das fitas. O registro da locação das fitas para o cliente foi feito. O cliente foi informado do prazo e valor da locação.

Requisitos Correlacionados: F1 e F2.

Variações tecnológicas: a identificação do cliente poderá ser feita através de um código simples ou um cartão com código de barras. A identificação das fitas também poderá ser feita por um código ou por leitor de código de barras. Outra opção seria um leitor magnético, mas esta opção não está sendo seriamente considerada no momento devido ao custo.

Questões em aberto:

1. Os prazos de locação variam de fita para fita?

2. Existem promoções do tipo leve 4 e pague 3?

Fluxo Principal:

1. O cliente chega ao balcão com as fitas que deseja locar.

2. O cliente informa seu nome e entrega ao funcionário as fitas.

3. [EV] O funcionário registra o nome do cliente e inicia a locação.

4. [EV] O funcionário registra cada uma das fitas.

5. [RS] O funcionário finaliza a locação, devolve as fitas ao cliente e lhe informa a data de devolução e o valor total da locação.

6. O cliente vai embora com as fitas.

Tratamento de exceções:

3a. O cliente não possui cadastro.

3a.1 O cliente deve informar seus dados para cadastro.

3a.2 [EV] O funcionário registra o cadastro.

3a.3 Retorna ao fluxo principal no passo 3.

3b. O cliente possui pendências no cadastro (locação anterior não foi paga).

3b.1 O cliente paga seu débito.

3b.2 [EV] O funcionário registra a quitação do débito, eliminando assim a pendência.

3b.3 Retorna ao passo 3.

4a. Uma fita está reservada para outro cliente.

4a.1 [RS] O funcionário informa que a fita não está disponível para locação.

4a.2 Prossegue a locação do passo 4 sem incluir a fita reservada.

4b. Uma fita está danificada.

4b.1 O funcionário informa que a fita está danificada.

4b.2 [EV] O funcionário registra que a fita está danificada.

4b.2 O funcionário verifica se existe outra fita disponível com o mesmo filme.

4b.3 [EV] Se existir, o funcionário substitui a fita e segue no passo 4, senão segue do passo 4 sem incluir a fita danificada.



Caso de Uso: Emprestar Fitas Atores: Funcionário e Cliente

Interessados: Gerente financeiro, Setor de compras

Pré-condições: As fitas a serem locadas estão devidamente registradas (pode-se garantir que as fitas com código identificador tenham sido previamente registradas no sistema se o código for produzido apenas após o registro).

Pós-condições: O cliente ficou de posse das fitas. O registro da locação das fitas para o cliente foi feito. O cliente foi informado do prazo e valor da locação.

Requisitos Correlacionados: F1 e F2.

Variações tecnológicas: a identificação do cliente poderá ser feita através de um código simples ou um cartão com código de barras. A identificação das fitas também poderá ser feita por um código ou por leitor de código de barras. Outra opção seria um leitor magnético, mas esta opção não está sendo seriamente considerada no momento devido ao custo.

Questões em aberto:

1. Os prazos de locação variam de fita para fita?

2. Existem promoções do tipo leve 4 e pague 3?

Fluxo Principal:

1. O cliente chega ao balcão com as fitas que deseja locar.

2. O cliente informa seu nome e entrega ao funcionário as fitas.

3. [EV] O funcionário registra o nome do cliente e inicia a locação.

4. [EV] O funcionário registra cada uma das fitas.

5. [RS] O funcionário finaliza a locação, devolve as fitas ao cliente e lhe informa a data de devolução e o valor total da locação.

6. O cliente vai embora com as fitas.

Tratamento de exceções:

3a. O cliente não possui cadastro.

3a.1 O cliente deve informar seus dados para cadastro.

3a.2 [EV] O funcionário registra o cadastro.

3a.3 Retorna ao fluxo principal no passo 3.

3b. O cliente possui pendências no cadastro (locação anterior não foi paga).

3b.1 O cliente paga seu débito.

3b.2 [EV] O funcionário registra a quitação do débito, eliminando assim a pendência.

3b.3 Retorna ao passo 3.

4a. Uma fita está reservada para outro cliente.

4a.1 [RS] O funcionário informa que a fita não está disponível para locação.

4a.2 Prossegue a locação do passo 4 sem incluir a fita reservada.

4b. Uma fita está danificada.

4b.1 O funcionário informa que a fita está danificada.

4b.2 [EV] O funcionário registra que a fita está danificada.

4b.2 O funcionário verifica se existe outra fita disponível com o mesmo filme.

4b.3 [EV] Se existir, o funcionário substitui a fita e segue no passo 4, senão segue do passo 4 sem incluir a fita danificada.



Fronteira do Sistema



Na fase de análise, o texto dos casos de uso expandidos terá basicamente duas utilizações:

Como fonte de informação para encontrar conceitos para o modelo conceitual.

Como fonte de informação para encontrar as operações e consultas de sistema, que darão origem aos métodos que fazem a interface do sistema com o mundo externo.



Operações e Consultas de Sistema Operações de sistema são métodos que são

ativados a partir de um evento de sistema, ou seja, como resposta a uma ação de um usuário [EV]

Consultas de sistema são métodos que correspondem à simples verificação de informação já armazenada [RS]



Operações e Consultas de Sistema Pode-se dizer que as operações e consultas

de sistema, em conjunto, correspondem à totalidade das funções possíveis do sistema, ou seja, à funcionalidade efetiva total do sistema.



Operações e Consultas de Sistema O analista deve preocupar-se então em construir

um catálogo com todas as operações e consultas de sistema identificadas nesta fase, seja nos fluxos principais como os fluxos alternativos.

Mais adiante, ainda no processo de análise estas informações serão usadas para definir os contratos de operação de sistema que indicam como o sistema transforma a informação.



Caracterização de termos Evento de sistema: dos atores para a aplicação

Resposta de sistema: do controlador para a aplicação e da aplicação para os atores

Operação de sistema: da aplicação para o controlador (altera a informação – não segue resposta de sistema)

Consulta de sistema: da aplicação para o controlador (não altera a informação – segue resposta de sistema)



Tipos de Operação de Sistema Operações com parâmetros, que usualmente

correspondem a eventos informativos.

Operações sem parâmetros, que usualmente correspondem a eventos de controle.



Problemas com Casos de Uso Foco na interação, pouco entendimento do negócio. Dificuldade da modelagem da interação pelo cliente. Dificuldade de determinar quando está completo. Natureza não OO, descrição procedural. Natureza especulativa de comportamento futuro. Força um projeto raso do comportamento baseado

em ações. Mascara o projeto de lógica de negócio, posando

como repositório único de requisitos. Distorção do modelo de domínio sob a vista de

cada caso de uso.



Descrições de Casos de Uso através de Mecanismos de Extensibilidade

da UML



Descrições de Casos de uso como Diagramas de Atividade Estendidos

Por que Diagramas de Atividade? Boa representação para condições, paralelismo e

sincronização UML 2.1 suporta sub-diagramas para as

atividades (estruturação hierárquica) Facilmente transformáveis em diagramas de

seqüência Podem ser associados a outros modelos



Extensões utilizadas

<<extension point>>Ponto de Extensão

<<inclusion point>>Ponto de Inclusão

<<system>>Evento do Sistema

<<actor>>Evento do Ator

<<use case description>>Descrição do caso de uso

EstereótipoElementos da descrição



Seqüência alternativaFluxo principal



Cadastra Funcionário Cadastra Pessoa

<<include>>



Efetua Compra Pagamento em Dinheiro

<<extend>>

Pagamento em Cheque

<<extend>>



Casos de Colaboração



Vínculo da descrição com o resto do Modelo



Relação com a arquitetura



Relação com o modelo de classes



Navegabilidade e Rastreamento



É possível verificar todos os caminhos possíveis

Verificação de Cenários

Validação do caso de uso



Casos de Uso: Conclusão São uma ferramenta usada na captura de

requisitos e no planejamento e controle de um projeto iterativo. A captura de casos de uso é uma das tarefas básicas na fase de elaboração.

Representam uma visão externa do sistema.

Cobrem apenas uma parte dos requisitos.

Documents

Mestrado em Informática IM/NCE - msoo.pbworks.commsoo.pbworks.com/f/Diagrama+de+Casos+de+Uso.pdf · Mestrado em Informática - IM/NCE Disciplina: MSOO 2008.2 Modelagem de Casos de