padrões apostila

8/3/2019 Padres apostila

1/37

1

UNIVERSIDADE DE SO PAULOINSTITUTO DE CINCIAS MATEMTICAS E DE COMPUTAO

Padres e Frameworks de Software(Notas Didticas)

Editores:Jos Carlos MaldonadoRosana Teresinha Vaccare BragaFerno Stella Rodrigues GermanoPaulo Cesar Masiero


2/37

1

Sumrio

SUMRIO.........................................................................................................................................................1

1 PADRES ...................................................................................................................................................1

1.1 COMPONENTES DE UM PADRO...............................................................................................................21.2 ANTI-PADRES .......................................................................................................................................41.3 CLASSIFICAO DE PADRES ................................................................................................................. 41.4 COLETNEAS DE PADRES...................................................................................................................... 5

1.4.1 Colees de padres ....................................................................................................................... 6

1.4.2 Catlogos de padres ..................................................................................................................... 6

1.4.3 Sistemas de padres........................................................................................................................7

1.4.4 Linguagens de padres ...................................................................................................................7

1.4.5 Sntese de trabalhos afins ...............................................................................................................8

1.4.6 Exemplos....................................................................................................................................... 11

1.5 REGRAS PARA DERIVAO DE NOVOS PADRES ...................................................................................181.6 DESENVOLVIMENTO DE SISTEMAS USANDO PADRES ........................................................................... 191.7 EXERCCIOS ..........................................................................................................................................20

2 FRAMEWORKS ......................................................................................................................................21

2.1 INTRODUO ........................................................................................................................................212.2 CONCEITOS & TERMINOLOGIA .............................................................................................................21

2.2.1 Definies .....................................................................................................................................21

2.2.2 Inverso de controle ..................................................................................................................... 22

2.2.3 Frameworks Caixa Branca X Caixa Preta ...................................................................................23

2.3 CLASSIFICAO DE FRAMEWORKS ....................................................................................................... 252.4 SNTESE DE TRABALHOS AFINS..............................................................................................................252.5 EXEMPLOS ............................................................................................................................................262.6 EXERCCIOS ..........................................................................................................................................272.7 CONCLUSES........................................................................................................................................29

3 COMPARAO ENTRE AS DIVERSAS FORMAS DE REUSO......................................................30REFERNCIAS: ............................................................................................................................................ 32


3/37

1

1 Padres

A origem dos padres de projeto deu-se com o trabalho feito pelo arquiteto

Christopher Alexander no final dos anos 70. Ele escreveu dois livros: A Pattern

Language [Alexander 77] e A Timeless Way of Building [Alexander 79] que, alm de

exemplificarem, descrevem seu mtodo para documentao de padres. O trabalho de

Alexander, apesar de ser voltado para a arquitetura, possui uma fundamentao bsica que

pode ser abstrada para a rea de software.

Os padres permaneceram esquecidos por um tempo, at que ressurgiram na

conferncia sobre programao orientada a objetos (OOPSLA) de 1987, mais

especificamente, no Workshop sobre Especificao e Projeto para Programao Orientada a

Objetos [Beck 87]. Nesse trabalho, Beck e Cunningham falam sobre uma linguagem depadres para projetar janelas em Smalltalk. A partir de ento, muitos artigos, revistas e

livros tm aparecido abordando padres de software, que descrevem solues para

problemas que ocorrem freqentemente no desenvolvimento de software e que podem ser

reusadas por outros desenvolvedores. Um dos primeiros trabalhos estabelecendo padres

foi o de Coad [Coad 92], no qual so descritos sete padres de anlise. Nesse mesmo ano

Coplien publicou um livro definindo inmeros idiomas, que so padres de programao

especficos para a linguagem C++. Em 1993, Gamma e outros introduzem os primeiros de

seus vinte e trs padres de projeto [Gamma 93], que seriam publicados em 1995 [Gamma

95]. Esses foram os trabalhos pioneiros na rea de padres, seguidos por muitos outros nos

anos seguintes.

Um padro descreve uma soluo para um problema que ocorre com freqncia

durante o desenvolvimento de software, podendo ser considerado como um par

problema/soluo [Buschmann 96]. Projetistas familiarizados com certos padres podem

aplic-los imediatamente a problemas de projeto, sem ter que redescobri-los [Gamma 95].

Um padro um conjunto de informaes instrutivas que possui um nome e que capta aestrutura essencial e o raciocnio de uma famlia de solues comprovadamente bem

sucedidas para um problema repetido que ocorre sob um determinado contexto e um

conjunto de repercusses [Appleton 97].


4/37

2

Padres de software podem se referir a diferentes nveis de abstrao no

desenvolvimento de sistemas orientados a objetos. Assim, existem padres arquiteturais,

em que o nvel de abstrao bastante alto, padres de anlise, padres de projeto, padres

de cdigo, entre outros. As diversas categorias de padres so discutidas a seguir. O uso de

padres proporciona um vocabulrio comum para a comunicao entre projetistas, criando

abstraes num nvel superior ao de classes e garantindo uniformidade na estrutura do

software [Gall 96]. Alm disto, eles atuam como blocos construtivos a partir dos quais

projetos mais complexos podem ser construdos [Gamma 95].

1.1 Componentes de um padro

Apesar de existirem diversos padres de padro, padres tm sido descritos em

diferentes formatos. Porm, existem componentes essenciais que devem ser claramente

identificveis ao se ler um padro [Appleton 97]:

Name: Todo padro deve ter um nome significativo. Pode ser uma nica palavra

ou frase curta que se refira ao padro e ao conhecimento ou estrutura descritos

por ele. Se o padro possuir mais do que um nome comumente usado ou

reconhecvel na literatura, subsees Aliases ou Also know as devem ser

criadas.

Problem: Estabelece o problema a ser resolvido pelo padro, descreve a

inteno e objetivos do padro perante o contexto e foras especficas.

Context: Pr-condies dentro das quais o problema e sua soluo costumam

ocorrer e para as quais a soluo desejvel, o que reflete a aplicabilidade do

padro. Pode tambm ser considerado como a configurao inicial do sistema

antes da aplicao do padro.

Forces: Descrio dos impactos, influncias e restries relevantes para oproblema e de como eles interagem ou so conflitantes entre si e com os

objetivos a alcanar. Um cenrio concreto que serve como motivao para o

padro.

Solution: Relacionamentos estticos e regras dinmicas descrevendo como

obter o resultado desejado. Equivale a dar instrues que descrevem como o


5/37

3

problema resolvido, podendo para isso utilizar texto, diagramas e figuras. So

possveis as seguintes subsees:

Structure, revelando a forma e organizao esttica do padro;

Participants, descrevendo cada um desses componentes;

Dynamics, exibindo o comportamento dinmico do padro.

Implementation, mostrando detalhes de implementao do padro; e

Variants, discutindo possveis variaes e especializaes da soluo.

Examples: Uma ou mais aplicaes do padro que ilustram, num contexto

inicial especfico, como o padro aplicado e transforma aquele contexto em

um contexto final.

Resulting context: O estado ou configurao do sistema aps a aplicao do

padro, podendo ter uma subseo Conseqncias (tanto boas quanto ruins).

Descreve as ps-condies e efeitos colaterais do padro.

Rationale: Uma explicao das regras ou passos do padro que explicam como

e porque ele trata suas influncias contrrias, definidas em 'Forces', para

alcanar os objetivos, princpios e filosofia propostos. Isso nos diz realmente

como o padro funciona, porque funciona e porque ele bom.

Related Patterns: Os relacionamentos estticos e dinmicos desse padro com

outros dentro da mesma linguagem ou sistema de padres. Padres relacionadosgeralmente compartilham as mesmas influncias. So possveis os seguintes

tipos de padres relacionados:

padres predecessores, cuja aplicao conduza a esse padro;

padres sucessores, que devem ser aplicados aps esse;

padres alternativos, que descrevem uma soluo diferente para o mesmo

problema mas diante de influncias e restries diferentes; e

padres codependentes, que podem (ou devem) ser aplicadossimultaneamente com esse padro.

Known Uses: Descreve ocorrncias conhecidas do padro e sua aplicao em

sistemas existentes. Isso ajuda a validar o padro, verificando se ele realmente

uma soluo provada para um problema recorrente.


6/37

4

1.2 Anti-padres

Anti-padres representam uma lio aprendida, ao contrrio dos padres, que

