UFSCar Universidade Federal de So Carlos

Departamento de Computao

Padres e Frameworks

MDS Metodologias de Desenvolvimento de Software Turma A

Professora Rosngela Dellosso Penteado
Autores: Marcelo Brando Theodoro Jnior RA 281069
Oscar Jos Fernandes Tanner RA 280801

1. ndice
2.

INTRODUO

3.

PADRES E LINGUAGENS DE PADRES

4.

FRAMEWORKS DE SOFTWARE ORIENTADOS A OBJETOS

5.

COMPARAO ENTRE FORMAS DE RESO

6.

PADRES DE ANLISE

7.

ABORDAGEM PARA CONSTRUO DE FRAMEWORKS

8.

ABORDAGENS PARA INSTANCIAO DE FRAMEWORKS

9.

BIBLIOGRAFIA

2. Introduo
A reutilizao de software um propsito enunciado quase que simultaneamente com o
surgimento da prpria Engenharia de Software [Bosch et al, 1999]. Porm, esse reso esbarra em
vrios obstculos como a prpria dificuldade em reutilizar o software e at mesmo o fato de ser
mais atraente recriar algo do que reutilizar algo pronto, entre outros. Este trabalho apresentar o
embasamento terico necessrio para que o reso de software usando padres e frameworks possa
vir a ser mais usado entre os leitores desta monografia.
O reso baseado em frameworks pode diminuir consideravelmente o tempo e o custo de
desenvolvimento, se bem feito. Alm do uso de frameworks, o desenvolvimento feito a partir da
modelagem usando um padro ou uma linguagem de padres facilita o processo de manuteno
futura, agregando qualidade ao software e reduzindo custos futuros.
Toda a parte terica mostrada nesta monografia servir de suporte ao entendimento da
apresentao em sala de aula e principalmente, quando ser mostrado como se instanciar um
sistema usando um framework e uma linguagem de padres.
3. Padres e Linguagens de Padres
O conceito de padro foi primeiramente definido na dcada de 70 por Alexander (consultar
bibliografia [iv]), um arquiteto que notou que poderia simplificar seu trabalho definindo uma forma
nica para resolver situaes parecidas. Alexander disse: Cada padro descreve um problema que
ocorre repetidas vezes em nosso ambiente, e ento descreve o ncleo da soluo para esse
problema, de forma que voc possa utilizar essa soluo milhes de vezes sem us-la do mesmo
modo duas vezes.
Esse conceito foi abstrado para a rea da computao por Beck e Cunningham (bibliografia
[v] e [vi]) que desenvolveram uma linguagem de padro para guiar programadores inexperientes em
Smalltalk. Na dcada de 1990 vrios autores iniciaram a criao de um catlogo de padres de
projeto. Esse catlogo foi publicado em um livro que posteriormente foi denominado Design
Patterns: Elements of Reusable Object-Oriented Software (ISBN 0-201-63361-2) que impulsionou
a disseminao dos padres de software dentro da comunidade cientfica.
Portanto, os padres de software descrevem solues para problemas que ocorrem com
freqncia no desenvolvimento de software. O intuito retratar a essncia do problema captado
pelos desenvolvedores durante anos de experincia e nomear uma soluo de sucesso. Isso pode ser
visto pelo simples fato de que dificilmente uma nova soluo criada quando se deseja resolver um

problema, o desenvolvedor ir utilizar-se de suas experincias passadas com problemas semelhantes

