2 – Atividade Analisar Caso de Uso

(1)

2 – Atividade

Analisar Caso de Uso

Objetivos deste módulo

• Apresentar os passos necessários para

realizar a atividade analisar casos de uso

e discutir seus artefatos

(2)

Projeto Orientado a Objetos 3

Fluxo de Análise

Objetivos desta atividade

• Transformar os requisitos em um projeto

(inicialmente abstrato) do sistema

– Encontrar as classes iniciais do sistema (classes de análise) e distribuir

comportamento dos casos de uso entre elas – Para cada classe, descrever as

responsabilidades, atributos e associações

(3)

Visão geral dos artefatos

Passos para

Analisar Casos de

Uso

Para cada caso de uso:

1. Encontrar classes de análise 2. Identificar persistência

Para cada classe:

3. Distribuir comportamento entre as classes 4. Descrever responsabilidades

5. Descrever atributos e associações

(4)

Passo 1. Encontrar classes de

análise

• O comportamento do caso de uso é

distribuído em classes de análise dos

seguintes tipos (estereótipos)

– fronteira – controle – entidade

• Estes estereótipos são uma conveniência

de análise que desaparecem no projeto

Classes de análise: um primeiro

passo em direção ao executável

!

"# $ "

(5)

BVF - Diagrama de Casos de Uso

• Usaremos o BVF como exemplo

Manter Livros Manter Revistas Manter Periódicos Reservar Obras Consultar Obras Locatário(a) Fazer Login Usuario Manter Obras Manter Locatário Bibliotecário(a) Impressora Imprimir Comprovante Locar Obras <<include>> Devolver Obras Sistemas Internos

Classes de Fronteira (boundary

classes)

• Isolam o sistema de mudanças no ambiente externo

• Atores devem se comunicar apenas com classes de fronteira

• Exemplos de classes fronteira

– GUI

– Interface com outros sistemas – Interface com dispositivos

<<boundary>>

(6)

BVF – Fazer Login

• Regra geral para encontrar classes de fronteira: uma classe por cada par ator/caso de uso

TelaLogin <<boundary>>

ClienteAtor Fazer Login

BVF – Imprimir Comprovante

• Descobrindo classes de fronteira

Bibliotecario

Imprimir Comprovante

Impressora

ComunicacaoImpressora <<boundary>> TelaImprimirComprovante

(7)

Descrevendo Classes de

Fronteira

• GUI

– Concentre-se nas informações que serão apresentadas, não em um projeto gráfico

• Interface com outros sistemas ou

dispositivos

– Concentre-se em quais protocolos devem ser definidos, não como serão implementados

• Concentre-se nas responsabilidades, não

nos detalhes!

Classes de Entidade (entity

classes)

• Abstrações e conceitos chaves dos casos de uso • Fontes:

– Conhecimento do negócio – Glossário

– Modelo de negócios – Documento de requisitos – Especificação do Caso de uso

<<entity>>

(8)

BVF – Fazer Login

• Observe o fluxo de eventos do Fazer Login

Este caso de uso é responsável por autenticar um locatário do sistema.

Pré-condição: nenhuma

Pós-condição: um locatário válido é logado e sua sessão é registrada no sistema.

Fluxo de eventos principal

1. O locatário informa login e senha.

2. O sistema verifica se o login e a senha são válidos (verifica-se se o login e senha pertencem a uma conta).

3. O sistema registra o início de uma sessão de uso.

Fluxos secundários

- No passo 2, se o login ou a senha forem inválidos, o sistema exibe uma mensagem e volta ao passo 1.

Este caso de uso é responsável por autenticar um locatário do sistema.

Pré-condição: nenhuma

Pós-condição: um locatário válido é logado e sua sessão é

registrada no sistema.

Fluxo de eventos principal 1. O locatário informa login e senha.

2. O sistema verifica se o login e a senha são válidos (verifica-se se o login e senha pertencem a uma conta).

3. O sistema registra o início de uma sessão de uso.

Fluxos secundários

- No passo 2, se o login ou a senha forem inválidos, o sistema exibe uma mensagem e volta ao passo 1.

Orientações para encontrar

Classes de Entidade

• Usando a descrição do caso de uso, use a

abordagem tradicional de filtrar

substantivos

– identifique substantivos no fluxo de eventos – remova candidatos redundantes e vagos – remova atores que apenas interagem com o

sistema mas não fazem parte da modelagem – remova atributos (serão usados mais tarde) e

(9)

• Classes de entidade

• Algumas classes levantadas podem ser eliminadas e novas serão adicionadas

BVF – Fazer Login

Locatário <<entity>>

Classes de Controle (control

classes)

• Coordenam o comportamento (lógica de controle) do caso de uso

• Interface entre fronteira e entidade

• Dependente do caso de uso, independente do ambiente

• Permitem separação entre o uso da entidade (específico do sistema) do comportamento inerente à entidade

