O documento discute a importância da arquitetura de software em projetos, destacando os papéis do arquiteto de software e sua interface com stakeholders. Ele aborda como a arquitetura deve ser desenvolvida, enfatizando a identificação de requisitos, endereçamento de riscos e a necessidade de modelos adequados. Além disso, esclarece equívocos comuns sobre o que constitui a arquitetura de software e fundamenta sua relevância para o sucesso de projetos complexos.

1. ARQUITETURA
DE
SOFTWARE
NA
PRÁTICA
Alessandro
Kieras
kieras@gmail.com
@kierasbr

2. Apresentação
¨ Alessandro
Kieras
¤ kieras@gmail.com
¤ www.linkedin.com/in/kieras
¤ @kierasbr
¨ Arquiteto
de
So6ware
¨ Formação
¤ Ciência
da
Computação
na
PUC
Minas
¤ Especialização
em
Arquitetura
de
Sistemas
no
IEC
©
Alessandro
Kieras.
Twi2er:
@kierasbr

3. Agenda
¨ ObjeGvos
¨ Arquitetura
de
So6ware
¨ Arquiteto
de
So6ware
¨ O
Desenvolvimento
de
uma
Arquitetura
de
So6ware
¨ Conclusões
©
Alessandro
Kieras.
Twi2er:
@kierasbr

4. ObjeGvos
¨ Compreender...
¤ O
papel
da
arquitetura
de
so6ware
em
projetos
¤ O
papel
do
profissional
arquiteto
de
so6ware
e
suas
principais
atribuições
¤ Como
a
arquitetura
de
so6ware
é
aplicada
em
projetos
©
Alessandro
Kieras.
Twi2er:
@kierasbr

5. Arquitetura
de
So6ware

6. Arquitetura
de
So;ware
MoGvação
¨ Projetos
simples
podem
ser
realizados
por
uma
única
pessoa
¤ Pouca
modelagem
¤ Ferramentas
simples
¤ Processo
simples
¤ Pouco
projeto
¤ Pouca
especialização
para
construir
©
Alessandro
Kieras.
Twi2er:
@kierasbr

7. Arquitetura
de
So;ware
MoGvação
¨ Projetos
complexos/maiores
exigem
arquitetura
¤ Mais
modelagem
¤ Ferramentas
mais
poderosas
¤ Processos
mais
bem
definidos
¤ Mais
projeto
¤ Alta
especialização
para
construir
©
Alessandro
Kieras.
Twi2er:
@kierasbr

8. Arquitetura
de
So;ware
MoGvação
©
Alessandro
Kieras.
Twi2er:
@kierasbr

9. Arquitetura
de
So;ware
MoGvação
©
Alessandro
Kieras.
Twi2er:
@kierasbr

10. Arquitetura
de
So;ware
MoGvação
¨ O
sistema
possui
todos
seus
casos
de
uso
implementados
“corretamente”,
no
entanto...
¤ Sua
usabilidade
é
ruim
¤ “Quebra”
quando
há
picos
de
uGlização
¤ Possui
potenciais
furos
de
segurança
¤ É
diXcil
e
caro
para
manter
e
evoluir
¤ Não
suporta
o
crescimento
da
“carga”
com
o
tempo
¤ Seu
desempenho
é
inaceitável
para
o
usuário
¤ <coloque
seu
exemplo
aqui>
©
Alessandro
Kieras.
Twi2er:
@kierasbr

11. Arquitetura
de
So;ware
MoGvação
©
Alessandro
Kieras.
Twi2er:
@kierasbr

12. Arquitetura
de
So;ware
Equívocos
sobre
Arquitetura
de
So6ware
¨ Arquitetura
é
o
mesmo
que
Desenho
¤ Nem
todo
desenho
é
arquitetura
¤ Arquitetura
lida
com
decisões
de
desenho
mais
significaGvas
¤ Arquitetura
também
lida
no
espaço
do
problema
¨ Arquitetura
é
a
Infra-­‐Estrutura
¤ Infra-­‐estrutura
é
apenas
parte
da
arquitetura
¤ Arquitetura
restrita
à
infra-­‐estrutura
não
possui
resultados
saGsfatórios
©
Alessandro
Kieras.
Twi2er:
@kierasbr

13. Arquitetura
de
So;ware
Equívocos
sobre
Arquitetura
de
So6ware
¨ A
Tecnologia
“X”
é
Arquitetura
¤ Arquitetura
é
mais
que
uma
lista
de
produtos
ou
tecnologias
¤ Parte
da
arquitetura
pode
ser
realizada
por
uma
tecnologia
¤ Tecnologia
ajuda
a
definir
a
arquitetura,
mas
a
arquitetura
não
deve
se
limitar
à
tecnologia
¨ Arquitetura
é
realizada
por
uma
única
“pessoa”,
o
arquiteto
¤ Complexidade
dos
sistemas
atuais
à
Gme
de
arquitetos
¤ Diversos
interessados
(stakeholders)
à
influenciam
a
definição
da
arquitetura
©
Alessandro
Kieras.
Twi2er:
@kierasbr

14. Arquitetura
de
So;ware
Equívocos
sobre
Arquitetura
de
So6ware
¨ Arquitetura
pode
ser
representada
em
única
visão
¤ Normalmente
não
é
suficiente,
ou
leva
a
um
modelo
confuso,
desnecessariamente
complexo
e
às
vezes
desorganizado
¤ Não
atende
às
necessidades
de
todos
stakeholders
n Diretor
(cliente)
vs.
Desenvolvedores
¤ O
“Modelo
de
Visualização
4+1”
(Krutchen)
é
bastante
uGlizado
e
suficiente
para
a
maioria
dos
casos
©
Alessandro
Kieras.
Twi2er:
@kierasbr

