Arquitetura de Software Na Pratica

ARQUITETURA
DE
SOFTWARE

NA
PRÁTICA

Alessandro
Kieras

kieras@gmail.com

@kierasbr

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

Agenda

¨  ObjeGvos

¨  Arquitetura
de
So6ware

¨  Arquiteto
de
So6ware

¨  O
Desenvolvimento
de
uma
Arquitetura
de

So6ware

¨  Conclusões

©
Alessandro
Kieras.
Twi2er:
@kierasbr

ObjeGvos

¨  Compreender...

¤  O
papel
da
arquitetura
de
so6ware
em
projetos

¤  O
papel
do
proﬁssional
arquiteto
de
so6ware
e
suas

principais
atribuições

¤  Como
a
arquitetura
de
so6ware
é
aplicada
em

projetos

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Arquitetura
de
So6ware

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

Arquitetura
de
So;ware

MoGvação

¨  Projetos
complexos/maiores
exigem
arquitetura

¤  Mais
modelagem

¤  Ferramentas
mais
poderosas

¤  Processos
mais
bem
deﬁnidos

¤  Mais
projeto

¤  Alta
especialização
para
construir

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Arquitetura
de
So;ware

MoGvação

©
Alessandro
Kieras.
Twi2er:
@kierasbr

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

Arquitetura
de
So;ware

Equívocos
sobre
Arquitetura
de
So6ware

é
o
mesmo
que
Desenho

¤  Nem
todo
desenho
é
arquitetura

¤  Arquitetura
lida
com
decisões
de
desenho
mais

signiﬁcaGvas

também
lida
no
espaço
do
problema

é
a
Infra-‐Estrutura

¤  Infra-‐estrutura
é
apenas
parte
da
arquitetura

restrita
à
infra-‐estrutura
não
possui

resultados
saGsfatórios

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Arquitetura
de
So;ware

Equívocos
sobre
Arquitetura
de
So6ware

¨  A
Tecnologia
“X”
é
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

é
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

Arquitetura
de
So;ware

Equívocos
sobre
Arquitetura
de
So6ware

pode
ser
representada
em
única
visão

¤  Normalmente
não
é
suﬁciente,
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
suﬁciente
para
a
maioria
dos
casos

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Arquitetura
de
So;ware

Equívocos
sobre
Arquitetura
de
So6ware

é
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

Arquitetura
de
So;ware

Deﬁniçõ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

Arquitetura
de
So;ware

Deﬁnições

é
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

Arquitetura
de
So;ware

Importância

¨  Obter
a
“visão
geral”
do
sistema

¤  Compreender
os
elementos
importantes
do
so6ware

¨  Construir
sistemas
complexos
e
desaﬁadores

¨  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

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

¨  Deﬁnir
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

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

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
ﬁnais

¨  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

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

Arquiteto
de
So;ware

Contexto
de
Atuação

¨  Stakeholders

¤  IdenGﬁcar,
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

Arquiteto
de
So;ware

Contexto
de
Atuação

¨  Lembre-‐se
que
o
arquiteto
não
está
sozinho

©
Alessandro
Kieras.
Twi2er:
@kierasbr

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

Arquiteto
de
So;ware

Papel
e
Atribuições

¨  Deﬁnir
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

ﬁnal
do
sistema

¨  Prover
liderança
técnica

©
Alessandro
Kieras.
Twi2er:
@kierasbr

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

O
Desenvolvimento
de
uma
Arquitetura

de
So6ware

O
Desenvolvimento
de
uma

Arquitetura
de
So6ware

¨  Entendendo
um
Exemplo
Real

¨  IdenGﬁcação,
Classiﬁcação
e
Priorização
dos

Requisitos

¨  Endereçamento
de
Riscos
e
Provas
de
Conceito

¨  Representação
da
Arquitetura

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Entendendo
um
Exemplo
Real

Sistema
de
Aprovisionamento

¨  Finalidade

¤  AGvação
e
conﬁguraçã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
conﬁabilidade
e
escalabilidade
do
sistema

¤  Diminuir
custos
operacionais

¤  PermiGr
a
convergência
de
serviços

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Entendendo
um
Exemplo
Real

Sistema
de
Aprovisionamento

¨  Visão
Geral
da
Arquitetura

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Entendendo
um
Exemplo
Real

Sistema
de
Aprovisionamento

¨  Visão
Geral
de
Casos
de
Uso

©
Alessandro
Kieras.
Twi2er:
@kierasbr

