Graduado em Sistemas de Informao (UNIPAM) Mestrado em Cincias da Computao (UFU) Analista de Sistemas Senior Mercado Financeiro Professor FPU

FPU UNIPAM Java .NET Scala C/C++

Augusto A. B. Branquinho. 05/05/2012

SUMRIO
1. Arquitetura de Sistemas
1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)

Referncias
.com

 Estilos

de arquitetura Communication Deployment Domain Structure

Architecture styles Service-Oriented Architecture (SOA), Message Bus Client/Server, N-Tier, 3-Tier Domain Driven Design Component-Based, Object-Oriented, Layered Architecture

Category Communication Deployment Domain Structure

.com

 Arquitetura

de Sistemas Um sistema envolve vrios estilos de arquitetura No existe a melhor arquitetura Existe a melhor soluo de arquitetura para um cenrio bem definido

.com

SUMRIO
1. Arquitetura de Sistemas
1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)

Referncias
.com

 Abstrao
Composio Herana Encapsulamento Polimorfismo Desacoplamento

.com

 Benefcios

Compreensvel Reutilizvel Testvel Extensvel Alta

Coeso

.com

SUMRIO
1. Arquitetura de Sistemas
1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)

Referncias
.com

 Uma

das arquiteturas mais citadas Historicamente a mais importante Cliente se comunica individualmente com o servidor
Separado

em diferentes computadores Compartilham recurso

Um

servidor pode ser o cliente de outro servidor

.com

 Exemplo
Web

muito comum

server

Difcil

escalabilidade
contexto
.com

Compartilhar

Peer-to-peer

Cliente/Servidor

Peer-to-peer
Mesma

aplicao compartilhando objetos em vrias instncias

.com

 Comunicao
Socket

UDP TCP

RPC

(Remote Process Call) RMI (Remote Method Invoke) SOAP (Simple Object Access Protocol)
Distributed
Exerccios:

System [1]
1.3, 1.5
.com

.com

 Projeto

de exemplo

Servidor

UDP Cliente UDP Simples mapa de um jogo Movimentos randmicos gerados pelo servidor Projetos Wpattern-client Wpattern-client-server-utils Wpattern-server
.com

.com

.com

 Projeto

de exemplo

SVN: http://wpattern.codeplex.com/ sample projects java wpattern-udpclient-server Blog: http://wpattern.com

SUMRIO
1. Arquitetura de Sistemas
1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)

Referncias
.com

 Separao

entre segmentos Cada segmento uma camada Cada camada tem uma responsabilidade Podem estar separados fisicamente Geralmente usam um padro para comunicao Melhorar o uso de recursos Algumas interaes podem ser assncronas
.com

 Manutenabilidade
Mais

fcil de manter cada camada

Acoplamento
Normalmente
Baixa

o acoplamento alto

Escalabilidade Tolerncia
Baixa

a falha

.com

 Avaliar

se uma camada no consome recursos de outras camadas preciso avaliar o nvel de segurana de cada camada Dependncia lgica entre camadas importante avaliar quantas camadas so necessrias
Para

sistemas mais simples temos apenas 3 camadas

.com

 3-Tier

(arquitetura em camadas mais comum)

Presentation

Layer Business Layer Data Layer

Sistemas

menores Sistemas intranet Adio do Service Layer

.com

.com

.com

1.
2. 3. 4. 5. 6.

7.
8. 9.

Escolher sua estratgia de camadas Determinar o que cada camada requer Definir como distribuir as camadas Determinar se preciso unir camadas Determinar as regras de interao entre camadas Determinar os interesses dos mdulos Definir a interface entre as camadas Determinar a escolha da estratgia de deploy Escolher o protocolo de comunicao
.com

 Mais

detalhes da camada Presentation Layer

.com

 Presentation

Layer

Componentes de interface do usurio Lgica dos componentes de interface

Presentation

Layer (consideraes)

Escolher o tipo de aplicao (web, desktop, ...) Escolher o tipo de tecnologia da interface Usar os padres relevantes (MVC, MVVM, MVP, ...) Projetar com a separao de responsabilidades Considerar a usabilidade Projetar o Presentation Layer de acordo com as necessidades do usurio
.com

 Presentation

Layer (questes especficas)

Caching Communication

Composition
Exception

Management Navigation User Experience User Interface Validation

 Mais

detalhes da camada Business Layer

.com

 Business

Layer

