Arquitetura de Software Arquitetura de Software

Arquitetura de Software
Pós -Graduação a Dist ância
Professor Luciano Gaspar
Professora Elisamara de Oliveira
1
2
SUMÁRIO
Apresentação 5
Capítulo 1 – Fundamentos de Arquitetura de Software 5
Definição de Arquitetura de Software 5
Mas, o que é arquitetura de software? 6
Modelagem de aplicações de softwares 6
Tarefas Acidentais e Essenciais 7
Aspectos essenciais na produção de software 8
Princípios SOLID 11
Princípio de Responsabilidade Única 12
Princípio Aberto-Fechado 12
Princípio de Substituição de Liskov 13
Princípio Segregação de Interface 14
Princípio de Inversão de Dependência 14
Polimorfismo e Herança em OO 15
Capítulo 2 – Padrões de Arquitetura de Software 16
Definição de Padrão Arquitetural 16
Padrão de Arquitetura em Camadas 17
Padrão de Arquitetura Pipes and Filters ou Pipeline 19
Padrão de Arquitetura Blackboard 21
Model-View-Controller (MVC) 23
Padrão de Arquitetura Microkernel 26
Padrão de Arquitetura Reflection 29
Exercícios do Capítulo 2 30
Capítulo 3 – Design Patterns – Padrões de Criação 31
Conceitos de Padrões de Projeto 31
Definição de Padrões de Criação 36
Padrão Abstract Factory 37
Padrão Builder 38
Padrão Factory Method 40
Padrão Prototype 41
Padrão Singleton 42
Capítulo 4 – Design Patterns – Padrões Estruturais 43
Definição de Padrões Estruturais 43
Padrão Adapter 44
Padrão Bridge 44
3
Padrão Decorator 46
Padrão Façade 47
Padrão Proxy 47
Capítulo 5 – Design Patterns – Padrões Comportamentais 48
Definição de Padrões Comportamentais 48
Padrão Chain of Responsability 49
Padrão Mediator 50
Padrão Observer 51
Padrão Strategy 52
Padrão Visitor 53
Considerações finais 55
Glossário de Siglas 58
Bibliografia 58
4
do software. Além disso, vamos apontar os princípios liga-

Apresentação
dos à arquitetura e aos padrões de projeto que podem ser
seguidos, de forma a trazer um diferencial na carreira do
Os Sistemas de Informação são provedores de solução
desenvolvedor de soluções em software, pois conhecer as
para as mais diversas áreas do conhecimento e impulsio-
dificuldades inerentes a esta área tornará mais fácil o tra-
nam a indústria, o comércio, os serviços e, em especial,
balho quando elas surgirem.
segmentos de mercado dependentes de tecnologia ou

mesmo novos negócios que surgem apoiados em software.
Luciano Gaspar
Segundo Laudon (2010), empresas apoiam seus proces-
Elisamara de Oliveira
sos de gestão nas tecnologias, com o objetivo de gerenciar
suas operações, desenvolver novos produtos e serviços, es-
treitar relacionamento com clientes e fornecedores, auxiliar Capítulo 1 – Fundamentos de
na tomada de decisões e obter vantagem competitiva.
A importância crescente do software, aliado ao maior
conhecimento (desde 1967) sobre como construí-lo, resul- Caro aluno, neste capítulo abordaremos concei-
tou na necessidade de uma formação mais ampla para o tos iniciais sobre o projeto de arquitetura de software
programador. Este deve se preocupar em aplicar técnicas e as consequências de um software não arquitetado.
e métodos especializados para projetar, construir, testar e
manter os produtos de software. Uma parte considerável Será discutido o papel do arquiteto de software,
destes conhecimentos pertence à área de Engenharia de assim como as barreiras e princípios de modelagem
Software. que devem ser levados em consideração na concep-
ção de uma arquitetura.
Após a “crise do software” uma longa série de inovações
passaram a ser adotadas nas práticas de desenvolvimento, Definição de Arquitetura de Software
incluindo modularidade, programação estruturada, diagra-
mas de fluxo de dados, proteção de informações (informa- Caro aluno, para entendermos a necessidade de se ar-
tion hiding), abstração de dados, reutilização de softwa- quitetar um software alguns conceitos serão introduzidos,
re, programação visual, programação orientada a objeto, assim como os desafios que um profissional desta área
padrões de projetos, ferramentas CASE. Porém tudo isso deverá lidar.
trouxe ganhos modestos e não transformou a Engenharia
de Software em algo sistemático, disciplinado e quantifi- Historicamente o número fracassos de projetos de sof-
cável para o desenvolvimento, operação e manutenção do twares são da ordem de 84% de falhas e os fatores críti-
software. cos de sucesso estão relacionados à natureza complexa e
intangível do software.
A Engenharia de Software possui peculiaridades que tal-
vez nenhuma outra área do conhecimento tenha. Isso nos O software é visto pelas áreas de negócios como algo
faz refletir sobre quais competências um profissional que flexível e adaptável, porém sabemos que um software não
atue em desenvolvimento de sistemas de software tenha arquitetado pode dificultar sua manutenção, escalabilida-
que adquirir. de e reuso.
Assim, prezado aluno, esse material foi elaborado para Desta forma, desenvolver soluções arquitetadas é uma
chamar sua atenção e trazer uma reflexão sobre os prin- prática que tornará nosso trabalho, a longo prazo, menos
cipais aspectos que têm afetado diretamente a produção reativo e estressante.
5
Mas, o que é arquitetura de software? Reflita: Os softwares que estamos desenvol-

vendo são mais parecidos com a figura 1 ou com
a figura 2? Nossas aplicações possuem um pa-
Bass et al (2003) definem arquitetura de sof- drão arquitetural? São concebidos para aceitar
tware como a estrutura do sistema composta por novas funcionalidades? Permitem o reuso e es-
elementos de software (componentes, conectores calabilidade?
ou dados), com propriedades externamente visíveis
destes elementos e os relacionamentos entre eles. Para aqueles que possuem vivência na área de de-
senvolvimento de software sabem que muitas vezes uma
mudança ou um novo requisito tem impacto estrutural e
Uma arquitetura registra informações sobre como os
demanda grande esforço de desenvolvimento e é realizada
elementos de software se relacionam uns com os outros,
sem planejamento desencadeando efeitos colaterais em
ocultando ou explicitando elementos do software que de-
todo software.
vem ou não existir em diferentes níveis de abstração.
As figuras 1 e 2 ilustram um projeto arquitetado e um Modelagem de aplicações de softwares

não arquitetado. Reflita sobre as principais características
entre eles. Caro aluno, como estudado na disciplina Engenharia de
Software e de Requisitos, um aplicativo possui um ciclo de
vida. Ao longo deste ciclo muitas mudanças são realizadas
e geram impactos no código escrito nas primeiras versões
do software.
O software é afetado por um fenômeno de degradação

que impacta sua confiabilidade, estrutura e sua consistên-
cia. Sua documentação é desatualizada dificultando sua
manutenção, tornando-a onerosa.
Figura 1: Bairro Planejado Sabemos que um processo de desenvolvimento defi-

Fonte: http://blogdelancamentos-hbc.lopes.com.br/2009/05/ nido que favoreça a obtenção e validação dos requisitos
realize-seu-sonho-no-parque-dos-sonhos.html
pode minimizar esses impactos, porém o fato do software
ser visto como algo flexível torna a definição de uma arqui-
tetura um elemento fundamental para o desenvolvimento
de software em larga escala.
O uso de modelos apoiam o entendimento e definição

da arquitetura do software, assim como a identificação das
regiões críticas que podem degradar-se ao longo do tem-
po.
Se você já desenvolveu algum software ou até mesmo
uma planilha eletrônica com várias referências a fórmulas
em diferentes arquivos, já percebeu que existe um limite
Figura 2: Crescimento desordenado para a capacidade humana para compreender, ao longo do
Fonte: http://olhosinquietos.blogspot.com/2012/01/
tempo, aquilo que foi produzido, tornando esta uma ativi-
crescente-e-diversificada.html
6
dade complexa.O software possui uma natureza complexa

crescente seja pelo número de linhas de código ou pela
sua intangibilidade. Logo, a criação de modelos torna-se De acordo com Zachman (1997) arquitetura é o
indispensável para compreensão do que está sendo de- conjunto de artefatos ou um descritivo relevante de
senvolvido. um objeto, de forma que este possa ser construído de
acordo com os requisitos (de qualidade), bem como
No processo de criação de modelos muitos problemas mantido ao longo da sua vida útil.
podem ser antecipados e decisões são tomadas a fim de Neste sentido modelar um sistema significa de-
minimizar seu impacto ao longo do tempo. terminar e representar um conjunto de informações
arquitetadas sob diferentes vistas que servirão de
guia de referência para a produção de algo concreto
(código fonte).
Blaha e Rumbaugh (2006) definem modelo
como uma abstração de algo que facilita seu en-
tendimento antes de construí-lo. Abstração é um
Cada área de conhecimento adota tipos específicos de
processo mental básico que permite lidar com a
modelos. Na engenharia de software contemporânea, se-
complexidade, omitindo detalhes não essenciais.
gundo Booch, Rumbaugh e Jacobson (2006) adota-se uma
perspectiva orientada a objetos, onde a UML é empregada
A abstração permite a simplificação de algo complexo,
para a visualização, a especificação, a construção e a do-
como no exemplo na figura 3.
cumentação de artefatos que orientam o desenvolvimento
do software.
Para entender a importância de controlar esta comple-

xidade, no próximo tópico, vamos analisar o trabalho de
Brooks (1987) que faz uma classificação dos aspectos que
estão sob nosso controle e aqueles que fogem do controle
impactando o cronograma, o custo e a equipe de projeto
Fonte: http://www.mundodastribos.com do software.
Fonte: http://paraconstruir.wordpress.com
Figura 3: Abstração de uma casa
Tarefas Acidentais e Essenciais
No processo de produção do software, criam-se mode-
los para descrever a estrutura e o comportamento de um Independentemente do processo de desenvolvimen-
software para posterior implementação. Estas descrições to de software adotado, um conjunto de tarefas são or-
de modelos guiam a construção e mantém registros das ganizadas e realizadas. Tais tarefas são classificadas por
decisões tomadas na sua concepção. Brooks (1987) como tarefas acidentais e essenciais.
Para os criadores da UML- Unified Modeling Language, • As tarefas acidentais estão relacionadas à im-
Booch, Rumbaugh e Jacobson, nenhum modelo único é plementação do software e as principais preocu-
suficiente. Qualquer sistema não-trivial será melhor inves- pações estão ligadas à sintaxe das linguagens,
tigado por meio de um conjunto de modelos quase inde- aos limites de hardware, aos ambientes e ferra-
pendentes com vários pontos de vista. mentas de desenvolvimento e demais aspectos
Um ou mais modelos podem servir de inspiração para técnicos. Estes aspectos são facilmente superados
dar origem a uma arquitetura que sustente as necessida- com treinamentos, leituras ou a consulta a um
des do que está sendo modelado. profissional mais experiente.
7
• As tarefas essenciais estão relacionadas ao dade, conformidade, flexibilidade e intangibilidade. Estes

processo mental de criação de um conjunto de aspectos são descritos a seguir.
conceitos que se interligam.
• Complexidade
Tanto as tarefas acidentais quanto as essenciais criam
barreiras para o desenvolvimento de software, porém Entidades de software possuem uma natureza com-
grande parte das barreiras acidentais foram transpostas plexa e aumentar sua escala não é meramente repetir os
na última década e as principais falhas de projetos estão mesmos elementos em tamanho maior. É necessário um
relacionadas às atividades essenciais que criam barreiras aumento do número de elementos diferentes amplificando
que dificilmente são domináveis. a complexidade do todo de forma não linear.
De forma análoga, e neste contexto, pode-se comparar Queremos dizer que existe uma grande diferença entre
o processo de desenvolvimento de software ao processo fazer um software com poucas linhas de código e desen-
de criação de um texto, onde as tarefas acidentais estão volver um software com um número maior de requisitos.
relacionadas ao domínio de uma ferramenta de edição de
textos e a sintaxe e semântica da língua. Tais tarefas po-
dem criar barreiras para a produção do texto, mas serão
superadas com algum nível de estudo ou apoio de ter-
ceiros, porém não garantem que o texto escrito atenderá
critérios de qualidade.
Para um software mais robusto, não bastaria aumen-

tar as linhas de código, teremos que incluir elementos de
software para facilitar o entendimento das linhas já produ-
zidas, a manutenção, a inclusão de novas funcionalidades,
aumento da equipe, a padronização, inclusão de interfa-
ces, dentre outras demandas que um software de maior
escala exige.
Logo, o domínio de tarefas acidentais não garante a

Imagine um artesão trabalhando na produção de um vaso
qualidade do que está sendo produzido. A qualidade será
de barro e você, de passagem em turismo pelo local, ado-
definida pela forma peculiar de criação e organização das
rasse aquele vaso. Em função disso solicitasse que o artesão
ideias atuando sobre a construção mental e essencial que
produzisse 1.000 unidades, pois presentearia seus familiares
serão descritos de forma textual.
e venderia o restante dos vasos na sua cidade de origem.
Aspectos essenciais na produção de Reflita: O processo e as ferramentas de produ-

software ção adotados pelo artesão seriam suficientes para
atender sua encomenda? Bastaria apenas aumen-
Brooks (1987) elenca quatro aspectos essenciais que tar em quantidade a matéria prima do artesão?
impactam na produção do software, são eles: complexi- Contratar mais artesões garantiria a beleza do vaso
8
apreciada por você? O processo para produzir uma Provavelmente muitos dos programadores já passaram
unidade é o mesmo para produzir 1.000 unidades? por situações de não conseguir ou demorar para entender
um código, seja ele gerado por terceiros ou até mesmo um
Acredito que chegará facilmente à conclusão que novos código próprio.
elementos deverão ser inseridos no processo de produção
do vaso. Talvez o uso de formas para garantir o padrão, a Sabe-se que a complexidade do código é crescente e
contratação de novos artesões, uma sequência ordenada existe um limite que o cérebro humano consegue geren-
de tarefas, a criação de modelos que serão submetidos a ciar, impactando na quantidade de novas linhas de código
testes, dentre outras ações. que podem ser acrescentadas a um programa ao longo do
Agora reflita: O que diferencia a produção de tempo. [BROOKS,1987]
um software de 1.000 linhas com um de 15.000
linhas? Será só a quantidade de linhas? A figura 5 mostra a relação produtividade no desen-
volvimento versus tempo. À medida que o software vai
Softwares com 1.000 linhas de códigos, no pior caso,
sendo implementado, ou seja, linhas de código são inseri-
podem ser refeitos gastando apenas mais alguns dias de
das, consequentemente sua complexidade crescente afeta
trabalho; porém reescrever um sistema mais complexo le-
a produtividade ao longo do tempo.
varia meses ou anos. Portanto, cuidar da arquitetura no
início reduz os problemas futuros.
A figura 4 exibe os impactos da complexidade na pro-