representam a melhor prtica [Appleton 97]. Os anti-padres podem ser de dois tipos:

Aqueles que descrevem uma soluo ruim para um problema que resultou em

uma situao ruim

Aqueles que descrevem como escapar de uma situao ruim e como proceder

para, a partir dela, atingir uma boa soluo.

Os anti-padres so necessrios porque to importante ver e entender solues

ruims como solues boas. Se por um lado til mostrar a presena de certos padres em

sistemas mal sucedidos, por outro lado til mostrar a ausncia dos anti-padres em

sistemas bem sucedidos.Segundo uma outra definio [CMG 98] um anti-padro :

um padro que diz como ir de um problema para uma soluo ruim ou

um padro que diz como ir de uma soluo ruim para um soluo boa.

A primeira parece intil, exceto se considerarmos o padro como uma mensagem

No faa isso. O segundo definitivamente um padro positivo, no qual o problema a

soluo ruim.

1.3 Classificao de Padres

Conforme j mencionado, padres de software abrangem diferentes nveis de

abstrao, podendo portanto ser classificados em diversas categorias de modo a facilitar sua

recuperao e uso. Porm, essa classificao no rigorosa, podendo haver padres que se

encaixem em mais do que uma categoria. A seguir resumem-se algumas categorias

importantes de padres. Outras categorias de padres so discutidas em [Coplien 95,

Vlissides 96, Martin98].

Padres de processo: definem solues para os problemas encontrados nos

processos envolvidos na engenharia de software: desenvolvimento, controle de

configurao, testes, etc.


7/37

5

Padres arquiteturais: expressam o esquema ou organizao estrutural

fundamental de sistemas de software ou hardware.

Padres de padro (em ingls,patterns on patterns): so padres descrevendo

como um padro deve ser escrito, ou seja, que padronizam a forma com que os

padres so apresentados aos seus usurios.

Padres de anlise: descrevem solues para problemas de anlise de sistemas,

embutindo conhecimento sobre o domnio de aplicao especfico.

Padres de projeto: definem solues para problemas de projeto de software.

Padres de interface: definem solues para problemas comuns no projeto da

interface de sistemas. um caso particular dos padres de projeto.

Padres de programao: descrevem solues de programao particulares de

uma determinada linguagem ou regras gerais de estilo de programao.

Padres de Persistncia: descrevem solues para problemas de armazenamen-

to de informaes em arquivos ou bancos de dados.

Padres para Hipertexto: descrevem solues para problemas encontrados no

projeto de hipertextos.

Padres para Hipermdia: descrevem solues para problemas encontrados no

desenvolvimento de aplicaes hipermdia.

1.4 Coletneas de padres

Conforme j mencionado, diversos autores tm proposto centenas de padres nas

mais diversas reas de aplicao. Esses padres so descobertos aps a abstrao de fatores

comuns em diversos pares problema-soluo, podendo-se situar em vrias faixas de escala

e abstrao. Existem padres de domnio especfico, como por exemplo para sistemas

multimdia educativos e tambm padres independentes de domnio, como por exemplopadres para projeto de interface. H padres que ajudam a estruturar um sistema de

software em subsistemas e outros que ajudam a implementar aspectos de projeto

particulares.

Olhando mais de perto para muitos padres, percebe-se que um padro resolve um

problema, mas sua aplicao pode gerar outros problemas, que podem ser resolvidos por


8/37

6

outros padres. Em geral no existem padres isolados: um padro pode depender de outro

no qual esteja contido, ou das partes que ele contm, ou ser uma variao de outro, ou ser

uma combinao de outros. De maneira geral, um padro e seus variantes descrevem

solues para problemas muito similares, que variam em algumas das influncias

envolvidas.

Portanto, deve-se pensar em formas de agrupar os padres existentes segundo algum

critrio, de forma a facilitar sua recuperao e reuso. Isso pode ser feito por meio de

colees de padres, catlogos de padres, sistemas de padres ou linguagem de padres.

Este captulo tm por objetivo fornecer os conceitos relacionados a esses quatro

tipos de agrupamento de padres, bem como exemplific-los, deixando clara a diferena

entre eles e a utilidade de cada um deles em particular.

1.4.1 Colees de padres

Uma coleo de padres uma coletnea qualquer de padres que no possuem

nenhum vnculo entre si e, em geral, nenhuma padronizao no formato de apresentao.

Os padres podem estar reunidos por terem sido apresentados em um mesmo congresso,

por terem sido propostos pelo mesmo autor, ou por se referirem a um mesmo domnio, mas

no possuem um relacionamento semntico significativo.

1.4.2 Catlogos de padres

Um catlogo de padres uma colenea de padres relacionados (talvez

relacionados apenas fracamente ou informalmente). Em geral subdivide os padres em um

pequeno nmero de categorias abrangentes e pode incluir algumas referncias cruzadas

entre os padres [Appleton 97].

Um catlogo de padres pode oferecer um esquema de classificao e recuperao

de seus padres, j que eles esto subdivididos em categorias. Um catlogo de padres

adiciona uma certa quantidade de estrutura e organizao a uma coleo de padres, mas

usualmente no vai alm de mostrar apenas as estruturas e relaes mais superficiais (se

que o faz) [Appleton 97].


9/37

7

1.4.3 Sistemas de padres

Um sistema de padres um conjunto coeso de padres co-relacionados que

trabalham juntos para apoiar a construo e evoluo de arquiteturas completas. Alm de

ser organizado em grupos e subgrupos relacionados em mltiplos nveis de granularidade,um sistema de padres descreve as diversas inter-relaes entre os padres e seus

grupamentos e como eles podem ser combinados e compostos para resolver problemas mais

complexos. Os padres num sistema de padres devem ser descritos num estilo consistente

e uniforme e precisam cobrir uma base de problemas e solues suficientemente abrangente

para permitir a construo de parcelas significativas de arquiteturas completas [Appleton

97].

Um sistema de padres interliga padres individuais, descreve como os padres que

o constituem so conectados com outros padres no sistema, como esses padres podem ser

implementados e como o desenvolvimento de software com padres apoiado. Um sistema

de padres um veculo poderoso para expressar e construir arquiteturas de software

[Buschmann 96].

Alm da estrutura e organizao oferecidas por um catlogo de padres, num

sistema de padres adicionada uma maior profundidade estrutura, maior riqueza

interao dos padres e maior uniformidade ao catlogo de padres [Appleton 97].

1.4.4 Linguagens de padres

Uma linguagem de padres uma coleo estruturada de padres que se apoiam uns

nos outros para transformar requisitos e restries numa arquitetura [Coplien 98].

Os padres que constituem uma linguagem de padres cobrem todos os aspectos

importantes em um dado domnio. Pelo menos um padro deve estar disponvel para cada

aspecto da construo e implementao de um sistema de software: no pode haver

vazios ou brancos.

Uma linguagem de padres uma forma de subdividir um problema geral e sua

soluo complexa em um nmero de problemas relacionados e suas respectivas solues.

Cada padro da linguagem resolve um problema especfico no contexto comum

compartilhado pela linguagem. importante notar que cada padro pode ser usado


10/37

8

separadamente ou com um certo nmero de padres da linguagem. Isso significa que um

padro sozinho considerado til mesmo se a linguagem no for ser usada em sua

plenitude.

Conforme j foi visto, a linguagem de padres proposta por [Meszaros & Doble 98]

possui uma sub-seo dedicada a padres a serem seguidos por linguagens de padres,

dentre os quais padres especificando que uma linguagem de padres deve: dar ao leitor

uma viso geral da ling. de padres, fornecer uma tabela resumindo todos os padres,

deixar claro quando houver formas alternativas para resolver o mesmo problema, deixar

clara a estruturao da linguagem, utilizar um mesmo exemplo em toda a linguagem para

ilustrar cada padro e oferecer um glossrio de termos como parte da linguagem.

Parte das linguagens de padres encontradas na literatura descrevem seus padres

utilizando a forma de Alexander e outra parte utiliza variaes dos padres de padro.

1.4.5 Sntese de trabalhos afins

Buschmann e outros [Buschmann 96] distinguem sistemas de padres de linguagens

de padres, salientando que uma linguagem de padres tem a obrigao de ser completa em

um certo domnio restrito, isto , tem que ter pelo menos um padro disponvel para cada

aspecto da construo e implementao de sistemas de software. No pode haver falhas ou

