A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Análise e Projeto Orientados a Objeto com UML e Padrões

Apresentações semelhantes


Apresentação em tema: "Análise e Projeto Orientados a Objeto com UML e Padrões"— Transcrição da apresentação:

1 Análise e Projeto Orientados a Objeto com UML e Padrões
Parte III Análise (1) Prof. Msc. Emerson Silas Dória

2 Construindo um Modelo Conceitual
Plan. & Elaboração Construção Implantação Ciclo de Desenv. 1 Ciclo de Desenv. 2 ... Refin. Plano Sinc. Artefatos Análise Projeto Impl. Teste Prof. Msc. Emerson Silas Dória

3 Construindo um Modelo Conceitual
Sinc. Artefatos Análise Projeto Teste Refin. Plano Impl. 2. Refinar Diag. Casos de Uso 3. Refinar Modelo Conceitual 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 feito b. contínuo c. opcional Notas Prof. Msc. Emerson Silas Dória

4 Prof. Msc. Emerson Silas Dória
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
Item Depósito endereço nome Venda data hora Pagamento quantia Item de Venda quantidade Armazenado-em Aloja Contido-em 1..* Registra-venda-de 0..1 Pago-por 1 Capturado-no4 Conceito Associação Atributos * Prof. Msc. Emerson Silas Dória

6 Prof. Msc. Emerson Silas Dória
Conceitos Idéias, coisas, ou objetos do mundo real Não representam componentes de software! BancodeDados Artefato de software; não faz parte do modelo evitar Classe de software ; não faz parte do modelo conceitual Sale data hora imprime() evitar 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 Prof. Msc. Emerson Silas Dória
Conceitos Típicos Categoria Exemplos Objetos físicos ou tangíveis POST Avião Especificação de projetos ou descrição de coisas Especificação de produto Descrição de vôo Lugares Loja Aeroporto Transações Venda, Pagamento Reserva Itens de transação Itens de venda Papéis de pessoas Operador Piloto Contêiner de outras coisas Depósito, Armário, Aeronave Prof. Msc. Emerson Silas Dória

9 Prof. Msc. Emerson Silas Dória
Conceitos Típicos Categoria Exemplos Coisas em um container Item Passageiro Sistemas externos Sistema de Autorização de Crédito Conceitos e substantivos abstratos Fome Aerofobia Organizações Departamento de vendas Companhia aérea Eventos Venda, Roubo, Reunião Vôo, Decolagem Regras e políticas Política de reembolso Política de cancelamento Prof. Msc. Emerson Silas Dória

10 Identificando Conceitos e Atributos em Descrições Textuais
Seqüência Típica de Eventos Ação do Ator Resposta do Sistema 1. Este caso de uso começa quando um Cliente chega no caixa (equipado com um POST) com itens que deseja comprar. 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. Usar com cuidado! Linguagens naturais: imprecisão e ambigüidade Prof. Msc. Emerson Silas Dória

11 Conceitos Candidatos para o Sistema POST
Item Loja Venda Item de Venda Operador Cliente Gerente Pagamento Catálogo Produtos Especificação de Produtos Conceitos restritos ao caso de uso Comprar Itens - Versão expandida 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 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 Atributos normalmente correspondem a um texto ou número no mundo real Prof. Msc. Emerson Silas Dória

14 Conceitos de Especificação ou de 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 é excluído reduz informações redundantes ou duplicadas Muito comum no domínio de produtos e vendas Item descrição preço número serial UPC EspecificaçãoProduto Número serial Descreve 1 * pior melhor Prof. Msc. Emerson Silas Dória

15 Conceitos de Especificação ou de Descrição
outro exemplo: Vôo Voa-para Aeroporto Data Número hora pior * 1 nome Vôo Descrito-por Descrição-Vôo melhor data hora * 1 número * Descreve-vôo-para 1 Aeroporto nome Prof. Msc. Emerson Silas Dória

16 Prof. Msc. Emerson Silas Dória
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 Prof. Msc. Emerson Silas Dória
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 cardinalidade EspecificaçãoProduto Item Númeroserial descreve 1 * Descrição Preço UPC Prof. Msc. Emerson Silas Dória

19 Prof. Msc. Emerson Silas Dória
Associações Típicas Categoria Exemplos A é uma parte física de B (*) Gaveta - POST Asa – Avião A é uma parte lógica de B (*) Item de Venda - Venda Escala – Vôo A está fisicamente contido em/sobre B (*) POST - Loja Passageiro – Avião A está logicamente contido em B (*) 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 ou relatório B Opção de Reserva – Reserva A é conhecido/registrado/repor-tado/capturado em B (*) Venda - POST Reserva - Terminal de Reserva (*) alta prioridade Prof. Msc. Emerson Silas Dória

