Um Arcabouço de Apoio Ao Aprendizado de Padrões de Projeto No Contexto de Disciplinas de Programação Orientada A Objetos

Universidade Federal do Cear
Centro de Tecnologia
Departamento de Engenharia de Teleinformtica
Curso de Graduao de Engenharia de Teleinformtica
UM ARCABOUO DE APOIO AO APRENDIZADO DE

PADRES DE PROJETO NO CONTEXTO DE DISCIPLINAS DE
PROGRAMAO ORIENTADA A OBJETOS
Igor Arcanjo Chaves
Fortaleza Cear
Junho/2012
UM ARCABOUO DE APOIO AO APRENDIZADO DE

PADRES DE PROJETO NO CONTEXTO DE DISCIPLINAS DE
PROGRAMAO ORIENTADA A OBJETOS
Projeto
Final
de
Curso
submetido
Coordenao do programa de Graduao em

Engenharia
de
Teleinformtica
da
Universidade Federal do Cear como parte

dos requisitos para a obteno do grau de
Engenheiro de Teleinformtica.
Autor: Igor Arcanjo Chaves

Orientador: Prof. Dr. Jos Marques Soares
Fortaleza Cear
Junho/2012
Ttulo do Trabalho: UM ARCABOUO DE APOIO AO APRENDIZADO DE PADRES

DE PROJETO NO CONTEXTO DE DISCIPLINAS DE PROGRAMAO ORIENTADA
A OBJETOS
Autor: Igor Arcanjo Chaves
Defesa em: 29/06/2012
Nota Obtida: 9,7
Banca Examinadora
_________________________________________
Prof. Dr. Jos Marques Soares
Orientador
_________________________________________
Prof. Dr. Danielo Gonalves Gomes
Universidade Federal do Cear
_________________________________________
Prof. Dr. Antonio de Barros Serra
Instituto Federal de Educao, Cincia e Tecnologia do Cear
Fortaleza, 29 de Junho de 2012
Dedico esta monografia aos meus pais, Tarcisio e Helena, pelo apoio
incondicional, aos meus irmos, Breno e Tassia, que apesar da
distncia sempre estiveram ao meu lado e minha namorada,
Fernanda, que nos momentos mais difceis me deu foras e inspirao
para continuar e jamais desistir dos meus objetivos.
Que os vossos esforos desafiem as impossibilidades, lembrai-vos de

que as grandes coisas do homem foram conquistadas do que parecia
impossvel.
Charles Chaplin
AGRADECIMENTOS
Considerando este trabalho como o resultado de uma longa caminhada, o
agradecimento s pessoas que contriburam para a minha formao no uma tarefa fcil.
Para no correr o risco de cometer injustias agradeo de antemo todas as pessoas que
passaram pela minha vida e que direta ou indiretamente me ajudaram nessa longa caminhada
em busca do sucesso.
Gostaria de agradacer tambm em particular algumas pessoas que tiveram participao
fundamental para a construo desse trabalho:
Ao meu professor e orientador, Prof. Dr. Jos Marques, pelos conhecimentos
transmitidos em sala de aula e tambm fora dela e pela fora e dedicao na orientao deste
trabalho.
Ao GREat (Grupo de Redes de Computadores, Engenharia de Software e Sistemas),
em especial Prof. Dra. Rossana Andrade e ao Reinaldo Braga, pela oportunidade mpar que
tive ao ingressar no grupo e pelo total apoio e confiana depositada em mim durante todo o
tempo em que estive no grupo.
Aos amigos de faculdade pelos momentos de descontrao dentro e fora de sala de
aula, pelas noites em claro estudando para provas e trabalhos da faculdade e pela forte
amizade que construmos durante essa longa caminhada.
A todos os professores do Departamento de Engenharia de Teleinformtica pelo
aprendizado passado durante minha graduao.
Universidade Federal do Cear pela formao de nvel superior de excelente
qualidade.
Resumo
Os processos modernos de engenharia de software, em especial as metodologias geis,
tem como principal objetivo no s a produtividade na construo de softwares, mas tambm
a sua produo com requisitos de alta qualidade, o que inclui caractersticas de reusabilidade e
expansibilidade. Umas das tcnicas para se alcanar qualidade e produtividade o uso de
padres de projeto (ou design patterns). Em muitos programas acadmicos, os padres de
projeto s so estudados em disciplinas de Engenharia de Software, mais precisamente,
durante as fases associadas codificao. Defende-se a incluso de maneira objetiva do
estudo sobre padres de projeto j em disciplinas de programao orientada a objetos, visto
que eles podem ser vistos como tcnicas avanadas e consolidadas de construo de software
e representam um elemento de compreenso efetiva dos mecanismos de herana e
polimorfismo. Nesse sentido, este trabalho prope um arcabouo simples para dar suporte ao
aprendizado de padres de projeto em disciplinas de programao orientada a objetos. O
Arcabouo apresentado atravs do desenvolvimento inicial de um conjunto de padres de
projeto que so julgados importantes, podendo ser generalizado para futuras expanses. Para
cada um desses padres, so descritas as suas principais caractersticas, a situao que
comumente requer o seu uso, alm de sua implementao em Java um caso de exemplo.
Finalmente, proposto um exerccio para sedimentar o seu aprendizado, explorando-se, em
seguida, o reuso das classes e interfaces que fazem parte da estrutura do padro a fim de
mostrar a facilidade de evoluo da soluo e ressaltar as caractersticas de baixo acoplamento
de suas partes.
Palavras-Chaves: Padro de Projeto, Programao Orientada a Objetos, Engenharia
de Software, Qualidade de Software.
Abstract
Modern processes of software engineering, particularly agile methods, has its the main
goal not only the productivity in building software, but also its production with high quality
requirements, which includes characteristics of reusability and expandability. One of the
techniques to achieve quality and productivity is the use of design patterns. In many academic
programs, design patterns are only studied in the disciplines of Software Engineering, more
specifically during the phases associated with encoding. The text supports the inclusion of an
objective study on design patterns already in programming disciplines, especially in objectoriented programming, since they can be viewed as advanced and consolidated programming
techniques, besides it represents an element of effective understanding of the mechanisms of
inheritance and polymorphism. Thus, this study aims to build a framework to support the
learning of design patterns in disciplines of object-oriented programming. The framework is
presented by developing a set of design patterns that are deemed important and can be
generalized for future expansion. For each of these patterns, it's describes its main
characteristics, the situation that usually requires its use, and its implementation in Java an
example case. Finally, we propose an exercise to consolidate their learning, exploring,
whenever possible, the reuse of classes and implementing interfaces involved in the expansion
of pattern in order to emphasize the fundamentals of low coupling provided by it.
Keywords: Design Patterns, Object Oriented Programming, Software Engineering,
Software Quality.
SUMRIO
1.
2.
Introduo .................................................................................................................................... 12
1.1.
Motivao............................................................................................................................. 12
1.2.
Objetivos .............................................................................................................................. 13
1.3.
Organizao do documento ................................................................................................. 14
Padres de Projeto ....................................................................................................................... 15

2.1 Introduo .................................................................................................................................. 15
2.2 Elementos Indispensveis de Programao Orientada a Objetos .............................................. 16
Herana ........................................................................................................................................ 17
Polimorfismo ................................................................................................................................ 18
2.3 Arcabouo para o Estudo de Padres de Projeto ....................................................................... 20
2.4 Strategy ...................................................................................................................................... 23
Apresentao ............................................................................................................................... 23
Descrio com Exemplo ............................................................................................................... 23
Codificao do Exemplo ............................................................................................................... 26
Proposio .................................................................................................................................... 29
Extenso ....................................................................................................................................... 30
2.5 Abstract Factory ......................................................................................................................... 30
Apresentao ............................................................................................................................... 30
Proposio .................................................................................................................................... 37
Extenso ....................................................................................................................................... 37
2.6 Composite .................................................................................................................................. 37
Apresentao ............................................................................................................................... 37
Proposio .................................................................................................................................... 41
Extenso ....................................................................................................................................... 41
2.7 Padres de Projeto em Construo ............................................................................................ 42
3.
A Gnese do Arcabouo Proposto ................................................................................................ 43
4.
Consideraes finais ..................................................................................................................... 48
5.
Referncias Bibliogrficas............................................................................................................. 50
6.
Apndice ...................................................................................................................................... 52
6.1. Apndice A - Facade .................................................................................................................. 52
Apresentao ............................................................................................................................... 52
Proposio .................................................................................................................................... 55
Extenso ....................................................................................................................................... 56
6.2. Apndice B - Singleton............................................................................................................... 56
Apresentao ............................................................................................................................... 56
Proposio .................................................................................................................................... 59
Extenso ....................................................................................................................................... 59
6.2. Apndice C - Iterator ................................................................................................................. 59
Apresentao ............................................................................................................................... 59
Proposio .................................................................................................................................... 64
Extenso ....................................................................................................................................... 64
LISTA DE FIGURAS
Figura 1 Exemplo de Classe e Objetos (UML). .................................................................... 16
Figura 2 Exemplo de Herana. .............................................................................................. 18
Figura 3 Exemplo de Polimorfismo....................................................................................... 20
Figura 4 Arcabouo para o estudo de padres. ...................................................................... 22
Figura 5 Diagrama de Classes Inicial (UML) Strategy ......................................................... 23
Figura 6 Classes RubberDuck e WoodDuck ......................................................................... 24
Figura 7 Classes RubberDuck ............................................................................................... 25
Figura 8 Diagrama de Classes Final (UML) Strategy ........................................................... 26
Figura 9 Classes FlyBehavior.java, FlyWithWings.java e FlyNoWay.java ......................... 26
Figura 10 Classes QuackBehavior.java, Quack.java, MuteQuack.java e Squeak.java ......... 27
Figura 11 Classe Duck.java ................................................................................................... 28
Figura 12 Classes MallardDuck.java, ReadheadDuck.java, WoodDuck.java e
RubberDuck.java ...................................................................................................................... 29
Figura 13 Classe Application.java ......................................................................................... 29
Figura 14 (a) Classes Button e Menu (b) Classe Application.java ........................................ 31
Figura 15 (a) Classes WinButton e LinuxButton (b) Classe Application.java ...................... 31
Figura 16 Diagrama de Classes (UML) Abstract Factory ..................................................... 33
Figura 17 Classe GUIFactory.java I ...................................................................................... 34
Figura 18 Classes WinFactory.java e LinuxFactory.java ...................................................... 34
Figura 19 Classe Button.java ................................................................................................. 34
Figura 20 Classes WinButton.java e LinuxButton.java ........................................................ 35
Figura 21 Classes Application.java ....................................................................................... 36
Figura 22 Classe GUIFactory.java II ..................................................................................... 36
Figura 23 Diagrama de Classes (UML) Composite .............................................................. 39
Figura 24 Classe ComponenteGrafico.java ........................................................................... 39
Figura 25 Classes Linha.java e Texto.java ............................................................................ 40
Figura 26 Classe Imagem.java............................................................................................... 41
Figura 27 Enunciado da Atividade sobre Design Patterns .................................................... 44
Figura 28 Diagrama de Classes (UML) Facade .................................................................... 53
Figura 29 Classes Motor.java, Porta.java, Farol.java e Radio.java ....................................... 54
Figura 30 Classe CarroFacade.java ....................................................................................... 55
Figura 31 Exerccio Proposto Facade .................................................................................... 56
Figura 32 Diagrama de Classes (UML) Singleton ................................................................ 57
Figura 33 Classe Singleton.java ............................................................................................ 58
Figura 34 Classe Main.java ................................................................................................... 59
Figura 35 Diagrama de Classes (UML) Iterator .................................................................... 61
Figura 36 Classes Estrutura.java e Iterador.java ................................................................... 61
Figura 37 Classes Fila.java e Lista.java ................................................................................ 62
Figura 38 Classes IteradorLista.java e IteradorFila.java ....................................................... 63
Figura 39 Classe Aplicacao.java ........................................................................................... 64
LISTA DE TABELAS
Tabela 1 Avaliao mdia dos alunos da turma de graduao para a atividade sobre padres
de projeto na disciplina de Engenharia de Software (2012-1).................................................. 46
12
1. Introduo
1.1. Motivao
A definio de Engenharia de Software no nica. Apesar das distintas definies de
diversos autores, elas apresentam caractersticas de convergncia. O IEEE (Institute of
Eletrical and Eletronics Engineers) [1] define engenharia de software como o estudo e
aplicao
de
uma
abordagem
sistemtica,
disciplinada
quantificvel
para
desenvolvimento, operao e manuteno do software. De acordo com Ian Summerville [2] a

