O documento discute a importância da arquitetura de software, o papel do arquiteto de software e padrões para arquiteturas de software. Apresenta a definição de arquitetura de software e exemplos de decisões técnicas de arquitetura. Discute as habilidades, deveres e conhecimentos necessários para um arquiteto de software.

1. A
importância
da
Arquitetura
de
So2ware
CEFET-­‐MG,
Março
de
2013
Adriano
de
Pinho
Tavares
adriano.tavares@gmail.com
h3p://adrianotavares.com
hEp://pangeanet.org

2. Agenda
A
importância
da
arquitetura
de
so2ware
O
Papel
do
arquiteto
de
so2ware
Padrões
para
arquiteturas
de
so2ware
Exemplo
didáOco
Conclusões

3. Arquitetura
como
o
elemento
central
no
desenvolvimento
de
so2ware
A
IMPORTÂNCIA
DA
ARQUITETURA

4. Toda
solução
tem
uma
arquitetura

5. Toda
solução
tem
um
arquiteto

6. A
arquitetura
não
é
apenas
uma
fase
do
desenvolvimento
de
uma
solução
Quanto
maior
e
mais
complexo,
maior
a
necessidade
de
arquitetar!

7. Considerações
fundamentais
1.
Todo
so2ware
tem
uma
arquitetura
3.
Arquitetura
não
é
uma
fase
2.
Todo
so2ware
do
processo
de
tem
pelo
menos
desenvolvimento
um
arquiteto
do
so2ware

8. Definição
de
Arquitetura
de
So2ware
“A
arquitetura
de
so2ware
de
um
sistema
é
o
conjunto
das
principais
decisões
técnicas
de
design
tomadas
a
respeito
do
so2ware.”

9. Exemplos
de
decisões
técnicas
Tecnologia
Equipe
Estrutura
• “O
So2ware
deve
ser
• “Para
este
projeto
• “Os
elementos
devem
estar
desenvolvido
em
Java
EE
com
precisaremos
de
um
Ome
organizados
em
camadas.”
banco
de
dados
Oracle.”
com
as
competências
• “Deve
ser
uOlizado
um
técnicas
ABC.”
barramento
de
integração."
Comportamento
Interação
Qualidade
interna
• “O
processamento,
• “A
comunicação
com
o
• “Deve
haver
uma
replicação
armazenamento
e
consulta
back-­‐end
deve
ser
de
dados
entre
estes
dois
devem
ser
feitos
assíncrona,
usando
módulos
para
garanOr
a
sequencialmente.”
noOficações
de
eventos.”
independência
entre
eles.”
Implementação
• “Os
componentes
da
interface
com
o
usuário
devem
ser
implementados
usando
GWT.”

10. A
experiência
do
arquiteto
influencia
as
decisões
Experiência
do Arquiteto
Necessidades dos
envolvidos
Questões de gerenciamento
do negócio Atributos
de
Qualidade
Contratos e legislação
Pressão comercial / Requisitos
Competitiva De
Negócio
Arquitetura
Ambiente técnico
Requisitos
Questões políticas Funcionais
Sistema
Questões de ciclo de vida
Sistema
Sistema

11. Arquitetura
é
o
elemento
central
no
desenvolvimento
de
so2ware
Fornecem
Metas
de
DesOladas
em
Condutores
Negócio
Arquiteturais
Envolvidos
Conduzem
a
estrutura
da
Refina
Refina
DAS
Descrita
pelo
Arquitetura
Acompanhamento
Base
para…
e
Supervisão
Plano
Plano
Provas
de
Alocação
Releases
Plano
de
Desenho
de
de
conceito
da
do
Deploy
detalhado
Projeto
Testes
(experimentos)
Equipe
Produto

12. Metas
Blocos
de
Mecanismos
construção
Padrões
Preocupações
Modelagem
e
Documentação
Restrições
DAS
(Documento
de
Arquitetura
de
Atributos
de
Métodos
Qualidade
So=ware)
Envolvidos
Condutores
Visões
Requisitos
Provas
de
Conceito
Riscos

13. Deveres,
habilidades
e
conhecimento.
O
PAPEL
DO
ARQUITETO
DE
SOFTWARE

