Professor Mário Dantas

Post on 20-Jan-2016

35 views 0 download

description

Análise Orientada a Objetos. Set/2010. Professor Mário Dantas. Aula 04 - Agenda. Ator Caso de uso Associações Entre atores e casos de uso Entre casos de uso Inclusão: estereótipo Extensão: estereótipo > Generalização Diagrama de casos de uso - PowerPoint PPT Presentation

Transcript of Professor Mário Dantas

Professor Mário Dantas

ANÁLISE ORIENTADA A OBJETOSANÁLISE ORIENTADA A OBJETOSSet/2010

2

Aula 04 - Agenda

Ator Caso de uso Associações Entre atores e casos de uso Entre casos de uso

Inclusão: estereótipo <<include>> Extensão: estereótipo <<extend>> Generalização

Diagrama de casos de uso Especificação de casos de uso

3

Ator

É qualquer entidade que interage com o sistema

Pode ser um usuário, um hardware externo, outro sistema

Representa uma classe de usuários (papel), não um usuário específico

Algo sobre o que o sistema não tem controle

4

Ator

Várias pessoas podem ser representas por um único ator.

5

Ator

Um pessoa pode atuar como mais de um ator.

6

Como nomear um ator

Agrupe os indivíduos segundo a utilização do sistema

Identifique os papéis que eles assumem ao utilizar o sistema: cada papel é um ator em potencial

Cargo nem sempre é um papel Escolha nomes conhecidos dos usuários:

não invente!

7

Como nomear um ator

8

Caso de Uso

“Um Caso de Uso é a relação de uma seqüência de ações que um sistema executa produzindo um resultado de valor observável para um ator específico.”

Rational Unified Process – RUP

9

Caso de Uso

Modela um diálogo entre ator e sistema Define o comportamento de um sistema

ou de parte dele Descreve passo a passo como o sistema

desempenha suas funções Possui cenários (instâncias) Define respostas que o sistema deve

gerar para cada evento previsto Deve possuir uma especificação

10

Caso de Uso

11

Descrição

Apresenta uma breve descrição do objetivo do caso de uso.

12

Pré-condição

É o estado do sistema requerido antes do caso de uso ser iniciado

Deve ser um estado de valor mensurável; A pré-condição é uma restrição para o

início do caso de uso e não o evento que inicia o caso de uso (um evento ter ocorrido pode ser uma pré-condição).

13

Pós-condição

Uma pós-condição é o estado no qual o sistema deve estar ao término da execução do caso de uso

Deve ser um estado de valor mensurável

14

Cenário

São os caminhos possíveis no diálogo ator-sistema durante a execução do caso de uso: instância de um caso de uso

Fluxo principal (ou básico) Fluxo onde tudo “dá certo”; o mais freqüente

Fluxos alternativos Variações na execução do fluxo básico

Fluxos de exceção Erros que podem ocorrer nos fluxos básico e

alternativo

15

Cenários

16

Fluxo principal

Exemplo:1. O Cliente informa a opção de Saque.2. O Sistema solicita o valor do saque.3. O Cliente informa o valor e confirma a operação.4. O Sistema verifica o valor informado.5. O Sistema verifica o saldo do cliente.6. O Sistema debita o valor sacado do saldo do cliente.7. O Sistema entrega o dinheiro.8. Fim do caso de uso.

17

Fluxo alternativo

Exemplos:

A1. Saldo insuficiente1. No passo 5 do fluxo básico o Sistema verificou que o cliente não possui saldo. 2. O Sistema informa o saldo disponível.3. O caso de uso volta para o passo 8 do fluxo básico.

A2. Valor informado inválido1. No passo 4 do fluxo básico o sistema verificou que o valor informado é inválido.

2. O sistema informa que o valor é inválido.3. O sistema informa as regras para valores válidos.4. O caso de uso volta para o passo 2 do fluxo básico.

18

Um caso de uso não contém Detalhes da interface gráfica com usuário

– GUI (útil apenas para protótipos) Objetivos de performance (requisito não

funcional) Detalhes da arquitetura da aplicação:

