Vous êtes sur la page 1sur 37

UNIVERSIDADE DE SO PAULO

INSTITUTO DE CINCIAS MATEMTICAS E DE COMPUTAO

Padres e Frameworks de Software


(Notas Didticas) Editores: Jos Carlos Maldonado Rosana Teresinha Vaccare Braga Ferno Stella Rodrigues Germano Paulo Cesar Masiero

Sumrio
SUMRIO ......................................................................................................................................................... 1 1 PADRES ................................................................................................................................................... 1 1.1 COMPONENTES DE UM PADRO............................................................................................................... 2 1.2 ANTI-PADRES ....................................................................................................................................... 4 1.3 CLASSIFICAO DE PADRES ................................................................................................................. 4 1.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 ................................................................................... 18 1.6 DESENVOLVIMENTO DE SISTEMAS USANDO PADRES ........................................................................... 19 1.7 EXERCCIOS .......................................................................................................................................... 20 2 FRAMEWORKS ...................................................................................................................................... 21 2.1 INTRODUO ........................................................................................................................................ 21 2.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 ....................................................................................................... 25 2.4 SNTESE DE TRABALHOS AFINS.............................................................................................................. 25 2.5 EXEMPLOS ............................................................................................................................................ 26 2.6 EXERCCIOS .......................................................................................................................................... 27 2.7 CONCLUSES ........................................................................................................................................ 29 3 COMPARAO ENTRE AS DIVERSAS FORMAS DE REUSO...................................................... 30 REFERNCIAS: ............................................................................................................................................ 32

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 de padres 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 a estrutura 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].

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 o problema 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
2

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 relacionados geralmente 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 aplicados

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

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.

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 armazenamento 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 exemplo padres 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
5

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

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
7

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

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 perspectiva especfica: 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
9

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 organizao tambm 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..
10

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
2- Padres de propsitos gerais 3- Padres de propsitos especficos

Padro
Command Processor Shopper

Autor
Peter Sommerlad Jim Doble

A Structural Pattern for Designing Transparent Aamod Sane e Roy Campbell Layered Services Patterns for Processing Satellite Telemetry with Stephen Berczuk Distributed Teams A Pattern Integration Transactions and Accounts Language for Object-RDBMS Kyle Brown e Bruce Whitenack Ralph Johnson Dana Anthony

6- Padres de Exposio

Patterns for Classroom Education

A Pattern Language for the Preparation of Todd Coram Software Demonstrations A Pattern Language for na Essay-Based Web Robert Orenstein Site

Catlogos de padres

11