e ir adaptar a soluo anteriormente utilizada para resolver seu novo problema.
Uma forma de reconhecer mais facilmente onde e quando usar os padres necessrios
fazer uma separao por categorias, como forma de classific-los. Devemos tomar muito cuidado
com essa classificao, pois um padro pode facilmente estar contido em mais de uma categoria. Os
padres de processo definem solues para 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 anlise descrevem solues para problemas de anlise de sistemas,
embutindo conhecimento sobre um domnio de aplicao especfico. Padres de projeto definem
solues para problemas de projeto de software, enquanto padres de programao descrevem
solues de programao particulares de uma determinada linguagem ou regras gerais de estilo de
programao.
Alm do agrupamento de padres de acordo com seu nvel de abstrao, eles ainda podem
ser agrupados em colees, catlogos, sistemas e linguagens. Uma definio importante a de uma
linguagem de padres. Como ela possui vrios padres, a maior parte da linguagem formada pelos
padres em si. A outra parte da linguagem diz respeito a uma viso geral do domnio ao qual ela
est inserida, de sua aplicabilidade e de uma viso geral dos seus padres. Para definir essa outra
parte so sugeridas vrias formas por diversos autores. Basicamente uma linguagem de padro deve
apresentar um sumrio da linguagem, um sumrio de problemas e solues de cada padro, um
exemplo de aplicao da linguagem e um glossrio de termos. O sumrio da linguagem deve
explicar o porqu dos padres estarem juntos, o que foi encontrado em comum em mais de um
padro e como os padres podem trabalhar juntos para executar algo til. O sumrio de problemas e
solues composto de uma tabela que contm um de cada problema e a soluo correspondente.
Um exemplo deve ser escolhido para ilustrar, de preferncia, todos os padres de uma linguagem.
Um glossrio de termos deve explicar a terminologia que no seja familiar aos usurios.
Para definir os padres podemos utilizar vrios formatos, como o formato de Portland, o
formato GoF e o formato Appleton. Como exemplo o formato do GoF define que cada padro deve
conter os seguintes elementos: nome do padro; inteno; tambm conhecido como; motivao;
aplicabilidade; estrutura; participantes; colaboraes; conseqncias; implementao; cdigo
exemplo; usos conhecidos e padres relacionados.
Abaixo mostrado um exemplo com um padro da GRN para ilustrar como descrever um
padro.
Padro 1: IDENTIFICAR O RECURSO
Contexto : Seu sistema de negcio lida com uma ou mais das seguintes transaes: pedidos,
compras, vendas, locaes, aluguis, atribuies, reservas, consertos ou manutenes. Essas
transaes referem-se, por exemplo, a produtos de uma loja, fitas de vdeo em uma locadora, livros
em uma biblioteca, tempo de um especialista em uma clnica mdica ou carros em uma oficina
mecnica. Todos esses casos tratam de recursos de negcio gerenciados por sistemas especficos.
Problema : Como representar os recursos de negcio envolvidos nas transaes processadas
pelo sistema?
Influncias :
Recursos de negcio tm, em geral, atributos ou qualidades em comum. Guardar as informaes
pertinentes a cada recurso em particular importante para as empresas envolvidas em seu
gerenciamento;
Recursos de negcio so freqentemente classificados em diversas categorias. Por exemplo, em
uma locadora de vdeos, os filmes podem ser agrupados em categorias como Aventura, Suspense,
Romance, Comdia, etc. Essa qualificao til na obteno de relatrios expressivos como, por

exemplo, qual o tipo de filme preferido pelos clientes e que, portanto, merece maior investimento
na aquisio. A qualificao de recursos pode ser obtida adicionando um atributo classe que
representa o recurso, de modo que a categoria seja considerada um atributo do recurso. Essa
abordagem funciona bem quando a categoria simplesmente uma descrio do grupo, sem
comportamento prprio;
Quando existem atributos e mtodos comuns, inerentes ao grupo delimitado por esse atributo,
justifica-se a separao em duas classes. O espao necessrio para manter esses atributos para todo
recurso e a redundncia obtida so indesejveis. Entretanto, a separao pode aumentar o tempo de
processamento, j que uma classe precisar referenciar a outra e essa referncia deve ser cuidada
pelo sistema. Isso deve ser levado em considerao na otimizao do desempenho do sistema.
Se o recurso possuir apenas alguns atributos, esses podem ser colocados nas classes que
representam as transaes efetuadas pela organizao. Isso facilita a implementao, embora limite
a evoluo do software e cause redundncia de informaes.
A figura abaixo representa a modelagem do padro e ao lado, um exemplo modelado usando o
padro.