módulos, menus, componentes Quaisquer requisitos não funcionais:

eventualmente, podem ser inserido por meio de notas explicativas

19

Um caso de uso não contém

“... O ator clica no botão OK...” “... O sistema exibe um JTable com os...” “... A resposta deverá ser retornada em

menos de 10 segs...” “... O sistema inicia uma conexão com o

servidor de aplicação...” “... O usuário deverá informar os códigos

por meio da caneta ótica ....”

20

Como encontrar casos de uso? Identifique as interações do usuário: concentre-se

nos objetivos do usuário: “Sacar dinheiro...” “Transferir dinheiro entre contas...” “Cadastrar contas de débito automático...”

Descreva o quê o usuário espera do sistema Descreva as operações que criam, lêem, atualizam e

excluem informações (manter, CRUD, etc.); Descreva como os atores são notificados sobre

alterações de estado do sistema; Descreva como o ator necessitará informar ao

sistema eventos ocorridos.

21

Como encontrar casos de uso? Crie listas de verificação e validação (V&V):

O sistema fornece o comportamento correto às necessidades do negócio?

Todas as necessidades são resolvidas pelos Casos de Uso que você identificou?

Quais Casos de Uso suportarão as principais funcionalidades do sistema?

Quais informações devem ser modificadas ou criadas no sistema?

Aplicar as Listas de V&V para os casos de uso encontrados

22

Como nomear casos de uso? Use uma frase que especifique o objetivo do ator Técnica “O ator usa o sistema para...” Utilize verbos concretos, “fortes”, ao invés de verbos

genéricos e fracos, exemplos: Verbos fortes: criar, calcular, migrar, receber, arquivar,

registrar e ativar Verbos fracos: fazer, relatar, controlar, gerenciar,

administrar, organizar e processar Seja explícito Use termos específicos:

Termos genéricos: formulário, dado e sistema Termos específicos: propriedade, pagamento e conta

23

Como nomear casos de uso? Boas escolhas

Depositar Dinheiro

Conferir Movimentação Bancária

Transferir Valores entre Contas Correntes

Escolhas ruins Controle de Saque Controle de Saldo Transferência

Bancária Gerir Algo Gestão Disso ou

Daquilo

24

Exemplo

O cliente pode usar o caixa automático para sacar e transferir dinheiro e consultar o saldo

Ator: Cliente

Casos de uso: Sacar Dinheiro Transferir Dinheiro Consultar Saldo

25

Associações: Ator – Caso de Uso

Indicar que o ator participa e se comunica com o sistema, conforme descrito no caso de uso

A seta, quando houver, indica quem inicia a comunicação, não demonstram fluxo e setas duplas não são usadas

26

Associações: Ator – Caso de Uso

Seta do ator para o caso de uso: Ator dispara o caso de uso Ator estimula o sistema Ator principal

27

Associações: Ator – Caso de Uso

Seta do caso de uso para o ator: Sistema solicita ou envia informações Sistema sinaliza que espera uma ação do ator Ator secundário

28

Associações: Ator – Caso de Uso

29

Associação entre Casos de Uso Surgem da fatoração de casos de uso Três tipos:

Inclusão <<include>> Extensão <<extend>> Generalização

Objetivos: Reuso de parte do caso de uso Especialização de comportamento Descrição de procedimentos opcionais

30

Associação entre Casos de Uso

31

Inclusão – include

A execução do caso de uso incluído é obrigatória

O caso de uso base depende do caso de uso incluído

Nem o caso de uso base, nem o incluído, acessam os atributos um do outro (baixo acoplamento)

A inclusão é, na essência, um tipo de encapsulamento

32

Exemplo de Inclusão – include No sistema de Caixa Bancário, os casos de uso

“Sacar”, “Depositar” e “Transferir” precisam indicar que o cliente será identificado no sistema. Este comportamento pode ser fatorado em um caso de uso chamado “Identificar Cliente”, que os três casos de uso incluem.

Da perspectiva dos casos de uso base, não importa qual método é utilizado para a identificação, se senha, cartão, identificação de retina, mas apenas o resultado.