[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 Classe Factory Method Objeto Abstract Factory Builder Prototype Singleton Estrutural Adapter Adapter Bridge Composite Decorator Facade Flyweygth Proxy Comportamental Interpreter Template Method Chain of Responsability Command Iterator Mediator Memento Observer State Strategy Visitor

Escopo

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

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

13

[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 um software 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;

14

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 Da lama para a estrutura Sistemas Distribudos Sistemas Interativos Sistemas adaptveis Decomposio da estrutura Organizao do trabalho Controle de Acesso Gerenciamento Comunicao Layers Pipes and Filters Blackboard Brokers Pipes and Filters Microkernel MVC PAC Microkernel Reflection

Padres de projeto

Idiomas

Whole-Part Master-Slave Proxy Command Processor View Handler Publisher-Subscriber Forwarder-Receiver Cliente-Dispatcher-Server Counted Pointer

Manuseio de Recursos

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
15

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.
Capacity Bottleneck

Memory Capacity

Processing Capacity

Messaging Capacity

Faster Processor

Optimize HighRunner Cases

Shed Load

Share the Load

Finish Work in Progress

Fresh Work Before Stale

Match Progress Work with New

Shed Work at Periphery

Different Strokes for Different Folks

Hash Access Port

Leaky Bucket of Credits

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
16

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 interrelacionamento entre seus diversos padres.
Tabela 4 Padres da Linguagem e propsitos

Padro
Capacity Bottleneck Memory Capacity Processing Capacity Messaging Capacity Faster Processor Optimize High-Runner Cases Shed Load Share the Load

Propsito
Quando h um gargalo na capacidade do sistema, como proceder. Quando a causa do gargalo na capacidade do sistema a capacidade de memria, como proceder. Quando a causa do gargalo na capacidade do sistema a capacidade de processamento, como proceder. Quando a causa do gargalo na capacidade do sistema a dificuldade de enviar mensagens entre processadores a tempo, como proceder. Quando um processador mais rpido necessrio para aumentar a capacidade de processamento do sistema, como proceder. Quando a otimizao dos casos de maior demanda necessria para aumentar a capacidade de processamento do sistema, como proceder. Quando o descarte de parte da demanda necessrio para evitar sobrecarga da capacidade de processamento do sistema, como proceder. Quando o atendimento da demanda deve ser compartilhado por mais de um processador para aumentar a capacidade de processamento do sistema, como proceder. Quando o trmino do atendimento de trabalho em curso necessrio para evitar sobrecarga da capacidade de processamento do sistema,, como proceder. Quando o atendimento prioritrio de certos clientes necessrio para evitar sobrecarga da capacidade de processamento do sistema, como proceder. Quando necessrio evitar o desperdcio dos recursos j empregados no atendimento de certos clientes, causado por sua desistncia de obter atendimento, como proceder. Quando necessrio o descarte da demanda que est alm da capacidade de processamento do sistema, como proceder para detectar o quanto antes o que dever ser descartado. Quando necessrio o estabelecimento de prioridades para o atendimento de certos clientes, como proceder para garantir que esse atendimento seja de boa qualidade. Quando o estabelecimento de funes Hash na porta de entrada de atendimento prioritrio necessrio para estabelecer as prioridades, como proceder. Quando reservatrios com vazamento so necessrios para armazenar os crditos enviados aos processadores perifricos por processadores sobrecarregados que todavia ainda possuem capacidade de processamento disponvel, como proceder

Finish Work in Progress Fresh Work before Stale Match Progress work with new Shed Work at Periphery

Different Strokes for Different Folks Hash Access Port Leaky Bucket of Credits

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


17

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 do trabalho 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 ser reconhecidas 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:

18

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 software em 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.

19

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 autores destas notas didticas? Por que?

20

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 e relacionamentos 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 Definies Um 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
21

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 controle Uma 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.

Biblioteca

Framework

Conjunto de classes instanciadas pelo cliente Cliente chama funes Fluxo de controle no pr-definido Interao no pr-definida No tem comportamento default

Cuida da personalizao atravs de subclasses Chama funes do cliente Controla o fluxo de execuo Define a interao dos objetos Tem comportamento default

Figura 3 Frameworks X Bibliotecas

22

2.2.3 Frameworks Caixa Branca X Caixa Preta O 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 criar subclasses 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 frozenspots 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.

R R3 Hot Spot

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

23

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-spot seria possvel.

R Hot Spot

R1 R2 R3

Ocorrncia de variabilidade

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 framework caixa 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 podese 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
24

permitir a especificao das classes que faro parte da aplicao e sua interconexo. Podese 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 infraestrutura 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 de dados 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.
25

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 a modelagem 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 default editando 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, JavaSofts RMI 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
26

interface com o usurio, tendo mostrado a adequao da orientao a objetos para implementao de interfaces grficas com o usurio.

Figura 6 Editor default do HotDraw

2.6 Exerccios
1) Compare frameworks caixa branca e caixa preta. 2) Apresente um exemplo de um possvel hot-spot em um framework qualquer. 3) Discuta o impacto da evoluo de um framework quanto manuteno de aplicaes dele derivadas 4) Discuta

27

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

Dados principais

Figura 7 Exemplo de modelo com vrias vises

Controller
Interao c/os dispositivos de entrada do usurio

Mensagens de viso

