Projeto: notações; patterns

GA-031 Professor: Antônio Tadeu Azevedo Gomes

Email: atagomes@gmail.com Site: http://wiki.martin.lncc.br/atagomes-cursos-lncc-ga031

1

Mapeamento arquitetura ->

projeto -> implementação

(mais sobre estratégias de implementação na Parte 4…)

2

Notações

3

UML

4

Ferramenta para projeto de software

Detalhamento da visão de módulos usando diagramas de classes

Porque UML (parte 2)?Notação orientada a objetos

Passível de transformações modelo-código

Linguagem auto-definida (metamodelo UML)

Extensível (perfis UML)

Executável (!)5

Metamodelo UML6

7

Perfis UML

Permite adequar UMLa domínios e estilos/patterns específicos

Por que NÃO UML?Redundância e irrelevância Aprendizado não necessariamente trivial Incoerência semântica Abuso no uso dos mecanismos de extensibilidade

8

“UML: The Positive Spin”

9

I have followed the T.A.'s advice. For example there might be nice things to say about the notation itself. It might be simple, useful, convincing, easy to learn. (...) Of course

UML has none of these properties. In its attempt to show that it has included everyone's pet ideas, it is a chock-full of symbol after bizarre symbol. Just the

"Notation Summary" takes up 60 pages and has its own table of contents! UML is in fact as complex as a big and cryptic programming language, with generous use of "$" and "#" and "-" and "*" and "solid triangles with no tail" and rectangles and diamonds and solid lines and dotted lines and solid ellipses and dotted ellipses and arrows of all kinds and keywords such as "const" and "sorted" (not to be confused with "ordered")

and different semantics for a class depending on whether its name appears in roman or italics; but at least a programming language, even the worst of languages, is

executable! Here you have to learn all this monstrous complexity just to build diagrams of a possible future system. (...)

http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html

Alternativas a UML na fase de projeto?

10

Koala Fractal RTSC (Real-Time Software Components) BON (Business Object Notation) DSLs (Linguagens de domínio específico)

Patterns

11

12

Relembrando: Categorias de padrões

Padrões (ou estilos) arquiteturais [Buschmann et al., 1996] Expressam aspectos estruturais do sistema de software como um todo Ex: Cliente-servidor, Camadas, Pipelines etc.

Padrões de projeto [Gamma et al., 1995] Expressam aspectos estruturais ou comportamentais de partes do sistema de software Ex: Composite, Observer, Factory method etc.

Idiomas Expressam aspectos de implementação em uma linguagem de programação Ex: Cópia de string em C e Pascal, Smart pointers em C++

13

Catálogos de padrões de projeto

Há dois catálogos de propósito geral mais conhecidos:

POSA vol. 1 [Buschmann et al., 1996]: independente de paradigma de desenvolvimento, englobando também estilos e idiomas GoF [Gamma et al., 1995]: baseado no paradigma de desenvolvimento orientado a objetos

Muitos dos padrões de projeto presentes nesses catálogos são similares ou mesmo equivalentes

Catálogos de padrões de projeto (cont.)

Há vários catálogos de propósito específico: POSA

vol. 2: elementos concorrentes e em rede vol. 3: gerência de recursos vol. 4: computação distribuída

Patterns for Parallel Programming

14

Ecossistema de padrões

POSA (vol. 1)

15

Decomposição estrutural Organização de trabalho

Controle de acesso Gerenciamento Comunicação

16

Alguns padrões POSAMaster-slave: oferece suporte para computação paralela, tolerância a falhas e/ou acurária computacional. Aplica a ideia do princípio de “Dividir e Conquistar” onde o trabalho é dividido em sub-tarefas que são processadas de modo independente por cada elemento Passagem de tokens: oferece suporte para computação concorrente. Tokens são trocados entre componentes de tal forma que somente componentes de posse de um token podem efetuar uma dada operação

Alguns padrões POSA (cont.)

Single Sign-on: permite que um elemento delegue a outro seus direitos de acesso a um certo recurso. O delegado pode então agir em nome do delegador Extension Interface: permite que múltiplas interfaces sejam exportadas por um componente sem conhecimento prévio dos clientes

17

18

Padrão Master-slaveUm elemento central (master) distribui trabalho a outros elementos (slaves)

