Arquitetura de software,

frameworks OO e padrões de
software – uma introdução

Prof. Eduardo Bezerra

edubezerra@gmail.com
 Visão geral
• Arquitetura de software
• Frameworks OO
• Padrões de software

2
Arquitetura de software

3
 Arquitetura de software
• Arquitetura é daqueles termos difíceis de definir e
que possuem diversos significados.
• Uma definição possível é encontrada no manual de
especificação da UML:
“Arquitetura de software é a estrutura organizacional do
software. Uma arquitetura pode ser recursivamente
decomposta em partes que interagem através de interfaces”

4
 Arquitetura de software
• O termo “arquitetura” pode ser usado em dois contextos:
arquitetura lógica e arquitetura física.
• Arquitetura lógica
– Diz respeito a como um SSOO é decomposto logicamente em diversas
partes e como as suas classes são dispostas por essas partes.
– Como um sistema OO complexo deve ser logicamente decomposto, e
como as suas classes são dispostas pelas partes resultante dessa
decomposição?
• Arquitetura física
– Diz respeito a como as partes desse SSOO devem ser dispostas
fisicamente quando o sistema tiver de ser implantado.
– Como as partes lógicas devem ser fisicamente dispostas?

5
 Arquitetura de software
• O termo camada é algumas vezes utilizado com dois sentidos
diferentes na literatura:
– camada lógica (layer)
– camada física (tier), esta última normalmente corresponde a um nó de
processamento ou a um processo.
• Note que há confusão na literatura, e que layer e tier são
muitas vezes usados como sinônimos.
– “When people discuss layering, there's often some confusion over the
terms layer and tier. Often the two are used as synonyms, but most
people see tier as implying a physical separation” – Fowler (PEAA)
• Aqui, usamos o camada para denotar cada componente
lógico de uma aplicação.

6
 Aplicações OO mal projetadas
• Um problema comum em muitas aplicações OO é que elas são
muito acoplados aos limites de uma aplicação em particular
sendo construída, sem preocupação com reuso.
• Outro problema é a falta de planejamento inicial para definir
a organização das partes da aplicação.
– O resultado é a construção de aplicações OO nas quais diferentes
aspectos do software estão misturados em uma mesma região do
código fonte.

7
 Aplicações OO mal projetadas
• Um exemplo de aplicação OO mau projetada é aquela em que
grande parte da lógica da aplicação está “misturada” com a
lógica da interface com o usuário.
– Nesse cenário, há poucas (ou nenhuma) classes na aplicação que
representam conceitos do domínio do problema e que poderiam ser
reutilizados em outras aplicações.
• Conforme novas funcionalidades são adicionadas, essas
aplicações se tornam cada vez mais difíceis de manter.
• Uma forma adequada de organizar aplicações OO complexas é
definir cuidadosamente os aspectos da arquitetura lógica.

8
 Aplicações OO mal projetadas
• Termos sinônimos:
– BIG BALL OF MUD
– SHANTYTOWN CODE
– SPAGHETTI CODE

Veja também:
http://en.wikipedia.org/wiki/Big_ball_of_mud 9
 Arquitetura lógica
• Chamamos de arquitetura lógica à organização das classes de
uma aplicação em diversos “componentes” que colaboram
entre si.
– Esses componentes são denominados camadas.
• Cada uma dessas camadas
– possui um propósito particular (e.g., interação com o usuário,
interação com outros sistemas, validação de regras do negócio,
persistência de dados, etc.).
– corresponde a aglomerados de classes e interfaces que colaboram
entre si para atingir esse propósito particular.

10
 Camadas
• Uma camada é um componente que adiciona valor a
componente de menor nível de abstração.
• Cada camada é responsável por um aspecto particular da
aplicação.
– Cada camada corresponde a um conjunto coeso de funcionalidades de
uma aplicação.
• Por exemplo, a camada de domínio de uma aplicação
adicionar valor à camada de persistência.
– A camada de persistência provê serviços de persistência de dados da
aplicação;
– A camada de domínio persiste dados e também provê serviços para
aplicar regras do negócio a esses dados.

11
 Camadas
• Uma camada pode ser subdividida em um ou mais
componentes.
– cada componente em uma camada fornece serviços no mesmo nível
de abstração que os demais contidos na mesma camada.
• Por exemplo, a camada de infraestrutura contém serviços de
persistência de objetos e de logging de informações, cada um
dos quais pode ser visto como uma subcamada da camada de
persistência.
• O padrão Layers (Layers pattern) é um padrão arquitetural
usado para estruturar aplicações que podem ser decompostas
em grupos de tarefas nas quais cada grupo de tarefa está em
um nível particular de abstração.
12
 Padrão Layers