omisses. J um sistema de padres pode abranger um domnio mais amplo, sem ter essa

obrigao de ser completo. Sua definio de um sistema de padres para arquitetura de

software : uma coleo de padres para arquitetura de software, juntamente com

diretrizes para sua implementao, combinao e uso prtico no desenvolvimento de

software. Tal sistema deve dar apoio ao desenvolvimento de sistemas de alta qualidade,

que satisfaam tanto a requisitos funcionais quanto no-funcionais.

Os requisitos desejveis para um sistema de padres so os seguintes:

Deve abranger uma base suficiente de padres: deve haver padres paraespecificao da arquitetura bsica do sistema, padres que ajudem ao

refinamento dessa arquitetura bsica e padres que ajudem a implementar essa

arquitetura de software em uma linguagem de programao especfica


11/37

9

Deve descrever todos os padres de maneira uniforme: a forma de descrio

deve captar tanto a essncia do padro quanto a definio precisa de seus

detalhes e deve permitir a comparao do padro com outros

Deve expor os vrios relacionamentos entre padres, tais como: refinamentos,

combinaes, etc.

Deve organizar os padres que o constituem: o usurio deve poder encontrar

rapidamente um padro que resolva seu problema de projeto concreto e deve ser

possvel que o usurio explore solues alternativas endereadas por padres

diferentes

Deve apoiar a construo de sistemas de software: deve haver diretrizes de

como aplicar e implementar seus padres constituintes

Deve apoiar sua prpria evoluo: assim como a evoluo tecnolgica, um

sistema de padres deve evoluir tambm. Assim, deve ser permitida a

modificao de padres existentes, a melhoria de sua descrio, a adio de

novos padres e a retirada de padres no mais utilizados

Riehle e Zllighoven [Riehle 95] apresentam uma linguagem de padres chamada

A Pattern Language for Tool Construction and Integration Based on the Tools and

Materials Metaphor. Essa linguagem foi desenvolvida para ajudar no aprendizado da

metfora de ferramentas e materiais, segundo a qual o trabalho possui uma perspectivaespecfica: as pessoas tem competncia e talento necessrio para seu trabalho; no h

necessidade de definir um fluxo de trabalho fixo, porque as pessoas saber o que querem e

podem arcar com mudanas na situao de forma adequada e as pessoas devem poder

decidir sozinhas como organizar seu trabalho e seu ambiente (inclusive o software que

utilizam), de acordo com suas tarefas. A idia principal dessa metfora que a maioria dos

objetos de um domnio de aplicao devem pertencer ou a uma ferramenta ou a um

material. Ferramentas so a forma de operar em materiais, onde materiais so resultado

do trabalho em um domnio.

Aarsten e outros [Aarsten 95] apresentam a G++, uma linguagem de padres para

manufatura integrada ao computador. O problema abordado por essa linguagem o projeto

de sistemas de informaes concorrentes e provavelmente distribudos, com aplicaes na

manufatura integrada ao computador. O objetivo do trabalho aumentar o reuso de projeto


12/37

10

orientado a objetos desde o nvel de componentes at o nvel arquitetural, oferecendo um

modelo conceitual para arquiteturas concorrentes e distribudas.

Cunningham [Cunningham 95] apresenta uma linguagem de padres chamada The

CHECKS Pattern Language of Information Integrity, que diz como fazer checagem nas

entradas de dados para separar dados invlidos dos vlidos e assegurar que o menor

nmero possvel de dados invlidos seja registrado. O objetivo fazer essa checagem sem

complicar os programas e comprometer a flexibilidade futura.. Em [Cunningham 96] ele

apresenta a linguagem de padres chamada EPISODES: A Pattern Language of

Competitive Development, que descreve uma forma de desenvolvimento de software

apropriada para organizaes entreprenurial. Assume-se que os desenvolvedores dessa

organizao trabalham em equipes pequenas de pessoas brilhantes e altamente motivadas e

que o tempo de mercado altamente valorizado pela organizao. Essa organizaotambm espera liberar outras verses em um tempo razovel, isto , ela espera ter sucesso

e explorar esse sucesso pelo tempo que os clientes desejarem.

Kerth [Kerth 95] apresenta uma linguagem de padres chamada Caterpillar's Fate:

A Pattern Language for Transformation from Analysis to Design. Ela usada para apoiar

a transformao dos documentos de anlise em um projeto inicial de software. O nome da

linguagem (destino da lagarta) vem da analogia que feita entre a transio da anlise

para o projeto com a lagarta que magicamente se transforma em uma borboleta. A

linguagem tenta captar a sabedoria adquirida durante o desenvolvimento de solues de

projeto a partir de modelos de anlise, documentando o que deve ser feito durante a

transio.

Braga e outros [Braga 99] apresentam uma linguagem de padres chamada A

Pattern Language for Business Resource Management, que composta de padres para

guiar o desenvolvimento de sistemas para gerenciamento de recursos de negcios tais

como: produtos, carros, servios, etc. A linguagem composta de quinze padres

Algumas outras linguagens de padres podem ser citadas, como a Evolving

Frameworks A Pattern Language for developing object-oriented frameworks [Roberts

98], a A Pattern Language for Pattern Writing [Meszaros 98], a A Pattern Language for

Developing Form Style Windows [Bradac 98], a A Pattern Language of Transport

Systems (Point and Route) [Zhao 98] e a Patterns for System Testing..


13/37

11

1.4.6 Exemplos

Colees de padres

[Vlissides 96] uma coleo de padres, no caso dos padres apresentados no

PLOP95. A Tabela 1 mostra alguns deles. Estudando esses padres de forma detalhada,

observa-se que eles abrangem domnios e nveis de abstrao variados, e no possuem

relacionamento explcito. So padres escritos por diversos autores diferentes e de maneira

independente, isto , um autor no tinha conhecimento do que os demais autores estavam

escrevendo. O editor do livro agrupou os padres que pertencem ao mesmo domnio ou

fase do processo de desenvolvimento em captulos, mas isso no suficiente para que essa

coleo de padres possa ser considerada um catlogo de padres.

Tabela 1 Coleo de Padres [Vlissides 96]

Captulo Padro Autor

Command Processor Peter Sommerlad2- Padres de propsitos

gerais Shopper Jim Doble

A Structural Pattern for Designing Transparent

Layered Services

Aamod Sane e Roy Campbell

Patterns for Processing Satellite Telemetry with

Distributed Teams

Stephen Berczuk

A Pattern Language for Object-RDBMS

Integration

Kyle Brown e Bruce

Whitenack

3- Padres de propsitos

especficos

Transactions and Accounts Ralph Johnson

Patterns for Classroom Education Dana Anthony

A Pattern Language for the Preparation of

Software Demonstrations

Todd Coram

6- Padres de Exposio

A Pattern Language for na Essay-Based WebSite

Robert Orenstein

Catlogos de padres


14/37

12

[Gamma 95] um catlogo de padres de projeto, pois possui mais estrutura e

organizao, exibindo tambm relaes entre os padres. A Tabela 2 exibe os padres

desse catlogo. Deve-se lembrar que os critrios para classificao dos padres so dois:

escopo e propsito.

Tabela 2 Catlogo de Padres [Gamma 95]

Propsito

De Criao Estrutural Comportamental

Classe Factory Method Adapter InterpreterTemplate Method

Escopo

Objeto Abstract Factory

Builder

Prototype

Singleton

Adapter

BridgeComposite

Decorator

Facade

Flyweygth

Proxy

Chain of Responsability

CommandIterator

Mediator

MementoObserver

State

Strategy

Visitor

No critrio escopo decide-se se o padro atua sobre uma classe ou sobre objetos

da classe. Padres da classe lidam com os relacionamentos entre classes e suas subclasses,

por meio do uso de herana, sendo portanto estabelecidos de forma esttica (em tempo de

compilao). Padres do objeto lidam com relacionamentos entre objetos, que podem ser

modificados durante a execuo e so mais dinmicos. A maioria dos padres utiliza

herana de alguma forma. Portanto os nicos padres classificados na categoria classe

so os que se concentram em relacionamentos de classes.

No critrio propsito existem padres de criao, padres estruturais e padres

comportamentais. Padres de criao concentram-se no processo de criao de objetos.

Padres estruturais lidam com a composio de classes ou objetos. Padres

comportamentais caracterizam as formas pelas quais classes ou objetos interagem e