IdenBﬁcação
,
Classiﬁcação
e
Priorização
dos
Requisitos

Requisitos

©
Alessandro
Kieras.
Twi2er:
@kierasbr

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

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

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

Endereçamento
de
Riscos

Riscos

¨  “Ou
você
ataca
os
riscos
ou
eles
te
atacam!”

é
fundamental
para
idenGﬁcar
os
riscos
e

trabalhar
em
estratégias
para
sua
miGgação

©
Alessandro
Kieras.
Twi2er:
@kierasbr

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

Endereçamento
de
Riscos

Riscos

¨  Falta
de
conhecimento
para
integrar
com
algumas

plataformas
(protocolos)

¤  Tipo:
Técnico


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

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


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

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
deﬁnidos
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

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

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

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

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

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

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

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
ﬁlas
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

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

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

¤  IdenGﬁca
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

Representação
da
Arquitetura

Modelo
4+1

©
Alessandro
Kieras.
Twi2er:
@kierasbr

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

Representação
da
Arquitetura

Modelo
4+1

¨  Visão
+1
=
Casos
de
Uso
(ou
Cenários)

¤  Exemplo
didáGco

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Representação
da
Arquitetura

Modelo
4+1

¨  Visão
+1
=
Casos
de
Uso
(ou
Cenários)

¤  Exemplo
real

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Representação
da
Arquitetura

Modelo
4+1

¨  Visão
Lógica

¤  Exemplo
didáGco

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Representação
da
Arquitetura

Modelo
4+1

¨  Visão
Lógica

¤  Exemplo
real

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Representação
da
Arquitetura

Modelo
4+1

¨  Visão
de
Componentes

¤  Exemplo
didáGco

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Representação
da
Arquitetura

Modelo
4+1

¨  Visão
de
Componentes

¤  Exemplo
real

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Representação
da
Arquitetura

Modelo
4+1

¨  Visão
de
Implantação

¤  Exemplo
didáGco

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Representação
da
Arquitetura

Modelo
4+1

¨  Visão
de
Implantação

¤  Exemplo
real

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Representação
da
Arquitetura

Modelo
4+1

¨  Visão
de
Processos

¤  Exemplo
didáGco

©
Alessandro
Kieras.
Twi2er:
@kierasbr

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

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

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

de
Referência

¤  Mecanismos
de
Análise
e
Desenho

¤  Cenários
de
Atributos
de
Qualidade

©
Alessandro
Kieras.
Twi2er:
@kierasbr

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

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

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

Representação
da
Arquitetura

Documento
de
Arquitetura
de
So6ware

de
Referência

¤  EsGlos
Arquiteturais

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Representação
da
Arquitetura

Documento
de
Arquitetura
de
So6ware

¨  Mecanismos
de
Análise
e
Desenho

©
Alessandro
Kieras.
Twi2er:
@kierasbr

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

Representação
da
Arquitetura

Documento
de
Arquitetura
de
So6ware

¨  Mecanismos
de
Análise
e
Desenho

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

Representação
da
Arquitetura

Documento
de
Arquitetura
de
So6ware

¨  Mecanismos
de
Análise
e
Desenho

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

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
Conﬁabilidade Tolerância
a
eventos
anormais WLS
Recuperabilidade

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Representação
da
Arquitetura

Documento
de
Arquitetura
de
So6ware

¨  Cenários
de
Atributos
de
Qualidade

©
Alessandro
Kieras.
Twi2er:
@kierasbr

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
(ﬁla
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

Representação
da
Arquitetura

Documento
de
Arquitetura
de
So6ware

¨  Cenários
de
Atributos
de
Qualidade

¤  Conﬁabilidade

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
ﬁla
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

Conclusões

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

Conclusões

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
Reﬁnados
de
Análise
à
Desenho
à
Implementação

n  Cenários
de
Atributos
de
Qualidade

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Conclusões

de
So6ware
é
crucial
para
a

compreensão
e
o
desenvolvimento
de
sistemas

complexos,
que
requerem
alto
nível
de
qualidade

©
Alessandro
Kieras.
Twi2er:
@kierasbr

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

Obrigado

¨  Contato:

¤  Alessandro
Kieras

n  kieras@gmail.com

n  linkedin.com/in/kieras

n  @kierasbr

©
Alessandro
Kieras.
Twi2er:
@kierasbr

Arquitetura de Software Na Pratica

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Arquitetura de Software Na Pratica

Ähnlich wie Arquitetura de Software Na Pratica (20)

Arquitetura de Software Na Pratica