Componentes de negcio Entidades do negcio Fluxo de regras do negcio Business Layer (consideraes)

Decidir se preciso ser separado Identificar as responsabilidades e os consumidores No misturar diferentes tipos componentes Reduzir o nmero de acessos (caso seja remoto) Evitar a dependncia entre outras camadas

.com

 Business

Layer (questes especficas)

Authentication
Authorization Caching

Coupling

and Cohesion Exception Management Logging, Auditing, and Instrumentation Validation

.com

 Mais

detalhes da camada Data Layer

.com

 Data

Layer

Componentes de acesso a dados Agentes de servios Componentes utilitrios

Data

Layer (consideraes)

Escolher a forma de acesso a dados Usar abstrao para implementar o baixo acoplamento com a interface de dados Encapsular o acesso a dados Decidir como mapear as entidades
.com

 Data

Layer (consideraes)
a consolidao de dados (DTOs)

Considerar

Decidir como gerenciar as conexes Decidir como gerenciar as excees Considerar riscos de segurana Reduzir os processos de busca de dados Avaliar objetivos de escalabilidade e performance

.com

 Data

Layer (questes especficas)

Batching
Binary

Large Objects (BLOBs) Connections Data Format Exception Management Object Relational Mapping

.com

 Data

Layer (questes especficas)

Queries
Stored

Procedures Stored Procedures vs. Dynamic SQL Transactions Validation XML

.com

.com

 Service

Layer

Interface

dos servios Tipos de mensagens Implementao dos servios Pode ser realizado separadamente
Service

Layer (consideraes)

Projetar

os servios baseados no escopo da aplicao Projetar os servios e contratos extensveis

.com

 Service

Layer (consideraes)

Projetar

os servios considerando que no conhecem os clientes A camada deve implementar apenas o contrato Separar as responsabilidades dos servios e de infraestrutura Usar um padro para compor as entidades Projetar considerando requisies invlidas
.com

 Service

Layer (consideraes)
Layer (questes especficas)

Projetar

uma interface de contrato separada da implementao

Service

Authentication Authorization

Communication
Exception

Management Messaging Channels

.com

 Service

Layer (questes especficas)

Message

Construction Message Endpoint Message Protection Message Routing Message Transformation Service Interface Validation

.com

 Projeto

de exemplo

SVN:
-FPU-

https://github.com/bbranquinho/Hibernate-Example-

Blog: http://wpattern.com Posts:

http://wpattern.com/blog/post/2011/09/09/Introducaoao-Hibernate-(Componentes)-Parte-01.aspx http://wpattern.com/blog/post/2011/09/11/Introducaoao-Hibernate-(Configuracao-do-Ambiente)-Parte-02.aspx http://wpattern.com/blog/post/2011/09/11/Introducaoao-Hibernate-(Explicacao-da-Arquitetura-eDesenvolvimento-do-Utils)-Parte-03.aspx

.com

 Projeto

de exemplo

Posts:

http://wpattern.com/blog/post/2011/09/11/Introducaoao-Hibernate-(Configuracao-do-Hibernate)-Parte-04.aspx http://wpattern.com/blog/post/2011/09/11/Introducaoao-Hibernate-(Criacao-Entidades-e-do-Banco-de-Dados)Parte-05.aspx http://wpattern.com/blog/post/2011/09/11/Introducaoao-Hibernate-(Criacao-dos-DAOs)-Parte-06.aspx http://wpattern.com/blog/post/2011/09/12/Introducaoao-Hibernate-(Criacao-dos-Servicos)-Parte-10.aspx http://wpattern.com/blog/post/2011/09/12/Introducaoao-Hibernate-(Testes-dos-Servicos)-Parte-12.aspx

.com

 Projeto

de exemplo

Posts:

http://wpattern.com/blog/post/2011/09/12/Introducaoao-Hibernate-(Integracao-da-Interface-com-os-Servicos)Partes-13-e-14.aspx http://wpattern.com/blog/post/2011/09/23/Introducaoao-Hibernate-(Consideracoes-Finais)-Parte-15.aspx

.com

.com

.com

.com

.com

SUMRIO
1. Arquitetura de Sistemas
1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)

Referncias
.com

 Modelar

a arquitetura por mdulos/

projetos Cada mdulo um componente Tratar individualmente cada parte do sistema Segregar responsabilidades Subsistemas trabalhando em conjunto para formar um sistema completo
.com

 Princpios
nica