distribuem responsabilidades.


15/37

13

Gamma e outros propem tambm uma outra forma de organizar seus padres de

projeto, mostrada na Figura 1. Nessa figura os padres esto relacionados de acordo com a

maneira com que cada um referencia os outros na seo Related Patterns.

Figura 1 Relacionamento entre padres [Gamma 95]

Sistemas de padres


16/37

14

[Buschmann 96] um exemplo de um sistema de padres, j que d maior destaque

estrutura e interao entre os padres e os apresenta com maior uniformidade. A Tabela

3 mostra os padres desse sistema, no qual so usados dois critrios para classificao:

categorias de padres e categorias de problemas. As categorias de padres propostas por

Buschmann e outros so:

padres arquiteturais, que podem ser usados no incio do projeto de alto nvel,

quando se faz a especificao da estrutura fundamental de uma aplicao;

padres de projeto, que so aplicados no final do projeto, quando se refina e se

estende a arquitetura fundamental de um sistema de software e

idiomas, que so usados na fase de implementao para transformar a

arquitetura de software em um programa escrito numa linguagem especfica

Abstraindo os problemas especficos que ocorrem durante o desenvolvimento de umsoftware podem ser definidas categorias de problemas, cada uma das quais envolvendo

diversos problemas relacionados. Essas categorias de problemas correspondem diretamente

a situaes concretas de projeto. As categorias de problemas propostas por Buschamnn e

outros para agrupar os padres que fazem parte do seu sistema de padres so:

Da lama para a estrutura (em ingls, From Mud to Structure): padres que

apoiam a decomposio adequada de uma tarefa do sistema em sub-tarefas que

cooperam entre si; Sistemas Distribudos (em ingls, Distributed Systems): padres que

fornecem infra-estrutura para sistemas que possuem componentes localizados

em processadores diferentes ou em diversos sub-sistemas e componentes;

Sistemas Interativos (em ingls, Interactive Systems): padres que ajudam a

estruturar sistemas com interface homem-mquina;

Sistemas Adaptveis (em ingls, Adaptable Systems): padres que fornecem

infra-estruturas para a extenso e adaptao de aplicaes em resposta a

requisitos de evoluo e mudana funcional;

Decomposio Estrutural (em ingls Structural Decomposition): padres

que apoiam a decomposio adequada de sub-sistemas e componentes

complexos em partes cooperativas;


17/37

15

Organizao do Trabalho (em ingls, Organization of Work): padres que

definem como componentes colaboram para oferecer um servio complexo;

Controle de Acesso (em ingls, Access Control): padres que guardam e

controlam o acesso a servios e componentes;

Gerenciamento (em ingls, Management): padres para lidar com colees

homogneas de objetos, servios e componentes como um todo;

Comunicao (em ingls, Communication): padres que ajudam a organizar

a comunicao entre componentes e

Manuseio de Recursos (em ingls, Resource Handling): padres que ajudam

a gerenciar componentes e objetos compartilhados

Tabela 3 Sistema de Padres [Buschmann 96]

Padres arquiteturais Padres de projeto Idiomas

Da lama para aestrutura

LayersPipes and FiltersBlackboard

SistemasDistribudos

BrokersPipes and FiltersMicrokernel

SistemasInterativos

MVCPAC

Sistemasadaptveis

MicrokernelReflection

Decomposioda estrutura

Whole-Part

Organizao dotrabalho

Master-Slave

Controle deAcesso

Proxy

Gerenciamento Command ProcessorView Handler

Comunicao Publisher-SubscriberForwarder-ReceiverCliente-Dispatcher-Server

Manuseio deRecursos

Counted Pointer

Linguagem de padres

[Meszaros 96] uma linguagem de padres para melhorar a capacidade e

confiabilidade de sistemas reativos. Esses padres so geralmente encontrados em sistemas


18/37

16

de telecomunicaes, embora possam tambm ser aplicados a quaisquer sistemas reativos

com caractersticas de pico de capacidade. Por sistemas reativos entende-se aqueles

sistemas cuja funo principal a de responder a requisies de usurios de fora do

sistema. Esses usurios podem ser pessoas ou mquinas. Exemplos de sistemas reativos

so: sistemas computacionais de tempo compartilhado, centrais telefnicas de comutao,

servidores, processamento de transaes on-line (como redes bancrias ATM, etc.).

Todos esses sistemas precisam de alta capacidade a um custo razovel e alta confiabilidade

quando frente de cargas extremas que podem levar sobrecarga do sistema.

Essa linguagem de padres prope padres para lidar com a necessidade de

sistemas de alta capacidade e sobrevivncia diante de condies de sobrecarga do sistema.

A Figura 2 ilustra, de forma grfica, os padres que constituem a linguagem e seus

relacionamentos, enquanto a Tabela 4 lista os padres e seus respectivos propsitos.

Figura 2 Estrutura da Linguagem de Padres apresentada graficamente

Para ilustrar a similaridade de um padro de uma linguagem em relao a um

padro convencional, descreve-se a seguir o padro Finish Work in Progress. Deve-se

observar que, como no existe um formato padro para escrever os padres de uma

Capacity Bottleneck

Memory Capacity Processing Capacity Messaging Capacity

Faster Processor Optimize High-Runner Cases

Shed Load Share the Load

Finish Work inProgress

Fresh WorkBefore Stale

Match ProgressWork with New

Shed Work atPeriphery

Different Strokesfor Different Folks

Hash Access Port Leaky Bucket ofCredits


19/37

17

linguagem, os autores tm usado o formato que acreditam ser mais apropriado para

documentar os padres que ele tem em mos. No caso desse exemplo, Meszaros utilizou o

formato Nome/ Alias/ Problem/ Context/ Forces/ Solution/ Related Patterns. Observe na

descrio do padro que referncias a outros padres da linguagem so colocadas em

sublinhado. Isso garante que o usurio da linguagem fique consciente do inter-

relacionamento entre seus diversos padres.

Tabela 4 Padres da Linguagem e propsitos

Padro Propsito

Capacity Bottleneck Quando h um gargalo na capacidade do sistema, como proceder.Memory Capacity Quando a causa do gargalo na capacidade do sistema a capacidade de

memria, como proceder.Processing Capacity Quando a causa do gargalo na capacidade do sistema a capacidade de

processamento, como proceder.

Messaging Capacity Quando a causa do gargalo na capacidade do sistema a dificuldade de enviarmensagens entre processadores a tempo, como proceder.Faster Processor Quando um processador mais rpido necessrio para aumentar a capacidade

de processamento do sistema, como proceder.Optimize High-RunnerCases

Quando a otimizao dos casos de maior demanda necessria para aumentara capacidade de processamento do sistema, como proceder.

Shed Load Quando o descarte de parte da demanda necessrio para evitar sobrecarga dacapacidade de processamento do sistema, como proceder.

Share the Load Quando o atendimento da demanda deve ser compartilhado por mais de umprocessador para aumentar a capacidade de processamento do sistema, comoproceder.

Finish Work in Progress Quando o trmino do atendimento de trabalho em curso necessrio paraevitar sobrecarga da capacidade de processamento do sistema,, como proceder.

Fresh Work before Stale Quando o atendimento prioritrio de certos clientes necessrio para evitarsobrecarga da capacidade de processamento do sistema, como proceder.Match Progress work withnew

Quando necessrio evitar o desperdcio dos recursos j empregados noatendimento de certos clientes, causado por sua desistncia de obteratendimento, como proceder.

Shed Work at Periphery Quando necessrio o descarte da demanda que est alm da capacidade deprocessamento do sistema, como proceder para detectar o quanto antes o quedever ser descartado.

Different Strokes forDifferent Folks

Quando necessrio o estabelecimento de prioridades para o atendimento decertos clientes, como proceder para garantir que esse atendimento seja de boaqualidade.

Hash Access Port Quando o estabelecimento de funes Hash na porta de entrada de atendimentoprioritrio necessrio para estabelecer as prioridades, como proceder.

Leaky Bucket of Credits Quando reservatrios com vazamento so necessrios para armazenar oscrditos enviados aos processadores perifricos por processadoressobrecarregados que todavia ainda possuem capacidade de processamentodisponvel, como proceder

Padro 5 Finish Work in Progress (Termine o Trabalho em Andamento)


20/37

18

Tambm conhecido como: Termine o que voc comeou