15. Arquitetura
de
So;ware
Equívocos
sobre
Arquitetura
de
So6ware
¨ Arquitetura
é
uma
arte
“oculta”
¤ Soluções
provadas
na
práGca
são
reuGlizadas,
adaptadas
e
melhoradas
n EsGlos
arquiteturais
n Pipes-­‐and-­‐Filters,
Client/Server,
N-­‐Tier,
IntegraGon
Hub,
P2P…
n Padrões
de
desenho
n Design
Pamerns,
IntegraGon
Pamerns,
Enterprise
App
Pamerns…
n Indústria
e
mercado
n Frameworks,
Metodologias,
Padronizações,
Normas,
Tecnologias…
¤ É
resultado
de
trabalho
intenso
¤ Vivência
em
projetos
e
experiência
são
fundamentais
©
Alessandro
Kieras.
Twi2er:
@kierasbr

16. Arquitetura
de
So;ware
Definições
¨ A
arquitetura
de
um
so6ware
é
a
estrutura
do
sistema
que
compreende
¤ Os
elementos
de
so6ware
¤ O
relacionamento
entre
estes
elementos
¤ As
propriedades
externamente
visíveis
destes
elementos
¨ Bass,
Clements,
and
Kazman.
So6ware
Architecture
in
PracGce
2nd
ed,
Addison-­‐Wesley
2003
©
Alessandro
Kieras.
Twi2er:
@kierasbr

17. Arquitetura
de
So;ware
Definições
¨ Arquitetura
é
a
organização
fundamental
de
um
sistema
compreendida
pelos
¤ Seus
componentes
¤ Seus
relacionamentos
entre
si
¤ Seus
relacionamentos
com
o
ambiente
¤ Os
princípios
que
guiam
seu
desenho
e
evolução
¨ IEEE
Recommended
PracGce
for
Architectural
DescripGon
of
So6ware-­‐Intensive
Systems
(IEEE
Std
1471
/
2000)
©
Alessandro
Kieras.
Twi2er:
@kierasbr

18. Arquitetura
de
So;ware
Importância
¨ Obter
a
“visão
geral”
do
sistema
¤ Compreender
os
elementos
importantes
do
so6ware
¨ Construir
sistemas
complexos
e
desafiadores
¨ Aumentar
a
consistência
e
ortogonalidade
¨ Documentar
decisões
de
alto
impacto
para
os
stakeholders
¨ Aumentar
o
reuso
¨ Diminuir
o
retrabalho
e
a
redundância
©
Alessandro
Kieras.
Twi2er:
@kierasbr

19. Arquitetura
de
So;ware
Importância
¨ MiGgar
riscos
cedo
e
conGnuamente
¤ Tecnológicos,
Humanos,
Negócio,
Gerenciais
etc
¨ Reduzir
custos
de
desenvolvimento,
manutenção
e
evolução
do
so6ware
¨ Definir
estratégias
gerenciais
de
desenvolvimento
¨ Manter
o
foco
em
so6ware
executável
Arquitetura
pode
levar
ao
sucesso
ou
ao
fracasso
de
um
projeto
©
Alessandro
Kieras.
Twi2er:
@kierasbr

20. Arquiteto
de
So6ware

21. Arquiteto
de
So;ware
Contexto
de
Atuação
Escopo
da
decisão
Sem
muita
importância
Foco
do
para
o
Arquiteto
arquiteto
Impacto
da
decisão
Sem
muita
Normalmente
importância
não
é
foco
do
para
o
arquiteto
arquiteto
©
Alessandro
Kieras.
Twi2er:
@kierasbr

22. Arquiteto
de
So;ware
Contexto
de
Atuação
¨ Analista
de
Negócios
¤ Interação
especial
quando
está
lidando
com
visões
e
requisitos
ligados
aos
usuários
finais
¨ Gerente
de
Projetos
¤ Auxiliar
no
desenvolvimento
de
planos
ou
avaliá-­‐los
¤ Prover
informações
técnicas,
feedback,
conselhos,
avaliação
de
riscos
etc
¨ Especialistas
em
tecnologia
¤ Obter
informações
detalhadas
sobre
uma
tecnologia
¤ Suas
aplicações
e
restrições
©
Alessandro
Kieras.
Twi2er:
@kierasbr

23. Arquiteto
de
So;ware
Contexto
de
Atuação
¨ Desenvolvedores
¤ Liderança
técnica
para
garanGr
aderência
à
arquitetura
¤ Auxílio,
acompanhamento
e
revisão
de
desenhos
produzidos
pela
equipe
¤ Mentoring
e
treinamento
¤ Envolvimento
em
testes
de
sistema
e
integrados
¤ Desenvolver
código,
se
necessário
©
Alessandro
Kieras.
Twi2er:
@kierasbr

24. Arquiteto
de
So;ware
Contexto
de
Atuação
¨ Stakeholders
¤ IdenGficar,
envolver
e
balancear
as
necessidades
¤ Alinhar
as
expectaGvas
com
o
objeGvo
do
projeto
n Usuário
Final
à
funções
corretas,
usabilidade
n Administrador
à
ferramentas
para
monitoração
n MarkeGng
à
conjunto
de
features,
“Gme
to
market”
n Cliente
à
preço,
features
n Desenvolvedor
à
requisitos
claros,
bom
desenho
n Gerente
à
uso
produGvo
de
recursos,
prazo,
custo
n Suporte
à
documentação
clara,
gerenciabilidade
©
Alessandro
Kieras.
Twi2er:
@kierasbr

