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

Da Análise ao Projeto Artefatos de análise capturam os resultados do processo de investigação do domínio do problema Artefatos de projeto capturam uma solução para o problema baseada no paradigma de OO Diagramas de interação e classe de projeto Atribuição de responsabilidades e uso de padrões Artefato Questões Respondidas Casos de uso Quais são os processos do domínio? Modelo conceitual Quais são os conceitos, termos? Diagramas de seqüência Quais são os eventos e operações do sistema? Contratos O que fazem as operações do sistema?

Descrevendo Casos de Uso Reais Um Ciclo de Desenvolvimento Notas a. em paralelo com diag. interação Refin. Plano Sinc. Artefatos Análise Projeto Impl. Teste b. ordem variada 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

Casos de Uso Reais Projeto “real” de um caso de uso em termos de tecnologias concretas de entrada/saída e sua implementação como um todo Referências a janelas, componentes da interface com o usuário, mecanismos de interação, etc. Necessários apenas se desenvolvedor ou cliente requer uma descrição minuciosa da interface com o usuário antes da implementação Alternativa: rascunhos de storyboards para a interface com o usuário, com detalhes sendo adicionados na implementação

Casos de Uso Reais Exemplo: Comprar Itens - Versão 1 Caso de uso: Atores: Propósito: Descrição: Comprar Itens - Versão 1 (apenas com dinheiro) Cliente (Iniciador), Operador Capturar uma venda e seu pagamento em dinheiro. Um Cliente chega no caixa com itens para comprar. O Operador registra os itens e coleta um pagamento com dinheiro. Ao final, o Cliente sai com os itens. Tipo: Referencia: primário e real Funções: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1

Típica Seqüência de Eventos Casos de Uso Reais Exemplo: Comprar Itens - Versão 1 (cont.) Típica Seqüência de Eventos Ação do Ator Resposta do Sistema 1. Este caso de uso começa quando um Cliente chega no caixa com itens para comprar. 2. Para cada item, o Operador digita o UPC em A da Janela-1. Se tem mais de um do mesmo item, ele pode opcionalmente digitar a quantidade em E. Ao final de cada item, ele pressiona H. 3. Determina o preço do item e adiciona informação sobre o item à transação de venda em anda-mento. Mostra a descrição e o preço do item corrente em B e F da Janela-1. 4. Após o último item ter sido processado, o Operador indica final de venda pressionando I. 5. Calcula total da venda e mostra em C. 6. ... .

Definindo Diagramas de Interação Um Ciclo de Desenvolvimento Notas a. em paralelo com diag. interação Refin. Plano Sinc. Artefatos Análise Projeto Impl. Teste b. ordem variada 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

Diagramas de Interação Um diagrama de interação ilustra as interações de mensagens entre instâncias (e classes) no modelo de classes Atribuição de responsabilidades aos objetos Ponto de partida é o cumprimento das pós- condições especificadas nos contratos de operação A UML defines dois tipos (equivalentes) de diagramas de interação: Diagramas de colaboração Diagramas de seqüência

Tipos de Diagramas de Interação Diagrama de colaboração Ilustra interações num formato de grafo ou rede Diagramas de seqüência Ilustra interações num formato de colunas ou cerca 1: message2() message1() 2: message3() :ClassAInstance :ClassBInstance :ClassAInstance :ClassBInstance message2() message3() message1()

Diagramas de Colaboração 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

Como Fazer um Diagrama de Colaboração 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 responsabilidades e 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.

Diagramas de Colaboração e Outros Artefatos Cashier System enterItem (upc, quantity) endSale() makePayment (amount) Collaboration Diagrams Sequence Diagram Operation: enterItem Postconditions: 1. If a new sale, a new Sale has been created... Operation: makePayment 1. ... Contracts :POST enterItem(upc, qty) makePayment(amount)

1: addPayment(cashTendered) Notação Básica Classes e instâncias Links 1: addPayment(cashTendered) :POST :Sale msg1() link line

Notação Básica Mensagens Parâmetros 1: message1() 2: message2() :POST :Sale msg1() all messages flow on the same link 1: addPayment(amount: Money) :POST :Sale msg1() parameters

Notação Básica Valor de retorno Sintaxe alternativa 1: tot := total(): Integer :POST :Sale msg1() return value type return value name 1: addPayment(cashTendered) :POST :Sale msg1() standard UML message syntax 1: addPayment: cashTendered msg1 Smalltalk syntax

Notação Básica Mensagem para “self” ou “this” Iteração 1*: li := nextLineItem(): SalesLineItem :POST :Sale msg1() iteration recurrence values omitted

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

Notação Básica Criação de instância 1: create(cashier) :POST :Sale msg1() create message, with optional initializing parameters new created instance «new» "«new»" is optionally allowed for emphasis

Notação Básica Seqüenciamento de mensagens :ClassA msg1() :ClassB :ClassC 1.1: msg3() not numbered legal numbering

Notação Básica Seqüenciamento complexo de mensagens ;ClassA msg1() :ClassB 1: msg2() :ClassC 1.1: msg3() 2.1: msg5() 2: msg4() :ClassD 2.2: msg6() first second fourth sixth fifth third