Problema: Quais requisies devem ser aceitas e quais devem ser rejeitadas de

forma a melhorar o throughput do sistema

Contexto: Voc est trabalhando com um sistema reativo ou orientado a transaes,

no qual as requisies do usurio dependem de certa forma umas das outras. Uma

requisio pode se apoiar em uma requisio prvia, fornecer informao adicional em

resposta (ou em antecipao) a outra requisio, ou cancelar ou desfazer uma requisio

prvia.

Influncias: Entender as interdependncias entre requisies crucial para separar

trabalho de forma produtiva. Rejeitar o trabalho errado pode negar investimento prvio

considervel, ou pior ainda, resultar em deadlock por pendurar algumas transaes

juntamente com todos os recursos que elas estejam usando. Falhar na identificao dotrabalho que pode ser rejeitado inibe a melhoria da capacidade do sistema pela aplicao do

padro Shed Load.

Soluo:Requisies que so continuaes de trabalho em andamento devem serreconhecidas como tal e devem ser priorizadas em relao requisies totalmente novas.

Claramente categorize todas as requisies em categorias Novo e Em Andamento, e

assegure que todas as requisies do tipo Em Andamento sejam processadas antes das do

tipo Novo. A nica exceo a essa regra quando o tempo decorrido entre as requisies

iniciais e as seguintes fixo e previsvel (por exemplo, t segundos). Nessa situao,

bloquear completamente todas as requisies novas resultar em uma queda de carga t

segundos depois que o sistema comear a separar o trabalho novo. Isso cria uma oscilao

entre uma condio de sobrecarga e subcarga; o resultado uma capacidade mdia

reduzida. Isso pode ser contornado admitindo uma pequena quantidade de trabalho novo

durante o perodo de sobrecarga para reduzir a profundidade da queda.

Padres Relacionados: Esse padro apoia a aplicao do padro Shed Load.

1.5 Regras para derivao de novos padres

Algumas regras para derivao de novos padres (Pattern mining) so sugeridas

por Buschmann e outros [Buschmann 96]. So elas:


21/37

19

1. Encontre pelo menos trs exemplos nos quais um problema resolvido

efetivamente usando a mesma soluo. .....

2. Extraia a soluo, o problema e as influncias

3. Declare a soluo como candidata a padro

4. Execute um writers workshop para melhorar a descrio do candidato e

compartilh-lo com outros

5. Aplique o candidato a padro em um outro projeto de desenvolvimento de

software

6. Declare o candidato a padro como padro se sua aplicao for bem sucedida.

Caso contrrio tente procurar uma soluo melhor.

1.6 Desenvolvimento de sistemas usando padres

Segundo Buschmann e outros [Buschmann 96], padres no definem um novo

mtodo para desenvolvimento de software que substitua os j existentes. Eles apenas

complementam os mtodos de anlise e projeto gerais e independentes do problema, p.ex,

Booch, OMT, Shlaer/Mellor, etc., com diretrizes para resolver problemas especficos e

concretos. Em [Buschmann 96] sugerem-se os seguintes passos para desenvolver um

sistema usando padres de software:

1. Utilize seu mtodo preferido para o processo de desenvolvimento de softwareem cada fase do desenvolvimento.

2. Utilize um sistema de padres adequado para guiar o projeto e implementao

de solues para problemas especficos, isto , sempre que encontrar um padro

que resolva um problema de projeto presente no sistema, utilize os passos de

implementao associados a esse padro. Se esses se referirem a outros padres,

aplique-os recursivamente.

3. Se o sistema de padres no incluir um padro para seu problema de projeto,tente encontrar um padro em outras fontes conhecidas.

4. Se nenhum padro estiver disponvel, aplique as diretrizes de anlise e projeto

do mtodo que voc est usando. Essas diretrizes fornecem pelo menos algum

apoio til para resolver o problema de projeto em mos.


22/37

20

Segundo Buschmann, essa abordagem simples evita que se criem outros mtodos de

projeto. Ela combina a experincia de desenvolvimento de software captada pelos mtodos

de anlise e projeto com as solues especficas para problemas de projeto descritas pelos

padres.

Os autores destas notas didticas discordam quanto a essa afirmao, por acharem

que est claro que a abordagem proposta cria um novo mtodo de desenvolvimento de

sistemas, diferente dos j existentes.

1.7 Exerccios

1) Discuta a evoluo de uma coleo de padres para se tornar um catlogo, um

sistema e uma linguagem de padres.

2) Quais as dificuldades de recuperao de um padro nas diversas formas de

agrupamento dos mesmos?

3) Apresente mais um critrio de classificao que poderia ser til na recuperao

de padres.

4) Em que voc concorda/discorda em relao proposta para derivao de novos

padres? Por que?

5) Com relao seo 1.6, voc concorda com Buschmann ou com os autoresdestas notas didticas? Por que?


23/37

21

2 Frameworks

2.1 Introduo

Aps a popularizao da linguagem Smalltalk, no incio da dcada de 80,

paralelamente s bibliotecas de classes, comearam a ser construdos frameworks de

aplicao, que acrescentam s bibliotecas de classes os relacionamentos e interao entre as

diversas classes que compem o framework. Com os frameworks, reutilizam-se no

somente as linhas de cdigo, como tambm o projeto abstrato envolvendo o domnio de

aplicao.

Framework definido por Coad como um esqueleto de classes, objetos erelacionamentos agrupados para construir aplicaes especficas [Coad 92] e por Johnson

como um conjunto de classes abstratas e concretas que prov uma infra-estrutura genrica

de solues para um conjunto de problemas [Johnson 88]. Essas classes podem fazer parte

de uma biblioteca de classes ou podem ser especficas da aplicao. Frameworks

possibilitam reutilizar no s componentes isolados, como tambm toda a arquitetura de um

domnio especfico. O Captulo 2 explica em detalhes os conceitos associados a

frameworks, exemplificando diversos deles.

Diversos frameworks tm sido desenvolvidos nas duas ltimas dcadas, visando o

reuso de software e conseqentemente a melhoria da produtividade, qualidade e

manutenibilidade. Neste captulo so definidos os frameworks de software, bem como

diversos conceitos bsicos necessrios para entender sua finalidade. A seguir so dados

exemplos de alguns frameworks existentes e o framework Model-View-Controller visto

em maiores detalhes.

2.2 Conceitos & Terminologia

2.2.1 DefiniesUm Framework o projeto de um conjunto de objetos que colaboram entre si

para execuo de um conjunto de responsabilidades. Um framework reusa anlise, projeto e

cdigo. Ele reusa anlise porque descreve os tipos de objetos importantes e como um


24/37

22

problema maior pode ser dividido em problemas menores. Ele reusa projeto porque contm

algoritmos abstratos e descreve a interface que o programador deve implementar e as

restries a serem satisfeitas pela implementao. Ele reusa cdigo porque torna mais fcil

desenvolver uma biblioteca de componentes compatveis e porque a implementao de

novos componentes pode herdar grande parte de seu cdigo das super-classes abstratas.

Apesar de todos os tipos de reuso serem importantes, o reuso de anlise e de projeto so os

que mais compensam a longo prazo [Johnson 91].

2.2.2 Inverso de controleUma caracterstica importante dos frameworks que os mtodos definidos pelo

usurio para especializ-lo so chamados de dentro do prprio framework, ao invs de

serem chamados do cdigo de aplicao do usurio [Johnson 88]. O framework geralmente

faz o papel de programa principal, coordenando e sequenciando as atividades da aplicao.

Essa inverso de controle d fora ao framework para servir de esqueletos extensveis. Os

mtodos fornecidos pelo usurio especializam os algoritmos genricos definidos no

framework para uma aplicao especfica.

A Figura 3 mostra algumas diferenas bsicas entre bibliotecas e frameworks.

Conjunto de classes instanciadaspelo cliente

Cliente chama funes

Fluxo de controle no pr-definido

Interao no pr-definida

No tem comportamento default

Cuida da personalizaoatravs de subclasses

Chama funes do cliente

Controla o fluxo de execuo

Define a interao dos objetosTem comportamento default

Biblioteca Framework

Figura 3 Frameworks X Bibliotecas


25/37

23

2.2.3 Frameworks Caixa Branca X Caixa PretaO comportamento especfico de um framework de aplicao geralmente definido

adicionando-se mtodos s subclasses de uma ou mais de suas classes.

