ELABORAÇÃO. GRASP General Responsibility Assignment Software Patterns. Core of OODesign. Artefactos de input para OOD

Transcrição

1 Core of OODesign ELABORAÇÃO Após identificar os requisitos e desenhar o modelo de domínio, a seguir adicionar métodos às classes de software e definir as mensagens entre os objectos para dar resposta aos requisitos A ferramenta de Desenho (Design) crítica para o desenvolvimento de software, é uma mente bem educada nos princípios de Design (não é a UML ou outra tecnologia qualquer) Artefactos de input para OOD Imagine se que o cenário do exemplo do NewPOS é o seguinte, nesta altura. Nota: Nem todos os artefactos são necessários, pois no UP tudo é opcional. GRASP General Responsibility Assignment Software Patterns A primeira workshop de levantamento de requisitos, com duração de dois dias, está terminada Três dos vinte casos de uso (aqueles que são arquitecturalmente relevantes e de alto valor de negócio), foram analisados em detalhe, incluindo, claro, o use case do processo de venda. Experiências de programação resolveram algumas questões técnicas relevantes como sejam, se o UI Java Swing trabalhava num monitor de touch screen. O arquitecto chefe e de negócio concorda em implementar e testar alguns cenários do Processo de Venda na primeira iteração, timeboxed, de três semanas Outros artefactos foram iniciados: Especificações Suplementares, Glossário e o Modelo de Domínio. O arquitecto chefe desenhou algumas ideias para a arquitectura lógica de larga escala, usando diagramas de package em UML. Isto é parte do Modelo de Desenho no UP.

2 Cashier Process Sale Artefactos de input para OOD Relações entre artefactos no UP Sample UP Artifact Relationships O use case em texto define o comportamento visível, que os objectos de software devem suportar osobjectos são desenhados para realizar (implementar) os use cases. No UP, este desenho OO é chamado realização de caso da uso. Os Diagramas de Sequencia do Sistema identificam as mensagens de operação do sistema, que são as mensagens iniciais nos diagramas de interacção dos objectos em colaboração Os contratos de operação podem complementar os casos de uso em texto, para clarificar o que é que os objectos de software devem efectuar numa operação do sistema. As pós condições definem objectivos detalhados A Especificação Suplementar define os requisitos não funcionais (URPS+), que os objectos devem suportar O glossário clarifica parâmetros ou dados provenientes do nível de UI, dados a passarem para a BD e requisitos de validação ou lógica específica, tal como formatos legais e validação para UPCs dos produtos O Modelo de Domínio sugere alguns nomes e atributos de objectos no nível de domínio da arquitectura de software Business Modeling Requirements inspiration for names of some software domain objects starting events to design for, and detailed postcondition to satisfy Design Domain Model Sale..* Sales... LineItem date quantity Use-Case Model Process Sale use. Customer Supplementary case arrives Specification names Cashier enters item identifier. non-functional functional requirements Use Case Diagram Use Case Text requirements that must be domain rules ideas for system realized by the postconditions events the objects : System Glossary Operation: : Cashier enteritem( ) make system NewSale() Post-conditions: operations enteritem -... (id, quantity) item details, formats, Operation Contracts System Sequence Diagrams validation Design Model : Register : ProductCatalog : Sale enteritem (itemid, quantity) d = getproductdescription(itemid) addlineitem( d, quantity ) Register ProductCatalog makenewsale() * getproductdescription() enteritem() Actividades do Desenho de Objectos Responsability Driven Design (RDD) Sai o analista Entra o Modelador Desenhador Na abordagem RDD os objectos têm responsabilidades (uma abstracção do que eles fazem) Começar imediatamente t o desenvolvimento (idealmente utilizando a abordagem Teste First Development) Começar outras técnicas de modelação como por exemplo Cartas CRC Começar alguma modelação UML dos objectos do desenho Desenhar Diagramas de Interacção (modelo dinâmico) ~ dia Diagramas de Classe (modelo estático) Aplicar princípios ou padrões GRASP e GoF durante o desenho e codificação A abordagem a modelação OOD é baseada na metáfora Responsability Driven Design (RDD) pensar como atribuir responsabilidades aos objectos As responsabilidades são atribuídas a classes de objectos durante o desenho dos objectos RDD é uma metáfora para ajudar o processo de desenho de software OO. Pensar em objectos de software de forma similar em como pensamos em pessoas com responsabilidades que colaboram com outras pessoas para executarem o seu trabalho Uma responsabilidade não é o mesmo que um método, é uma abstracção, mas os métodos implementam responsabilidades 2