<<control>>

(10)

Orientações para encontrar

Classes de Controle

• Usualmente, uma classe de controle por

caso de uso

• Eventualmente mais de uma

(comportamento complexo) ou nenhuma

(manipulação simples de informações

armazenadas)

BVF – Efetuar Login

• Encontrando classes de controle

ControladorLogin <<c ontrol>>

(11)

BVF – Imprimir Comprovante

• Encontrando classes de controle

Bibliotecario

Imprimir Comprovante

Impressora

ControladorImprimirComprovante <<control>>

FBV - Classes

)

O bra Re se rva

<<e n...>>

Loc atário <<entity>> Loc ação

TelaLo gin TelaIm pr im irC om pr ova nte

Co ntrola do rLogin ControladorIm prim irC om provante

(12)

BVF – Reservar Obra

• Observe o fluxo de eventos do caso de

uso Reservar Obra

BVF – Reservar Obra

• Descrição inicial

Este caso de uso é responsável por realizar a reservar da obra para o locatário

Pré-condição: O locatário estar logado no sistema.

Pós-condição: A obra deve estar reservada para o locatário.

Este caso de uso é responsável por realizar a reservar da obra para o locatário

Pré-condição: O locatário estar logado no sistema.

(13)

BVF – Reservar Obra

• Fluxo de eventos principal

1. O locatário escolhe a opção reservar obra 2. O sistema requisita os dados para reserva

3. O locatário informa os dados necessários para reservar uma obra: - número de matrícula.

- dados da obra

4. O sistema verifica se esse locatário pode reservar obras. [FS001 – Locatário não pode fazer reserva] ;

5. O locatário confirma a reserva; [FS002 – Locatário deseja fazer outra reserva]

6. O sistema registra a reserva e retorna um número de reserva para o locatário.

1. O locatário escolhe a opção reservar obra 2. O sistema requisita os dados para reserva

3. O locatário informa os dados necessários para reservar uma obra: - número de matrícula.

- dados da obra

4. O sistema verifica se esse locatário pode reservar obras. [FS001 – Locatário não pode fazer reserva] ;

5. O locatário confirma a reserva; [FS002 – Locatário deseja fazer outra reserva]

6. O sistema registra a reserva e retorna um número de reserva para o locatário.

BVF – Reservar Obra

• Fluxo de eventos secundários

Fluxo secundário

- [FS001 – Locatário não pode fazer reserva]

1. O sistema mostra a mensagem “Este locatário não pode reservar obra, procure a Fucapi para regularizar sua situação!”

- [FS002 – Locatário deseja fazer outra reserva]

1. O locatário escolhe a opção “Reservar outras obras” 2. O sistema armazena a possível primeira reserva 3. O locatário volta para a tela de reservar obras e consequentemente, o passo 1 do fluxo principal.

Fluxo secundário

- [FS001 – Locatário não pode fazer reserva]

1. O sistema mostra a mensagem “Este locatário não pode reservar

obra, procure a Fucapi para regularizar sua situação!”

- [FS002 – Locatário deseja fazer outra reserva]

(14)

Exercício

• Dado:

– Artefatos de requisitos do BFV,

especialmente o fluxo de eventos do caso de uso Reservar Obra

• Produzir:

– Identificação das classes de análise, com seus estereótipos e breve descrição

• Classes de análise

BVF – Reservar Obra

O b ra

R e s e rva <<e ntity>>

L o c a tá rio < <e ntity> >

L oc a ç ão

ControladorReserva <<control>> FormReserva

(15)

Passo 2. Identificar persistência

• Identificar que classes de análise deverão

ser persistentes

• Criar, para cada classe persistente, uma

classe de cadastro com estereótipo

BVF – Fazer Login

*

Locatário <<entity>> CadastroLocatario

<<entity collection>>

Bibliotecario <<entity>> CadastroBibliotecario

(16)

Exercício

• Dado

– Artefatos de requisitos, especialmente a descrição dos requisitos não funcionais – Classes de entidade

• Produzir

– Identificação das classes que deverão ser persistentes

– Criar classes de cadastro

Contexto

• Encontradas as classes de análise e

identificadas as classes persistentes,

vamos agora descrever o seu

comportamento.

(17)

Passo 3. Distribuir

comportamento entre as classes

• Para cada fluxo de eventos

– alocar responsabilidades do caso de uso às classes de análise

– modelar interações entre as classes através dos diagramas de interação

Distribuindo comportamento

entre as classes

(18)

Alocando responsabilidades

• Use estereótipos de análise como guia

– Classes de fronteira

• comportamento que envolve comunicação com um ator

– Classes de entidade

• comportamento que envolve informação encapsulada na abstração

– Classes de controle

• comportamento específico ao caso de uso (lógica de controle do caso de uso)

Alocando responsabilidades

• Identificar que classe tem a informação