• Problema
– Em um sistema, há diversos níveis de abstração (altos e baixos), e
componentes de alto nível devem usar os componentes de baixo nível.
• A parte de baixo nível está perto do hardware
• A parte de mais alto nível está perto do usuário
– O fluxo de comunicação consiste de pedidos fluindo do alto para o
baixo níveis (As respostas andam na direção contrária )
• Solução: decompor o sistema em subsistemas, considerando
as seguintes restrições.
– Subsistemas devem ser maximamente coesos.
– Subsistemas devem ser minimamente acoplados.

13
 Padrão Layers
• Para minimizar o acoplamento, esse padrão sugere que a
maioria dos serviços que a camada (i) fornece são construídos
a partir de serviços fornecidos pela camada (i-1).
– Uma camada utiliza vários serviços da camada inferior.
– A camada inferior não tem conhecimento da existência da camada
superior.
– A camada inferior esconde (da camada superior) as camadas
localizadas abaixo dela.

14
 Vantagens do uso de camadas
• Habilita o reuso de camadas entre aplicações.
– Porque camadas inferiores são projetadas para ser independentes das
camadas superiores.
• Ajuda a gerenciar a complexidade através da divisão do
sistema em partes menos complexas que o todo.
– Facilita o entendimento de cada camada em particular, em separado
das demais camadas.
• Permite intercambialidade (exchangeability)
– Um camada por ser trocada por outra, se as duas possuírem a mesma
interface.
– O acoplamento entre camadas é mantido no nível mínimo possível.
– Permite usar implementações de vários fornecedores.

15
 Vantagens do uso de camadas
• Divisão do trabalho
– Permite dividir o trabalho das equipes por camada por causa da
segmentação fornecidas por elas.
• Alterações são mantidas locais:
– Uma mudança em uma camada mais baixa que não afete a sua
interface não implicará em mudanças nas camadas mais altas.
– Uma mudança em uma camada mais alta que não implica na criação
de um novo serviço em uma camada mais baixa não irá afetar esta
última.

16
 Desvantagens do uso de camadas
• Potencial geração de cascatas de mudanças
– Sob certas condições, alterações de comportamento numa camada
podem desencadear alterações em cascata.
– Exemplo: adição de um campo em uma janela, que corresponde a uma
informação armazenada no banco de dados.
• Menor eficiência
– Camadas adicionam sobrecarga de comunicação, por conta de
mudança de representações entre camadas.
– Um “bloco monolítico de código" (Big Ball of Mud) seria mais
eficiente...

17
 Desvantagens do uso de camadas
• Requer da equipe de desenvolvimento habilidades técnicas
adicionais para organizar as camadas e manter o acoplamento
entre elas em um nível baixo.
– Uso de padrões de software e frameworks para organização da
interface com o usuário, injeção de dependências, persistência, etc;
– Uso de interfaces abstratas para abstrair implementações das
camadas;
– Tratamento adequado de exceções;
– etc.

18
 Aplicações corporativas
• São sistemas de informação, tais como lojas virtuais,
sistemas de controle acadêmico, sistemas de
controle de contratos, etc.
• Características
– Envolvem dados persistentes;
– Implementam lógica do negócio;
– Envolvem acesso concorrente por vários “usuários”;
– Normalmente manipulam grandes quantidades de dados;
– Precisam se comunicar com outras aplicações corporativas
(i.e., envolvem interações sistêmicas).

19
Arquitetura de aplicações corporativas
• Não há um consenso na terminologia usada para
fazer referência às camadas componentes de uma
aplicação corporativa.
• Duas taxonomias normalmente aceitas são as
propostas por Martin Fowler e Eric Evans:
– Fowler: Apresentação, Serviços, Domínio, Acesso a dados.
– Evans: Apresentação, Aplicação, Domínio, Infraestrutura.

20
Arquitetura de aplicações corporativas
(Fowler)
• Presentation
– Provision of services, display of information (e.g., in
Windows or HTML, handling of user request (mouse clicks,
keyboard hits), HTTP requests, command-line invocations,
batch API)
• Service
– Typically includes logic that's particular to a single use case
and also some communication with other infrastructures,
such as messaging.

Categorização de Martin Fowler (1/2) 21

Arquitetura de aplicações corporativas
(Fowler)
• Domain
– Logic that is the real point of the system
• Data Source
– Communication with databases, messaging systems,
transaction managers, other packages

Categorização de Martin Fowler (2/2) 22

 Arquitetura de aplicações corporativas
(Fowler)

23
Fonte: http://martinfowler.com/eaaCatalog/serviceLayer.html
Arquitetura de aplicações corporativas
(Evans)
• UI (User Interface):
– […] responsible of displaying information to the user, and
accept new data.
• Application Layer:
– it’s in charge of coordinating the actions to be performed
on the domain. There are no business rules or domain
knowledge here. […]