dução do software. Da complexidade vem a dificuldade
de entender e se comunicar com os membros da equipe
de desenvolvimento levando à deficiência do produto, que
aumenta os custos, que afeta o cronograma e a confiabili-
dade. Da complexidade da estrutura vem a dificuldade de
entender o comportamento e ampliar os programas sem
Figura 5 - Tempo versus produtividade
criar efeitos colaterais, tornando árdua a atividade de ge-
Fonte: Martin [2009]
renciar estes problemas.
• Conformidade e flexibilidade
Outras áreas do conhecimento também lidam com a

complexidade crescente, mas, como o software não está
suscetível às leis naturais, é visto como algo flexível e de
fácil adequação. Pelo menos se comparado à Física e ou-
tras ciências...
Brooks (1997) afirma que, em decorrência da sua com-

plexidade, a versão inicial de um software muitas vezes
não atende aos requisitos na sua plenitude, necessitando
de constantes mudanças, ou seja, que todo software de
sucesso acaba por ser modificado. Assim, um sistema de
software deve ser concebido para mudar.
Caso você já atue na área de desenvolvimento de sof-

Figura 4: Impactos da complexidade no desenvolvimento de software tware, deve ter percebido que a mudança dos requisitos
9
é algo constante. Isso não significa que as mudanças são

correções de erros, mas podem decorrer de novas fun-
cionalidades para atender às necessidades de negócios.
UML (Unified Modeling Language) - Um
Vale dizer que a TI deve impulsionar os negócios e não breve histórico
ser gargalo para novas oportunidades. Logo, caro aluno, A UML surgiu da união de três metodologias de
precisamos desenvolver software no qual uma mudança modelagem: o método do americano Grady Booch,
não afete toda a estrutura já desenvolvida. o método OMT (Object Modeling Technique) do sue-
co Ivar Jacobson e o método OOSE (Object-Oriented
Nosso código deve “aceitar” mudanças com certa fle- Software Engineering) do americano James Rum-
xibilidade, comunicar claramente suas responsabilidades, baugh. Estas eram até meados da década de 1990,
facilitar a manutenção e proporcionar o reuso. Esse é o as três metodologias de modelagem orientada a ob-
grande desafio! jeto mais populares. A união dessas tecnologias con-
tou com o apoio da Rational Software, que incentivou
• Intangibilidade e financiou a união das três metodologias.
Software é intangível, portanto, é difícil se criar uma

O esforço inicial do projeto começou com a união
representação visual objetiva e comum para ele. Ao tentar
do método de Booch com o método OMT de Jacob-
diagramar uma estrutura de software, descobre-se que ela
son, o que resultou no lançamento do Método Unifi-
não é apenas um, mas sim, vários diagramas superpostos
cado no final de 1995. Logo em seguida, Rumbaugh
um aos outros, sem hierarquias ou relações diretas entre
juntou-se a Booch e Jacobson na Rational Software
seus elementos forçando cortes que eliminam conexões
e seu método OOSE começou a ser incorporado à
nas diferentes vistas do modelo.
nova metodologia. O trabalho de Booch, Jacobson e
Rumbaugh conhecidos popularmente como "os três
Para Brooks (1987) esses cortes prejudicam não
amigos", resultou no lançamento, em 1996, da pri-
só o processo de projeto do software, mas também a
meira versão da UML propriamente dita.
comunicação entre os membros da equipe.
Assim que a primeira versão foi lançada, diver-

Vocês já estudaram a UML - Unified Modeling Language,
sas grandes empresas atuantes na área de software
na disciplina “Análise e Modelagem de Objetos”. Como
passaram a contribuir com o projeto, fornecendo su-
viram, essa linguagem é uma poderosa ferramenta para
gestões para melhorar e ampliar a linguagem. Final-
tangibilizar as descrições de implementação do arquiteto mente a UML foi adotada pela OMG (Object Manage-
de software. ment Group) em 1997, como a linguagem padrão de
modelagem. Atualmente a UML está na versão 2.0.
Um arquiteto de software deve apoiar-se em
Fonte: http://www.dsc.ufcg.edu.br/~sampaio/cursos/2007.1/
descrições de modelos para comunicar suas decisões de Graduacao/SIII/Uml/historia_uml/historia_uml.htm
implementação. Um diagrama UML, analogamente, pode
ser comparado com uma planta hidráulica ou elétrica que
um engenheiro civil ou eletricista utiliza para tangibilizar Antes de prosseguir, convém você recordar o que é o
um modelo mental e comunicar seu projeto. paradigma orientado a objetos (OO) e alguns de seus con-
ceitos mais importantes.
Portanto, a descrição de modelos de software apoiados
em diagramas é uma ferramenta essencial para um Volte ao material da disciplina“Análise e Modelagem de
arquiteto de software e um dos elementos que o difere do Objetos” e leia o quadro Saiba Mais que se segue.
programador.
10
• um objeto A tem um método que referencia um

Princípios SOLID
objeto B ou a própria classe B, tipicamente carac-
terizado por um parâmetro ou variável local do
Em 1995 Robert C. Martin iniciou uma discussão so-
tipo B ou um objeto retornado de uma mensagem
bre um conjunto de princípios de modelagem de software
sendo uma instância de B.
orientado a objetos. Estes princípios ajudavam a lidar com
os problemas oriundos da natureza do software discutidos Tais formas de acoplamento podem ser mitigadas com
até aquele momento. mudanças no código fonte. Uma boa prática no desenvol-
Booch, Rumbaugh e Jacobson (2006) definem que, em vimento de software OO é criar estruturas com baixo acopla-
OO, “responsabilidade é um contrato ou obrigação de um mento entre objetos para que a atribuição de responsabi-
tipo ou classe”. Os autores afirmam que há dois tipos de lidades seja feita de forma que sua alocação não aumente
responsabilidades dos objetos: o acoplamento de um objeto com outros.
• De conhecimento (knowing): sobre dados privati- Ainda dentro de um projeto OO, existe outro conceito mui-
vos e encapsulados; sobre objetos relacionados; to importante que é a coesão. Coesão é uma medida de quão
sobre coisas que pode calcular ou derivar. fortemente estão relacionadas e focadas as responsabilidades
de um dado elemento. Um elemento que esteja altamente
• De realização (doing): em fazer alguma coisa em especializado e que não realize uma grande quantidade de tarefas
si mesmo; iniciar uma ação em outro objeto; con- é considerado com alta coesão, ou seja, possui um alto grau
trolar e coordenar atividades em outros objetos. de coesão.
Responsabilidades são atribuídas aos objetos durante

o projeto do software OO. A tradução de responsabilida- Assim, uma classe com baixa coesão, geralmente exe-
des em classes e métodos depende da granularidade da cuta muitas funções pouco relacionadas entre si, realizan-
responsabilidade. Os métodos são implementados para do um trabalho excessivo. Classes deste tipo são altamen-
cumprir responsabilidades. Uma responsabilidade pode te indesejáveis num projeto, pois acumulam os seguintes
ser cumprida por um único método ou por uma coleção de problemas:
métodos trabalhando em conjunto. Responsabilidades do
tipo knowing geralmente são inferidas a partir do modelo • são de difícil compreensão;
conceitual (são os atributos e relacionamentos). • não conseguem ser reutilizadas;
• são de difícil manutenção;
Um dos pontos que levam à degradação do código ao
• são constantemente afetadas por qualquer modi-
longo do tempo é o alto acoplamento entre os objetos
ficação no projeto.
(que é o foco nesta disciplina) que deve ser gerenciado,
reduzindo a dependência entre eles.
No paradigma orientado a objetos uma das principais Baixo acoplamento (low coupling) e alta co-
preocupações é o acoplamento. Um acoplamento pode esão (high cohesion) são conceitos relevantes que
ocorrer de diferentes formas. O acoplamento pode ocorrer devem ser considerados e preservados sempre du-
quando: rante os processos de tomada de decisão em um
projeto orientado a objetos. São conceitos que estão
• uma classe A possui um atributo que referencia o intimamente ligados ao desenvolvimento de softwa-
objeto B ou a própria classe B; res que priorizam uma arquitetura que favorece a
manutenção e a construção de objetos reusáveis.
• um objeto A chama um método de um objeto B;
11
O gerenciamento de dependência entre objetos é um se a forma de cálculo for alterada ou uma interação com
problema que certamente já foi enfrentado por quem a interface gráfica tiver que ser alterada, ambas afetam a
desenvolve ou desenvolveu um aplicativo OO. Não se classe Retangulo. Ou seja, as linhas de código escritas
preocupar com o gerenciamento de dependência leva a nesta classe possuem duas formas de serem impactadas.
um código confuso, difícil de mudar e não reutilizável.
Os princípios abaixo concentram-se na gestão de de-

pendências dos objetos de um sistema OO e são conheci-
dos como SOLID. São estes os princípios SOLID:
S Single Responsability Principle (Princípio de Res-

ponsabilidade Única) Figura 6: Classe Retangulo
O Open Close Principle (Princípio Aberto-fechado)
L Liskov Substitution Principle (Princípio de Substi- Para atender o princípio SRP devemos separar as res-
tuição de Liskov) ponsabilidades em duas classes diferentes, sendo uma para
I Interface Segregation Principle (Princípio de Se- calcular a área e outra para desenhar o retângulo. Neste
gregação de Interface) caso teremos as classes RetanguloDes e RetanguloCal, cada
D Dependency Inversion Principle (Princípio Inver- uma com seus métodos, conforme mostra a figura 7:
são de dependência)
Figura 7: Classes para cálculo da área e desenho de retângulos
Cada um destes princípios será detalhado no que se segue. Princípio Aberto-Fechado

Princípio de Responsabilidade Única O princípio Aberto-Fechado ou simplesmente OCP-
Open Close Principle, estabelece que uma classe deve
O Princípio de Responsabilidade Única, também conhe- estar “aberta” para extensão, porém fechada para modifi-
cido como SRP - Single Responsability Principle estabelece cação, ou seja, devemos organizar as classes para possibi-
que uma classe deve ter um e somente um motivo para litar o crescimento, porém sem alterar o código das classes
mudar. existentes.
Se uma classe é responsável por efetuar várias ações Vejamos o exemplo da figura 8:
dentro de um determinado contexto, ela está ferindo este
princípio.
Vamos analisar o exemplo:
A classe Retangulo da figura 6 possui os métodos

Area () que calcula a área do retângulo e Desenhar()que
desenha o retângulo. Essa classe fere o princípio SRP, pois Figura 8: Classe Pagamento
12
A classe Pagamento possui os métodos que têm as instruções para pagamentos dos tipos Parcelado, Avista, Debito
e Credito. Como você implementaria isso?
Certamente em determinado trecho de código utilizaria uma instrução IF ou CASE e de acordo com a forma de
pagamento selecionado pelo usuário chamaria um método específico. Caso você venha desenvolvendo software desta
forma, lembre-se que o princípio OCP está sendo ferido.
O resultado em não respeitar este princípio é que, para cada nova forma de pagamento, o código da classe Pagamento
deverá ser alterado com a inclusão do novo método de pagamento e a inclusão de mais um parâmetro na instrução IF ou CASE.
Para atender o princípio OCP deve-se separar as formas de pagamento em sub-classes. Desta forma, uma nova forma
de pagamento não afetaria a classe Pagamento, ou seja, o código estaria fechado para alteração e aberto para extensão.
A figura 9 ilustra simplificadamente as classes para atender o OCP, neste exemplo.
Figura 9: Classes e sub-classes para formas de pagamento
Aplicando o princípio Aberto-Fechado, os problemas apontados são evitados, porque a classe Pagamento não pre-
cisa mais ser alterada quando uma nova forma de pagamento for inserida, basta a inclusão de uma subclasse com a
nova forma de pagamento com os métodos específicos deste tipo de pagamento.
Desta forma as classes serão mais simples e não estarão sobrecarregadas de atribuições.
Princípio de Substituição de Liskov

O princípio de Substituição de Liskov, ou simplesmente LSP - Liskov Substitution Principle, estabelece que as classes
derivadas devem ser substituídas por suas classes base. Se utilizarmos um objeto e, através do uso de polimorfismo,
manipulá-lo como sendo do seu tipo base, ele deve funcionar e se comportar da mesma forma como se comportaria se
ele realmente fosse daquele tipo.
Retomando o exemplo ilustrado na figura 9 temos uma classe Pagamento (base) e subclasses derivadas (Parcelado,
Avista, Debito e Credito). Respeitar o princípio LSP significa dizer que posso usar qualquer classe derivada como se fosse
a classe Base Pagamento, sem alterar o comportamento da classe base.
13
Princípio Segregação de Interface

O princípio de Segregação de Interface ou ISP- Interface Segregation Principle estabelece que interfaces sejam de
“fina granularidade”, para que sejam específicas para quem vai utilizá-las. Uma interface não deve ter inúmeras funcio-
nalidades. Deve ser o mais “enxuta” possível, seguindo o princípio SRP, porém voltado para a interfaces.
Princípio de Inversão de Dependência

Com o objetivo de reduzir o acoplamento entre objetos o Princípio de Inversão de Dependência ou DIP- Dependency
Inversion Principle estabelece que sempre devemos depender de classes abstratas e nunca de classes concretas. Se um
objeto depender de classes concretas, qualquer alteração que ocorrer nesta classe, afeta todas que dependerem dela.
Observe a figura 10, elaborada com o software BlueJ (www.bluej.org), que mostra 4 classes distintas, cuja relação entre
elas se dá na forma de classes concretas.
Figura 10: Relação entre Classes
A figura 11 representa, por meio de marcações hachuradas, as classes que são afetadas quando a classe
Canvas é alterada. Observe que uma alteração em Canvas afeta todas as demais classes relacionadas a ela.
Figura 11: Classes afetadas após alteração em Canvas
14
A figura 12 representa uma implementação onde existe

uma relação entre as classes, porém todas dependem da
classe abstrata Figure. Observe que esta classe impede a propa
No mundo real uma operação é simplesmen-
te uma abstração de um comportamento análo-
go entre diferentes tipos de objetos. Cada objeto
"sabe” como executar suas próprias operações.
Entretanto, uma linguagem de programação ba-
seada em objetos seleciona automaticamente o
método correto para implementar uma operação
com base no nome da operação e na classe do
gação da alteração realizada em Canvas. objeto que esteja sendo operado. O usuário de
uma operação não precisa saber quantos métodos
existem para implementar uma determinada ope-
Figura 12: Diagrama com classe abstrata ração polimórfica. Novas classes podem ser adi-
cionadas sem que se modifique o código existen-
te, são fornecidos métodos para cada operação
aplicável nas novas classes.
Ouça o podcast sobre princípios SOLID, dispo-

