• Nenhum resultado encontrado

5-ModelagemCasoUso

N/A
N/A
Protected

Academic year: 2021

Share "5-ModelagemCasoUso"

Copied!
38
0
0

Texto

(1)
(2)

Objetivo

História

Atores

Casos de Uso

Diagramas

Estruturação (Generalização, Inclusão,

Extensão)

(3)

História

Descrições textuais da funcionalidade do

sistema a partir da perspectiva do usuário

Usados para mostrar a funcionalidade que

o sistema oferecerá e quais usuários de

alguma forma se comunicarão com o

sistema quando prover essa

funcionalidade

Desenvolvido por I. Jacobson

Parte de UML

(4)

Diagramas de Caso de Uso

 Servem para facilitar o entendimento de um

sistema mostrando a sua “visão externa”

 São usados para modelar o contexto de um

sistema, subsistema ou classe

 São uma das maneiras mais comuns de

documentar os requisitos do sistema  Delimitam o Sistema

(5)

Atores

O sistema será descrito através de

vários

Casos de Uso

que são

executados por um número de

atores

Atores constituem as entidades do

ambiente do sistema

São pessoas ou outros subsistemas que

interagem com o sistema em

desenvolvimento

(6)

Atores

Accountant Campaign

Manager

Staff Contact

Um ator é alguém ou algum outro

sistema que deve interagir com o

sistema em desenvolvimento

(7)

Atores: Especialização

 É possível definir tipos gerais de atores e

especializá-los usando o relacionamento de especialização

(8)

Atores

Atores são externos ao sistema

Primeiro é preciso identificar os

usuários do sistema, que serão

chamados de

atores

.

Um ator é um tipo ou categoria de

(9)

Encontrando Atores

 Podem ser identificados pelas seguintes questões:

 Quem usará a funcionalidade principal do sistema

(atores primários)?

 Quem precisará do auxílio do sistema para fazer suas

tarefas diárias?

 Quem precisará manter, administrar, conservar o

sistema funcionando (atores secundários)?

 Que dispositivos de hardware o sistema precisa para

(10)

Encontrando Atores

 Com que outros sistemas o sistema precisa interagir?  Quem ou o que tem interesse nos resultados que o

sistema produz?

 Dicas

 Não considere apenas os usuários que usam o sistema

diretamente, mas todos os outros que precisam dos serviços do sistema

(11)

Casos de Uso

Atores são examinados para determinar as

suas necessidades

 Gerente de Campanha -- adiciona um novo cliente  Funcionário de Contato -- Altera um contato do

cliente

Contador -- Registra o pagamento do cliente

Record client payment Add new client Change a client contact

(12)

Definição: Caso de Uso

Uma unidade coerente de

funcionalidade provida por uma

classificador (um sistema, subsistema

ou classe) manifestado por uma

sequência de mensagens trocadas entre

o sistema e um ou mais usuários

externos (representados como atores),

junto com as ações executadas pelo

(13)

Descrição de Casos de Uso

 Pode ser numa forma resumida ou numa forma

mais detalhada na qual a interação entre o ator e o caso de uso é descrita passo a passo.

 Descreve interações assim como o usuário vê, e

não é uma definição de processos internos do sistema ou algum tipo de especificação de

(14)

Caso de Uso detalhado

 Um documento com o fluxo de eventos é criado para cada

caso de uso

 Escrito sob o ponto de vista de um ator

 Detalha o que o sistema deve oferecer para o ator quando

o Caso de Uso é executado

 Conteúdo típico

 Como o caso de uso começa e termina  Fluxo normal de eventos

 Fluxo alternativo de eventos  Fluxo excepcional de eventos

(15)

Diagramas de Use Case

Uma associação entre um

ator

e um

use case

indica que há uma

comunicação, possivelmente com envio

e recepção de mensagens

(16)

Diagrama de Caso de Uso

 Diagramas de Caso de Uso são criados para

visualizar as relações entre os atores e os Casos de Uso

Campaign Mnager

Altera um contato do cliente

Adiciona um novo cliente

Registra o pagamento do cliente Staff

(17)
(18)

Estudo de Caso: Agate

(19)

Encontrando Casos de Uso

 Faça as seguintes perguntas para cada ator

 Que funções o ator requer do sistema? O que o ator precisa fazer?  O ator precisa ler, criar, destruir, modificar, ou armazenar alguns

tipos de informações no sistema?

 O ator tem que ser notificado sobre eventos no sistema? Ou o ator

precisa notificar o sistema sobre alguma coisa? O que estes eventos representam em termos de funcionalidade?

 O trabalho diário do ator poderia ser simplificado ou feito com mais

(20)

Encontrando Casos de Uso

 Sem considerar os atores atuais

 Quais entradas/saídas o sistema precisa ? De onde as entradas vêm

e para onde as saídas vão?

 Quais são os maiores problemas com a implementação atual do

(21)

Organizando Caso de Uso

Generalização

Inclusão

(22)

Caso de Uso: Generalização

Relaciona um Use Case especializado a

um mais geral

O filho herda os atributos, operações e

sequências de comportamento dos pais

O filho pode adicionar e redefinir o

comportamento do pai

O filho pode substituir o pai em

(23)

Caso de Uso: Generalização

 O use case filho pode adicionar

comportamento incremental através da

inserção de sequências adicionais de ações em pontos arbitrários da sequência do pai

 Pode modificar alguma das operações e

sequências herdadas (cuidado!!)

 Relacionamentos de inclusão e extensão do

use case filho também modificam o use case do pai

(24)

Caso de Uso: Generalização

 É possível abstrair comportamentos de use

