Download - 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
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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].
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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.
-
8/3/2019 Padres apostila
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.
-
8/3/2019 Padres apostila
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/3/2019 Padres apostila
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].
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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..
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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.
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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;
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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)
-
8/3/2019 Padres apostila
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:
-
8/3/2019 Padres apostila
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.
-
8/3/2019 Padres apostila
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?
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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.
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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].
-
8/3/2019 Padres apostila
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
-
8/3/2019 Padres apostila
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.
-
8/3/2019 Padres apostila
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.
-
8/3/2019 Padres apostila
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.
-
8/3/2019 Padres apostila
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:
-
8/3/2019 Padres apostila
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/