Herança: é o compartilhamento de atributos e
nível em:
http://podcast.dotnetarchitects.net/2009/11/podcast-8- operações entre classes com base num relaciona-
principios-s-o-l-i-d/ mento hierárquico. Uma classe pode ser definida
de forma abrangente e depois ser refinada em
sucessivas subclasses mais definidas. Cada sub-
classe incorpora, ou herda, todas as proprieda-
des da sua superclasse e acrescenta suas próprias
Polimorfismo e Herança em OO
e exclusivas características. As propriedades da
superclasse não precisam ser repetidas em cada
Polimorfismo: significa que a mesma operação
subclasse. Por exemplo, Janela Rolante e Janela
pode atuar de modos diversos em classes diferen-
Fixa são subclasses da superclasse Janela. Estas
tes. Uma operação é uma ação ou transformação
duas subclasses herdam as propriedades de Ja-
que um objeto executa ou a que ele está sujeito.
nela, como uma região visível na tela. Janela Ro-
Right-justify (justificar à direita), display (exibir)
lante acrescenta uma barra de rolagem e limites
e move (mover) são exemplos de operações. A
de rolagem. A capacidade de identificar proprie-
operação move (mover), por exemplo, pode atuar
dades comuns a várias classes de uma superclas-
de modo diferente nas classes Janela e Peça de
se comum e de fazê-las herdar as propriedades
Xadrez.
da superclasse pode reduzir substancialmente as
repetições nos projetos e programas e é uma das
Uma implementação específica de uma opera-
principais vantagens dos sistemas baseados em
ção por uma determinada classe é chamada de
objetos.
método. Quando uma operação baseada em obje-
tos é polimórfica, pode haver mais de um método
Fonte: [BLAHA ; RUMBAUGH, 2006]
para a sua implementação.
15
Exercícios do Capítulo 1
1 – Descreva brevemente como uma mudança de re-

quisitos pode afetar o projeto arquitetural de um
software.
2 – Como os princípios SOLID contribuem para evitar

a degradação do código fonte?
3 – O Princípio de Responsabilidade Única contribui

para a organização e entendimento do código
fonte? Explique.
4 – Quais recursos um arquiteto de software pode utili- Fonte:http://cebracnailha.blogspot.com/2011_04_01_archive.html

zar para tangibilizar a arquitetura de um software?
Temos agora um problema de segunda ordem que está
5 – Explique porquê consideramos que um software
relacionado à como organizar as linhas de código. Muitas
possui a complexidade crescente.
vezes sabemos quais linhas de código atenderão um de-
6 – O que significa dizer que um conjunto de classes de terminado requisito de negócio, porém ainda precisamos
um projeto de software está fechado para altera- saber qual a melhor organização das linhas de código que
ção e aberto para extensão? evitará a degradação da aplicação. O uso de padrões ar-
quiteturais pode ser um dos direcionadores desta orga-
nização. Um único padrão pode auxiliar na solução das
Capítulo 2 – Padrões de Arquitetura de necessidades ligadas à organização do código ou pode-se
Software usar uma combinação destes padrões.
Caro aluno, neste capítulo descreveremos os Vale lembrar que o conceito de padrões arquiteturais
padrões arquiteturais e exemplos de aplicação diferencia-se de padrões de projetos e ambos são assun-
serão apresentados, bem como os benefícios da tos tratados neste material de ensino.
sua utilização em diferentes casos.
Definição de Padrão Arquitetural
Caro aluno, um padrão arquitetural determina a estru- Arquitetura de software é um conjunto de

decisões significativas sobre a organização de um
tura de um projeto de software. Portanto, se trata de um
sistema, a seleção dos elementos estruturais e das
conceito amplo que aborda questões como limitação de
suas interfaces, junto ao seu comportamento espe-
hardware, alta disponibilidade de uso e risco de negócio
cificado nas colaborações entre esses elementos, a
[BUSCHMANN et al, 1996]. Como sabemos, o desenvolvi-
composição desses elementos estruturais e com-
mento de algoritmos visa resolver problemas com o auxílio
portamentais em subsistemas mais abrangentes,
do computador. Já houve uma época em que os programa-
e o estilo arquitetural que guia essa organização
dores tinham muita dificuldade com a escrita e compilação
– esses elementos e suas interfaces, suas colabora-
do código. Esta dificuldade já foi superada com a ajuda
ções e sua composição. [BOOCH et al., 1999]
de ferramentas que auxiliam o programador na sintaxe e
semântica das linguagens de programação.
16
De uma maneira mais simplificada, Pressman (2010) define arquitetura de software como “estrutura do sistema que
abrange os componentes de software, as propriedades externamente visíveis destes componentes e as relações entre
eles”.
As seções a seguir descrevem os principais padrões arquiteturais, suas vantagens e desvantagens. Vale lembrar que
existem muitos outros padrões possíveis, simples ou compostos, mas vamos nos ater aos mais utilizados nesta abor-
dagem.
Padrão de Arquitetura em Camadas

De acordo com Buschmann (1996), camadas são grupos de componentes reutilizáveis, similares e inter-relacionados,
responsáveis por um nível de abstração particular, ou seja, as camadas executam tarefas específicas da aplicação
consumindo e fornecendo recursos entre si.
• Objetivo
Este padrão tem por objetivo decompor a aplicação em módulos reutilizáveis, organizados por funcionalidades espe-
cíficas, como por exemplo, acesso a dados, lógica de negócio, construção da interface etc.
• Contexto
São mais utilizados em sistemas grandes e complexos que necessitam de decomposição, pois frequentemente são
compostos por operações de baixo e alto nível. Deste modo, o agrupamento de tarefas comuns aumenta a escalabilida-
de e facilita a manutenção de camadas distintas.
• Estrutura
Cada camada pode ser definida pela sua função e pelos vínculos que ela mantém com as outras camadas da apli-
cação. A estrutura desta arquitetura pode ser dividida em N-camadas, de acordo com a necessidade da aplicação. No
entanto, o padrão mais utilizado é o de 3 camadas: interface com o usuário, lógica de negócio e acesso a dados. A figura
13 ilustra este modelo.
Figura 13: Modelo de arquitetura em 3 camadas
17
• Aplicabilidade
Caro aluno, o padrão de arquitetura em camadas deve ser utilizado quando:
• Tarefas similares podem ser agrupadas para facilitar a manutenção;
• A manutenção de um componente não deve afetar os outros;
• As partes do sistema podem ser substituídas de modo independente;
• Há a possibilidade de utilizar recursos do sistema atual em projetos futuros;
• Componentes complexos precisam ser decompostos;
• O limite entre os componentes é bem definido.
• Consequências
Vantagens:
• Boa reusabilidade devido ao encapsulamento;
• Suporte à padronização com a criação de frameworks;
• As dependências são restritas à camada;
• Recursos intercambiáveis entre aplicações distintas.
Desvantagens:
• Queda de desempenho proporcional ao número de camadas;
• Alterações de comportamento podem provocar efeito cascata e causar gargalos.
• Exemplo de aplicação
Considere o seguinte cenário: uma empresa possui diversas bases de dados alimentadas de modo independente e
deseja fornecer informações processadas por uma única regra de negócio para diferentes plataformas de acesso.
Neste caso a arquitetura em 3 camadas pode ser implementada permitindo o desenvolvimento de componentes espe-
cíficos para bases distintas, interfaces adequadas para cada dispositivo e uma regra de negócios centralizada e comparti-
lhada, conforme ilustrado na figura 14.
18
Figura 14: Arquitetura em camadas para o exemplo de múltiplas bases e múltiplas plataformas.
Padrão de Arquitetura Pipes and Filters ou Pipeline

Caro aluno, o padrão arquitetural Pipes and Filters, também denominado Pipeline, permite um processamento
sequencial através de etapas encapsuladas em componentes chamados Filters que, por sua vez, são acoplados por meio
de conexões conhecidas como Pipes. [BUSCHMANN, 1996] A figura 15 ilustra este padrão.
Figura 15: Arquitetura Pipes and Filters
19
• Objetivo • Deve ser viável realizar atualizações através de

substituição parcial ou recombinação de Filters.
O padrão tem por objetivo decompor o sistema em
etapas independentes com o propósito de reutilizar esses
módulos separadamente e facilitar a manutenção. • Consequências
Vantagens:
• Contexto
Sistemas que processam sequências de dados e exe- • Reutilização de Filters em aplicações distintas;
cutam a mesma operação várias vezes, podem fazer uso • Flexibilidade através da troca e recombinação de
deste padrão para encapsular tarefas e reutilizá-las como Filters;
etapas independentes na mesma pipeline ou em outras.
• Possibilidade de processamento paralelo.
• Estrutura
Desvantagens:
De acordo com Buschmann (1996), e conforme ilustra-
do na figura 15, a estrutura deste padrão é composta da
• Compartilhamento de estado intricado;
seguinte forma:
• Complexidade no tratamento de erros em casca-
• Filters: são componentes responsáveis por trans- ta;
formar dados de entrada. O processamento de
• Perda de desempenho no processamento dos da-
um filter deve depender apenas desses dados, a
dos em sequencias com muitas etapas.
fim de permitir sua utilização no desenvolvimento
de outros sistemas;
• Pipes: são as conexões entre Filters, e são res-
ponsáveis pela transferência de dados e pela sin- Considere o seguinte cenário: um banco realiza diversas
cronização entre os componentes acoplados; transações financeiras através do processamento de arqui-
vos texto padronizados. Cada transação possui uma confi-
• Data Source: fonte de dados sequenciais padro-
guração específica para os dados de entrada. No entanto,
nizados;
várias operações são comuns em transações distintas.
• Data Sink: processo responsável por coletar o re-
sultado final da sequência de processamento rea- Neste exemplo, toda entrada de dados será realizada
lizada pelos Filters. através de arquivos texto, portanto, podemos utilizar um
único componente para “Leitura de Arquivos”. Contudo, as
regras de negócio para cada transação são independentes
• Aplicabilidade
e devem ser empregados componentes específicos confor-
Caro aluno, o padrão Pipes and Filters pode ser aplicado me a necessidade.
nas seguintes condições:
Em uma etapa seguinte todas as transações geram re-
• Dados de entrada e saída padronizados; latórios através de outro componente compartilhado. Por
fim, o componente de “Leitura de Arquivos” é utilizado
• Necessidade de processar dados sequenciais;
novamente para processar o conteúdo dos relatórios e dis-
• Etapas paralelas não devem compartilhar infor- ponibilizá-lo ao Data Sink. A figura 16 ilustra este exemplo.
mação;
20
Figura 16: Arquitetura Pipes e Filters para transação financeira com múltiplas entradas e processos compartilhados.
Acesse o link e saiba mais sobre o padrão arquitetural Pipes and Filters.
http://elemarjr.net/2011/03/22/architectural-patterns-pipes-and-filters/
Padrão de Arquitetura Blackboard

Caro aluno, o padrão Blackboard é utilizado para tratar problemas não determinísticos, como por exemplo, sistemas
de Inteligência Artificial e Reconhecimento de Padrões. Neste padrão arquitetural, de acordo com Buschmann (1996),
diversos subsistemas unem seus conhecimentos para gerar uma possível solução parcial ou aproximada.
Algoritmo determinista: o resultado de cada operação é definido de forma única.

Algoritmo não-determinista: capaz de escolher uma dentre as várias alternativas possíveis a cada
passo. Algoritmos não-deterministas contém operações cujo resultado não é unicamente definido, ainda
que limitado a um conjunto especificado de possibilidades.
• Objetivo
O objetivo do padrão arquitetural Blackboard, é dividir um problema não determinístico entre subsistemas especia-
lizados para solucionar o objetivo de modo cooperativo.
21
• Contexto • Consequências
Este padrão pode ser aplicado em domínios imaturos Vantagens:

ou complexos, compostos por diversos fatores sem solu-
• Em domínios imaturos há a possibilidade de expe-
ção algorítmica conhecida ou viável.
rimentar diferentes algoritmos para mesma subta-
refa sem afetar as demais;
• Estrutura
• Algoritmos disjuntos induzem a aplicação de pa-
Este padrão é composto pelos seguintes itens: ralelismo potencial, ou seja, as fontes de conheci-
mento podem ser exploradas em paralelo, porém,
• Blackboard: central de armazenamento de dados; o acesso a central de dados deve ser sincronizado
as possíveis soluções e os dados de controle são e compartilhado;
armazenados aqui.
• Torna possível a experimentação com algoritmos
• Fontes de conhecimento: subsistemas indepen- distintos e também permite que diferentes heurís-
dentes que resolvem aspectos específicos do pro- ticas de controle sejam empregadas;
blema. Nenhum deles pode resolver a tarefa do
sistema sozinho, uma solução global só pode ser • Suporta mutabilidade e manutenção, porque as
construída através da integração dos resultados fontes de conhecimento, a central de controle e
de várias fontes de conhecimento. a estrutura de dados central são rigorosamente

separadas;
• Central de controle: Monitora as alterações no
Blackboard, coordena as funções das Fontes de • As fontes de conhecimento independentes são es-
Conhecimento e decide a tomada de ações de pecializadas em tarefas específicas e podem ser
acordo com a estratégia da aplicação. A estratégia reutilizadas em outras aplicações;
é definida de acordo com as informações obtidas • Tolerância a falhas e conclusões duvidosas.

sobre o domínio.
Desvantagens:
• Aplicabilidade
Caro aluno, o padrão Blackboard pode ser aplicado nas • Testes complexos, devido à dificuldade de repro-
seguintes condições: duzir resultados não determinísticos;
• Não há garantia de uma solução ótima;

• O problema possui dados incertos e admite solu-
ções aproximadas; • Dificuldade para estabelecer uma boa estratégia
de controle;
• A pesquisa completa do espaço de soluções possí-
veis não é viável em um tempo razoável; • Baixo desempenho computacional;
• O problema global pode ser resolvido através de • Grande esforço no processo de desenvolvimento;
soluções parciais, seguindo a abordagem “dividir
• Não suporta paralelismo integral;
para conquistar”;
• Os dados de entrada e saída, parcial ou global,

têm representações distintas e os algoritmos de-
vem ser implementados de acordo com paradig- Considere o seguinte cenário: uma aplicação de reco-
mas específicos. nhecimento de voz deve interpretar comandos, reconhecer
22
o usuário e executar ações. Neste contexto são empregados agentes distintos com as seguintes funções: interpretação
de palavras isoladas; interpretação de comandos compostos como frases; reconhecimento de sinal de voz.
Este problema pode ser modelado da seguinte forma: um codificador repassa o sinal para um agente de reco-
nhecimento, que por sua vez, verifica as permissões de acesso para o usuário. Caso o acesso seja liberado, o sinal é
encaminhado para o interpretador de palavras, que transforma o sinal em texto e envia o conjunto de palavras para a
verificação de comandos compostos. Nesta etapa um agente verifica se o padrão formado pelo conjunto de palavras
extraídas do sinal é compatível com algum comando armazenado na estrutura de dados central. Esta sequência de
controle pode ser induzida através de heurística ou inferida com o auxílio de algoritmos de aprendizado. A figura 17
ilustra este exemplo.
Figura 17: Arquitetura Blackboard para reconhecimento de comandos de voz.
Model-View-Controller (MVC)
O padrão MVC é um modelo de camadas específico que divide a aplicação em três componentes:
• o Model, ou Modelo, que contém as funções básicas e o acesso aos dados;
• a View, ou visualizador, que exibe os dados para o usuário; e
23
• o Controller, ou controlador, que gerencia a inte- • Control: interpreta eventos de entrada e envia re-
ração entre as entradas do usuário e os dados do quisições para o modelo de dados. Em seguida,
sistema. processa os dados carregados a partir do modelo
e envia para o visualizador.
• Aplicabilidade
Caro aluno, o padrão MVC é muito flexível e pode ser

