Análise e Projeto

Orientados a Objeto
com UML e Padrões

Modelo de Análise

1
Iniciando um Ciclo de Desenvolvimento

Plan. & Construção Implantaçã

Elaboração o

Ciclo de Ciclo de
...
Desenv. 1 Desenv. 2

Refin. Sinc.
Plano Artefatos Análise Projeto Impl. Teste

2
 Descrevendo caso de uso detalhado

Um Ciclo de Desenvolvimento Nota

s
a. se ainda não feito
Refin. Sinc. Anális Projeto Impl Teste b.
Plano Artefatos c.
contínuo
e .
opcional

1. Definir Casos 2. Refinar Diag. 3. Refinar Modelo 4. Refinar

de a Casos de Uso Conceitual Glossário b
Uso Essenciais

5. Definir Diag. 6. Definir Contrat. 7. Definir Diag.

Seq. de Operação Estado c

3
 Casos de Uso
● Descrições narrativas de processos do domínio da
aplicação

● Documentam a seqüência de eventos de um ator

(um agente externo) usando o sistema para
completar, do início ao fim, um determinado
processo

4
 Descrição Resumida
(simplificada)

Processar Venda:
Este caso de uso acontece quando um cliente chega em um
ponto de venda com itens de produtos que deseja adquirir. O
Operador do PDV informa para cada item comprado o código
de identificação e a quantidade de unidades. O sistema mostra
a descrição do produto, o valor unitário, o valor do item e o
valor acumulado (parcial) da venda. O Operador do PDV
informa a finalização dos itens. O sistema mostra o valor total
da venda. O Operador do PDV informa ao sistema a forma de
pagamento (dinheiro ou cartão). O sistema trata a forma de
pagamento validando os dados de acordo com a forma de
pagamento escolhida. O sistema registra a venda com os itens
comprados e dados de pagamento. O sistema atualiza o
estoque e emite um recibo que é entregue pelo Operador do
PDV ao cliente. O cliente sai com os itens comprados.

5
 Descrição essencial expandida
Caso de uso: Processar venda em dinheiro
Atores: Operador do PDV e Cliente
Propósito: Processar uma venda e seu pagamento em
dinheiro
Tipo: Primário e essencial
Pré-condições:
– Produtos previamente cadastrados
– Ponto de venda iniciado com registro do código identificador do
PDV e do identificador do Operador que o inicializou
Pós-condições:
– Venda registrada com data, horário, identificador do ponto de
venda, identificação e quantidade de cada item, valor total e
dados do pagamento (valor pago e troco recebido)
– Recibo de venda emitido para o cliente com dados da venda
registrada
6
 Descrição essencial expandida
Cenário Principal de Sucesso
1. O Operador do PDV informa ao sistema o identificador do item a ser
vendido e sua quantidade.
2. O Sistema exibe a descrição do produto, o valor unitário do produto e o
valor do item.
3. O sistema calcula e exibe o valor acumulado da venda.
Os passos 2 e 3 se repetem até que não haja mais itens
4. O Operador do PDV informa ao sistema o término dos itens
5. O Sistema exibe o valor total da venda
6. O Operador do PDV informa ao sistema o valor em dinheiro pago pelo
Cliente
7. O Sistema calcula e exibe o troco que deve ser dado ao cliente.
8. O Sistema registra a venda, atualiza o estoque dos produtos vendidos e
emite o recibo de pagamento.
7
 Descrição essencial expandida
Cenários Aternativos
1.a. O código identificador do item não é reconhecido
1. O Sistema exibe uma mensagem de erro e solicita a reentrada do
identificado do item
2. O Sistema retorna ao passo 1 do Cenário Principal de Sucesso

6.a. O Cliente desiste da compra

3. O Sistema exibe mensagem de venda cancelada
4. O caso de uso é encerrado

8
 Descrição essencial expandida
Cenários Aternativos

6 b. O Cliente pede para cancelar um dos itens da venda

1. O Operador do PDV informa o número do item de venda que deve
ser cancelado
2. O Sistema exclui o item da venda e recalcula o valor acumulado da
venda
3. O Sistema retorna ao passo 5

9
 Atores
● Entidades externas ao sistema que de algum modo
participam da estória do caso de uso
– Estimulam o sistema com eventos de entrada, ou
recebem alguma coisa dele
– Designados pelo papel que exercem no caso de uso
Ex.: Cliente, Operador, etc.