14. Porque
todo
mundo
quer
ser
arquiteto?

15. O
Papel
do
Arquiteto
de
So2ware
Deveres
Conhecimento
Habilidades
Arquiteto
de
So2ware

16. Deveres
Habilidades
Conhecimento
Arquitetar
Comunicação
Ciência
da
computação
Outras
disciplinas
Relacionamento
da
Eng.
So2ware
interpessoal
Tecnologias
e
plataformas
Interação
com
os
Liderança
envolvidos
Conhecimento
sobre
o
contexto
da
Organização
organização
onde
Gerenciamento
Pessoal
trabalha

17. So2-­‐Skills
essenciais
para
Arquitetos
de
So2ware
• Negócios
1. PragmaOsmo
2. Visão
3. Conhecimento
de
negócios
4. Inovação
• Pessoais
5. Mudança
de
contexto
6. Transparência
7. Paixão
• Relacionamento
8. Liderança
9. PolíOcas
10. Comunicação
11. Comportamento
12. Negociação
• Técnicos

18. Arquitetos
precisam
de
métodos
para
fazer
o
seu
trabalho
“Um
método
centrado
em
arquitetura
é
uma
abordagem
repexvel
para
fazer
a
ligação
entre
a
arquitetura
e
o
desenvolvimento
iteraOvo."

19. ACDM
• Architec@ng
So=ware
Intensive
Systems:
A
Prac@@oner’s
Guide
• Livro
sobre
o
ACDM
-­‐
Architecture
Centric
Development
Method

20. Método
de
desenvolvimento
centrado
em
arquitetura
Requisitos,
restrições
e
1:
Descobrir
os
condutores
arquiteturais
atributos
de
qualidade
Condutores
arquiteturais
e
2:
Estabelecer
o
escopo
do
projeto
planejamento
preliminar
3:
Descrever
a
arquitetura
Visualizações
Arquiteturais
4:
Revisar
a
arquitetura
Riscos
e
trade-­‐offs
7:
Executar
POCs
e
No-­‐Go
Refinar
Arquitetura
6:
Planejar
POCs
5:
Produzir
Relatório
de
POCs,
decisão
Plano
de
POCs
Arquitetura
Refinada
e
(Go/NoGo)
Planos
atualizados
Retorna
ao
estágio
apropriado
6:
Planejar
Desenvolvimento
7:
Desenvolver
e
itera
o
quanto
for
Go
necessário
Plano
de
Projeto
e
Desenho
detalhado
Plano
de
Teste
do
produto
hEp://reports-­‐archive.adm.cs.cmu.edu/anon/isri2005/CMU-­‐ISRI-­‐05-­‐103.pdf

21. O
Trabalho
de
um
arquiteto
não
é
fácil

22. PADRÕES
PARA
ARQUITETURAS
DE
SOFTWARE

23. Padrões
para
Arquitetura
de
So2ware
“Arquitetos
experientes
procuram
aderir
a
princípios
e
promover
boas
práOcas
de
design
usando
padrões
para
documentar
e
reuOlizar
soluções
em
novos
projetos
de
so2ware.”

24. Padrões
de
desenho
SOA
Catálogo
de
Padrões
para
SOA
http://www.soapatterns.org/
Livros
dobre
SOA
http://www.soabooks.com/

25. SOA
Reference
Architecture
Arquitetura
de
referência
SOA
do
The
Open
Group
http://www.opengroup.org

26. Camadas
SOA

27. Padrões
para
Arquitetura
de
Aplicações
CorporaOvas
Catálogo
de
padrões
para
aplicações
corporaOvas
hEp://marOnfowler.com/eaaCatalog/

28. Camadas
de
Arquitetura
de
Aplicações
CorporaOvas
Camada
de
Apresentação
Camada
de
Negócios
Camada
de
Domínio
Camada
de
Acesso
a
Dados
Serviços
de
Sistema

