análise e projeto orientados a objeto com uml e padrões
Post on 01-Jan-2016
27 Views
Preview:
DESCRIPTION
TRANSCRIPT
Prof. Msc. Emerson Silas Dória 1
Análise e Projeto Orientados a Objetocom UML e Padrões
Parte III Análise (1)
Prof. Msc. Emerson Silas Dória 2
Construindo um Modelo Conceitual
Ciclo deDesenv. 1
Sinc.Artefatos
Análise Projeto TesteRefin.Plano
Impl.
Ciclo deDesenv. 2 ...
ConstruçãoPlan. &Elaboração
Implantação
Prof. Msc. Emerson Silas Dória 3
Construindo um Modelo Conceitual
Sinc.Artefatos
Análise Projeto TesteRefin.Plano
Impl.
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
a. se ainda não feitob. contínuoc. opcional
Notas
Prof. Msc. Emerson Silas Dória 4
Modelo Conceitual Artefato mais importante da AOO
Representa conceitos relevantes (do ponto de vista do projetista) do domínio do problema
Na UML, ilustrado com diagramas de estruturas estáticas contendo: Conceitos Associações entre conceitos Atributos de conceitos
Prof. Msc. Emerson Silas Dória 5
Modelo Conceitual Parcial para o Sistema POST
POST
Item
Depósito
endereçonome
Venda
datahora
Pagamento
quantia
Item de Venda
quantidade
Armazenado-em
Aloja
Contido-em
1..*
Registra-venda-de
0..1
Pago-por
1
1
1
1
1
1
1
1
Capturado-no
Conceito
Associação
Atributos
*
1..*
Prof. Msc. Emerson Silas Dória 6
Conceitos
BancodeDados Artefato de software;não faz parte do modeloevita
r
Classe de software ; não faz parte do modelo conceitual
Sale
datahora
imprime()
evitar
Idéias, coisas, ou objetos do mundo real
Não representam componentes de software!
Prof. Msc. Emerson Silas Dória 7
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
Prof. Msc. Emerson Silas Dória 8
Conceitos TípicosCategoria Exemplos
Objetos físicos ou tangíveis POSTAvião
Especificação de projetos ou descrição de coisas
Especificação de produtoDescrição de vôo
Lugares LojaAeroporto
Transações Venda, PagamentoReserva
Itens de transação Itens de venda
Papéis de pessoas OperadorPiloto
Contêiner de outras coisas Depósito, Armário, Aeronave
Prof. Msc. Emerson Silas Dória 9
Conceitos TípicosCategoria Exemplos
Coisas em um container ItemPassageiro
Sistemas externos Sistema de Autorização de Crédito
Conceitos e substantivos abstratos
FomeAerofobia
Organizações Departamento de vendasCompanhia aérea
Eventos Venda, Roubo, ReuniãoVôo, Decolagem
Regras e políticas Política de reembolsoPolítica de cancelamento
Prof. Msc. Emerson Silas Dória 10
Identificando Conceitos e Atributos em Descrições TextuaisSeqüência Típica de Eventos
Ação do Ator Resposta do Sistema
2. O Operador registra o identificador de cada item.Se houver mais de um exemplar 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 corrente.Mostra a descrição e o preço do item corrente.
1. Este caso de uso começa quando um Cliente chega no caixa (equipado com um POST) com itens que deseja comprar.
Usar com cuidado! Linguagens naturais: imprecisão e ambigüidade
Prof. Msc. Emerson Silas Dória 11
Conceitos Candidatos para o Sistema POST
Conceitos restritos ao caso de uso Comprar Itens - Versão expandida
LojaPost VendaItem
Pagamento
Item de Venda
Operador Cliente Gerente
Catálogo Produtos
Especificação de
Produtos
Prof. Msc. Emerson Silas Dória 12
Criando um Modelo Conceitual Passos sugeridos:
Liste os conceitos candidatos, usando a Lista de Categorias de Conceitos e a identificação de substantivos relacionados com os requisitos que estão sendo considerados;
Desenhe-os em um modelo conceitual; Acrescente as associações necessárias para
registrar os relacionamentos para os quais existe a necessidade de preservar alguma memorização *
Acrescente os atributos necessários para completar os requisitos de informação *
* serão apresentados posteriormente
Prof. Msc. Emerson Silas Dória 13
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 Atributos normalmente correspondem a um
texto ou número no mundo real
Criando um Modelo Conceitual
Prof. Msc. Emerson Silas Dória 14
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
é excluído reduz informações redundantes ou
duplicadas Muito comum no domínio de produtos e
vendas
Conceitos de Especificação ou de Descrição
Item
descriçãopreçonúmero serialUPC
EspecificaçãoProdutoItem
Número serial
Descreve1 *
descriçãopreçoUPC
pior melhor
Prof. Msc. Emerson Silas Dória 15
outro exemplo:
Conceitos de Especificação ou de Descrição
pior
melhor
Vôo
DataNúmerohora
Aeroporto
nome
Voa-para
1*
Vôo
datahora
Descrição-Vôo
número
Aeroporto
nome
Descreve-vôo-para
Descrito-por
1*
1
*
Prof. Msc. Emerson Silas Dória 16
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”
Prof. Msc. Emerson Silas Dória 17
Associações Uma associação é um relacionamento
entre conceitos que indica uma conexão com significado e interesse
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 Entre quais objetos necessitamos ter
alguma memória de um relacionamento?
Prof. Msc. Emerson Silas Dória 18
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
cardinalidadeEspecificaçãoProduto
Item
Númeroserial
descreve
1 *DescriçãoPreçoUPC
Prof. Msc. Emerson Silas Dória 19
Associações Típicas(*) alta prioridadeCategoria Exemplos
A é uma parte física de B (*) Gaveta - POSTAsa – Avião
A é uma parte lógica de B (*) Item de Venda - VendaEscala – Vôo
A está fisicamente contido em/sobre B (*)
POST - LojaPassageiro – Avião
A está logicamente contido em B (*)
Descrição-Item - CatálogoVôo - Roteiro de Viagem
A é uma descrição de B Descrição-Item - ItemDescrição-Vôo – Vôo
A é um item de uma transação ou relatório B
Item de Venda - VendaOpção de Reserva – Reserva
A é conhecido/registrado/repor-tado/capturado em B (*)
Venda - POSTReserva - Terminal de Reserva
Prof. Msc. Emerson Silas Dória 20
Associações TípicasCategoria Exemplos
A é um membro de B Operador - LojaPiloto - Companhia Aérea
A é uma sub-unidade organizacional de B
Departamento - LojaManutenção - Companhia Aérea
A usa ou gerencia B Operador - POSTPiloto – Avião
A se comunica com BCliente - OperadorAgente de Reserva – Passageiro
A está relacionado com uma transação B
Cliente - PagamentoPassageiro – Bilhete
A é uma transação relacionada com outra transação B
Pagamento - VendaReserva – Cancelamento
A é possuído por B POST - LojaAvião - Companhia Aérea
(*) alta prioridade
Prof. Msc. Emerson Silas Dória 21
Identificando Associações Regras úteis:
Focaliza-se naquelas associações para as quais o conhecimento do relacionamento necessita ser preservado por algum tempo;
É mais importante identificar conceitos do que identificar associações;
O excesso de associações tende a tornar um modelo conceitual confuso, em vez de esclarecê-lo.
Prof. Msc. Emerson Silas Dória 22
Cada ponta de um associação é chamada de um “papel”
Um papel pode ter: Nome Expressão de multiplicidade Navegabilidade
Papéis de uma Associação
ItemLoja Estoca
*1
Prof. Msc. Emerson Silas Dória 23
Adicionando Associações ao Modelo Conceitual do POST Relacionamentos fundamentais
Venda Capturada-em POST 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
Prof. Msc. Emerson Silas Dória 24
Aplicando a lista de Associações Típicas
Categoria Sistema POST
A é uma parte física de B (*) Não aplicável
A é uma parte lógica de B (*) Item de Venda – Venda
A está fisicamente contido em/sobre B (*)
POST – LojaItem – Loja
A está logicamente contido em B (*)EspecificaçãoProduto – CatálogoProdutos CatálogoProdutos – Loja
A é uma descrição de B EspecificaçãoProduto – Item
A é um item de uma transação ou relatório B ItemVenda – Venda
A é conhecido/registrado/repor-tado/capturado em B (*)
Venda (corrente) – POSTVendas (completada) – Loja
Prof. Msc. Emerson Silas Dória 25
Aplicando a lista de Associações Típicas
Categoria Sistema POST
A é um membro de B Operador - Loja
A é uma sub-unidade organizacional de B Não aplicável
A usa ou gerencia B Operador – POSTGerente – POST
A se comunica com B Cliente – Operador
A está relacionado com uma transação B
Cliente – PagamentoOperador – Pagamento
A é uma transação relacionada com outra transação B Pagamento – Venda
A é possuído por B POST – Loja
Prof. Msc. Emerson Silas Dória 26
Conceitos e Associações candidatos para o POST
POST
ItemLoja
Venda
Pagamento
Item Venda
OperadorCliente
Gerente
Catálogode Produtos
Especificaçãode Produto
estoca
*
possui
1..*
usado-por
*
contém1..*
descreve
*
capturada-por
contido-em
1..*
descrito-por
*
registra-venda-de
0..1
iniciado-por
paga-por iniciada-por
log-vendas realizadas
*
registra-venda-no
1
1
1
1
1
1
11
1
1
1
1
1
1
1
1 1
1
iniciada-por
1
1
Prof. Msc. Emerson Silas Dória 27
Eliminando associações redundantes ou desnecessárias Associações cujo conhecimento não precisa
ser preservado podem ser removidas do modelo:Associação Consideração
Venda iniciada-por OperadorConhecimento não exigido nos requisitos; derivável da associação Operador registra-vendas-em POST.
Operador registra-vendas-em POST Conhecimento não exigido nos requisitos.
POST 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.
ItemVenda registra-venda-de Item Conhecimento não exigido nos requisitos.
Prof. Msc. Emerson Silas Dória 28
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: Exemplo: 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 ou informação;
Regra geral é enfatizar associações de conhecimento, mas preservar associações que enriquecem o entendimento do domínio
Prof. Msc. Emerson Silas Dória 29
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
Venda
Atributos datahora:data
Prof. Msc. Emerson Silas Dória 30
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”)Operador
nomePOSTcorrente
pior
Operador
nome
POST
número
usamelhor
1 1
Prof. Msc. Emerson Silas Dória 31
Podem ser representados diretamente no modelo conceitual
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
Atributos Não-Primitivos
Especificação de Produto
upc : UPC
Loja
endereço:Endereço
Prof. Msc. Emerson Silas Dória 32
Adicionando Atributos aos Conceitos Candidatos do Sistema POST
Conceito Atributos e justificativa
Pagamentoquantia - Para determinar se pagamento é suficiente e calcular troco.
EspecificaçãoProduto
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.
ItemVendaquantidade - Para registrar a quantidade digitada quando há mais de um do mesmo item.
Loja nome, endereço - Para imprimir no recibo.
Prof. Msc. Emerson Silas Dória 33
Atributo Derivado Um atributo derivado é um atributo cujo
valor pode ser deduzido a partir de outras informações Ex.: quantidade em Item Venda - pode ser
deduzido a partir da multiplicidade da associação entre Item Venda e Item
Na UML, indicado com o símbolo “/”
Prof. Msc. Emerson Silas Dória 34
Modelo Conceitual Inicial do POST
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
Um item da venda pode estar associado a vários
itens, portanto, quantidade pode ser
obtida através da multiplicidade do relacionamento
ItemVenda e Item
Prof. Msc. Emerson Silas Dória 35
Definindo Diagramas de Seqüência (Comportamento do Sistema)
Sinc.Artefatos
Análise Projeto TesteRefin.Plano
Impl.
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
a. se ainda não feitob. contínuoc. opcional
Notas
Prof. Msc. Emerson Silas Dória 36
Comportamento do Sistema Um diagrama de seqüência do sistema é uma
figura que mostra, para o particular cenário de uso, os eventos que os atores externos geram, sua ordem e os eventos entre sistemas;
Todos os sistemas são tratados com uma caixa-preta; a ênfase do diagrama está nos eventos que atravessam a fronteira do sistema entre atores e outros sistemas;
Um diagrama de seqüência do sistema deve ser feito para a seqüência típica de eventos do caso de uso.
Prof. Msc. Emerson Silas Dória 37
Diagrama de Seqüência do Sistema (Comportamento do Sistema)
EntrarItem(UPC,quantidade)
:SistemaOperador
TerminarVenda()
Repetir até nãoter mais itens
RegistrarPagamento(quantia)Texto que esclarece o controle, a lógica, a iteração, etc.Pode se obtido do caso de uso.
AtorComprar Itens – versão 1
O sistema como umacaixa-preta
Evento de sistema dispara uma operação de sistema.
Prof. Msc. Emerson Silas Dória 38
Eventos e Operações Um evento de sistema é um evento
externo de entrada gerado por um ator para um sistema Inicia uma operação de resposta do sistema
Uma operação de sistema é uma operação executada em resposta a um evento de sistema
O nome do evento e da operação são idênticos; evento é o estimulo nomeado, e a operação é a resposta
Prof. Msc. Emerson Silas Dória 39
Eventos e Operações
EntrarItem(UPC,quantidade)
:SistemaOperador
Comprar Itens – versão 1
evento de sistema “EntrarItem”ele dispara uma operação de sistema, da mesma maneira, chamada “EntrarItem”
Prof. Msc. Emerson Silas Dória 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) TerminarVenda() RegistrarPagamento(quantia)
Na UML, representado como operações de um tipo denominado Sistema
Representando Operações
Sistema
EntrarItem(UPC, quantidade)
TerminarVenda()
RegistrarPagamento(quantia)
Prof. Msc. Emerson Silas Dória 41
Definindo Diagramas de Seqüência (Comportamento do Sistema)
Regras úteis1. 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 e ilustrar os eventos de sistema que cada ator gera.
4. Opcionalmente, incluir o texto do caso de uso à esquerda do diagrama.
Prof. Msc. Emerson Silas Dória 42
Definindo Diagramas de Seqüência (Comportamento do Sistema)
EntrarItem(UPC,quantidade)
:SistemaOperador
TerminarVenda()
RegistrarPagamento(quantia)
Comprar Itens – versão 1
2. O Operador registra o identificador de cada item.Se houver mais de um exemplar do mesmo item, o Operador também pode informar a quantidade.
4. Após processar o último item, o Operador indica ao POST que a entrada de itens terminou.
6. O Operador informa o total ao Cliente.
1. Este caso de uso começa quando um Cliente chega no caixa (equipado com um POST) com itens que deseja comprar.
Identifique os eventos do sistemaque cada ator gera.
Registre as operações de sistema requeridas.
Prof. Msc. Emerson Silas Dória 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.: TerminarVenda em vez de PressionarTeclaEnter
Expressar intenção no nível mais alto de abstração
Ex.: RegistrarPagamento em vez de EntrarQuantia
Prof. Msc. Emerson Silas Dória 44
Definindo Contratos de Operação
Sinc.Artefatos
Análise Projeto TesteRefin.Plano
Impl.
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
a. se ainda não feitob. contínuoc. opcional
Notas
Prof. Msc. Emerson Silas Dória 45
Contratos Um contrato é um documento que
descreve o que uma operação se compromete a atingir: Estilo declarativo Pré e pós-condições de mudanças de
estado Para métodos, classes, ou operações
gerais de sistema
Prof. Msc. Emerson Silas Dória 46
Contratos Exemplo para operação EntrarItem
Contrato: EntrarItem (UCP:número, quantidade:inteiro)
Responsabilidade: Registra venda de um item e o adiciona à venda corrente. Mostra descrição e preço do item
Tipo: Sistema
Referência Cruzada: Funções: R1.1, R1.3, R1.9Caso de Uso: Comprar Itens
Notas: Usar acesso rápido ao BD
Exceções: Se UPC inválido, indicar erro
Saída:
Pré-condições: UPC é conhecido do sistema
Prof. Msc. Emerson Silas Dória 47
Contratos Exemplo para operação EntrarItem
Pós-condições: Se for uma nova venda, uma Venda foi criada (criação de instância); Se for uma nova venda, a nova Venda foi associada ao POST (formada uma associação); Um ItemVenda foi criado (criação de instância); O ItemVenda foi associado à Venda (formada uma associação); ItemVenda.quantidade recebeu o valor de quantidade (modificação de atributo); O ItemVenda foi associado a uma EspecificaçãoDeProduto, baseada numa correspondência com o UPCs (formada uma associação).
Prof. Msc. Emerson Silas Dória 48
Seções de um Contrato
Contrato: Nome e parâmetros da operação
Responsabilidade: Descrição informal das responsabilidades da operação
Tipo: Nome do tipo (conceito, classe, interface)
Referência Cruzada: Número de referência de funções, casos de uso, etc.
Notas: Notas de projeto, algoritmos, etc.
Exceções: Casos excepcionais
Saída: Saídas não-IU, tais como mensagens ou registros enviados para fora do sistema
Pré-condições: Hipóteses e assertivas sobre o estado do sistema antes da execução da operação
Prof. Msc. Emerson Silas Dória 49
Como Fazer um Contrato Regras úteis:
1. Identificar operações de sistema a partir dos diagramas de seqüência do sistema;
2. Para cada operação construa 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 de forma declarativa as mudanças de estado que ocorrem aos objetos do modelo conceitual;
5. Para descrever as Pós-condições considere as seguintes categorias:
Criação e remoção de instâncias Modificação de atributos Associações formadas e desfeitas (erro mais comum!)
Prof. Msc. Emerson Silas Dória 50
Contratos e Outros Artefatos
Caso de Uso:Comprar Itens
Sequência Tipica de Eventos
1. Este caso de uso começa...
Operação: EntrarItemPós-Condições:1. Se tSe for uma nova venda, uma Venda foi criada (criação de instância);Sistema
EntrarItem(UPC, quantidade)
TerminarVenda()
RegistrarPagamento(quantia)
EntrarItem(UPC,quantidade)
:SistemaOperador
TerminarVenda()
RegistrarPagamento(quantia)
Caso de Uso DSS Operações do Sistema Contratos
Operação: TerminarVendaPós-Condições:1. Venda.Completada recebe o valor...
Prof. Msc. Emerson Silas Dória 51
Pós-condições 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
Prof. Msc. Emerson Silas Dória 52
Contratos para o POST Operação TerminarVendaContrato: TerminarVenda()
Responsabilidade: Registrar que é o fim da entrada de itens de venda e exibir o total da venda
Tipo: Sistema
Referência Cruzada: Funções: R1.2Caso de Uso: Comprar Itens
Notas:
Exceções: Se uma venda não está em andamento, indicar o erro
Saída:
Pré-condições: UPC é conhecido do sistema
Prof. Msc. Emerson Silas Dória 53
Contratos para o POST Operação TerminarVendaPós-condições: Venda.Completada recebe o valor true (modificação
de atributos).
Prof. Msc. Emerson Silas Dória 54
Contratos para o POST Operação RegistrarPagamento:Contrato: RegistrarPagamento(quantia:numero)Responsabilidade: Registrar o pagamento, calcular o troco e imprimir
recibo.Tipo: SistemaReferência Cruzada: Funções: R2.1
Caso de Uso: Comprar ItensNotas:
Exceções: Se a venda não está completa, indicar um erroSe a quantia for menor que o total da venda, indicar um erro
Saída:
Pré-condições:
Prof. Msc. Emerson Silas Dória 55
Contratos para o POST Operação RegistrarPagamento:Pós-condições: Um Pagamento foi criado (criação de instância);
Pagamento.quantiaFornecida recebeu o valor da quantia (modificação de atributos); O Pagamento foi associado à Venda (relacionamento foi formado); A Venda foi associada à Loja, para acrescentá-la ao histórico de vendas completadas (relacionamento foi formado).
Prof. Msc. Emerson Silas Dória 56
Contratos para o POST Operação InicializarContrato: Inicializar()
Responsabilidade: Inicializar o sistema
Tipo: Sistema... ...
Pós-condições: Uma Loja, CatálogodeProdutos, EspecificaçõesDeProdutos foram criadas (criação de instâncias); CatálogodeProdutos foi associado a EspecificaçõesDeProdutos (associação formada); Loja foi associada a CatálogodeProdutos (associação formada);
Prof. Msc. Emerson Silas Dória 57
Contratos para o POST Operação Inicializar
Pós-condições: Loja foi associada POST (associação formada); POST associado a CatálogodeProdutos (associação formada).
Prof. Msc. Emerson Silas Dória 58
Diagrama da UML Consulte na página
www2.unoeste.br/~emerson documentos específicos com os detalhes sintáticos da UML.
top related