Análise Orientada a
Objeto
com a metodologia (R)UP + UML
Modelo Conceitual (ou de
Domínio), Diagrama de
Seqüência, Contrato de
Operação
© Nabor C. Mendonça 2001
1
Construindo um Modelo Conceitual
Um Ciclo de Desenvolvimento
Refin.
Plano
© Nabor C. Mendonça 2001
Sinc.
Artefatos
Análise
Notas
Projeto
Impl.
a. se ainda não feito
b. contínuo
c. opcional
Teste
1. Definir Casos de
Uso Essenciais a
2. Refinar Diag.
Casos de Uso
3. Refinar Modelo
Conceitual
5. Definir Diag.
Seq.
6. Definir Contrat.
de Operação
7. Definir Diag.
Estado
4. Refinar
Glossário
b
c
2
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
© Nabor C. Mendonça 2001
3
Modelo Conceitual para o Sistema TV

Diagrama parcial
Concept
Sales
LineItem
1
0..1
quantity
Item
Records-sale-of
*
1..*
Association
Stocked-in
Contained-in
1
1
Sale
Attributes
date
time
Store
address
name
1
1
1
Houses
Paid-by
1
Payment
1..*
POST
Captured-on

1
amount
© Nabor C. Mendonça 2001
4
Conceitos

Idéias, coisas, ou objetos do mundo real
Loja
TV
Venda
data
hora

Não representam componentes de software!
BDdeVendas
Venda
data
hora
Artefato de software; não faz
parte do modelo conceitual
Classe de software; não faz
parte do modelo conceitual
imprimir()
© Nabor C. Mendonça 2001
5
Caso de Uso e Modelo de Domínio
© Nabor C. Mendonça 2001
6
Identificando Conceitos

Regras úteis:
–
É melhor ‘pecar’ por excesso do que por parcimônia
–
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 dos casos de uso
Considere os substantivos e frases nominais nas descrições
textuais do domínio do problema como possíveis candidatos
a conceitos ou atributos
© Nabor C. Mendonça 2001
7
Conceitos Típicos
Categoria
Objeto físico ou tangível
Exemplos
Terminal de ponto-de-venda
Avião
Especificação, projeto, ou
descrição de coisas
Especificação de produto
Descrição de vôo
Lugares
Loja
Transações
Aeroporto
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
© Nabor C. Mendonça 2001
8
Conceitos Típicos
Categoria
Coisas em um container
Exemplos
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
© Nabor C. Mendonça 2001
9
Conceitos Típicos
Categoria
Catálogos
Exemplos
Catálogo de produtos
Catálogo de peças
Registros de finança, trabalho,
contrato, questões legais
Recibo, Contrato de trabalho
Registro de manutenção
Instrumentos e serviços financeiros Linha de crédito
Ações
Manuais, livros
Manual do empregado
Manual de reparos
© Nabor C. Mendonça 2001
10
Identificando Conceitos e Atributos em Casos
de Uso
Ação do Ator
1. Este caso de uso começa
quando um Cliente chega no
caixa com itens para comprar.
2. O Operador registra o identificador de cada item.
Se há mais de um do mesmo
item, o Operador também pode
informar a quantidade.
© Nabor C. Mendonça 2001
Resposta do Sistema
3. Determina o preço do item e
adiciona informação sobre o item
à transação de venda em andamento.
Mostra a descrição e o preço do
item corrente.
11
Conceitos Candidatos para o Sistema TV
POST
Sales
LineItem
Payment

Item
Store
Cashier
Customer
Product
Catalog
Product
Specification
Sale
Manager
Conceitos restritos ao caso de uso Processar
Venda - Versão 1
© Nabor C. Mendonça 2001
12
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
TV?
–
Sim, mas apenas no ciclo de desenvolvimento que
trata do caso de uso Devolver Itens
© Nabor C. Mendonça 2001
13
Criando um Modelo Conceitual