Exemplos:

Problema do Caixeiro-Viajante (teoria de grafos)

Transformada discreta de cosseno (DCT) de uma imagem

Correlação cruzada de sinais

Fatoração de grandes números em fatores primos

19

Padrão Single-Sign OnUm elemento cliente (Client) delega a um elemento intermediário (SSODelegator) suas credenciais de acesso, que podem ser usadas pelo elemento servente (ServiceProvider) de forma restrita (p.ex. validade limitada, permissões reduzidas)

Exemplos:

Certificados proxy em grades computacionais (p.ex. Globus)

Autenticação de aplicações via provedores de identidade (p.ex. Facebook)

queryInterface()

operation()

20

Padrão Extension Interface

Permite que um mesmo elemento (servant) ofereça múltiplas interfaces, prevenindo o “inchamento” de interfaces ou a incompatibilização com clientes quando a funcionalidade do elemento é estendida ou modificada

O elemento oferece a operação QueryInterface(), presente em todas as interfaces do elemento, que dá acesso às outras interfaces do mesmo

Exemplos: COM XPCOM CORBA CCM

Client Servant

Ecossistema de padrões GoF

De criação Estrutural

Comportamental

21

*

22

Padrões de CriaçãoAbstract Factory: provê uma interface para criar famílias de objetos relacionados, sem especificar suas classes concretas Builder: separa a construção de um objeto completo de sua representação de modo que o mesmo processo de construção pode criar diferentes representações Factory Method: define uma interface para criar um objeto, mas deixa subclasses decidirem que classe instanciar Prototype: especifica os tipos de objetos para criar usando uma interface prototipadora, e cria novos objetos copiando/clonando um protótipo Singleton: garante que uma classe tenha uma única instância, e provê um ponto de acesso central a essa instância

23

Padrões EstruturaisAdapter: converte a interface de uma classe em outra interface esperada pelos clientes Bridge (ou Handle): desacopla uma abstração de sua implementação de forma que ambas possam variar de modo independente Composite: compõe objetos em estruturas de árvore para representar hierarquias “parte-todo”; clientes podem tratar objetos individuais e composições de objetos de modo uniforme Decorator: adiciona responsabilidades a objetos dinamicamente; provê uma alternativa flexível a herança direta como forma de estender funcionalidade Façade: provê interface unificada para uma serie de interfaces de um subsistema; define uma interface de mais alto nível que torna o subsistema mais fácil de ser usado Flyweight: usa compartilhamento para dar suporte eficiente a um grande numero de objetos de granulosidade fina Proxy: provê um substituto para outro objeto, controlando o acesso a este último

24

Padrões Comportamentais

Chain of Responsibility: evita o acoplamento entre um solicitante de uma requisição e um provedor dando a um conjunto de objetos a chance de tratar essa requisição; esses objetos são encadeados e a requisição é passada ao longo da cadeia até que um objeto trate a requisição Command: encapsula uma requisição como um objeto, permitindo parametrizar clientes com diferentes requisições, enfileirar requisições, ou registrar (log) requisições, bem como dar suporte a “undo" de operações Interpreter: dada uma linguagem, define uma representação para sua gramática juntamente com um interpretador que usa a representação para interpretar sentenças na linguagem Iterator: provê uma forma de acessar os elementos de um objeto agregado sequencialmente, sem expor a representação interna do agregado Mediator: define um objeto que encapsula a forma como um conjunto de objetos interage; promove o fraco acoplamento impedindo que objetos se referenciem explicitamente

Memento: captura e recupera o estado interno de um objeto sem violar seu encapsulamento Observer: define uma dependência 1-para-N entre objetos de modo que quando um objeto mude seu estado, todos os dependentes sejam notificados/atualizados automaticamente State: altera o comportamento de um objeto quando seu estado muda; o objeto aparenta mudar sua classe Strategy: define uma família de algoritmos, encapsula cada um deles, e os torna intercambiáveis; permite que o algoritmo varie independentemente dos clientes que o usam Template Method*: define o esqueleto de uma operação, delegando a concretização de alguns passos dessa operação a subclasses Visitor: representa uma operação a ser executada sobre os elementos da estrutura de um objeto; permite definir uma operação sem mudar as classes dos elementos sobre os quais a operação age.

