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

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

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

Apresentações semelhantes


Apresentação em tema: "Prof. Msc. Emerson Silas Dória1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte III Análise (1)"— Transcrição da apresentação:

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

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

3 Prof. Msc. Emerson Silas Dória3 Construindo um Modelo Conceitual Sinc. Artefatos AnáliseProjetoTeste 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

4 Prof. Msc. Emerson Silas Dória4 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

5 Prof. Msc. Emerson Silas Dória5 Modelo Conceitual Parcial para o Sistema POST 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 Capturado-no  Conceito Associação Atributos * 1..*

6 Prof. Msc. Emerson Silas Dória6 Conceitos 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 Idéias, coisas, ou objetos do mundo real Não representam componentes de software!

7 Prof. Msc. Emerson Silas Dória7 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

8 Prof. Msc. Emerson Silas Dória8 Conceitos Típicos CategoriaExemplos 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çãoItens de venda Papéis de pessoas Operador Piloto Contêiner de outras coisasDepósito, Armário, Aeronave

9 Prof. Msc. Emerson Silas Dória9 Conceitos Típicos CategoriaExemplos 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

10 Prof. Msc. Emerson Silas Dória10 Identificando Conceitos e Atributos em Descrições Textuais Seqüência Típica de Eventos Ação do Ator Resposta do Sistema 2. O Operador registra o i dentificado r de cada item. Se houver mais de um exemplar do mesmo item, o Operado r 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

11 Prof. Msc. Emerson Silas Dória11 Conceitos Candidatos para o Sistema POST Conceitos restritos ao caso de uso Comprar Itens - Versão expandida LojaPostVendaItem Pagamento Item de Venda OperadorClienteGerente Catálogo Produtos Especificação de Produtos

12 Prof. Msc. Emerson Silas Dória12 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

13 Prof. Msc. Emerson Silas Dória13 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

14 Prof. Msc. Emerson Silas Dória14 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ção preço número serial UPC EspecificaçãoProduto Item Número serial Descreve 1 * descrição preço UPC pior melhor

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

16 Prof. Msc. Emerson Silas Dória16 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”

17 Prof. Msc. Emerson Silas Dória17 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?

18 Prof. Msc. Emerson Silas Dória18 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

19 Prof. Msc. Emerson Silas Dória19 Associações Típicas (*) alta prioridade CategoriaExemplos 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 Item de Venda - Venda Opção de Reserva – Reserva A é conhecido/registrado/repor- tado/capturado em B (*) Venda - POST Reserva - Terminal de Reserva

20 Prof. Msc. Emerson Silas Dória20 Associações Típicas CategoriaExemplos 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

21 Prof. Msc. Emerson Silas Dória21 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.

22 Prof. Msc. Emerson Silas Dória22 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

23 Prof. Msc. Emerson Silas Dória23 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

24 Prof. Msc. Emerson Silas Dória24 Aplicando a lista de Associações Típicas CategoriaSistema 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 BEspecificaçã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

25 Prof. Msc. Emerson Silas Dória25 Aplicando a lista de Associações Típicas CategoriaSistema POST A é um membro de BOperador - 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 BCliente – 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

26 Prof. Msc. Emerson Silas Dória26 Conceitos e Associações candidatos para o POST POST Item Loja Venda Pagamento Item Venda OperadorCliente Gerente Catálogo de Produtos Especificação de Produto estoca * possui 1..* usado-por * contém 1.. * 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 iniciada-por 1 1

27 Prof. Msc. Emerson Silas Dória27 Eliminando associações redundantes ou desnecessárias Associações cujo conhecimento não precisa ser preservado podem ser removidas do modelo: AssociaçãoConsideraçã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 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.

28 Prof. Msc. Emerson Silas Dória28 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

29 Prof. Msc. Emerson Silas Dória29 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

30 Prof. Msc. Emerson Silas Dória30 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 1

31 Prof. Msc. Emerson Silas Dória31 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

32 Prof. Msc. Emerson Silas Dória32 Adicionando Atributos aos Conceitos Candidatos do Sistema POST Conceito 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.

33 Prof. Msc. Emerson Silas Dória33 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 “/”

34 Prof. Msc. Emerson Silas Dória34 Modelo Conceitual Inicial do POST 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