Passos sugeridos
1. Liste os conceitos candidatos encontrados nos
casos de usos
2. Represente-os em um modelo conceitual
Retângulos
3. Adicione os relacionamentos entre os conceitos
Linhas e multiplicidade
4. Adicione os atributos dos conceitos
Diferença entre Conceito e Atributo?
© Nabor C. Mendonça 2001
14
Conceito e Atributo de Conceito
parte_de
Vôo
Vôo
ou... ?
destino
Aeroporto
1..*
1..*
nome
chega_a
Note que, em um sistema de vôos, aeroporto é um conceito
relevante, logo deve ser modelado como tal, e não como um
atributo (destino).
Outras razões:
- que vôos partem (chegam) de (a) um aeroporto?
- quais os aeroportos de origem e destino de um vôo?
© Nabor C. Mendonça 2001
15
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 é
removido
–
reduz informações redundantes ou duplicadas
Muito comum no domínio de produtos e vendas
Ex.:
Item
descrição
preço
número serial
UPC
pior
© Nabor C. Mendonça 2001
Especificação-Produto
descrição
preço
UPC
Item
Descreve
1
*
Número serial
melhor
16
Conceitos e a Terminologia da UML

UML usa o termo genérico “classe” para denotar
tanto entidades (conceitos) 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 (análise), e “classe”
denota componentes de software e suas
especificações (design)
© Nabor C. Mendonça 2001
17
Relacionamentos e Associações


Relacionamento entre conceitos indica uma
conexão significativa e interessante entre os
conceitos
No nível de instância de conceito, diz-se
associação entre instâncias
–

Descritos na UML como “associações estruturais
entre objetos de tipos diferentes”
Um relacionamento precisa ser preservado
durante algum tempo
–
Duração de mili-segundos ou anos, dependendo do
contexto
© Nabor C. Mendonça 2001
18
Relacionamentos

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 multiplicidade
-"direction reading arrow"
-it hasno meaning except to indicate direction of
reading the association label
-often excluded
POST
Records-current

1
association name
© Nabor C. Mendonça 2001
1
Sale
multiplicity
19
Relacionamentos Típicos
Categoria
A é uma parte física de B
Exemplos
Gaveta - TV
Asa - Avião
A é uma parte lógica de B
Item de Venda - Venda
Escala - Vôo
A está fisicamente contido em B
TV - Loja
A está logicamente contido em B
Passageiro - Avião
Descrição-Item - Catálogo
Vôo - Roteiro de Viagem
A é uma descrição de B
Descrição-Item - Item
Descrição-Vôo - Vôo
A é um item de uma transação B ou
um ítem de um relatório B
Item de Venda - Venda
Opção de Reserva - Reserva
A é conhecido/registrado/reportado/captado em B
Venda - TV
Reserva - Terminal de Reserva
© Nabor C. Mendonça 2001
20
Relacionamentos Típicos
Categoria
A é um membro de B
Exemplos
Operador - Loja
Piloto - Companhia Aérea
A é uma sub-unidade
organizacional de B
Departamento - Loja
Manutenção - Companhia Aérea
A usa ou gerencia B
Operador - TV
A se comunica com B
Piloto - Avião
Cliente - Operador
Agente de Reserva - Passageiro
A está relacionado com uma
transação B
Cliente - Pagamento
Passageiro - Bilhete
A é uma transação relacionada
com outra transação B
Pagamento - Venda
Reserva - Cancelamento
A é propriedade de B
TV - Loja
Avião - Companhia Aérea
© Nabor C. Mendonça 2001
21
Identificando Relacionamentos nos Casos de Uso

Regras úteis:
–
Focar nos relacionamentos cujo conhecimento deve
ser preservado
–
Extrair expressões verbais dos casos de uso
–
Relacionamentos demais tendem a confundir um
modelo conceitual ao invés de iluminá-lo
© Nabor C. Mendonça 2001
22
Multiplicidade de Relacionamentos
Store
Stocks
1
*
Item
multiplicity of the role
© Nabor C. Mendonça 2001
23
Expressões de Multiplicidade
*
1..*
1..40
5
3, 5, 8

T
zero or more;
"many"
T
one or more
T
one to forty
T
exactly five
T
exactly three,
five or eight
O valor da multiplicidade depende do contexto
–
Ex.: Pessoa Trabalha-para Empresa
© Nabor C. Mendonça 2001
24
Adicionando Relacionamentos ao Modelo
Conceitual do Sistema TV