Existem dois tipos de frameworks: caixa branca e caixa preta [Johnson 88]. No

framework caixa branca o reuso provido por herana, ou seja, o usurio deve criarsubclasses das classes abstratas contidas no framework para criar aplicaes especficas.

Para tal, ele deve entender detalhes de como o framework funciona para poder us-lo. J no

framework caixa preta o reuso por composio, ou seja, o usurio combina diversas

classes concretas existentes no framework para obter a aplicao desejada. Assim, ele deve

entender apenas a interface para poder us-lo.

Um aspecto varivel de um domnio de aplicao chamado de ponto de

especializao (em ingls, Hot spot) [Buschman 96]. Diferentes aplicaes dentro de um

mesmo domnio so distinguidas por um ou mais hot spots. Eles representam as partes do

framework de aplicao que so especficas de sistemas individuais. Os hot-spots so

projetados para serem genricos podem ser adaptados s necessidades da aplicao.

Pontos fixos (em ingls, Frozen-spots) definem a arquitetura geral de um

sistema de software seus componentes bsicos e os relacionamentos entre eles. Os frozen-

spots permanecem fixos em todas as instanciaes do framework de aplicao.

A Figura 4 ilustra um framework caixa branca com um nico hot-spot R [Schmid

97]. Para utilizao do framework necessrio fornecer a implementao referente a esse

hot-spot, que no caso da Figura 4 R3.

Figura 4 - Framework Caixa-branca (White-box)

HotSpot

R

R3


26/37

24

A Figura 5 ilustra um framework caixa-preta, tambm com um nico hot-spot R.

Nesse framework, existem trs alternativas (R1, R2 e R3) para implementao da

responsabilidade R. O usurio deve escolher uma delas para obter sua aplicao especfica.

Note que R1, R2 e R3 fazem parte do framework e so as nicas alternativas possveis de

implementao do hot-spot. J no caso da Figura 4 R3 no fazia parte do framework, mas,

em compensao, qualquer alternativa de implementao do hot-spotseria possvel.

Figura 5 - Framework Caixa-preta (Black-box)

Resumindo, um framework caixa branca mais fcil de projetar, pois no h

necessidade de prever todas as alternativas de implementao possveis. J o frameworkcaixa preta mais difcil de projetar por haver a necessidade de fazer essa previso. Por

outro lado, o framework caixa preta mais fcil de usar, pois basta escolher a

implementao desejada, enquanto no caixa branca necessrio fazer essas

implementaes completas.

Frameworks caixa branca podem evoluir para se tornar cada vez mais caixa preta

[Johnson 97]. Isso pode ser conseguido de forma gradativa, implementando-se vrias

alternativas que depois so aproveitadas na instanciao do framework. Ao mesmo tempo

no se fecha totalmente o framework, permitindo ao usurio continuar usando-o como

caixa branca. Aps um certo tempo, estaro disponveis diversas alternativas e ento pode-

se decidir tornar o framework caixa preta de fato. A medida em que o framework vai se

tornando mais caixa preta, diminui o nmero de objetos criados, embora aumente a

complexidade das suas interconexes. Alm disso, o scripting fica mais importante, por

HotSpot

R R1

R2

R3

Ocorrncia devariabilidade


27/37

25

permitir a especificao das classes que faro parte da aplicao e sua interconexo. Pode-

se tambm construir ferramentas de apoio que ajudem na especificao da aplicao. Essas

ferramentas tm como objetivo facilitar a instanciao do framework, por meio do uso de

componentes visuais que sejam mais fceis de usar do que os comandos do script.

2.3 Classificao de Frameworks

Os frameworks so classificados em trs grupos [Fayad 97]: Frameworks de infra-

estrutura do sistema, frameworks de integrao de middleware e frameworks de

aplicao empresarial.

Os frameworks de infra-estrutura do sistema simplificam o desenvolvimento da

infra-estrutura de sistemas portveis e eficientes, como por exemplo os sistemas

operacionais, sistemas de comunicao, interfaces com o usurio e ferramentas de

processamento de linguagem. Em geral so usados internamente em uma organizao de

software e no so vendidos a clientes diretamente.

Os frameworks de integrao de middleware so usados, em geral, para integrar

aplicaes e componentes distribudos. Eles so projetados para melhorar a habilidade de

desenvolvedores em modularizar, reutilizar e estender sua infra-estrutura de software para

funcionar seamlessly em um ambiente distribudo. Exemplos dessa classe de framework

so o Object Request Broker (ORB), middleware orientado a mensagens e bases dedados transacionais.

Os frameworks de aplicao empresarial esto voltados a domnios de aplicao

mais amplos e so a pedra fundamental para atividades de negcios das empresas, como

por exemplo sistemas de telecomunicaes, aviao, manufatura e engenharia financeira.

Frameworks dessa classe so mais caros para desenvolver ou comprar, mas podem dar um

retorno substancial do investimento, j que permitem o desenvolvimento de aplicaes e

produtos diretamente.

2.4 Sntese de trabalhos afins

Diversos trabalhos na literatura tm dado enfoque construo e uso de

frameworks.


28/37

26

O framework de aplicao OOHDM-Java, cujo domnio composto pelas

aplicaes hipermdia modeladas com o mtodo OOHDM e disponibilizadas na WWW,

considera uma separao entre os dados da aplicao, os objetos navegacionais e os objetos

de interface, resultando em uma arquitetura mais flexvel. Ele pode ser classificado como

um framework caixa-branca, pelo fato de ser necessrio que o programador entenda o seu

projeto e a sua implementao, at um determinado grau de detalhe, para poder utiliz-lo.

No entanto, o framework composto internamente por alguns componentes considerados

caixas-pretas, j que estes requerem apenas o conhecimento da sua interface externa para

serem utilizados". O artigo traz detalhes de implementao e outros ligados ao OOHDM,

que so mais difceis de entender se o leitor no domina Java ou o mtodo OOHDM. O

interessante que a implementao do framework foi bem elaborada e consistente com a

fase de projeto. Usa vrias tecnologias atuais e realmente enfatiza a importncia de fazer amodelagem antes de implementar uma aplicao baseada nesse framework.

HotDraw [Johnson 92] um framework grfico bidimensional para editores de

desenho estruturado, escrito no VisualWorks Smalltalk. Ele tem sido usado para criar

diversos editores diferentes, desde ferramentas CASE at HyperCard clone. Pode-se

facilmente criar novas figuras e ferramentas especiais de manipulao para seus desenhos.

Ao contrrio de muitos editores de desenhos, os desenhos do HotDraw podem ser

animados. A Figura 6 mostra um exemplo do editor defaulteditando algumas figuras.

2.5 Exemplos

A maioria dos frameworks existentes para domnios tcnicos tais como interfaces

com o usurio ou distribuio, como por exemplo os frameworks MacApp, especfico para

aplicaes Macintosh, o Lisa Toolkit, o Smalltalk Model View Controller, o Interviews,

etc. A maioria dos frameworks para aplicaes especficas no de domnio pblico.

Exemplos so o ET++, ACE, Microsoft Foundation Classes (MFC) e DCOM, JavaSoftsRMI e implementaes do OMGs CORBA.

O Model-View-Controller (MVC) [Krasner 88] foi o primeiro framework

largamente utilizado. Ele foi inicialmente implementado em Smalltalk-80, mas atualmente

conta com implementaes em todas as verses existentes de Smalltalk, como o

VisualWorks, VisualAge, Dolphin, Squeak, etc. O MVC usado pelo Smalltalk como


29/37

27

interface com o usurio, tendo mostrado a adequao da orientao a objetos para

implementao de interfaces grficas com o usurio.

Figura 6 Editor defaultdo HotDraw

2.6 Exerccios

1) Compare frameworks caixa branca e caixa preta.

2) Apresente um exemplo de um possvel hot-spotem um framework qualquer.

3) Discuta o impacto da evoluo de um framework quanto manuteno de

aplicaes dele derivadas4) Discuta


30/37

28

Figura 7 Exemplo de modelo com vrias vises

ControllerInterao c/os

dispositivosde entrada do

usurio

ViewMostra a sada

e vises dainterao

ModelEstado e

comportamento

do domnio deaplicao

sensores deentrada do

usurio

sada

Mensagensde mudana

dosdependentes

Mensagensde mudana

dosdependentes

Mensagens deacesso ao

modelo e edio

Mensagens deviso