25. Arquiteto
de
So;ware
Contexto
de
Atuação
¨ Lembre-­‐se
que
o
arquiteto
não
está
sozinho
©
Alessandro
Kieras.
Twi2er:
@kierasbr

26. Arquiteto
de
So;ware
Papel
e
Atribuições
¨ GaranGr
que
o
escopo,
contexto
e
restrições
do
projeto
são
documentados
e
aceitos
¨ IdenGficar
e
envolver
os
diversos
stakeholders
¨ Facilitar
a
decisão
dos
stakeholders,
fornecendo
informações,
mostrando
trade-­‐offs,
alinhando
os
objeGvos
gerais
¨ Definir
e
documentar
a
estrutura
e
a
forma
do
sistema
©
Alessandro
Kieras.
Twi2er:
@kierasbr

27. Arquiteto
de
So;ware
Papel
e
Atribuições
¨ Definir
e
documentar
estratégias,
padrões,
guias
etc
para
direcionar
a
construção
do
sistema
¨ GaranGr
que
a
arquitetura
contemple
os
atributos
de
qualidade
do
sistema
¨ Desenvolver
a
descrição
arquitetural
¨ Ajudar
a
garanGr
que
a
arquitetura
é
aplicada
até
o
final
do
sistema
¨ Prover
liderança
técnica
©
Alessandro
Kieras.
Twi2er:
@kierasbr

28. Arquiteto
de
So;ware
Papel
e
Atribuições
¨ Manter-­‐se
envolvido
com
todo
o
processo
de
desenvolvimento
Grau
de
Envolvimento
Requisitos
Desenho
Código/Teste
Integração
Aceitação
©
Alessandro
Kieras.
Twi2er:
@kierasbr

29. O
Desenvolvimento
de
uma
Arquitetura
de
So6ware

30. O
Desenvolvimento
de
uma
Arquitetura
de
So6ware
¨ Entendendo
um
Exemplo
Real
¨ IdenGficação,
Classificação
e
Priorização
dos
Requisitos
¨ Endereçamento
de
Riscos
e
Provas
de
Conceito
¨ Representação
da
Arquitetura
©
Alessandro
Kieras.
Twi2er:
@kierasbr

31. Entendendo
um
Exemplo
Real
Sistema
de
Aprovisionamento
¨ Finalidade
¤ AGvação
e
configuração
de
serviços
nas
plataformas
de
telecomunicações
através
do
processamento
de
ordens
de
serviço
¨ Missão
do
Projeto/Produto
¤ SubsGtuir
o
sistema
de
aprovisionamento
atual
¤ Aumentar
a
capacidade
do
sistema
para
suportar
1
milhão
de
transações/dia
¤ Aumentar
a
confiabilidade
e
escalabilidade
do
sistema
¤ Diminuir
custos
operacionais
¤ PermiGr
a
convergência
de
serviços
©
Alessandro
Kieras.
Twi2er:
@kierasbr

32. Entendendo
um
Exemplo
Real
Sistema
de
Aprovisionamento
¨ Visão
Geral
da
Arquitetura
©
Alessandro
Kieras.
Twi2er:
@kierasbr

33. Entendendo
um
Exemplo
Real
Sistema
de
Aprovisionamento
¨ Visão
Geral
de
Casos
de
Uso
©
Alessandro
Kieras.
Twi2er:
@kierasbr

34. O
Desenvolvimento
de
uma
Arquitetura
de
So6ware
¨ Entendendo
um
Exemplo
Real
¨ IdenGficação,
Classificação
e
Priorização
dos
Requisitos
¨ Endereçamento
de
Riscos
e
Provas
de
Conceito
¨ Representação
da
Arquitetura
©
Alessandro
Kieras.
Twi2er:
@kierasbr

35. IdenBficação
,
Classificação
e
Priorização
dos
Requisitos
Requisitos
©
Alessandro
Kieras.
Twi2er:
@kierasbr

36. IdenBficação
,
Classificação
e
Priorização
dos
Requisitos
Requisitos
©
Alessandro
Kieras.
Twi2er:
@kierasbr

37. IdenBficação
,
Classificação
e
Priorização
dos
Requisitos
Requisitos
Categoria
Subcategoria
Requisito
Prior
Comp
Pond
Integração
online
com
WLI
5
2
10
Integração
batch
com
SIEBEL
5
2
10
Comunicação
com
plataforma
HLR
Nokia
5
3
15
Comunicação
com
plataforma
PMS/BLL
5
5
25
Comunicação
com
a
Plataforma
SMSC
5
3
15
Interoperabilidade
Comunicação
com
a
Plataforma
OTA
5
3
15
Comunicação
com
a
Plataforma
PSA
5
3
15
Funcionalidade
Comunicação
com
a
Plataforma
NMS
5
3
15
Comunicação
com
a
Plataforma
VMS
5
5
25
Comunicação
com
a
Plataforma
PTT
5
3
15
Comunicação
com
a
Plataforma
OSC
5
5
25
Integração
com
Oracle
10g
4
1
4
Padronização
Conformidade
Java
EE
5
4
1
4
Cadastro
de
usuários
3
2
6
Segurança
Acesso
por
papéis
3
3
9
Criptografia
5
2
10
©
Alessandro
Kieras.
Twi2er:
@kierasbr