responsabilidade Open/Close Orientado a interfaces Inverso de dependncia Altamente coesos No pode duplicar implementaes No pode expor detalhes internos Entender como ser a comunicao entre componentes
.com

 Aplicar

os princpios chave da arquitetura baseada em componente Reutilizvel Substituvel Extensvel Encapsulado Independente

.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

FIX 5.0

Market

Server

Broker

Risk

Manager

Order

Recovery Database

BD Cassandra

Admin

Account

Web

Configuration
.com

Plataforma 1

Plataforma 2

Plataforma 3

.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

Admin

Broker

.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

FIX 5.0

Server

Admin

Broker

.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

FIX 5.0

Market

Server

Admin

Broker

.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

FIX 5.0

Market

Server

Broker

Manager

Admin

.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

FIX 5.0

Market

Server

Broker

Risk

Manager

Admin

.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

FIX 5.0

Market

Server

Broker

Risk

Manager

Order

Admin

.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

FIX 5.0

Market

Server

Broker

Risk

Manager

Order

Recovery

Admin

.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

FIX 5.0

Market

Server

Broker

Risk

Manager

Order

Recovery Database

Admin

.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

FIX 5.0

Market

Server

Broker

Risk

Manager

Order

Recovery Database

BD Cassandra

Admin

.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

FIX 5.0

Market

Server

Broker

Risk

Manager

Order

Recovery Database

BD Cassandra

Admin

Account

.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

FIX 5.0

Market

Server

Broker

Risk

Manager

Order

Recovery Database

BD Cassandra

Admin

Account

Configuration
.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

FIX 5.0

Market

Server

Broker

Risk

Manager

Order

Recovery Database

BD Cassandra

Admin

Account

Web

Configuration
.com

 Comunicao

via interface Componente usa a interface Recebe a instncia de um objeto Realiza chamadas dos mtodos da interface Componente implementa a interface Implementa uma determinada regra

.com

Market

Server

Broker

Risk

Manager

Order

Recovery

Database

.com

Market

Server

Risk

Manager

Order

Recovery

Database

.com

Market

Order

Risk

Manager

Server

Recovery

Database

.com

Utils

Market

Order

Risk

Manager

Server

Recovery

Database

Factory
.com

Utils

Dependncia

Market

Order

Risk

Manager

Server

Recovery

Database

Dependncia

Factory
.com

 Simplificamos

o desenvolvimento

Monoltico Distribudo Quando dividimos mdulos em mquinas podemos usar o padro de projeto Adapter Os mtodos das interfaces do tipo de chamada (Sncrona ou Assncrona) Sncrona Pode ter retorno de valores (objetos ou tipos primitivos) Assncrono Todo retorno deve ser void

.com

Utils

Dependncia

Market

Order

Risk

Manager

Server

Recovery

Database

Dependncia
Factory 1 Factory 2

Dependncia

.com

Mercados

Plataforma 1

Plataforma 2

Plataforma 3

Market Order Risk

Market Adapter

Socket (TCP/IP)

Server Adapter

Server Manager Recovery Database

.com

 Exemplo

de projeto Servidor baseado em componentes Possui servios RMI Cliente baseado em componentes Consome servios RMI Blog: http://wpattern.com

.com

.com

.com

.com

.com

.com

SUMRIO
1. Arquitetura de Sistemas
1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)

Referncias
.com

 Organizar

os detalhes do domnio do negcio a nvel de aplicao Aproximar as regras de negcio com a realidade do desenvolvimento Encapsular as regras de negcio Relaciona conceitos do domnio do negcio com artefatos de Software Regras Mdulos
.com

 Representao
PowerPoint Diagramas

dos modelos

UML Rascunho em papel Diversos outros meios de representao

Domain
Criar

model

um modelo comum entre o negcio e os Stakeholders O time usa para se comunicar sobre os requisitos do sistema, entidade de dados e modelo de processos
.com

 Domain

Model

Modular Extensvel

Fcil

de manter Refletir o modelo de negcio Melhorar a reusabilidade e testabilidade do domnio de objetos de negcio
No

usar DDD impacta em camadas infladas e um Domain Model anmico

.com

.com

SUMRIO
1. Arquitetura de Sistemas
1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)

Referncias
.com

 Integrao

entre aplicaes Diferentes tecnologias Diferentes plataformas Comunicao baseada em mensagens

Produo

e consumo de mensagens

Baixo

custo na adio e remoo de aplicaes

.com

 Problemas