Figura 8 Estrutura do Model-View-Controller

Black: 43%Red: 39%Blue: 6%Green: 10%Others: 2%

Dadosprincipais


31/37

29

2.7 Concluses

Padres documentam uma parte repetida de um projeto orientado a objetos,

permitindo seu entendimento e aplicao em um contexto particular. Eles fornecem ao

projeto um vocabulrio comum aos desenvolvedores, facilitando a comunicao entre

projetistas. Alm disso, eles constituem uma base de experincia para construo de

software reutilizvel. Pode-se pensar em padres como blocos construtivos a partir dos

quais projetos mais complexos podem ser construdos

Padres expem conhecimento sobre a construo de software que foi ganho por

especialistas em muitos anos. Portanto, todo trabalho sobre padres deveria esforar-se para

colocar esse recurso precioso amplamente disponvel [Buschmann 96]: Todo

desenvolvedor de software deveria ser capaz de usar padres de forma efetiva. Quando issofor conseguido, seremos capazes de comemorar a inteligncia humana que os padres

refletem, tanto em cada padro individual quanto em todos os padres na sua plenitude.

Tanto padres quanto frameworks so valiosos instrumentos de reuso. Alm disso,

os padres so preciosos para a documentao dos frameworks.

Com frameworks bem projetados fica muito mais fcil fazer extenses, fatorar a

funcionalidade comum, promover a interoperabilidade e melhorar a manuteno e

confiabilidade de software [Taligent 93].

Frameworks fornecem a infra-estrutura e diretrizes arquiteturais de um sistema de

software. A maior parte da funcionalidade j existe no framework, reduzindo codificao,

teste e depurao. O exemplo de cdigo fornecido guia os desenvolvedores no uso da

tecnologia de objetos.

A Figura 9 ilustra os benefcios obtidos versus os custos de construo de

frameworks [Taligent 93, 94].


32/37

30

Economia a longo prazo

Aproveitamento da experincia deespecialistas do domnio

Maior consistncia e integrao entreaplicaes

Reduo da manuteno: menos linhas decdigo nas aplicaes, reparos no frameworkse propagam pelas aplicaes

Melhora da produtividade: os programadorespodem se concentrar nas caractersticasespecficas de suas aplicaes

Benefcios

Custos

Mais esforo para

construo e aprendizadoProgramas mais difceisde depurar

Necessriadocumentao demanuteno e apoio

Figura 9 Custo X Benefcio de Frameworks

3 Comparao entre as diversas formas de reuso

Fazendo uma comparao entre padres e frameworks, Johnson [Johnson 97] diz

que padres so mais abstratos do que frameworks, porque um framework um software

executvel, enquanto um padro representa conhecimento e experincia sobre software

(pode-se dizer que frameworks tm natureza fsica enquanto que padres tm natureza

lgica). Os padres so menores do que frameworks. Em geral padres so compostos por

2 ou 3 classes, enquanto os frameworks envolvem um nmero bem maior de classes,

podendo englobar diversos padres. Os padres so menos especializados do que

frameworks, j que os frameworks geralmente so desenvolvidos para um domnio de

aplicao especfico e os padres (ou muitos deles) podem ser usados em diversos tipos de

aplicao. Apesar de haver padres mais especializados, eles no so capazes de ditar aarquitetura de uma aplicao, ao contrrio dos frameworks.

Comparando frameworks com bibliotecas de programao, nas bibliotecas os

componentes no esto inter-relacionados, enquanto em frameworks os componentes

cooperam entre si. Em uma biblioteca de programao o desenvolvedor responsvel pela

chamada de componentes e fluxo de controle do programa enquanto em um framework h a


33/37

31

inverso de papis: o programa principal reutilizado e o desenvolvedor decide quais

componentes so chamados e deriva novos componentes. O framework determina a

estrutura geral e o fluxo de controle do programa.

Comparando frameworks com geradores de aplicao, pelo menos duas

semelhanas so encontradas:

ambos envolvem anlise de domnio para sua construo, na qual diferentes

aplicaes dentro do mesmo domnio so estudadas e posteriormente

generalizadas

e ambos resultam em cdigo que integrar uma aplicao especfica, embora

com o uso de um framework novas classes possam ser criadas e nele embutidas

para uso futuro.

Existem, porm, diversas diferenas entre eles: nos geradores de aplicao necessrio fornecer uma especificao do sistema

em alto nvel para obter o produto final, enquanto no framework so apenas

informados os pontos variveis, com possvel criao de novas classes, para a

instanciao do framework para uma aplicao especfica.

frameworks implicam o uso da orientao a objetos, j que sua definio

envolve classes, enquanto geradores de aplicao so independentes do

paradigma de desenvolvimento. nos frameworks o cdigo herdado enquanto em geradores de aplicao o

cdigo gerado. Assim, grande parte do cdigo de um framework incorporado

ao produto final, enquanto grande parte do cdigo do gerador de aplicao existe

apenas para fornecer mecanismos de gerao do cdigo do produto final.


34/37

32

Referncias:

[Alexander 77] Christopher Alexander et. al., A Pattern Language, Oxford University

Press, New York, 1977.[Alexander 79] Christopher Alexander, The Timeless Way of Building, Oxford UniversityPress, New York, 1979.

[Appeton 97] Appleton, Brad. Patterns and Software: Essential Concepts andTerminology, disponvel na WWW na URL:http://www.enteract.com/~bradappdocpatterns-intro.html.

[Beck 87] Beck, Kent; Cunningham, Ward. Using Pattern Languages for Object-Oriented Programs, Technical Report n CR-87-43, 1987, disponvel naWWW na URL: http://c2.com/doc/oopsla87.html

[Bosch 97] Bosch, Jan. Design Patterns as Language Constructs, disponvel naWWW na URL: http://st-www.cs.uiuc.edu/users/patterns/papers, 1997.

[Boyd 98] Boyd, L. Business Patterns of Association Objects. In: Martin, R.C.;Riehle, D.; Buschmann, F. Pattern Languages of Program Design 3.Reading, MA, Addison-Wesley, 1998, p. 395-408.

[Braga 98a] Braga, Rosana T. V.; Germano, Ferno S.R.; Masiero, Paulo C.A Familyof Patterns for Business Resource Management. In Proceedings of the 5th

Annual Conference on Pattern Languages of Programs (PLOP98),Monticello, Illinois, Technical Report #WUCS-98-25, WashingtonUniversity in St. Louis, Missouri, EUA, agosto de 1998, disponvel naWWW na URL: http://jerry.cs.uiuc.edu/plop/plopd4-submissions/plopd4-submissions.html.

[Braga 98b] Braga, Rosana T.V.; Germano, Ferno S.R.; Masiero, Paulo C.

Experimentos para implementao do padro Type-Object em linguagemDelphi.So Carlos, USP, 1998. (Documento de Trabalho, ICMSC-USP,So Carlos, SP)

[Budinsky 96] Budinsky, F.J, et al. Automatic code generation from design patterns.IBM Systems Journal, V. 35, n 2, p. 151-171, 1996.

[Buschmann 96] Buschmann, F. et at.A System of Patterns, Wiley, 1996.[Chikofsky 90] Chikofsky, E.J.; Cross, J.H. Reverse Engineering and Design Recovery: A

Taxonomy. IEEE Trans. Software, pp. 13-17, Janeiro 1990.[CMG 98] Component Management Group (CMG). Anti-patterns, disponvel na

WWW na URL: http://160.79.202.73/Resource/AntiPatterns/index.html.[Coad 91] Coad, Peter/ Yourdon, Edward. Object-Oriented Analysis, 2 edio,

Yourdon Press, 1991.[Coad 92] Coad, Peter. Object-Oriented Patterns. Communications of the ACM, V.35, n9, p. 152-159, setembro 1992.

[Coad 95] Coad, P.; North, D.; Mayfield, M. Object Models: Strategies, Patternsand Applications, Yourdon Press, 1995.

[Cook 94] Cook, Steve; Daniel, John. Designing Object Systems. Prentice Hall,1994.


35/37

33

[Coleman 94] Coleman, D. et al. Object Oriented Development - the Fusion Method.Prentice Hall, 1994.

[CMG 98] Component Management Group (CMG). Anti-patterns, disponvel naWWW na URL: http://160.79.202.73/Resource/AntiPatterns/index.html.

