Augusto A. B. Branquinho.

05/05/2012
Graduado em Sistemas
de Informao (UNIPAM)
Mestrado em Cincias
da Computao (UFU)
Analista de Sistemas
Senior
Mercado Financeiro
Professor
FPU
UNIPAM
Java
.NET
Scala
C/C++
SUMRIO
1. Introduo
2. Arquitetura de Sistemas
2.1. Padres Arquiteturais
3. Padres de Projetos
3.1. GRASP
3.2. Padres de Criao
3.3. Padres Estruturais
3.4. Padres Comportamentais
3.5. Padres de Concorrncia
Referncias

.com
Software com Slida Fundao
Planejamento de uma boa arquitetura
Problemas em uma arquitetura pobre
Instvel
Impossvel de dar suporte
Impossvel adicionar novos requisitos
Difcil implantao
Difcil gerenciamento
Arquitetura + Software = ?
.com
Padres de Projeto
Problemas comuns em projetos
Solues padronizadas
Usado nos mdulos (componentes)
Aplicado pontualmente
Tornar flexvel a adio de novas
funcionalidades
Manutenibilidade do projeto/cdigo
.com
Padres de Projeto + Software = ?
Sistemas Distribudos

.com
Um software deve ser projetado considerando
Usurio (necessidades)
Sistema (infraestrutura)
Negcio (requisitos)
As REAS so baseadas na soluo e vice-versa
No focar em uma rea especfica
Usurio Negcio
Sistema
.com
Questes que devem ser levantadas
na elaborao de uma arquitetura
Como os usurios iram usar o sistema?
Como a aplicao ser implantada e
gerenciada em produo?
Como a aplicao deve ser projetada
para ser flexvel e manutenvel?
Quais so as tendncias de arquiteturas
que podem afetar a aplicao agora e
no futuro?
.com
Questes que devem ser levantadas na
elaborao de uma arquitetura
Quais so os atributos de qualidade
requeridos?
Segurana
Performance
Concorrncia
Internacionalizao
Configurao
.com
Necessidades que devem ser
consideradas
Expor a estrutura do sistema mas esconder
os detalhes de implementao
Abordar todos os casos de uso e cenrios
Tentar abordar os requisitos dos
Stakeholders
Lidar com requisitos funcionais e de
qualidade

.com
Princpios chave
Separao de preocupaes
Princpio da responsabilidade nica
Princpio do menor conhecimento
No duplicar a anlise em mais de um local
Projetar apenas o necessrio
.com
Prticas de Projetos
Manter os padres de projetos
No duplicar as funcionalidades
Preferir composio em vez de herana
Estabelecer um estilo de codificao
Estabelecer uma conveno de nomes
Manter a qualidade usando tcnicas
automatizadas de Anlise de Qualidade
Considerar as operaes da aplicao
.com
Camadas (mdulos) da Arquitetura
Separar as camadas pelas preocupaes
Explicitar a comunicao entre camadas
Baixo acoplamento entre camadas
No misturar o tipo de lgica das camadas
Interface grfica
Processamento
Persistncia ...
No misturar a formatao de dados entre
das camadas
.com
Mdulos
Um componente no deve conhecer a
implementao de outro componente
Definir bem o contrato entre os mdulos
Depende da arquitetura
Flexibilidade na alterao da forma de
comunicao
Manter manutenvel a comunicao entre
mdulos
.com
Consideraes da Arquitetura
Determinar o tipo da aplicao
Determinar a forma de Deploy
Determinar as apropriadas tecnologias
Determinar os atributos de qualidade
Determinar as preocupaes transversais
Arquitetos devem realizar provas de
conceito (PoC) sobre propostas de
arquitetura
.com
Padres (estilos) arquiteturais
Cliente/Servidor
Camadas (N-tier, 3-tier)
Componentes
Domain Driven Design
Barramento de mensagens
Orientado a servios (SOA)
On demand
Geralmente so feitas combinaes
desses padres
.com
.com
.com
.com
.com
.com
Padres de Projeto
Padres usados para resolver problemas
comuns em projetos
Os padres de projeto devem ser
Especfico para resolver um problema
Genrico para atender problemas e
requisitos futuros
Analistas de sistemas experientes
Reutilizam solues que funcionaram no
passado
.com
Objetivos
Reutilizar solues bem sucedidas
Tornar flexvel o projeto para alteraes
Evitar alternativas que comprometem a
reutilizao e estrutura do projeto
O que um padro de projeto?
Nome do padro
Problema
Soluo
Consequncias
.com
GRASP (General Responsibility
Assignment Software Patterns)
Padro gerais para atribuio de
responsabilidade em projetos
Padres de Criao
Padres Estruturais
Padres Comportamentais
Padres de Concorrncia
.com
Responsabilidade dos objetos
Fazer algo o prprio objeto
Iniciar aes de outros objetos
Controlar e coordenar atividades de outros
objetos
Conhecimento dos objetos
Sobre o encapsulamento de dados privados
Sobre objetos relacionados
Sobre coisas que pode calculado
.com
Responsabilidade e mtodos
.com
5 primeiros padres
Information expert
Creator
High Cohesion
Low Coupling
Controller

.com
Information Expert
Classe possui informaes necessrias
para sua responsabilidade
Creator
Classe possui a responsabilidade para
criar instncias/objetos
Low Coupling
Baixo acoplamento entre classes
.com
High Cohesion
Altamente coeso das classes
Controller
Associar responsabilidade para receber e
coordenar um eventos de sistema

.com
Abstrair o processo de instanciao
Auxilia o sistema no baixo acoplamento
Delegar a criao para outros objetos
Centralizar a criao
Privilegiar o uso de interface em vez
das classes concretas

.com
Preocupa com a forma que as classes
so formadas
Meio de compor as classes de forma
extensvel
Meio de compor as classes
manutenveis

.com
Preocupam com as atribuio dos
objetos
Usar composio em vez de herana
Determinar a forma de interao entre
objetos
.com
Tratar de problemas de concorrncia
Tratar o acesso a classes
Diminuir o acoplamento entre o
controle de concorrncia e as classes
.com
GUTHRIE, S.; SOMASEGAR, S.; et al. Microsoft
Application Architeture Guide. 2 Ed. 2009.
Pginas 1 52. Disponvel em:
http://apparchguide.codeplex.com/

LARMAN, C. Applying UML and Patterns: Na
Introduction to Object-Oriented Anlysis and Design
and the Unified Process. 2 Ed. 2004.

GAMMA, Erich. Padres de Projeto: Solues
Reutilizveis de Software Orientado a Objetos.
Porto Alegre: Bookman, 2005.
.com
Professor: Augusto A. B. Branquinho.
Email: augustobranquinho@yahoo.com.br
Blog: http://wpattern.com
.com
Market Data
OMS
...
M
e
s
s
a
g
e

B
U
S
M
e
s
s
a
g
e

B
U
S
M
e
s
s
a
g
e

B
U
S
M
e
s
s
a
g
e

B
U
S