necessária para realizar a

responsabilidade

– isso pode envolver apenas uma classe, pode ser preciso criar nova classe ou

(19)

Modelando interações

• Diagramas de interação (colaboração e

seqüência) modelam interações do sistema com seus atores

• A interação é iniciada por um ator e envolve instâncias (objetos) das classes

• Diagramas de interação capturam a semântica do fluxo de eventos do caso de uso

– Auxiliam a identificar classes, responsabilidades e relacionamentos

Forma Geral dos Diagramas

de Seqüência

(20)

BVF – Fazer Login

: Locatário(a) : TelaLogin : ControladorLogin _{CadastroLocatario}: efetuarLogin(login, senha)

efetuarLogin(login, senha)

pesquisarLocatario(login, senha)

registraSessao(login)

:

: Locatario create

BVF – Fazer Login

: Locatário(a) : TelaLogin

: ControladorLogin

: CadastroLocatario 1: efetuarLogin(login, senha)

2: efetuarLogin(login, senha)

3: pesquisarLocatario(login, senha) 5: registraSessao(login)

: Locatario

(21)

Quantos diagramas de

interação fazer?

• Quantos for necessário para modelar o comportamento do caso de uso!

• Pelo menos o fluxo principal deveria ser modelado

• Não é necessário modelar todos os fluxos

– Os fluxos secundários geralmente não acrescentam muito à modelagem do principal

• O importante é exemplificar o uso de todas as responsabilidades

Que diagramas de interação

fazer?

• Diagramas de colaboraçãox_{diagramas de seqüência}

• Colaboração

– Melhores para visualizar os relacionamentos e responsabilidades de um dado objeto

– Mais fáceis de desenhar - úteis em sessões de brainstorm

• Seqüência

– Melhores para visualizar a seqüência do fluxo no tempo – Melhores para visualizar o fluxo completo

(22)

Contexto

Para cada caso de uso

encontramos as classes de análise identificamos classes persistentes

descrevemos o seu comportamento através de diagramas de interação

Agora, para cada classe

vamos descrever suas responsabilidades

Passo 4. Descrever

Responsabilidades

• Responsabilidades identificadas nos fluxos de eventos são refletidas em diagramas de interação

• Mensagens nestes diagramas resultam em responsabilidades nas classes receptoras

##

## $

(23)

BVF – Fazer Login

*

ControladorLogin

efetuarLogin(login, senha) <<control>>

TelaLogin

efetuarLogin(login, senha) registraSessao(login)

<<boundary>>

CadastroLocatario

pesquisarLocatario(login, senha)

<<entity collection>>

Locatario <<entity>>

Login Senha

Analisando o Modelo

• Classes com responsabilidades similares são candidatas a serem combinadas

• Uma classe com responsabilidades disjuntas é candidata a ser dividida

• Classes sem (ou com apenas uma responsabilidade) e classes que interagem com muitas classes são

candidatas a serem reexaminadas

(24)

Exercício

• Dado:

– Artefatos de requisitos do BVF,

especialmente o fluxo de eventos do caso de uso Reservar Obra

– As classes de análise identificadas no exercício anterior

• Produzir:

– Diagrama de interação para o caso de uso – VOPC com responsabilidades

Passo 5. Descrever atributos

e associações

• Detalhando mais as classes

– definir atributos

(25)

Encontrando Atributos

• Possíveis fontes: conhecimento do negócio, requisitos, glossário, modelo do negócio, etc.

• São propriedades/características das classes identificadas

– informação cujo valor é o aspecto crucial – informação de propriedade exclusiva do objeto

– informação que pode ser lida ou escrita por operações, mas sem outro comportamento a não ser fornecer um valor

• Se a informação tem comportamento complexo ou é compartilhada, deve gerar uma classe

Encontrando Relacionamentos

• Links entre objetos em diagramas de colaboração indicam a necessidade de relacionamento entre as respectivas classes

• Links reflexivos só geram relacionamentos reflexivos quando dois objetos da classe precisam se comunicar (mas não quando um objeto envia mensagens para si próprio)

• A navegabilidade do relacionamento deve estar de acordo com a direção da mensagem

(26)

Encontrando

Relacionamentos

% $ % $

Um relacionamento para cada link

!

BVF – Fazer Login

CadastroLocatario

pesquisarLocatario(login, senha) <<entity collection>> TelaLogin

efetuarLogin(login, senha)() registraSessao(login)()

<<boundary>>

ControladorLogin

efetuarLogin(login, senha)() <<control>>

(27)

Exercício

• Dado:

– Classes de análise do caso de uso Reservar Obra com estereótipos e responsabilidades – Diagramas de interação do caso de uso – VOPCs desenvolvidos no exercício anterior

• Produzir:

– VOPCs com relacionamentos e atributos. Incluir multiplicidade e navegabilidade dos relacionamentos