engenharia de software se relaciona com todos os apectos da produo do software, desde a
especificao do sistema at a manuteno que ser feita aps o software entrar em produo.
Os processos modernos de engenharia de software, em especial as metodologias geis,
tem como principal objetivo no s a produo de softwares com alta produtividade, mas
tambm com alta qualidade e que sejam reusveis e expansveis.
Qualidade de software outro termo utilizado na engenharia de software na qual a
definio no uma unanimidade. A NBR ISO 9000:2005 [3] define qualidade como o "grau
no qual um conjunto de caractersticas inerentes satisfaz a requisitos". Segundo a mesma
norma requisito a "necessidade ou expectativa que expressa, geralmente, de forma
implcita ou obrigatria". Dessa forma, pode-se inferir que a qualidade pode ser medida
atravs do grau de satisfao das pessoas envolvidas na realizao de determinado servio ou
produto, tornando a qualidade algo bem subjetivo, j que depende da interpretao de cada ser
envolvido e no somente do que est escrito ou expresso.
De acordo com Pressman [4] a qualidade de software precisa ser implementada e no
ficar somente na idia. Ele diz que preciso definir explicitamente o termo qualidade quando
o mesmo for utilizado, preciso tambm criar um conjunto de atividades que iro ajudar a
garantir que a qualidade definida seja alcanada e, tambm, utilizar mtricas para melhoraria
de processo de software aumentando, consequentemente, a qualidade do produto final.
Portanto, a busca da qualidade de software no algo que deve se preocupar somente aps o
cdigo ser gerado, ela precisa ser uma atividade que seja aplicada ao longo do processo de
desenvolvimento de software.
Bruegge [5] sintetiza o conceito Engenharia de Software englobando diversas
caractersticas, definindo-o como uma coleo de tcnicas, metodologias e ferramentas que
do suporte produo de sistemas de alta qualidade, com um oramento determinado e
13
dentro do cronograma estabelecido, considerando que mudanas nos requisitos e no ambiente

ocorrem frequentemente.
Umas das tcnicas para se alcanar qualidade e produtividade, imprimindo, ao mesmo
tempo, caractersticas que ofeream maior suporte a mudanas, o uso de padres de projeto,
mais conhecido pelo termo em ingls design patterns. A idia de projetar solues a partir de
problemas j conhecidos, solucionados e documentados no nova e no teve origem na
engenharia de software, o conceito de padres, dentro dessa tica, foi apresentada por um
arquiteto chamado Christopher Alexander [6] em 1977, no contexto de arquitetura. Segundo
ele cada padro descreve um problema que ocorre repetidas vezes em nosso ambiente, para
ento descrever a parte central da soluo para esse problema que poder ser utilizada
inmeras vezes, sem nunca ter que faz-lo duas vezes da mesma maneira.
Essa definio de padro chamou a ateno da comunidade de engenharia de software
e em 1995 Erich Gamma, Richard Helm, Ralph Jonhson e Jonh Vlissides lanaram o livro
Design Patterns elements of reusable object-oriented software [7]. Esse livro descreve 23
padres de projetos sendo classificados, de acordo com os autores, em 3 categorias: padres
de projeto de criao, estruturais e comportamentais. Segundo os autores a utilizao de
padres de projeto facilita o reso de projetos e arquiteturas de software que tiveram xito em
experincias anteriores. Os padres tambm ajudam os desenvolvedores a modelar
alternativas que no comprometam o reso, alm de melhorar a documentao e,
consequentemente, a manuteno do software. De forma objetiva o padro de projeto ajuda o
desenvolvedor a modelar o seu problema rpida e corretamente.
Os padres de projeto representam solues que foram generalizadas ao longo do
tempo para problemas de caractersticas recorrentes. Dessa maneira, justifica-se incluir, de
maneira objetiva, o estudo sobre padres de projeto j em disciplinas de programao, em
especial, em programao orientada a objetos, visto que eles podem ser vistos como tcnicas
avanadas e consolidadas de programao.
1.2. Objetivos
Sabendo da importncia da utilizao de padres de projeto para a qualidade e
produtividade do desenvolvimento de software, este trabalho tem por objetivo propor um
arcabouo constitudo por recursos tcnicos de apoio ao ensino e aprendizagem para
introduo aos padres de projeto em disciplinas de programao orientada a objetos.
14
Visa-se associar, de maneira efetiva, a teoria e a prtica sobre o estudo de padres de

maneira desvinculada de disciplinas de Engenharia de Software. O arcabouo inclui, para
cada um dos padres, os seguintes pontos:
1) Introduo terica ao padro, identificando seus objetivos e benefcios;
2) Modelagem, atravs de diagrama de classes (UML) do padro de projetos;
3) Descrio das classes envolvidas no padro;
4) Implementao de um cenrio simples com o uso do padro;
5) Sugesto de exerccio prtico para um cenrio diferente do apresentado, usando
o mesmo padro.
Atravs desse arcabouo, pretende-se que o aprendizado e o ensino de orientao a
objetos, com premissas de baixo acoplamento, alta coeso e reusabilidade, se d de forma
mais eficaz. Para isso, ser sempre feita a contextualizao por intermdio de exemplos
prticos, seguido da aplicao do padro para aquele tipo de problema.
1.3. Organizao do documento

Este trabalho est disposto da seguinte maneira: no primeiro captulo, foram
apresentados uma breve introduo sobre engenharia de software e padres de projeto seguido
da motivao deste trabalho, finalizando com a descrio de seus objetivos; no segundo
captulo o conceito de padro de projeto descrito, em seguida discute-se o conceito de
programao orientada a objetos, logo aps proposto um arcabouo para o estudo de
padres de projeto, para ento apresentar os padres nos moldes do arcabouo proposto; no
captulo terceiro so descritas algumas dificuldades no aprendizado de padres de projeto em
sala de aula; no quarto captulo fazemos as consideraes finais; na seo posterior temos as
referncias bibliogrficas; e, por fim, temos no apndice, captulo seis, padres de projeto que
ainda encontram-se em construo nos moldes do arcabouo em questo.
15
2. Padres de Projeto
2.1 Introduo
Gamma et al [7] definem que padres de projeto so descries de objetos e classes
comunicantes que precisam ser personalizadas para resolver um problema geral de projeto
num contexto particular. Eles surgiram como o resultado de experincias e solues para
problemas recorrentes no desenvolvimento de software. Eles podem ser definidos, tambm,
como arquiteturas testadas para construir softwares orientados a objetos flexveis e
sustentveis [8].
O grupo conhecido como Gang of Four, formado por Erich Gamma, Richard Helm,
Ralph Johnson e John Vlissides, no livro lanado em 1995, descreve 23 padres de projeto
agrupados em 3 categorias: criacionais, estruturais e comportamentais [7]. Ele ainda subdivide
cada categoria de padro em padres de classe ou de objeto.
Padres de projeto criacionais esto relacionados com o processo de criao e
instanciao de objetos. Eles ajudam a projetar um sistema independente de como os objetos
so criados, compostos e representados. O padro criacional de classe utiliza herana para
variar a forma como a classe instanciada, enquanto o padro criacional de objeto delega sua
instanciao para outro objeto.
Padres do tipo estrutural fazem referncia forma como classes e objetos so
compostos para formar estruturas maiores. No padro estrutural de classe, utiliza-se o
conceito de herana para compor implementaes ou interfaces. J nos padres estruturais de
objeto so descritas formas de compor objetos para adquirir novas funcionalidades em tempo
de execuo, o que no possvel atravs da composio esttica de classes.
Padres comportamentais descrevem a interao e atribuio de responsabilidades
entre objetos e classes. Eles no descrevem somente padres de objetos ou classes mas
tambm padres de comunicao entre eles. Esse tipo de padro caracteriza os fluxos
complexos de controle que difcil de acompanhar em tempo de execuo. Os padres
comportamentais
de
classe
utilizam
herana
para
distribuir
comportamentos,
responsabilidades entre as classes, j os padres de objeto utilizam a composio para fazer

essa distribuio.
Neste trabalho no temos como objetivo abordar todos os padres de projeto, mas um
conjunto que seja suficientemente capaz de cobrir e exemplificar a estrutura do arcabouo
16
proposto. Assim, so expostos e discutidos os padres criacionais Singleton e Abstract

Factory, os padres estruturais Facade e Composite e os padres comportamentais Iterator e
Strategy.
2.2 Elementos Indispensveis de Programao Orientada a Objetos