Os padres da GRN so descritos nesse formato: contexto, problema, influncias, modelagem

do padro usando UML e exemplo anexo.
4. Frameworks de Software Orientados a Objetos
Do ponto de vista da estrutura de um framework, pode-se defin-lo como um conjunto de
classes que contm o projeto abstrato de solues para uma famlia de problemas relacionados,
propiciando o reso com granularidade maior do que simplesmente algumas classes. Esse projeto de
alto nvel representa o cdigo intelectual do software, que muito mais difcil de criar ou recriar do
que um cdigo-fonte. Por isso a grande importncia do reso de um framework encontra-se no
reso das interfaces internas de um sistema e da maneira como os componentes so divididos e no
na capacidade de reaproveitamento de cdigo.
Ainda do ponto de vista de um framework, temos que ele composto por uma coleo de
classes abstratas e concretas e a interface entre elas. Esse conjunto representa o projeto de um
subsistema. A base de um framework fornecido pelas classes abstratas, a partir das quais podem
ser implementadas classes concretas ou outras classes abstratas. Quando essa coleo de classes
abrange um sistema de software genrico para um domnio de aplicao, utiliza-se o termo
framework de aplicao.
Um framework pode ser definido como o esqueleto de uma aplicao ou um conjunto de
blocos de software pr-fabricados que programadores podem usar, estender e adaptar para solues
computacionais especificas. Os frameworks possibilitam que os desenvolvedores no precisem
comear do zero sempre que constroem uma aplicao. Assim, podem ser considerados um tcnica
de reso orientada a objetos que trabalha com tcnicas como os templates e os esquemas.
Quando o reuso feito da forma convencional, usando bibliotecas e componentes, o controle
do fluxo geral do programa e do uso das funes deve ser feito por parte do desenvolvedor. Porm
com o uso de um framework ocorre a chamada inverso de controle, em que o programa principal
reusado, ficando a cargo do desenvolvedor decidir qual componente ser usado, se novos
componentes sero criados novos cdigos a partir do framework. Isso significa que agora o

framework quem decide onde e como os componentes so usados, tomando conta do fluxo de
controle do programa e de sua estrutura geral.
Podemos classificar os frameworks de acordo com o escopo ou abrangncia de sua aplicao
em um dado domnio. Essa classificao feita em trs grupos: frameworks de infra-estrutura do
sistema, frameworks de integrao middleware e frameworks de aplicao empresarial.
Os frameworks de infra-estrutura so utilizados principalmente no desenvolvimento de
softwares como sistemas operacionais, sistemas de comunicao, interfaces com o usurio e
ferramentas de processamento de linguagem. Isso ocorre, pois esses frameworks simplificam muito
a infra-estrutura de criao de sistemas portteis e eficientes.
Os frameworks de integrao middleware so usados 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 de forma integrada
em um ambiente distribudo.
Frameworks de aplicao empresarial foram desenvolvidos para aplicaes mais amplas e
so muito utilizados em atividades de negcios das empresas, como sistemas de telecomunicaes,
aviao, manufatura e engenharia financeira. Esses frameworks so mais caros para comprar ou
desenvolver, mas a sua utilizao produz tantos benefcios que acabam compensando os custos.
Considerando a forma de reso existem trs tipos de framework: caixa branca, caixa preta e
caixa cinza. No framework caixa branca o reso ocorre por meio de herana, o usurio deve criar
subclasses das classes abstratas contidas no framework para produzir as aplicaes especificas. Para
isso deve ser entendido como o framework funciona. No framework caixa preta, o reso ocorre por
meio de composio, onde o usurio combina as diversas classes concretas existentes no framework
para obter a aplicao especifica. Esses dois frameworks apresentam srios problemas como a total
liberdade que o usurio tem para alterar as classes e implement-las do jeito que desejar (caixa
branca) e a falta dessa liberdade, o que pode limitar as aplicaes que podem ser desenvolvidas ou
dificultar o processo. Por isso, foram criados os frameworks caixa cinza, que combinam os pontos
positivos dos dois frameworks citados acima para minimizar seus problemas. O reso nesse tipo de
framework ocorre por meio de herana, por ligao dinmica e tambm pelas interfaces de
definio.
5. Comparao entre formas de reso
a. Padres x Frameworks
Os padres so mais abstratos que os frameworks, pois o framework possui cdigo
executvel, enquanto um padro representa o conhecimento e experincia sobre o software. Em
geral, os padres so compostos por duas ou trs classes, so menos especializados e podem ser
usados em diversos tipos de situao principalmente os padres de projeto. J os frameworks so
compostos por muitas classes, podendo englobar vrios padres. So mais especializados pois
geralmente so desenvolvidos para um domnio de aplicao especifico, alm de que um framework
pode ditar a arquitetura de uma aplicao.
b. Framework x Linguagens de Padres
Padres e Linguagens de Padres podem ser utilizados para documentar um Framework,
visando facilitar o seu reso. Pode ser criado um conjunto de padres que mostrem como o
framework deve ser utilizado, sem mostrar como ele funciona ou como ele foi desenvolvido. Porm
se utilizarmos uma linguagem de padres ao invs de padres separados podemos organizar a
seqncia que gerou o projeto do framework. Isso pode ser utilizado para que possam ser tomadas
decises durante a manuteno de um framework.
Um framework permite a implementao de uma aplicao segundo a linguagem de
padres, ou seja, ele contm a implementao de todos os padres compem a aplicao especfica.

