© Nabor C. Mendonça 2001 1 Análise e Projeto Orientados a Objeto com UML e Padrões.

Apresentação em tema: "© Nabor C. Mendonça 2001 1 Análise e Projeto Orientados a Objeto com UML e Padrões."— Transcrição da apresentação:

1 © Nabor C. Mendonça 2001 1 Análise e Projeto Orientados a Objeto com UML e Padrões

2 © Nabor C. Mendonça 2001 2 n Artefatos de análise capturam os resultados da investigação do domínio do problema n Artefatos de projeto capturam uma solução para o problema baseada no paradigma de OO – Diagramas de colaboração e classe de projeto – Atribuição de responsabilidades e uso de padrões Da Análise ao Projeto Artefato Casos de uso Questões Respondidas Quais são os cenários usuário-sistema? Modelo conceitual Quais são os conceitos e seus relacionamentos? Diagramas de seqüênciaQuais são as operações do sistema? ContratosO que fazem as operações do sistema?

3 © Nabor C. Mendonça 2001 3 Definindo Diagramas de Colaboração 2. Definir Rel. & IU 4. Definir Diag. Colaboração 5. Definir Diag. Classe a 6. Definir Esquema do BD 1. Definir Casos de Uso Reais 3. Refinar Arquitetura b Notas a. em paralelo com diag. interação b. ordem variada Sinc. Artefatos AnáliseProjetoTeste Refin. Plano Impl. Um Ciclo de Desenvolvimento

4 © Nabor C. Mendonça 2001 4 Diagramas de Colaboração n Um diagrama de colaboração ilustra as interações de mensagens entre objetos do modelo do domínio (diagrama de classe, simplificado) – Atribuição de responsabilidades aos objetos – Ponto de partida é o cumprimento das pós- condições especificadas nos contratos de operação

5 © Nabor C. Mendonça 2001 5 n Diagrama de colaboração – Ilustra interações num formato de grafo ou rede Diagramas de Colaboração :ClassAInstance:ClassBInstance 1: message2() 2: message3() message1()

6 © Nabor C. Mendonça 2001 6 Diagramas de Colaboração n Exemplo para a operação fazerPagamento 1: makePayment(cashTendered) 1.1: create(cashTendered) :POST:Sale :Payment makePayment(cashTendered) parameter direction of message first message instance first internal message link line

7 © Nabor C. Mendonça 2001 7 Como Fazer um Diagrama de Colaboração n Regras úteis 1. Criar um diagrama em separado para cada uma das operações de sistema sendo desenvolvidas no ciclo atual - Para cada mensagem de operação de sistema, criar um diagrama com essa mensagem como mensagem inicial 2. Se um diagrama fica muito complexo (não cabe facilmente num folha de papel A4), o diagrama deve ser dividido em diagramas menores 3. Usar as pós-condições dos contratos de operação, e a descrição dos casos de uso para projetar um sistema cujo objetos interagem para cumprir as tarefas exigidas, segundo o modelo do domínio

8 © Nabor C. Mendonça 2001 8 Diagramas de Colaboração e Outros Artefatos Modelo do Domínio

9 © Nabor C. Mendonça 2001 9 n Classes e instâncias n Links Notação Básica 1: makePayment(cashTendered) :POST:Sale msg1() link line

10 © Nabor C. Mendonça 2001 10 n Mensagens n Parâmetros Notação Básica 1: message1() 2: message2() 3: message3() :POST:Sale msg1() all messages flow on the same link 1: makePayment(amount: Money) :POST:Sale msg1() parameters

11 © Nabor C. Mendonça 2001 11 n Valor de retorno Notação Básica 1: tot := total(): Real :POST:Sale msg1() return value type return value name

12 © Nabor C. Mendonça 2001 12 n Mensagem para “self” ou “this” n Iteração Notação Básica 1*: li := nextLineItem(): SalesLineItem :POST:Sale msg1() iteration recurrence values omitted

13 © Nabor C. Mendonça 2001 13 n Cláusula de iteração n Iteração com múltiplas mensagens Notação Básica 1*: [i := 1..10] li := nextLineItem(): SalesLineItem :POST:Sale msg1() iteration clause 1*: [i := 1..10] msg2() :AmyB :B msg1() note that iteration clauses are equal myC :C 2*: [i := 1..10] msg3() msg1() { for i := 1 to 10 { myB.msg2() myC.msg3() } }