25

Padrões Comportamentais (cont.)

26

Exemplo de Padrão de Criação:Padrão Abstract FactoryProblema: família de objetos que precisam ser criados Solução: coordena a criação de famílias de objetos Aplicabilidade:

Um sistema deve ser independente de como objetos de uma família são criados, compostos ou representados Uma família de objetos foi projetada para ser usada em conjunto e é necessário garantir essa restrição

27

Especificação do padrão Abstract Factory em UML

28

Especificação do padrão Abstract Factory em UML

OK!!

29

Especificação do padrão Abstract Factory em UML

NÃO!!

30

Especificação do padrão Abstract Factory em UML

31

Elementos do Padrão Abstract Factory

Abstract Factory Define a interface de criação de cada membro da família

Concrete Factory (CF) Cria cada membro da família (o “como”)

Abstract Product Define a interface genérica de um membro da família

Concrete Product Define um membro da família (o “como”)

32

Exemplo de uso do Padrão Abstract Factory

Agenda de endereços e número de telefones

public class USAddrBookFactory implements AddrBookFactory { public Address createAddress() { return new USAddress(); } public PhoneNumber createPhoneNumber() { return new USPhoneNumber(); }}

AddrBookFactory af;if( lang.equals( "BR" ) ) af = new BRAddrBookFactory();else if( lang.equals( "US" ) ) af = new USAddrBookFactory();else { System.out.println( "Wrong location" ); return;} Address a = af.createAddress();PhoneNumber p = af.createPhoneNumber();a.setAddress( "R. da Feira", "300" );p.setPhoneNumber( "22222121" );System.out.println( a.getAddress() );System.out.println( p.getPhoneNumber() );

33

Outro Exemplo de Padrão de Criação:Padrão Singleton

Problema: Uma classe tem apenas uma instância e provê um ponto de acesso global a essa instância Solução: Criar um método estático getInstance(). Quando o método for executado pela primeira vez, cria a instância do objeto e retorna uma referência para o objeto criado. Em acessos subseqüentes nenhuma instância é criada e a referência ao objeto existente é retornada

34

Especificação do Padrão Singleton em UMLSingleton

Static getInstance() SingletonOperation() GetSingletonData()

Static uniqueInstance singletonData

Retorna instância única

35

Elementos do Padrão Singleton

Singleton Define uma operação getInstance() que permite que o cliente acesse apenas sua única instância. getInstance() é uma operação da classe

36

