Your SlideShare is downloading. ×
Arquitetura de Software Na Pratica
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Arquitetura de Software Na Pratica

40,822
views

Published on

Software Architecture In Practice presents software architecture concepts illustrated with a real world case study about the process of architecting, and the architecture itself, of the provisioning …

Software Architecture In Practice presents software architecture concepts illustrated with a real world case study about the process of architecting, and the architecture itself, of the provisioning system built for the largest brazilian telecommunications company. It's a 24x7 mission-critical system that is extremely reliable and scalable. Presented for PANGEA community (http://pangeanet.org/) and Unatec's Systems Architecture students.

Arquitetura de Software Na Pratica apresenta conceitos sobre arquitetura de software ilustrados com um estudo de caso real sobre o processo de arquitetar, e a própria arquitetura de software, de um sistema de aprovisionamento construído para a maior companhia de telecomunicações do Brasil. É um sistema de missão crítica 24x7 extremamente confiável e escalável. Apresentado para a comunidade PANGEA (http://pangeanet.org/) e estudantes da disciplina de Arquitetura de Sistemas na faculdade Unatec.

Published in: Technology, Business

10 Comments
104 Likes
Statistics
Notes
No Downloads
Views
Total Views
40,822
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
161
Comments
10
Likes
104
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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çãoGerência de N.A. EJB contêiner / WLStransaçãoSegurança Criptografia DES Java Cryptographic ArchitectureTempo Temporização CommonJComunicaçã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çãoComunicaçã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çãoManutenibilidade Testabilidade JUnit Testabilidade CruiseControl Facilidade de instalação Facilidade de instalação GroovyFuncionalidade InteroperabilidadeConfiabilidade 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