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

Prof. Msc. Emerson Silas Dória Da Análise ao Projeto Artefatos de análise capturam os resultados do processo de investigação do domínio do problema Casos de Uso Quais são os processos do domínio? Modelo Conceitual Quais são os conceitos, termos? Diagramas de Seqüência do Sistema Quais são os eventos e operações do sistema? Contratos O que fazem as operações do sistema? Prof. Msc. Emerson Silas Dória

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

Descrevendo Casos de Uso Reais Sinc. Artefatos Análise Projeto Teste Refin. Plano Impl. 2. Definir Rel. & IU 4. Definir Diag. Interaçã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 diagrama de interação b. ordem variada Prof. Msc. Emerson Silas Dória

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

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

Seqüência Típica de Eventos Casos de Uso Reais Object Store Entrar Item UPC Total Quantidade Fornecido Troco A C E G H Terminar Venda I Registrar Pagamento J Preço Descrição B D F 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

Definindo Diagramas de Interação Refin. Plano Sinc. Artefatos Análise Projeto 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 Prof. Msc. Emerson Silas Dória

Prof. Msc. Emerson Silas Dória 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. Pós-condições: Se for uma nova venda, uma Venda foi criada (criação de instância); Se for uma nova venda, a nova Venda foi associada ao POST (formada uma associação); Um ItemVenda foi criado (criação de instância); O ItemVenda foi associado à Venda (formada uma associação); . . . Prof. Msc. Emerson Silas Dória

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

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

Diagramas de Interação Diagramas de Colaboração Ênfase na organização estrutural dos objetos que enviam e recebem mensagens :Instância_ClasseA :Instância_ClasseB 1: mensagem2( ) 2: mensagem3( ) mensagem1( ) 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

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

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

Diagramas de Colaboração 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); Sistema EntrarItem(UPC, quantidade) TerminarVenda() RegistrarPagamento(quantia) EntrarItem(UPC,quantidade) :Sistema Operador DSS Operações do Contratos Operação: TerminarVenda 1. Venda.Completada recebe o valor... Diag. Colaboração :POST EntrarItem(UPC, quantidade) Prof. Msc. Emerson Silas Dória

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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( ) :Venda iv:ItemVenda 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

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

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

Padrão Especialista (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

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

Padrão Especialista (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. :ItemVenda :Venda t:obter_total( ) iv:ItemVenda 2:st:=obter_subtotal() 1*:[para cada]iv:next( ) Venda data hora obter_total( ) Aqui ocorrem as definições de responsabilidade. ItemVenda quantidade obter_subtotal() Prof. Msc. Emerson Silas Dória

Padrão Especialista (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. t:obter_total( ) :Venda 1*:[para cada]iv:next( ) Venda data hora, status obter_total( ) Aqui ocorrem as definições de responsabilidade. ItemVenda quantidade obter_subtotal() EspecificaçãoProduto descrição preço UPC obter_preço( ) 2:st:=obter_subtotal( ) iv:ItemVenda :ItemVenda :ItemVenda 2.1:p:=obter_preço( ) :Especificação Produto Prof. Msc. Emerson Silas Dória

Padrão Especialista (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: Classe Venda Conhecer total da venda Responsabilidade ItemVenda Conhecer subtotal do item EspecificaçãoProduto Conhecer preço do produto Prof. Msc. Emerson Silas Dória

Padrão Especialista (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

Padrão Criador (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

Padrão Criador (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 Venda data hora criar_iv( ) obter_total( ) 1:criar_iv(quantidade) :ItemVenda Benefícios (garante baixo acoplamento) Prof. Msc. Emerson Silas Dória

Padrão Baixo 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

Padrão Baixo 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) :POST RegistrarPagamento( ) p:Pagamento 1:criar( ) :Venda 2:adicionar_pagamento (p) Prof. Msc. Emerson Silas Dória

Padrão Baixo 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: :POST RegistrarPagamento( ) :Venda 1:RegistrarPagamento( ) :Pagamento 1.1:criar( ) Prof. Msc. Emerson Silas Dória

Padrão Baixo 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

Padrão Alta 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

Padrão Alta 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. :POST RealizarPagamento( ) :Venda adicionar_pagamento (p) p:Pagamento criar( ) Prof. Msc. Emerson Silas Dória

Padrão Alta 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

Padrão Alta 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

Padrão Alta 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

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