Para estudar padres de projeto, necessrio um conhecimento consistente do
paradigma de programao orientada a objetos. Esse paradigma baseia-se na anlise, projeto e
desenvolvimento de sistemas a partir da utilizao de objetos, que possuem atributos e
comportamentos, e se comunicam entre si, atravs de mensagens, colaborando para a
formao de sistemas. Esse paradigma baseado nos seguintes conceitos: objeto, classe,
encapsulamento, herana e polimorfismo.
Os conceitos de classe e objeto esto intimamente ligados. O objeto pode ser definido
como uma entidade fsica, palpvel ou mesmo conceitual, abstrata. Cada objeto tem suas
caractersticas, as quais chamamos de atributos, e comportamentos, que tambm podem ser
chamados de mtodos. Existem objetos que possuem propriedades e comportamentos
similares, dando origem ao conceito de classe (de objetos). As classes definem um conjunto
de atributos e de comportamentos que so comuns a um conjunto de objetos. Enquanto um
objeto uma entidade que executa uma funo no sistema, uma classe define uma estrutura
comum aos tipos de objetos.
Na Figura 1 apresentado um exemplo onde a classe Pessoa possui trs atributos ,
nome, cpf e endereco, e trs mtodos, comer(), estudar(), dormir(). Tem-se tambm a
representao de dois objetos da classe Pessoa, identificados como joao e maria. A
conveno utilizada inerente Unified Modeling Language (UML).
Figura 1 Exemplo de Classe e Objetos (UML).
O encapsulamento um conceito que, como o prprio nome insinua, empacota, ou

seja, protege algumas propriedades do objeto de modificaes que possam deixar o objeto em
17
estado inconsistente. Utilizando esse conceito obtemos vrios benefcios, entre eles proteger
dados e operaes, deixar o cdigo mais legvel e melhor estruturado, tornando a manuteno
menos custosa. Para dar suporte ao encapsulamento bem como definio da interface
pblica de um objeto (mtodos e atributos expostos para outros objetos), a mairoria das
linguagens OO, como o Java, fornece quatro tipos de modificadores de acesso ou visibilidade:
public, private, protected e default.
Os atributos e mtodos de um objeto ou classe so comumente chamados de membros
desse objeto ou classe. Desse modo, quando um membro de uma classe definido como
public, significa que todos os objetos tm acesso a esse membro. Quando, por outro lado, esse
membro definido como private, s quem tem acesso a esse membro a prpria classe. Os
modificadores protected e default so quase idnticos. Enquanto o membro default pode ser
acessado apenas pelas classes que pertencerem ao mesmo pacote, o membro protected pode
ser acessado tambm pelas suas subclasses, mesmo que suas subclasses no perteam ao
mesmo pacote [9].
Herana
O conceito de herana definido por [8] como uma forma de reutilizar o cdigo
quando uma nova classe criada, absorvendo membros de uma classe j existente,
economizando tempo durante o desenvolvimento do software.
Quando uma classe herda de uma outra classe existente, esta classe chamada de
superclasse e aquela de subclasse. A subclasse herda as propriedades da superclasse, ou seja,
ela tem acesso aos atributos e mtodos, dependendo dos modificadores de acesso, da
superclasse. Existem dois tipos de herana, simples e mltipla, na primeira uma classe s
pode herdar de somente uma superclasse diretamente, como o caso do Java, j na herana
mltipla uma classe pode herdar mais de uma superclasse diretamente, um exemplo a
linguagem C++.
Na Figura 2, mostrado um exemplo onde as classes Estudante e Engenheiro so
subclasses da classe Pessoa. Desse modo, as subclasses herdam todos os atributos, pois eles
possuem modificadores de acesso protected, e todos os mtodos da superclasse, pois possuem
modificadores de acesso public.
18
Figura 2 Exemplo de Herana.
Polimorfismo
Polimorfismo, que vem do grego "muitas formas", permite que se utilizem objetos
pertencentes a classes relacionadas entre si pela relao de herana. Atravs de uma interface
nica, o objetivo o de tratar uma variedade de classes relacionadas de forma uniforme,
facilitando, por um lado, a especializao do comportamento e, por outro lado, simplificando
a adio de novas classes ao software sem requerer modificao nas classes pr-existentes, o
que imprime ao software caractersticas de baixo acoplamento.
O polimorfismo permite que o processamento de objetos que possuem a mesma
superclasse em uma hierarquia sejam tratados como se todas fossem objetos da superclasse
[8]. Utilizando o polimorfismo, pode-se projetar e implementar sistemas que so facilmente
extensveis, ou seja, a adio de novas classes pode ser feita com pouca ou nenhuma
modificao, contanto que essas novas classes faam parte da hierarquia de herana do
sistema. Nota-se que polimorfismo est intimamente ligado utilizao de herana.
Entretanto, para que esse requisito seja cumprido de maneira correta, necessrio que a
hierarquia de classes atenda ao princpio de substituio de Liskov [10], que define que, se um
objeto do tipo S pode ser substitudo em todos os locais onde um objeto do tipo T, esperado,
ento S um subtipo de T. Se, em algum caso, essa substituio no resultar em um
comportamento correto e esperado, o reuso promovido pela herana foi utilizado de maneira
incorreta, modificando a semntica da interface comum encontrada na hierarquia de classes, e
o princpio de Liskov foi quebrado.
19
Na Figura 3 mostra-se um exemplo em Java utilizando conceito de polimorfismo. A

classe abstrata Animal que contm o mtodo tambm abstrato display() a superclasse das
classes concretas Dog e Cat que implementam o mtodo herdado. A aplicao representada
pela classe Application, onde, na linha 8, tem-se a instanciao de uma lista de objetos,
animalList, do tipo Animal. Ainda na aplicao, tem-se a instanciao de dois objetos, dog e
cat, do tipo Dog e Cat, respectivamente. Nas linhas 12 e 13 esses dois objetos so adicionados
na lista animalList. criado, tambm na classe Application, o mtodo showAnimals(), que
recebe como parmetro um ArrayList<Animal>. Nesse mtodo varrem-se todos os objetos e
chama-se, para cada um deles o mtodo, display(). Note que, na linha 22, apesar de no saber
qual o tipo de animal, chamado o mtodo display() e ser mostrado na tela o tipo
correspondente ao animal que ele representa.
possvel observar tambm que ao adicionar outra classe que herde de Animal, por
exemplo a classe Coelho, eu no precisarei modificar o cdigo no mtodo showAnimals(). A
nica alterao ser para colocar o coelho na lista de animais.
20
Figura 3 Exemplo de Polimorfismo.
A aplicao dos conceitos de herana e polimorfismo, desenvolvidos atravs do

princpio de substituio de Liskov, so elementos de relevncia indispensveis
compreenso e utilizao dos padres de projeto.
2.3 Arcabouo para o Estudo de Padres de Projeto

Como j mencionado anteriormente, a utilizao de padres de projeto de extrema
importncia no desenvolvimento de software de qualidade e com produtividade. Este trabalho
descreve os padres de projeto com foco na introduo do seu aprendizado em disciplinas de
programao orientada a objetos. Utiliza-se um modelo que associa, de maneira efetiva, a
21
teoria e a prtica na utilizao dos padres de projeto. O modelo proposto formado por trs
blocos principais: apresentao, desenvolvimento conceitual e desenvolvimento prtico,
descritos em seguida:
Apresentao Neste bloco descrito formalmente o padro de projeto e o

seu propsito, indicando-se como e onde ele pode ser utilizado, mas sem
maiores detalhamentos tcnicos sobre implementao ou modelagem.
Desenvolvimento conceitual Neste bloco so explorados os aspectos

conceituais e a motivao para usar o padro estudado. Esse bloco subdivide-se
em duas partes.
o Descrio com exemplo apresenta-se um problema tcnico com o
exemplo e usa-se uma abordagem de tentativas intermedirias de
soluo do mesmo, at chegar estrutura efetivamente proposta pelo
padro de projetos, mostrando, assim, os benefcios de sua utilizao.
As estruturas so desenvolvidas com apoio em diagramas de classes
simplificados. Esses diagramas tm por objetivo enfatizar a soluo do
padro de projeto e no mostrar, necessariamente, todas as
propriedades das classes envolvidas. No obrigatria a utilizao de
diagramas em UML, podendo-se utilizar outras formas de apresentao.
Entretanto, devido representatividade e adequao dessa linguagem
de modelagem Orientao a Objetos, seu uso fortemente
recomendado. Eventualmente, os conhecimentos sobre diagramas de
classe podem ser desenvolvidos de maneira concomitante, caso isso no
tenha ocorrido ao longo do aprendizado do curso de orientao a
objetos.
o Codificao do exemplo Nesta parte, realizada e discutida a
codificao que materializa o exemplo desenvolvido na parte
precedente do bloco desenvolvimento conceitual. mostrada e
discutida a implementao que realiza as relaes apresentadas no
diagrama de classes apresentado. O cdigo contendo os exemplos
fornecido aos alunos, que podem execut-lo em seu ambiente de
programao e servir de apoio para o desenvolvimento prtico, que
consiste no ltimo bloco do arcabouo.
22
Desenvolvimento Prtico - Este bloco visa o desenvolvimento prtico do

aluno atravs da soluo para um ou mais problemas propostos. O bloco
dividido em duas partes:
o Proposio feito o enunciado de um ou mais problemas que devem
ser
diferentes
do
exemplo
que
foi
apresentado
no
bloco
desenvolvimento conceitual. Evita-se, assim, a falsa sensao de

aprendizado, permitindo a consolidao do conhecimento acerca do
padro em estudo.
o Extenso Etapa que possibilita validar caractersticas de baixo
acoplamento e de reusabilidade da aplicao, propondo-se uma
modificao no enunciado proposto da parte anterior que deve ser
desenvolvido sem comprometer a estrutura proposta pelo padro de
projetos em questo.
Apresentao
Desenvolvimento conceitual
Descrio com Exemplo
Codificao do Exemplo
Desenvolvimento prtico
Proposio
Extenso
Figura 4 Arcabouo para o estudo de padres.
Na Figura 4, a estruturao seqencial das sees de utilizao do arcabouo

apresentada pelas setas contnuas. Entretanto, usando-se as setas pontilhadas, procura-se
representar a no-linearidade do aprendizado, uma vez que, de qualquer ponto, pode-se
recorrer aos elementos constituintes das sees anteriores para auxiliar no desenvolvimento.
Note que, na estrutura apresentada na Figura 4, os blocos mais abaixo (em cinza) so
aqueles em que se desenvolve a prtica laboratorial pelo aluno. Esses blocos representam dois
momentos particulares da aprendizagem de padres de projeto. Nas prximas sees so
apresentados alguns padres de projeto estruturados de acordo com o arcabouo proposto.
Embora os exemplos e os exerccios estejam sendo propostos em Java, o arcabouo proposto
23
no faz nenhuma restrio em relao linguagem de programao ou tecnologia a serem

utilizados.
2.4 Strategy
Apresentao
O Padro Strategy define uma famlia de algoritmos que so encapsulados em objetos
independentes dos objetos para os quais os algoritmos foram efetivamente concebidos.
Encapsular comportamentos associados a objetos pertencentes a uma hierarquia de
classes permite que os algoritmos variem independentemente dos clientes que o utilizam [7].
Alm disso, a estrutura proposta pelo padro Strategy possibilita efetuar a modificao do
comportamento de um objeto em tempo de execuo.
Descrio com Exemplo