● Representação em UML:
Cliente

10
 Atores e Casos de Uso
● Um caso de uso possui um ator iniciador, que gera
o estímulo inicial, e possivelmente vários atores
participantes
– O ator iniciador deve ser indicado explicitamente na
descrição do caso de uso

● Algumas categorias típicas de atores incluem:

– papeis exercidos por pessoas
– sistemas de computação
– dispositivos elétricos e mecânicos

11
 Identificando Casos de Uso
● Normalmente não são eventos ou passos
individuais, mas um processo completo
– Erro mais comum!

● Método baseado em atores

1. Identificar os atores relacionados com o sistema ou
organização
2. Para cada ator, identificar os processo que eles
iniciam ou participam

12
 Identificando Casos de Uso
● Método baseado em eventos
1. Identificar os eventos externos aos quais o sistema
deve responder
2. Relacionar os eventos a atores e casos de uso

● Exemplos do sistema PDV

– Operador de PDV: Login, Retirar Dinheiro
– Cliente: Vender Produtos, Processar Devolução
– Digitar Senha?
– Imprimir Recibo?

13
 Casos de Uso e Funções
● Todas as funções do sistema identificadas na
especificação dos requisitos devem ser alocadas a
casos de usos
– Alocação documentada através da seção Referência

● Idealmente, funções e casos de uso devem ser

rastreáveis até a implementação e teste do sistema

14
 Diagramas de Caso de Uso
● Ilustram um conjunto de casos de uso e atores
para um sistema e os relacionamentos entre eles

● Diagrama parcial para o sistema PDV

PDV

Vender Produtos

Operador de PDV Cliente

Iniciar PDV

Devolver Produtos

15
 Casos de Uso e o Limite do Sistema
● Identificar os atores e casos de uso de um sistema
requer a definição de seu limite de atuação

● Alguns limites típicos incluem:

– o software/hardware de um dispositivo ou sistema
de computação
– um departamento de uma organização
– uma organização inteira

● Limites diferentes podem resultar em diferentes

conjuntos de atores e casos de uso

16
 Casos de Uso e o Limite do Sistema
● Exemplo de um diagrama de caso de uso para o
sistema PDV, quando o limite de atuação é a loja
inteira

Loja

Vender Produtos

Cliente
Devolver Produtos

17
 Tipos de Caso de Uso
● Primário
Representam os processos principais ou mais
comuns (ex.: Vender Produtos)

● Secundário
Representam processos menos importantes ou mais
raros (ex.: Cadastrar Operadores)

● Opcional
Representam processos que podem ser ignorados
ou incluídos em futuras versões do sistema (ex.:
Solicitar Estoque para um Novo Produto)
18
 Formatos de Caso de Uso
● Resumido (Alto-nível)
– Breve descrição de um processo, normalmente em
duas ou três frases, e deliberadamente vago em
decisões de projeto
– Criados na fase inicial de requisitos

● Expandido
– Descrição passo a passo dos eventos de um
processo
– Durante a fase de requisitos, apenas os casos de
uso mais importantes devem ser escritos nesse
formato

19
 Formatos de Caso de Uso
● Essencial
– Descrição de um processo em termos de sua
motivação e atividades essenciais
– Expressos relativamente livres de detalhes de
implementação, decisões de projeto, e uso de
tecnologias

● Concreto
– Descrição de um processo em termos de seu
projeto real, comprometido com tecnologias de
desenvolvimento, interfaces de entrada e saída, etc.

20
 Descrição concreta expandida
Cenário Principal de Sucesso
1. O Caixa digita o código identificador do produto no campo UPC da
Janela 1 e a quantidade no campo campo QTD da janela “Venda”. Ele
então pressiona o botão “Entrar Item” com o mouse ou pressiona a tecla
<Enter>.
2. O Sistema exibe a descrição do produto no campo Descrição da janela
“Venda”, o valor unitário no campo “Valor Unitário” da janela “Venda” e o
valor do item no campo “Valor do Item” da janela “Venda’.
3. O sistema calcula e exibe o valor acumulado da venda no campo “Valor
Acumulado” da janela “Venda”.
Os passos 2 e 3 se repetem até que não haja mais itens

21
 Casos de Uso no Processo de
Desenvolvimento
● Passos da fase de Construção
1. Análise: Escreva casos de uso expandidos essenciais para
aqueles sendo atacados no ciclo de desenvolvimento corrente,
se ainda não feito.