aplicado em diversas situações. Como, por exemplo, nos
casos em que:
• O projeto da interface deve ser desenvolvido se-

paradamente;
• A mesma informação deve ser exibida em formas

diferentes;
• A interface e o comportamento da aplicação de-

vem refletir os dados do modelo em tempo real;
• Alterações de interface devem ser simples e per-

• Objetivo
mitir mudanças em tempo real;
O objetivo do padrão MVC é garantir a coerência entre
a interface do usuário e o modelo de dados da aplicação. • Haja necessidade de implementar um mecanismo
de propagação de mudança para manter a coe-
rência entre o modelo e a interface;
• Contexto
As aplicações interativas com uma interface homem- • Seja necessário suportar diferentes plataformas
-computador flexíveis, podem fazer uso deste padrão ar- sem a necessidade de alterar a base da aplicação.
quitetural.
• Consequências
• Estrutura
Este padrão é composto da seguinte forma, de acordo

Vantagens:
com Buschmann (1996):
• Múltiplas interfaces para o mesmo modelo;

• Model: encapsula o acesso aos dados e funções
• Mecanismo de propagação de alteração entre o
básicas da aplicação, fornecendo ao usuário pro-
modelo e a interface;
cedimentos que executam tarefas específicas;
• Interfaces e controladores intercambiáveis em
• View: exibe para o usuário os dados fornecidos
tempo real;
pelo controle e estabelece uma interface para in-
teração entre o usuário e a aplicação; • Criação de um possível Framework.
24
Desvantagens:
• Aumento de complexidade;
• Propagação de atualizações excessiva;
• Alta dependência entre interface e controlador:
• Interfaces e controladores podem ser altamente dependentes do modelo;
• Interfaces e controladores podem ser altamente dependentes da plataforma;
• Ineficiência de acesso a dados através de interfaces com múltiplas requisições.
Considere um sistema de gerenciamento que atende todos os departamentos de uma determinada empresa, da
produção até a presidência. Vários funcionários fornecem e consomem informações simultaneamente através de plata-
formas e dispositivos distintos, como computadores, celulares e tablets. Porém, para cada setor as informações devem
ser visualizadas da forma mais conveniente. Ou seja, os operadores têm acesso a informações específicas do seu tra-
balho, os gestores controlam planilhas detalhadas da sua equipe e a diretoria visualiza apenas os balancetes. A figura
18 ilustra esta situação.
Figura 18: Arquitetura MVC aplicada à modelagem de um sistema de gerenciamento com base compartilhada e visualização personalizada.
25
ao sistema podem utilizar as funcionalidades forne-

cidas pelo Microkernel.
Acesse o link e veja um simples exemplo de • Servidores internos: componentes adicionais que
implementação em Java. estendem as funcionalidades do Microkernel. Ser-
http://www.dsc.ufcg.edu.br/~jacques/cur- vidores internos podem, portanto, encapsular al-
sos/map/html/arqu/mvc/mvc.htm gumas dependências no hardware subjacente ou
sistema de software.
Para ver um exemplo em C# acesse:
• Servidores externos: componentes que utilizam
http://www.macoratti.net/10/07/asp_mvc1. os recursos do Microkernel para executar suas
htm próprias interfaces.
• Clientes: aplicativos associados a um servidor ex-

terno. Eles só acessam os recursos disponibiliza-
Padrão de Arquitetura dos pelo servidor.
Microkernel • Adaptadores: proporcionam uma interface entre
clientes e servidores externos, permitindo que os
O padrão arquitetural Microkernel se aplica a sistemas clientes acessem os serviços fornecidos indepen-
de software que devem ser capazes de se adaptar às ne- dentemente da plataforma.
cessidades de mudança do sistema. Ele separa um núcleo
funcional mínimo de recursos estendidos e partes específi-
cas. Este padrão também serve como um gerenciador para
conectar essas extensões e coordenar a sua colaboração.
[BUSCHMANN, 1996]
• Objetivo
O padrão Microkernel visa permitir o desenvolvimento

de várias aplicações que utilizam interfaces de programa-
ção semelhantes e que compartilham as mesmas funcio-
nalidades.
• Contexto
Aplicações baseadas em módulos independentes po-

• Aplicabilidade
dem utilizar o padrão Microkernel para gerenciais recursos
adicionais. Caro aluno, o padrão Microkernel pode ser aplicado nos
seguintes casos:
• Estrutura
• A aplicação deve suportar módulos diferentes em
A estrutura deste padrão é composta da seguinte forma:
uma única plataforma;
• Microkernel: é o principal componente deste padrão. • Os módulos podem ser categorizados em grupos
Ele implementa serviços centrais como comunicação que usam o mesmo núcleo funcional de diferentes
e gerenciamento de recursos. Os módulos acoplados maneiras;
26
• A plataforma de aplicações deve lidar com o hardware e contínua evolução do software;
• A plataforma de aplicação deve ser portável, extensível e adaptável para permitir uma fácil integração de tec-
nologias emergentes;
• O núcleo funcional da aplicação deve ser separado em um componente com tamanho mínimo, e os módulos
devem ser adicionados conforme a necessidade.
• Consequências
Vantagens:
• Portabilidade: na maioria dos casos apenas o Microkernel precisa ser reescrito e alterações de hardware deman-
dam modificações apenas em suas dependências específicas;
• Flexibilidade e extensão: uma das maiores vantagens desta arquitetura é a capacidade de extensão e adapta-
ção do sistema através da inclusão de novos módulos sem a necessidade de alterações no núcleo;
• Separação de mecanismos e políticas: o Microkernel controla apenas os mecanismos básicos e permite que os
módulos implementem suas políticas específicas;
• Escalabilidade: altamente adaptável em sistemas distribuídos;
• Confiabilidade: a tolerância a erros pode ser facilmente suportada porque os sistemas distribuídos permitem
que se ocultem as falhas de um usuário;
• Transparência: em sistemas distribuídos a arquitetura Microkernel permite que cada componente acesse outros
serviços sem a necessidade de saber a sua localização.
Desvantagens:
• Desempenho: softwares monolíticos com foco específico são mais eficientes que a arquitetura Microkernel;
• Complexidade de concepção e implementação: a separação entre mecanismos e políticas requer um profundo

conhecimento de domínio e um esforço considerável durante a análise de requisitos. Além de exigir uma espe-
cificação meticulosa dos recursos disponibilizados pelo Microkernel.
Suponha que você pretende desenvolver um novo sistema operacional para celulares que deverá atender os seguintes
requisitos: fácil portabilidade para qualquer aparelho, integração simplificada de novas aplicações e possibilidade de
executar aplicativos de outros sistemas similares.
27
Figura 19: Arquitetura Microkernel aplicada ao projeto de um sistema operacional
Neste caso você deverá implementar uma estrutura elementar mínima que permita a expansão dos recursos com a
inclusão de módulos. A execução de aplicativos externos poderá ocorrer através de adaptadores ou emuladores, que
tenham acesso aos recursos do núcleo principal do sistema operacional. A figura 19, ilustra a estrutura deste exemplo.
Acesse o link (em inglês) e veja um simples exemplo de implementação em Java.

http://www.vico.org/pages/PatronsDisseny/Pattern%20MicroKernel/
Leia o artigo de Elemar Jr Architectural Patterns: Microkernel, publicado em 17/03/2011 em

http://elemarjr.net/2011/03/17/architectural-patterns-microkernel/
28
Padrão de Arquitetura • Necessidade de minimizar os efeitos colaterais de

alterações invasivas.
Reflection • Consequências

O padrão Reflection fornece um mecanismo para alte- Vantagens:
rar a estrutura e o comportamento de sistemas de forma
dinâmica. Neste padrão a arquitetura é divida em duas • Não há alterações explícitas no código fonte;
partes. Um nível meta, que provê informações sobre as
propriedades do sistema. E um nível base que inclui a ló- • Alterações no sistema são simplificadas por parâ-
gica da aplicação. Alterações realizadas em informações metros;
contidas no nível meta afetam o comportamento do nível
base. [BUSCHMANN, 1996]. • Suporte para vários tipos de alterações parame-
trizadas.
• Objetivo
Desvantagens:
O padrão Reflection visa à criação de sistemas que
suportem a sua própria modificação sem a necessidade de
alterar a estrutura lógica da aplicação. • Modificações incorretas nos parâmetros do nível
Meta podem causar falhas;
• Contexto
• Aumento do número de componentes proporcio-
Sistemas que dependem de adaptações frequentes po-
nal à quantidade de parâmetros utilizados no nível
dem implementar este padrão arquitetural para facilitar o
Meta;
processo de modificação.
• Baixa eficiência causada pela interpretação dos
• Estrutura parâmetros em tempo de execução;
Este padrão é composto pelos seguintes itens:

• Nem todas as alterações são suportadas por pa-
• Nível Base: implementa a lógica da aplicação. Seus râmetros;
componentes representam os serviços fornecidos
• Nem todas as linguagens de programação supor-
pelo sistema, o modelo de dados e a interface de
tam esta arquitetura.
usuário. E também específica a comunicação en-
tre estas estruturas.
• Nível Meta: é composto por um conjunto de ob-
jetos que encapsulam informações específicas Considere uma aplicação que necessita ler páginas
sobre um único aspecto da estrutura, comporta- HTML de um site para armazenar informações contidas
mento ou estado do Nível de Base. entre tags específicas.
• Aplicabilidade O layout desse site, assim como a estrutura das suas

páginas, variam frequentemente demandando alterações
Caro aluno, o padrão Reflection pode ser aplicado nos
constantes na aplicação. Neste caso, é possível definir um
seguintes casos:
nível Meta capaz de parametrizar a extração de informa-
• Adaptações constantes; ções do site permitindo que a aplicação seja adaptada sem
• Possibilidade de alterações parametrizadas; alterações específicas no código fonte.
29
A figura 20 ilustra este exemplo para a arquitetura Reflection.
Figura 20: Arquitetura Reflection aplicada ao projeto de um sistema para extração de informações em websites com estrutura volátil.
Acesse o link http://www.guj.com.br/articles/10 e veja um exemplo de implementação em Java.

Para ver um exemplo Asp.Net em C# acesse: http://www.linhadecodigo.com.br/artigo/1518/entendendo-
-o-reflectionaspnet_csharp.aspx
1 - Qual arquitetura deve ser aplicada em problemas não-determinísticos e por quê?
2 - Assinale V (Verdadeiro) ou F (Falso), nas afirmativas abaixo:

( ) A arquitetura em camadas é limitada a três níveis
( ) MVC é uma arquitetura em camadas com níveis específicos
( ) No padrão Pipers and Filters, os Filters não são reutilizáveis
( ) O modelo Microkernel é simples de conceber e implementar;
( ) No padrão Reflection qualquer alteração pode ser realizada através do nível Meta
3 - Cite um objetivo comum a todas as arquiteturas apresentadas neste capítulo e compare os exemplos.
30
Os 9 padrões que compõem o GRASP são: creator (cria-

Capítulo 3 – Design Patterns – Padrões
dor); information expert (especialista); low coupling (bai-
de Criação xo acoplamento); controller (controlador); high cohesion
Caro aluno, neste capítulo definiremos o que é (alta coesão); polymorphism (polimorfismo); pure fabri-
um padrão de projeto, quais são os padrões ado- cation (pura invenção); indirection (indireção); protected
tados pela comunidade de desenvolvedores e como variations (variações protegidas).
eles são classificados.
Os padrões de projeto descrevem os princípios fun-
Depois definiremos o que são padrões de criação damentais da atribuição de responsabilidades a objetos
e apresentaremos os principais padrões de criação, (como vimos no capítulo 1).
bem como exemplos de uso.
Esses padrões exploram os princípios fundamentais de
Conceitos de Padrões de Projeto sistemas OO. Embora a adoção de padrões não seja trivial
para um programador iniciante, atualmente este conceito
tem sido adotado pela comunidade de desenvolvedores e
cada vez mais exigido por líderes nas fábricas de software.
Como visto anteriormente, um código fonte de um pro-

grama pode degradar-se ao longo de sua vida. Por prin-
cípio, os padrões buscam isolar as partes do código que
são estáveis daquelas que são/serão mais suscetíveis a
mudanças.
Fonte:http://www.selectorweb.com/design_patterns.html
O resultado que se espera é ter aplicações nas quais
seja mais fácil se efetuar procedimentos de manuten-
Os primeiros registros de design patterns ou padrões de
ção, cujo código seja mais facilmente compreendido pela
projeto foram publicados por Erich Gamma, Richard Helm,
equipe do projeto e que favoreçam o reuso de código,
Ralph Johnson, John Vlissides em 1994 no livro Design
aumentado seu tempo de vida e postergando o início da
Patterns: elements of reusable object-oriented software.
degradação.
Estes padrões ficaram conhecidos como padrões GoF -

Gang of Four, em referência aos 4 autores. Os Design Patterns são uma coleção de padrões de pro-
jeto de software, que oferecem soluções para problemas
Além dos padrões GoF, há diversos outros padrões de conhecidos e recorrentes no desenvolvimento de software.
projeto. Craig Larman, em 2004, no seu livro “Applying
UML and Patterns” reuniu um conjunto de padrões sob o Um pattern descreve uma solução comprovada para
acrônimo GRASP- General Responsibility Assignment Sof- um problema recorrente, dando ênfase ao contexto em
tware Patterns (Padrões de Software para Atribuição de que o problema ocorre e mostrando as consequências e o
Responsabilidade Geral), que funcionam como um guia no impacto de sua solução.
desenvolvimento orientado a objetos apoiando a organiza-
ção por responsabilidades. Assim, os patterns são dispositivos que permitem que
os programadores compartilhem conhecimento sobre o
O GRASP reúne 9 padrões relevantes para o desenvol- seu projeto. Como desenvolvedores, sabemos que quando
vimento de sistemas OO dirigidos por responsabilidades. programamos, encontramos muitos problemas que ocor-
31
rem, ocorreram e irão ocorrer novamente. A pergunta que sempre fazemos é: “como vamos solucionar este problema
desta vez?”.
Documentar um padrão é uma maneira de podermos reusar e possivelmente compartilhar uma informação que
aprendemos em relação à melhor maneira de se resolver um determinado problema de software.
As vantagens de se utilizar design patterns são muitas e incluem as seguintes:
• Os padrões já foram provados e refletem a experiência, o conhecimento e as soluções dos desenvolvedores que
tiveram sucesso usando-os em seus trabalhos.
• Os padrões são reusáveis e provêem uma solução pronta que pode ser aplicada a diferentes problemas.
• Os padrões provêem um vocabulário comum que pode expressar muitas soluções, de forma sucinta e objetiva.