Categorização de Eric Evans (1/2) 24

Arquitetura de aplicações corporativas
(Evans)
• Domain Layer:
– Business rules and logic lives inside this layer. Business
entity state and behavior is defined and used here.
Communication with other systems, persistence details,
are forwarded to the infrastruture layer.
• Infrastructure Layer:
– God and devil are in the details, and in the infrastructure
layer. Its main responsibility is the persistence of the
business state, most frequently, using a relational
database.

Categorização de Eric Evans (2/2) 25

 Arquitetura de aplicações corporativas
(Evans)

26
Fonte: DDD Quickly
Padrões de software

27
 Padrão de software - definição
• “Um padrão é uma entidade que descreve um
problema que ocorre freqüentemente, e então
descreve a essência de uma solução para o
problema, de maneira que você possa usar esta
solução um milhão de vezes, sem fazê-la do mesmo
jeito duas vezes.”
Christopher Alexander (Arquiteto e Urbanista)

ALEXANDER, C. et al. A Pattern Language: Towns, Buildings, Construction.

Oxford University Press, New York, NY, 1977. 28
 Catálogos de padrões
• Um catálogo de padrões é um grupo de
padrões que estão relacionados de uma certa
forma e podem ser usados juntos ou
independentemente.

29
 Catálogos de padrões
• GoF (Gang of Four)
• JEE (Java Enterprise Edition)
• P of EAA (Patterns of Enterprise Application
Architecture)
• POSA (Pattern-Oriented Software
Architecture)
• GRASP (General Responsibility Assignment
Software Patterns/Principles)
30
 Tipos de padrões de software
• Padrões organizacionais (organizational patterns)
• Padrões de requisitos (requirement patterns)
• Padrões de análise (analysis patterns)
• Padrões de projeto (design patterns)
• Padrões arquitetônicos (architectural patterns)
• Padrões de implementação (idioms, coding patterns)
• Padrões de testes
• Anti-padrões (anti patterns)

31
Exemplo – MVC para Web

32
 Exemplo – MVC para Web
• Componentes
– O model representa as informações processadas e contém
comportamento para validar essas informações.
– O controller manipula requisições do usuário.
• Entretanto, em vez de interagir com dispositivos de hardware (teclado,
mouse), o controller dessa variação processa requisições HTTP que são a
ele delegadas.
– O view é o conteúdo enviado ao usuário.

33
 Exemplo – MVC para Web
• Colaborações
– Ao receber uma requisição HTTP, o front controller
• (1) realiza operações de recepção,
• (2) localiza o controller adequado e
• (3) repassa a requisição.
– Ao receber a requisição, o controller realiza alterações
(consultas) sobre o model e, após isso, passa o controle ao
view.
• O controller pode passar ao view a parte do model necessária à
atualiza dele.

34
 Exemplo – MVC para Web (Java)

35
Fonte: Argonavis
Frameworks OO

36
 Frameworks OO
• Um framework OO consiste de uma coleção de classes, tanto
abstratas quanto concretas que, em cooperação, fornecem
funcionalidades que podem ser usadas na solução de uma
família de problemas relacionados.
• Um framework
– fornece um conjunto de funcionalidades reutilizáveis e adaptáveis em
algum contexto.
– provê um comportamento genérico e adaptável para que diversas
aplicações possam fazer uso.
– pode ser usado como base para o desenvolvimento de inúmeras
aplicações no domínio modelado pelo mesmo.

37
 Uso de frameworks
• Frameworks habilitam o reuso na construção de aplicações
OO.
• Um framework captura o fluxo de controle relacionado com
algum aspecto encontrado em aplicações OO.
– Este fluxo pode ser especializado mais tarde por uma aplicação
específica, o que chamamos de instanciação do framework.
• Clientes (usuários) de frameworks são desenvolvedores de
software que os utilizam para aumentar a produtividade na
construção de suas aplicações.

38
39
 Construção de frameworks
• Na construção de diversas aplicações para um mesmo
domínio, um conjunto de tarefas comuns emerge.
• O processo evolutivo de abstrair (fatorar) essas tarefas
comuns leva à construção de frameworks.
• A construção de um framework é normalmente uma tarefa
complexa e realizada por desenvolvedores experientes.