3 Tipos de Responsabilidades RDD >> Colaboração As responsabilidades de fazer, de um objecto incluem: Fazer algo ele próprio, tal como criar um objecto ou efectuar um cálculo Iniciar acções noutros objectos Controlar e coordenar actividades noutros objectos A abordagem RDD inclui a ideia de colaboração. As responsabilidades são implementadas através de métodos, que actuam sozinhos ou colaboram com outros métodos e objectos As responsabilidades de saber de um objecto incluem: Ter conhecimento de dados privados encapsulados Ter conhecimento de objectos relacionados Ter conhecimento de coisas que pode derivar ou calcular Ex.: Uma Venda é responsável por criar LinhasDeVenda (um fazer ) Uma Venda é responsável por saber o seu total (um saber ) Ex: A classe Venda pode definir um ou mais métodos para saber o seu total, por exemplo um método chamado GetTotal. Para dar resposta a essa responsabilidade a Venda pode colaborar com outros objectos, tal como enviar uma mensagem GetSubtotal para cada objecto LinhaDeVenda a solicitar o seu subtotal. Guidelines RDD GRASP Para objectos do domínio do software, o Modelo de Domínio é uma fonte de inspiração para as responsabilidades do saber. Ex: Uma Venda no MD tem um atributo datahora. É natural que a classe de software saiba a sua data e hora. A tradução de responsabilidades em classes e métodos é influenciada pela granularidade da responsabilidade Grandes responsabilidades podem incluir centenas de classes e métodos GRASP: General Responsibility Assignment Software Patterns GRASP é uma abordagem metodológica ao Desenho OO Os princípios ou padrões subjacentes ao GRASP são um auxiliar para perceber o essencial do desenho de objectos e aplicar o raciocínio de desenho de uma forma metodológica, racional e perceptível. A abordagem GRASP é baseada em padrões de atribuição de responsabilidades Pequenas responsabilidades podem incluir apenas um método 3

4 Responsabilidades >> GRASP >> UML Padrões (Patterns) O que são? Podemos pensar sobre as responsabilidades a atribuir, ou seja aplicar o GRASP, durante várias fases, nomeadamente, na codificação e na modelação Programadores e arquitectos de software experientes em OO foram criando um conjunto de princípios gerais e soluções idiomáticas para se suportarem na criação de software Em UML, no desenho dos Diagramas de Interacção são o meio para considerar estas responsabilidades Quando desenhamos os DI, estamos a decidir sobre quais as responsabilidades a atribuiraa cada objecto Estes princípios que são designados por padrões de desenho são apresentados de uma forma estruturada que descreve o problema, a solução e têm um nome Muitos padrões, dada um tipo de problema, orientam na atribuição das responsabilidades Exemplo: GRASP >> UML Padrões >> Estrutura >> Exemplo :: Venda Sale EfectuarPagamento(valorEntregue) makepayment(cashtendered) Create(valorEntregue) create(cashtendered) : Pagamento Payment Nome do Padrão: Problema: Information Expert Qual é o principio básico para atribuição de responsabilidades a objectos abstract, Implica que implies o objecto Sale Venda objects tem ahave a responsibility responsabilidade s to de create criar e Pagamentos Payments Solução: Atribuir a responsabilidade a uma classe que tenha a informação para dar resposta a essa responsabilidade 4