Mas é importante lembrar que os padrões, por si só, não garantem o sucesso do seu uso. A descrição do padrão indi-
ca quando ele pode ser aplicado, mas apenas a experiência pode determinar quando um padrão particular irá melhorar
o projeto do sistema.
O principal objetivo de um Design Pattern é criar uma abstração de um problema recorrente e apresentar uma
solução viável, além de poder compartilhar este conhecimento para que outras pessoas se beneficiem dele. Assim, a
documentação de um Design Pattern deve ser feita de uma forma muito bem definida. De uma maneira geral, a docu-
mentação de um padrão inclui a definição dos seguintes itens:
• Objetivos ou pré-requisitos que devem ser satisfeitos antes de se decidir aplicar um padrão;
• A motivação ou o contexto em que o padrão se aplica;
• Uma descrição da estrutura do programa em que o padrão será definido;
• Consequências do uso do padrão, positivas e negativas;
• Exemplos de uso e aplicação do padrã
A figura 21 apresenta o Mapa de Padrões de Projetos proposto pela Gang of Four (GoF). Parte destes padrões será
abordada nesta disciplina.
32
Figura 21: Mapa de padrões de projetos GoF

Fonte: http://knol.google.com/k/padr%C3%B5es-de-software#
33
O catálogo de padrões do GoF contém 23 padrões e está, basicamente, dividido em três seções:
• Creational (Padrões de Criação)
• Structural (Padrões Estruturais)
• Behavioral (Padrões Comportamentais)
Os padrões de projeto do GoF são soluções para problemas recorrentes no desenvolvimento de sistemas de software
orientado a objetos. A figura 22 mostra a divisão destes padrões, no contexto da programação orientada a objetos.
Os padrões de criação se referem à instanciação de objetos, os estruturais estão ligados com a composição de
classes ou objetos e os comportamentais procuram caracterizar formas de interação entre classes e objetos. Um padrão
GoF também é classificado segundo o seu escopo em 2 outros grupos:
• Padrões com escopo de classe : definido por relacionamentos de herança e em tempo de compilação.
• Padrões com escopo de objeto : encontrados no relacionamento entre os objetos definidos em tempo de exe-
cução.
Figura 22: Divisão dos padrões GoF

Fonte: http://www.linhadecodigo.com.br/artigo/2573/desing-patterns-na-pratica---desvendando-misterios-parte-1.aspx
Neste capítulo trataremos dos padrões de criação e nos capítulos seguintes apresentaremos os padrões estruturais
e os comportamentais.
Mas, antes de prosseguirmos, um pouco de humor...
34
Ainda para manter o bom humor, leia sobre “Princípios Comuns de Design”
Disponível em: http://www.princiweb.com.br/blog/programacao/o-que-sao-design-patterns/
“Há diversos princípios comuns de design, que, assim como os design patterns, se tornaram boas práticas
através dos anos e ajudaram que software de fácil manutenção pudessem ser construídos. Abaixo, segue um
resumo dos princípios mais conhecidos:
Keep It Simple Stupid (KISS)
Mantenha Isto Estupidamente Simples
Um problema comum em programação de software é a necessidade de complicar demais a solução. O objetivo

do princípio KISS é manter o código simples, mas não simplista, assim evitando complexidade desnecessária.
Don’t Repeat Yourself (DRY)
Não Repita Você Mesmo
35
O princípio do DRY é evitar a repetição de qualquer parte do sistema abstraindo as coisas que são comuns
entre si e colocá-las em um lugar único. Esse princípio não se preocupa somente com o código, mas qualquer
lógica que está duplicada no sistema.
Tell, Don’t Ask
Fale, não pergunte
O principio Tell, Don’t Ask está estreitamente alinhado com o encapsulamento e a atribuição de responsabilida-
des para as suas classes corretas. O princípio afirma que você deve dizer aos objetos quais ações você quer que
eles realizem, ao invés de fazer perguntas sobre o estado do objeto e então tomar uma decisão por si próprio em
cima da ação que você quer realizar. Isso ajuda a alinhar as responsabilidades e evitar o forte acoplamento entre
as classes.
You Ain’t Gonna Need It (YAGNI)
Você Não Vai precisar Disso
O princípio YAGNI se refere à necessidade de adicionar somente as funcionalidades que são necessárias para
a aplicação e deixar de lado qualquer tentação de adicionar outras funcionalidades que você acha que precisa. “
Definição de Padrões de Criação
Fonte: http://jutalala.wordpress.com/2011/07/17/e-nisso-que-da-competir-com-o-deus-da-criacao/
Caro aluno, padrões de criação auxiliam na concepção de sistemas independentes do modo como os objetos são
gerados, compostos e representados. Este tipo de padrão abstrai o processo de instanciação, alterando a classe instan-
ciada através e herança. [GAMMA, 1995]
36
Assim, os padrões de criação concentram-se na composição de objetos complexos e no encapsulamento do com-

portamento de criação. Dessa forma, pretende-se evitar código embutido definindo pequenos grupos de características
fundamentais capazes de compor estruturas mais complexas.
Os padrões de criação podem ser competitivos ou cooperativos. Algumas técnicas se complementam enquanto outras
executam funções similares de formas distintas. As cinco abordagens presentes no modelo GoF serão apresentadas a seguir.
Padrão Abstract Factory

• Objetivo
Fonte: http://justintarte.blogspot.com/2010/07/if-you-have-ever-walked-into-factory.html
De acordo com Gamma (1995), o objetivo do padrão Abstract Factory é fornecer uma interface para criar grupos de
objetos relacionados aos dependentes sem especificar suas classes concretas.
• Contexto
Produtos portáveis utilizam o conceito abstrato deste padrão para desvincular código fundamental da aplicação
de recursos que são dependentes da plataforma.
• Estrutura
Este padrão é composto pelos seguintes elementos:
• AbstractFactory: declara uma interface para operações que criam objetos abstratos;
• ConcreteFactory: implementa operações específicas para criar objetos concretos;
• AbstractProduct: declara uma interface para cada tipo de objeto;
• ConcreteProduct: implementa uma interface de AbstractProduct para definir um objeto que pode ser criado por sua
ConcreteFactory correspondente;
• Client: utiliza as interfaces declaradas pelo AbstractFactory e AbstractProduct, sem se preocupar com as implemen-
tações concretas.
37
• Aplicabilidade
O padrão Abstract Factory pode ser empregado nos

seguintes casos:
• Um sistema deve ser independente do modo

como seus objetos são criados, compostos e re-
Fonte:http://www.opencs.com.br/site/index.
presentados;
php?page=caracteristicas-tecnicas-m-trusted
• Um sistema deve ser configurado com vários grupos
distintos de objetos;
• Alguns objetos relacionados foram projetados para Padrão Builder
serem utilizados em conjunto, e você precisa impor
essa restrição;
• Você quer fornecer uma biblioteca de classes e pre-
tende revelar apenas suas interfaces, não suas im-
plementações.
• Consequências
Vantagens:
• Isola as classes concretas e ajuda a controlar as

Fonte: http://houstonagentmagazine.com/builder-
classes de objetos que um aplicativo cria. confidence-posts-highest-monthly-gain-in-19-months/
• Torna fácil a troca de implementações específicas,

pois a classe ConcreteFactory aparece apenas
• Objetivo
onde é instanciada na aplicação;
O objetivo do padrão Builder é separar a construção de
• Promove a consistência entre produtos, pois faci-
um objeto complexo da sua representação, de modo que
lita a implementação de objetos que foram proje-
o mesmo processo de construção possa criar diferentes
tados para trabalhar juntos.
representações. [GAMMA, 1995]
Desvantagens:
• Contexto
• Alta complexidade para suportar novos produtos. Sistemas capazes de gerar ações indeterminadas
Este processo requer alteração do Abstract Fac- para uma única aplicação, utilizam a estrutura modular
tory e todas as subclasses. deste padrão para permitir a implementação de soluções
alternativas que utilizem recursos oriundos de uma fonte
única.
Considere um sistema de diagnóstico para telefones
celulares. Os componentes principais executam funções si- • Estrutura
milares, no entanto, cada fabricante emprega sua própria
arquitetura de hardware e software. Neste caso, é possível Este padrão é composto pelos seguintes elementos:
desenvolver uma biblioteca abstrata genérica e implemen- • Builder: especifica uma interface abstrata para a
tar classes concretas adequadas para cada aparelho. criação de módulos do sistema;
38
• Concretebuilder: cria e executa módulos através da interface do Builder; controla a representação criada e
fornece um meio para obtenção dos resultados;
• Director: constrói o objeto principal utilizando a interface do Builder;
• Product: representa um módulo alternativo que inclui interfaces para geração do resultado final.
• Aplicabilidade
Este padrão pode ser empregado nas seguintes situações:
• O algoritmo para a criação de um objeto complexo deve ser independente dos módulos que compõem o sis-
tema e como eles são montados;
• O processo de construção deve permitir diferentes representações para o objeto construído.
• Consequências
Vantagens:
• Permite variar o resultado gerado por um sistema. Como o sistema é construído através de uma interface abs-
trata, tudo que você precisa fazer para mudar a representação interna é definir um novo tipo de construtor;
• Isola o código para a construção e representação. O padrão Builder melhora a modularidade, encapsulando a
maneira como um objeto complexo é construído e representado;
• Proporciona um melhor controle sobre o processo de criação de objetos, pois carrega o sistema passo a passo
sob o controle do Director.
Desvantagens:
• Pelo fato de ser um padrão bastante flexível, pode resultar no uso redundante e mal planejado, impactando
no entendimento do código gerado.
Considere um sistema para tratamento de imagens. Atualmente existem diversos recursos e todos os anos surgem
novos algoritmos que fornecem funções inovadoras.
No entanto, o conceito fundamental dessas ferramentas é único: uma imagem original é fornecida e uma imagem
tratada é obtida no final do processo. Portanto, a base do sistema precisa implementar apenas essas funções e a cada
novo algoritmo que surge um novo módulo deve ser desenvolvido com suas características específicas.
39
Fonte: http://www.ibm.com/developerworks/br/library/os-datavis2/index.html
Padrão Factory Method

• Objetivo
De acordo com Gamma (1995), o objetivo do padrão Factory Method é definir uma interface para criação de objeto
que permita que as subclasses decidam qual classe será instanciada.
• Contexto
Sistemas que manipulam um número variável de tipos de objetos podem utilizar este modelo devido à sua flexibili-
dade. O Factory Method permite que a aplicação final implemente o suporte aos objetos necessários.
• Estrutura
O padrão Factory Method é composto pelos seguintes elementos:
• Product: define a interface dos objetos criados por este padrão;
• ConcreteProduct: implementa a interface do Product;
• Creator: declara o método que retorna o objeto do tipo esperado;
• ConcreteCreator: sobrescreve o método original para retornar uma instancia do objeto esperado, ou seja o
ConcreteProduct.
40
• Aplicabilidade
Padrão Prototype
Este padrão pode ser usado nas seguintes situações:
• A aplicação não pode antecipar os tipos de obje-

tos que devem ser criados;
• Uma classe espera que suas subclasses especifi-

quem o tipo de objeto a ser criado;
• As classes delegam a responsabilidade a uma das

subclasses e você quer identificar de qual subclas-
se advém o conhecimento.
Fonte:http://allthecars.wordpress.com/2009/07/22/lotus-projeta-
compacto-urbano-movido-a-eletricidade/lotus-city-car-prototipo-04/
• Consequências
Vantagens: • Objetivo
O objetivo do padrão Prototype é especificar o tipo dos

• Provê meios para as subclasses estenderem as
objetos através de uma instância-protótipo e criar novos
funções básicas;
objetos através da cópia dessa instância. [GAMMA, 1995].
• Conecta hierarquias de classes paralelas que com-
partilham o conhecimento da operação. • Contexto
A estrutura deste padrão permite a implementação de

• Exemplo de aplicação variações de uma classe sem o uso de subclasses, através
da criação de instâncias-protótipo com características es-
pecíficas pré-definidas.
• Estrutura
A estrutura deste padrão é composta pelos seguintes

itens:
• Prototype: declara uma interface para autoclona-
gem;
• ConcretePrototype: implementa a operação de

autoclonagen;
Considere uma aplicação que carrega vários tipos de • Client: cria objetos solicitando um clone ao pro-
arquivos distintos. As funções básicas de busca, leitura e tótipo.
gravação são as mesmas em qualquer situação. Contudo,
cada arquivo possui características particulares que são
• Aplicabilidade
definidas por subclasses específicas. Portanto, o aplicativo
não sabe qual classe deve ser instanciada até a subclasse, O padrão Prototype pode ser empregado nas seguintes
associada a um arquivo, informá-lo. situações:
41
• As classes a serem instanciadas são especificadas através da configuração de parâmetros de um clone da

em tempo de execução, por exemplo, por instância-protótipo da classe principal.
carregamento dinâmico;
• Para evitar a construção de hierarquias de classe

Padrão Singleton
paralelas;
• Objetivo
• Quando a instância de uma classe pode ter dife-
O objetivo do padrão Singleton, de acordo com Gamma
rentes estados.
(1995), é garantir que uma classe tenha somente uma ins-
tância e fornecer um ponto global de acesso a ela.
• Consequências
Vantagens:
• Especificar novos objetos através da estrutura,

utilizando composições;
• Reduzir o número de subclasses através da clona-

gem de um protótipo;
• Adição e remoção de tipos de objetos em tem-

po de execução. Protótipos permitem incorporar
uma classe nova em um sistema, simplesmente
copiando um protótipo através do Client;
• Especificar novos objetos através do valor das Fonte:http://www.tecmundo.com.br/hp/6040-novas-impressoras-

da-hp-passam-a-distancia-arquivos-do-celular-para-o-papel.htm
propriedades e não pela definição de subclasses;
• Configurar aplicações com classes dinamicamente • Contexto