2. Projeto: Escreva casos de uso reais para aqueles sendo

atacados no ciclo de desenvolvimento corrente, se ainda não
feito.

22
 Passos do Processo para o Sistema PDV
● Desenhar diagrama de caso de uso
PDV

Vender Produtos

Operador de PDV Cliente

Abrir PDV

Devolver Produtos

Inicializar

Gerente
Gerenciar
Usuários
Administrador do
Sistema
etc.

23
 Priorizando Casos de Uso
● Atacar primeiro aqueles com maior influência na
estrutura básica do sistema

● Características que podem aumentar a prioridade

de um caso de uso:
– Impacto significativo no projeto da arquitetura
– Funções complexas, arriscadas, ou de tempo crítico
– Envolve novas pesquisas ou tecnologia emergente
– Representa processos primários de negócio
– Contribui diretamente para aumentar lucros ou
diminuir custos

24
 O Caso de Uso “Inicializar”
● Presente em virtualmente todos os sistemas

● Desenvolvido já no primeiro ciclo, pelo menos em

alguma versão simplificada

● Elaborado incrementalmente nos outros ciclos

para satisfazer as necessidades de inicialização
dos outros casos de uso

● Escalonamento implícito

25
Escalonando os Casos de Uso do Sistema
PDV
● Casos de uso do primeiro ciclo:
– Vender Produtos
– Abrir PDV (versão simplificada)

● Criando múltiplas versões de Vender Produtos

– Versão 1: apenas pagamentos com dinheiro, sem
atualização de estoque, ...
– Versão 2: permite todos os tipos de pagamento
– Versão 3: versão completa, incluindo atualização de
estoque

26
Escalonando os Casos de Uso do Sistema
PDV
● Alocando casos de uso a ciclos de
desenvol-vimento

Ciclo de Ciclo de Ciclo de

Ciclo de
Desenvolvimento Desenvolvimento Desenvolvimento
Desenvolvimento
2 3 4
1

Vender Produtos Vender Produtos Vender Produtos Conectar

versão 1 versão 2 versão 3
-----
----- ----- ----- -----
----- ----- ----- -----
----- ----- -----

Devolver Produtos
-----
-----
-----

27
 Versões de Caso de Uso para Vender Produtos
● Simplificações, objetivos e pressuposições
– Versão 1
Apenas pagamentos com dinheiro
Sem atualização de estoque
Única loja
Entrada manual de UPC (sem leitora de código de barras)
Sem cálculo de impostos
Sem descontos
Operador não precisa fazer login (sem controle de acesso)
Sem registro de clientes e seus hábitos de compra
– Versão 2
Os mesmos da Versão 1, exceto que pagamentos podem ser
feitos com dinheiro, cheque, ou cartão de crédito
28
 Construindo um Modelo Conceitual

Um Ciclo de Desenvolvimento Nota

s
a. se ainda não feito
Refin. Sinc. Anális Projeto Impl Teste b.
Plano Artefatos c.
contínuo
e .
opcional

1. Definir Casos 2. Refinar Diag. 3. Refinar Modelo 4. Refinar

de a Casos de Uso Conceitual Glossário b
Uso Essenciais

5. Definir Diag. 6. Definir Contrat. 7. Definir Diag.

Seq. de Operação Estado c

29
 Modelo Conceitual
● Artefato mais importante da AOO

● Representa conceitos relevantes (do ponto de vista

do modelador) do domínio do problema

● Na UML, ilustrado com diagramas de estruturas

estáticas contendo:
– Conceitos
– Associações entre conceitos
– Atributos de conceitos

30
 Modelo Conceitual para o Sistema PDV
● Diagrama parcial

31
 Conceitos
● Idéias, coisas, ou objetos do mundo real

Stor PDV Sal

e e
dat
tim
e
e

● Não representam componentes de software!

id SalesDatabas
software artifact; not
avo e of conceptual
part
model

id Sal
avo e software class; not
dat of conceptual
part
tim
e model
e
print(
)
32
 Identificando Conceitos
● Regras úteis:
– É melhor especificar demais do que especificar de
menos
– Não exclua conceitos simplesmente porque os
requisitos não indicam a necessidade de guardar
informações sobre eles (comum em projeto de BD)
– Comece fazendo uma lista de conceitos candidatos
a partir de uma lista de conceitos comuns
– Considere os substantivos e frases nominais nas
descrições textuais do domínio do problema como
possíveis candidatos a conceitos ou atributos