5 Padrões GRASP >> CREATOR Creator >> Exemplo Nome do Padrão: Creator Problema: Quem deve ser responsável por criar uma nova instanciade umaclasse? A classe Venda contém (na realidade agrega) muitos objectos LinhasDeVenda. O padrão Creator sugere por esta via que Venda é um bom candidato para ter a responsabilidade de criar as instâncias i LinhaDeVenda Solução: Atribuir à classe B a responsabilidade para criar a instância da classe A, se uma as seguintes situações for verdadeira (quantas mais melhor) B contém ou agrega compositamente A B armazena A B usa A de forma próxima B tem os dados de inicialização de A, que lhe serão passados quando for criado. Assim B é um Expert em relação a cria A Esta atribuição faz com que o método MakeLinhaDeVenda seja definido na Venda Notar que as responsabilidades são atribuídas enquanto se desenha o DI. A secção dos métodos nas classes do DC, podem depois sumarizar as responsabilidades atribuídas Creator >> Exemplo Creator >> Exemplo Exemplo: Quem deve responsável por criar a instância SalesLineItem no projecto NewPOS? O DI seria então: Considerar o modelo de domínio parcial que foi desenhado: : Register : Sale Sale time makelineitem(quantity) create(quantity) : SalesLineItem Contains Sales LineItem quantity..* * Described-by Product Description description price itemid 5

6 Creator >> Orientações Padrões GRASP >> Expert O Creator orienta a atribuir as responsabilidades relacionadas com a criação dos objectos A escolha do Creator deve obedecer a critérios de low coupling (baixo acoplamento) Composito, agrega Parte, Contentor contém Conteúdo e Gravador (Recorder) grava Gravação. Estas são relações muito comuns entres classes num DI. O Creator sugere que as classes Composito, Contentor ou Gravador são boas candidatas para assumirem a responsabilidade de Criarem a coisa contida ou gravada Nome do Padrão: Information Expert (or Expert) Problema: Qual é o principio geral para atribuição de responsabilidades a objectos? Solução: Atribuir a responsabilidade ao Information Expert A classe que tem a informação necessária para satisfazer a responsabilidade Creator >> Orientações Muitas vezes identificamos o Creator, procurando a classe que tem os dados de inicialização do que são passados durante a criação (Expert pattern) Ex.: A instância pagamento quando e criada necessita de ser inicializada com o total da Venda. Assim sendo que classe é a melhor Candidata para criar a instância Pagamento? É a Venda Quando a criação requer um esforço significativo de complexidade, como por exemplo a criação condicional de instâncias de uma família de classes similares baseadas numa qualquer propriedade externa, é aconselhável delegar a criação em classes auxiliares chamadas Concrete Factory ou Abstract Factory Expert >> Exemplo Exemplo: Quem deve responsável por saber o grande total de uma Venda? Considerar o modelo de domínio parcial que foi desenhado: time Sale Sales LineItem quantity Contains..* * Described-by Product Description description price itemid Pelo principio Information Expert devemos procura a classe que tem a informação necessária que é necessária para calcular o Total 6