38. IdenBficação
,
Classificação
e
Priorização
dos
Requisitos
Requisitos
Categoria
Subcategoria
Requisito
Prior
Comp
Pond
Facilidade
de
Análise
Histórico
de
comandos
5
5
25
Manutenção
Monitoração
de
filas
4
4
16
Testabilidade
Emprego
de
testes
unitários
3
2
6
Emprego
de
plataformas
mock
3
4
12
Facilidade
de
Instalação
Implantação
a
quente
de
comandos
4
4
16
Adaptabilidade
Execução
em
BEA
WebLogic
Server
10
5
3
15
Portabilidade
Sistema
operacional
HPUX
5
2
10
Facilidade
de
Troca
Reinstalação
de
componentes
Java/JEE
4
2
8
Reinstalação
transparente
de
novos
comandos
4
4
16
©
Alessandro
Kieras.
Twi2er:
@kierasbr

39. IdenBficação
,
Classificação
e
Priorização
dos
Requisitos
Requisitos
Categoria
Subcategoria
Requisito
Prior
Comp
Pond
Maturidade
Disponibilidade
24
x
7
/
99,9%
4
5
20
Tolerância
a
falhas
Integridade
dos
elementos
5
5
25
Confiabilidade
Interrupção
para
erros
técnicos
5
4
20
Reestabelecimento
após
erro
técnico
5
4
20
Recuperação
de
falhas
Reestabelecimento
de
nó
3
5
15
Registro
de
resultados
de
todos
comandos
5
5
25
Operabilidade
Interface
web
para
configuração
3
2
6
Usabilidade
Interface
web
para
monitoração
4
4
16
Entendimento
Facilidade
de
entendimento
das
interfaces
3
2
6
Aprendizado
Facilidade
de
aprendizado
das
interfaces
3
2
6
Execução
de
550
mil
elementos
por
hora
4
4
16
Execução
diária
de
4,5
milhões
de
elementos
4
4
16
Uso
de
tempo
Priorização
de
elementos
4
3
12
Eficiência
Modificação
de
prioridade
dos
elementos
3
5
15
Eficiência
na
manipulação
de
filas
4
5
20
Uso
de
recursos
Várias
conexões
simultâneas
com
NE
4
3
12
©
Alessandro
Kieras.
Twi2er:
@kierasbr

40. O
Desenvolvimento
de
uma
Arquitetura
de
So6ware
¨ Entendendo
um
Exemplo
Real
¨ IdenGficação,
Classificação
e
Priorização
dos
Requisitos
¨ Endereçamento
de
Riscos
e
Provas
de
Conceito
¨ Representação
da
Arquitetura
©
Alessandro
Kieras.
Twi2er:
@kierasbr

41. Endereçamento
de
Riscos
Riscos
¨ “Ou
você
ataca
os
riscos
ou
eles
te
atacam!”
¤ Arquitetura
é
fundamental
para
idenGficar
os
riscos
e
trabalhar
em
estratégias
para
sua
miGgação
©
Alessandro
Kieras.
Twi2er:
@kierasbr

42. Endereçamento
de
Riscos
Riscos
¨ Prazo
impossível
de
ser
cumprido
¤ Tipo:
Gerencial
¤ MiGgação:
n A
solução
arquitetural
contribuiu
para
parGcionar
o
projeto
em
várias
entregas,
gerando
valor
mais
rapidamente
e
adiando
requisitos
de
menor
impacto
n Contribuiu
também
para
a
organização
e
paralelização
dos
trabalhos
da
equipe
de
desenvolvimento
em
várias
frentes:
n Núcleo
n Conectores
de
Entrada
n Adaptadores
de
Rede
n Aplicações
Web
(Cadastro,
Monitor,
Histórico)
n Supervisor
n etc
©
Alessandro
Kieras.
Twi2er:
@kierasbr

43. Endereçamento
de
Riscos
Riscos
¨ Falta
de
conhecimento
para
integrar
com
algumas
plataformas
(protocolos)
¤ Tipo:
Técnico
¤ MiGgação:
n Construção
de
plataformas
mock
para
auxiliar
na
testabilidade
n Realizar
um
esforço
de
desenho
dos
adaptadores
de
rede
n Iniciar
o
desenvolvimento
dos
adaptadores
de
rede
todos
em
paralelo,
priorizando
os
mais
diXceis
ou
desconhecidos
pela
equipe
(Corba,
Rmi,
Socket
etc)
logo
na
fase
de
concepção
©
Alessandro
Kieras.
Twi2er:
@kierasbr

44. Endereçamento
de
Riscos
Riscos
¨ Falta
de
conhecimento
da
equipe
nas
ferramentas
a
serem
uGlizadas
no
projeto
(servidor
de
aplicação)
¤ Tipo:
Técnico/Gerencial
¤ MiGgação:
n Treinamento
mínimo
da
equipe
nas
ferramentas
necessárias
n Não
houve
treinamento
n Provas
de
conceito
para
uGlização
de
recursos
©
Alessandro
Kieras.
Twi2er:
@kierasbr

45. Endereçamento
de
Riscos
Riscos
¨ Outros
riscos
técnicos
foram
tratados
através
de
provas
de
conceito
¨ Prova
de
Conceito
¤ Busca
validar/invalidar
uma
possível
solução
para
um
problema
¤ Critérios
de
sucesso/insucesso
da
prova
de
conceito
devem
ser
definidos
antes
de
sua
execução
¤ Seu
custo
pode
variar:
n Lista
de
produtos
/
features
de
um
produto
/
documento
n Construção
de
um
protóGpo
“executável”
©
Alessandro
Kieras.
Twi2er:
@kierasbr

