Successfully reported this slideshow.
ARQUITETURA	  DE	  SOFTWARE	                         NA	  PRÁTICA	               Alessandro	  Kieras	               kieras...
Apresentação	  ¨     Alessandro	  Kieras	         ¤  kieras@gmail.com	         ¤  www.linkedin.com/in/kieras	         ¤...
Agenda	  ¨  ObjeGvos	  ¨  Arquitetura	  de	  So6ware	  ¨  Arquiteto	  de	  So6ware	  ¨  O	  Desenvolvimento	  de	  uma...
ObjeGvos	  ¨    Compreender...	        ¤  O	  papel	  da	  arquitetura	  de	  so6ware	  em	  projetos	        ¤  O	  pa...
Arquitetura	  de	  So6ware	  
Arquitetura	  de	  So;ware	  MoGvação	  ¨    Projetos	  simples	  podem	  ser	  realizados	  	  por	  uma	  única	       ...
Arquitetura	  de	  So;ware	  MoGvação	  ¨    Projetos	  complexos/maiores	  exigem	  arquitetura	        ¤  Mais	  model...
Arquitetura	  de	  So;ware	  MoGvação	                                     ©	  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...
Arquitetura	  de	  So;ware	  MoGvação	                                     ©	  Alessandro	  Kieras.	  Twi2er:	  @kierasbr	  
Arquitetura	  de	  So;ware	  Equívocos	  sobre	  Arquitetura	  de	  So6ware	  ¨    Arquitetura	  é	  o	  mesmo	  que	  De...
Arquitetura	  de	  So;ware	  Equívocos	  sobre	  Arquitetura	  de	  So6ware	  ¨    A	  Tecnologia	  “X”	  é	  Arquitetura...
Arquitetura	  de	  So;ware	  Equívocos	  sobre	  Arquitetura	  de	  So6ware	  ¨    Arquitetura	  pode	  ser	  representad...
Arquitetura	  de	  So;ware	  Equívocos	  sobre	  Arquitetura	  de	  So6ware	  ¨    Arquitetura	  é	  uma	  arte	  “oculta...
Arquitetura	  de	  So;ware	  Definições	  ¨    A	  arquitetura	  de	  um	  so6ware	  é	  a	  estrutura	  do	        sistem...
Arquitetura	  de	  So;ware	  Definições	  ¨    Arquitetura	  é	  a	  organização	  fundamental	  de	  um	        sistema	 ...
Arquitetura	  de	  So;ware	  Importância	  ¨    Obter	  a	  “visão	  geral”	  do	  sistema	        ¤  Compreender	  os	 ...
Arquitetura	  de	  So;ware	  Importância	  ¨    MiGgar	  riscos	  cedo	  e	  conGnuamente	        ¤  Tecnológicos,	  Hum...
Arquiteto	  de	  So6ware	  
Arquiteto	  de	  So;ware	  Contexto	  de	  Atuação	                                                 Escopo	  da	          ...
Arquiteto	  de	  So;ware	  Contexto	  de	  Atuação	  ¨    Analista	  de	  Negócios	        ¤  Interação	  especial	  qua...
Arquiteto	  de	  So;ware	  Contexto	  de	  Atuação	  ¨    Desenvolvedores	        ¤  Liderança	  técnica	  para	  garanG...
Arquiteto	  de	  So;ware	  Contexto	  de	  Atuação	  ¨    Stakeholders	        ¤  IdenGficar,	  envolver	  e	  balancear	...
Arquiteto	  de	  So;ware	  Contexto	  de	  Atuação	  ¨    Lembre-­‐se	  que	  o	  arquiteto	  não	  está	  sozinho	  	   ...
Arquiteto	  de	  So;ware	  Papel	  e	  Atribuições	  ¨  GaranGr	  que	  o	  escopo,	  contexto	  e	  restrições	  do	    ...
Arquiteto	  de	  So;ware	  Papel	  e	  Atribuições	  ¨  Definir	  e	  documentar	  estratégias,	  padrões,	  guias	      e...
Arquiteto	  de	  So;ware	  Papel	  e	  Atribuições	  ¨    Manter-­‐se	  envolvido	  com	  todo	  o	  processo	  de	      ...
O	  Desenvolvimento	  de	  uma	  Arquitetura	  de	  So6ware	  
O	  Desenvolvimento	  de	  uma	  Arquitetura	  de	  So6ware	  ¨  Entendendo	  um	  Exemplo	  Real	  ¨  IdenGficação,	  Cl...
Entendendo	  um	  Exemplo	  Real	  Sistema	  de	  Aprovisionamento	  ¨    Finalidade	        ¤  AGvação	  e	  configuraçã...
Entendendo	  um	  Exemplo	  Real	  Sistema	  de	  Aprovisionamento	  ¨    Visão	  Geral	  da	  Arquitetura	              ...
Entendendo	  um	  Exemplo	  Real	  Sistema	  de	  Aprovisionamento	  ¨    Visão	  Geral	  de	  Casos	  de	  Uso	         ...
O	  Desenvolvimento	  de	  uma	  Arquitetura	  de	  So6ware	  ¨  Entendendo	  um	  Exemplo	  Real	  ¨  IdenGficação,	  Cl...
IdenBficação	  ,	  Classificação	  e	  Priorização	  dos	  Requisitos	  Requisitos	                                         ...
IdenBficação	  ,	  Classificação	  e	  Priorização	  dos	  Requisitos	  Requisitos	                                         ...
IdenBficação	  ,	  Classificação	  e	  Priorização	  dos	  Requisitos	  Requisitos	         Categoria	           Subcategori...
IdenBficação	  ,	  Classificação	  e	  Priorização	  dos	  Requisitos	  Requisitos	          Categoria	              Subcate...
IdenBficação	  ,	  Classificação	  e	  Priorização	  dos	  Requisitos	  Requisitos	        Categoria	             Subcategor...
O	  Desenvolvimento	  de	  uma	  Arquitetura	  de	  So6ware	  ¨  Entendendo	  um	  Exemplo	  Real	  ¨  IdenGficação,	  Cl...
Endereçamento	  de	  Riscos	  Riscos	  ¨    “Ou	  você	  ataca	  os	  riscos	  ou	  eles	  te	  atacam!”	        ¤  Arqu...
Endereçamento	  de	  Riscos	  Riscos	  ¨    Prazo	  impossível	  de	  ser	  cumprido	        ¤  Tipo:	  Gerencial	      ...
Endereçamento	  de	  Riscos	  Riscos	  ¨    Falta	  de	  conhecimento	  para	  integrar	  com	  algumas	        plataform...
Endereçamento	  de	  Riscos	  Riscos	  ¨    Falta	  de	  conhecimento	  da	  equipe	  nas	  ferramentas	        a	  serem...
Endereçamento	  de	  Riscos	  Riscos	  ¨  Outros	  riscos	  técnicos	  foram	  tratados	  através	  de	      provas	  de	...
Endereçamento	  de	  Riscos	  Provas	  de	  Conceito	  (Fase	  1)	                  #            Descrição POC            ...
Endereçamento	  de	  Riscos	  Provas	  de	  Conceito	  (Fase	  2)	       Grupo                     Prova de Conceito      ...
Endereçamento	  de	  Riscos	  Resultado	  PoC	  ServiceMix	  ¨    Distribuição	  em	  nós	  disGntos	        ¤  O	  test...
Endereçamento	  de	  Riscos	  Resultado	  PoC	  ServiceMix	  ¨    Balanceamento	  de	  carga	        ¤  A	  distribuição...
Endereçamento	  de	  Riscos	  Resultado	  PoC	  ServiceMix	  ¨    Tolerância	  à	  falhas	        ¤  No	  teste	  de	  t...
Endereçamento	  de	  Riscos	  Resultado	  PoC	  ServiceMix	  ¨    Desempenho,	  Uso	  do	  Tempo,	  Carga	        ¤  Um	...
Endereçamento	  de	  Riscos	  Resultado	  PoC	  ServiceMix	  ¨    Avaliação	  Geral	        ¤  No	  geral	  a	  aplicaçã...
Endereçamento	  de	  Riscos	  Resultado	  PoC	  ServiceMix	                                                               ...
O	  Desenvolvimento	  de	  uma	  Arquitetura	  de	  So6ware	  ¨  Entendendo	  um	  Exemplo	  Real	  ¨  IdenGficação,	  Cl...
Representação	  da	  Arquitetura	  Documentação	  da	  Arquitetura	  ¨    A	  documentação	  da	  arquitetura	  de	  so6w...
Representação	  da	  Arquitetura	  Modelo	  4+1	                                           ©	  Alessandro	  Kieras.	  Twi2...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  +1	  =	  Casos	  de	  Uso	  (ou	  Cenários)	        ¤  Re...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  +1	  =	  Casos	  de	  Uso	  (ou	  Cenários)	        ¤  Ex...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  +1	  =	  Casos	  de	  Uso	  (ou	  Cenários)	        ¤  Ex...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  +1	  =	  Casos	  de	  Uso	  (ou	  Cenários)	        ¤  Ex...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  Lógica	        ¤  Exemplo	  didáGco	                     ...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  Lógica	        ¤  Exemplo	  real	                        ...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  Lógica	        ¤  Exemplo	  real	                        ...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  Lógica	        ¤  Exemplo	  real	                        ...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  de	  Componentes	        ¤  Exemplo	  didáGco	           ...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  de	  Componentes	        ¤  Exemplo	  real	              ...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  de	  Implantação	        ¤  Exemplo	  didáGco	           ...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  de	  Implantação	        ¤  Exemplo	  real	              ...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  de	  Implantação	        ¤  Exemplo	  real	              ...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  de	  Processos	        ¤  Exemplo	  didáGco	             ...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Visão	  de	  Processos	        ¤  Exemplo	  real	                ...
Representação	  da	  Arquitetura	  Modelo	  4+1	  ¨    Nem	  todas	  visões	  são	  sempre	  necessárias	  ¨    As	  vis...
Representação	  da	  Arquitetura	  Documento	  de	  Arquitetura	  de	  So6ware	  ¨  O	  DAS	  deve	  prover	  uma	  visão...
Representação	  da	  Arquitetura	  Documento	  de	  Arquitetura	  de	  So6ware	  ¨    Requisitos	  de	  Qualidade	       ...
Representação	  da	  Arquitetura	   Documento	  de	  Arquitetura	  de	  So6ware	   ¨    Restrições	  ou	  Decisões	  Arqu...
Representação	  da	  Arquitetura	  Documento	  de	  Arquitetura	  de	  So6ware	  ¨    Restrições	  ou	  Decisões	  Arquit...
Representação	  da	  Arquitetura	  Documento	  de	  Arquitetura	  de	  So6ware	  ¨    Arquitetura	  de	  Referência	     ...
Representação	  da	  Arquitetura	  Documento	  de	  Arquitetura	  de	  So6ware	  ¨    Arquitetura	  de	  Referência	     ...
Representação	  da	  Arquitetura	  Documento	  de	  Arquitetura	  de	  So6ware	  ¨    Mecanismos	  de	  Análise	  e	  Des...
Representação	  da	  Arquitetura	  Documento	  de	  Arquitetura	  de	  So6ware	  ¨    Mecanismos	  de	  Análise	  e	  Des...
Representação	  da	  Arquitetura	    Documento	  de	  Arquitetura	  de	  So6ware	    ¨    Mecanismos	  de	  Análise	  e	 ...
Representação	  da	  Arquitetura	      Documento	  de	  Arquitetura	  de	  So6ware	      ¨    Mecanismos	  de	  Análise	 ...
Representação	  da	  Arquitetura	  Documento	  de	  Arquitetura	  de	  So6ware	  ¨    Mecanismos	  de	  Análise	  e	  Des...
Representação	  da	  Arquitetura	  Documento	  de	  Arquitetura	  de	  So6ware	  ¨    Cenários	  de	  Atributos	  de	  Qu...
Representação	  da	  Arquitetura	   Documento	  de	  Arquitetura	  de	  So6ware	   ¨    Cenários	  de	  Atributos	  de	  ...
Representação	  da	  Arquitetura	   Documento	  de	  Arquitetura	  de	  So6ware	   ¨    Cenários	  de	  Atributos	  de	  ...
Conclusões	  
Conclusões	  ¨    Arquitetura	  de	  So6ware	        ¤  Define	  estrutura	  e	  comportamento	  do	  sistema	        ¤ ...
Conclusões	  ¨    Arquitetura	  de	  So6ware	        ¤    Deve	  ser	  provada	  com	  código	              n  Provas	 ...
Conclusões	  ¨    Arquitetura	  de	  So6ware	  é	  crucial	  para	  a	        compreensão	  e	  o	  desenvolvimento	  de	...
Referências	  ¨    Sites	        ¤  www.sei.cmu.edu/architecture	        ¤  www.ibm.com/developerworks/architecture	   ...
Obrigado	  ¨    Contato:	        ¤  Alessandro	  Kieras	           n  kieras@gmail.com	           n  linkedin.com/in/k...
Upcoming SlideShare
Loading in …5
×