33
 Conceitos Típicos
Categoria Exemplos
Objeto físico ou tangível Terminal de ponto-de-venda
Avião
Especificação, projeto, ou Especificação de produto
descrição de coisas
Descrição de vôo
Lugares Loja
Aeroporto
Transações Venda, Pagamento
Reserva
Itens de transação Itens de venda
Parcelas de pagamento
Papéis de pessoas Operador
Piloto
Container de coisas Loja
Avião
34
 Conceitos Típicos
Categoria Exemplos
Coisas em um container Item
Passageiro
Sistemas externos Serviço de crédito
Controle de tráfego aéreo
Nomes abstratos Fome
Aracnofobia
Organizações Departamento de vendas
Companhia aérea
Eventos Venda, Assalto, Reunião
Vôo, Decolagem
Regras e políticas Política de devolução
Política de cancelamento

35
 Conceitos Típicos

Categoria Exemplos
Catálogos Catálogo de produtos
Catálogo de peças
Registros de finança, trabalho, Recibo, Contrato de trabalho
contrato, questões legais
Registro de manutenção
Instrumentos e serviços financeiros Linha de crédito
Ações
Manuais, livros Manual do empregado
Manual de reparos

36
 Identificando Conceitos e Atributos em
Descrições Textuais
Ação do Ator Resposta do Sistema
1. Este caso de uso começa
quando um Cliente chega no
caixa com itens para comprar.
2. O Operador registra o 3. Determina o preço do item e
identi-ficador de cada item. adiciona informação sobre o item
Se há mais de um do mesmo à transação de venda em
item, o Operador também pode anda-mento.
informar a quantidade. Mostra a descrição e o preço do
item corrente.

● Usar com cuidado!

– Linguagens naturais: imprecisão e ambigüidade

37
Conceitos Candidatos para o Sistema PDV

● Conceitos restritos ao caso de uso Processar

Venda - Versão 1

38
 Conceitos de Relatório
● Não incluir no modelo conceitual quando:
– Toda informação contida no relatório é derivada de
outras fontes

● Incluir no modelo conceitual quando:

– Relatório tem um papel especial em termos das
regras de negócio
Ex.: Recibo de venda dá direito à devolução dos itens
comprados
● Incluir Recibo no modelo conceitual para o sistema
PDV?
– Sim, mas apenas no ciclo de desenvolvimento que
trata do caso de uso Devolver Itens
39
 Criando um Modelo Conceitual
● Passos sugeridos:
1. Liste os conceitos candidatos para os casos de
usos em questão usando a lista de categorias
comuns e identificação textual de nomes.
2. Desenhe-os em um modelo conceitual.
3. Adicione as associações necessárias para registrar
os relacionamentos para os quais é preciso
preservar alguma memória (*)
4. Adicione os atributos necessários para cumprir os
requisitos de informação. (*)
(*) A ser discutido

40
 Criando um Modelo Conceitual
● Estratégia do “fazedor de mapas”:
– Usar nomes existentes no vocabulário do domínio
– Incluir apenas conceitos pertinentes para os
requisitos (casos de uso) em questão
– Excluir tudo que não há no domínio do problema

● Erro comum: atributo em vez de conceito

Vôo Vôo Aeroporto

ou... ?
destino nome

– Atributos normalmente correspondem a um texto ou

número no mundo real
41
 Conceitos de Especificação ou Descrição
● A especificação ou descrição de um objeto deve
ser representada como um conceito em separado
– evita perda de informação quando o objeto é
deletado
– reduz informações redundantes ou duplicadas

● Muito comum no domínio de produtos e vendas

Ex.:
Item
Especificação-Produto
descrição Item
descrição Descreve
preço 1
número serial
preço * Número serial
UPC
UPC

pior melhor

42
 Conceitos de Especificação ou Descrição
● Outro exemplo:
Vôo
Aeroporto
data Voa-para
pior
número 1 nome
hora *

Vòo
Descrição-Vôo
Descrito-por melhor
data
1 número
hora *
*
Descreve-vôo-para
1

Aeroporto

nome

43
 Conceitos e a Terminologia da UML
● UML usa o termo genérico “classe” para denotar
tanto entidades do domínio da aplicação quanto
classes na POO
– Uma classe na POO é chamada mais
especificamente de “classe de implementação”

● Os termos “tipo” e “interface” são usados para

denotar especificações de classes de
implementação