Relacionamentos fundamentais
–
Venda Processada-em TV
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
© Nabor C. Mendonça 2001
25
Aplicando a Lista de Relacionamentos Típicos
Categoria
Exemplos
A é uma parte física de B
Não Aplicável (N.A.)
A é uma parte lógica de B
Item de Venda - Venda
A está fisicamente contido em B
TV - Loja
A está logicamente contido em B
Item - Loja
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
relatório B
Item de Venda - Venda
A é conhecido/registrado/reportado/capturado em B
Venda (corrente) - TV
Venda (completada) - Loja
© Nabor C. Mendonça 2001
26
Aplicando a Lista de Associações Típicas
Categoria
Exemplos
A é um membro de B
Operador - Loja
A é uma sub-unidade
organizacional de B
N.A.
A usa ou gerencia B
Operador - TV
A se comunica com B
Gerente - TV
Cliente - Operador
A está relacionado com uma
transação B
Cliente - Pagamento
Operador - Pagamento
A é uma transação relacionada
com outra transação B
Pagamento - Venda
A é propriedade de B
TV - Loja
© Nabor C. Mendonça 2001
27
Conceitos e Relacionamentos Candidatos
para o Sistema TV
Records-sale-of
Described-by
1
Product
Specification
Product
Catalog
Contains
1
1..*
1
0..1
Used-by
*
Describes
*
Sales
LineItem
*
Store
Item
Stocks
1
1
1
*
1..*
Logscompleted

Contained-in
1
*
Sale
1
Houses
1..*
POST
Captured-on
1
1
Started-by
1
1
Manager
1
Paid-by
1
1
1
Initiated-by
1
 Records-sales-on
1
1
Initiated-by
Payment
© Nabor C. Mendonça 2001
Customer
1
Cashier
28
Eliminando Relacionamentos Redundantes ou
Desnecessários

Relacionamentos cujo conhecimento não precisam
ser preservados podem ser removidos do modelo
Relacionamento
Comentários
Venda Iniciada-por Operador
Conhecimento não exigido nos
requisitos; derivável da associação
Operador Registra-vendas-em TV
Operador Registra-vendas-em TV
Conhecimento não exigido nos
requisitos.
TV Inicializado-por Gerente
Conhecimento não exigido nos
requisitos.
Venda Iniciada-por Cliente
Conhecimento não exigido nos
requisitos.
Loja Armazena Item
Conhecimento não exigido nos
requisitos.
Item de Venda Registra-venda-de Item
Conhecimento não exigido nos
requisitos.
© Nabor C. Mendonça 2001
29
Preservando Relacionamentos de Compreensão

Preservar apenas relacionamentos 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 relacionamentos de conhecimento, mas
preservar relacionamementos que enriquecem o
entendimento do domínio
© Nabor C. Mendonça 2001
30
Atributos


Atributos descrevem conceitos 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
Sale
attributes
date
startTime : Time
© Nabor C. Mendonça 2001
31
Adicionando Atributos aos Conceitos
Candidatos do Sistema TV
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.
© Nabor C. Mendonça 2001
32
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
© Nabor C. Mendonça 2001
33
Modelo Conceitual Inicial do Sistema TV
Records-sale-of
Described-by
1
Product
Specification
Product
Catalog
Contains
1
1.. *
1
0..1
description
price
UPC
Used-by
*
Describes
*
Sales
LineItem
*
Store
Item
Stocks
/quantity
1
address
name
1
1
*
1.. *
Logscompleted

Contained-in
1
*
Sale
1
Houses
1.. *
POST
time
Paid-by
1
Payment
1
Manager
Started-by
date
1
1
Captured-on
1
1
Initiated-by
1
Customer
1
1
 Records-sales-on
1
Cashier
amount
© Nabor C. Mendonça 2001
34
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)
© Nabor C. Mendonça 2001
35
Glossário Parcial para o Sistema TV
Termo
Categoria
Comentário
Comprar Itens
caso de uso
Descrição do processo de um
cliente comprando itens numa loja.
Especificação-Produto.descrição
:Texto
atributo
Uma descrição sucinta de um item
de venda.
Item
tipo
Um item à venda numa loja.
Pagamento
tipo
Um pagamento em dinheiro.
Especificação-Produto.preço
:Quantidade
atributo
O preço de um item de venda.
Item de Venda.quantidade
:Inteiro
atributo
A quantidade de um tipo particular
de item comprado.
Venda
tipo
Uma transação de venda.
Item de Venda
tipo
Um item particular comprado como
parte de uma venda.
© Nabor C. Mendonça 2001
36
Definindo Diagramas de Seqüência
Um Ciclo de Desenvolvimento
Refin.
Plano
© Nabor C. Mendonça 2001
Sinc.
Artefatos
Análise
Notas
Projeto
Impl.
a. se ainda não feito
b. contínuo
c. opcional
Teste
1. Definir Casos de
Uso Essenciais a
2. Refinar Diag.
Casos de Uso
3. Refinar Modelo
Conceitual
5. Definir Diag.
Seq.
6. Definir Contrat.
de Operação
7. Definir Diag.
Estado
4. Refinar
Glossário
b
c
37
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
system as black box
Buy Items-version 1
Actor
:System
Cashier
Repeat until no
more items
enterItem(UPC, quantity)
endSale()
Text which clarifies
control, logic, iteration,
etc.
makePayment(amount)
May be taken from the
use case.
system event
it triggers a system operation
© Nabor C. Mendonça 2001
38
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
Buy Items-version 1
:System
Cashier
enterItem(UPC, quantity)
system event "enterItem"
it triggers a system operation
likewise named "enterItem"
© Nabor C. Mendonça 2001
39
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 POST:
entrarItem(UPC, quantidade)
encerrarVenda()
fazerPagamento(quantia)