carregadas.
Este padrão é ideal para restringir o acesso a recursos
limitados e compartilhados pelo sistema. Como por exem-
Desvantagem: plo: conexão com o banco de dados, acesso à impressora,
alteração de configurações centralizadas etc.
• A principal limitação deste padrão é que as sub-
classes de um protótipo devem implementar a
• Estrutura
operação de clonagem e isso nem sempre é pos-
sível, pois alguns objetos não suportam cópia ou A estrutura deste padrão possui apenas um item deno-
possuem referenciais circulares. minado Singleton, que define uma instância de operações
única que provê acesso aos outros recursos do sistema.
Considere o mesmo exemplo do Factory Method, onde • Aplicabilidade
um sistema deve trabalhar com vários tipos distintos de O padrão Singleton é adequado nos seguintes
arquivos. A diferença é que no modelo Prototype não é casos:
necessário implementar uma nova classe para cada tipo • Deve haver exatamente uma instância de uma
de arquivo suportado pelo sistema. Essa distinção é feita classe acessível de qualquer ponto do sistema;
42
• Quando a instância única deve ser extensível atra- 3 – Leia a situação problema abaixo e indique qual pa-
vés de subclasses e os clientes devem ser capazes drão de projeto pode ser utilizado para resolver o
de usar uma instância estendida sem modificar problema.
seu código.
“A empresa CPI precisa desenvolver um media player
para um grande cliente. O Software faz parte de uma cam-
• Consequências
panha de marketing da empresa que permitirá ao cliente
Vantagens: ouvir músicas em diferentes formatos. Trata-se de um
brinde da empresa que agregará valor aos produtos ven-
• Controlar o acesso à instância única, definindo didos.
quando e como ela poderá ser acessada;
A equipe desenvolvimento não está conseguindo impe-
• Reduz o uso de variáveis globais;
dir que apenas uma música seja tocada.
• Permite refinamento de operações e de represen-
tações, através de classes estendidas; Se o usuário clicar em duas músicas para tocá-las, o
• Permite variar o número de instâncias mantendo media player não interrompe a música anterior, tocando
o controle de acesso; uma música sobreposta pela outra”.
• Mais flexível do que restrições geradas por opera-

ções de classe.
Estruturais
Caro aluno, neste capítulo serão apresenta-
dos os padrões de projetos classificados como
estruturais pelo GoF.
Observe que cada padrão é utilizado com um

determinado propósito. A aplicabilidade e um
exemplo de cada um deles também são apresen-
tados visando um melhor entendimento.
Considere que a sua aplicação tem acesso a um Web-

Service para consulta de endereço através do CEP. Entre- Definição de Padrões Estruturais
tanto, este serviço não permite consultas simultâneas de
um mesmo cliente e o seu sistema possui diversas funções Os padrões estruturais se preocupam com a forma
que realizam esta tarefa. Neste caso, o padrão Singleton como classes e objetos são compostos para formar estru-
pode ser implementado para restringir o acesso e geren- turas maiores. Este tipo de padrão de projeto descreve
ciar o retorno das consultas dentro do sistema. maneiras de compor objetos para obter novas funciona-
lidades.
A flexibilidade obtida pela composição de objetos pro-
1 – Quais benefícios temos em utilizar os Padrões de vém da capacidade de mudar a composição em tempo de
Projetos? execução. Se utilizar o modelo de análise no contexto da
2 – Diferencie os Padrões Estruturais e Comportamen- estrutura da solução, o arquiteto pode começar a definir os
tais. frameworks no contexto dos padrões estruturais.
43
• ClasseExistente: Define uma interface

Padrão Adapter
pré-existente que necessita ser adaptada.
• Aplicabilidade
O padrão Adapter é utilizado quando:
• Deseja-se usar uma classe existente e sua interfa-

ce não está de acordo com o que a aplicação em
desenvolvimento necessita;
• É necessário criar uma classe reutilizável que tra-

balhe de forma cooperativa com classes que não
sabemos qual comportamento deve exibir, ou seja,
classes que podem não ter interfaces compatíveis.
Fonte:http://www.americanas.com.br/produto/7307846/
kit-com-10-adaptadores-para-tomada-padrao-novo-sms
• Consequências
• Objetivo
Vantagens:
O padrão Adapter é usado quando queremos converter
a interface de uma classe em outra interface utilizada • Permite que uma aplicação utilize funcionalidades
por um cliente. Permite que certas classes trabalhem em externas
conjunto, pois de outra forma seria impossível por causa • Uma classe Adapter implementa uma interface
de suas interfaces incompatíveis. conhecida dos clientes e permite acesso a instân-
cias de uma classe não conhecida
• Contexto
• Um objeto Adapter provê a funcionalidade prome-
Este padrão é bastante útil quando precisamos da tida por uma interface sem fixar a classe que de
comunicação entre classes que não poderiam trabalhar fato a implementa
juntas devido à incompatibilidade de suas interfaces.
Precisamos fazer uso de uma biblioteca de classes de

• Estrutura um software comercial e não temos acesso ao código. Po-
demos utilizar um Adapter para servir de interface entre
as classes da biblioteca e do aplicativo que está sendo
itens:
desenvolvido.
• Cliente: Colabora entre os objetos conforme

Padrão Bridge
a interface Alvo.
• Alvo: Define a interface de domínio específi- • Objetivo

co que o Cliente utiliza.
O padrão Bridge é usado para separar uma abstração
• Adapter: Adapta a ClasseExistente para ser da sua implementação de modo que as duas possam ser
utilizada pela classe Alvo. modificadas de forma independente.
44
• Aplicabilidade
Use o padrão de projeto Bridge sempre que:
• Quiser evitar uma ligação permanente entre a in-

terface e a implementação.
• Uma alteração na implementação não puder
afetar clientes.
• Implementações forem compartilhadas entre ob-
Fonte: http://www.ratestogo.com/blog/10-awesome-bridges- jetos desconhecidos do cliente.
around-the-world/
• Consequências
Vantagens:
• Contexto
Caro aluno, vimos na seção 1.5 os princípios conhecidos • Separa interface de implementação;
como SOLID. Estes princípios nos auxiliam a lidar com o
• Melhora as hierarquias de abstração e Implemen-
acoplamento entre os objetos de um sistema o que evita a
tação;
degradação do código, em função das mudanças que ele
• Esconde detalhes de implementação dos clientes.
sofre. O padrão Bridge é uma das formas de desacoplar
objetos do sistema, porém este padrão propõe a separação
dos conceitos de implementações, ou seja, podemos
ter uma classe que representa o conceito de algo e outra
que especifica o código desta classe.
• Estrutura

itens:
Abstração: Define a interface de abstração e mantém

uma referência a um objeto do tipo Implementador.
• AbstracãoRefinada: Estende a interface definida

por Abstração.
Fonte:http://temd.wordpress.com/2009/03/18/a-
• Implementador: Define a interface para classes de historia-da-interface-grafica/
implementação. Esta interface não tem que cor-

responder exatamente à interface de abstração.
Imagine um sistema gráfico de janelas que deve ser
De fato, as duas interfaces podem ser diferentes.
portável para diversas plataformas. Neste sistema são
Tipicamente, a interface de implementação fornece
encontrados diversos tipos de janelas, ícones, caixas de
apenas operações primitivas, cabendo à abstração
diálogos, etc. Estas janelas formam uma hierarquia que
a responsabilidade de definir operações de alto ní-
contém uma abstração das janelas (classe base). Normal-
vel baseadas nestas primitivas.
mente, a portabilidade seria obtida criando-se especiali-
• ImplementadorConcreto: Implementação concreta zações dos tipos de janelas para cada uma das platafor-
da interface definida por um Implementador. mas suportadas. O problema com essa solução reside na
45
complexidade da hierarquia gerada e na dependência de • ComponenteConcreto: define um objeto para o qual

plataforma que existirá nos clientes do sistema. comportamentos adicionais podem ser atribuídos.
• Decorator: mantém uma referência para um obje-

Através do padrão Bridge, a hierarquia que define os tipos
to Componente. Define uma interface que segue
de janelas é separada da hierarquia que contém a implemen-
a interface de Componente.
tação. Desta forma todas as operações de Janela são abstra-
tas e suas implementações são escondidas dos clientes. • DecoratorConcreto1 e DecoratorConcreto2: acres-
centam comportamentos ao componente.
Exemplo extraído de: http://pt.wikipedia.org/wiki/
Bridge_(padr%C3%A3o_de_projeto_de_software)
• Aplicabilidade
Quando desejamos inserir um comportamento adicional

Padrão Decorator
a uma classe, porém em tempo de execução. Por exemplo,
em uma interface gráfica, quando se deseja acrescentar
uma borda a um componente qualquer ou uma barra de
rolagem a uma área de texto. Uma prática utilizando este
padrão seria inserir o componente em outro objeto que
adiciona a borda.
• Consequências
Vantagens:
• O uso do padrão Decorator evita a criação de uma

grande quantidade de subclasses, podendo se
definir classes simples, em que somente o que
• Objetivo é principal será implementado além de se poder
adicionar funcionalidades dinamicamente.
O padrão Decorator permite adicionar e remover res-
ponsabilidades e/ou comportamentos de uma classe em • Exemplo de aplicação
tempo de execução, ou seja, dinamicamente. Para com- Um caso de aplicação do Decorator é quando existem
preendê-lo melhor é necessário sempre raciocinar em ter- muitas variações de um objeto. Um exemplo: uma clas-
mos de objetos. se Janela com uma subclasse JanelaComBorda. Caso haja
a necessidade de janelas com rolagem, tem-se ainda Ja-
• Contexto nelaComRolagem e JanelaComBordaERolagem, dentre ou-
tras combinações.
Utilizamos o Decorator quando queremos adicionar funcio-
nalidades a uma classe em tempo de execução, ou seja, adi-
cionar responsabilidades a um objeto, mas não à sua classe.
• Estrutura

itens:
• Componente: define a interface para objetos que Fonte:http://www.ajustefinoeshop.com.br/
podem ter comportamentos acrescentados a eles produto.php?cod_produto=1190395
dinamicamente.
46
Padrão Façade
• Objetivo
O objetivo do padrão Façade é fornecer uma interface

para um conjunto de interfaces em um subsistema.
Façade define uma interface de nível mais alto que torna
o subsistema mais fácil de ser usado. [GAMMA, 1995]
• Contexto
Alguns sistemas possuem subsistemas complexos. O

padrão Façade fornece uma interface simplificada para
operar os subsistemas.
• Estrutura
A estrutura deste padrão é composta pelos seguintes itens:

Fonte: http://www.sraengenharia.blogspot.com.br/
• Façade: conhece quais classes do subsistema são

responsáveis pelas requisições de um cliente e O padrão Façade pode ser utilizado para simplificar a
delega solicitações aos objetos apropriados dos integração do sistema Casa Segura com seus subsistemas.
subsistemas.
Geralmente um sistema de segurança residencial,
• Classes de subsistema: (ClasseX, ..., ClasseZ) im-
como o Casa Segura, possui câmeras que podem ser aces-
plementam as funcionalidades dos subsistemas.
sadas via internet de qualquer ponto do mundo, além de
controle de acesso através de fechaduras com biometria e
• Aplicabilidade diversos outros equipamentos que podem ser controlados
remotamente pelos moradores. Um sistema que utilizasse
Façades podem ser utilizados não somente para criar
o padrão Façade facilitaria muito a interface com as clas-
uma interface mais simples em termos de chamadas a mé-
ses que controlariam estes dispositivos.
todos, mas também para reduzir o número de objetos com
os quais o objeto cliente deve lidar. [SHALLOWAY, 2004]
Padrão Proxy
• Consequências
• Objetivo
Vantagens:
O padrão Proxy tem como objetivo fornecer um objeto
• Isola os clientes dos componentes do subsistema representante ou um marcador para que outro objeto con-
reduzindo o número de objetos com os quais o trole o acesso a ele.
cliente tem que lidar.
• Contexto
• Promove um acoplamento fraco entre o subsiste-
ma e seus clientes. O acoplamento fraco permite Muitas vezes um aplicativo precisa continuar funcio-
variar os componentes do subsistema sem afetar nando mesmo na ausência de um subsistema, neste caso
os seus clientes. [GAMMA, 1995] o Proxy pode intermediar temporariamente esta relação.
47
• Estrutura neste contexto pode facilitar a interação entre os diferentes

subsistemas garantindo a disponibilidade de funções não
criticas. Um Proxy pode conhecer as funcionalidades de
itens:
objetos reais do sistema, porém na ausência de um deles
• Proxy: mantém uma referência que permite que o
o dispositivo continuará funcionando.
proxy acesse o objeto real. Fornece uma interface
idêntica ao objeto real para os clientes.
• Cliente: quem consome o Proxy “pensando” que

é um objeto real.
Assista ao filme do Youtube sobre a Casa do
• Objeto real: É o objeto real que um Proxy repre- Futuro
senta. http://youtu.be/qRCT3lWyRbs
• Aplicabilidade Exercícios do Capítulo 4
O padrão Proxy é aplicado quando um sistema precisa

1 - Cite dois padrões estruturais que favorecem o
consumir os recursos de um objeto, mas por algum motivo
desacoplamento das classes.
ele não está disponível. A solução então é providenciar
um substituto que possa se comunicar com esse objeto 2 - Compare o padrão Adapter com padrão Façade.
quando ele estiver disponível. O cliente passa a usar o 3 - Cite as vantagens em utilizar o padrão Bridge.
objeto intermediário que possui uma referência a um
4 - Descreva os elementos que fazem parte da es-
objeto real que, quando estiver disponível, recebe as
trutura do padrão Proxy.
informações.
• Consequências
Vantagens:
Comportamentais
• Transparência, pois é utilizada a mesma sintaxe
na comunicação entre o cliente e o objeto real;
Caro aluno, neste capítulo serão apresenta-
• Tratamento inteligente dos dados no cliente dos os padrões de projetos classificados como
comportamentais pelo GoF. Observe que os pa-
• Maior eficiência com caching no cliente.
drões classificados nesta categoria atuam na ins-
tanciação das classes que descrevem o compor-
Desvantagens: tamento de uma aplicação de software.
• Possível impacto na performance

Definição de Padrões Comportamentais
• Fatores externos como queda da rede pode deixar
o Proxy inoperante. Os padrões classificados como comportamentais tratam
da organização das linhas de código que focam nas relações
entre os objetos, a fim de melhorar a comunicação entre
os mesmos. O objetivo é compartilhar um mesmo tipo de
Imagine o projeto da Casa Segura, no qual um conjunto comportamento entre diferentes classes fazendo uso de
de componentes devem se comunicar. O uso do Proxy heranças de interfaces e classes abstratas.
48
• Aplicabilidade
Padrão Chain of Responsability
Gamma (1995) recomenda o uso deste padrão quando:
• Objetivo • Mais de um objeto pode tratar uma solicitação e
este é desconhecido.
Um sistema desenvolvido sob o paradigma orientado a
objetos trabalha com a interação entre os objetos que o • Quando quiser emitir um pedido de um dos vá-
compõem através de mensagens. rios objetos sem especificar o receptor de forma

explícita.
O desenvolvedor do sistema precisa especificar qual o • O conjunto de objetos capaz de tratar da solicita-
objeto que irá tratar uma requisição (mensagem). O pa- ção deve ser especificado dinamicamente.
drão de projeto Chain of Responsability propõe uma parti-
cular maneira de tratar estas requisições.
• Consequências
• Contexto Vantagens:
O padrão Chain of Responsability auxilia na definição de