14 © Nabor C. Mendonça 2001 14 n Criação de instância Notação Básica

15 © Nabor C. Mendonça 2001 15 n Seqüenciamento de mensagens Notação Básica :ClassA msg1() :ClassB 1: msg2() :ClassC 1.1: msg3() not numbered legal numbering

16 © Nabor C. Mendonça 2001 16 n Seqüenciamento complexo de mensagens Notação Básica

17 © Nabor C. Mendonça 2001 17 n Mensagens condicionais Notação Básica 1: [nova venda] create() :TV:Venda :LinhaDeVenda 1.1: create() msg1() conditional message, with test

18 © Nabor C. Mendonça 2001 18 n Caminhos condicionais mutuamente exclusivos Notação Básica

19 © Nabor C. Mendonça 2001 19 n Operação entrarItem() (diagrama parcial) Notação Básica 1: [nova venda] create() :TV:Venda :LinhaDeVenda 3: create() entrarItem() conditional message, with test 2: [velha venda] criarLinhaDeVenda() Note que mensagens condicionais simulam IF... THEN... ELSE

20 © Nabor C. Mendonça 2001 20 n Coleções (multiobjects) n Mensagens para uma coleção Notação Básica

21 © Nabor C. Mendonça 2001 21 n Mensagens para uma coleção e um elemento Notação Básica 1: create() :Salesl: SalesLineItem SalesLineItem :SalesLineItem 2: addElement(sl) msg1() 2: print() :Salesl: SalesLineItem SalesLineItem :SalesLineItem 1: sl := get(key) msg1()

22 © Nabor C. Mendonça 2001 22 Responsabilidades e Métodos n Responsabilidade é “um contrato ou obrigação de um tipo ou classe” [Booch et al.’97] – Relacionada com o comportamento dos objetos n Dois tipos básicos: – De conhecer (alguma coisa) Ex.: dados privados encapsulados, objetos relacionados, informação derivada ou calculada – De fazer (alguma coisa) Ex.: Fazer algo individualmente, iniciar uma ação em outros objetos, controlar ou coordenar atividades em outros objetos

23 © Nabor C. Mendonça 2001 23 Responsabilidades e Métodos n Responsabilidade são atribuídas aos objetos do sistema durante o projeto OO – Exemplos: “Uma Venda é responsável por imprimir a si própria” (de fazer) “Uma Venda é responsável por conhecer sua data” (de conhecer) n Tradução 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 SGBD relacionais”

24 © Nabor C. Mendonça 2001 24 Responsabilidades e Métodos n Métodos são implementados para cumprir responsabilidades – Podem agir sozinhos ou em colaboração com outros métodos e objetos n Exemplo – A classe Venda pode definir um método específico para cumprir a responsabilidade de impressão – Esse método, por sua vez, pode precisar colaborar com outros objetos, possivelmente enviando mensagens de impressão para cada um dos objetos Item-de-Venda associados à Venda

25 © Nabor C. Mendonça 2001 25 n Diagramas de interação ilustram decisões na atribuição de responsabilidades a objetos – Quais mensagens são enviadas para diferentes classes e objetos? n Guias práticos para facilitar a tomada de decisões na atribuição de responsabilidades são oferecidos pelos padrões GRASP Responsabilidades e Diagramas de Interação :Sale print()2: print() sli:SalesLineItem implies Sale objects have a responsibility to print themselves SalesLineItem :SalesLineItem 1*: [for each] sli := next()

26 © Nabor C. Mendonça 2001 26 Padrões n Nome e descrição de um problema comum de domínio e sua respectiva solução – Expresso de modo que o padrão possas ser aplicado a novos contextos e circunstâncias variadas n Capturam princípios fundamentais de engenharia de software n Podem oferecer guias de como responsabilidades devem ser atribuídas a objetos, dada uma categoria específica de problema

27 © Nabor C. Mendonça 2001 27 Padrões n Em geral, não contêm novas idéias nem soluções originais – Codificam soluções existentes comprovadas n Possuem nomes sugestivos – Suportam fácil incorporação ou abstração do conjunto de conceitos representado pelo padão n Facilitam comunicação – Permitem a discussão de um princípio ou conceito complexo através de um único nome