● No âmbito do curso, o termo “conceito” denota

entidades do mundo real, e “classe” denota
componentes de software e suas especificações
44
 Associações
● Uma associação é um relacionamento entre
conceitos que indica uma conexão significativa e
interessante

● Descritos na UML como “relacionamentos

estruturais entre objetos de tipos diferentes”

● Indicam conhecimento de um relacionamento que

precisa ser preservado durante algum tempo
– Duração de milisegundos ou anos, dependendo do
contexto

45
 Associações
● Notação na UML
– Uma linha entre dois conceitos mais um nome
– Inerentemente bidirecional
– Pode conter um seta de direção de leitura
– Pontas podem conter expressões de cardinalidade

46
 Associações Típicas
Categoria
A é uma parte física de B (*)
A é uma parte lógica de B (*)
A está fisicamente contido em B (*)
A está logicamente contido em B (*)
A é uma descrição de B
A é um item de uma transação ou
relatório B
Aé
conhecido/registrado/repor-tado/cap
turado em B (*)
Exemplos
Gaveta - PDV
Asa - Avião
Item de Venda - Venda
Escala - Vôo
PDV - Loja
Passageiro - Avião
Descrição-Item - Catálogo
Vôo - Roteiro de Viagem
Descrição-Item - Item
Descrição-Vôo - Vôo
Item de Venda - Venda
Opção de Reserva - Reserva
Venda - PDV
Reserva - Terminal de Reserva
(*) Alta prioridade 47
 Associações Típicas
Categoria
A é um membro de B
A é uma sub-unidade
organizacional de B
A usa ou gerencia B
A se comunica com B
A está relacionado com uma
transação B
A é uma transação relacionada
com outra transação B
A é possuído por B
Exemplos
Operador - Loja
Piloto - Companhia Aérea
Departamento - Loja
Manutenção - Companhia Aérea
Operador - PDV
Piloto - Avião
Cliente - Operador
Agente de Reserva - Passageiro
Cliente - Pagamento
Passageiro - Bilhete
Pagamento - Venda
Reserva - Cancelamento
PDV - Loja
Avião - Companhia Aérea
48
 Identificando Associações
● Regras úteis:
– Focar nas associações cujo conhecimento deve ser
preservado
– Usar nomes baseados em expressões verbais que
façam sentido quando lidas no contexto do modelo
– Evitar mostrar associações deriváveis ou
redundantes
– É mais importante identificar conceitos do que
associações
– Associações demais tendem a confundir um modelo
conceitual ao invés de iluminá-lo

49
 Papeis de Uma Associação
● Cada ponta de um associação é chamada de um
“papel”
● Um papel pode ter:
– Nome
– Expressão de multiplicidade

– Navegabilidade
50
 Expressões de Multiplicidade

● O valor da multiplicidade depende do contexto

– Ex.: Pessoa Trabalha-para Empresa

51
 Adicionando Associações ao Modelo
Conceitual do Sistema PDV
● Relacionamentos fundamentais
– Venda Capturada-em PDV
Para conhecer a venda corrente, calcular total e imprimir
recibo
– Venda Paga-por Cliente
Para saber se a venda foi paga, calcular troco, e imprimir
recibo
– Catálogo-Produto Contém Especificação-Item
Para obter a especificação de um item, dado um UPC

52
Aplicando a Lista de Associações Típicas
Categoria Exemplos
A é uma parte física de B N.A.

A é uma parte lógica de B Item de Venda - Venda

A está fisicamente contido em B PDV - Loja

Item - Loja
A está logicamente contido em B Especificação-Produto - Catálogo
Catálogo - Loja
A é uma descrição de B Especificação-Produto - Item

A é um item de uma transação ou Item de Venda - Venda

relatório B

Aé Venda (corrente) - PDV

conhecido/registrado/repor-tado/cap
turado em B Venda (completada) - Loja
53
Aplicando a Lista de Associações Típicas
Categoria Exemplos
A é um membro de B Operador - Loja

A é uma sub-unidade N.A.

organizacional de B

A usa ou gerencia B Operador - PDV

Gerente - PDV
A se comunica com B Cliente - Operador

A está relacionado com uma Cliente - Pagamento

transação B
Operador - Pagamento
A é uma transação relacionada Pagamento - Venda
com outra transação B

A é possuído por B PDV - Loja

54
Conceitos e Associações Candidatos para o
Sistema PDV