Para apresentar este padro, utilizado aqui o exemplo encontrado em [11], em que o
contexto um jogo de computadores cujas personagens so patos de diferentes tipos. Os patos
do jogo possuem um conjunto de atributos e comportamentos semelhantes, mas podem
apresentar algumas especificidades entre si. Exploram-se os comportamentos de nadar e
produzir sons. Inicialmente, utilizando tcnicas de orientao a objetos, prope-se a definio
da superclasse abstrata Duck e, a partir dela, os demais tipos de patos so criados. O diagrama
de classes mostrado na Figura 5(a) exemplifica a especializao de Duck para apenas duas
subclasses.
Figura 5 Diagrama de Classes Inicial (UML) Strategy
24
Supondo-se a necessidade de adicionar um novo comportamento para patos existentes

ou para novos patos que sejam agregados ao jogo, percebe-se que alguns deles podem voar.
Utilizando-de tcnicas de orientao a objetos, prope-se a criao do mtodo fly() na
superclasse Duck, como mostra a Figura 5(b).
Figura 6 Classes RubberDuck e WoodDuck
Entretanto, percebe-se que nem todos os patos podem voar. Por exemplo, patos de
borracha no voam. Uma alternativa inicial sobrescrever o mtodo fly() na classe dos patos
de borracha, RubberDuck, para modificar o seu comportamento em relao ativao deste
mtodo, como mostrado na Figura 6. Analisando-se a extensibilidade da soluo, ao adicionar
outro tipo de pato, por exemplo, um pato de madeira, representado pela classe WoodDuck,
teremos que modificar novamente os mtodos quack() e fly(), como mostrado na Figura 6.
Pode-se observar que essa soluo possui vrias desvantagens: (i) cdigo duplicado entre
diferentes classes; (ii) alteraes no comportamento em tempo de execuo se tornam difceis;
(iii) difcil saber de antemo o comportamento de todos os patos.
Como generalizar o comportamento inserindo os mtodos fly() e quack() na
superclasse Duck traz os problemas citados, explora-se outra alternativa com a utilizao de
interfaces distintas para representar os dois comportamentos: Flyable e Quackable. Desse
modo, sugere-se que os patos que voam implementem a interface Flyable e,
consequentemente, o mtodo fly(). Da mesma maneira, os patos que grasnam devem
implementar a interface Quackable e, consequentemente, o mtodo quack(), como mostrado
no diagrama de classes da Figura 7. Embora, da perspectiva de um objeto, essa soluo trate o
encapsulamento de uma maneira mais limpa, ela compromete a reutilizao do cdigo que
define cada um desses comportamentos. Imaginando um cenrio em que diversos tipos de
pato apresentem o mesmo comportamento de voo, por exemplo, o mesmo cdigo precisaria
ser replicado para todos os patos que o implementam. Alm isso, uma alterao, mesmo que
pequena, no comportamento de vo exigiria uma atualizao em todas as classes que o
implementam, tornando a manuteno uma tarefa extremamente custosa e podendo gerar
inconsistncia no sistema.
25
Figura 7 Classes RubberDuck
Para solucionar os problemas citados, prope-se o padro de projeto Strategy. A

soluo, mostrada na Figura 8, o encapsulamento dos comportamentos em objetos distintos,
que so agregados como atributo dos objetos que os utilizam. Isso feito por meio da criao
de interfaces para representar cada comportamento, nesse caso as interfaces FlyBehavior e
QuackBehavior. A partir delas so criadas classes concretas que implementam cada
comportamento: FlyWithWings, FlyNoWay, Quack, Squeak e MuteQuack. Observa-se que na
classe Duck, agora, tem-se como atributo dois objetos, um do tipo QuackBehavior e outro do
tipo FlyBehavior, que sero responsveis pela realizao do comportamento especfico. A
classe apresenta, dessa forma, os mtodos performFly() e performQuack(), no lugar dos
mtodos fly() e quack(), e setQuackBehavior() e setFlyBehavior(). Estes ltimos permitem
configurar o comportamento de vo para cada pato de forma dinmica. Note que a mudana
de comportamento ao longo da interao com jogos eletrnicos uma caracterstica comum
s personagens dos mesmos. No contexto aqui explorado, um pato poderia, por exemplo,
adquirir como bnus a habilidade de voar logo aps uma passagem de fase do jogo.
26
Figura 8 Diagrama de Classes Final (UML) Strategy
Na Figura 9 temos a implementao da interface FlyBehavior e das classes concretas
FlyNoWay e FlyWithWings que implementam essa interface. Na Figura 10, temos a
implementao da outra interface, QuackBehavior, e das classes concretas Quack, Squeak e
MuteQuack que implementam essa interface.
Figura 9 Classes FlyBehavior.java, FlyWithWings.java e FlyNoWay.java
27
Figura 10 Classes QuackBehavior.java, Quack.java, MuteQuack.java e Squeak.java
Na classe abstrata Duck, Figura 11, temos a implementao dos mtodos

performQuack() e performFly(). Neles so executados os comportamentos de grasnar e voar,
respectivamente, chamados atravs dos objetos quackBehavior e flyBehavior. Note que o
comportamento que ser executado depender da instncia desses objetos. Os mtodos
setQuackBehavior() e setFlyBehavior() tambm so implementados, permitindo a mudana
de comportamento em tempo de execuo.
28
Figura 11 Classe Duck.java
Na Figura 12, temos as classes MallardDuck, WoodDuck, RedheadDuck e

RubberDuck que estendem a classe abstrata Duck. importante observar que no construtor
dessas classes temos a instanciao dos objetos quackBehavior e flyBehavior, herdados da
classe Duck, de acordo com cada tipo de pato, o que estabelece a relao de agregao entre
os patos e os seus comportamentos. A agregao simples visto que os objetos relativos
aos comportamentos persistem eventual eliminao do pato que o utilize.
29
Figura 12 Classes MallardDuck.java, ReadheadDuck.java, WoodDuck.java e RubberDuck.java
Na Figura 13, temos uma pequena aplicao, classe Application, onde mostramos o
funcionamento das classes discutidas anteriormente.
Figura 13 Classe Application.java
Proposio
Um Sistema de Controle de Produo Cientfica (SCPC), em desenvolvimento para
uma instituio de ensino, permite a organizao de diferentes tipos de documentos, tais como
monografias, artigos, relatrios e estatsticas. Possuindo os diferentes documentos um
conjunto de caractersticas em comum, para diversas funcionalidades do sistema, eles so
tratados de maneira indistinta. Entretanto, algumas operaes, embora comuns a todos os
tipos de documento, apresentam especificidades, como o caso da operao de codificao.
Relatrios e estatsticas so codificados em HTML, para serem apresentadas na interface de
30
navegadores Web, enquanto que artigos e monografias so codificados em PDF. Alm disso,
alterando-se o modo de operao do sistema, deve ser possvel codificar tambm em PDF os
documentos do tipo relatrio e estatstica.
A partir do problema apresentado, prospecte uma soluo reutilivel que leve em
considerao a possibilidade de diferentes formas de condificao para todos os tipos de
documento, sem deixar de considerar suas semelhanas. Com base no padro Strategy,
elabore um diagrama de classes capaz de abstrair todos os tipos de objetos envolvidos na
soluo. Em seguida, implemente a soluo modelada.
Lembre-se que a soluo deve tratar tanto a especificidade do comportamento de
codificao para os diferentes tipos de documento como a dinmica associada alterao no
modo de operao para os documentos do tipo relatrio e estatstica.
Extenso
Uma modificao foi solicitada para o SCPC. Ser preciso agora adicionar um outro
tipo de documento, o edital, e outro tipo de codificao, XML, visto que o sistema ser
integrado ao sistema da Pr-Reitoria de Ps-Graduao. Modifique o diagrama de classes e a
implementao desenvolvidos para contemplar essas novas caractersticas no sistema.
Verifique se foi necessrio modificar alguma das classes ou operaes do modelo
original. Caso isso tenha acontecido, possvel que voc no tenha desenvolvido o padro
Strategy corretamente.
2.5 Abstract Factory

Apresentao
O padro de projeto Abstract Factory tem por objetivo fornecer uma interface para
criao de famlias de objetos relacionados ou dependentes sem especificar suas classes
concretas [7]. Esse padro permite que o sistema determine em tempo de execuo qual
subclasse ir instanciar um objeto. Pois em determinadas aplicaes a subclasse no
conhecida durante o desenvolvimento ou simplesmente no se deseja especificar a subclasse.
Descrio com Exemplo

Tomando como exemplo a construo de um toolkit, que um conjunto de
componentes bsicos de interface grfica com o usurio, por exemplo, botes, janelas, menus,
31
entre outros, para uma aplicao que ser executada pelo sistema operacional Windows.
Inicialmente, a soluo modelada para este toolkit utiliza a classe Button para representar o
componente grfico boto, que possui o mtodo paint() que ir desenh-lo na tela, mostrada
na Figura 14(a). A partir dela so criados todos os botes da aplicao, que so utilizados,
nesse exemplo, pela classe Application.java mostrada na Figura 14 (b).
Figura 14 (a) Classes Button e Menu (b) Classe Application.java
Supondo agora que essa aplicao dever ser executada tambm no sistema
operacional Linux, foi desenvolvido um novo diagrama de classes, mostrado na Figura 15(a).
Utilizando os conceitos de Orientao a Objetos a classe Button agora se tornou abstrata, e as
classes WinButton e LinuxButton estendem dela, onde cada uma dessas classes ir
implementar o mtodo paint() que ir desenhar o componente de acordo com seu sistema
operacional.
Figura 15 (a) Classes WinButton e LinuxButton (b) Classe Application.java
32
Entretanto, utilizando essa soluo, nota-se que as caractersticas de baixo

