1 / 50

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 IV Projeto (1A). Da Análise ao Projeto. Artefatos de análise capturam os resultados do processo de investigação do domínio do problema. O Começo da Fase Projetar.

gay
Télécharger la présentation

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 IV Projeto (1A) Prof. Msc. Emerson Silas Dória

  2. Da Análise ao Projeto • Artefatos de análise capturam os resultados do processo de investigação do domínio do problema Prof. Msc. Emerson Silas Dória

  3. O Começo da Fase Projetar • A partir dos artefatos da fase de análise é desenvolvida uma solução lógica baseada no paradigma orientado a objetos. • Os Diagramas de Interação são a base de tal solução lógica, posteriormente, são criados os Diagramas de Classes de Projeto. Prof. Msc. Emerson Silas Dória

  4. Refin. Plano Impl. Teste 1. Definir Casos de Uso Reais 2. Definir Rel. & IU 3. Refinar Arquitetura b 4. Definir Diag. Interação 5. Definir Diag. Classe 6. Definir Esquema do BD a Notas a. em paralelo com diagrama de interação b. ordem variada Sinc. Artefatos Análise Projeto Descrevendo Casos de Uso Reais Prof. Msc. Emerson Silas Dória

  5. Casos de Uso Reais • Projeto “real” de um caso de uso em termos de tecnologias concretas de entrada/saída e sua implementação geral • Referências a janelas, componentes da interface com o usuário, mecanismos de interação, etc. • Necessários apenas se o desenvolvedor ou cliente requer uma descrição minuciosa (detalhada) da interface com o usuário antes da implementação Prof. Msc. Emerson Silas Dória

  6. Casos de Uso Reais • Exemplo de um caso de uso real Caso de uso: Atores: Finalidade: Visão Geral: Comprar Itens com Dinheiro Cliente, Operador Capturar uma venda e seu pagamento em dinheiro. Um Cliente chega no caixa, com itens que deseja comprar. O Operador registra os itens de compra e recebe um pagamento em dinheiro. Ao final, o Cliente deixa a loja com os itens. Tipo: Referências Cruzadas: Primário e Essencial Funções: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1 Prof. Msc. Emerson Silas Dória

  7. Object Store A E UPC Quantidade B F Descrição Preço C G Total Troco D Fornecido Entrar Item Terminar Venda Registrar Pagamento H I J Casos de Uso Reais 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. Para cada item, o Operador digita o código universal de produto (UPC) no campo A da Janela 1. Se houver mais de um exemplar do item, a quantidade pode ser digitada opcionalmente. Ele então pressiona o botão “Entra Item” com o mouse ou pressiona a tecla <Enter>. 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 no campo B e F da Janela 1. 4.. . . 5.. . . Prof. Msc. Emerson Silas Dória

  8. Notas a. em paralelo com diagrama de interação b. ordem variada Sinc. Artefatos Análise Projeto Definindo Diagramas de Interação Refin. Plano Impl. Teste 1. Definir Casos de Uso Reais 2. Definir Rel. & IU 3. Refinar Arquitetura b 4. Definir Diag. Interação 5. Definir Diag. Classe 6. Definir Esquema do BD a Prof. Msc. Emerson Silas Dória

  9. Ponto de Partida • Os contratos não mostram uma solução de como os objetos de software procederão para satisfazer as pós-condições. Prof. Msc. Emerson Silas Dória

  10. Diagramas de Interação • Um Diagrama de Interação ilustra como os objetos interagem através de mensagens para cumprir tarefas. • A criação de um DI depende da criação prévia dos seguinte artefatos: • Modelo Conceitual: subsidia a definição de classes de software correspondentes a conceitos, cujos objetos participam dos DI; Prof. Msc. Emerson Silas Dória

  11. Diagramas de Interação • continuando... • Contratos: subsidia a definição de responsabilidades e as pós-condições que os DI devem satisfazer • Casos de Uso Reais ou Essencias: subsidia a coleta de informações sobre quais tarefas os DI ilustram, além do que está nos contratos Prof. Msc. Emerson Silas Dória

  12. 1: mensagem2( ) :Instância_ClasseA :Instância_ClasseB mensagem1( ) 2: mensagem3( ) Diagramas de Interação • Diagramas de Colaboração • Ênfase na organização estrutural dos objetos que enviam e recebem mensagens • Diagramas de Seqüência • Ênfase na ordenação temporal das mensagens: :Instância_ClasseA :Instância_ClasseB mensagem1( ) 1: mensagem2( ) 2: mensagem3( ) Prof. Msc. Emerson Silas Dória

  13. RegistrarPagamento(df) 1:RegistrarPagamento(df) :Venda :POST 1.1:Criar(df) :Pagamento Diagramas de Interação • Exemplo de Diagrama de Colaboração para a operação RegistrarPagamento: direção da mensagem primeira mensagem instância primeira mensagem interna Prof. Msc. Emerson Silas Dória

  14. Como Fazer um Diagrama de Colaboração • Regras úteis: 1. Criar um diagrama em separado para cada uma das operações de sistema em desenvolvimento. • Para cada mensagem de operação de sistema, criar um diagrama com essa mensagem como mensagem inicial. 2. Se um diagrama se tornar muito complexo, o diagrama deve ser dividido. 3. Utilizar as responsabilidades e pós-condições dos contratos das operações de sistema, e a descrição dos casos de uso para projetar um sistema cujo objetos interajam para cumprir tarefas. Prof. Msc. Emerson Silas Dória

  15. Operação:EntrarItem Pós-Condições: 1. Se tSe for uma nova venda, uma Venda foi criada (criação de instância); :Sistema Operador EntrarItem(UPC, quantidade) EntrarItem(UPC,quantidade) TerminarVenda() Operação: TerminarVenda Pós-Condições: 1. Venda.Completada recebe o valor... :POST Sistema EntrarItem(UPC, quantidade) TerminarVenda() RegistrarPagamento(quantia) RegistrarPagamento(quantia) Diag. Colaboração DSS Operações do Sistema Contratos Diagramas de Colaboração e Outros Artefatos Prof. Msc. Emerson Silas Dória

  16. :Venda p1:Pagamento POST instância instância nomeada classe msg1( ) 1:msg1(a,b ) 2:msg2( ) :Venda :POST 3:msg3( ) Notação Básica para DI • Classes e Instâncias • Ligações, Mensagens, Parâmetros Prof. Msc. Emerson Silas Dória

  17. msg1( ) 1:tot:=total( ):integer :Venda :POST msg1( ) :POST 1:clear( ) Notação Básica para DI • Valor de Retorno • Mensagem para “self” ou “this” Prof. Msc. Emerson Silas Dória

  18. msg1( ) 1*:l:=proximaLinhaItem( ) :Venda :POST msg1( ) 1*[i:=1..10]:l:=proximaLinhaItem( ) :Venda :POST Notação Básica para DI • Iteração • Cláusula de Iteração * Expressa mensagem enviada repetidamente Prof. Msc. Emerson Silas Dória

  19. msg1( ) 1:msg2( ) :ClasseB :ClasseA 1.1:msg3( ) 2.1:msg5( ) 2:msg4( ) :ClasseC 2.2:msg6( ) :ClasseD Notação Básica para DI • Seqüenciamento de Mensagens Prof. Msc. Emerson Silas Dória

  20. msg1( ) 1:[nova venda] criar( ) :Venda :POST Expressa que a mensagem só deve ser enviada se o valor de nova venda for TRUE em tempo de execução. :ItemVenda Notação Básica para DI • Mensagens Condicionais Prof. Msc. Emerson Silas Dória

  21. msg1( ) 1a:[test]msg2( ) :ClasseB :ClasseA 1.1:msg3( ) 2.1:msg5( ) 1b:[not test]msg4( ) :ClasseC 2.2:msg6( ) Expressa que a mensagem 1a ou 1b podem ser executadas, dependendo do teste lógico entre []. :ClasseD Notação Básica • Caminhos Condicionais Mutuamente Exclusivos Prof. Msc. Emerson Silas Dória

  22. :ClasseB :ClasseB Expressa um conjunto lógico de instâncias (Ex: Vector em Java) vendas:Venda msg1( ) :ItemVenda :ItemVenda 1:s:=size():int :ItemVenda :Venda Expressa uma mensagem enviada a Java.util.Vector, por exemplo, para descobrir o número de elementos no Vetor (objeto coleção) Notação Básica • Coleções (multiobjects) • Mensagens para uma coleção Prof. Msc. Emerson Silas Dória

  23. msg1( ) 1:criar( ) iv:ItemVenda :Venda 2:additem(iv ) :ItemVenda :ItemVenda :ItemVenda Notação Básica • Mensagens para uma coleção e um elemento Prof. Msc. Emerson Silas Dória

  24. Notação Básica • Mensagens para um objeto classe msg1( ) 1:d1:=today( ):Date Data :Venda Expressa uma mensagem sendo enviada para uma classe Prof. Msc. Emerson Silas Dória

  25. Atribuição de Responsabilidades O POO às vezes é definido como: “Identificado os requisitos e o modelo conceitual, acrescente os métodos às classes de software e defina as mensagens/troca de mensagens (DI) para atender os requisitos” Prof. Msc. Emerson Silas Dória

  26. Atribuição de Responsabilidades • Contratos: suposição preliminar sobre as responsabilidades e as pós-condições das operações • Diagramas de Interação: ilustram a solução, em termos de objetos interatuantes, que satisfazem responsabilidades e pós-condições POO -> Atribuição de Responsabilidade -> Bons Projetos OO Prof. Msc. Emerson Silas Dória

  27. Responsabilidades e Métodos • Responsabilidade é “um contrato ou obrigação de um tipo ou classe” (Booch e Rumbaugh, 1997) • Relacionada as obrigações dos objetos em termos de comportamento. • Tipos básicos • De fazer (alguma coisa) • Ex: fazer algo individualmente, iniciar ações em outros objetos, controlar ou coordenar atividades em outros objetos • De conhecer (alguma coisa) • Ex: dados privados encapsulados, objetos relacionados, informação derivada ou calculada Prof. Msc. Emerson Silas Dória

  28. Responsabilidades e Métodos • Responsabilidades são atribuídas aos objetos do sistema durante o Projeto OO • “Uma Venda é responsável por imprimir a si própria” (de fazer) • “Uma Venda é responsável por conhecer sua data” (de conhecer) • Tradução de responsabilidades para classes e métodos é influenciada pela granularidade da responsabilidade • Um único método para “imprimir venda” • Dezenas de métodos para “prover um mecanismo de acesso a SGBDR” Prof. Msc. Emerson Silas Dória

  29. Responsabilidades e Métodos • Métodos são implementados para cumprir responsabilidades • Podem agir sozinhos ou em colaboração com outros métodos e objetos • Exemplo: • A classe Venda pode definir um ou mais métodos específicos para cumprir a responsabilidade de imprimir • Esse método, por sua vez, pode precisar colaborar com outros objetos, possivelmente enviando mensagens de impressão para cada um dos objetos ItemVenda associados à Venda. Prof. Msc. Emerson Silas Dória

  30. Responsabilidades e DI • Diagramas de Interação ilustram decisões de atribuição de responsabilidades a objetos. • Quais mensagens são enviadas para diferentes classes e objetos? :ItemVenda 1:[para cada] iv:=next( ) imprimir( ) iv:ItemVenda :Venda Implica que objetos Venda têm uma responsabilidade de imprimirem a si mesmos. 2:imprimir( ) iv:ItemVenda • Guias práticos para facilitar a tomada de decisões na atribuição de responsabilidades são oferecidos pelos padrões GRASP. Prof. Msc. Emerson Silas Dória

  31. Padrões (Patterns) • “Um padrão é um par nomeado problema/solução que pode ser aplicado em novos contextos, com conselhos sobre sua aplicação em novas situações e uma discussão sobre as conseqüências de seu uso.” • Capturam princípios fundamentais da engenharia de software. • Em geral, não contêm novas idéias nem soluções originais • Codificam soluções existentes comprovadas • Podem oferecer guias de como responsabilidades devem ser atribuídas a objetos, dada uma categoria específica de problemas. Prof. Msc. Emerson Silas Dória

  32. Padrões GRASP(General Responsibility Assignment Software Patterns) • Atribuição competente de responsabilidades a objetos: • Cruciais no POO e ocorre na construção dos Diagramas de Interação • Padrões: pares de problema/solução que codificam orientações e princípios freqüentemente relacionados com a atribuição de responsabilidades. • Cinco padrões mais comuns (Especialista; Criador; Alta Coesão; Baixo Acoplamento; Controlador) Prof. Msc. Emerson Silas Dória

  33. PadrãoEspecialista (Expert) • Solução • Atribuir responsabilidade para o especialista na informação - a classe que tem a informação necessária para cumprir a responsabilidade. • Problema • Qual é o princípio básico pelo qual responsabilidades são atribuídas em POO? • Exemplo: • Quem deve ser responsável por conhecer o total de uma venda? Segundo o padrão EXPERT, devemos procurar a classe de objetos que tem a informação necessária para determinar o total. • Informação necessária: conhecer todas as instâncias ItemVenda da Venda e o subtotal de cada uma delas. Somente uma instância de venda conhece isso. Prof. Msc. Emerson Silas Dória

  34. Venda Venda data hora data hora, status t:obter_total( ) :Venda obter_total() contém 1..* ItemVenda EspecificaçãoProduto descrito * Aqui ocorrem as definições de responsabilidade. quantidade descrição preço UPC Modelo Conceitual Parcial PadrãoEspecialista (Expert) • Pelo padrão, a classe Venda deve ser a responsável. Prof. Msc. Emerson Silas Dória

  35. Venda 1*:[para cada]iv:next( ) t:obter_total( ) :Venda data hora Aqui ocorrem as definições de responsabilidade. 2:st:=obter_subtotal() obter_total( ) iv:ItemVenda :ItemVenda ItemVenda :ItemVenda quantidade obter_subtotal() PadrãoEspecialista (Expert) • Mas quem deve ser responsável por conhecer o subtotal de um ItemVenda? • Informação necessária: ItemVenda.quantidade e EspecificaçãoProduto.preço • Pelo padrão, a classe ItemVenda deve ser a responsável. Prof. Msc. Emerson Silas Dória

  36. Venda data hora, status obter_total( ) EspecificaçãoProduto ItemVenda descrição preço UPC quantidade Aqui ocorrem as definições de responsabilidade. obter_subtotal() obter_preço( ) PadrãoEspecialista (Expert) • Porém, para cumprir essa responsabilidade de conhecer ou informar seu subtotal um ItemVenda precisa conhecer o preço do Item. • Portanto, o ItemVenda deve mandar uma mensagem para a EspecificaçãoProduto para saber o preço do item. 1*:[para cada]iv:next( ) t:obter_total( ) :Venda 2:st:=obter_subtotal( ) iv:ItemVenda :ItemVenda :ItemVenda 2.1:p:=obter_preço( ) :Especificação Produto Prof. Msc. Emerson Silas Dória

  37. Classe Responsabilidade Venda Conhecer total da venda ItemVenda Conhecer subtotal do item EspecificaçãoProduto Conhecer preço do produto PadrãoEspecialista (Expert) • Concluindo, para cumprir a responsabilidade de conhecer e informar o total da venda, três responsabilidades foram atribuídas a três classes de objetos: Prof. Msc. Emerson Silas Dória

  38. PadrãoEspecialista (Expert) • Contra-Indicações • Indesejável, geralmente devido ao problema do acoplamento e coesão. • Benefícios • Mantém encapsulamento pois objetos usam sua própria informação, favorecendo o baixo acoplamento • Comportamento é distribuído através das classes que tem a informação necessária para cumprir a responsabilidade, obtendo alta coesão Prof. Msc. Emerson Silas Dória

  39. PadrãoCriador (Creator) • Solução • Atribuir à classe B a responsabilidade de criar uma instância da classe A se umas das seguintes condições forem verdadeiras: • B agrega instâncias de A (*) • B contém instâncias de A (*) • B registra instâncias de A • B usa bem de perto instâncias de A • B tem os dados de inicialização para criar instâncias de A (B portanto é um especialista na criação de A) • Problema • Quem deve ser responsável por criar uma nova instância de alguma classe? Algumas vezes um criador é encontrado ao observar a classe que tem os dados iniciais que serão passados na criação. (*) priorizar Prof. Msc. Emerson Silas Dória

  40. Venda data hora criar_iv( ) obter_total( ) PadrãoCriador (Creator) • Exemplo • Quem deve ser responsável por criar uma instância de ItemVenda? • Pelo padrão, Venda deve ser responsável. criar_iv(quantidade) :Venda 1:criar_iv(quantidade) :ItemVenda • Benefícios (garante baixo acoplamento) Prof. Msc. Emerson Silas Dória

  41. PadrãoBaixo Acoplamento (Low Coupling) • Solução • Atribuir a responsabilidade de modo que o acoplamento (dependência entre classes) permaneça baixo. • Problema • Como conseguir menor dependência (entre as classes) e maior reuso? • Acoplamento • Baixo: Não depende de outros elementos (classes) • Alto: Depende de muitos outros elementos (classes) • Tais classes podem ter os seguintes problemas: mudanças em classes relacionadas forçam mudanças locais; difíceis de compreender isoladamente; difíceis de serem reutilizadas. Prof. Msc. Emerson Silas Dória

  42. RegistrarPagamento( ) 1:criar( ) p:Pagamento :POST 2:adicionar_pagamento (p) :Venda PadrãoBaixo Acoplamento (Low Coupling) • Exemplo • Quem deve ser responsável por criar um Pagamento e associá-lo à Venda? • Pelo padrão Criador, poderia ser POST (uma vez que POST “registra” pagamentos no mundo real) Prof. Msc. Emerson Silas Dória

  43. RegistrarPagamento( ) 1:RegistrarPagamento( ) :Venda :POST 1.1:criar( ) :Pagamento PadrãoBaixo Acoplamento (Low Coupling) • Uma solução melhor, do ponto de vista do padrão, que preserva baixo acoplamento é a própria Venda criar o Pagamento: Prof. Msc. Emerson Silas Dória

  44. PadrãoBaixo Acoplamento (Low Coupling) • Benefícios • Responsabilidade não é (ou é pouco) afetada por mudanças em outros componentes. • Responsabilidade é mais simples de entender isoladamente. • Maior chance para reuso. Prof. Msc. Emerson Silas Dória

  45. PadrãoAlta Coesão (High Cohesion) • Solução • Atribuir uma responsabilidade de modo que a coesão permaneça alta. • Problema • Como manter a complexidade (das classes) sob controle? • Coesão • Alta: Um elemento com responsabilidades altamente relacionadas e que não executa um grande volume de trabalho. • Baixa: Uma classe faz muitas coisas não relacionadas ou executa muitas tarefas (indesejável pois fica difícil de: compreender, reutilizar e manter; e são constantemente afetadas pelas mudanças) Em POO a Coesão Funcional mede o quanto as responsabilidades de um elemento são fortemente relacionadas. Prof. Msc. Emerson Silas Dória

  46. :POST :Venda RealizarPagamento( ) criar( ) p:Pagamento adicionar_pagamento (p) PadrãoAlta Coesão (High Cohesion) • Exemplo • Quem deve ser responsável por criar um Pagamento e associá-lo à Venda? • Pelo padrão Criador, seria POST. Mas se POST for o responsável pela maioria das operações do sistema, ele vai ficar cada vez mais sobrecarregado e sem coesão. Prof. Msc. Emerson Silas Dória

  47. PadrãoAlta Coesão (High Cohesion) • Exemplo • Outra forma para atribuição da responsabilidade RealizarPagamento que favorece uma coesão mais alta :POST :Venda RealizarPagamento( ) RealizarPagamento( ) criar( ) :Pagamento Prof. Msc. Emerson Silas Dória

  48. PadrãoAlta Coesão (High Cohesion) • Níveis de coesão • Muito baixa • Um única classe é responsável por muitas coisas em áreas funcionais muito diferentes. • Baixa • Um classe é a única responsável por uma tarefa complexa em uma área funcional. • Alta • Um classe tem responsabilidades moderadas em uma área funcional e colabora com outras classes para realizar tarefas. • Moderada • Uma classe tem peso leve e responsabilidades exclusivas em algumas áreas logicamente relacionadas ao conceito da classe, mas não uma com a outra. Prof. Msc. Emerson Silas Dória

  49. PadrãoAlta Coesão (High Cohesion) • Benefícios • Aumento da clareza e compreensão do projeto • Simplificação da manutenção • Favorece baixo acoplamento • Reuso facilitado Prof. Msc. Emerson Silas Dória

  50. Princípios Básicos (Pressman,1995) • Acoplamento • “O acoplamento é uma medida da interconexão entre os módulos de uma estrutura de software, depende da complexidade de interface entre módulos”; • Coesão • “Um módulo coeso executa uma única tarefa dentro do procedimento de software, exigindo pouca interação com procedimentos executados em outras partes de um programa.” Prof. Msc. Emerson Silas Dória

More Related