• Evita acoplamento entre o transmissor de uma re-
responsabilidade e pode ser composto com outros padrões
quisição e seus receptores, fazendo com que mais
de projetos. Desta forma, vários objetos podem tratar uma de um objeto tenha a chance de manipular uma
tarefa, permitindo uma divisão de responsabilidades de requisição.
forma clara.
• Encadeia os objetos receptores e passa a requisi-
ção ao longo desse fluxo até que um objeto possa
• Estrutura
manipulá-lo.
A estrutura deste padrão, de acordo com Gamma
• Favorece a flexibilidade.
(1995) é composta pelos seguintes itens:
• Alimentador: define a interface para manipular as

solicitações e implementa a referência ao suces-

sor. Acesse o link (em inglês) e veja exemplos de
implementação do padrão Chain of Responsability
• AlimentadorConcretoA, ..., AlimentadorConcre- nas linguagens C#, C++, Delphi, Java e PHP.
toN: Manipula as solicitações pelas quais é res- http://sourcemaking.com/design_patterns/
ponsável. Pode acessar seu sucessor. Se o Alimen- chain_of_responsibility
tadorConcreto pode tratar a solicitação, ele assim
o faz; caso contrário ele repassa a solicitação para
o seu sucessor.
Uma máquina de refrigerantes necessita armazenar,
• Cliente: Inicia a solicitação para um objeto Ali- em locais diferentes, cada tipo de moeda possível. Pode
mentadorConcreto da cadeia. ser útil que um objeto receba a moeda, mas se ele não
for capaz de armazenar no local correto, deve passá-lo
• Requisição: As instâncias de Requisição é que para outro objeto buscando a colocação correta da moeda.
iram transportar as informações para os alimen- [MORAIS, 2010]
tadores executarem algo.
49
• Mediator: Define a interface para a comuni-

cação entre objetos que se relacionam.
• ConcreteMediator: Implementa a interface

e coordena a comunicação entre os objetos
ligados.
• ConcreteColleague: Se comunica com ou-

tros objetos através do Mediator.
• Aplicabilidade
Fonte: http://mundoestranho.abril.com.br/materia/como-
funcionam-as-maquinas-a-dinheiro-de-refrigerantes
Aplicável em sistemas que possuem um conjunto de
objetos que se comunicam de forma bem definida, mas
Este é um exemplo de desacoplamento, pois se alguém
complexa.
não resolver determinada tarefa ocorre uma delegação da
responsabilidade para outro objeto de forma transparente.
• Consequências
Vantagens:
Padrão Mediator
• Ao mudar um comportamento de diferentes clas-
• Objetivo
ses, apenas o Mediator será afetado.
O padrão Mediator define um objeto que encapsula a
• Um Mediator simplifica protocolos de objeto, uma
interação entre um conjunto de objetos. Favorece um aco-
vez que substitui uma interação muitos-para-
plamento fraco ao evitar que os objetos se refiram explici-
-muitos para interações um-para-muitos entre o
tamente uns aos outros, ou seja, gerencia as colaborações
Mediator e os seus colegas.
entre um grupo de objetos.
• A política de comunicações está centralizada no
mediador e pode ser alterada sem mexer nos seus
• Contexto
colegas.
Prezado aluno, caso já tenha alguma experiência com
Desvantagem:
programação em uma linguagem orientada a objetos, você
sabe que um programa possui um número muito gran-
de de classes e o código está espalhado nestas classes. • Um Mediator encapsula protocolos e pode tornar-
-se mais complexo do que qualquer colega indivi-
Quanto maior o número de classes seu projeto tiver, mais
dual. Isso pode tornar o Mediator muito complexo
complexa será a comunicação entre eles.
e com uma grande quantidade de código, o que
dificultará a sua manutenção.
Com o padrão Mediator, a comunicação entre os obje-
tos é encapsulada com um objeto Mediador reduzindo a • Exemplo de aplicação
dependência entre eles.
A torre de controle de um aeroporto, de forma análoga,
demonstra o uso deste padrão. Os pilotos dos aviões que
• Estrutura
se aproximam ou partem do aeroporto, comunicam-se com
A estrutura deste padrão é composta pelos seguintes a torre, em vez de se comunicarem entre si. As restrições
itens: de quem pode pousar ou levantar voo são definidas pela
50
torre. É importante notar que a torre não controla todo o • ClasseConcreta: Guarda os estados definidos e
voo de um avião. A sua função é apenas estabelecer as envia notificações para seus observadores.
restrições relativas ao pouso e decolagem do aeroporto.
• ClasseObservadora: mantém a referência para a
Exemplo adaptado de: http://pt.scribd.com/
ClasseConcreta. Implementa o Observador.
doc/39006620/23/Mediator-Mediador
• Aplicabilidade
O padrão Observer pode ser utilizado quando:

Assista ao filme do Youtube com a reportagem
da Rede Globo sobre o Funcionamento do Controle
do Espaço Aéreo Brasileiro • Uma abstração tem dois aspectos, um dependen-
http://youtu.be/7wsrs3a-y3M te do outro. Encapsular estes aspectos em objetos
separados permite reusá-los independentemente.
• Uma mudança em um objeto exige mudar os ou-

Padrão Observer tros e você não sabe quantos objetos serão afe-
tados.
• Objetivo
O padrão Observer define uma dependência um-para-

muitos entre objetos para que, quando um objeto mudar • Consequências
de estado, todos os seus dependentes sejam notificados e
atualizados automaticamente. [GAMMA, 1995] Vantagens:
• Contexto
• Tanto observadores quando sujeitos observados
Utilizado em situações em que se tem forte acoplamento
podem ser reutilizados e ter sua interface e imple-
de classes do tipo muito- para-muitos. Um Observador
mentação alteradas sem afetar o sistema.
conhece regiões críticas do sistema e pode reduzir os
efeitos colaterais de uma manutenção no código. • O acoplamento forte implicado pelo relacionamen-
to bidirecional é reduzido com o uso de interfaces
• Estrutura e classes abstratas.
A estrutura deste padrão é composta pelos seguintes Desvantagens:

itens:
• Cliente: Conhece seus observadores e fornece

• O abuso pode causar sério impacto na performan-
uma interface para comunicação.
ce.
• Observador: define uma interface de atualiza- • Sistemas em que todos notificam todos a cada
ção para objetos que devem ser notificados de mudança ficam inundados de requisições (“tem-
uma mudança. pestade de eventos”).
51
• Exemplo de aplicação • Aplicabilidade
Podemos utilizar como exemplo o sistema do projeto Este padrão é utilizado:

“Casa Segura”. Muito provavelmente se o sistema for de-
senvolvido apoiado no paradigma Orientado a Objetos seu
• Quando classes relacionadas forem diferentes
modelo estrutural será composto por diferentes classes.
apenas no seu comportamento.
Tais classes se relacionam entre si e partes do sistema
serão alteradas ao longo do seu ciclo de vida. • Quando são necessárias diferentes variações de
Sabe-se que uma alteração em uma classe pode afe- um mesmo algoritmo.
tar outras classes que dependem dela e, no processo de • Quando um algoritmo usa dados que o cliente
desenvolvimento, criamos dependências do tipo muitos-
não deve conhecer.
-para-muitos, ou seja, muitas classes dependendo de mui-
tas outras classes. Utilizar o padrão Observer auxiliaria na • Quando uma classe define muitos comportamen-
manutenção do mesmo, visto que implementaríamos um tos e estes aparecem como múltiplas declarações
“observador” para gerenciar esta complexidade. Este Ob- condicionais em suas operações.
servador ficaria responsável por conhecer tais mudanças e
comunicá-las às demais classes.
• Consequências
Padrão Strategy Vantagens:
• Objetivo
• Conjunto de algoritmos relacionados.
O padrão Strategy define uma família de algorit-
mos, encapsula cada um e os torna intercambiáveis. Este • É uma alternativa ao uso de subclasses.
padrão permite que o algoritmo varie independentemente
• Elimina comandos condicionais.
dos clientes que o utilizam.
• Contexto Desvantagens:
Este padrão é utilizado quando se deseja que um algo-
ritmo trate de forma diferente os dados submetidos a ele, • Gera um aumento do número de objetos no sis-
ou seja, de acordo com um contexto o algoritmo apresen- tema.
tará um comportamento.
• Estrutura • Exemplo de aplicação
A estrutura deste padrão é composta pelos seguintes Caro aluno, suponha um banco que deva praticar uma
itens: taxa para cada tipo de cliente. Teríamos que implementar,
para cada tipo de cliente, um algoritmo diferente e para
• Estratégia: define uma interface comum para to-
cada novo tipo realizar um conjunto de alterações.
dos os algoritmos suportados.
• EstrategiaConcretaA e EstrategiaConcretaB: im-
O padrão Strategy pode definir os tipos de clientes,
plementa o algoritmo usando a interface de Es-
mas sua implementação deve estar em outras classes que
tratégia.
as implementam.
52
Fonte:http://www.serasaexperian.com.br/serasaexperian/publicacoes/revista/2008/67/revista_0358.htm

Acesse o link e veja um exemplo de implementação do padrão Strategy.
https://www.youtube.com/watch?v=tFX1uAjvrww
Padrão Visitor
• Objetivo
Este padrão representa uma operação a ser realizada nos elementos de um objeto. O Visitor permite definir uma
nova operação sem mudar as classes dos elementos nos quais opera. [GAMMA,1995].
Dentre os princípios de modelagem SOLID, o padrão Visitor contribui no atendimento ao princípio OCP, em que uma
classe deve estar “aberta” para extensão, porém fechada para modificação.
• Contexto
O Visitor permite plugar novas funcionalidades em objetos sem precisar alterar a estrutura de herança. É utilizado
para evitar espalhamento e fragmentação de código.
53
• Estrutura • Agrupa operações relacionadas e separa opera-

ções não relacionadas: reduz o espalhamento de
funcionalidades e entrelaçamento do código.
itens:
• Visitor: declara uma operação de visita para cada
classe de ElementoConcreto na estrutura do ob- Desvantagens:
jeto. O nome da operação e assinatura identifica
a classe que envia o pedido de visita ao visitan- • Exige grande trabalho para adicionar novos ele-
te. Isso permite que o visitante determine a classe mentos na hierarquia, requer alterações em todos
concreta do elemento sendo visitado. Em segui- os Visitors e, se a estrutura muda com frequência,
da, o visitante pode acessar o elemento direta- é recomendado não utilizá-lo.
mente através de sua interface particular.
• Quebra de encapsulamento, pois métodos e da-
• VisitorConcreto: Implementa as operações de- dos usados pelo Visitor devem estar acessíveis.
claradas pelo Visitor. Fornece o contexto para o
algoritmo e armazena seu estado local. Este esta-
do frequentemente acumula resultados durante a
mudança da estrutura. No contexto do sistema para “Casa Segura” o padrão
Visitor deve ser utilizado para evitar o espalhamento e
• ElementoConcreto: Após do aceite de mudança
entrelaçamento de código.
de estrutura ele leva o Visitor como argumento.
• EstruturaObjeto: Fornece uma interface para

permitir que o visitante realize consulta em seus
elementos Acesse o link (em inglês) e veja exemplos de

implementação do padrão Visitor nas linguagens
• Aplicabilidade C#, C++, Delphi, Java e PHP.
http://sourcemaking.com/design_patterns/
Este padrão, de acordo com Gamma (1995), é utilizado: visitor
• Quando uma estrutura de objetos contém mui-

tas classes de objetos com diferentes interfaces e
você deseja realizar operações sobre esses obje-
tos que dependem de suas classes concretas.
• Quando a estrutura do objeto é compartilhada

1 – Descreva quais problemas o padrão Mediator visa
por muitas aplicações.
resolver.
• Quando as classes que definem a estrutura de
2 – Quando você deseja incluir novas operações a
objetos raramente mudam, mas muitas vezes
um objeto sem precisar mudar sua estrutura de
você deseja definir novas operações sobre a es- herança, utilizamos qual padrão de projeto?
trutura.
3 – Cite duas desvantagens na utilização do padrão
Observer.
• Consequências
4 – Descreva um exemplo de aplicação do padrão
Vantagens: Decorator e sua estrutura.
• Facilita a adição de novas operações.
54
Considerações finais
Caro aluno, concluímos mais uma etapa do curso. Esta

Respostas Comentadas dos Exercícios
disciplina apresentou algumas barreiras que a área de de-
senvolvimento de software ainda deve superar.
Sabe-se que muitos projetos de desenvolvimento de

Capítulo 1
software têm sido afetados pela complexidade crescente 1 – Descreva brevemente como uma mudança
do software e isso tem impactado o cronograma e o custo de requisitos pode afetar o projeto arquitetural de
dos projetos de desenvolvimento, bem como dificultado a um software.
customização de sistemas.
Notamos que um software é visto como algo flexível e,
Os princípios de atribuição de responsabilidade em sis-
portanto passível de mudanças por solicitação das áreas
temas OO, os padrões de arquitetura de software e os
de negócios ou clientes, portanto a mudança ou inclusão
Design Patterns apresentados nesta disciplina são ferra-
de novos requisitos é quase inevitável. Neste caso, depen-
mentas essenciais para o arquiteto de software. Se você
dendo do tipo de mudança, pode afetar a estrutura de um
é um desenvolvedor ou líder de equipe e ainda não está
software como um todo.
familiarizado com os temas tratados até aqui, sugerimos
que se dedique bastante ao assunto, utilizando este e ou-
O que vai determinar se a mudança afeta ou não a
tros materiais sobre os temas.
estrutura do software é como foi ele foi concebido sob o
ponto de vista arquitetural. Uma mudança simples em um
Este conhecimento certamente vai gerar um diferen-
software com objetos fortemente acoplados tem grandes
cial muito importante na sua carreira. Uma consequência
chances de propagar mudanças por toda sua estrutura.
direta disso, que você verá em pouco tempo, é que os
softwares desenvolvidos por você ou por sua equipe ga-
2 – Como os princípios SOLID contribuem para
nharão notoriedade.
evitar a degradação do código fonte?
Iniciamos aqui uma discussão sobre modelagem de
software, porém as ferramentas adequadas para a criação A degradação de código ocorre em função das mudan-
de modelos estáticos e dinâmicos de um sistema de sof- ças que acontecem ao longo do ciclo de vida do software.
tware serão apresentadas em outras disciplinas. Um dos Respeitar os princípios de modelagem de software signifi-
tópicos fundamentais do curso é o uso da UML, associar ca gerenciar melhor as dependências entres os objetos do
a UML com tudo o que falamos aqui é uma importante sistema para reduzir o acoplamento.
conexão que você deve fazer. Fique atento!
Neste sentido uma arquitetura com baixo nível de aco-
Caso tenha sentido dificuldades em entender os con-
plamento terá um nível de degradação menor que uma
ceitos abordados aqui, saiba que não é um tópico trivial
arquitetura fortemente acoplada.
de estudo. A compreensão dos padrões de projeto exige
um alto nível de abstração dos conceitos de orientação a
3 – O Princípio de Responsabilidade Única con-
objetos e certa vivência em desenvolvimento de software. tribui para organização e entendimento do código
fonte? Explique.
Esperamos que os tópicos abordados tenham sido sig-
nificativos para você e desejamos sucesso nos próximos Este princípio estabelece que uma classe pode ter ape-
módulos do nosso curso. Continuem contando conosco. nas uma razão para mudar, consequentemente tal classe
terá menor linhas de códigos e todas elas estarão rela-
Prof. Luciano Gaspar e Profa. Elisamara cionadas a apenas um contexto do software, gerando um
55
código melhor organizado e de fácil entendimento privile-