comuns entre comunicao de sistemas

Dependncia

entre as aplicaes A aplicao de requisio precisa conhecer o receptor O receptor precisa conhecer a mensagem Em uma comunicao ponto a ponto temos (n * (n 1)) / 2 conexes Manuteno, custo e alteraes
.com

N Computadores

N de Conexes

2 3 4 5 6 7 8 9 10

1 3 6 10 15 21 28 36 45

.com

 Problemas
Alterar

comuns entre comunicao de sistemas

a interface de todas aplicaes no to simples Aplicaes proprietrias

.com

 Soluo:

Barramento de Mensagens

Transporte de mensagens entre aplicaes 3 elementos Conjunto de mensagens permitidas Conjunto de mensagens comuns Infraestrutura para o barramento de mensagens
Envia

mensagens apenas para o barramento Recebe mensagens apenas do barramento

.com

cliente passa um listener para o barramento Normalmente diminui o fluxo de mensagens Normalmente no garante a ordem das mensagens Precisa ter um tratamento interno No barramento preciso de otimizao, roteamento e armazenamento
.com

Aplicao 1

Aplicao 2

Aplicao 3

Aplicao 4 Aplicao 5

Aplicao 6

Aplicao 7

Message BUS (Barramento de Mensagens)

Aplicao 8

Aplicao 9

Aplicao 10

Aplicao 11

.com

 Problema

para a adio de mais uma aplicao

.com

Barramento deve conhecer sintaticamente a mensagem O Barramento no precisa conhecer semanticamente a mensagem Baseado em Publish/Subscribe
Plublish:

envio de mensagem para o barramento Subscribe: escuta um grupo especfico de mensagens ou todas mensagens
.com

 Publisher

e Subscriber usam frequentemente o padro Observer

.com

tipos de Publisher/Subscriber Fixo Dinmico

Publisher/Subscriber Fixo

.com

Publisher/Subscriber Dinmico

.com

 Normalmente

os Clientes no esto conectados diretamente no Barramento de Mensagens

Cliente 1 Cliente 2 Cliente 3 Cliente 4 Cliente 5

Aplicao 1

Aplicao 2

Message BUS
Aplicao 3 Aplicao 4
.com

Tipos de Publish/Subscribe
List-Based

Publish/Subscribe Broadcast-Based Publish/Subscribe Content-Based Publish/Subscribe

.com

tipo do Publish/Subscribe impacta diretamente na arquitetura O barramento de mensagens Mantem uma lista de Published (Subjects) Mantem uma lista de Subscribers (Observers) Possui uma formatao comum das mensagens
.com

 List-Based
Mantem

Publish/Subscribe

uma lista de Published Mantem uma lista de interessados (Subscribers) Mensagem recebida no barramento enviada apenas aos interessados (Subscribers)

.com

 Broadcast-Based
Mantem

Publish/Subscribe

uma lista de Published Mantem uma lista de Ns O barramento recebe uma mensagem e envia ela para todos os Ns Cada N precisa filtrar as mensagens que lhe interessa

.com

 Content-Based
As

Publish/Subscribe

mensagens so enviadas de acordo com um padro desejado Um Subscriber envia um comando contendo o padro/contedo de mensagens interessadas Identifica um ou mais campos A mensagem enviada para um Subscriber se ela combinar com seus interesses
.com

 Content-Based
Realiza

Publish/Subscribe

um roteamento inteligente Depende de uma estrutura de alta performance Ler mensagens Analisar mensagens Rotear cada mensagem para os Subscribers

.com

.com

 Pontos
O

negativos

problema deve depender da adio e remoo de sistemas Alto custo de infraestrutura Alto nvel de complexidade Necessita de uma equipe experiente Grande fluxo de mensagens Em sistemas pequenos adiciona latncia

.com

 Pontos
Em

positivos

Escalabilidade

grandes sistemas, normalmente, corresponde a alta performance Tolerncia a falha Decomposio de sistemas por responsabilidade Possibilidade de um sistema sobre demanda
.com

Cliente 1 Cliente 2

Cliente 3

Cliente 4

Cliente 5

Cliente 6

Web Service (Home Broker)

Message BUS (Barramento de Mensagens)

Roteador de Ordens

Dados de Mercado Autenticao Autorizao (Market Data)

Gerenciador de Risco

Mercados BD Cassandra Memcached

.com

 Estrutura

Memcached

Aplicao

Retorna o valor cacheado