Ao mesmo tempo a linguagem de padres fornece as regras para o uso dos elementos do framework
e para a sua extenso.
c. Linguagens de Padres x Frameworks x Aplicaes
Vimos que a linguagem de padres permite documentar e projetar o framework. O
framework permite implementar aplicaes e d suporte a linguagens de padres implementando os
padres nela contidos. A figura abaixo resume as idias descritas anteriormente, ilustrando o
relacionamento entre as linguagens de padres, frameworks e aplicaes.

Fig. 1: Relacionamento entre Linguagens de Padres e Frameworks

6. Padres de Anlise

So conjuntos de padres que podem ser usados em um ou mais domnios de negcio. Esses
padres recebem esse nome justamente por fazerem parte da modelagem da fase de anlise de um
projeto.
A linguagem de padres GRN (Gesto de Recurso de Negcio) composta por padres de
anlise que auxiliam o desenvolvedor na modelagem de uma aplicao no domnio de gesto de
recursos de negcio, como por exemplo, sistemas de automao de vendas, como o de um
supermercado.
A GRN dividida em trs grandes grupos de padres:
-

Grupo 1. Identificao do Recurso de Negcio: composto de trs padres que tm como

objetivo identificar um recurso, qualific-lo, quantific-lo e armazen-lo.

Grupo 2. Transaes de Negcio: composto de sete padres que so responsveis pelas

transaes efetuadas com o recurso identificado pelo grupo 1.

Grupo 3: Detalhes da Transao de Negcio: trata dos detalhes externos as transaes com
os recursos de negcio, como o pagamento da transao, a identificao de um executor das
transaes, entre outros.

Como forma de visualizar melhor o uso de padres de analise, esse tpico ser tratado de
forma mais detalhada na apresentao em sala de aula. Abaixo o grafo dos padres da GRN.

Veja tambm o material sobre GRN a disposio na pgina da disciplina para

maiores informaes.

7. Abordagem para construo de frameworks

Nos ltimos anos, muitas pesquisas vem sendo feitas sobre a construo de frameworks,
sendo propostas diversas abordagens, as mais conhecidas so a de Pree (1999), a de Schmid (1997,
1999), a de Froehlich et al. (1997), a de Roberts e Johnson (1998) e a de Bosh et al. (1999).
Em suma, as abordagens de Pree, Schmid e Roberts e Johnson partem de modelos de
aplicaes particulares, incluindo a flexibilidade desejada posteriormente. Na abordagem de
Froehlich, o conhecimento sobre os pontos variveis proveniente do desenvolvedor do framework,
que o adquiriu por meio da experincia pratica ou anlise de domnio. Na abordagem de Bosh o
modelo de anlise do domnio obtido no incio do processo, o que torna os pontos variveis do
framework mais previsveis.