View
Mostra a sada e vises da interao

sensores de entrada do usurio

sada

Mensagens de acesso ao modelo e edio Mensagens de mudana dos dependentes

Model
Estado e comportamento do domnio de aplicao

Mensagens de mudana dos dependentes

Figura 8 Estrutura do Model-View-Controller

28

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 isso for 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].

29

Custos Benefcios
Economia a longo prazo Aproveitamento da experincia de especialistas do domnio Maior consistncia e integrao entre aplicaes Reduo da manuteno: menos linhas de cdigo nas aplicaes, reparos no framework se propagam pelas aplicaes Melhora da produtividade: os programadores podem se concentrar nas caractersticas especficas de suas aplicaes Mais esforo para construo e aprendizado Programas mais difceis de depurar Necessria documentao de manuteno 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 a arquitetura 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
30

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.

31

Referncias:
Christopher Alexander et. al., A Pattern Language, Oxford University Press, New York, 1977. [Alexander 79] Christopher Alexander, The Timeless Way of Building, Oxford University Press, New York, 1979. [Appeton 97] Appleton, Brad. Patterns and Software: Essential Concepts and Terminology, disponvel na WWW na URL: http://www.enteract.com/~bradappdocpatterns-intro.html. [Beck 87] Beck, Kent; Cunningham, Ward. Using Pattern Languages for ObjectOriented Programs, Technical Report n CR-87-43, 1987, disponvel na WWW na URL: http://c2.com/doc/oopsla87.html [Bosch 97] Bosch, Jan. Design Patterns as Language Constructs, disponvel na WWW 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 Family of 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, Washington University in St. Louis, Missouri, EUA, agosto de 1998, disponvel na WWW 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 linguagem Delphi. 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, Patterns and Applications, Yourdon Press, 1995. [Cook 94] Cook, Steve; Daniel, John. Designing Object Systems. Prentice Hall, 1994. [Alexander 77]

32

[Coleman 94] [CMG 98] [Coplien 92] [Coplien 95] [Coplien 98]