20 Prof. Msc. Emerson Silas Dória
Associações Típicas Categoria Exemplos A é um membro de B 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 - POST Piloto – Avião A se comunica com B 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 é possuído por B POST - Loja Aviã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 Papéis de uma Associação
Cada ponta de um associação é chamada de um “papel” Um papel pode ter: Nome Expressão de multiplicidade Navegabilidade Loja Estoca Item 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 – Loja Item – 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) – POST Vendas (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 – POST Gerente – POST A se comunica com B 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 é possuído por B POST – Loja Prof. Msc. Emerson Silas Dória

26 Conceitos e Associações candidatos para o POST
Item Loja Venda Pagamento Item Venda Operador Cliente Gerente Catálogo de Produtos Especificação de Produto estoca * possui 1..* usado-por contém descreve capturada-por contido-em descrito-por registra-venda-de 0..1 iniciado-por paga-por iniciada-por log-vendas realizadas 6 3 registra-venda-no 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 Operador Conhecimento 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 Venda iniciada-por Cliente Loja armazena Item ItemVenda registra-venda-de Item 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 Prof. Msc. Emerson Silas Dória
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 data hora: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 nome POSTcorrente pior Operador nome POST número usa melhor 1 Prof. Msc. Emerson Silas Dória

31 Atributos Não-Primitivos
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 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
Atributos e justificativa Pagamento quantia - 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. ItemVenda quantidade - 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 Prof. Msc. Emerson Silas Dória
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
Item Store address name Sale date time Payment amount Sales LineItem /quantity Cashier Customer Manager Product Catalog Specification description price UPC Stocks * Houses 1.. Used-by Contains Describes Captured-on Contained-in Described-by Records-sale-of 0..1 Started-by Paid-by Initiated-by Logs- completed 6 3 Records-sales-on 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 Teste Refin. Plano Impl. 2. Refinar Diag. Casos de Uso 3. Refinar Modelo Conceitual 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 feito b. contínuo c. 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) :Sistema Operador TerminarVenda() Repetir até não ter mais itens RegistrarPagamento(quantia) Texto que esclarece o controle, a lógica, a iteração, etc. Pode se obtido do caso de uso. Ator Comprar Itens – versão 1 O sistema como uma caixa-preta Evento de sistema dispara uma operação de sistema. Prof. Msc. Emerson Silas Dória

38 Prof. Msc. Emerson Silas Dória
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 Prof. Msc. Emerson Silas Dória
Eventos e Operações Comprar Itens – versão 1 :Sistema Operador EntrarItem(UPC,quantidade) evento de sistema “EntrarItem” ele dispara uma operação de sistema, da mesma maneira, chamada “EntrarItem” Prof. Msc. Emerson Silas Dória

40 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) TerminarVenda() RegistrarPagamento(quantia) Na UML, representado como operações de um tipo denominado Sistema Sistema EntrarItem(UPC, quantidade) TerminarVenda() RegistrarPagamento(quantia) Prof. Msc. Emerson Silas Dória

41 Definindo Diagramas de Seqüência (Comportamento do Sistema)
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 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) :Sistema Operador 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. Registre as operações de sistema requeridas. Identifique os eventos do sistema que cada ator gera. 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 Teste Refin. Plano Impl. 2. Refinar Diag. Casos de Uso 3. Refinar Modelo Conceitual 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 feito b. contínuo c. opcional Notas Prof. Msc. Emerson Silas Dória

45 Prof. Msc. Emerson Silas Dória
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 Prof. Msc. Emerson Silas Dória
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.9 Caso 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 Prof. Msc. Emerson Silas Dória
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 Prof. Msc. Emerson Silas Dória
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 Prof. Msc. Emerson Silas Dória
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
Operação: EntrarItem Pós-Condições: 1. Se tSe for uma nova venda, uma Venda foi criada (criação de instância); Caso de Uso: Comprar Itens Sequência Tipica de Eventos 1. Este caso de uso começa... EntrarItem(UPC,quantidade) :Sistema Operador TerminarVenda() RegistrarPagamento(quantia) Sistema EntrarItem(UPC, quantidade) TerminarVenda() RegistrarPagamento(quantia) Operação: TerminarVenda Pós-Condições: 1. Venda.Completada recebe o valor... Caso de Uso DSS Operações do Sistema Contratos Prof. Msc. Emerson Silas Dória

51 Prof. Msc. Emerson Silas Dória
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 Prof. Msc. Emerson Silas Dória
Contratos para o POST Operação TerminarVenda Contrato: 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.2 Caso 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 Prof. Msc. Emerson Silas Dória
Contratos para o POST Operação TerminarVenda Pós-condições: Venda.Completada recebe o valor true (modificação de atributos). Prof. Msc. Emerson Silas Dória

54 Prof. Msc. Emerson Silas Dória
Contratos para o POST Operação RegistrarPagamento: Contrato: RegistrarPagamento(quantia:numero) Responsabilidade: Registrar o pagamento, calcular o troco e imprimir recibo. Tipo: Sistema Referência Cruzada: Funções: R2.1 Caso de Uso: Comprar Itens Notas: Exceções: Se a venda não está completa, indicar um erro Se a quantia for menor que o total da venda, indicar um erro Saída: Pré-condições: Prof. Msc. Emerson Silas Dória

55 Prof. Msc. Emerson Silas Dória
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 Prof. Msc. Emerson Silas Dória
Contratos para o POST Operação Inicializar Contrato: 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 Prof. Msc. Emerson Silas Dória
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 Prof. Msc. Emerson Silas Dória
Diagrama da UML Consulte na página www2.unoeste.br/~emerson documentos específicos com os detalhes sintáticos da UML. Prof. Msc. Emerson Silas Dória


Carregar ppt "Análise e Projeto Orientados a Objeto com UML e Padrões"

Apresentações semelhantes


Anúncios Google