Da perspectiva do caso de uso incluído, não importa qual caso de uso o está utilizando (incluindo) ou como o resultado será processado.

33

Exemplo de Inclusão – include

34

Execução de caso de uso include

O comportamento incluído é inserido em uma localização específica do caso de uso base e é executado quando este passo é atingido.

35

Extensão - extend

Indica que uma parte do caso de uso é um comportamento opcional do sistema

Para mostrar que um comportamento é executado somente sob certas condições

Para mostrar que podem existir tipos de comportamento que serão inseridos no caso de uso dependendo da interação do ator com o caso de uso

36

Extensão - extend

O caso de uso de extensão é inserido no caso de uso base em locais específicos chamados “Pontos de extensão”

O caso de uso extensor depende do caso de uso estendido.

37

Exemplo Caso de Uso extend

No sistema de Caixa Bancário, quando o cliente for identificado, o sistema precisa saber se ele já adquiriu seguro contra roubo de cartão e, caso negativo, oferecer a aquisição do seguro. Podemos demonstrar isso com a criação de um caso de uso chamado “Adquirir Seguro” que estende a funcionalidade de “Identificar Cliente”.

38

Exemplo Caso de Uso extend

39

Execução de Caso de Uso extend

Quando a execução do caso de uso atinge o ponto de extensão, a condição do caso de uso é avaliada, e se for verdadeira o caso de uso é executado.

40

Fluxo alternativo ou extend? Freqüentemente nos deparamos com a

dúvida entre um fluxo alternativo e um caso de uso estendido. Considerar o seguinte: O fluxo alternativo é complexo ao ponto de

confundir o entendimento do caso de uso? A condição para execução do fluxo é muito

excepcional? O valor semântico do modelo com extensão

fica aprimorado?

41

Generalização

Destacar o comportamento comum a mais de um caso de uso, mas com algumas particularidades adicionais

Demonstrar formas mais específicas de comportamento do um caso de uso

Relacionamento do tipo é-um entre um caso de uso base (pai) com um ou mais casos de uso filhos

42

Generalização

Semelhante a herança entre classes O filho herda toda a estrutura,

comportamento e relacionamentos do pai;

O filho é totalmente dependente da estrutura do pai.

43

Exemplo de Generalização

No caso de uso “Cobrança de Pênalti”, podem ser representados: (1) a cobrança de pênalti em tempo regulamentar e (2) a cobrança de pênalti como desempate.

Esses dois casos de uso têm muito do seu comportamento em comum, mas com uma particularidade: a reposição da bola, que deve ser posta em jogo (1) ou não (2).

44

Exemplo de Generalização

Exemplo de Generalização

46

Exemplo de Generalização

47

Exemplo de Generalização

O caso de uso “pai” é executado quando, no fluxo do caso de uso “filho”, existe generalização

O caso de uso “filho” é executado quando, no fluxo do caso de uso “pai”, existe especialização

48

Diagrama de Casos de Uso

É criado para representar o conjunto de associações entre atores e casos de uso e entre casos de uso

São casos de uso associados que descrevem todas as formas de uso do sistema

Fornece uma visão das funcionalidades de um sistema: ajuda a capturar os requisitos funcionais

Constitui uma forma de comunicação bastante útil entre projetistas e clientes

Ajuda na identificação de objetos, na execução de testes e na documentação

49

Diagrama de Casos de Uso

Indica que tipo de usuário (ator, perfil) usa quais funcionalidades: o quê o sistema deve fazer e para quem

Deve ser completo: todas as funcionalidades devem estar presentes, mesmo que em diagramas separados que compõem o sistema

É uma visão de alto nível: perspectiva externa e dos atores

O mais informal dos diagramas da UML

50

Diagrama de Casos de Uso

Trata-se de uma representação dinâmica: é importante para a organização e modelagem de comportamentos do sistema

Não há decomposições funcionais (explosões)

Devem ter a complexidade controlada, podendo ser organizados de acordo com sua relevância, freqüência de utilização e valor para os usuários