46. Endereçamento
de
Riscos
Provas
de
Conceito
(Fase
1)
# Descrição POC Tempo est
1.1 Compatibilidade ServiceMix / WebLogic 16
1.2 Compatibilidade OpenESB / WebLogic 24
1.3 Compatibilidade Mule / WebLogic 16
1.4 Compatibilidade JBoss ESB / WebLogic 24
2.1 Endereçamento funcional ServiceMix 32
2.2 Endereçamento funcional OpenESB 32
2.3 Endereçamento funcional Mule 40
2.4 Endereçamento funcional JBoss ESB 32
2.5 Funcionalidade de Binding Components 16
2.6 Binding Components + Linguagem de Script 4
2.7 Flexibilidade Service Engine 16
2.8 Escolha da linguagem de script 24
3.1 Endereçamento não-funcional ESB 60
4.1 Avaliação Message Broker WebLogic 16
5.1 Viabilidade Binding Component 24
5.2 Viabilidade Message Normalization 24
5.3 Viabilidade Service Engine 24
6.1 Simulação integração 40
464
©
Alessandro
Kieras.
Twi2er:
@kierasbr

47. Endereçamento
de
Riscos
Provas
de
Conceito
(Fase
2)
Grupo Prova de Conceito Prioridade
Supervisão Mecanismo de comunicação de supervisor <---> agentes (jmx) 1
Supervisão Mecanismo de comunicação de supervisor <---> agentes (jms) 1
Supervisão Monitoração remota de Mbean supervisor com JConsole 2
Supervisão Registro de ativação desativação de itens/nós monitorados 3
Supervisão Redistribuição de message listeners 4
Monitoração Número de usuários/telas de monitoração simultâneos suportados 1
Monitoração Desempenho/viabilidade arrastar pop-up no cliente 2
Monitoração Modelo de objetos / data type / biblioteca data type 3
Monitoração Padronização de componentes / interface (validar modelo interação) 4
Monitoração Escolha de framework web 1
Hp Open View Monitoração com JMX 1
Hp Open View Monitoração com SNMP 2
Cadastro e Configuração Implementação de aplicação Grails padrão 1
Cadastro e Configuração Implementação de aplicação Grails com melhorias* 2
Histórico Implementação utilizando Log4j 1
Histórico Utilização de otimizações do WLS 2
Histórico Implementação "pura" (sem frameworks) 3
Histórico Implementação utilizando aspectos 4
Single Sign On Pesquisa e implementação de mecanismo do WLS 1
©
Alessandro
Kieras.
Twi2er:
@kierasbr

48. Endereçamento
de
Riscos
Resultado
PoC
ServiceMix
¨ Distribuição
em
nós
disGntos
¤ O
teste
da
distribuição
do
aprovisionador
e
comunicadores
em
nós
disGntos
foi
realizada
com
sucesso
pelo
ServiceMix
¤ No
entanto
em
alguns
testes,
quando
o
servidor
era
iniciado,
o
ServiceMix
não
conseguiu
encontrar
a
rota
para
os
bind
components
e
uma
exceção
era
lançada
¤ Reinicializando
o
servidor,
a
rota
era
encontrada
©
Alessandro
Kieras.
Twi2er:
@kierasbr

49. Endereçamento
de
Riscos
Resultado
PoC
ServiceMix
¨ Balanceamento
de
carga
¤ A
distribuição
das
mensagens
para
os
comunicadores
feita
pelo
ServiceMix
não
considerou
a
capacidade
de
processamento
dos
nós
¤ Levou
a
uma
distribuição
ineficiente
da
carga
pois
distribuía
igualmente
entre
os
nós
¤ Em
um
ambiente
onde
hajam
recursos
com
capacidade
de
processamento
diferente,
os
de
menor
capacidade
ficarão
sobrecarregados
enquanto
os
de
maior
capacidade
poderão
ficar
ociosos
©
Alessandro
Kieras.
Twi2er:
@kierasbr

50. Endereçamento
de
Riscos
Resultado
PoC
ServiceMix
¨ Tolerância
à
falhas
¤ No
teste
de
tolerância
à
falhas,
ao
restabelecer
funcionamento
de
um
nó,
a
comunicação
foi
recuperada
¤ Porém
foi
detectada
a
perda
de
mensagens
©
Alessandro
Kieras.
Twi2er:
@kierasbr

51. Endereçamento
de
Riscos
Resultado
PoC
ServiceMix
¨ Desempenho,
Uso
do
Tempo,
Carga
¤ Um
cliente
conseguiu
inserir
510K
mensagens
no
Weblogic
JMS
Server
em
5
horas.
¤ Ao
iniciar
o
consumo
das
mensagens
pelo
aprovisionador,
após
alguns
minutos,
o
container
terminou
inesperadamente.
©
Alessandro
Kieras.
Twi2er:
@kierasbr

52. Endereçamento
de
Riscos
Resultado
PoC
ServiceMix
¨ Avaliação
Geral
¤ No
geral
a
aplicação
apresentou
baixa
maturidade
¤ Por
diversas
vezes
foi
necessário
reiniciar
os
servidores
¤ O
ServiceMix,
por
padrão,
uGliza
filas
não-­‐persistentes
contribuindo
possivelmente
para
a
perda
de
mensagens
n Não
foi
encontrada
na
documentação
à
época
uma
forma
de
alterar
essa
caracterísGca
¤ A
alternaGva
ESB
ServiceMix
foi
abandonada
por
falhar
em
vários
critérios
da
prova
de
conceito
©
Alessandro
Kieras.
Twi2er:
@kierasbr