[Coplien 92] Coplien, J.O. Advanced C++ Programming Styles and Idioms. Reading-

MA, Addison-Wesley, 1992.[Coplien 95] Coplien, J.; Schmidt, D. (eds.) Pattern Languages of Program Design,Reading-MA, Addison-Wesley, 1995.

[Coplien 98] James O. Coplien. Software Design Patterns: Common Questions andAnswers. In Linda Rising, editor, The Patterns Handbook: Techniques,Strategies, and Applications, p. 311-320. Cambridge University Press,New York, January 1998.

[Cunningham 95] Cunningham,Ward. The CHECKS Pattern Language of InformationIntegrity. In Coplien, J.; Schmidt, D. (eds.) Pattern Languages ofProgram Design, Reading-MA, Addison-Wesley, 1995, p. 145-155.

[Cunningham 96] Cunningham,Ward. EPISODES: A Pattern Language of CompetitiveDevelopment. In: Vlissides, J.; Coplien, J.; Kerth, N (eds.). PatternLanguages of Program Design 2. Reading-MA; Addison-Wesley, 1996,p. 371-388.

[Eriksson 98] Eriksson, H.; Penker, M. UML Toolkit. New York, Wiley ComputerPublishing, 1998.

[Fayad 97] Fayad, M.E.; Schmidt, D.C. (eds) Object-Oriented ApplicationFrameworks. Communications of the ACM, V. 40, n 10, p. 32-38, 1997.

[Fowler 97] Fowler, M.Analysis Patterns. Menlo-Park-CA, Addison-Wesley, 1997.[Gall 96] Gall, Harald C., Klsh, Ren R.; Mittermeir, Roland T. Application

Patterns in Re-Engineering: Identifying and Using Reusable Concepts.Proceedings of the 6th International Conference on InformationProcessing and Management of Uncertainty in Knowledge-BasedSystems, Julho 1996,p. 1099-1106.

[Gamma 93] Gamma, E.; Helm, R.; Johnson,R.; Vlissides, J. Design Patterns -Abstraction and Reuse of Object-Oriented Design. LNCS, n 707, p. 406-431, julho de 1993.

[Gamma 95] Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. Design Patterns -Elements of Reusable Object-Oriented Software. Reading-MA, Addison-Wesley, 1995.

[Graham 94] Graham, Ian. Object Oriented Methods, 2 edio, Addison-Wesley,1994.

[Johnson 88] Johnson, Ralph E.; Foote B. Designing Reusable Classes. Journal ofObject Oriented Programming JOOP, 1(2):22-35, Junho/Julho 1988.

[Johnson 91] Johnson, Ralph E.; Russo, Vincent. Reusing Object-Oriented Designs.Relatrio Tcnico da Universidade de Illinois, UIUCDCS 91-1696, 1991.

[Johnson 97] Johnson, Ralph E. CS497 Lectures Lecture 12, 13, 14 e 17, disponvelna WWW na URL: http://st-www.cs.uiuc.edu/users/johnson/cs497/notes98/online-course.html

[Johnson 97a] Johnson, Ralph. E. Frameworks = (Components + Patterns).Communications of the ACM, V. 40, n 10, p. 39-42, 1997.


36/37

34

[Johnson 98] Johnson, Ralph E.; Woolf, B. Type Object. In: Martin, R.C.; Riehle, D.;Buschmann, F. Pattern Languages of Program Design 3. Reading-MA,Addison-Wesley, 1998, p. 47-65.

[Kerth 97] Kerth, Norman L.; Cunningham, Ward. Using Patterns to Improve OurArchitectural Vision, IEEE Software, pp. 53-59, janeiro, 1997.

[Kramer 96] Krmer, Christian; Prechelt, Lutz.Design Recovery by Automated Search for Structural Design Patterns in Object-Oriented Software. Proceedingof the 3rd Working Conference on Reverse Engineering (WCRE),Monterey-CA, EUA, 1996, p. 208-215.

[Krasner 88] Krasner, E. K.; Pope, S.T. A Cookbook for using the Model-View-Controller User Interface Paradigm in Smalltalk-80. Journal of ObjectOriented Programming, p. 26-49, Agosto-Setembro 1988.

[Martin 98] Martin, R.C.; Riehle, D.; Buschmann, F. (eds.) Pattern Languages ofProgram Design 3, Reading-MA, Addison-Wesley, 1998.

[Masiero 93] Masiero, P.C.; Meira, C.A. A. Development and Instantiation of aGeneric Application Generator. Journal of Systems and Software, Vol.23, pp. 27-37, 1993.

[Masiero 98] Masiero, P.C.; Germano, F.S; Maldonado, J.C. Object and System LifeCycles Revisited: Their Use in Object-Oriented Analysis and Design

Methods. Proceedings of the 3rd CaiSE/IFIP8.1 (International Workshopon Evaluation of Modeling Methods in Systems Analysis and Design),Pisa, Italy, pp. O1-O12, Junho 1998.

[Meira 91] MEIRA, C.A.A. Sobre Geradores de Aplicao, Dissertao de Mestradoapresentada ao Instituto de Cincias Matemticas de So Carlos, USP,setembro de 1991.

[Meszaros 95] Meszaros, Gerard. A Pattern Language for Improving the Capacity ofReactive Systems. In: Coplien, J.; Schmidt, D. (eds.) Pattern Languagesof Program Design, Reading-MA, Addison-Wesley, 1995, p. 575-591.

[Pree 95] Pree, Wolfgang. Design Patterns for Object-Oriented SoftwareDevelopment. Reading-MA, Addison-Wesley, 1995.

[Pressman 95] Pressman, Roger S.Engenharia de Software, Makron Books, 1995.[Riehle 95] Riehle, Dirk; Zllighoven, Heinz. A Pattern Language for Tool

Construction and Integration Based on the Tools and MaterialsMetaphor. In: Coplien, J.; Schmidt, D. (eds.) Pattern Languages ofProgram Design, Reading-MA, Addison-Wesley, 1995, p. 9-42.

[Roberts 98] Roberts, Don; Johnson, Ralph E. Evolving Frameworks: A Pattern Language for Developing Object-Oriented Frameworks, In Martin, R.C.; Riehle, D. and Buschmann, F. Pattern Languages of Program Design3, Addison-Wesley, pp. 471-486, 1998, disponvel na WWW na URL:http://st-www.cs.uiuc.edu/users/droberts/evolve.html

[Schmidt 96] Schmidt, Douglas C.; Fayad, Mohamed; Johnson, Ralph E. (guesteditors). Software Patterns. Communications of the ACM, V. 39, n10,pp. 36-39, outubro 1996.

[Schmid 97] Schmid, H. A. Systematic Framework Design by generalization.Communications of the ACM, V. 40, n 10, p. 48-51, 1997.

[Taligent 93] Taligent Inc.Leveraging Object-Oriented Frameworks. A Taligent WhitePaper, 1993, disponvel na WWW na URL:


37/37

http://www.ibm.com/java/education/ooleveraging.[Taligent 94] Taligent Inc. Building Object-Oriented Frameworks. A Taligent White

Paper, 1994, disponvel na WWW na URL:http://www.ibm.com/java/education/oobuilding/index.html.

[Turine 98] Turine, Marcelo A. S. Fundamentos, Conceitos e Aplicaes do

Paradigma de Orientao a Objetos. Apresentao didtica, agosto de1998, disponvel na WWW na URL:http://nt-labes.icmsc.sc.usp.br/cursos/sce220/02_98/aulas.html

[Vlissides 95] Vlissides, John. Reverse Architecture, Position Paper for SoftwareArchitectures Seminar, Schloss Daghstuhl, Germany, agosto 1995,disponvel na WWW na URL:http://st-www.cs.uiuc.edu/users/patterns/papers/,.

[Vlissides 96] Vlissides, J.; Coplien, J.; Kerth, N (eds.). Pattern Languages of ProgramDesign 2. Reading-MA; Addison-Wesley, 1996.

[Yoder 98] Yoder, J.W.; Johnson, R.E.; Wilson, Q.D. Connecting Business Objects to Relational Databases. Proceedings of the 5th Conference on the PatternLanguages of Programs, Monticello-IL, EUA, agosto de 1998. (RelatrioTcnico n WUCS-98-25 da Universidade de Washington), disponvel naWWW na URL: http://jerry.cs.uiuc.edu/~plop/plop98/final_submissions/

padrões apostila

Documents