acoplamento e de reusabilidade da aplicao no so atendidas, pois em uma nova expanso
da aplicao para outro sistema operacional, teria-se que modificar novamente todas as partes
da aplicao onde os botes fossem criados, tornando a manuteno custosa e podendo gerar
inconsistncias na aplicao.
Portanto, para que o toolkit da aplicao seja porttil para diferentes sistemas
operacionais, Windows ou Linux, necessrio que esses componentes no sejam codificados
exclusivamente para uma determinada interface grfica, pois isso dificultaria a mudana de
uma interface para outra, com isso dificultando tambm a manuteno desse cdigo.
Esse problema pode ser resolvido, utilizando o padro de projeto Abstract Factory,
criando-se uma classe abstrata GUIFactory, mostrada na Figura 16, que ser a classe base
para a criao dos componentes grficos. Nessa classe sero definidos os mtodos abstratos
para criao dos componentes, no nosso exemplo o mtodo createButton(). Ser tambm
nessa classe definido, atravs do mtodo getFactory(), qual factory (fbrica em ingls),
WinFactory ou LinuxFactory, ser utilizada para a criao de fato dos componentes. As
classes WinFactory e LinuxFactory so subclasses concretas da GUIFactory, so nessas
classes concretas que os componentes grficos sero construdos de fato, atravs dos mtodos
abstratos herdados da classe me, que sero implementados por elas, ou seja, a partir de agora
a criao dos componentes grficos ser de responsabilidade dessas duas classes concretas.
As classes que representam os componentes grficos tambm sero criadas utilizando
a mesma ideia. No nosso exemplo, a classe abstrata Button possui o mtodo abstrato paint().
A partir dessa classe sero criadas as suas subclasses, WinButton e LinuxButton, e nelas
implementados o mtodo herdado paint().
Neste momento a criao de componentes grfico torna-se transparente para a
aplicao, pois ela enxergar somente as classes GUIFactory e Button, como mostra o
diagrama de classes na Figura 16. Com isso o problema de portabilidade resolvido sem
precisar modificar o cdigo na aplicao que somente ir se preocupar com a criao dos
componentes, sem se preocupar em qual sistema operacional ela ser executada. Internamente
ser definido qual factory utilizar, WinFactory ou LinuxFactory, e, consequentemente, que
componentes criar, WinButton ou LinuxButton.
33
Figura 16 Diagrama de Classes (UML) Abstract Factory
Na Figura 17 temos a implementao da classe GUIFactory. Note que no mtodo
esttico getFactory() na linha 7 definido em qual sistema operacional a aplicao est
rodando em tempo de execuo e dependendo dele ser instanciado um objeto do tipo
WinFactory ou LinuxFactory. criado tambm, como dito anteriormente, o mtodo abstrato
createButton(), que ser implementado pelas suas subclasses para criar o componente grfico
boto.
34
Figura 17 Classe GUIFactory.java I
As classes WinFactory e LinuxFactory estendem de GUIFactory, Figura 18. Note que

o mtodo abstrato createButton() implementado e dependendo da classe ele ir retornar um
objeto do tipo WinButton ou LinuxButton.
Figura 18 Classes WinFactory.java e LinuxFactory.java
A classe abstrata Button, Figura 19, criada com o mtodo abstrato paint(), que
dever ser implementada pelas suas subclasses concretas.
Figura 19 Classe Button.java
35
WinButton e LinuxButton, Figura 20, so as classes concretas que herdam de Button.

Nelas ser definido como o boto ser criado de fato, dependendo do sistema operacional,
atravs da implementao do mtodo paint().
Figura 20 Classes WinButton.java e LinuxButton.java
Note que na aplicao, aqui representada pela classe Application, mostrada na Figura
21, utiliza-se somente as classes GUIFactory e Button, que so as classes bases para a criao
dos componentes grficos. Na linha 7 obtm-se o objeto factory atravs do mtodo
GUIFactory.getFactory(), dessa forma v-se que, para a aplicao, transparente se esse
mtodo ir retornar um objeto do tipo WinFactory ou LinuxFactory. Na linha 8, o objeto
button recebe um objeto atravs da chamada mtodo factory.createButton() e posteriormente,
na linha 9, temos a chamada do mtodo button.paint(). Note, mais uma vez, que para a
aplicao o tipo de boto que ser criado indiferente, bem como a forma como esse boto
vai ser desenhado na tela. Desse modo a aplicao no precisa se preocupar em qual sistema
operacional ela ser executada, facilitando o seu desenvolvimento.
36
Figura 21 Classes Application.java
importante notar que ao surgir uma necessidade de expandir essa aplicao para
outro sistema operacional, por exemplo o Lion da Apple, no se faz necessrio grandes
mudanas. Primeiramente iremos criar a classes LionFactory e LionButton, herdando de
GUIFactory e Button, respectivamente. Por fim, modificaramos apenas o mtodo
getFactory() da classe GUIFactory, como mostrado na Figura 22, mudana essa que no
impacta em nenhuma das classes previamente implementadas, principalmente na aplicao.
Figura 22 Classe GUIFactory.java II
37
Proposio
Uma montadora de veculos est desenvolvendo um sistema para auxiliar sua linha de
montagem. Esse sistema ser responsvel pelo controle completo da montagem dos veculos
dessa montadora, desde o controle de estoque das peas que sero utilizadas at a montagem
das peas no veculo.
Sabe-se que cada modelo de veculo tem sua prpria linha de montagem. Pois, apesar
de alguns modelos compartilharem algumas peas comuns, a montagem e grande parte das
peas so diferentes.
Inicialmente, a montadora quer que o sistema funcione para dois modelos de carro,
modelo X e modelo Y, a partir do qual sero feitos testes e ser decidido pelos scios se o
sistema ser implantado para outros modelos ou no. Desenvolva, a partir do problema
descrito, uma soluo para esse sistema, tendo como foco o baixo acoplamento e a
reusabilidade. Utilizando o padro Abstract Factory elabora o diagrama de classes e
implemente a soluo modelada.
Extenso
Aps inmeros testes a montadora aprovou o sistema de linha de montagem
desenvolvido, para os modelos de carro X e Y. Agora ela quer que a linha de montagem de
seu mais novo carro, modelo Z, tambm seja controlada por esse sistema. Modifique o
diagrama de classes e a implementao desenvolvidas para contemplar essa modificao.
Analise onde as modificaes foram realizadas, se foi preciso modificar alguma das
classes implementadas ou as operaes do sistema anterior, pois, em caso afirmativo,
possvel que o padro Abstract Factory no tenha sido desenvolvido corretamente.
2.6 Composite
Apresentao
O padro de projeto Composite consiste na criao de uma estrutura em rvore para
compor objetos utilizando componentes em estruturas hierrquicas. Cada um desses
componentes implementa uma mesma interface ou estende uma mesma superclasse. Esse
padro permite que o cliente utilize esses componentes e a composio desses componentes
de forma uniforme.
38
Descrio com Exemplo

De acordo com [7] o desenvolvimento de interfaces grficas fazem com que os
desenvolvedores construam diagramas complexos a partir de componentes grficos simples.
O desenvolvedor pode agrupar um grupo de componentes para formar uma componente
maior, que por sua vez ser utilizado para formar um outro componente ainda maior e assim
sucessivamente. Uma simples implementao seria a definio de classes de componentes
grficos primitivos como Texto e Linha e de classes que funcionariam como containers para
essas classes primitivas, por exemplo Imagem.
Entretanto, o cdigo utilizando essa abordagem teria que tratar as classes primitivas e
containers de forma diferente, embora na maioria das vezes elas tenham comportamentos
muito semelhantes. Fazer essa distino faz com que o cdigo se torne mais complexo na
medida que a aplicao cresce. Nesse contexto o padro Composite prope uma soluo
recursiva para que os desenvolvedores no precisem fazer essa distino.
Esse padro tem como principal caracterstica uma classe abstrata que representa tanto
o tipo primitivo como tambm o container, que formado por um ou mais objetos do tipo
primitivo. Essa classe ir conter as caractersticas do objeto individual e as operaes que a
composio desses objetos possuem. Desse modo o desenvolvedor no ir se preocupar com
as diferenas entre as composies e os objetos individuais, passando a tratar cada um deles
uniformemente.
Na Figura 23 temos o diagrama de classe utilizando o padro de projeto em questo,
tomando como exemplo a construo de interfaces grficas. Note que a classe abstrata
ComponenteGrafico representa os objetos individuais, como Linha e Texto, e a composio
desses objetos, nesse exemplo representado pela classe Imagem.
Observe que as classes Linha e Texto, apesar de serem subclasses da
ComponenteGrafico, no implementam os mtodos relacionados a composio de objetos, j
que so classes primitivas e no so compostas por outros objetos. Essas classes s
implementam o mtodo desenhar, que caracterstico da classe primitiva.
A classe Imagem, que representa a composio de objetos grficos, por sua vez
implementa o mtodo desenhar de forma que esse execute o mtodo desenhar de cada um dos
objetos grficos que o compem. Implementam-se tambm os mtodos que relacionam a
composio desses objetos como Adicionar e Remover.
39
Figura 23 Diagrama de Classes (UML) Composite
Est implementado em Java o exemplo discutido acima de forma simplificada. A
classe ComponenteGrafico abstrata e possui 4 mtodos que devero ser implementados
pelas suas subclasses. Essa classe representa tanto os objetos primitivos quanto a composio
deles.
Figura 24 Classe ComponenteGrafico.java
As classes Linha e Texto so as classes primitivas que herdam de ComponenteGrafico.

Essas classes implementam o mtodo desenhar de acordo com o tipo do componente grfico.
Os outros mtodos herdados da superclasse so implementados de forma a no executarem
nenhuma ao significativa por no fazerem sentido para elas.
40
Figura 25 Classes Linha.java e Texto.java
A classe Imagem, que tambm herda de ComponenteGrafico, implementa os mtodos

adicionar, remover e getChild, j que ela uma classe que formada a partir da composio
de vrios objetos do tipo ComponenteGrafico, inclusive dela mesma. Note que nessa classe
temos um atributo que no existe nas outras classes, uma lista de objetos do tipo
ComponenteGrafico. Essa lista simboliza a composio desse objeto a partir de outros
objetos, isso fica melhor entendido quando observamos a implementao do mtodo
desenhar. Ao executar esse mtodo ele ir chamar o mtodo desenhar de cada um dos objetos
que o compem, desse modo o conjunto dos objetos desenhados formam o objeto da classe
Imagem.
41
Figura 26 Classe Imagem.java
Proposio
Um engenheiro de software est criando uma nova linguagem de programao, para
isso ele ter que definir uma gramtica com os comandos que sero utilizados nessa nova
linguagem. Faa o diagrama de classes para representar os comandos dessa linguagem da
melhor forma possvel utilizando o padro discutido.
Dica: divida os comandos da gramtica em comandos simples e comandos compostos.
Extenso
Aps feito o diagrama de classes no exemplo proposto, deseja-se adicionar dois novos
comandos, um simple e um composto. Modifique o diagrama de classes para contemplar os
novos comandos a serem implementados.
42
2.7 Padres de Projeto em Construo

No Apndice deste trabalho esto descritos mais trs padres de projeto que ainda se
encontram em construo no formato do arcabouo proposto. Esses padres so: Facade, no
apndice A; Singleton, no apndice B; e o Iterator, no apndice C.
43
3. A Gnese do Arcabouo Proposto