28 © Nabor C. Mendonça 2001 28 Padrões GRASP n Princípios gerais para atribuição de responsabilidades a objetos – Cruciais no POO – Parte da criação de diagramas de interação n Cinco padrões mais comuns: – Especialista (“Expert”) – Criador (“Creator”) – Alta coesão (“High Cohesion”) – Baixo acoplamento (“Low Coupling”) – Controlador (“Controler”)

29 © Nabor C. Mendonça 2001 29 Padrão Especialista n Problema – Qual é o princípio mais básico pelo qual responsabilidades são atribuídas no POO? n Solução – Atribuir responsabilidade para o especialista na informação — a classe que tem a informação necessária para cumprir a responsabilidade. n Exemplo – Quem deve ser responsável por conhecer o total de uma venda? Informação necessária: conhecer todas as instâncias Item-de- Venda da Venda e o subtotal de cada uma delas.

30 © Nabor C. Mendonça 2001 30 n Exemplo (cont.) – Pelo padrão, a classe Venda deve ser a responsável. – Mas quem dever ser responsável por conhecer o subtotal de um Item-de-Venda? Informação necessária: Item-de-Venda.quantidade e Especificação-Produto.preço Padrão Especialista Venda data tempo total() :Venda t := total() Novo método

31 © Nabor C. Mendonça 2001 31 n Exemplo (cont.) – Pelo padrão, a classe Item-de-Venda deve ser a responsável. – Porém, para cumprir essa responsabilidade um Item-de-Venda precisa conhecer o preço do Item. Padrão Especialista Venda data tempo total() :Venda t := total() SalesLineItem sli:LinhaDeVenda LinhaDeVenda quantidade subtotal() 2: st := subtotal() New method :LinhaDeVenda 1*: [para cada] sli := next()

32 © Nabor C. Mendonça 2001 32 n Exemplo (cont.) – Portanto, o Item-de-Venda deve mandar uma mensagem para a Especificação-Produto para saber o preço do item. Padrão Especialista Venda data tempo total() :Venda t := total() sli:inhaDeVenda LinhaDeVenda quantidade subtotal() 2: st := subtotal() :Especificacao Produto 2.1: p := preco() Especificacao Produto descricao preco UPC preco() New method SalesLineItem :LinhaDeVenda 1*: [para cada] sli := next()

33 © Nabor C. Mendonça 2001 33 n Exemplo (cont.) – Concluindo, para cumprir a responsabilidade de conhecer e comunicar o total da venda, três responsabilidades foram atribuídas a três classes de objetos: Padrão Especialista Classe Vendaconhece total da venda Responsabilidade Item-de-Vendaconhece subtotal do item Especificação-Produtoconhecer preço do produto

34 © Nabor C. Mendonça 2001 34 n Benefícios – Mantém encapsulamento (baixo acoplamento) – Comportamento é distribuído através das classes que tem a informação necessária para cumprir a responsabilidade (alta coesão) n Também conhecido como – “Quem sabe, faz” – “Faço eu mesmo” – “Cada serviço com seus atributos” Padrão Especialista

35 © Nabor C. Mendonça 2001 35 Padrão Criador n Problema – Quem deve ser responsável por criar uma nova instância de alguma classe? n Solução – Atribuir à classe B a responsabilidade de criar uma instância da classe A se: n B agrega instâncias de A (*) n B contém instâncias de A (*) n B registra instâncias de A n B usa bem de perto instâncias de A n B tem os dados de inicialização para criar instâncias de A (B portanto é um especialista na criação de A) (*) Priorizar

36 © Nabor C. Mendonça 2001 36 Padrão Criador n Exemplo – Quem deve ser responsável por criar uma instância de Item-de-Venda? – Pelo padrão, Venda deve ser responsável. n Benefícios – Suporta baixo acoplamento. Venda data tempo criarLinhaDeVenda() total() :Venda criarLinhaDeVenda(quantidade) :LinhaDeVenda 1: create(quantidade) New method