conditional message, with test Notação Básica Mensagens condicionais 1: [new sale] create() :POST :Sale :SalesLineItem 1.1: create() msg1() conditional message, with test

exclusive conditional paths Notação Básica Caminhos condicionais mutuamente exclusivos 1a: [test1] msg2() :ClassA :ClassB :ClassC 1a.1: msg3() msg1() :ClassD 1b: [not test1] msg4() 1b.1: msg5() :ClassE 2: msg6() unconditional after either msg2 or msg4 1a and 1b are mutually exclusive conditional paths

Notação Básica Coleções (multiobjects) Mensagens para uma coleção

Notação Básica Mensagens para uma coleção e um elemento 1: create() :Sale sl: SalesLineItem SalesLineItem :SalesLineItem 2: addElement(sl) msg1() 2: print() 1: sl := get(key)

Notação Básica Mensagens para um objeto classe

Responsabilidades e Métodos Responsabilidade é “um contrato ou obrigação de um tipo ou classe” [Booch et al.’97] Relacionada com o comportamento dos objetos 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

Responsabilidades e Métodos 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) 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”

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 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

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

Padrões 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 Capturam princípios fundamentais de engenharia de software Podem oferecer guias de como responsabilidades devem ser atribuídas a objetos, dada uma categoria específica de problema

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

Padrões GRASP Princípios gerais para atribuição de responsabilidades a objetos Cruciais no POO Parte da criação de diagramas de interação Cinco padrões mais comuns: Especialista Criador Alta coesão Baixo acoplamento Controlador

Padrão Especialista Problema Solução Exemplo Qual é o princípio mais básico pelo qual responsabilidades são atribuídas no POO? Solução Atribuir responsabilidade para o especialista na informação — a classe que tem a informação necessária para cumprir a responsabilidade. 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.

Padrão Especialista 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 Sale date time total() :Sale t := total() New method

1*: [for each] sli := next() Padrão Especialista 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. Sale date time total() :Sale t := total() SalesLineItem sli:SalesLineItem quantity subtotal() 2: st := subtotal() New method :SalesLineItem 1*: [for each] sli := next()

1*: [for each] sli := next() Padrão Especialista Exemplo (cont.) Portanto, o Item-de-Venda deve mandar uma mensagem para a Especificação-Produto para saber o preço do item. Sale date time total() :Sale t := total() sli:SalesLineItem SalesLineItem quantity subtotal() 2: st := subtotal() :Product Specification 2.1: p := price() Product description price UPC price() New method :SalesLineItem 1*: [for each] sli := next()

Padrão Especialista 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: Classe Responsabilidade Venda conhece total da venda Item-de-Venda conhece subtotal do item Especificação-Produto conhecer preço do produto

Padrão Especialista Benefícios Também conhecido como 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) Também conhecido como “Quem sabe, faz” “Faço eu mesmo” “Cada serviço com seus atributos”

Padrão Criador Problema Solução Quem deve ser responsável por criar uma nova instância de alguma classe? Solução Atribuir à classe B a responsabilidade de criar uma instância da classe A se: 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) (*) Priorizar

makeLineItem(quantity) Padrão Criador Exemplo Quem deve ser responsável por criar uma instância de Item-de-Venda? Pelo padrão, Venda deve ser responsável. Benefícios Suporta baixo acoplamento. Sale date time makeLineItem() total() :Sale makeLineItem(quantity) :SalesLineItem 1: create(quantity) New method

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

Padrão Baixo Acoplamento Exemplo (cont.) Uma solução melhor, (que preserva baixo acoplamento) é a própria Venda criar o Pagamento: :POST p : Payment :Sale makePayment() 1: create() 2: addPayment(p) :POST :Sale :Payment makePayment() 1: makePayment() 1.1. create()

Padrão Baixo Acoplamento 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 Alta Coesão Problema Solução Exemplo Como manter a complexidade (das classes) em um nível “controlável”? Solução Atribuir a responsabilidade de modo que a coesão (força do relacionamento entre as responsabilidades de uma classe) permaneça alta. 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 sobrecarredado e incoeso.

Padrão Alta Coesão Níveis de coesão Muito baixa Baixa Moderada Alta 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

Padrão Alta Coesão Benefícios Aumento da clareza e compreensão do projeto Simplificação de manutenção Baixo acoplamento Reuso facilitado

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

enterItem(upc, quantity) Padrão Controlador 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 :Cashier :BuyItemsHandler

Padrão Controlador Exemplo (cont.) Pelos padrões Baixo Acoplamento e Alta Coesão, a melhor escolha como controlador é POST POST ... endSale() enterItem() makePayment() System system operations discovered during system behavior analysis allocation of system operations during design, using the Controller pattern

Padrão Controlador Benefícios Considerações Maior chance de reuso Melhor controle sobre o estado do caso de uso 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)

1.1: makeLineItem(upc, qty) Padrão Controlador Considerações (cont.) Tratar eventos na camada de aplicação Objetos da IU devem apenas receber eventos, não tratá-los! Object Store Enter Item End Sale UPC Make Payment Total Quantity Tendered Balance :POST Cashier :POSTApplet presses button onEnterItem() 1: enterItem(upc, qty) :Sale 1.1: makeLineItem(upc, qty) Presentation Layer (Java applet) Domain Layer system event message controller