[Cunningham

[Cunningham

[Eriksson 98] [Fayad 97] [Fowler 97] [Gall 96]

[Gamma 93]

[Gamma 95]

[Graham 94] [Johnson 88] [Johnson 91] [Johnson 97]

[Johnson 97a]

Coleman, D. et al. Object Oriented Development - the Fusion Method. Prentice Hall, 1994. Component Management Group (CMG). Anti-patterns, disponvel na WWW na URL: http://160.79.202.73/Resource/AntiPatterns/index.html. Coplien, J.O. Advanced C++ Programming Styles and Idioms. ReadingMA, Addison-Wesley, 1992. Coplien, J.; Schmidt, D. (eds.) Pattern Languages of Program Design, Reading-MA, Addison-Wesley, 1995. James O. Coplien. Software Design Patterns: Common Questions and Answers. In Linda Rising, editor, The Patterns Handbook: Techniques, Strategies, and Applications, p. 311-320. Cambridge University Press, New York, January 1998. 95] Cunningham,Ward. The CHECKS Pattern Language of Information Integrity. In Coplien, J.; Schmidt, D. (eds.) Pattern Languages of Program Design, Reading-MA, Addison-Wesley, 1995, p. 145-155. 96] Cunningham,Ward. EPISODES: A Pattern Language of Competitive Development. In: Vlissides, J.; Coplien, J.; Kerth, N (eds.). Pattern Languages of Program Design 2. Reading-MA; Addison-Wesley, 1996, p. 371-388. Eriksson, H.; Penker, M. UML Toolkit. New York, Wiley Computer Publishing, 1998. Fayad, M.E.; Schmidt, D.C. (eds) Object-Oriented Application Frameworks. Communications of the ACM, V. 40, n 10, p. 32-38, 1997. Fowler, M. Analysis Patterns. Menlo-Park-CA, Addison-Wesley, 1997. 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 Information Processing and Management of Uncertainty in Knowledge-Based Systems, Julho 1996, p. 1099-1106. Gamma, E.; Helm, R.; Johnson,R.; Vlissides, J. Design Patterns Abstraction and Reuse of Object-Oriented Design. LNCS, n 707, p. 406431, julho de 1993. Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. Design Patterns Elements of Reusable Object-Oriented Software. Reading-MA, AddisonWesley, 1995. Graham, Ian. Object Oriented Methods, 2 edio, Addison-Wesley, 1994. Johnson, Ralph E.; Foote B. Designing Reusable Classes. Journal of Object Oriented Programming JOOP, 1(2):22-35, Junho/Julho 1988. Johnson, Ralph E.; Russo, Vincent. Reusing Object-Oriented Designs. Relatrio Tcnico da Universidade de Illinois, UIUCDCS 91-1696, 1991. Johnson, Ralph E. CS497 Lectures Lecture 12, 13, 14 e 17, disponvel na WWW na URL: http://st-www.cs.uiuc.edu/users/johnson/cs497 /notes98/online-course.html Johnson, Ralph. E. Frameworks = (Components + Patterns). Communications of the ACM, V. 40, n 10, p. 39-42, 1997.
33

[Johnson 98]

[Kerth 97] [Kramer 96]

[Krasner 88]

[Martin 98] [Masiero 93]

[Masiero 98]

[Meira 91]

[Meszaros 95]

[Pree 95] [Pressman 95] [Riehle 95]

[Roberts 98]

[Schmidt 96]

[Schmid 97] [Taligent 93]

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, Norman L.; Cunningham, Ward. Using Patterns to Improve Our Architectural Vision, IEEE Software, pp. 53-59, janeiro, 1997. Krmer, Christian; Prechelt, Lutz. Design Recovery by Automated Search for Structural Design Patterns in Object-Oriented Software. Proceeding of the 3rd Working Conference on Reverse Engineering (WCRE), Monterey-CA, EUA, 1996, p. 208-215. Krasner, E. K.; Pope, S.T. A Cookbook for using the Model-ViewController User Interface Paradigm in Smalltalk-80. Journal of Object Oriented Programming, p. 26-49, Agosto-Setembro 1988. Martin, R.C.; Riehle, D.; Buschmann, F. (eds.) Pattern Languages of Program Design 3, Reading-MA, Addison-Wesley, 1998. Masiero, P.C.; Meira, C.A. A. Development and Instantiation of a Generic Application Generator. Journal of Systems and Software, Vol. 23, pp. 27-37, 1993. Masiero, P.C.; Germano, F.S; Maldonado, J.C. Object and System Life Cycles Revisited: Their Use in Object-Oriented Analysis and Design Methods. Proceedings of the 3rd CaiSE/IFIP8.1 (International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design), Pisa, Italy, pp. O1-O12, Junho 1998. MEIRA, C.A.A. Sobre Geradores de Aplicao, Dissertao de Mestrado apresentada ao Instituto de Cincias Matemticas de So Carlos, USP, setembro de 1991. Meszaros, Gerard. A Pattern Language for Improving the Capacity of Reactive Systems. In: Coplien, J.; Schmidt, D. (eds.) Pattern Languages of Program Design, Reading-MA, Addison-Wesley, 1995, p. 575-591. Pree, Wolfgang. Design Patterns for Object-Oriented Software Development. Reading-MA, Addison-Wesley, 1995. Pressman, Roger S. Engenharia de Software, Makron Books, 1995. Riehle, Dirk; Zllighoven, Heinz. A Pattern Language for Tool Construction and Integration Based on the Tools and Materials Metaphor. In: Coplien, J.; Schmidt, D. (eds.) Pattern Languages of Program Design, Reading-MA, Addison-Wesley, 1995, p. 9-42. 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 Design 3, Addison-Wesley, pp. 471-486, 1998, disponvel na WWW na URL: http://st-www.cs.uiuc.edu/users/droberts/evolve.html Schmidt, Douglas C.; Fayad, Mohamed; Johnson, Ralph E. (guest editors). Software Patterns. Communications of the ACM, V. 39, n10, pp. 36-39, outubro 1996. Schmid, H. A. Systematic Framework Design by generalization. Communications of the ACM, V. 40, n 10, p. 48-51, 1997. Taligent Inc. Leveraging Object-Oriented Frameworks. A Taligent White Paper, 1993, disponvel na WWW na URL:
34

[Taligent 94]

[Turine 98]

[Vlissides 95]

[Vlissides 96] [Yoder 98]

http://www.ibm.com/java/education/ooleveraging. 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, Marcelo A. S. Fundamentos, Conceitos e Aplicaes do Paradigma de Orientao a Objetos. Apresentao didtica, agosto de 1998, disponvel na WWW na URL: http://nt-labes.icmsc.sc.usp.br/cursos/sce220/02_98/aulas.html Vlissides, John. Reverse Architecture, Position Paper for Software Architectures Seminar, Schloss Daghstuhl, Germany, agosto 1995, disponvel na WWW na URL: http://st-www.cs.uiuc.edu/users/patterns/papers/,. Vlissides, J.; Coplien, J.; Kerth, N (eds.). Pattern Languages of Program Design 2. Reading-MA; Addison-Wesley, 1996. Yoder, J.W.; Johnson, R.E.; Wilson, Q.D. Connecting Business Objects to Relational Databases. Proceedings of the 5th Conference on the Pattern Languages of Programs, Monticello-IL, EUA, agosto de 1998. (Relatrio Tcnico n WUCS-98-25 da Universidade de Washington), disponvel na WWW na URL: http://jerry.cs.uiuc.edu/~plop/plop98/final_submissions/

35

Vous aimerez peut-être aussi

  • 07 Links
    07 Links
    Document10 pages
    07 Links
    Nemésio Freitas Duarte Filho
    Pas encore d'évaluation
  • Vagas Autbank para 1 2014
    Vagas Autbank para 1 2014
    Document1 page
    Vagas Autbank para 1 2014
    Nemésio Freitas Duarte Filho
    Pas encore d'évaluation
  • Program A Conte Csi
    Program A Conte Csi
    Document72 pages
    Program A Conte Csi
    Nemésio Freitas Duarte Filho
    Pas encore d'évaluation
  • BPMN - Versão 20 (Beta) - em Português
    BPMN - Versão 20 (Beta) - em Português
    Document1 page
    BPMN - Versão 20 (Beta) - em Português
    José Perez
    Pas encore d'évaluation
  • Jhtp6 AppM Design Patterns
    Jhtp6 AppM Design Patterns
    Document14 pages
    Jhtp6 AppM Design Patterns
    Aline Scanavacca
    Pas encore d'évaluation
  • Apostila Curso PHP MySQL
    Apostila Curso PHP MySQL
    Document32 pages
    Apostila Curso PHP MySQL
    Juliano dos Santos da Silva
    100% (1)
  • Soa Modelo
    Soa Modelo
    Document33 pages
    Soa Modelo
    Leandro Murcia Britto Pena
    Pas encore d'évaluation
  • Apresentação 1
    Apresentação 1
    Document2 pages
    Apresentação 1
    Nemésio Freitas Duarte Filho
    Pas encore d'évaluation
  • 09a Exercicios
    09a Exercicios
    Document3 pages
    09a Exercicios
    Nemésio Freitas Duarte Filho
    Pas encore d'évaluation
  • SD 07
    SD 07
    Document36 pages
    SD 07
    Nemésio Freitas Duarte Filho
    Pas encore d'évaluation
  • Visual C#
    Visual C#
    Document41 pages
    Visual C#
    Anderson Luiz Silva
    Pas encore d'évaluation
  • Arq 0119
    Arq 0119
    Document12 pages
    Arq 0119
    Nemésio Freitas Duarte Filho
    Pas encore d'évaluation