55
Eliminando Associações Redundantes ou
Desnecessárias
● Associações cujo conhecimento não precisa ser
preservado podem ser removidas do modelo:

Associação
Venda Iniciada-por Operador
Operador Registra-vendas-em PDV
PDV Inicializado-por Gerente
Venda Iniciada-por Cliente
Loja Armazena Item
Item de Venda Registra-venda-de Item
Consideração
Conhecimento não exigido nos
requisitos; derivável da associação
Operador Registra-vendas-em PDV.
Conhecimento não exigido nos
requisitos.
Conhecimento não exigido nos
requisitos.
Conhecimento não exigido nos
requisitos.
Conhecimento não exigido nos
requisitos.
Conhecimento não exigido nos
requisitos.

56
Preservando Associações de Compreensão
● Preservar apenas associações de conhecimento
pode resultar num modelo que não transmite um
completo entendimento do domínio
– Ex.: Venda Iniciada-por Cliente
Remoção deixa de fora um aspecto importante do domínio—
o fato de que um cliente gera uma venda

● Modelo conceitual é um artefato de comunicação!

● Regra geral:
– Enfatizar associações de conhecimento, mas
preservar associações que enriquecem o
entendimento do domínio
57
 Atributos
● Um atributo é um dado lógico de um objeto do
domínio

● Definidos para conceitos cujos requisitos (casos

de uso) sugerem a necessidade de preservar
algum tipo de informação
– Ex.: atributos data e hora para o conceito Venda

● Notação na UML

58
 Identificando Atributos
● Atributos devem preferencialmente representar
tipos primitivos de dados ou de valores simples
– Ex.: Data, Número, Texto, Hora, Endereço, etc.
● Atributos não devem ser usados para:
– Representar um conceito complexo
– Relacionar conceitos (atributo “chave-estrangeira”)

59
 Atributos de Tipo Não-Primitivo
● Podem ser representados diretamente no modelo
conceitual Product Store
Specification
address : Address
upc : UPC

● Um atributo deve ser de tipo não-primitivo quando:

– É composto de seções separadas
Ex.: endereço, data
– Precisa ser analisado ou validado
Ex.: CPF, número de matrícula
– Possui outros atributos
Ex.: Um preço promocional com prazo de validade
– É uma quantidade com uma unidade
Ex.: valores monetários, medidas
60
Adicionando Atributos aos Conceitos
Candidatos do Sistema PDV

Conceito Atributos e justificativa

Pagamento quantia—Para determinar se pagamento é suficiente
e calcular troco.
Especificação-Produto descrição—Para mostrar na tela e imprimir no recibo.
UCP—Para localizar especificação do item.
preço—Para calcular o total da venda.
Venda data, hora—Para imprimir no recibo e registrar no log
de vendas.
Item de Venda quantidade—Para registrar a quantidade digitada
quando há mais de um do mesmo item.
Loja nome, endereço—Para imprimir no recibo.

61
 Atributo Derivado
● Um atributo “derivado” é um atributo cujo valor
pode ser deduzido a partir de outras informações
– Ex.: quantidade em Item de Venda—pode ser
deduzido a partir da multiplicidade da associação
entre Item de Venda e Item

● Na UML, indicado com o símbolo “/”

SalesLineItem 0..1 Records-sale-of 1.. Item

/quantity *

derived attribute from

the multiplicity value

62
Modelo Conceitual Inicial do Sistema PDV
Records-sale-of

Described-by
1

Product
Product Specification
Catalog Contains
1 description
1.. *
price
1 UPC
0..1 Used-by
* Describes
Sales * *
LineItem Store
Item
Stocks
/quantity 1 address 1 1..
name * *
1.. *
Logs- 1
Contained-in Houses
completed
1 6 1.. *

Sale * PDV
Manager
date Started-by
1 1
Captured-on
time 1 1
1
1 Initiated-by 1
Paid-by 3 Records-sales-on
1 1 1

Payment Customer Cashier

amount

63
 Registrando Termos no Glossário
● Um glossário ou dicionário de modelo é um
documento que define os termos (ou vocabulário)
do domínio
– Similar a um dicionário de dados usado na
modelagem de BD

● Fundamental para garantir uma comunicação

consistente e um entendimento compartilhado
entre usuários e desenvolvedores

● Também pode ser usado para registrar restrições

de domínio e regras de negócio (não explorado no
curso)
64
 Glossário Parcial para o Sistema PDV

Termo Categoria Comentário