Consulta

No

Lgica da Aplicao
Sim No memcached? Colocar no Memcached?
Resultado do Banco de Dados

Memcached
No

BD
Sim .com

 Grande

Throughput Analisar as possibilidades de escalabilidade Escalabilidade horizontal Escalabilidade vertical

.com

Aplicao 1

Aplicao 2

Aplicao 3

Aplicao 4 Aplicao 5

Aplicao 6 Aplicao 7

Message BUS

Grande Throughput
Aplicao 8

Aplicao 9

Aplicao 10

Aplicao 11

.com

Aplicao 1

Aplicao 2

Aplicao 3

Aplicao 4 Aplicao 5

Aplicao 6 Aplicao 7

Message BUS

Message BUS

Menor Throughput

Menor Throughput

Aplicao 8

Aplicao 9

Aplicao 10

Aplicao 11

.com

 Exemplo
Grande

de uso no Mercado Financeiro

nmero de aplicaes/clientes Grande distncia entre as aplicaes/clientes Conexes dedicadas e de alta velocidade Objetivos

Diminuir custos

Diminuir a latncia Aumentar o throughput

.com

Message BUS
Market Data OMS ...

Message BUS

Message BUS
Market Data OMS ...

Message BUS

Message BUS
Market Data OMS ...

Message BUS

Message BUS
Market Data

Message B Message BUS

Message BUS
Market Data

Message BUS

Message BUS

BUS

Message BUS
Market Data OMS ...

Message BUS

 Existem

sistemas usados para auxiliar um Barramento de Mensagens

RabbitMQ

http://www.rabbitmq.com/ http://www.rabbitmq.com/tutorials/tutorial -four-python.html HornetQ http://www.jboss.org/hornetq ZeroMQ http://www.zeromq.org http://zguide.zeromq.org/page:all#MissingMessage-Problem-Solver

.com

 Sistemas

usados para auxiliar o Barramento de Mensagens

Amazon SQS

Kestrel

http://robey.github.com/kestrel/ Existem muitas outras http://wiki.secondlife.com/wiki/Message_Q ueue_Evaluation_Notes Tipos de Queues: Pub/Sub, Multicast, Fan Out, http://lostechies.com/derekgreer/2012/03/ 28/rabbitmq-for-windows-exchange-types/
.com

 http://mikehadlow.blogspot.com.br/2011/04

/message-queue-shootout.html

.com

SUMRIO
1. Arquitetura de Sistemas
1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)

Referncias
.com

 Projeto
5

de exemplo

camadas .NET (C#) Entity Framework (EF) WCF (Windows Communication Foundation) WPF (Windows Presentation Foundation) ASP .NET MVC Silverlight
.com

.com

.com

.com

.com

.com

.com

.com

.com

.com

 Pontos
Fcil

Positivos

implementao Fcil manuteno Excelente opo para sistemas mais simples Fcil adaptao de diferentes BD Servios disponveis para vrios clientes

.com

 Pontos
Alto

Negativos

acoplamento entre camadas Contrato dos servios pouco flexveis Baixo desempenho em sistemas de baixa latncia (SOAP) Baixa escalabilidade Baixa tolerncia a falha

.com

SUMRIO
1. Arquitetura de Sistemas
1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)

Referncias
.com

1.

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

2.

3.

4.

COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T.; BLAIR, G. Distributed System: Concepts and Design. 5 ed. Addison-Wesley, 2012. Publish/Subscribe. Microsoft patterns & practices: proven practices for predictable results. http://msdn.microsoft.com/enus/library/ff649664.aspx
Message Bus. Microsoft patterns & practices: proven practices for predictable results. http://msdn.microsoft.com/enus/library/ms978583.aspx
.com

5.

6.

7.

Architectural Patterns and Styles. http://msdn.microsoft.com/enus/library/ee658117.aspx Domain Driven Design and Development In Practice. http://www.infoq.com/articles/ddd-inpractice
DDD Introduo a Domain Driven Design http://www.agileandart.com/2010/07/16/dddintroducao-a-domain-driven-design/
.com

8.

9.

10.

EVANS, E. Domain-Driven Design: Tackling Complexity in the Heart of Software. AddisonWesley Professional. 1 Ed. 2003.

.com

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 Market Data OMS ...

M e s s a g e B U S

Professor: Augusto A. B. Branquinho. Email: augustobranquinho@yahoo.com.br Blog: http://wpattern.com

.com