Embora o arcabouo proposto neste trabalho no tenha ainda sido utilizado na prtica
em um curso de Programao Orientada a Objetos, sua concepo fruto de um estudo
terico e da anlise dos resultados da aplicao de uma atividade prtica sobre Padres de
Projetos em duas disciplinas de Engenharia de Software no Departamento de Engenharia de
Teleinformtica da Universidade Federal do Cear. Uma das disciplinas foi ministrada no
curso de graduao e a outra no curso de ps-graduao (neste ltimo caso, em forma de
Estudos Especiais).
Ao longo do semestre, o professor da disciplina inferiu que a maioria dos alunos
possuam srias dificuldades conceituais em OO, especialmente em relao ao uso de
interfaces e na aplicao do polimorfismo. Essa dificuldade comprometeu de maneira
substancial o processo de aprendizagem de alguns contedos da disciplina, como a UML,
tendo sido revelada a partir de atividades de concepo de diagramas de classe e de sequncia
em um dos trabalhos propostos na disciplina. Nesse sentido, faz-se em seguida um breve
relato do desenvolvimento do curso de Engenharia de Software no semestre letivo 2012-1,
registrando-se algumas observaes e percepes identificadas pelo professor ou retiradas das
avaliaes que foram realizadas ao final de cada atividade pelos alunos.
As duas disciplinas, de graduao e ps-graduao, foram contextualizadas sobre um
mesmo problema-base, o qual foi trabalhado ao longo de todo o semestre letivo. Vrias
atividades foram propostas com base na metodologia PBL (Problem Based Learning),
fazendo-se algumas adaptaes em termo de estruturao e de orientao para compatibilizar
a metodologia realidade dos alunos (e do prprio professor), visto que possuam pouco ou
nenhum contato com esse tipo de abordagem. As primeiras atividades foram relativamente
orientadas para a Anlise e Projeto Orientados a Objeto (APOO). J na segunda atividade,
trabalhou-se com os principais casos de uso identificados para o problema base. Solicitou-se
aos alunos que fizessem, para cada um dos principais casos de uso identificados, a abstrao
dos objetos do domnio do negcio com ele comprometidos. Em seguida, pediu-se a
elaborao, tambm para cada caso de uso, de um diagrama de sequncia que representasse o
desenvolvimento da soluo do mesmo. Para isso, aps rpida definio dos conceitos de
objetos de entidade, de controle e de fronteira, sugeriu-se a abstrao de outros tipos de objeto
(no domnio da soluo) que auxiliassem a implementao do caso de uso, o que, em um
sistema OO, se d atravs da interao, ou comunicao, entre objetos.
44
A atividade foi realizada em grupo, como sugere a PBL. Os alunos manifestaram

grande dificuldade em seu desenvolvimento, o que foi, inicialmente, percebido pelo professor
como uma dificuldade relacionada com a metodologia. Entretanto, a partir das apresentaes
e discusses realizadas em sala de aula, notou-se uma limitao particular em lidar com
solues orientadas a objeto. Para os alunos de graduao, essa situao foi percebida com
alguma surpresa, visto que, na grade curricular do curso de Engenharia de Teleinformtica,
existe uma disciplina semestral especificamente voltada para a Orientao a Objetos
(Tcnicas de Programao para Engenharias II). No caso da ps-graduao, existe uma
heterogeneidade natural, devido ao fato de os alunos serem egressos de diversos cursos,
alguns no tendo tido qualquer tipo de formao em Orientao a Objetos.
A partir das percepes relatadas anteriormente, e tendo em perspectiva o avano da
disciplina com incurses em Projeto (design) OO, com definio da arquitetura do sistema,
componentizao, especificao das interfaces entre os componentes, entre outros aspectos
que dependem de um backgroud razoavelmente consistente em OO, foi preciso estabelecer
novos parmetros para o aprendizado de Engenharia de Software. Em especial, percebeu-se
que seria praticamente intil trabalhar Padres de Projeto, que fazem parte do programa da
disciplina, sem o devido amadurecimento de conceitos de OO.
Desenvolva um estudo sobre padres de projetos e, para cada padro definido para o seu grupo, registre
seus estudos em uma documentao contendo:
1. A apresentao do estudo sobre o padro
2. Uma possvel aplicao do padro estudado no sistema Mquinas de Alimentos em Redes sobre
o qual vem sendo contextualizadas as nossas atividades. Na apresentao da aplicao, desenvolva:
2.1. o diagrama de classes para a situao-exemplo;
2.2. a implementao de teste com uma linguagem Orientada a Objetos (no precisa ser uma
aplicao completa, basta ser uma simulao de uso para as classes que compem a
implementao do padro!).
3. Observaes:
3.1. Caso no consiga identificar uma aplicao no sistema que vem sendo trabalhado, exemplifique
o uso do padro em um outro contexto.
3.2. Sugere-se a gerao do cdigo a partir do diagrama de classes concebido, usando, para isso,
uma ferramenta CASE (EA, Astah, Umbrello, etc.), alm da complementao do cdigo com o
desenvolvimento dos mtodos especificados.
Lista de padres a serem estudados por grupo (podendo ser estendida, caso o grupo deseje):
Grupo A - ADAPTER, OBSERVER, PROXY, COMMAND, BRIDGE, DECORATOR
Grupo B ADAPTER, OBSERVER, PROXY, COMMAND, FACADE, TEMPLATE
Grupo C ADAPTER, OBSERVER, PROXY, COMMAND, ITERATOR, COMPOSITE
Grupo D ADAPTER, OBSERVER, PROXY, COMMAND, FACTORY, STRATEGY
Grupo E ADAPTER, OBSERVER, PROXY, COMMAND, ITERATOR, STATE
Grupo F OBSERVER, COMMAND, COMPOSITE (individual)
Figura 27 Enunciado da Atividade sobre Design Patterns
45
Assim, foi proposta uma atividade sobre Padres de Projeto na disciplina de

Engenharia de Software que est na gnese do arcabouo formalizado neste trabalho de
concluso de curso. O enunciado desta atividade encontra-se do quadro da Figura 27.
Durante a concepo desta atividade, considerou-se a possibilidade de reconstruo
dos conceitos fundamentais de Orientao a Objetos, pedindo-se, no s a modelagem de
situaes de uso dos padres de projeto, mas tambm a implementao da soluo usando
uma linguagem OO.
A atividade foi desenvolvida em dupla. A quantidade de padres solicitada por grupo
exigia que todos os componentes realizassem atividades de modelagem e programao,
inviabilizando o acmulo da atividade de programao para um nico aluno por dupla.
Alguns padres foram desenvolvidos por todos os grupos visando a discusso e a comparao
das solues em sala de aula.
Os resultados dessa atividade foram bastante significativos. Alm da documentao
solicitada, associada aos estudos sobre o padro, incluindo a codificao de uma situao
exemplo, pediu-se a apresentao do diagrama de classes em sala de aula, a explicao da
soluo e a demonstrao do seu uso. Durante as apresentaes, tanto no curso de graduao
como no de ps-graduao, verificou-se que algumas solues desenvolvidas resolviam o
problema ao qual se propunham, mas no se aplicavam corretamente ao padro. Em geral, a
verificao da inconsistncia era feita quando se solicitava a extenso da soluo para
verificar a reusabilidade do padro. Apesar do estresse inicial dos alunos, visto que as
modificaes eram feitas ao vivo, com projeo do desktop do computador usado no
quadro, a atividade e a discusso se mostrou altamente produtiva e didtica, reforando os
conceitos de OO e mostrando o alto grau de reusabilidade e baixo acoplamento propiciado
pelos padres de projeto.
A partir dessa observao, foram estruturados os blocos do arcabouo proposto neste
trabalho, que esto representados na Figura 4. Fruto das experincias relatadas no pargrafo
anterior, a nfase dada para o ltimo bloco do arcabouo, relativo ao desenvolvimento
prtico, onde na primeira parte desenvolvido uma soluo para um problema proposto,
enquanto na segunda parte valida-se a primeira, demonstrando a extensibilidade provida pelo
padro.
Outro aspecto que apresentou uma particular dificuldade para o desenvolvimento da
atividade de padres de projeto, que foi registrado entre os alunos de engenharia de software
nos dois cursos, foi a necessidade de encontrar a aplicabilidade do padro de projeto em
46
estudo para o sistema sobre o qual se desenvolviam as atividades da disciplina. Esse tipo de
dificuldade pode comprometer o tempo do aluno e retirar o foco de seu aprendizado da
programao Orientada a Objetos. Assim, tendo em vista a sua aplicao em disciplinas de
programao, e no em disciplinas de engenharia de software, estabeleceu-se que o arcabouo
deve enunciar diretamente uma situao problema apropriada ao uso do padro.
Ao final da atividade, foi solicitado aos alunos do curso de graduao que
preenchessem um formulrio de avaliao. As questes eram avaliadas pelos alunos usando
uma escala de representao variando de A (nota mxima) a E (nota mnima), ou X (no se
aplica). Dentre outros aspectos menos relevantes para este trabalho, as quatro perguntas
abaixo foram colocadas:
1) Como voc avalia os seus CONHECIMENTOS SOBRE ORIENTAO A
OBJETOS ANTES DO DESENVOLMENTO DESTA atividade?
2) Como voc avalia os seus CONHECIMENTOS SOBRE ORIENTAO A
OBJETOS DEPOIS DO DESENVOLMENTO DESTA atividade?
3) Aps a realizao do trabalho, como voc avalia a sua ABSORO DO
CONTEDO DESIGN PATTERNS?
4) Caso voc venha a trabalhar ou trabalhe com desenvolvimento de software,
como voc avalia a contribuio dessa atividade NA SUA VIDA
PROFISSIONAL?
A fim de computar as mdias das respostas, os conceitos associados atribudos pelos
alunos foram substitudos por valores numricos da seguinte maneira: A-10, B-8, C-6, D-4, E2 e X-0.
A Tabela 1 resume as mdias das avaliaes realizadas pelos onze alunos da turma de
graduao:
Tabela 1 Avaliao mdia dos alunos da turma de graduao para a atividade sobre padres de projeto
na disciplina de Engenharia de Software (2012-1)
Questo
Mdia
6,6
8,6
7,8
8,8
47
Pelas mdias apresentadas nas questes 1 e 2, respectivamente 6,6 e 8,6, percebe-se