Na UML, representado como operações de um tipo
denominado Sistema:
System
endSale()
enterItem()
makePayment()
© Nabor C. Mendonça 2001
40
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.
© Nabor C. Mendonça 2001
41
Definindo Diagramas de Seqüência

Diagrama de seqüência para o sistema POST com
(parte do) texto do caso de uso Compra Itens Versão 1:
Cashier
For all items, the Cashier records
the UPC and quantity .
On completion of item entry, the
Cashier indicates to the POST
that the sale is complete.
:System
enterItem(UPC, quantity)
endSale()
The Cashier tells the Customer
the total, and the Customer gives
a payment to the Cashier.
The Cashier records the cash
received amount.
© Nabor C. Mendonça 2001
makePayment(amount)
42
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
:System
Cashier
better name
enterItem(UPC, quantity)
enterKeyPressed(UPC, quantity)
worse name
© Nabor C. Mendonça 2001
43
Definindo Contratos de Operação
Um Ciclo de Desenvolvimento
Refin.
Plano
© Nabor C. Mendonça 2001
Sinc.
Artefatos
Análise
Notas
Projeto
Impl.
a. se ainda não feito
b. contínuo
c. opcional
Teste
1. Definir Casos de
Uso Essenciais a
2. Refinar Diag.
Casos de Uso
3. Refinar Modelo
Conceitual
5. Definir Diag.
Seq.
6. Definir Contrat.
de Operação
7. Definir Diag.
Estado
4. Refinar
Glossário
b
c
44
Contratos


Um contrato é um documento que descreve os
compromissos de uma operação
–
Pré e pós-condições de mudanças de estado
–
Para operações de sistema
–
Referências: casos de uso, funções (requisitos)
–
Assinatura
–
Descrição da operação (opcional)
Processo de definição de contratos
1. Identificar operações de sistema a partir do(s)
diagrama(s) de seqüência
2. Para cada operação do diagrama de seqüência,
construir um contrato
© Nabor C. Mendonça 2001
45
Contratos

Exemplo para operação entrarItem (Id, quant)
Pré-condições:
Objeto :Venda existe associado a um :TV, segundo o
relacionamento Registrada-por. O objeto foi criado pela
operação iniciarVenda().
Pós-condições:
Um :Item-de-Venda foi criado e associado com :Venda, segundo Venda
Contém Item-de-Venda
 :Item-de-Venda .quantidade := quant
 O Item-de-Venda foi associado a :Especificação-Produto e :Item, segundo
os relacionamentos Descrito-por e Registra-venda-de, respectivamente.

© Nabor C. Mendonça 2001
46
Contratos e Outros Artefatos
Cashier
USE CASE:
BUYING
ITEMS
Typical Course
Of Events
1. This use
case begins ...
System
Operation: enterItem
enterItem
(upc,
quantity)
endSale()
System
Postconditions:
1. If a new sale, a
new Sale has been
created...
endSale()
enterItem()
makePayment()
Operation: endSale
makePayment
(amount)
Use Case
© Nabor C. Mendonça 2001
System
Sequence
Diagram
Postconditions:
1. ...
System
Operations
Contracts
47
Contratos para o Sistema TV

Exercício: faça os contratos das demais operações
do sistema TV
© Nabor C. Mendonça 2001
48
Utilidade dos Contratos

A principal finalidade dos contratos é validar o
modelo conceitual
–
Faltando entidade?
Faltando atributo?
Atributo inútil?
–
–


Faltando relacionamento?
Entidade inútil?
Em conseqüência, o modelo conceitual pode ser
modificado / refinado
Exemplo: somente ao fazer o contrato
TerminarVenda(), descobriu-se a necessidade de
um novo atributo booleano Terminou, para o
sistema TV
© Nabor C. Mendonça 2001
49