29. Padrões
para
Arquitetura
de
Aplicações
CorporaOvas
Padrões
de
Lógica
de
domínio
• Modelo
de
Domínio
(Domain
Model),
o
Camada
de
Serviço
(Service
Layer);
Padrões
de
Mapeamento
em
Metadados
• Mapeamento
em
metadados
(Metadata
Mapping),
o
Objeto
de
Pesquisa
(Query
Object);
Padrões
Estruturais
Objeto-­‐Relacionas
• Campo
IdenOdade
(IdenOty
Field),
Mapeamento
de
Chave
Estrangeira
(Foreign
Key
Mapping),
Mapeamento
de
Tabela
AssociaOva
(AssociaOon
Table
Mapping);
Padrões
Comportamentais
Objeto-­‐Relacionas
• Carga
Tardia
(Lazy
Load);
Padrões
de
Apresentação
Web
• Modelo
Visão
Controlador
(Model
View
Controller);
Padrões
de
Distribuição
• Fachada
Remota
(Remote
Facade),
Objeto
de
Transferência
de
dados
(Data
Transfer
Object).

30. Padrões
para
Integração
de
Aplicações
• Catálogo
de
65
padrões
de
integração
baseados
em
mensagens
• hEp://eaipaEerns.com/
toc.html

31. Message
Bus
Qual
arquitetura
permite
separar
aplicações
para
trabar
juntas
mas
de
forma
desacoplada
para
que
aplicações
sejam
facilmente
adicionadas
ou
removidas
sem
afetar
as
outras?
hEp://www.eaipaEerns.com/MessageBus.html

32. EXEMPLO
DIDÁTICO

33. Meta
de
negócio
A
empresa
ACME
quer
expandir
suas
vendas
e
para
isso
decidiu
abrir
um
novo
canal
de
vendas
pela
Web.

34. Desafios
da
arquitetura
ü Capturar
os
condutores
arquiteturais;
ü Selecionar
as
tecnologias
e
ferramentas;
ü Desenhar
a
arquitetura
da
aplicação;
ü GaranOr
a
qualidade
da
solução;
ü Criar
a
arquitetura
executável
(Codificar).

35. Condutores
arquiteturais
ü Usar
uma
loja
virtual
de
mercado;
ü Integrar
o
ERP
da
empresa
à
loja
virtual;
ü UOlizar
tecnologias
Java
open-­‐source;
ü Atributos
de
qualidade
– Interoperabilidade;
– Tolerância
a
Falhas;
– Desempenho;
– Escalabilidade.

36. Proposta
de
plano
arquitetural
preliminar
ü Selecionar
fornecedor
de
loja
virtual
(POC);
ü Desenhar
a
projeto
arquitetônico
para
solução
de
integração
entre
a
loja
virtual
e
o
ERP;
ü Definir
as
tecnologias
e
ferramentas;
ü Dimensionar
o
Ome
e
as
competências
técnicas
necessárias
para
o
projeto;
ü Desenvolver
um
protóOpo
para
validar
a
solução
(POC).

37. Desenho:
Principal
EsOlo
Arquitetural
ü Message
Bus
– O
objeOvo
de
introduzir
um
barramento
de
mensagens
é
estruturar
um
middleware
de
ligação
entre
a
loja
virtual
e
o
ERP
para
permiOr
que
eles
operem
em
conjunto
de
maneira
flexível
uOlizando
mensagens.

38. Plataforma
Tecnológica
ü Loja
virtual
– UOlizar
Plataforma
Magento;
ü Integração
com
ERP
– UOlizar
plataforma
open-­‐source
baseada
em
Java;
– Ferramentas
• IDE
-­‐
Eclipse;
• Message
Bus
-­‐
Apache
Camel
sobre
Apache
AcOveMQ;
• Banco
de
dados
-­‐
MySQL.

39. CONCLUSÃO

40. Conclusões
• A
arquitetura
é
a
base
para
a
tomada
de
decisões
técnicas
em
um
projeto
de
software;
• A
arquitetura
é
um
aspecto
fundamental
durante
todo
o
ciclo
de
vida
de
um
software;
• Um
arquiteto
de
software
deve
se
desenvolver
em
aspectos
técnicos
e
pessoais.

41. ParOcipe
da
rede
Pangea
hEp://pangeanet.org
A
primeira
rede
social
sobre
arquitetura
de
so=ware
do
Brasil.