que os alunos experimentaram um significativo aumento na sensao de aprendizado sobre o
contedo OO aps a realizao da atividade que durou por volta de trs semanas. Essa
sensao foi observada tambm pelo professor em funo do desempenho e da confiana
demonstrada pelos alunos durante a apresentao das solues relativas atividade.
Entretanto, no que concerne o aprendizado de padres de projeto, foi registrada uma absoro
menor dos conceitos, revelado pela mdia 7,8 para a pergunta 3. Isso foi reforado por
algumas observaes escritas pelos alunos nos formulrios das avaliaes (em espaos
destinados a comentrios livres) e em algumas manifestaes verbais. Os comentrios
convergiam para o fato de que seria necessrio um tempo maior para trabalhar
satisfatoriamente com todos os padres propostos, o que seria praticamente invivel em uma
disciplina de 4 crditos. Essa caracterstica parece endossar a necessidade de uma dedicao
maior aos padres de projeto no contexto de disciplinas de programao, previamente ao
ensino de Engenharia de Software.
Por ltimo, a mdia da pergunta 4 mostra que os alunos da graduao que cursaram a
disciplina tm em perspectiva que o aprendizado de padres de projeto possui importncia
significativa em seu futuro profissional. importante relatar que apenas um ou dois dos
alunos dessa turma apresentam uma perspectiva profissional mais voltada para a rea de
hardware, o que pode ter influenciado para menos a mdia dessa questo.
A anlise exposta neste captulo fundamenta, assim, o arcabouo proposto, embora se
tenha conscincia da necessidade de experimentaes e readequaes sucessivas a partir do
momento em que ele seja efetivamente empregado como ferramenta de apoio didtico ao
processo de ensino e aprendizagem em disciplinas de programao.
48
4. Consideraes finais
Dada a importncia da utilizao de padres de projeto na qualidade do software a ser
produzido, foi desenvolvido neste trabalho um arcabouo para servir de apoio ao aprendizado
em disciplinas de programao orientada a objetos. Esse arcabouo constitudo por cinco
elementos que descrevem o comportamento de cada padro de projeto: apresentao,
descrio com exemplo, codificao do exemplo, proposio e extenso.
Esse trabalho selecionou um conjunto de padres que so julgados importantes e para
cada um deles descreve o que tem de mais importante na literatura [5], [7], [8], [11], [17],
sempre com foco na didtica de ensino. Para cada padro de projeto mostra-se em quais
aplicaes ele utilizado e destaca-se um problema em especfico, tomando-o como exemplo,
que seja mais conveniente para facilitar o entendimento da soluo que o padro fornece. A
partir desse exemplo criado o diagrama de classes da soluo. O exemplo tambm
implementado em Java para demonstrar o comportamento do padro. Por fim, apresentado
um exerccio proposto e uma extenso do mesmo com o objetivo de fixar o entendimento do
padro de projeto em questo.
O arcabouo possui duas sees principais no aprendizado de padres de projeto,
Proposio e Extenso. Nessas sees so colocados problemas com o objetivo de prover
um melhor entendimento, na prtica, do padro de projeto, mostrando sua utilidade e sua
versatilidade na evoluo e modificao da aplicao. Contudo, a elaborao de problemas
que sejam didticos e que abordem o padro na melhor forma possvel no uma tarefa fcil,
visto que necessrio que haja experincia em sala de aula notando as dificuldades e
deficincias dos alunos. Dessa forma, necessrio que haja uma utilizao na prtica do
arcabouo, tendo como propsito sua evoluo de acordo com as dificuldades que forem
surgindo.
Apesar de o arcabouo proposto ainda no ter sido utilizado na prtica em uma
disciplina de programao orientada a objetos, atravs de um estudo terico e da anlise de
uma atividade sobre padres de projeto em duas disciplinas no Departamento de Engenharia
de Teleinformtica da UFC, sendo uma na graduao e outra na ps-graduao, pode-se
inferir que as dificuldades conceituais em Orientao a Objetos, em especial no uso de
interfaces e de polimorfismo para soluo de problemas, comprometeu substancialmente o
processo de aprendizagem. Percebeu-se que seria praticamente intil trabalhar Padres de
49
Projeto sem o devido amadurecimento de conceitos de OO. Desse modo, justifica-se incluir,
de maneira objetiva, o estudo sobre padres de projeto j em disciplinas de programao
orientada a objetos, visto que eles podem ser vistos como tcnicas avanadas e consolidadas
de programao.
A utilizao deste trabalho em disciplinas de programao orientada a objetos torna o
aprendizado de padres de projeto mais eficaz, j que a teoria vista de forma mais prxima
da prtica, por ter exerccios para a melhor compreenso do padro, e mais objetiva, pois,
diferente de alguns livros, onde h, por vezes, exausto de informaes desnecessrias, neste
trabalho o padro visto tendo como foco a soluo para o problema apresentado.
50
5. Referncias Bibliogrficas
[1]
IEEE.
Institute
of
Eletrical
and
Eletronics
Engineers.
Disponvel
em
<http://www.ieee.org>. ltimo acesso em 15 de maio de 2012.

[2]
SOMMERVILLE, I. Engenharia de software. 8 Edio. So Paulo: Pearson/Prentice

Hall, 2007. 522 p.
[3]
ABNT (Associao Brasileira de Normas Tcnicas). NBR ISO 9000/2005: Sistema de

Gesto da Qualidade - Fundamentos e Vocabulrio. Rio de janeiro, 2005.
[4]
PRESSMAN, R. S. Engenharia de software. 6 Edio. So Paulo: McGraw-Hill, 2006.

720 p.
[5]
Bruegge, B; Dutoit, A. H. Object-Oriented Software Engineering: Using UML, Patterns

and Java. 2nd Ed. Prentice Hall, 2003. 800 p.
[6]
Alexander, C; Ishikawa, S; Silverstein, M; Jacobson, M; Fiksdahl-King, I; Angel, S. A

Pattern Language. Oxford University Press, NewYork, 1977.
[7]
GAMMA, E; HELM, R; JOHNSON, R; VLISSIDES, J. Design Patterns - Elements of

Reusable Object-Oriented Software. 1a Edio. Addison-Wesley, 1995. 395p.
[8]
DEITEL, H. M; DEITEL, P. J. Java: Como programar. 6 Edio. So Paulo:Pearson,

2006. 1110 p.
[9]
Sierra, K; Bates, B. SCJP Sun Certified Programmer for Java 6 Study Guide (Exam
310-065). McGraw-Hill, 2008.
[10] Liskov, B.H; Wing J.M. Behavioral Subtyping Using Invariants and Constraints.
Formal Methods for Distributed Processing, an Object Oriented Approach, Howard
Bowman and John Derrick, editors, Cambridge University Press, 2001, pp. 254-280.
[11] Freeman, E; Freeman, E; Sierra, K; Bates, B. Head First: Design Patterns. 1st Ed.
O'Reilly Media, 2004.
[12] ECLIPSE FOUNDATION. Eclipse Helios. Disponvel em <http://www.eclipse.org>.
ltimo acesso em 30 de maio de 2012.
[13] KOSCIANKI, A; SOARES, M. S. Qualidade de software. 2 Edio. So
Paulo:Novatec, 2007. 395 p.
[14] SERSON, R. R. A Bblia: Certificao JAVA 6. Rio de Janeiro: Brasport, 2009.
51
[15] Dicionrio Web. Disponvel em <http://www.dicionarioweb.com.br>. ltimo acesso em

10 de junho de 2012.
[16] THAYER, R. H; CHRISTENSEN, M. J. Software engineering. 3rd Ed. Hoboken, NJ:
IEEE Computer Society, 2005.
[17] SHALLOWAY, A; TROTT, J. R. Explicando padres de projeto: uma nova perspectiva
em projeto orientado a objeto. Porto Alegre: Bookman, 2004.
52
6. Apndice
6.1. Apndice A - Facade
Apresentao
O padro de projeto Facade, fachada em francs, um padro do tipo estrutural e tem
por objetivo fornecer uma interface unificada que simplifique o entendimento e a utilizao de
um subsistema mais complexo.
Descrio com Exemplo

Em algumas aplicaes para um processo ser realizado necessrio que um conjunto
de aes em diferentes classes sejam executadas, a esse conjunto de classes chamamos de
subsistema. Dependendo da aplicao, esse subsistema pode se tornar bem complexo, isso
far com que o uso e o entendimento dele se torne complexo. Com o propsito de simplificlo criado uma classe de fachada que ir conhecer as funes desse subsistema e ir fornecer
para a aplicao uma interface simplificada dos processos realizados por ele.
Ao ligar um carro, por exemplo, existem vrios processos que ocorrem que no
conhecemos bem ao certo, mas que precisam ser executados para o carro ligar corretamente.
Esse comportamento a base do padro de projeto Faade, onde um objeto (chamado de
objeto fachada) fornece uma interface simples para um subsistema mais complexo. Nesse
caso o objeto carro o nosso objeto fachada para o subsistema veculo. Exemplificando de
forma simplificada temos as classes Motor, Farol, Porta e Radio que fazem parte do
subsistema veculo. Ao ligar o carro o motor liga, o farol ascende, a porta tranca e o radio
liga. Ao desligar o carro o motor desliga, o farol apaga, a porta destranca e o radio desliga.
Nota-se que ao ligar e desligar o carro vrios processos ocorrem, porm de forma transparente
para o cliente, ou seja, ele no precisa saber exatamente o que est por trs do processo ligar
ou desligar o carro, pois atravs desse padro esses processos sero controlados pelo objeto
fachada.
53
Figura 28 Diagrama de Classes (UML) Facade
Atravs da estrutura mostrada na Figura 28 possvel observar que a aplicao

enxerga o objeto fachada, e atravs dele e de suas operaes acessa os processos do
subsistema. Esse padro apesar de fornecer uma interface que simplifica o uso e o
entendimento de um subsistema, no impede que a aplicao utilize as classes desse
subsistema diretamente.
54
Figura 29 Classes Motor.java, Porta.java, Farol.java e Radio.java
As classes apresentadas na Figura 29 so classes do subsistema em questo. Note que

sem uma classe fachada a aplicao precisaria, ao ligar e desligar o carro, chamar cada um
dos mtodos de cada uma das classes do subsistema.
55
Figura 30 Classe CarroFacade.java
A classe CarroFacade, Figura 30, nossa classe fachada, faria o papel de simplificador
dos processos relacionados ao subsistema, nesse caso ligar e desligar o carro. Desse modo,
como dito anteriormente, a aplicao no precisaria se preocupar com cada um dos processos
internos, e sim com os processos que realmente so relevantes para ela: ligar e desligar o
carro.
Proposio
O sistema de uma loja virtual recebe dados de um cliente atravs de um formulrio
que contm informaes de usurio e do carto de crdito. Aps receber os dados, as entradas
so validadas e gravadas em um lugar apropriado. Utilize o padro Facade para diminuir o
acoplamento entre os componentes, reduzindo as dependncias entre eles. Na Figura 31
mostra-se o diagrama de classes do exemplo em questo.
56
Figura 31 Exerccio Proposto Facade
Extenso
No sistema do exerccio acima, necessrio que seja adicionado ao formulrio o
endereo do cliente, modifique o diagrama de classes e a implementao, explicitando onde se
dariam as modificaes.
6.2. Apndice B - Singleton

Apresentao
Assegurar que uma classe tenha somente uma nica instncia. Aps a instanciao
desse objeto, no ser mais permitido a criao de objetos adicionais dessa mesma classe.
Descrio com Exemplo