40
Exemplos de frameworks para Java
• JADE (http://jade.tilab.com/)
– Frameworks para desenvolvimento de sistemas multi-agentes.
• Struts, Spring WEB, JSF
– Frameworks para desenvolvimento da camada de apresentação de
aplicações Web para plataforma JEE.
• Hibernate
– Framework para mapeamento objeto-relacional.
• JUnit
– Framework para construção e execução de testes de unidade.
• Pico Container
– Framework para injeção de dependências entre partes de uma
aplicação.
41
Uso de frameworks - complicadores
• Há diversos complicadores em potencial a ser analisados para
tomar a decisão de utilizar ou não um framework durante a
construção de uma aplicação OO:
– Esforço de desenvolvimento
– Curva de aprendizado
– Manutenibilidade
– Validação
– Eficiência
– Documentação

42
Uso de frameworks - complicadores
• Esforço de desenvolvimento
– (Se o framework tiver que ser desenvolvido antes de ser usado)
– É difícil desenvolver bons frameworks, pois é necessário uma boa
experiência no domínio.
– No entanto, há ótimos frameworks de código aberto (e.g., Hibernate,
Spring, JUnit, etc).
• Curva de aprendizado
– Em um framework, normalmente há muitas classes, muitos níveis de
abstração.
– O tempo necessário para se tornar produtivo como usuário de um
framework pode ser grande.
– Possível solução: treinamento da equipe.

43
Uso de frameworks - complicadores
• Manutenibilidade
– Pode haver dificuldade em se manter compatibilidade com versões
anteriores, já que frameworks se tornam “mais maduros” com o
passar do tempo e as aplicações que os usam devem evoluir em
paralelo.
• Validação
– O processo de depuração de uma aplicação que usa frameworks pode
se tornar complicado.
• Eficiência
– A flexibilidade e a generalidade de um framework podem trabalhar
contra sua eficiência em algumas aplicações.
• Documentação
– A documentação é essencial para o usuário (desenvolvedor) poder
utilizar o framework. 44
Padrões de software vs frameworks
• Padrões são mais abstratos de frameworks.
– Frameworks são implementações em uma linguagem específica
– Padrões são descrições de soluções para problemas recorrentes.
• Padrões podem documentar frameworks.
• Frameworks estão relacionados a um domínio de aplicação,
enquanto padrões são mais genéricos e podem ser aplicados
em vários domínios de aplicação.
• Padrões possuem uma arquitetura menor que um framework.
– Um framework pode conter vários padrões; no entanto, o oposto não
se aplica.
– A implementação de um framework complexo pode usar vários de
padrões.

45
Material complementar

46
 Frameworks Caixa Branca
• Em frameworks caixa branca, é utilizado o princípio da
inversão de controle.
• Segundo esse princípio, é o framework que define o fluxo de
execução geral da aplicação, e não o contrário.
– Código genérico chama código específico.
– Exemplo: Java Swing.
• Esse princípio é também conhecido como Princípio de
Hollyhood: “Don’t call us. We will call you.”
– Conceito um tanto enganoso...
• O desenvolvedor define subclasses de classes fornecidas pelo
framework.

47
Frameworks Caixa Branca

48
 Frameworks Caixa Branca
• Uso do padrão Template Method em um framework caixa branca.

49
 Frameworks Caixa Preta
• Em um framework caixa preta, a extensão ocorre por
composição e delegação.
• A funcionalidade do framework é estendida através da
implementação de componentes que estão de acordo com
uma interface específica esperada pelo framework.
• É típico o uso do padrão Strategy (GoF) na implementação de
frameworks caixa preta.

50
Frameworks Caixa Preta

51
 Referências sobre frameworks
• Fayad & Schmidt. Object oriented application frameworks.
Communications of the ACM, v. 40, n. 10, 1997.
• Livro do Ian Sommerville (particularmente o capítulo 14).
• Introdução ao Struts (framework para aplicações WEB)
– Disponível em http://www.jspbrasil.com.br/jsp/artigos/struts.jsp
• Xin Chen, Developing Application Frameworks in .NET, Apress.
• Michael Nash, Java Frameworks And Components Accelerate
Your Web Application Development, Cambridge University.

52
 Classificação de frameworks
• Por escopo (em qual ou quais situações o framework é
utilizado):
– Infraestrutura de sistema
– Integração de middleware e
– Enterprise.
• Por forma de extensão (de que forma o framework pode ser
estendido pela aplicação):
– Whitebox (caixa branca)
– Blackbox (caixa preta)
– Note que há um contínuo entre esses dois extremos.

53
 Classificação por Escopo
• Infraestrutura de sistema: utilizados na implementação de
certo aspecto interno de um sistema (persistência, Web, GUI,
etc.)
• Integração de middleware: utilizados na construção de
aplicações distribuídas (CORBA, EJB, DCOM, etc.)
• Enterprise: dão suporte ao desenvolvimento de aplicações em
um certo domínio de negócio (telecomunicações, aviação,
comércio eletrônico, finanças, manufaturas, etc.). Permitem o
desenvolvimento de aplicações diretamente para o usuário
final.

54