Capítulo 2
giando a legibilidade e manutenção.
1 - Qual arquitetura deve ser aplicada a proble-
4 – Quais recursos um arquiteto de software mas não-determinísticos e por quê?
pode utilizar para tangibilizar a arquitetura de um
software? Arquitetura Blackboard. Porque este padrão trabalha
com subsistemas especializados, que definem soluções
Sabe-se que uma das barreiras de modelagem é intan- aproximadas de cada etapa do problema a fim de compor
gibilidade do software, pois não conseguimos comunicar uma solução global.
ideias e modelos facilmente entre os envolvidos no seu
desenvolvimento. 2 - Assinale V (Verdadeiro) ou F(Falso), para as
afirmativas abaixo:
Um excelente recurso para minimizar isso é o uso da
UML, pois permite descrever modelos de software com di- (F) A arquitetura em camadas é limita a três níveis;
ferentes vistas do código e da computação descrita por
ele. Falso, pois a estrutura desta arquitetura pode
ser dividida em N-camadas, de acordo com a
5 – Explique o porquê consideramos que um sof- necessidade da aplicação.
tware possui a complexidade crescente.
(V) MVC é uma arquitetura em camadas com níveis
Estudamos ao longo deste curso que o software muda específicos;
ao longo do tempo e consequentemente o número de li-
nhas de código aumentam. Logo, significa dizer que quan- (F) No padrão Pipes and Filter, os Filters não são
to maior o número de linhas mais difícil torna-se seu ge- reutilizáveis;
renciamento.
Falso, pois este padrão tem por objetivo decompor o
Da complexidade vem a dificuldade de entender e co- sistema em etapas independentes com o propósito
municar membros da equipe de desenvolvimento levando de reutilizar os módulos separadamente.
a deficiência do produto, que aumenta os custos, que afe-
tam o cronograma e a confiabilidade. (F) O modelo Microkernel é simples de conceber e
implementar;
Da complexidade da estrutura vem a dificuldade de
entender o comportamento e ampliar os programas sem Falso, pois implementá-lo exige grande
criar efeitos colaterais, tornando árdua a atividade de ge- experiência em linguagens de programação e
renciar estes problemas. sistemas operacionais, além da aplicação ter

que suportar módulos diferentes em uma única
6 – O que significa dizer que um conjunto de plataforma
classes de um projeto de software está fechado
para alteração e aberto para extensão? (F) No padrão Reflection qualquer alteração pode ser
realizada através do nível meta;
Significa dizer que o princípio Aberto-Fechado está
sendo respeitado, pois a aplicação em questão permite Falso, pois o nível meta provê informações sobre
estender suas funcionalidades sem a necessidade de alterar as propriedades do sistema. E o nível base que
diretamente seu código fonte em determinadas classes. inclui a lógica da aplicação.
56
3 - Cite um objetivo comum a todas as arquiteturas classe seja responsável por “tocar” a música. Esta classe
apresentadas neste capítulo e compare exemplos: deve ser implementada respeitando o padrão Singleton.
Facilitar a implementação de alterações no sistema. No

Capítulo 4
padrão Microkernel, diversas alterações podem ser realiza-
das através de parâmetros e nos outros modelos a arqui- 1 - Cite dois padrões estruturais que favorecem
tetura é fragmentada para reduzir o impacto de modifica- o desacoplamento das classes.
ções locais em outros pontos da aplicação.
Muitos padrões podem ser utilizados para desacopla-
mentos de classes em um sistema. Três deles podem ser:
Capítulo 3 Bridge e Façade.
1 - Quais benefícios em utilizar os Padrões de

2 – Compare o padrão Adapter com padrão Fa-
Projetos?
çade.

Estudamos no Capítulo 1 os principais problemas que
O padrão Adapter utilizamos quando queremos conver-
estamos enfrentando para desenvolver e manter softwa-
ter a interface de uma classe em outra interface utilizada
re com o objetivo de reduzir a degradação do código ao
por um cliente, já o padrão Façade fornece uma interface
longo do tempo. Neste sentido os Padrões de Projetos for-
para um conjunto de interfaces em um subsistema. O Fa-
necem soluções que já foram testas, porém a escolha do
çade define uma interface de nível mais alto que torna o
padrão correto em cada caso é fator fundamental para
subsistema mais fácil de ser usado.
obter sucesso.
3 – Cite as vantagens em utilizar o padrão Bridge.

O uso de padrões torna o sistema mais fácil de desen-
volver e manter, além de favorecer o reuso no mesmo ou Separa interface de implementação; Melhora as hierar-
em outro projeto. quias de abstração e Implementação; Esconde detalhes de
implementação dos clientes.
2 - Diferencie os Padrões Estruturais e Compor-
tamentais. 4 – Descreva os elementos que fazem parte da
estrutura do padrão Proxy.
Os padrões de Projeto Comportamentais fornecem es-
tratégias para modelar a maneira como os objetos cola- Na implementação do padrão Proxy os seguintes ele-
boram entre si em um sistema e oferecem comportamen- mentos devem ser desenvolvidos: o Proxy que mantém
tos especiais apropriados para uma ampla variedade de uma referência que permite o acesso ao objeto real. O
problemas, já os Padrões Estruturais descrevem maneiras cliente: quem consome o Proxy “pensando” que é um ob-
comuns de organizar classes e objetos em um sistema. jeto real e o objeto real que um proxy representa.
3 - Leia a situação problema abaixo e indique Capítulo 5

qual padrão de projeto pode ser utilizado para re-
solver o problema. 1 – Descreva quais problemas o padrão Mediator
visa resolver.
Para resolver este problema o Padrão Singleton deve
ser utilizado. Lembre-se que este padrão garante a instân- Em sistemas orientados a objetos pode possuir um
cia única de uma classe. Imagine que uma determinada número grande de classes e o código está espalhado
57
nestas classes. Quanto maior o número de classes maior OCP - Open Close Principle (Princípio Aberto-Fechado)
o nível de espalhamento e de dependência entre essas OMG - Object Management Group
classes. Com o padrão Mediator, a comunicação entre os OMT - Object Modeling Technique
objetos é encapsulada com um objeto Mediador reduzindo OO – Orientação a Objetos
a dependência entre eles. OOSE - Object-Oriented Software Engineering
POO – Programação Orientada a Objetos
2 – Quando você deseja incluir novas operações SRP - Single Responsability Principle (Princípio de
a um objeto sem precisar mudar sua estrutura de Responsabilidade Única)
herança, utilizamos qual padrão de projeto? SO – Sistema Operacional
UML – Unified Modeling Language (Linguagem de
O padrão Visitor, pois ele permite definir uma nova Modelagem Unificada)
operação sem mudar as classes dos elementos nos quais
opera.
Bibliografia
3 – Cite duas desvantagens na utilização do
padrão Observer. BASS L.; CLEMENTS P; KAZMAN R. Software Architec-
ture in Practice. Addison-Wesley, 2003.
O abuso do uso o Observer pode causar sério impacto
na performance; e os sistemas onde todos os objetos BLAHA, M. R.; RUMBAUGH, J. R. Modelagem e projetos
notificam todos a cada mudança ficam com muitas baseados em objetos com UML 2. Rio de Janeiro, Brasil;
requisições gerando muito eventos. Elsevier, 2006.
4 – Descreva um exemplo de aplicação do padrão BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML – guia
Decorator e sua estrutura. do usuário. Rio de Janeiro: Editora Campus, 2006.
O padrão Decorator pode ser aplicado em um projeto BROOKS, F. P. No Silver Bullet: essence and accidents
que necessite, na sua interface gráfica, possuir uma Jane- of Software Engineering. IEEE Computer, April 1987.
la padrão, porém com variações do tipo Janela com borda,
janela com rolagem e/ou com borda e rolagem. BROOKS, F. P. The Mythical Man-Month: Essays on
Software Engineering. 20th Anniversary Edition. Addison-
O Decorator é composto por: Componente, Compo- Wesley Professional, 1995.
nenteConcreto, o Decorator e Decoradores (Decorator-
Concreto1 e DecoratorConcreto2, etc). BUSCHMANN, F.; MEUNIER, R.; ROHNERT, H.; SOM-
MERLAD, P.; STAL, M. A system of patterns: Pattern-ori-
ented software architecture. Chichester: Wiley, 1996.
Glossário de Siglas GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J.

Design Patterns: Elements of Reusable Object-Oriented
CASE - Computer-Aided Software Engineering Software. Reading: Addison-Wesley, 1995.
ES – Engenharia de Software
GoF - Gang of Four (referência aos autores Erich GARLAN, D. Software Architecture: a Roadmap. In: In-
Gamma, Richard Helm, Ralph Johnson e John Vlissides) ternational Conference on Software engineering: Future of
LSP - Princípio de Substituição de Liskov SE Track, pp. 91-101, Limerick, Ireland, 2000.
MVC - Model-View-Controller
58
LARMAN, Craig Applying UML and Patterns: An Intro- SHALLOWAY, A.; TROTT, J. R. Explicando Padrões de
duction to Object-Oriented Analysis and Design and Itera- Projeto: Uma Nova Perspectiva em Projeto Orientado a
tive Development. 1 ed. Prentice Hall, 2004. Objeto. Porto Alegre: Bookman, 2004.
LARMAN, Craig. Utilizando UML e Padrões. 3 ed. Porto SHAW, M.; CLEMENTS, P. A Field Guide to Boxology:
Alegre: Bookman, 2007. Preliminary Classification of Architectural Styles for Soft-
ware Systems. Proceedings of Computer Software and
LAUDON, K. C.; LAUDON, J. P. Management Informa- Applications Conference (COMPSAC ‘97), The Twenty-First
tion Systems: Managing the Digital Firm. 11th ed. Prentice Annual International, Washington, DC, EUA, pp. 6-13, au-
Hall, 2010. gust, 1997.
MARTIN, R. C. Agile Software Development, Principles, MORAIS, T. L. F. Padrões de Design. 2010. Disponí-
Patterns, and Practices. Upper Saddle River: Prentice Hall, vel em: http://di.uern.br/sebastiao/wp-content/uploa-
2003. ds/2010/04/ChainOfResponsibility.pdf. Acesso em: 20 fev.
2012.
PRESSMAN, R. S. Engenharia de Software. 8.ed. São
Paulo: McGraw-Hill, 2010. ZACHMAN, J. Enterprise Architecture: The Issue of the
Century. Database Programming and Design Magazine.
RUMBAUGH, James; et al. Modelagem e Projeto basea- San Francisco, CA, USA, 1997.
dos em objetos. Rio de Janeiro: Campus, 2006.
59

Arquitetura de Software Arquitetura de Software

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Arquitetura de Software Arquitetura de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Arquitetura de Software

Pós -Graduação a Dist ância

do software. Além disso, vamos apontar os princípios liga-

Mas, o que é arquitetura de software? Reflita: Os softwares que estamos desenvol-

As figuras 1 e 2 ilustram um projeto arquitetado e um Modelagem de aplicações de softwares

O software é afetado por um fenômeno de degradação

Figura 1: Bairro Planejado Sabemos que um processo de desenvolvimento defi-

O uso de modelos apoiam o entendimento e definição

dade complexa.O software possui uma natureza complexa

Para entender a importância de controlar esta comple-

• As tarefas essenciais estão relacionadas ao dade, conformidade, flexibilidade e intangibilidade. Estes

Para um software mais robusto, não bastaria aumen-

Logo, o domínio de tarefas acidentais não garante a

Aspectos essenciais na produção de Reflita: O processo e as ferramentas de produ-

A figura 4 exibe os impactos da complexidade na pro-

Outras áreas do conhecimento também lidam com a

Brooks (1997) afirma que, em decorrência da sua com-

Caso você já atue na área de desenvolvimento de sof-

é algo constante. Isso não significa que as mudanças são

Software é intangível, portanto, é difícil se criar uma

Assim que a primeira versão foi lançada, diver-

• um objeto A tem um método que referencia um

Responsabilidades são atribuídas aos objetos durante

Os princípios abaixo concentram-se na gestão de de-

S Single Responsability Principle (Princípio de Res-

Figura 7: Classes para cálculo da área e desenho de retângulos

Cada um destes princípios será detalhado no que se segue. Princípio Aberto-Fechado

Vamos analisar o exemplo:

A classe Retangulo da figura 6 possui os métodos

A figura 9 ilustra simplificadamente as classes para atender o OCP, neste exemplo.

Figura 9: Classes e sub-classes para formas de pagamento

Princípio de Substituição de Liskov

Princípio Segregação de Interface

Princípio de Inversão de Dependência

Figura 10: Relação entre Classes

Figura 11: Classes afetadas após alteração em Canvas

A figura 12 representa uma implementação onde existe

Ouça o podcast sobre princípios SOLID, dispo-

1 – Descreva brevemente como uma mudança de re-

2 – Como os princípios SOLID contribuem para evitar

3 – O Princípio de Responsabilidade Única contribui

4 – Quais recursos um arquiteto de software pode utili- Fonte:http://cebracnailha.blogspot.com/2011_04_01_archive.html

Definição de Padrão Arquitetural

Caro aluno, um padrão arquitetural determina a estru- Arquitetura de software é um conjunto de

Padrão de Arquitetura em Camadas

Figura 13: Modelo de arquitetura em 3 camadas

Caro aluno, o padrão de arquitetura em camadas deve ser utilizado quando:

• Tarefas similares podem ser agrupadas para facilitar a manutenção;

• A manutenção de um componente não deve afetar os outros;

• As partes do sistema podem ser substituídas de modo independente;

• Há a possibilidade de utilizar recursos do sistema atual em projetos futuros;

• Componentes complexos precisam ser decompostos;

• O limite entre os componentes é bem definido.

• Boa reusabilidade devido ao encapsulamento;

• Suporte à padronização com a criação de frameworks;

• As dependências são restritas à camada;

• Recursos intercambiáveis entre aplicações distintas.

• Queda de desempenho proporcional ao número de camadas;

• Alterações de comportamento podem provocar efeito cascata e causar gargalos.

Padrão de Arquitetura Pipes and Filters ou Pipeline

Figura 15: Arquitetura Pipes and Filters

• Objetivo • Deve ser viável realizar atualizações através de

Padrão de Arquitetura Blackboard