53. Endereçamento
de
Riscos
Resultado
PoC
ServiceMix
Teste Resulta
Subcategoria Requisito Pond
Realizado? do
Integração batch com CRM 15 Sim Ok
Interoperabilidade Comunicação com plataforma
HLR Nokia 15 Sim Ok
Disponibilidade 24 x 7 /
Maturidade
99,9% 20 Sim Falha
Integridade dos elementos 25 Sim Falha
Tolerância a falhas
Interrupção para erros técnicos 20 Não -
Reestabelecimento após erro
técnico 20 Não -
Recuperação de falhas Reestabelecimento de nó 15 Sim Ok
Registro de resultados de
todos comandos 25 Sim Falha
Execução de 550 mil
elementos por hora 16 Sim Falha
Uso de tempo
Execução diária de 4,5
milhões de elementos 16 Não -
Execução 10 15 Sim Ok
Adaptabilidade
Sistema operacional HPUX 15 Não -
Reinstalação de componentes
Java/JEE 8 Não -
Facilidade de Troca
Reinstalação transparente de
novos comandos 16 Não -
©
Alessandro
Kieras.
Twi2er:
@kierasbr

54. O
Desenvolvimento
de
uma
Arquitetura
de
So6ware
¨ Entendendo
um
Exemplo
Real
¨ IdenGficação,
Classificação
e
Priorização
dos
Requisitos
¨ Endereçamento
de
Riscos
e
Provas
de
Conceito
¨ Representação
da
Arquitetura
©
Alessandro
Kieras.
Twi2er:
@kierasbr

55. Representação
da
Arquitetura
Documentação
da
Arquitetura
¨ A
documentação
da
arquitetura
de
so6ware
¤ Facilita
comunicação
com/entre
stakeholders
¤ Documenta
antecipadamente
decisões
de
desenho
de
alto
impacto
e
grande
abrangência
¤ Auxilia
no
esclarecimento
dos
requisitos
do
so6ware
¤ IdenGfica
e
avalia
possíveis
opções
arquiteturais
¤ Alimenta
e
impõe
um
contexto
para
o
desenho
do
so6ware
¤ Propositalmente
oculta
detalhes
menos
importantes
¨ Modelo
mais
uGlizado:
4+1,
Krutchen
©
Alessandro
Kieras.
Twi2er:
@kierasbr

56. Representação
da
Arquitetura
Modelo
4+1
©
Alessandro
Kieras.
Twi2er:
@kierasbr

57. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
+1
=
Casos
de
Uso
(ou
Cenários)
¤ Relevantes
para
a
modelagem
arquitetural
(risco,
importância
para
o
negócio,
impacto
para
o
cliente,
ou
ponto
de
atenção)
¨ Visão
Lógica
¨ Visão
de
Componentes
¨ Visão
de
Implantação
¨ Visão
de
Processos
©
Alessandro
Kieras.
Twi2er:
@kierasbr

58. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
+1
=
Casos
de
Uso
(ou
Cenários)
¤ Exemplo
didáGco
©
Alessandro
Kieras.
Twi2er:
@kierasbr

59. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
+1
=
Casos
de
Uso
(ou
Cenários)
¤ Exemplo
real
©
Alessandro
Kieras.
Twi2er:
@kierasbr

60. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
+1
=
Casos
de
Uso
(ou
Cenários)
¤ Exemplo
real
©
Alessandro
Kieras.
Twi2er:
@kierasbr

61. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
Lógica
¤ Exemplo
didáGco
©
Alessandro
Kieras.
Twi2er:
@kierasbr

62. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
Lógica
¤ Exemplo
real
©
Alessandro
Kieras.
Twi2er:
@kierasbr

63. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
Lógica
¤ Exemplo
real
©
Alessandro
Kieras.
Twi2er:
@kierasbr

64. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
Lógica
¤ Exemplo
real
©
Alessandro
Kieras.
Twi2er:
@kierasbr

65. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
de
Componentes
¤ Exemplo
didáGco
©
Alessandro
Kieras.
Twi2er:
@kierasbr

66. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
de
Componentes
¤ Exemplo
real
©
Alessandro
Kieras.
Twi2er:
@kierasbr

67. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
de
Implantação
¤ Exemplo
didáGco
©
Alessandro
Kieras.
Twi2er:
@kierasbr

68. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
de
Implantação
¤ Exemplo
real
©
Alessandro
Kieras.
Twi2er:
@kierasbr

69. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
de
Implantação
¤ Exemplo
real
©
Alessandro
Kieras.
Twi2er:
@kierasbr

70. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
de
Processos
¤ Exemplo
didáGco
©
Alessandro
Kieras.
Twi2er:
@kierasbr

71. Representação
da
Arquitetura
Modelo
4+1
¨ Visão
de
Processos
¤ Exemplo
real
WLI Endpoint
Control Bus
Input Channel
Mapper
C
C
NE Channel Message C
Normalizer Channel Adapter
Dispatcher
Mapper Mapper Mapper
Mapper
C
C
Normalizer Provisioning Content Splitter Content Based NE Channel Message C
Channel Adapter
Channel - In Enricher Router Dispatcher
Mapper
Polling C
C
NE Channel Message C
Channel Adapter
Dispatcher
Message
Translator
Normalizer Provisioning Aggregator Network Reply
Channel - Out Channel
Output Channel
History Channel Store
WLI Endpoint
©
Alessandro
Kieras.
Twi2er:
@kierasbr