7 Expert >> Exemplo Expert >> Exemplo Onde devemos procurar as classes que tem a informação necessária? No Modelo de Domínio ou no Modelo de Desenho? Se existirem i classes relevantes no modelo dl de domínio começar por aí Se não, procurar no modelo de desenho e tentar usar ou expandir as suas representações para inspirar a criação de classes reais 2 ) Mas para calcular os subtotais precisamos ainda da informação LinhaDeVenda.Quantidade e Descriçãoproduto.preço A Linha de venda sabe a sua quantidade e está associada à DescriçãoProduto. Assimpelo Expert a LinhaDeVenda calcula o subtotal ) Neste exemplo podemos olhar para o MD e talvez considerar que a classe Venda preenche os requisitos necessários. Assim criamos uma classe similar Venda no Modelo Desenho atribuirmos lhe a responsabilidade de saber o total expresso pelo método GetTotal t = GetTotal *: st = GetSubtotal t gettotal *: st getsubtotal linhasprodutos[ lineitems[ i i ] : : : Venda Sale SalesLineItem LinhaDeVenda : Sale Venda time datahora gettotal() : SalesLineItem LinhaDeVenda quantity quantidade New Novo method Método getsubtotal() GetSubtotal( ) O DI será então: Expert >> Exemplo Expert >> Exemplo 3 ) Mas para satisfazer a responsabilidade de calcular o subtotal a classe LinhaDeVenda precisa de saber o preço t = GetTotal) gettotal t E a classe de software no MCD será: ::Sale Venda Assim a classe DescriçãoProduto, é um InformationExpert em disponibilizar e saber o preço. t = GetTotal *: st = GetSubtotal t gettotal *: st getsubtotal linhasprodutos[ lineitems[ i i ] : : : Venda Sale SalesLineItem LinhaDeVenda..: : p p = := GetPreço( getprice() ) e : Sale Venda :Product : DescriçaoProduto Description New Novo method método time datahora gettotal() : Sale Venda time datahora : SalesLineItem LinhaDeVenda quantity quantidade Product DescriçaoProduto Description description descrição price preço itemid produtoid gettotal() getsubtotal() GetSubtotal( ) New Novo method Método getprice() GetPreço( ) 7

8 Expert >> Resumo Exemplo Para satisfazer a responsabilidade de saber e disponibilizar o total da venda, atribuímos três responsabilidades a três classes de software: Padrões GRASP >> Low Coupling Nome do Padrão: Low Coupling Problema: Como suportar baixa dependência, baixo impacto à mudança e aumentar a reutilização? Classe de Desenho Venda LinhaDeVenda DescriçãoProduto Responsabilidade Sabe o total da venda Sabe o subtotal de uma linha Sabe o preço do produto Solução: Atribuir a responsabilidade de forma a que o acoplamento se mantenha baixo. Usar este princípio na avaliação de alternativas. Nota: Decidimos atribuição das responsabilidades ao desenharmos um DI. E de seguida fizemos reflectir os métodos relativos a essas responsabilidades no DCS Creator >> Orientações Padrões GRASP >> Low Coupling O Expert expressa a intuição de que os objectos fazem coisas relacionadas com a informação que têm A satisfação de uma responsabilidade requer muitas vezes informação que está dispersa por diferentes classes de objectos, o que implica que muitosinformation Expert parciais colaborem nessa tarefa Em algumas situações o Expert mais óbvio, não é a melhor solução devido a problemas com o acoplamento e coesão (princípios a ver) E.g.: Que classe é responsável por gravar uma venda na base de dados? Se for a venda, como seria mais óbvio, a coesão baixa pois a classe passa a estar focada no que tem de fazer e por outro lado o acoplamento aumenta, pois passa a estar acoplada a serviços técnicos de base de dados em vez de estar acoplada apenas a outros objectos no nível de domínio dos objectos de software Acoplamento é uma medida para medir quão forte um elemento está ligado, tem conhecimento de ou depende de outros elementos Uma classe de alto acoplamento depende de muitas outras o que é indesejável e algumas delas sofrem dos seguintes problemas: Alterações locais forçadas devido a alterações em classes relacionadas Difíceis de perceber se isoladas Difíceis de utilizar porque requerem a presença adicional das classes das quais são dependentes 8

9 Low Coupling >> Exemplo Exemplo: Considerar o seguinte DC parcial do projecto NewPOS Pagamento Registadora Venda Se se pretender criar uma instância de Pagamentos e associá la com a Venda correspondente, qual deve ser a classe responsável por isso? Low Coupling >> Exemplo Qual das soluções anteriores apresenta menor acoplamento? Em ambas existe acoplamento da Venda a Pagamento, mas no segundo caso ao atribuirmos à Venda a responsabilidade de criar o Pagamento estamos a diminuir o acoplamento pois a Registadora deixa de estar acoplada a Pagamento. No domínio do mundo real, é a classe Registadora que grava um pagamento, o padrão Creator sugere a classe Registadora como uma candidata para criar a instância Pagamento. De seguida a Registadora pode enviar uma mensagem à classe Venda com o novo pagamento como parametro Low Coupling >> Exemplo EfectuarPagamento( ) : Registadora : Create( ) 2: Addpagamento(p) p : Pagamento : Venda Esta atribuição de responsabilidade acopla a classe registadora à classe Pagamento Outra via alternativa seria: EfectuarPagamento( ) EfectuarPagamento( ) : Registadora : Venda Low Coupling >> Orientações Na prática o nível de acoplamento não pode ser considerado de forma isolada de outros padrões (princípios) como por exemplo Expert ou High Cohesion. Ainda assim é um factor a considerar na melhoria do desenho. O padrão Low Coupling deve estar presente em todas as decisões de desenho. É um objectivo a perseguir constantemente. É um princípio de avaliação a usar em todas as decisões do desenho. :Create( ) Pagamento 9

10 Low Coupling >> Orientações Linguagens de programação como Java, C++ ou C# podem formar vários acoplamentos TypeX para TypeY dos tipos: TypeX tem um atributo que se refere a uma instância do TypeY ou mesmo de TypeY Um objecto TypeX chama serviços de um objecto TypeY TypeX tem um método que referencia uma instância do TypeY, ou mesmo de TypeY. Tipicamente isto inclui um parâmetro ou variável local do TypeY ou um objecto retornado de uma mensagem, que é deumainstância i do TypeY TypeX é uma subclasse directa ou indirecta de TypeY TypeY é uma interface e TypeX implementa essa interface Low Coupling >> Orientações O caso extremo de low coupling é nenhum acoplamento!! Mas isso é contra o paradigma da OO, que diz que este é um sistema de objectos colaborante que comunicam entre si por mensagens. A virtude está numa avaliação constante dos vários princípios. Low Coupling >> Orientações Uma subclasse é fortemente acoplada à sua superclasse. Sempre que se derivar de uma superclasse deve ter se em atenção o forte acoplamento Se por exemplo existem objectos que devem ser guardados persistentemente numa BD, pode se optar por utilizar o padrão de desenho e criar uma superclasse PersistentObject da qual todas as outras derivam. A desvantagem é que acopla objectos do domínio a um serviço técnico particular e mistura diferentes preocupações específicas das várias arquitecturas, mas tem a vantagem de uma hereditariedade automática para o comportamento persistente. Padrões GRASP >> High Cohesion Nome do Padrão: High Cohesion Problema: Como manter os objectos focados, compreensíveis e geriveis e como efeito colateral suportarem baixo acoplamento? Solução: Atribuir a responsabilidade de forma a que a coesão se mantenha o mais alta possível. Utilizar este padrão para avaliar alternativas. Nota: Em termos de desenho de objectos, a coesão é uma medida de quão fortemente relacionadas e focadas as responsabilidades de um elemento são 0

11 Padrões GRASP >> High Cohesion Uma classe com baixa coesão faz muitas coisas não relacionadas umas com as outras ou faz muito trabalho. Tais classes são indesejáveis, elas têm os seguintes problemas: Difíceis de compreender Difíceis de reutilizar Difíceis de manter Delicadas. São constantemente afectadas pela mudança High Cohesion >> Exemplo Na opção ) a atribuição de responsabilidades coloca a responsabilidade de efectuar um pagamento na Registadora. A registadora está envolvida em parte da responsabilidade de satisfazer a operação do sistema EfectuarPagamento Este exemplo por si só é aceitável, mas se continuarmos a fazer com que a registadora seja responsável por efectuar a maior parte do trabalho relacionado com operações do sistema, ficará cada vez mais pesado e torna se não coeso. Ao delegar se o pagamento na Venda está se a suportar uma maior coesão na registadora. Por ser mais coeso e com menos acoplamento a opção 2 é melhor ) Low Coupling >> Exemplo Vejamos novamente o exemplo usado para estudar o Low Coupling e vamos analisá lo do ponto de vista do High Cohesion As alternativas são: EfectuarPagamento( ) : Registadora : Create( ) p : Pagamento High Cohesion >> Orientações A alta coesão tem uma analogia na vida real: É facilmente observável que se uma pessoa tiver demasiadas responsabilidades não relacionadas, principalmente aquelas que poderiam facilmente ser delegadas noutros, essa pessoa torna se ineficaz. 2) 2: Addpagamento(p) EfectuarPagamento( ) EfectuarPagamento( ) : Venda : Registadora : Venda. :Create( ) Pagamento Um dos princípios clássicos do desenvolvimento de software éfazê lo com a maior modularidade possível. A coesão e o baixo acoplamento promovem a modularidade, pois: A modularidade é a propriedade de um sistema poder ser decomposto num conjunto de módulos coesos e de baixo acoplamento [Booch94]