1 / 58

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

Análise e Projeto Orientados a Objeto com UML e Padrões. Parte III Análise (1). Sinc. Artefatos. Análise. Projeto. Construindo um Modelo Conceitual. Plan. & Elaboração. Construção. Implantação. Ciclo de Desenv. 1. Ciclo de Desenv. 2. Refin. Plano. Impl. Teste. Refin. Plano.

Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

  3. Refin. Plano Impl. Teste Notas a. se ainda não feito b. contínuo 4. Refinar Glossário 1. Definir Casos de Uso Essenciais 3. Refinar Modelo Conceitual 2. Refinar Diag. Casos de Uso c. opcional b a Sinc. Artefatos Análise Projeto 5. Definir Diag. Seq. 6. Definir Contrat. de Operação 7. Definir Diag. Estado c Construindo um Modelo Conceitual 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. Item de Venda Conceito Item Registra-venda-de 1 0..1 quantidade * 1..* Armazenado-em Contido-em Associação 1 1 Depósito Venda Atributos data endereço hora nome 1 1 1 Aloja Pago-por 1..* POST 1 Capturado-no4 Pagamento 1 quantia Modelo Conceitual Parcial para o Sistema POST Prof. Msc. Emerson Silas Dória

  6. BancodeDados Artefato de software; não faz parte do modelo evitar Sale Classe de software ; não faz parte do modelo conceitual evitar data hora imprime() Conceitos • 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ípicos Prof. Msc. Emerson Silas Dória

  9. Conceitos Típicos 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 • Usar com cuidado! • Linguagens naturais: imprecisão e ambigüidade 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. Prof. Msc. Emerson Silas Dória

  11. Conceitos Candidatos para o Sistema POST • Conceitos restritos ao caso de uso Comprar Itens - Versão expandida Post Item Loja Venda Item de Venda Operador Cliente Gerente Pagamento 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. 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. Item descrição preço número serial UPC pior melhor EspecificaçãoProduto Item Descreve descrição * 1 Número serial preço UPC 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 Prof. Msc. Emerson Silas Dória

  15. Conceitos de Especificação ou de Descrição • outro exemplo: Vôo Aeroporto Voa-para pior Data Número hora 1 * nome Vôo Descrição-Vôo Descrito-por melhor data hora 1 * número * Descreve-vôo-para 1 Aeroporto nome 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. EspecificaçãoProduto Item descreve Descrição Preço UPC 1 * Númeroserial 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 Prof. Msc. Emerson Silas Dória

  19. Associações Típicas (*) alta prioridade Prof. Msc. Emerson Silas Dória

  20. Associações Típicas (*) 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 Estoca Loja 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 Prof. Msc. Emerson Silas Dória

  25. Aplicando a lista de Associações Típicas Prof. Msc. Emerson Silas Dória

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

  30. Operador pior nome POSTcorrente usa 1 Operador POST 1 melhor nome número 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”) Prof. Msc. Emerson Silas Dória

  31. Especificação de Produto Loja endereço:Endereço upc : UPC 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 Prof. Msc. Emerson Silas Dória

  32. Adicionando Atributos aos Conceitos Candidatos do Sistema POST 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. Records-sale-of Described-by 1 Product Product Specification Catalog Contains description 1 * 1.. price UPC 1 0..1 * Used-by Describes * * Sales Store LineItem Item Stocks address 1..* /quantity * 1 1 name * 1.. Logs- 1 Houses Contained-in completed * 1.. 1 6 * Sale POST Manager Started-by date 1 1 Captured-on time 1 1 1 1 1 Initiated-by 3 Records-sales-on Paid-by 1 1 1 Payment Customer Cashier amount 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 Prof. Msc. Emerson Silas Dória

  35. Refin. Plano Impl. Teste Notas a. se ainda não feito b. contínuo 4. Refinar Glossário 1. Definir Casos de Uso Essenciais 3. Refinar Modelo Conceitual 2. Refinar Diag. Casos de Uso c. opcional b a Sinc. Artefatos Análise Projeto 5. Definir Diag. Seq. 6. Definir Contrat. de Operação 7. Definir Diag. Estado c Definindo Diagramas de Seqüência (Comportamento do Sistema) 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. O sistema como uma caixa-preta Comprar Itens – versão 1 Ator :Sistema Operador EntrarItem(UPC,quantidade) Repetir até não ter mais itens TerminarVenda() Texto que esclarece o controle, a lógica, a iteração, etc. Pode se obtido do caso de uso. RegistrarPagamento(quantia) Evento de sistema dispara uma operação de sistema. Diagrama de Seqüência do Sistema (Comportamento do 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 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. Sistema EntrarItem(UPC, quantidade) TerminarVenda() RegistrarPagamento(quantia) 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 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. Comprar Itens – versão 1 1. Este caso de uso começa quando um Cliente chega no caixa (equipado com um POST) com itens que deseja comprar. :Sistema Operador 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. EntrarItem(UPC,quantidade) TerminarVenda() 4. Após processar o último item, o Operador indica ao POST que a entrada de itens terminou. RegistrarPagamento(quantia) 6. O Operador informa o total ao Cliente. Definindo Diagramas de Seqüência (Comportamento do Sistema) 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.:RegistrarPagamentoem vez de EntrarQuantia Prof. Msc. Emerson Silas Dória

  44. Refin. Plano Impl. Teste Notas a. se ainda não feito b. contínuo 4. Refinar Glossário 1. Definir Casos de Uso Essenciais 3. Refinar Modelo Conceitual 2. Refinar Diag. Casos de Uso c. opcional b a Sinc. Artefatos Análise Projeto 5. Definir Diag. Seq. 6. Definir Contrat. de Operação 7. Definir Diag. Estado c Definindo Contratos de Operação 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 Prof. Msc. Emerson Silas Dória

  47. Contratos • Exemplo para operação EntrarItem Prof. Msc. Emerson Silas Dória

  48. Seções de um Contrato 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. :Sistema Operador EntrarItem(UPC,quantidade) TerminarVenda() Sistema EntrarItem(UPC, quantidade) TerminarVenda() RegistrarPagamento(quantia) RegistrarPagamento(quantia) Caso de Uso DSS Operações do Sistema Contratos 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... Operação: TerminarVenda Pós-Condições: 1. Venda.Completada recebe o valor... Prof. Msc. Emerson Silas Dória

More Related