8. Abordagens para instanciao de Frameworks

Os frameworks so uma tcnica poderosa para aumentar o reso de software. Visto que
podemos derivar inmeras aplicaes distintas por meio de sua instanciao. Mas muitas vezes o
processo de instanciao pode ser muito complexo, fazendo com que o usurio necessite de grandes
conhecimentos a respeito do projeto e implementao do framework. Todo framework composto
por uma parte fixa, ou frozen spot, que reflete o comportamento comum do domnio e partes
variveis que devem permanecer flexveis, ou hot spots, por representarem aspectos que mudam
de um aplicao para outra. Para alcanar essa flexibilidade os frameworks podem conter algumas
construes especiais que dificultam seu entendimento. Para auxiliar na implementao dessas
partes variveis so utilizados os padres de projeto. O framework resultante possui algumas classes
abstratas com um ou mais mtodos que devem ser sobrepostos nas subclasses concretas da
aplicao.
O principal problema ao instanciar um framework definir quais pontos variveis devem ser
adaptados e como adapt-los. Diversas abordagens foram propostas para resolver esse problema.
Basicamente as abordagens dizem que o framework deve possuir uma documentao com as
informaes necessrias para instanciar aplicaes especficas. No caso de um framework caixa
branca, essa documentao , geralmente, constituda pela hierarquia das classes do framework, das
classes abstratas que devem ser especializadas, dos mtodos a serem sobrepostos e de exemplos de
aplicaes derivadas a partir do framework.
Existem basicamente quatro formas de se instanciar um framework: pela documentao do
framework, por explorao de exemplos, por meio de padres e por meio de cookbooks. A primeira
abordagem consiste do estudo da documentao do framework, que pode ser feito atravs de
treinamento convencional ou por meio de tutoriais especialmente elaborados para essa situao. A
explorao de exemplos consiste na anlise de aplicaes existentes, construdas a partir do
framework para identificar as adaptaes necessrias para obteno do sistema especfico. Padres
de software podem ser usados para documentar o framework a ajudar a instanci-lo. Trs trabalhos
foram publicados, mas nenhum evolui rumo definio de um processo a ser utilizado. Os
cookbooks podem ser preparados como um conjunto de atividades que devem ser realizadas para
adaptar o framework em uma aplicao especfica, como uma receita culinrio.
Tanto a abordagem pela documentao do framework e por explorao de exemplos
necessitam que o usurio possua um bom nvel de conhecimento sobre o framework para que seja
possvel instanci-lo. Com o intuito de resolver esse problema so utilizados os padres de projeto
e cookbooks que tentam diminuir o nvel de conhecimento que o usurio deve ter sobre o
framework para que possam instanci-lo, ou seja, os usurios somente precisam se preocupar com
os pontos variveis que so necessrios para a sua aplicao.
9. Bibliografia
i. R. T. V. BRAGA. Um Processo para Construo e Instanciao de Frameworks
baseados em uma Linguagem de Padres para um domnio especifico. ICMC-USP So
Carlos SP. 2002
ii. R. T. V. BRAGA, P.C. MASIERO, F. S. R. GERMANO. GRN: Uma Linguagem de
Padres para Gesto de Recurso de Negcio. ICMC-USP So Carlos SP
iii. http://pt.wikipedia.org/wiki/Padres_de_projeto_de_software
Consultado em 02/09/2008.
iv. http://pt.wikipedia.org/wiki/Christopher_Alexander
Consultado em 02/09/2008.
v. http://en.wikipedia.org/wiki/Kent_Beck
Consultado em 02/09/2008
vi. http://en.wikipedia.org/wiki/Ward_Cunningham
Consultado em 02/09/2008