37 © Nabor C. Mendonça 2001 37 Padrão Baixo Acoplamento n Problema – Como conseguir menor dependência (entre as classes) e maior reuso? n Solução – Atribuir a responsabilidade de modo que o acoplamento (dependência entre classes) permaneça baixo. n 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)

38 © Nabor C. Mendonça 2001 38 n Exemplo (cont.) – Uma solução melhor, (que preserva baixo acoplamento) é a própria Venda criar o Pagamento: Padrão Baixo Acoplamento :TVp : Pagto :Venda fazerPagto()1: create() 2: addPagto(p) :TV:Venda :Pagto fazerPagto()1: fazerPagto() 1.1. create()

39 © Nabor C. Mendonça 2001 39 n Benefícios – Responsabilidade não é (ou é pouco) afetada por mudanças em outros componentes. – Responsabilidade é mais simples de entender isoladamente. – Maior chance para reuso. Padrão Baixo Acoplamento

40 © Nabor C. Mendonça 2001 40 Padrão Alta Coesão n Problema – Como manter a complexidade (das classes) em um nível “controlável”? n Solução – Atribuir a responsabilidade de modo que a coesão (força do relacionamento entre as responsabilidades de uma classe) permaneça alta n Exemplo – Quem deve ser responsável por criar um Pagamento e associá-lo à Venda? – Pelo padrão Criador, seria TV. Mas se TV for o responsável pela maioria das operações do sistema, ele vai ficar cada vez mais sobrecarregado e não coeso

41 © Nabor C. Mendonça 2001 41 Padrão Alta Coesão n Níveis de coesão – Muito baixa Um classe tem muitas responsabilidades em áreas funcionais bastantes diferentes. – Baixa Um classe é responsável por uma tarefa complexa de uma única área funcional. – Moderada Um classe tem moderadas responsabilidades em uma única área funcional e colabora com outras classes para cumprir suas tarefas. – Alta Um classe tem responsabilidades leves apenas em algumas áreas que estão logicamente relacionadas com o conceito da classe

42 © Nabor C. Mendonça 2001 42 Padrão Alta Coesão n Benefícios – Aumento da clareza e compreensão do projeto – Simplificação de manutenção – Baixo acoplamento – Reuso facilitado

43 © Nabor C. Mendonça 2001 43 Padrão Controlador n Problema – Quem deve ser responsável por tratar um evento do sistema? n Solução – Atribuir a responsabilidade de tratar um evento do sistema para uma classe “controladora” representando: n o sistema como um todo (facade controller) n o negócio ou organização com um todo (facade controller) n uma coisa ou papel de uma pessoa do mundo real envolvida diretamente com a tarefa (role controller) n um “tratador” (handler) artificial para todos os eventos de um caso de uso (use-case controller)

44 © Nabor C. Mendonça 2001 44 Padrão Controlador n Exemplo – No sistema POST, quem deve ser responsável por tratar eventos como entrarItem, encerrarVenda, e fazerPagamento? – Pelo padrão, as escolhas são: :POST enterItem(upc, quantity) :Store enterItem(upc, quantity) :Cashier enterItem(upc, quantity) :BuyItemsHandler enterItem(upc, quantity)

45 © Nabor C. Mendonça 2001 45 Padrão Controlador n Exemplo (cont.) – Pelos padrões Baixo Acoplamento e Alta Coesão, a melhor escolha como controlador é POST TV... terminarVenda() entrarItem() fazerPagto() Sistema terminarVenda() entrarItem() fazerPagto() system operations discovered during system behavior analysis allocation of system operations during design, using the Controller pattern

46 © Nabor C. Mendonça 2001 46 Padrão Controlador n Benefícios – Maior chance de reuso – Melhor controle sobre o estado do caso de uso n Considerações – Não sobrecarregar controlador com um número excessivo de eventos, responsabilidades ou atributos Adicionar mais controladores e/ou delegar responsabilidades – Evitar controladores representando papéis humanos Risco de baixa coesão; responsabilidades devem ser delegadas para objetos contendo a informação necessária (padrão Especialista)

47 © Nabor C. Mendonça 2001 47 Padrão Controlador n Considerações (cont.) – Tratar eventos na camada de aplicação Objetos da IU devem apenas receber eventos, não tratá-los!