© Nabor C. Mendonça 2001 1 Análise Orientada a Objeto com a metodologia (R)UP + UML Modelo...
Transcript of © Nabor C. Mendonça 2001 1 Análise Orientada a Objeto com a metodologia (R)UP + UML Modelo...
© Nabor C. Mendonça 2001 1
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 2
Construindo um Modelo Conceitual
a. se ainda não feitob. contínuoc. opcional
2. Refinar Diag. Casos de Uso
3. Refinar ModeloConceitual
4. Refinar Glossário b
6. Definir Contrat.de Operação
1. Definir Casos de Uso Essenciais a
5. Definir Diag.Seq.
7. Definir Diag.Estado c
Notas
Sinc.Artefatos Análise Projeto TesteRefin.
Plano Impl.
Um Ciclo de Desenvolvimento
© Nabor C. Mendonça 2001 3
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 4
Modelo Conceitual para o Sistema TV
Diagrama parcial
POST
Item
Store
addressname
Sale
datetime
Payment
amount
SalesLineItem
quantity
Stocked-in
*
Houses
1..*
Contained-in
1..*
Records-sale-of
0..1
Paid-by
1
1
1
1
1
1
1
1
Captured-on
Concept
Association
Attributes
© Nabor C. Mendonça 2001 5
Idéias, coisas, ou objetos do mundo real
Não representam componentes de software!
Conceitos
Loja TV Venda
datahora
BDdeVendas
evitar
Venda
datahora
imprimir()
evitar
Artefato de software; não fazparte do modelo conceitual
Classe de software; não fazparte do modelo conceitual
© Nabor C. Mendonça 2001 6
Caso de Uso e Modelo de Domínio
© Nabor C. Mendonça 2001 7
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 8
Conceitos Típicos
Categoria
Especificação, projeto, ou descrição de coisas
Especificação de produto
Descrição de vôo
Objeto físico ou tangível Terminal de ponto-de-venda
Avião
Lugares Loja
Aeroporto
Transações Venda, Pagamento
Reserva
Exemplos
Itens de transação Itens de venda
Parcelas de pagamento
Container de coisas Loja
Avião
Papéis de pessoas Operador
Piloto
© Nabor C. Mendonça 2001 9
Conceitos Típicos
Coisas em um container Item
Passageiro
Sistemas externos Serviço de crédito
Controle de tráfego aéreo
Nomes abstratos Fome
Aracnofobia
Eventos Venda, Assalto, Reunião
Vôo, Decolagem
Organizações Departamento de vendas
Companhia aérea
Regras e políticas Política de devolução
Política de cancelamento
Categoria Exemplos
© Nabor C. Mendonça 2001 10
Conceitos Típicos
Catálogos 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
Manuais, livros Manual do empregado
Manual de reparos
Instrumentos e serviços financeiros Linha de crédito
Ações
Categoria Exemplos
© Nabor C. Mendonça 2001 11
Identificando Conceitos e Atributos em Casos de Uso
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 identi-ficador de cada item.Se há mais de um do mesmo item, o Operador também pode informar a quantidade.
3. Determina o preço do item e adiciona informação sobre o item à transação de venda em anda-mento.Mostra a descrição e o preço do item corrente.
© Nabor C. Mendonça 2001 12
Conceitos Candidatos para o Sistema TV
Conceitos restritos ao caso de uso Processar Venda - Versão 1
StorePOST SaleItem
Payment
SalesLineItem
Cashier Customer Manager
ProductCatalog
ProductSpecification
© Nabor C. Mendonça 2001 13
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 14
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 15
Conceito e Atributo de Conceito
Vôo Aeroporto
nome
Vôo
destinoou... ?
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?
parte_de
chega_a
1..*
1..*
© Nabor C. Mendonça 2001 16
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.:
Conceitos de Especificação ou Descrição
Item
descriçãopreçonúmero serialUPC
Especificação-ProdutoItem
Número serial
Descreve1 *
descriçãopreçoUPC
pior melhor
© Nabor C. Mendonça 2001 17
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 18
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 19
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
SalePOST Records-current 11
association name multiplicity
-"direction reading arrow"-it has no meaning except to indicate direction of reading the association label-often excluded
© Nabor C. Mendonça 2001 20
Relacionamentos Típicos
Categoria
A é uma parte lógica de B Item de Venda - Venda
Escala - Vôo
A é uma parte física de B Gaveta - TV
Asa - Avião
A está fisicamente contido em B TV - Loja
Passageiro - Avião
A está logicamente contido em B Descrição-Item - Catálogo
Vôo - Roteiro de Viagem
Exemplos
A é uma descrição de B Descrição-Item - Item
Descrição-Vôo - Vôo
A é conhecido/registrado/repor-tado/captado em B
Venda - TV
Reserva - Terminal de Reserva
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
© Nabor C. Mendonça 2001 21
Relacionamentos Típicos
Categoria
A é uma sub-unidade organizacional de B
Departamento - Loja
Manutenção - Companhia Aérea
A é um membro de B Operador - Loja
Piloto - Companhia Aérea
A usa ou gerencia B Operador - TV
Piloto - Avião
A se comunica com B Cliente - Operador
Agente de Reserva - Passageiro
Exemplos
A está relacionado com uma transação B
Cliente - Pagamento
Passageiro - Bilhete
A é propriedade de B TV - Loja
Avião - Companhia Aérea
A é uma transação relacionada com outra transação B
Pagamento - Venda
Reserva - Cancelamento
© Nabor C. Mendonça 2001 22
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 23
Multiplicidade de Relacionamentos
ItemStore Stocks
*
multiplicity of the role
1
© Nabor C. Mendonça 2001 24
O valor da multiplicidade depende do contexto– Ex.: Pessoa Trabalha-para Empresa
Expressões de Multiplicidade
zero or more;"many"
one or more
one to forty
exactly five
T
T
T
T
*
1..*
1..40
5
T3, 5, 8 exactly three,
five or eight
© Nabor C. Mendonça 2001 25
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 26
Aplicando a Lista de Relacionamentos Típicos
Categoria
A é uma parte lógica de B Item de Venda - Venda
A é uma parte física de B Não Aplicável (N.A.)
A está fisicamente contido em B TV - Loja
Item - Loja
A está logicamente contido em B Especificação-Produto - Catálogo
Catálogo - Loja
Exemplos
A é uma descrição de B Especificação-Produto - Item
A é conhecido/registrado/repor-tado/capturado em B
Venda (corrente) - TV
Venda (completada) - Loja
A é um item de uma transação ou relatório B
Item de Venda - Venda
© Nabor C. Mendonça 2001 27
Aplicando a Lista de Associações Típicas
Categoria
A é uma sub-unidade organizacional de B
N.A.
A é um membro de B Operador - Loja
A usa ou gerencia B Operador - TV
Gerente - TV
A se comunica com B Cliente - Operador
Exemplos
A está relacionado com uma transação B
Cliente - Pagamento
Operador - Pagamento
A é propriedade de B TV - Loja
A é uma transação relacionada com outra transação B
Pagamento - Venda
© Nabor C. Mendonça 2001 28
Conceitos e Relacionamentos Candidatos para o Sistema TV
POST
ItemStore
Sale
Payment
SalesLineItem
CashierCustomer
Manager
ProductCatalog
ProductSpecification
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Described-by
*
Records-sale-of
0..1
Started-by
Paid-by Initiated-by
Logs-completed
*
Records-sales-on
1
1
1
1
1
1
11
1
1
1
1
1
1
1
1 1
1
Initiated-by
1
1
© Nabor C. Mendonça 2001 29
Eliminando Relacionamentos Redundantes ou Desnecessários
Relacionamentos cujo conhecimento não precisam ser preservados podem ser removidos do modelo
Relacionamento
Operador Registra-vendas-em TV Conhecimento não exigido nos requisitos.
Venda Iniciada-por Operador Conhecimento não exigido nos requisitos; derivável da associação Operador Registra-vendas-em TV
TV Inicializado-por Gerente Conhecimento não exigido nos requisitos.
Venda Iniciada-por Cliente Conhecimento não exigido nos requisitos.
Comentários
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 30
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 31
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
datestartTime : Time
attributes
© Nabor C. Mendonça 2001 32
Adicionando Atributos aos Conceitos Candidatos do Sistema TV
Conceito
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.
Pagamento quantia—Para determinar se pagamento é suficiente e calcular troco.
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.
Atributos e justificativa
Loja nome, endereço—Para imprimir no recibo.
© Nabor C. Mendonça 2001 33
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
/quantity
ItemRecords-sale-of0..1 1..*
derived attribute fromthe multiplicity value
© Nabor C. Mendonça 2001 34
Modelo Conceitual Inicial do Sistema TV
POST
ItemStore
addressname
Sale
date
time
Payment
amount
SalesLineItem
/quantity
CashierCustomer
Manager
ProductCatalog
ProductSpecification
descriptionpriceUPC
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Described-by
*
Records-sale-of
0..1
Started-by
Paid-by Initiated-by
Logs-completed
*
Records-sales-on
1
1
1
1
1
1
11
1
1
1
1
1
1
1
1 1
1
© Nabor C. Mendonça 2001 35
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 36
Glossário Parcial para o Sistema TV
Categoria
atributo Uma descrição sucinta de um item de venda.
caso de uso Descrição do processo de um cliente comprando itens numa loja.
tipo Um item à venda numa loja.
tipo Um pagamento em dinheiro.
Comentário
atributo O preço de um item de venda.
Termo
Especificação-Produto.descrição :Texto
Comprar Itens
Item
Pagamento
Especificação-Produto.preço :Quantidade
atributo A quantidade de um tipo particular de item comprado.
tipo Uma transação de venda.
tipo Um item particular comprado como parte de uma venda.
Item de Venda.quantidade :Inteiro
Venda
Item de Venda
© Nabor C. Mendonça 2001 37
Definindo Diagramas de Seqüência
a. se ainda não feitob. contínuoc. opcional
2. Refinar Diag. Casos de Uso
3. Refinar ModeloConceitual
4. Refinar Glossário b
6. Definir Contrat.de Operação
1. Definir Casos de Uso Essenciais a
5. Definir Diag.Seq.
7. Definir Diag.Estado c
Notas
Sinc.Artefatos Análise Projeto TesteRefin.
Plano Impl.
Um Ciclo de Desenvolvimento
© Nabor C. Mendonça 2001 38
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
enterItem(UPC, quantity)
:SystemCashier
endSale()
Repeat until nomore items
makePayment(amount)
Text which clarifiescontrol, logic, iteration,etc.
May be taken from theuse case.
ActorBuy Items-version 1
system as black box
system event
it triggers a system operation
© Nabor C. Mendonça 2001 39
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
enterItem(UPC, quantity)
Cashier
Buy Items-version 1
system event "enterItem"
it triggers a system operationlikewise named "enterItem"
:System
© Nabor C. Mendonça 2001 40
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:
Representando Operações
System
endSale()enterItem()makePayment()
© Nabor C. Mendonça 2001 41
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 42
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:
For all items, the Cashier recordsthe UPC and quantity .
On completion of item entry, theCashier indicates to the POSTthat the sale is complete.
The Cashier tells the Customerthe total, and the Customer givesa payment to the Cashier.
The Cashier records the cashreceived amount.
enterItem(UPC, quantity)
Cashier
endSale()
makePayment(amount)
:System
© Nabor C. Mendonça 2001 43
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
enterItem(UPC, quantity)
enterKeyPressed(UPC, quantity)
Cashier
worse name
better name
:System
© Nabor C. Mendonça 2001 44
Definindo Contratos de Operação
a. se ainda não feitob. contínuoc. opcional
2. Refinar Diag. Casos de Uso
3. Refinar ModeloConceitual
4. Refinar Glossário b
6. Definir Contrat.de Operação
1. Definir Casos de Uso Essenciais a
5. Definir Diag.Seq.
7. Definir Diag.Estado c
Notas
Sinc.Artefatos Análise Projeto TesteRefin.
Plano Impl.
Um Ciclo de Desenvolvimento
© Nabor C. Mendonça 2001 45
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 46
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().
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.
Pós-condições:
© Nabor C. Mendonça 2001 47
Contratos e Outros Artefatos
Cashier System
enterItem(upc,
quantity)
endSale()
makePayment(amount)
USE CASE:BUYINGITEMS
Typical CourseOf Events
1. This usecase begins ...
Use Case SystemSequenceDiagram
Operation: enterItem
Postconditions:1. If a new sale, anew Sale has beencreated...
Operation: endSale
Postconditions:1. ...
Contracts
System
endSale()enterItem()makePayment()
SystemOperations
© Nabor C. Mendonça 2001 48
Contratos para o Sistema TV
Exercício: faça os contratos das demais operações do sistema TV
© Nabor C. Mendonça 2001 49
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