Arquitetura de Software Na Pratica

48,527 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 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

Arquitetura de Software Na Pratica

  1. 1. ARQUITETURA  DE  SOFTWARE   NA  PRÁTICA   Alessandro  Kieras   kieras@gmail.com   @kierasbr  
  2. 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. 3. Agenda  ¨  ObjeGvos  ¨  Arquitetura  de  So6ware  ¨  Arquiteto  de  So6ware  ¨  O  Desenvolvimento  de  uma  Arquitetura  de   So6ware  ¨  Conclusões   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  4. 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. 5. Arquitetura  de  So6ware  
  6. 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. 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. 8. Arquitetura  de  So;ware  MoGvação   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  9. 9. Arquitetura  de  So;ware  MoGvação   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  10. 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. 11. Arquitetura  de  So;ware  MoGvação   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  12. 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. 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. 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. 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. 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. 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. 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. 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. 20. Arquiteto  de  So6ware  
  21. 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. 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. 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. 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. 25. Arquiteto  de  So;ware  Contexto  de  Atuação  ¨  Lembre-­‐se  que  o  arquiteto  não  está  sozinho     ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  26. 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. 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. 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. 29. O  Desenvolvimento  de  uma  Arquitetura  de  So6ware  
  30. 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. 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. 32. Entendendo  um  Exemplo  Real  Sistema  de  Aprovisionamento  ¨  Visão  Geral  da  Arquitetura   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  33. 33. Entendendo  um  Exemplo  Real  Sistema  de  Aprovisionamento  ¨  Visão  Geral  de  Casos  de  Uso   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  34. 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. 35. IdenBficação  ,  Classificação  e  Priorização  dos  Requisitos  Requisitos   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  36. 36. IdenBficação  ,  Classificação  e  Priorização  dos  Requisitos  Requisitos   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  37. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 56. Representação  da  Arquitetura  Modelo  4+1   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  57. 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. 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. 59. Representação  da  Arquitetura  Modelo  4+1  ¨  Visão  +1  =  Casos  de  Uso  (ou  Cenários)   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  60. 60. Representação  da  Arquitetura  Modelo  4+1  ¨  Visão  +1  =  Casos  de  Uso  (ou  Cenários)   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  61. 61. Representação  da  Arquitetura  Modelo  4+1  ¨  Visão  Lógica   ¤  Exemplo  didáGco   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  62. 62. Representação  da  Arquitetura  Modelo  4+1  ¨  Visão  Lógica   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  63. 63. Representação  da  Arquitetura  Modelo  4+1  ¨  Visão  Lógica   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  64. 64. Representação  da  Arquitetura  Modelo  4+1  ¨  Visão  Lógica   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  65. 65. Representação  da  Arquitetura  Modelo  4+1  ¨  Visão  de  Componentes   ¤  Exemplo  didáGco   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  66. 66. Representação  da  Arquitetura  Modelo  4+1  ¨  Visão  de  Componentes   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  67. 67. Representação  da  Arquitetura  Modelo  4+1  ¨  Visão  de  Implantação   ¤  Exemplo  didáGco   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  68. 68. Representação  da  Arquitetura  Modelo  4+1  ¨  Visão  de  Implantação   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  69. 69. Representação  da  Arquitetura  Modelo  4+1  ¨  Visão  de  Implantação   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  70. 70. Representação  da  Arquitetura  Modelo  4+1  ¨  Visão  de  Processos   ¤  Exemplo  didáGco   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  71. 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. 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. 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. 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. 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. 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. 77. Representação  da  Arquitetura  Documento  de  Arquitetura  de  So6ware  ¨  Arquitetura  de  Referência   ¤  EsGlos  Arquiteturais   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  78. 78. Representação  da  Arquitetura  Documento  de  Arquitetura  de  So6ware  ¨  Arquitetura  de  Referência   ¤  EsGlos  Arquiteturais   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  79. 79. Representação  da  Arquitetura  Documento  de  Arquitetura  de  So6ware  ¨  Mecanismos  de  Análise  e  Desenho   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  80. 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. 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. 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. 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. 84. Representação  da  Arquitetura  Documento  de  Arquitetura  de  So6ware  ¨  Cenários  de  Atributos  de  Qualidade   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  85. 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. 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. 87. Conclusões  
  88. 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. 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. 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. 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. 92. Obrigado  ¨  Contato:   ¤  Alessandro  Kieras   n  kieras@gmail.com   n  linkedin.com/in/kieras   n  @kierasbr   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  

×