cases. Nomalmente a similaridade entre use cases é identificada após a construção do use case.

 Os use cases

Checar password

e

Scan de

retina

ambos servem para validar o usuário.

 Identificar um use case abstrato

Validar

(25)

Caso de Uso: Generalização

(26)

Caso de Uso: Inclusão

 O use case base incorpora explicitamente o

comportamento de outro use case no local especificado na base.

 O use case incluído nunca estará sozinho,

somente será instanciado de um use case base que o incluirá.

 Usado para evitar a descrição do mesmo

(27)

Caso de Uso: Inclusão

Validar Conta use case incluído (servidor)

<<inclue>>

Sessão de ATM use case base (cliente)

Identificar Cliente

(28)

Use Case: Sessão de ATM mostre anúncio do dia

inclue Identificar Cliente inclue Validar Conta

imprimir cabeçalho do recibo log out

Use Case de Inclusão: Identificar Cliente pegue o nome do cliente

inclue Verificar Identidade

if falha de verificação then abort a sessão

obtenha número da conta do cliente Use Case de Inclusão: Validar Conta

(29)

Caso de Uso: Inclusão

 Descreve uma sequência adicional de

comportamento que será inserida na instância de use case que está executando o use base base

 O mesmo use case de inclusão pode ser inserido

em múltiplos use case base

 A inclusão representa comportamento

encapsulado que potencialmente poderá ser reusado em outros use case base

(30)

Caso de Uso: Extensão

Usado para:

 Para modelar partes opcionais de use

cases

 Para modelar cursos alternativos e

complexos que raramente ocorrem, como

Entrega Urgente

 Para modelar sub-cursos que são

(31)

Extensão: Pontos de Extensão

<<estende>> (ajuste prioridade) Fazer Pedido Pontos de extensão ajuste prioridade

Fazer Pedido Urgente

Use Case Fazer Pedido

Fluxo principal de eventos: inclue (Validar usuário).

<<inclue>>

Validar usuário

(32)

Caso de Uso: Inclusão e

Extensão

<<extend>> Check Campaign Budget Print Campaign Summary <<include>> Find Campaign

(33)

Caso de Uso: Extensão

Avançado

 Cada ponto de extensão precisa ser definido

no use case base.

 Quando a execução da instância do use case

alcança o local do use case referenciado pelo ponto de extensão e a condição da extensão é satisfeita, a execução é

transferida para a sequência do segmento de extensão. Quanto terminada, o controle volta para o use case original

(34)

Dicas: Modelando o Contexto

do Sistema

 Identifique os atores que cercam o sistema

 Quais grupos precisam de ajuda do sistema para

executarem suas tarefas

 Quais os grupos necessários para executarem as

funções do sistema

 Quais grupos interagem com hardware externo

ou outros sistemas de software

 Quais grupos executam funções secundárias de

(35)

Dicas: Modelando o Contexto

do Sistema

 Organize os atores que são similares em uma

hierarquia de generalização / especialização.

 Quando ajudar a compreensão, faça um

estereótipo para o ator

 Use os atores no diagrama de use cases e

especifique os caminhos de comunicação entre atores e use cases do sistema.

(36)

Dicas: Modelando Requisitos

do Sistema

 Estabeleça o contexto do sistema através da

identificação dos atores que o cercam

 Para cada ator, considere o comportamento

que eles esperam ou requerem que o sistema produza

 De um nome aos comportamentos comuns

(Caso de Uso)

 Fatore comportamentos comuns em novos

(37)

Dicas: Modelando Requisitos

do Sistema

 Fatore comportamento variante em novos

use cases que estendem a fluxo principal de eventos

 Modele os use cases, atores e seus

relacionamentos através de diagramas de use case

 Adorne os use cases com notas que

descrevem requisitos não funcionais (algumas destes se aplicam ao sistema como um todo).

(38)

Leituras Adicionais

 [Easterbrook94] Easterbrook, S., Resolving Requirements

Conflicts”, in [Jirotka94].

 [Macaulay96] Macaulay, L. Requirements Engineering, Springer.  [Kotonya98] Kotonya, G. et all. Requirements Engineering:

Processes and Tecniques, John Wiley & Sons.

 [Booch99] Booch, G. et all. The Unified Modeling Language

User Guide. Chapters 2, 16, 17. Addison-Wesley

 [Schneider98] Schneider, G. et all. Applying Use Cases,

Addison-Wesley.

 [Jacobson92] Jacobson, I. et all. Object-Oriented Software

Referências

Documentos relacionados

Verifica-se que para doses de inoculante utilizadas não apresentaram efeito significativo para altura de planta, massa fresca da parte aérea e número de folhas..

Uso de ovitrampas como instrumento para o monitoramento populacional de Aedes aegypti Linnaeus Diptera: Culicidae em áreas de Olinda, Pernambuco, Brasil MARIA ALICE V..

A etapa 1, de revisão, busca o reconhecimento de elementos e estruturas já estabelecidas; a etapa 2, promove a seleção de obras de arquitetura que permitam

A produção dos materiais está dirigida especificamente para disciplinas de projeto e para disciplinas de representação gráfica, que se reestruturam na perspectiva

1 Estruturar o perfil das organizações convencionais através de critérios e indicadores bem definidos, listando aqueles que as caracterizam; 2 Avaliar como as organizações

Estas deficiências refletem nos itens do desempenho: (8) conforto visual, (11) higiene, (13) durabilidade e (14) economia. Foto 5.8.4 – Aspecto visual deficiente das paredes

– Questões mais simples: índice ainda menor (raciocínio lógico).. Antes de começar: Enem 2017