72. Representação
da
Arquitetura
Modelo
4+1
¨ Nem
todas
visões
são
sempre
necessárias
¨ As
visões
complementam-­‐se
umas
às
outras
¨ Capturam
interesses
de
múlGplos
stakeholders
¨ Permitem
cruzar
as
informações
para
validação
do
modelo
¨ Representam
uma
estratégia
para
miGgação
de
riscos
do
projeto
¨ Permitem
realizar
o
vínculo
entre
o
problema
e
a
solução
¨ Fornecem
coerência
arquitetural
©
Alessandro
Kieras.
Twi2er:
@kierasbr

73. Representação
da
Arquitetura
Documento
de
Arquitetura
de
So6ware
¨ O
DAS
deve
prover
uma
visão
abrangente
da
arquitetura
do
so6ware
¨ Além
das
visões
arquiteturais,
sugere-­‐se
referenciar
também:
¤ Requisitos
de
Qualidade
(ISO
9126)
¤ Restrições
ou
Decisões
Arquiteturais
¤ Arquitetura
de
Referência
¤ Mecanismos
de
Análise
e
Desenho
¤ Cenários
de
Atributos
de
Qualidade
©
Alessandro
Kieras.
Twi2er:
@kierasbr

74. Representação
da
Arquitetura
Documento
de
Arquitetura
de
So6ware
¨ Requisitos
de
Qualidade
¤ ISO
9126
Categoria
Subcategoria
Requisito
Prior
Comp
Pond
Maturidade
Disponibilidade
24
x
7
/
99,9%
4
5
20
Tolerância
a
falhas
Integridade
dos
elementos
5
5
25
Confiabilidade
Interrupção
para
erros
técnicos
5
4
20
Reestabelecimento
após
erro
técnico
5
4
20
Recuperação
de
falhas
Reestabelecimento
de
nó
3
5
15
Registro
de
resultados
de
todos
comandos
5
5
25
Operabilidade
Interface
web
para
configuração
3
2
6
Usabilidade
Interface
web
para
monitoração
4
4
16
Entendimento
Facilidade
de
entendimento
das
interfaces
3
2
6
Aprendizado
Facilidade
de
aprendizado
das
interfaces
3
2
6
Execução
de
550
mil
elementos
por
hora
4
4
16
Execução
diária
de
4,5
milhões
de
elementos
4
4
16
Uso
de
tempo
Priorização
de
elementos
4
3
12
Eficiência
Modificação
de
prioridade
dos
elementos
3
5
15
Eficiência
na
manipulação
de
filas
4
5
20
Uso
de
recursos
Várias
conexões
simultâneas
com
NE
4
3
12
©
Alessandro
Kieras.
Twi2er:
@kierasbr

75. Representação
da
Arquitetura
Documento
de
Arquitetura
de
So6ware
¨ Restrições
ou
Decisões
Arquiteturais
¤ Conjunto
de
restrições
pré-­‐existentes
¤ Princípios
Arquiteturais,
PolíGcas
etc
¨ Exemplos:
Sistema
deve
integrar-­‐se
com
ferramenta
de
monitoração
HP
Open
View
Sistema
deve
expor
serviço
para
integração
com
plataforma
SOA
Implementação
deve
uGlizar
servidor
de
aplicação
WebLogic
10
e
SGBD
Oracle
10g
Sistema
deve
seguir
as
políGcas
de
segurança
do
cliente
Aplicações
web
devem
ser
compa‚veis
com
Internet
Explorer
6
(ou
superior)
e
Firefox
2
(ou
superior)
©
Alessandro
Kieras.
Twi2er:
@kierasbr

76. Representação
da
Arquitetura
Documento
de
Arquitetura
de
So6ware
¨ Restrições
ou
Decisões
Arquiteturais
¨ Exemplos:
¤ Fundamentar
serviços
em
JMS
¤ UGlizar
mecanismos
failover
e
load
balancing
n Store-­‐And-­‐Forward
n Persistência
em
SGBD
e/ou
arquivo
n RetentaGvas
automáGcas
de
execução
n Supervisão
de
sobrecarga
n Filas
e
tópicos
distribuidos
n Clustering
¤ Supervisão
aGva
©
Alessandro
Kieras.
Twi2er:
@kierasbr

77. Representação
da
Arquitetura
Documento
de
Arquitetura
de
So6ware
¨ Arquitetura
de
Referência
¤ EsGlos
Arquiteturais
©
Alessandro
Kieras.
Twi2er:
@kierasbr

78. Representação
da
Arquitetura
Documento
de
Arquitetura
de
So6ware
¨ Arquitetura
de
Referência
¤ EsGlos
Arquiteturais
©
Alessandro
Kieras.
Twi2er:
@kierasbr

79. Representação
da
Arquitetura
Documento
de
Arquitetura
de
So6ware
¨ Mecanismos
de
Análise
e
Desenho
©
Alessandro
Kieras.
Twi2er:
@kierasbr

80. Representação
da
Arquitetura
Documento
de
Arquitetura
de
So6ware
¨ Mecanismos
de
Análise
e
Desenho
Análise Design Implementação
Persistência SGBD Relacional Oracle 10g
Mapeamento Objeto/ JPA / Toplink
Relacional
Gerência de Auditoria de Apache log4J
erros execução Registro em bancos relacional
Graphics Model-view- Java Server Faces
controller
Conteúdo dinâmico XHTML
Facelets
Java Standard Tag Library
Java Server Pages
Custom tag libraries/tag files
©
Alessandro
Kieras.
Twi2er:
@kierasbr