Processar Venda caso de uso Descrição do processo de um
cliente comprando itens numa loja.
Especificação-Produto.descrição atributo Uma descrição sucinta de um item
:Texto de venda.
Item tipo Um item à venda numa loja.

Pagamento tipo Um pagamento em dinheiro.

Especificação-Produto.preço atributo O preço de um item de venda.

:Quantidade
Item de Venda.quantidade atributo A quantidade de um tipo particular
:Inteiro de item comprado.
Venda tipo Uma transação de venda.

Item de Venda tipo Um item particular comprado como

parte de uma venda.

65
 Definindo Diagramas de Seqüência

Um Ciclo de Desenvolvimento Nota

s
a. se ainda não feito
Refin. Sinc. Anális Projeto Impl Teste b.
Plano Artefatos c.
contínuo
e .
opcional

1. Definir Casos 2. Refinar Diag. 3. Refinar Modelo 4. Refinar

de a Casos de Uso Conceitual Glossário b
Uso Essenciais

5. Definir Diag. 6. Definir Contrat. 7. Definir Diag.

Seq. de Operação Estado c

66
 Diagramas de Seqüência
● Um diagrama de seqüência ilustra a ordem das
interações dos atores externos com o sistema
(representado como uma “caixa-preta”) e os
eventos que eles geram

67
 Eventos e Operações
● Um evento de sistema é um evento externo de
entrada gerado por um ator do sistema
– Inicia uma operação de resposta de mesmo nome
● Uma operação de sistema é uma operação do
sistema que executa em resposta a um evento de
sistema

68
 Representando Operações
● O conjunto necessário de operações de sistema é
determinado através da identificação dos eventos
de sistema
– Exemplos de operações para o sistema PDV:
entrarItem(UPC, quantidade)
encerrarVenda()
fazerPagamento(quantia)

● Na UML, representado como operações de um tipo

denominado Sistema:

69
 Definindo Diagramas de Seqüência
● Regras úteis:
1. Desenhar uma linha vertical representando o
sistema como uma caixa-preta.
2. Identificar os atores que operam diretamente com o
sistema. Desenhar uma linha vertical representando
cada um desses atores.
3. A partir da descrição das seqüências típicas de
eventos dos casos de uso, identificar os eventos de
sistema que cada ator gera. Ilustrar os eventos no
diagrama.
4. Opcionalmente, incluir o texto do caso de uso à
esquerda do diagrama.

70
 Definindo Diagramas de Seqüência
● Diagrama de seqüência para o sistema PDV com
(parte do) texto do caso de uso Compra Itens
-Versão 1:

71
 Nomeando Eventos e Operações
● Regras úteis:
– Começar com um verbo
– Enfatizar “intenção” em vez do meio físico de
entrada ou componente gráfico da interface com o
usuário
Ex.: encerrarVenda em vez de pressionarTeclaEnter
– Expressar intenção no nível mais alto de abstração
Ex.: fazerPagamento em vez de entrarQuantia

72
 Definindo Contratos de Operação

Um Ciclo de Desenvolvimento Nota

s
a. se ainda não feito
Refin. Sinc. Anális Projeto Impl Teste b.
Plano Artefatos c.
contínuo
e .
opcional

1. Definir Casos 2. Refinar Diag. 3. Refinar Modelo 4. Refinar

de a Casos de Uso Conceitual Glossário b
Uso Essenciais

5. Definir Diag. 6. Definir Contrat. 7. Definir Diag.

Seq. de Operação Estado c

73
 Contratos
● Um contrato é um documento que descreve os
compromissos de uma operação
– Estilo declarativo
– Pré e pós-condições de mudanças de estado
– Para métodos, classes, ou operações gerais de
sistema
● Exemplo para operação entrarItem:
Contrato: entrarItem (upc :número, quantidade :inteiro)
Responsabilidades: Registra venda de um item e o adiciona à venda
corrente. Mostra descrição e preço do item.
Tipo: Sistema
Referencia: Funções: R1.1, R1.3, R1.9
Casos de uso: Processar Venda
74
 Contratos