35 Prof. Msc. Emerson Silas Dória35 Definindo Diagramas de Seqüência (Comportamento do Sistema) Sinc. Artefatos AnáliseProjetoTeste 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

36 Prof. Msc. Emerson Silas Dória36 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.

37 Prof. Msc. Emerson Silas Dória37 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.

38 Prof. Msc. Emerson Silas Dória38 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

39 Prof. Msc. Emerson Silas Dória39 Eventos e Operações EntrarItem(UPC,quantidade) :Sistema Operador Comprar Itens – versão 1 evento de sistema “EntrarItem” ele dispara uma operação de sistema, da mesma maneira, chamada “EntrarItem”

40 Prof. Msc. Emerson Silas Dória40 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)

41 Prof. Msc. Emerson Silas Dória41 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.

42 Prof. Msc. Emerson Silas Dória42 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. Identifique os eventos do sistema que cada ator gera. Registre as operações de sistema requeridas.

43 Prof. Msc. Emerson Silas Dória43 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

44 Prof. Msc. Emerson Silas Dória44 Definindo Contratos de Operação Sinc. Artefatos AnáliseProjetoTeste 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

45 Prof. Msc. Emerson Silas Dória45 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

46 Prof. Msc. Emerson Silas Dória46 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

47 Prof. Msc. Emerson Silas Dória47 Contratos Exemplo para operação EntrarItem Pós-condições: n Se for uma nova venda, uma Venda foi criada (criação de instância); n Se for uma nova venda, a nova Venda foi associada ao POST (formada uma associação); n Um ItemVenda foi criado (criação de instância); n O ItemVenda foi associado à Venda (formada uma associação); n ItemVenda.quantidade recebeu o valor de quantidade (modificação de atributo); n O ItemVenda foi associado a uma EspecificaçãoDeProduto, baseada numa correspondência com o UPCs (formada uma associação).

48 Prof. Msc. Emerson Silas Dória48 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

49 Prof. Msc. Emerson Silas Dória49 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!)

50 Prof. Msc. Emerson Silas Dória50 Contratos e Outros Artefatos Caso de Uso: Comprar Itens Sequência Tipica de Eventos 1. Este caso de uso começa... Operação: EntrarItem Pó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) :Sistema Operador TerminarVenda() RegistrarPagamento(quantia) Caso de UsoDSSOperações do SistemaContratos Operação: TerminarVenda Pós-Condições: 1. Venda.Completada recebe o valor...

51 Prof. Msc. Emerson Silas Dória51 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

52 Prof. Msc. Emerson Silas Dória52 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

53 Prof. Msc. Emerson Silas Dória53 Contratos para o POST Operação TerminarVenda Pós-condições: n Venda.Completada recebe o valor true (modificação de atributos).

54 Prof. Msc. Emerson Silas Dória54 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:

55 Prof. Msc. Emerson Silas Dória55 Contratos para o POST Operação RegistrarPagamento: Pós-condições: n Um Pagamento foi criado (criação de instância); n Pagamento.quantiaFornecida recebeu o valor da quantia (modificação de atributos); n O Pagamento foi associado à Venda (relacionamento foi formado); n A Venda foi associada à Loja, para acrescentá-la ao histórico de vendas completadas (relacionamento foi formado).

56 Prof. Msc. Emerson Silas Dória56 Contratos para o POST Operação Inicializar Contrato:Inicializar() Responsabilidade:Inicializar o sistema Tipo:Sistema... Pós-condições: n Uma Loja, CatálogodeProdutos, EspecificaçõesDeProdutos foram criadas (criação de instâncias); n CatálogodeProdutos foi associado a EspecificaçõesDeProdutos (associação formada); n Loja foi associada a CatálogodeProdutos (associação formada);

57 Prof. Msc. Emerson Silas Dória57 Contratos para o POST Operação Inicializar Pós-condições: n Loja foi associada POST (associação formada); n POST associado a CatálogodeProdutos (associação formada).

58 Prof. Msc. Emerson Silas Dória58 Diagrama da UML Consulte na página www2.unoeste.br/~emerson documentos específicos com os detalhes sintáticos da UML.


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

Apresentações semelhantes


Anúncios Google