81. Representação
da
Arquitetura
Documento
de
Arquitetura
de
So6ware
¨ Mecanismos
de
Análise
e
Desenho
Análise Design Implementação
Gerência de N.A. EJB contêiner / WLS
transação
Segurança Criptografia DES Java Cryptographic Architecture
Tempo Temporização CommonJ
Comunicação Mensagem JMS/ EJB contêiner / WLS
Batch / XML Flat file / Apache Xerces
Protocolos Telnet, Apache Commons Net
HTTP
RMI Java RMI
CORBA Borland Visibroker client
©
Alessandro
Kieras.
Twi2er:
@kierasbr

82. Representação
da
Arquitetura
Documento
de
Arquitetura
de
So6ware
¨ Mecanismos
de
Análise
e
Desenho
Análise Design Implementação
Comunicação / Content Enricher N.A.
EIP Channel
Splitter
Mapper
Recipient List
Message Dispatcher
Message Translator
Channel Adapter
Message Filter
Aggregator
Endpoint
Loan Broker
Piper and Filter
Normalizer
Polling
©
Alessandro
Kieras.
Twi2er:
@kierasbr

83. Representação
da
Arquitetura
Documento
de
Arquitetura
de
So6ware
¨ Mecanismos
de
Análise
e
Desenho
Característica Sub-característica Implementação
Manutenibilidade Testabilidade JUnit
Testabilidade CruiseControl
Facilidade de instalação
Facilidade de instalação Groovy
Funcionalidade Interoperabilidade
Confiabilidade Tolerância
a
eventos
anormais WLS
Recuperabilidade
©
Alessandro
Kieras.
Twi2er:
@kierasbr

84. Representação
da
Arquitetura
Documento
de
Arquitetura
de
So6ware
¨ Cenários
de
Atributos
de
Qualidade
©
Alessandro
Kieras.
Twi2er:
@kierasbr

85. Representação
da
Arquitetura
Documento
de
Arquitetura
de
So6ware
¨ Cenários
de
Atributos
de
Qualidade
¤ Desempenho
Fração
do
cenário
Valores
Fonte
Fonte
de
ordens
de
serviço
(CRM)
EsMmulo
Chegada
periódica
150
eventos
por
segundo
(OS’s)
Artefato
Sistema
Ambiente
Modo
normal
(fila
média
global
de
120K
eventos)
Resposta
Processamento
normal
dos
eventos
Métrica
de
resposta
Throughput
de
150
eventos
por
segundo
©
Alessandro
Kieras.
Twi2er:
@kierasbr

86. Representação
da
Arquitetura
Documento
de
Arquitetura
de
So6ware
¨ Cenários
de
Atributos
de
Qualidade
¤ Confiabilidade
Fração
do
cenário
Valores
Fonte
Externo
ao
sistema
(plataforma)
EsMmulo
Erro
recebido
da
plataforma
Artefato
Adaptador
de
rede
Ambiente
Operação
normal
ou
degradada
Resposta
• Registro
em
log
e
histórico
• Mensagem
é
re-­‐inserida
na
fila
para
processamento
posterior
• Espera
entre
retentaGvas
para
não
sobrecarregar
a
plataforma
• Vazão
é
degradada
na
medida
que
aumenta
número
de
erros
Métrica
de
• Não
se
perde
nenhuma
informação
resposta
• Todas
mensagens
que
obGveram
erro
são
processadas
normalmente
após
remoção
do
es‚mulo
©
Alessandro
Kieras.
Twi2er:
@kierasbr

87. Conclusões

88. Conclusões
¨ Arquitetura
de
So6ware
¤ Define
estrutura
e
comportamento
do
sistema
¤ Tem
foco
nos
elementos
significaGvos
do
sistema
n Ajuda
a
tratar
a
complexidade
n Os
elements
significaGvos
podem
mudar
durante
o
projeto
¤ Influencia
a
estrutura
da
equipe
n Módulos
diferentes,
habilidades
diferentes
n Na
práGca,
a
equipe
também
influencia
a
arquitetura
¤ Balancea
as
necessidades
dos
stakeholders
©
Alessandro
Kieras.
Twi2er:
@kierasbr

89. Conclusões
¨ Arquitetura
de
So6ware
¤ Deve
ser
provada
com
código
n Provas
de
Conceito
n Arquitetura
Executável
¤ Modelo
de
Visualização
4+1
documenta
bem
uma
arquitetura
¤ A
documentação
da
arquitetura
deve
contemplar
(sempre
que
possível)
n Requisitos
de
Qualidade
(ISO
9126)
n Restrições,
Guias
e
Decisões
Arquiteturais
n Arquitetura
de
Referência
n Mecanismos
Refinados
de
Análise
à
Desenho
à
Implementação
n Cenários
de
Atributos
de
Qualidade
©
Alessandro
Kieras.
Twi2er:
@kierasbr

90. Conclusões
¨ Arquitetura
de
So6ware
é
crucial
para
a
compreensão
e
o
desenvolvimento
de
sistemas
complexos,
que
requerem
alto
nível
de
qualidade
©
Alessandro
Kieras.
Twi2er:
@kierasbr

91. Referências
¨ Sites
¤ www.sei.cmu.edu/architecture
¤ www.ibm.com/developerworks/architecture
¤ www.booch.com/architecture
¤ www.bredemeyer.com
¨ Rede
Social
¤ pangeanet.org
n A
primeira
rede
social
sobre
arquitetura
de
so6ware
do
Brasil
©
Alessandro
Kieras.
Twi2er:
@kierasbr

92. Obrigado
¨ Contato:
¤ Alessandro
Kieras
n kieras@gmail.com
n linkedin.com/in/kieras
n @kierasbr
©
Alessandro
Kieras.
Twi2er:
@kierasbr