Existem aplicaes que requerem que somente uma instncia de uma classe seja
criada. Por exemplo, alguns sistemas se conectam a um banco de dados utilizando apenas uma
instncia que gerencia a conexo, evitando que sejam desperdiados recursos ou que se
incorra em erros. Outra exemplo a utilizao de arquivo de log, onde uma nica instncia
seja responsvel pelo acesso a esse arquivo, evitando inconsistncias nas informaes
registradas.
Na API padro do Java, por exemplo, so raros os exemplos que utilizam o padro
Singleton, mas podemos encontr-los em locais onde a JSE (Java Standard Edition) precisa
utilizar os recursos do SO (Sistema Operacional) ou da JVM (Java Virtual machine). A classe
Runtime um bom exemplo, requerendo a existncia de um nico objeto que represente o
ambiente em que a aplicao est executando.
57
Figura 32 Diagrama de Classes (UML) Singleton
O padro de projeto Singleton, como dito acima, garante que um sistema instancie no
mximo um e somente um objeto de uma classe. No exemplo abaixo, demonstra-se como
feita a implementao desse padro em Java.
Na linha 3 temos a declarao da classe Singleton com o modificador final,
objetivando a no criao de subclasses o que poderia fornecer outras instncias de objetos da
mesma hierarquia, ferindo o objetivo principal do padro. Na linha 8 declaramos o construtor
da classe Singleton como private. Esse construtor caracteriza o padro de projeto Singleton,
pois, a partir dele, mostramos que somente a classe Singleton pode instanciar um objeto
Singleton. Juntamente com o construtor privado criada uma referncia private, encapsulando
a referncia ao objeto nico, e static, que garante a existncia de uma nica referncia ao
objeto Singleton, declarado como singleObject, na linha 5. Na linha 13 declarado o mtodo
getInstance() que retornar aos clientes a instncia nica da classe. Nesse mtodo
instanciado o objeto singleObject de Singleton, caso ele ainda no exista. Nele tambm
utilizado o modificador synchronized para impedir a execuo simultnea deste mtodo em
eventuais requisies.
58
Figura 33 Classe Singleton.java
A classe Main.java utiliza a classe Singleton.java para exemplificar o funcionamento

desse padro de projeto. Nessa classe podemos notar que realmente temos um e somente um
objeto instanciado do tipo Singleton, e que qualquer modificao feito nele ser refletido em
todas as classes que o utilizam.
59
Figura 34 Classe Main.java
Proposio
Precisa-se desenvolver um simulador de um processador, que possui apenas um ncleo
de processamento, que ser utilizado para testar algoritmos de escalonamento. Nesse projeto
ser utilizado um nico objeto para representar esse nico ncleo de processamento, onde as
aplicaes iro utiliz-lo para executar suas tarefas. Implemente a classe CPU de forma a
garantir a integridade da execuo de dados, utilizando o padro Singleton.
Extenso
A partir do exerccio anterior, implemente duas classes que representem duas
aplicaes distintas que iro utilizar o microprocessador em questo.
6.2. Apndice C - Iterator

Apresentao
Prover uma forma de acessar objetos pertencentes a uma estrutura de dados sem saber
exatamente como ela representada, ou seja, sem conhecer como essa estrutura acessa seus
dados ou mesmo como ela os organiza.
60
Descrio com Exemplo

Estruturas de dados, como por exemplo arrays, listas, pilhas e filas, so largamente
utilizados no desenvolvimento de software para organizar os dados de um programa. Agora
imagine que o desenvolvedor tenha que percorrer os objetos pertencentes a dois ou mais tipos
de estruturas de dados. Para fazer isso ele ter que saber com qual estrutura de dados ele est
mexendo, entretanto se isso no for possvel ele no poder faz-lo.
O padro de projeto Iterator uma soluo para o problema descrito acima. Esse
padro prope a criao de uma classe que ir percorrer os objetos da estrutura de dados de
forma transparente, ou seja, sem precisar conhecer exatamente como os dados esto
organizados e qual o comportamento da estrutura de dados.
Na diagrama de classes mostrado na Figura 35 temos a classe que representa a
estrutura de dados Estrutura, que uma classe abstrata, nela existe o mtodo que ser
implementado pelas suas subclasses concretas criarIterador(), nesse mtodo ser criado um
objeto que ser usado para percorrer a estrutura. No exemplo abaixo, temos as classes Fila e
Lista como as subclasses concretas da classe Estrutura. Note que na implementao do
mtodo criarIterador() cada uma das classes Fila e Lista ir retornar um objeto diferente.
Para representar a classe que ir percorrer os objetos da estrutura de dados, foi criada
uma classe abstrata Iterador que possui mtodos que iro ser implementados pelas suas
subclasses concretas IteradorFila e IteradorLista. Esses mtodos sero implementados de
acordo com a estrutura de dados iro percorrer, porm para o usurio isso transparente, ele
s ir enxergar os mtodos first(), next() e hasNext().
61
Figura 35 Diagrama de Classes (UML) Iterator
Na Figura 36 temos a implementao em Java do exemplo discutido. Temos as classes
abstratas Estrutura, que representa as diferentes estruturas de dados, e Iterador, que
representa a classe responsvel por percorrer os objetos da estrutura de dados.
Figura 36 Classes Estrutura.java e Iterador.java
As classes concretas Fila e Lista so subclasses de Estrutura, e implementam o

mtodo criarIterador(). Esse mtodo ir retornar o objeto que ir percorrer os objetos que
esto que esto na estrutura. Na classe Fila o mtodo ir retornar um objeto do tipo
IteradorFila e na classe Lista esse mtodo ir retornar um objeto do tipo IteradorLista.
62
Figura 37 Classes Fila.java e Lista.java
As classes concretas IteradorLista e IteradorFila, so subclasses de Iterador. Elas

implementam os mtodos definidos pela sua superclasse de acordo com a estrutura de dados
que elas iro percorrer.
63
Figura 38 Classes IteradorLista.java e IteradorFila.java
Na classe Aplicacao, Figura 39, temos um exemplo utilizando as classes mostrada na

Figura 38. Nas linhas 7 e 8 instanciam-se dois objetos, uma lista e uma fila, e nas linhas 11 e
12 essas estruturas so populadas. Na linha 14 temos o objeto minhaEstrutura do tipo
Estrutura e a ele atribumos o retorno do mtodo getEstrutura(), nesse mtodo retornado de
forma aleatria a instncia do objeto lista ou do objeto fila. Na linha seguinte temos o objeto
it do tipo Iterador que ir receber o iterador do objeto minhaEstrutura. Finalmente, nas linhas
17 e 18 percorrido os objetos pertencentes estrutura minhaEstrutura atravs do iterador it.
importante observar que, apesar de o tipo de estrutura do objeto minhaEstrutura no ser
conhecido, a forma de acesso aos objetos nela inseridos feita da mesma forma, usando o
iterador, independente de como se d o acesso a essa estrutura ou de como ela est
organizada.
64
Figura 39 Classe Aplicacao.java
Proposio
Faa um programa em Java utilizando o padro acima discutido utilizando pilha e
array como estruturas de dados a serem percorridas pelo iterador de forma transparente.
Extenso
Agora, adicione ao programa desenvolvido uma nova estrutura de dados, hash map.

Um Arcabouço de Apoio Ao Aprendizado de Padrões de Projeto No Contexto de Disciplinas de Programação Orientada A Objetos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Um Arcabouço de Apoio Ao Aprendizado de Padrões de Projeto No Contexto de Disciplinas de Programação Orientada A Objetos

Uploaded by

Copyright:

Available Formats

Universidade Federal do Cear

UM ARCABOUO DE APOIO AO APRENDIZADO DE

Igor Arcanjo Chaves

UM ARCABOUO DE APOIO AO APRENDIZADO DE

Coordenao do programa de Graduao em

Universidade Federal do Cear como parte

Autor: Igor Arcanjo Chaves

Ttulo do Trabalho: UM ARCABOUO DE APOIO AO APRENDIZADO DE PADRES

Defesa em: 29/06/2012

Nota Obtida: 9,7

Fortaleza, 29 de Junho de 2012

Que os vossos esforos desafiem as impossibilidades, lembrai-vos de

Organizao do documento ................................................................................................. 14

Padres de Projeto ....................................................................................................................... 15

A Gnese do Arcabouo Proposto ................................................................................................ 43

Consideraes finais ..................................................................................................................... 48

desenvolvimento, operao e manuteno do software. De acordo com Ian Summerville [2] a

dentro do cronograma estabelecido, considerando que mudanas nos requisitos e no ambiente

Visa-se associar, de maneira efetiva, a teoria e a prtica sobre o estudo de padres de

1.3. Organizao do documento

responsabilidades entre as classes, j os padres de objeto utilizam a composio para fazer

proposto. Assim, so expostos e discutidos os padres criacionais Singleton e Abstract

2.2 Elementos Indispensveis de Programao Orientada a Objetos

Figura 1 Exemplo de Classe e Objetos (UML).

O encapsulamento um conceito que, como o prprio nome insinua, empacota, ou

Figura 2 Exemplo de Herana.

Na Figura 3 mostra-se um exemplo em Java utilizando conceito de polimorfismo. A

Figura 3 Exemplo de Polimorfismo.

A aplicao dos conceitos de herana e polimorfismo, desenvolvidos atravs do

2.3 Arcabouo para o Estudo de Padres de Projeto

Apresentao Neste bloco descrito formalmente o padro de projeto e o

Desenvolvimento conceitual Neste bloco so explorados os aspectos

Desenvolvimento Prtico - Este bloco visa o desenvolvimento prtico do

desenvolvimento conceitual. Evita-se, assim, a falsa sensao de

Descrio com Exemplo

Figura 4 Arcabouo para o estudo de padres.

Na Figura 4, a estruturao seqencial das sees de utilizao do arcabouo

no faz nenhuma restrio em relao linguagem de programao ou tecnologia a serem

Descrio com Exemplo

Figura 5 Diagrama de Classes Inicial (UML) Strategy

Supondo-se a necessidade de adicionar um novo comportamento para patos existentes

Figura 6 Classes RubberDuck e WoodDuck

Figura 7 Classes RubberDuck

Para solucionar os problemas citados, prope-se o padro de projeto Strategy. A

Figura 8 Diagrama de Classes Final (UML) Strategy

Figura 9 Classes FlyBehavior.java, FlyWithWings.java e FlyNoWay.java

Figura 10 Classes QuackBehavior.java, Quack.java, MuteQuack.java e Squeak.java

Na classe abstrata Duck, Figura 11, temos a implementao dos mtodos

Figura 11 Classe Duck.java

Na Figura 12, temos as classes MallardDuck, WoodDuck, RedheadDuck e

Figura 12 Classes MallardDuck.java, ReadheadDuck.java, WoodDuck.java e RubberDuck.java

Figura 13 Classe Application.java

2.5 Abstract Factory

Descrio com Exemplo

Figura 14 (a) Classes Button e Menu (b) Classe Application.java

Figura 15 (a) Classes WinButton e LinuxButton (b) Classe Application.java

Entretanto, utilizando essa soluo, nota-se que as caractersticas de baixo

Figura 16 Diagrama de Classes (UML) Abstract Factory

Figura 17 Classe GUIFactory.java I

As classes WinFactory e LinuxFactory estendem de GUIFactory, Figura 18. Note que

Figura 18 Classes WinFactory.java e LinuxFactory.java

Figura 19 Classe Button.java

WinButton e LinuxButton, Figura 20, so as classes concretas que herdam de Button.