Exemplo de uso do Padrão Singletonpublic class ClassicSingleton { private static ClassicSingleton instance = null; protected ClassicSingleton() { // Exists only to defeat instantiation. }

public static ClassicSingleton getInstance() { if(instance == null) { instance = new ClassicSingleton(); } return instance; } }

37

Exemplo de Padrão Estrutural:Padrão Adapter

Problema: Uma classe muitas vezes não é reusada porque sua interface não corresponde à interface específica de uma aplicação Solução: Converter a interface de uma classe em outra interface, permitindo que classes incompatíveis trabalhem em conjunto Aplicabilidade:

Quer-se usar uma classe existente, porém sua interface não é compatível com a que se deseja Quer-se criar uma classe reutilizável que coopera com classes não previstas inicialmente, isto é, que não necessariamente têm interfaces compatíveis

38

Especificação do Padrão Adapter em UML

Adaptador de Classes

Usa herança múltipla para adaptar uma interface a outra

Adaptador de Objeto

Usa herança simples e delegação

39

Elementos do Padrão Adapter

Client Colabora com objetos compatíveis com uma certa interfaceAdaptee Define uma interface que vai ser adaptada para permitir acesso pelo Client

Adapter Adapta a interface do Adaptee à interface esperada pelo Client

40

Exemplo simplificado de uso do Padrão (Object) Adapter

public class NewTime { public: int getTime( ) { return ad_oldTime.getOldTime() * 100 + 50; }

private: OldTime ad_oldTime;};

Adapter

Adaptee

41

Outro Exemplo de Padrão Estrutural: Padrão Composite

Problema: composições e elementos primitivos são tratados de modo diferente (como classes distintas), inibindo composições recursivas Solução: usar composição recursiva de tal modo que clientes possam não fazer distinção entre elementos primitivos e composições Aplicabilidade:

Quer-se representar hierarquias de composições de objetos Quer-se que clientes sejam capazes de ignorar a diferença entre composições ou objetos individuais

42

Especificação do Padrão Composite em UML

43

Elementos do Padrão Composite

Client Manipula objetos da composição via interface Component

Component Declara a interface genérica para objetos da composição

Leaf Representa elementos primitivos

Composite Representa composições (recursivas)

44

Exemplo de uso do Padrão Composite

class CompositeElement : DrawingElement { private ArrayList elements = new ArrayList(); public override void Add( DrawingElement d ) { elements.Add(d); }

public override void Remove( DrawingElement d ) { elements.Remove(d); }

public override void Display( int indent ) { ... foreach (DrawingElement c in elements) { c.Display(); } }}

abstract class DrawingElement { public void Add( DrawingElement d ); public void Remove( DrawingElement d ); public void Display();}

public class PrimitiveElement : DrawingElement { public override void Add( DrawingElement c ) { Console.WriteLine( "Cannot do it!“ ); }

public override void Remove( DrawingElement c ) { Console.WriteLine( "Cannot do it!"); }

public override void Display() { ... }}

45

Outro Exemplo de Padrão Estrutural:

Padrão DecoratorProblema: às vezes é necessário acrescentar responsabilidades a objetos individuais e não a toda uma classe Solução: agregar dinamicamente responsabilidades adicionais a um objeto. O padrão Decorator permite extensão de funcionalidades Aplicabilidade:

Quer-se adicionar (ou remover!) responsabilidades a objetos individuais de forma dinâmica e transparente, isto é, sem alteração de outros objetos Quando extensão por herança de subclasse é impraticável

46

Especificação do Padrão Decorator em UML

47

Elementos do Padrão Decorator

Component Define a interface para objetos que podem ter responsabilidades acrescentadas aos mesmos dinamicamente

ConcreteComponent Define um objeto para o qual responsabilidades adicionais podem ser atribuídas

Decorator Mantém uma referência para um objeto Component e define uma interface que segue a interface de Component (opcionalmente pode executar operações adicionais antes e depois de repassar a solicitação)

ConcreteDecorator Acrescenta responsabilidades ao componente

48

Exemplo de uso do Padrão Decorator

Alterar o comportamento de leitores e escritores de fluxos de dados

API Java IO:

Pode-se decorar InputStreams com buffers, push backers (devolução de caracteres lidos ao InputStream) etc.

int c;InputStream in = new BufferedInputStream( new FileInputStream( “test.txt” ) ) );while( ( c = in.read() ) >= 0 ) { System.out.print( ( char )c );}in.close();

49

Exemplo de Padrão Comportamental: Padrão Strategy

Problema: Uma classe muitas vezes não é reusada porque sua interface não corresponde à interface específica de uma aplicação Solução: Definir uma familia de algoritmos, encapsular cada um deles e torná-los intercambiáveis. O padrão Strategy permite que o algoritmo varie de modo independente dos clientes que o usam Aplicabilidade:

Muitas classes relacionadas diferem somente no seu comportamento Necessidade de variantes de um algoritmo

50

Especificação do Padrão Strategy em UML

51

Elementos do Padrão Strategy

Strategy Define uma interface comum para todos os algoritmos suportados

ConcreteStrategy Implementa o algoritmo usando a interface de Strategy

Context É configurado com um objeto ConcreteStrategy e mantém uma referência para o mesmo

52

Exemplo de uso do Padrão Strategy

Definir como bordas sãodesenhadas em componentes GUI

API Java Swing:

AbstractBorder defineuma família de estratégiasde desenho de bordas de componentes GUI

public class HandleBorder extends AbstractBorder { ... public void paintBorder(Component component, Graphics g, int x, int y, int w, int h) { ... } ...}

public abstract class JComponent { ... public void setBorder(Border border) { Border oldBorder = this.border; this.border = border; firePropertyChange("border", oldBorder, border); if (border != oldBorder) { ... repaint(); } } public Border getBorder() { return border; } ... protected void paintBorder(Graphics g) { Border border = getBorder(); if (border != null) { border.paintBorder(this, g, 0, 0, getWidth(), getHeight()); } }}