51

Exemplos: Operação de Cursos

52

Exemplo: Agência Bancária

53

Especificação de Caso de Uso Os casos de uso, mesmo no contexto de seus

diagramas, são semanticamente limitados, dependendo de interpretação

A especificação (documentação) é essencial para uma compreensão precisa

Diagramas da UML, como o de atividades e o de seqüência, mais formais e precisos, podem ser usados na documentação

O padrão de especificação, incluindo nível de detalhe exigido e informações obrigatórias, deve estar definido na metodologia

54

Modelo de Especificação

Descrição Requisitos Atores Pré-condições Evento que inicia Fluxo Principal Fluxos Alternativos Extensões Pós-condições Regras de negócio

55

Exemplo: Manter empregados RF1 – O sistema deve permitir a

manutenção dos dados dos empregados, pelo gerente, conforme regras de negócio RN1 a RN6

56

Exemplo: Manter empregados RN1 – Um empregado deve possuir

obrigatoriamente os dados: código, nome, idade, data de admissão e estar associado a um cargo

RN2 – O código é o identificador do empregado na empresa e deve ser exclusivo

RN3 – O nome do empregado deve ser um nome válido de acordo com a legislação de registro de nascimentos

57

Exemplo: Manter empregados RN4 – A idade deve ser um número inteiro

maior ou igual a 16 e menor que 150 RN5 – A data de admissão deve ser uma

data válida, no formato dia, mês e ano e não pode ser posterior à data corrente, nem anterior à data corrente menos trinta dias

RN6 – O cargo do cliente deve ser selecionado entre os cargos cadastrados no sistema

58

Exemplo: Manter empregados Descrição: Permite consultar, incluir,

alterar dados e excluir fisicamente empregados na base de dados do sistema

Requisitos: RF1 Atores: Gerente Pré-condições: O ator deve estar

identificado pelo sistema e ser um gerente Evento que inicia: Solicitação do ator Extensões e inclusões: não há

59

Exemplo: Manter empregados Pós-condições: A operação solicitada

pelo ator é concluída com dados atualizados ou consultados, condicionado ao atendimento das regras de negócio

Regras de Negócio: RN1 a RN6

60

Exemplo: Manter empregadosFluxos Alternativos: [A1] O ator escolhe um empregado para

consulta detalhada 1. O sistema pesquisa e exibe todos o

dados do empregado selecionado 2. O ator solicita retorno à relação de

empregados 3. O sistema retorna ao passo 1 do fluxo

principal

61

Exemplo: Manter empregados [A2] O ator escolhe um empregado para

edição 1. O sistema pesquisa e exibe todos os dados

do empregado selecionado, oferecendo as opções de edição dos dados exceto o código identificador

2. O ator edita os dados e solicita gravação [A5]

3. O sistema valida e grava os dados [A6] 4. O sistema retorna ao passo 1 do fluxo

principal

62

Exemplo: Manter empregados [A3] O ator escolhe um empregado para

exclusão 1. O sistema solicita confirmação 2. O ator confirma a exclusão [A7] 3. O sistema exclui o empregado e retorna

ao passo 1 do fluxo principal

63

Exemplo: Manter empregados [A4] O ator escolhe a inclusão de um

novo empregado 1. O sistema solicita os dados do

empregado 2. O ator informa os dados e solicita

gravação [A5] 3. O sistema valida e grava os dados [A6] 4. O sistema retorna ao passo 1 do fluxo

principal

64

Exemplo: Manter empregados [A5] O ator solicita cancelamento da

operação 1. O sistema retorna ao passo 1 do fluxo

principal

65

Exemplo: Manter empregados [A6] Dados inválidos, conforme RN

usadas no caso de uso 1. O sistema informa quais dados estão

inválidos e porque 2. O sistema retorna à inclusão ou edição

com os dados informados pelo usuário, mesmo que inválidos

66

Exemplo: Manter empregados [A7] O ator não confirma a exclusão dos

dados 1. O sistema retorna ao passo 1 do fluxo

principal