● Exemplo para operação entrarItem (cont.):
Notas: Usar acesso rápido ao BD
Exceções: Se UPC inválido, indicar erro.
Saída:
Pré-condições: UPC é conhecido do sistema
Pós-condições:
● Se nova venda, uma Venda foi criada (criação de instância).
● Se nova venda, a nova Venda foi associada com um PDV (formação de

associação.
● Um Item-de-Venda foi criado (criação de instância).

● O Item-de-Venda foi associado à Venda (formação de associação).

● Item-de-Venda.quantidade foi definido para quantidade (modificação de

atributo).
● O Item-de-Venda foi associado com uma Especificação-Produto, baseado

no casamento de UPCs (formação de associação).

75
 Seções de um Contrato
Contrato: Nome e parâmetros da operação
Responsabilidades: Descrição informal das responsabilidades da operação
Tipo: Nome do tipo (conceito, classe, interface)
Referencia: Funções, casos de uso, etc.
Notas: Notas de projeto, algoritmos, etc.
Exceções: Casos excepcionais e ações executadas no seu tratamento
Saída: Saídas não-IU, tais como mensagens ou registros
enviados para fora do sistema
Pré-condições: Pré-suposições sobre o estado do sistema antes da
execução da operação
Pós-condições: O estado do sistema após a execução da operação

Regras de negócio: Regras de negócio utilizadas pela operação para cumprir

suas responsabilidades

76
 Como Fazer um Contrato
● Regras úteis:
1. Identificar operações de sistema a partir dos
diagramas de seqüência.
2. Para cada operação, construir um contrato.
3. Começar escrevendo a seção Responsabilidades,
descrevendo informalmente o propósito da operação.
4. Completar a seção Pós-condições, descrevendo
declarativamente as mudanças de estado que
ocorrem aos objetos do modelo conceitual:
- Criação e remoção de instância
- Modificação de atributo
- Formação e quebra de associações (erro mais comum!)

77
 Como Fazer um Contrato
● Regras úteis (cont.):
5. Completar a seção Pré-condições, descrevendo as
pré-suposições sobre o estado do sistema no início
da operação:
- Coisas que devem ser testadas pelo sistema em algum ponto
durante a execução da operação
- Coisas que não são testadas, mas sobre as quais depende
fortemente o sucesso da operação

78
 Contratos e Outros Artefatos

Caixa Sistema
Caso de Uso: Operação: entrarItem
iniciarVenda()
Processar
Vendas Pos-condições:
entrarItem
• Foi criada uma
(idItem,qtd) instância de
Fluxo Principal
Sistema ItemVenda

1. Este caso de finalizarVenda() iniciarVenda()

Uso começa... entrarItem()
Operation: endSale
finalizarVenda()
makePayment
fazerPagamento() Postconditions:
(amount)
1. ...

Caso de Uso Diagrama de Operaçõe Contratos de

Sequencia de s
do Sistema Operação
Sistema

79
 Pós-condições: Palco e Cortina
● Pós-condições devem ser expressas no passado,
enfatizando mudanças de estado já ocorridas

● Analogia: Palco e Cortina

– Imagine os objetos do sistema no palco de um teatro
– Antes da operação, fotografe o palco
– Feche a cortina e execute a operação
– Abra a cortina e fotografe o palco novamente
– Compare as duas fotos, e então expresse como
pós-condições as mudanças no estado do palco

80
 Contratos para o Sistema PDV
● Operação finalizarVenda:
Operação: finalizarVenda ()
Responsabilidades: Registra o fim da entrada de itens de venda, e mostra o
total da venda.

Pré-condições: Existe uma venda em andamento

Pós-condições:
● Venda.Completada é definido para verdadeiro (modificação de atributo).
Note a necessidade de adicionar o atributo
lógico Completada ao conceito Venda!

81
 Contratos para o Sistema PDV
● Operação fazerPagamento:
Operação: fazerPagamento (quantia: Número ou Quantidade)
Responsabilidades: Registra o pagamento, calcula troco, e imprime recibo.
Pré-condições:
Pós-condições:
● Um Pagamento foi criado (criação de instância).
● Pagamento.quantia foi definido para quantia (modificação de atributo)

● O Pagamento foi associado com a Venda (formação de associação).

● A Venda foi associada com a Loja, para adicioná-la ao log de vendas

completadas (formação de associação).

82
 Contratos para o Sistema PDV
● Operação Inicializar:
Operação: Inicializar ()
Responsabilidades: Inicializa o sistema.
Pré-condições:
Pós-condições:
● Loja, PDV, Catálogo-Produto, e Especificação-Produto foram criados
(criação de instância).
● PDV foi associado com Loja, e Catálogo-Produto com

Especificação-Produto, PDV, e Loja (formação de associação).

83