SlideShare uma empresa Scribd logo
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	
  profissional	
  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	
  definidos	
  
      ¤  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	
  




                                   ©	
  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	
  

MoGvação	
  




                                   ©	
  Alessandro	
  Kieras.	
  Twi2er:	
  @kierasbr	
  
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	
  
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	
  
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	
  
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	
  
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	
  
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	
  
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	
  
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	
  
Arquiteto	
  de	
  So6ware	
  
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	
  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	
  
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	
  
      ¤  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	
  
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	
  
¨  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	
  
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	
  
¨  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	
  
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	
  
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	
  
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	
  
IdenBficação	
  ,	
  Classificação	
  e	
  Priorização	
  dos	
  Requisitos	
  

Requisitos	
  




                                                                     ©	
  Alessandro	
  Kieras.	
  Twi2er:	
  @kierasbr	
  
IdenBficação	
  ,	
  Classificaçã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	
  
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	
  
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	
  
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	
  
      ¤  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	
  
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	
  
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	
  
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	
  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	
  
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	
  
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	
  
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	
  
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	
  +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	
  Lógica	
  
      ¤  Exemplo	
  real	
  




                                         ©	
  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	
  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	
  

      ¤  Arquitetura	
  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	
  

¨    Arquitetura	
  de	
  Referência	
  
      ¤  EsGlos	
  Arquiteturais	
  




                                            ©	
  Alessandro	
  Kieras.	
  Twi2er:	
  @kierasbr	
  
Representação	
  da	
  Arquitetura	
  

Documento	
  de	
  Arquitetura	
  de	
  So6ware	
  

¨    Arquitetura	
  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	
  
      Análise                         Design                Implementação
Gerência de                 N.A.                 EJB contêiner / WLS
transação
Segurança                   Criptografia DES     Java Cryptographic Architecture
Tempo                       Temporização         CommonJ
Comunicação                 Mensagem             JMS/ EJB contêiner / WLS
                            Batch / XML          Flat file / Apache Xerces
                            Protocolos Telnet,   Apache Commons Net
                            HTTP
                            RMI                  Java RMI
                            CORBA                Borland Visibroker client




                                                    ©	
  Alessandro	
  Kieras.	
  Twi2er:	
  @kierasbr	
  
Representação	
  da	
  Arquitetura	
  

    Documento	
  de	
  Arquitetura	
  de	
  So6ware	
  

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

Documento	
  de	
  Arquitetura	
  de	
  So6ware	
  

¨    Mecanismos	
  de	
  Análise	
  e	
  Desenho	
  
Característica                Sub-característica                             Implementação
Manutenibilidade              Testabilidade                                  JUnit
                              Testabilidade                                  CruiseControl
                              Facilidade de instalação
                              Facilidade de instalação                       Groovy
Funcionalidade                Interoperabilidade
Confiabilidade                 Tolerância	
  a	
  eventos	
  anormais         WLS
                              Recuperabilidade	
  




                                                               ©	
  Alessandro	
  Kieras.	
  Twi2er:	
  @kierasbr	
  
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	
  (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	
  
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	
  
Conclusões	
  
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	
  
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	
  
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	
  
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	
  

Mais conteúdo relacionado

Mais procurados

Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
Fábio Nogueira de Lucena
 
Arquitetura de Software EXPLICADA
Arquitetura de Software EXPLICADAArquitetura de Software EXPLICADA
Arquitetura de Software EXPLICADA
Fábio Nogueira de Lucena
 
Arquitetura orientada a serviços (SOA)
Arquitetura orientada a serviços (SOA)Arquitetura orientada a serviços (SOA)
Arquitetura orientada a serviços (SOA)
Helio Henrique L. C. Monte-Alto
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
Elaine Cecília Gatto
 
Desenvolvimento de aplicações para dispositivos móveis
Desenvolvimento de aplicações para dispositivos móveisDesenvolvimento de aplicações para dispositivos móveis
Desenvolvimento de aplicações para dispositivos móveis
Marcelo Quinta
 
Modelo V - Desenvolvimento de Software
Modelo V - Desenvolvimento de SoftwareModelo V - Desenvolvimento de Software
Modelo V - Desenvolvimento de Software
Bruno Bitencourt Luiz
 
Padrões Arquiteturais de Sistemas
Padrões Arquiteturais de SistemasPadrões Arquiteturais de Sistemas
Padrões Arquiteturais de Sistemas
Vagner Santana
 
Modelos de Processo de Software Parte 3
Modelos de Processo de Software Parte 3Modelos de Processo de Software Parte 3
Modelos de Processo de Software Parte 3
Elaine Cecília Gatto
 
Android - Programação para dispositivos móveis (Aula 1)
Android - Programação para dispositivos móveis (Aula 1)Android - Programação para dispositivos móveis (Aula 1)
Android - Programação para dispositivos móveis (Aula 1)
Ricardo Longa
 
A importância da arquitetura de software
A importância da arquitetura de softwareA importância da arquitetura de software
A importância da arquitetura de software
Adriano Tavares
 
Modelo cascata
Modelo cascataModelo cascata
Modelo cascata
Priscila Comparsi
 
Programação Orientada a Objetos com Java
Programação Orientada a Objetos com JavaProgramação Orientada a Objetos com Java
Programação Orientada a Objetos com Java
Álvaro Farias Pinheiro
 
Introdução sobre desenvolvimento web
Introdução sobre desenvolvimento webIntrodução sobre desenvolvimento web
Introdução sobre desenvolvimento web
Rodrigo Rodrigues
 
Arquitetura de Software - Uma visão gerencial
Arquitetura de Software - Uma visão gerencialArquitetura de Software - Uma visão gerencial
Arquitetura de Software - Uma visão gerencial
Alexandre Leão
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
Leinylson Fontinele
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
Nécio de Lima Veras
 
Heurística, Principios e Usabilidade na web
Heurística, Principios e Usabilidade na webHeurística, Principios e Usabilidade na web
Heurística, Principios e Usabilidade na web
Daniel Brandão
 
Extreme programming (xp)
 Extreme programming   (xp) Extreme programming   (xp)
Extreme programming (xp)
João Carlos Ottobboni
 
Testes de Software
Testes de SoftwareTestes de Software
Testes de Software
Capgemini
 
Metodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de SoftwareMetodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de Software
Álvaro Farias Pinheiro
 

Mais procurados (20)

Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Arquitetura de Software EXPLICADA
Arquitetura de Software EXPLICADAArquitetura de Software EXPLICADA
Arquitetura de Software EXPLICADA
 
Arquitetura orientada a serviços (SOA)
Arquitetura orientada a serviços (SOA)Arquitetura orientada a serviços (SOA)
Arquitetura orientada a serviços (SOA)
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
 
Desenvolvimento de aplicações para dispositivos móveis
Desenvolvimento de aplicações para dispositivos móveisDesenvolvimento de aplicações para dispositivos móveis
Desenvolvimento de aplicações para dispositivos móveis
 
Modelo V - Desenvolvimento de Software
Modelo V - Desenvolvimento de SoftwareModelo V - Desenvolvimento de Software
Modelo V - Desenvolvimento de Software
 
Padrões Arquiteturais de Sistemas
Padrões Arquiteturais de SistemasPadrões Arquiteturais de Sistemas
Padrões Arquiteturais de Sistemas
 
Modelos de Processo de Software Parte 3
Modelos de Processo de Software Parte 3Modelos de Processo de Software Parte 3
Modelos de Processo de Software Parte 3
 
Android - Programação para dispositivos móveis (Aula 1)
Android - Programação para dispositivos móveis (Aula 1)Android - Programação para dispositivos móveis (Aula 1)
Android - Programação para dispositivos móveis (Aula 1)
 
A importância da arquitetura de software
A importância da arquitetura de softwareA importância da arquitetura de software
A importância da arquitetura de software
 
Modelo cascata
Modelo cascataModelo cascata
Modelo cascata
 
Programação Orientada a Objetos com Java
Programação Orientada a Objetos com JavaProgramação Orientada a Objetos com Java
Programação Orientada a Objetos com Java
 
Introdução sobre desenvolvimento web
Introdução sobre desenvolvimento webIntrodução sobre desenvolvimento web
Introdução sobre desenvolvimento web
 
Arquitetura de Software - Uma visão gerencial
Arquitetura de Software - Uma visão gerencialArquitetura de Software - Uma visão gerencial
Arquitetura de Software - Uma visão gerencial
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
 
Heurística, Principios e Usabilidade na web
Heurística, Principios e Usabilidade na webHeurística, Principios e Usabilidade na web
Heurística, Principios e Usabilidade na web
 
Extreme programming (xp)
 Extreme programming   (xp) Extreme programming   (xp)
Extreme programming (xp)
 
Testes de Software
Testes de SoftwareTestes de Software
Testes de Software
 
Metodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de SoftwareMetodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de Software
 

Semelhante a Arquitetura de Software Na Pratica

Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
Jairo Junior
 
Arquitetura da Informacao na WEB
Arquitetura da Informacao na WEBArquitetura da Informacao na WEB
Arquitetura da Informacao na WEB
Fábio Flatschart
 
aula1introducaoarquitetura.pdf
aula1introducaoarquitetura.pdfaula1introducaoarquitetura.pdf
aula1introducaoarquitetura.pdf
Antonio Lobato
 
Engenheiro ou arquiteto? - M²Obras
Engenheiro ou arquiteto? - M²ObrasEngenheiro ou arquiteto? - M²Obras
Engenheiro ou arquiteto? - M²Obras
M2OBRAS
 
Não deixe seu projeto só nas mãos do framework
Não deixe seu projeto só nas mãos do frameworkNão deixe seu projeto só nas mãos do framework
Não deixe seu projeto só nas mãos do framework
Giuseppe Lopes
 
FIT e IFSP - Arquitetura (evolucionária) e o papel do arquiteto
FIT e IFSP - Arquitetura (evolucionária) e o papel do arquitetoFIT e IFSP - Arquitetura (evolucionária) e o papel do arquiteto
FIT e IFSP - Arquitetura (evolucionária) e o papel do arquiteto
Leandro Daniel
 
Metodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareMetodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de Software
Adolfo Neto
 
Seu código fonte é sustentável?
Seu código fonte é sustentável?Seu código fonte é sustentável?
Seu código fonte é sustentável?
Isaac de Souza
 
InfoQ Brasil - Arquitetando o Futuro da TI - Por Wagner Santos
InfoQ Brasil -  Arquitetando o Futuro da TI - Por Wagner SantosInfoQ Brasil -  Arquitetando o Futuro da TI - Por Wagner Santos
InfoQ Brasil - Arquitetando o Futuro da TI - Por Wagner Santos
Manoel Pimentel Medeiros
 
TDC 2012 - Fishbowl conversation sobre Arquitetura
TDC 2012 - Fishbowl conversation sobre ArquiteturaTDC 2012 - Fishbowl conversation sobre Arquitetura
TDC 2012 - Fishbowl conversation sobre Arquitetura
Leandro Daniel
 
Formação de custos de projetos estruturais
Formação de custos de projetos estruturaisFormação de custos de projetos estruturais
Formação de custos de projetos estruturais
Val Bordin
 
Arquitetura de Software em Equipes Ágeis
Arquitetura de Software em Equipes ÁgeisArquitetura de Software em Equipes Ágeis
Arquitetura de Software em Equipes Ágeis
Joao Paulo Oliveira dos Santos
 
Ddd e software architecture
Ddd e software architectureDdd e software architecture
Ddd e software architecture
Gabriel Faraday
 
Aula1 dia 22 02 2022.pdf
Aula1  dia 22 02 2022.pdfAula1  dia 22 02 2022.pdf
Aula1 dia 22 02 2022.pdf
MarcondesTiburcio
 
Arquitetura de Software 101
Arquitetura de Software 101Arquitetura de Software 101
Arquitetura de Software 101
Leandro Silva
 
Macro Arquitetura de Software
Macro Arquitetura de SoftwareMacro Arquitetura de Software
Macro Arquitetura de Software
Edjalma Queiroz da Silva
 
Arquitetura e qualidade de codigo
Arquitetura e qualidade de codigoArquitetura e qualidade de codigo
Arquitetura e qualidade de codigo
Thamara Hessel
 
Projetos Estruturados de Redes - Parte 1
Projetos Estruturados de Redes - Parte 1Projetos Estruturados de Redes - Parte 1
Projetos Estruturados de Redes - Parte 1
José Wagner Bungart
 
O uso de softwares na engenharia civil
O uso de softwares na engenharia civilO uso de softwares na engenharia civil
O uso de softwares na engenharia civil
debvieir
 
TDC 2011 (Florianópolis) - Entendendo a Arquitetura Evolucionária
TDC 2011 (Florianópolis) - Entendendo a Arquitetura EvolucionáriaTDC 2011 (Florianópolis) - Entendendo a Arquitetura Evolucionária
TDC 2011 (Florianópolis) - Entendendo a Arquitetura Evolucionária
Leandro Daniel
 

Semelhante a Arquitetura de Software Na Pratica (20)

Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Arquitetura da Informacao na WEB
Arquitetura da Informacao na WEBArquitetura da Informacao na WEB
Arquitetura da Informacao na WEB
 
aula1introducaoarquitetura.pdf
aula1introducaoarquitetura.pdfaula1introducaoarquitetura.pdf
aula1introducaoarquitetura.pdf
 
Engenheiro ou arquiteto? - M²Obras
Engenheiro ou arquiteto? - M²ObrasEngenheiro ou arquiteto? - M²Obras
Engenheiro ou arquiteto? - M²Obras
 
Não deixe seu projeto só nas mãos do framework
Não deixe seu projeto só nas mãos do frameworkNão deixe seu projeto só nas mãos do framework
Não deixe seu projeto só nas mãos do framework
 
FIT e IFSP - Arquitetura (evolucionária) e o papel do arquiteto
FIT e IFSP - Arquitetura (evolucionária) e o papel do arquitetoFIT e IFSP - Arquitetura (evolucionária) e o papel do arquiteto
FIT e IFSP - Arquitetura (evolucionária) e o papel do arquiteto
 
Metodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareMetodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de Software
 
Seu código fonte é sustentável?
Seu código fonte é sustentável?Seu código fonte é sustentável?
Seu código fonte é sustentável?
 
InfoQ Brasil - Arquitetando o Futuro da TI - Por Wagner Santos
InfoQ Brasil -  Arquitetando o Futuro da TI - Por Wagner SantosInfoQ Brasil -  Arquitetando o Futuro da TI - Por Wagner Santos
InfoQ Brasil - Arquitetando o Futuro da TI - Por Wagner Santos
 
TDC 2012 - Fishbowl conversation sobre Arquitetura
TDC 2012 - Fishbowl conversation sobre ArquiteturaTDC 2012 - Fishbowl conversation sobre Arquitetura
TDC 2012 - Fishbowl conversation sobre Arquitetura
 
Formação de custos de projetos estruturais
Formação de custos de projetos estruturaisFormação de custos de projetos estruturais
Formação de custos de projetos estruturais
 
Arquitetura de Software em Equipes Ágeis
Arquitetura de Software em Equipes ÁgeisArquitetura de Software em Equipes Ágeis
Arquitetura de Software em Equipes Ágeis
 
Ddd e software architecture
Ddd e software architectureDdd e software architecture
Ddd e software architecture
 
Aula1 dia 22 02 2022.pdf
Aula1  dia 22 02 2022.pdfAula1  dia 22 02 2022.pdf
Aula1 dia 22 02 2022.pdf
 
Arquitetura de Software 101
Arquitetura de Software 101Arquitetura de Software 101
Arquitetura de Software 101
 
Macro Arquitetura de Software
Macro Arquitetura de SoftwareMacro Arquitetura de Software
Macro Arquitetura de Software
 
Arquitetura e qualidade de codigo
Arquitetura e qualidade de codigoArquitetura e qualidade de codigo
Arquitetura e qualidade de codigo
 
Projetos Estruturados de Redes - Parte 1
Projetos Estruturados de Redes - Parte 1Projetos Estruturados de Redes - Parte 1
Projetos Estruturados de Redes - Parte 1
 
O uso de softwares na engenharia civil
O uso de softwares na engenharia civilO uso de softwares na engenharia civil
O uso de softwares na engenharia civil
 
TDC 2011 (Florianópolis) - Entendendo a Arquitetura Evolucionária
TDC 2011 (Florianópolis) - Entendendo a Arquitetura EvolucionáriaTDC 2011 (Florianópolis) - Entendendo a Arquitetura Evolucionária
TDC 2011 (Florianópolis) - Entendendo a Arquitetura Evolucionária
 

Último

História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
TomasSousa7
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
Momento da Informática
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
Momento da Informática
 
DESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdf
DESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdfDESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdf
DESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdf
Momento da Informática
 
Manual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdfManual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdf
WELITONNOGUEIRA3
 
Certificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdfCertificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdf
joaovmp3
 

Último (6)

História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
 
DESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdf
DESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdfDESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdf
DESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdf
 
Manual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdfManual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdf
 
Certificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdfCertificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdf
 

Arquitetura de Software Na Pratica

  • 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  
  • 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  
  • 21. Arquiteto  de  So;ware   Contexto  de  Atuação   Escopo  da   decisão   Sem    muita   importância   Foco  do   para    o   Arquiteto   arquiteto   Impacto  da   decisão   Sem    muita   Normalmente   importância   não  é  foco  do   para    o   arquiteto   arquiteto   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 22. Arquiteto  de  So;ware   Contexto  de  Atuação   ¨  Analista  de  Negócios   ¤  Interação  especial  quando  está  lidando  com  visões  e   requisitos  ligados  aos  usuários  finais   ¨  Gerente  de  Projetos   ¤  Auxiliar  no  desenvolvimento  de  planos  ou  avaliá-­‐los   ¤  Prover  informações  técnicas,  feedback,  conselhos,   avaliação  de  riscos  etc   ¨  Especialistas  em  tecnologia   ¤  Obter  informações  detalhadas  sobre  uma  tecnologia   ¤  Suas  aplicações  e  restrições   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 23. Arquiteto  de  So;ware   Contexto  de  Atuação   ¨  Desenvolvedores   ¤  Liderança  técnica  para  garanGr  aderência  à   arquitetura   ¤  Auxílio,  acompanhamento  e  revisão  de  desenhos   produzidos  pela  equipe   ¤  Mentoring  e  treinamento   ¤  Envolvimento  em  testes  de  sistema  e  integrados   ¤  Desenvolver  código,  se  necessário   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 24. Arquiteto  de  So;ware   Contexto  de  Atuação   ¨  Stakeholders   ¤  IdenGficar,  envolver  e  balancear  as  necessidades   ¤  Alinhar  as  expectaGvas  com  o  objeGvo  do  projeto   n  Usuário  Final  à  funções  corretas,  usabilidade   n  Administrador  à  ferramentas  para  monitoração   n  MarkeGng  à  conjunto  de  features,  “Gme  to  market”   n  Cliente  à  preço,  features   n  Desenvolvedor  à  requisitos  claros,  bom  desenho   n  Gerente  à  uso  produGvo  de  recursos,  prazo,  custo   n  Suporte  à  documentação  clara,  gerenciabilidade   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 25. Arquiteto  de  So;ware   Contexto  de  Atuação   ¨  Lembre-­‐se  que  o  arquiteto  não  está  sozinho     ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 26. Arquiteto  de  So;ware   Papel  e  Atribuições   ¨  GaranGr  que  o  escopo,  contexto  e  restrições  do   projeto  são  documentados  e  aceitos   ¨  IdenGficar  e  envolver  os  diversos  stakeholders   ¨  Facilitar  a  decisão  dos  stakeholders,  fornecendo   informações,  mostrando  trade-­‐offs,  alinhando  os   objeGvos  gerais   ¨  Definir  e  documentar  a  estrutura  e  a  forma  do   sistema   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 27. Arquiteto  de  So;ware   Papel  e  Atribuições   ¨  Definir  e  documentar  estratégias,  padrões,  guias   etc  para  direcionar  a  construção  do  sistema   ¨  GaranGr  que  a  arquitetura  contemple  os  atributos   de  qualidade  do  sistema   ¨  Desenvolver  a  descrição  arquitetural   ¨  Ajudar  a  garanGr  que  a  arquitetura  é  aplicada  até  o   final  do  sistema   ¨  Prover  liderança  técnica   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 28. Arquiteto  de  So;ware   Papel  e  Atribuições   ¨  Manter-­‐se  envolvido  com  todo  o  processo  de   desenvolvimento   Grau  de  Envolvimento   Requisitos   Desenho   Código/Teste   Integração   Aceitação   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 29. O  Desenvolvimento  de  uma  Arquitetura   de  So6ware  
  • 30. O  Desenvolvimento  de  uma   Arquitetura  de  So6ware   ¨  Entendendo  um  Exemplo  Real   ¨  IdenGficação,  Classificação  e  Priorização  dos   Requisitos   ¨  Endereçamento  de  Riscos  e  Provas  de  Conceito   ¨  Representação  da  Arquitetura   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 31. Entendendo  um  Exemplo  Real   Sistema  de  Aprovisionamento   ¨  Finalidade   ¤  AGvação  e  configuração  de  serviços  nas  plataformas  de   telecomunicações  através  do  processamento  de  ordens  de   serviço   ¨  Missão  do  Projeto/Produto   ¤  SubsGtuir  o  sistema  de  aprovisionamento  atual   ¤  Aumentar  a  capacidade  do  sistema  para  suportar  1  milhão   de  transações/dia   ¤  Aumentar  a  confiabilidade  e  escalabilidade  do  sistema   ¤  Diminuir  custos  operacionais   ¤  PermiGr  a  convergência  de  serviços   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 32. Entendendo  um  Exemplo  Real   Sistema  de  Aprovisionamento   ¨  Visão  Geral  da  Arquitetura   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 33. Entendendo  um  Exemplo  Real   Sistema  de  Aprovisionamento   ¨  Visão  Geral  de  Casos  de  Uso   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 34. O  Desenvolvimento  de  uma   Arquitetura  de  So6ware   ¨  Entendendo  um  Exemplo  Real   ¨  IdenGficação,  Classificação  e  Priorização  dos   Requisitos   ¨  Endereçamento  de  Riscos  e  Provas  de  Conceito   ¨  Representação  da  Arquitetura   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 35. IdenBficação  ,  Classificação  e  Priorização  dos  Requisitos   Requisitos   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 36. IdenBficação  ,  Classificação  e  Priorização  dos  Requisitos   Requisitos   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 37. IdenBficação  ,  Classificação  e  Priorização  dos  Requisitos   Requisitos   Categoria   Subcategoria   Requisito   Prior   Comp   Pond   Integração  online  com  WLI   5   2   10   Integração  batch  com  SIEBEL   5   2   10   Comunicação  com  plataforma  HLR  Nokia   5   3   15   Comunicação  com  plataforma  PMS/BLL   5   5   25   Comunicação  com  a  Plataforma  SMSC   5   3   15   Interoperabilidade   Comunicação  com  a  Plataforma  OTA   5   3   15   Comunicação  com  a  Plataforma  PSA   5   3   15   Funcionalidade   Comunicação  com  a  Plataforma  NMS   5   3   15   Comunicação  com  a  Plataforma  VMS   5   5   25   Comunicação  com  a  Plataforma  PTT   5   3   15   Comunicação  com  a  Plataforma  OSC   5   5   25   Integração  com  Oracle  10g   4   1   4   Padronização   Conformidade  Java  EE  5   4   1   4   Cadastro  de  usuários   3   2   6   Segurança   Acesso  por  papéis   3   3   9   Criptografia     5   2   10   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 38. IdenBficação  ,  Classificação  e  Priorização  dos  Requisitos   Requisitos   Categoria   Subcategoria   Requisito   Prior   Comp   Pond   Facilidade  de  Análise   Histórico  de  comandos   5   5   25   Manutenção   Monitoração  de  filas   4   4   16   Testabilidade   Emprego  de  testes  unitários   3   2   6   Emprego  de  plataformas  mock   3   4   12   Facilidade  de  Instalação   Implantação  a  quente  de  comandos   4   4   16   Adaptabilidade   Execução  em  BEA  WebLogic  Server  10   5   3   15   Portabilidade   Sistema  operacional  HPUX   5   2   10   Facilidade  de  Troca   Reinstalação  de  componentes  Java/JEE   4   2   8   Reinstalação  transparente  de  novos  comandos   4   4   16   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 39. IdenBficação  ,  Classificação  e  Priorização  dos  Requisitos   Requisitos   Categoria   Subcategoria   Requisito   Prior   Comp   Pond   Maturidade   Disponibilidade  24  x  7  /  99,9%   4   5   20   Tolerância  a  falhas   Integridade  dos  elementos   5   5   25   Confiabilidade   Interrupção  para  erros  técnicos   5   4   20   Reestabelecimento  após  erro  técnico   5   4   20   Recuperação  de  falhas   Reestabelecimento  de  nó   3   5   15   Registro  de  resultados  de  todos  comandos   5   5   25   Operabilidade   Interface  web  para  configuração   3   2   6   Usabilidade   Interface  web  para  monitoração   4   4   16   Entendimento   Facilidade  de  entendimento  das  interfaces   3   2   6   Aprendizado   Facilidade  de  aprendizado  das  interfaces   3   2   6   Execução  de  550  mil  elementos  por  hora   4   4   16   Execução  diária  de  4,5  milhões  de  elementos   4   4   16   Uso  de  tempo   Priorização  de  elementos   4   3   12   Eficiência   Modificação  de  prioridade  dos  elementos   3   5   15   Eficiência  na  manipulação  de  filas   4   5   20   Uso  de  recursos   Várias  conexões  simultâneas  com  NE   4   3   12   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 40. O  Desenvolvimento  de  uma   Arquitetura  de  So6ware   ¨  Entendendo  um  Exemplo  Real   ¨  IdenGficação,  Classificação  e  Priorização  dos   Requisitos   ¨  Endereçamento  de  Riscos  e  Provas  de  Conceito   ¨  Representação  da  Arquitetura   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 41. Endereçamento  de  Riscos   Riscos   ¨  “Ou  você  ataca  os  riscos  ou  eles  te  atacam!”   ¤  Arquitetura  é  fundamental  para  idenGficar  os  riscos  e   trabalhar  em  estratégias  para  sua  miGgação   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 42. Endereçamento  de  Riscos   Riscos   ¨  Prazo  impossível  de  ser  cumprido   ¤  Tipo:  Gerencial   ¤  MiGgação:   n  A  solução  arquitetural  contribuiu  para  parGcionar  o  projeto  em   várias  entregas,  gerando  valor  mais  rapidamente  e  adiando   requisitos  de  menor  impacto   n  Contribuiu  também  para  a  organização  e  paralelização  dos   trabalhos  da  equipe  de  desenvolvimento  em  várias  frentes:   n  Núcleo   n  Conectores  de  Entrada   n  Adaptadores  de  Rede   n  Aplicações  Web  (Cadastro,  Monitor,  Histórico)   n  Supervisor   n  etc   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 43. Endereçamento  de  Riscos   Riscos   ¨  Falta  de  conhecimento  para  integrar  com  algumas   plataformas  (protocolos)   ¤  Tipo:  Técnico   ¤  MiGgação:   n  Construção  de  plataformas  mock  para  auxiliar  na   testabilidade   n  Realizar  um  esforço  de  desenho  dos  adaptadores  de  rede   n  Iniciar  o  desenvolvimento  dos  adaptadores  de  rede  todos   em  paralelo,  priorizando  os  mais  diXceis  ou  desconhecidos   pela  equipe  (Corba,  Rmi,  Socket  etc)  logo  na  fase  de   concepção   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 44. Endereçamento  de  Riscos   Riscos   ¨  Falta  de  conhecimento  da  equipe  nas  ferramentas   a  serem  uGlizadas  no  projeto  (servidor  de   aplicação)   ¤  Tipo:  Técnico/Gerencial   ¤  MiGgação:   n  Treinamento  mínimo  da  equipe  nas  ferramentas   necessárias   n  Não  houve  treinamento   n  Provas  de  conceito  para  uGlização  de  recursos   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 45. Endereçamento  de  Riscos   Riscos   ¨  Outros  riscos  técnicos  foram  tratados  através  de   provas  de  conceito   ¨  Prova  de  Conceito   ¤  Busca  validar/invalidar  uma  possível  solução  para  um   problema   ¤  Critérios  de  sucesso/insucesso  da  prova  de  conceito   devem  ser  definidos  antes  de  sua  execução   ¤  Seu  custo  pode  variar:   n  Lista  de  produtos  /  features  de  um  produto  /  documento   n  Construção  de  um  protóGpo  “executável”   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 46. Endereçamento  de  Riscos   Provas  de  Conceito  (Fase  1)   # Descrição POC Tempo est 1.1 Compatibilidade ServiceMix / WebLogic 16 1.2 Compatibilidade OpenESB / WebLogic 24 1.3 Compatibilidade Mule / WebLogic 16 1.4 Compatibilidade JBoss ESB / WebLogic 24 2.1 Endereçamento funcional ServiceMix 32 2.2 Endereçamento funcional OpenESB 32 2.3 Endereçamento funcional Mule 40 2.4 Endereçamento funcional JBoss ESB 32 2.5 Funcionalidade de Binding Components 16 2.6 Binding Components + Linguagem de Script 4 2.7 Flexibilidade Service Engine 16 2.8 Escolha da linguagem de script 24 3.1 Endereçamento não-funcional ESB 60 4.1 Avaliação Message Broker WebLogic 16 5.1 Viabilidade Binding Component 24 5.2 Viabilidade Message Normalization 24 5.3 Viabilidade Service Engine 24 6.1 Simulação integração 40 464 ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 47. Endereçamento  de  Riscos   Provas  de  Conceito  (Fase  2)   Grupo Prova de Conceito Prioridade Supervisão Mecanismo de comunicação de supervisor <---> agentes (jmx) 1 Supervisão Mecanismo de comunicação de supervisor <---> agentes (jms) 1 Supervisão Monitoração remota de Mbean supervisor com JConsole 2 Supervisão Registro de ativação desativação de itens/nós monitorados 3 Supervisão Redistribuição de message listeners 4 Monitoração Número de usuários/telas de monitoração simultâneos suportados 1 Monitoração Desempenho/viabilidade arrastar pop-up no cliente 2 Monitoração Modelo de objetos / data type / biblioteca data type 3 Monitoração Padronização de componentes / interface (validar modelo interação) 4 Monitoração Escolha de framework web 1 Hp Open View Monitoração com JMX 1 Hp Open View Monitoração com SNMP 2 Cadastro e Configuração Implementação de aplicação Grails padrão 1 Cadastro e Configuração Implementação de aplicação Grails com melhorias* 2 Histórico Implementação utilizando Log4j 1 Histórico Utilização de otimizações do WLS 2 Histórico Implementação "pura" (sem frameworks) 3 Histórico Implementação utilizando aspectos 4 Single Sign On Pesquisa e implementação de mecanismo do WLS 1 ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 48. Endereçamento  de  Riscos   Resultado  PoC  ServiceMix   ¨  Distribuição  em  nós  disGntos   ¤  O  teste  da  distribuição  do  aprovisionador  e   comunicadores  em  nós  disGntos  foi  realizada  com   sucesso  pelo  ServiceMix   ¤  No  entanto  em  alguns  testes,  quando  o  servidor  era   iniciado,  o  ServiceMix  não  conseguiu  encontrar  a  rota   para  os  bind  components  e  uma  exceção  era  lançada   ¤  Reinicializando  o  servidor,  a  rota  era  encontrada   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 49. Endereçamento  de  Riscos   Resultado  PoC  ServiceMix   ¨  Balanceamento  de  carga   ¤  A  distribuição  das  mensagens  para  os  comunicadores   feita  pelo  ServiceMix  não  considerou  a  capacidade  de   processamento  dos  nós   ¤  Levou  a  uma  distribuição  ineficiente  da  carga  pois   distribuía  igualmente  entre  os  nós   ¤  Em  um  ambiente  onde  hajam  recursos  com   capacidade  de  processamento  diferente,  os  de  menor   capacidade  ficarão  sobrecarregados  enquanto  os  de   maior  capacidade  poderão  ficar  ociosos   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 50. Endereçamento  de  Riscos   Resultado  PoC  ServiceMix   ¨  Tolerância  à  falhas   ¤  No  teste  de  tolerância  à  falhas,  ao  restabelecer   funcionamento  de  um  nó,  a  comunicação  foi   recuperada   ¤  Porém  foi  detectada  a  perda  de  mensagens   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 51. Endereçamento  de  Riscos   Resultado  PoC  ServiceMix   ¨  Desempenho,  Uso  do  Tempo,  Carga   ¤  Um  cliente  conseguiu  inserir  510K  mensagens  no   Weblogic  JMS  Server  em  5  horas.     ¤  Ao  iniciar  o  consumo  das  mensagens  pelo   aprovisionador,  após  alguns  minutos,  o  container   terminou  inesperadamente.   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 52. Endereçamento  de  Riscos   Resultado  PoC  ServiceMix   ¨  Avaliação  Geral   ¤  No  geral  a  aplicação  apresentou  baixa  maturidade   ¤  Por  diversas  vezes  foi  necessário  reiniciar  os   servidores   ¤  O  ServiceMix,  por  padrão,  uGliza  filas  não-­‐persistentes   contribuindo  possivelmente  para  a  perda  de   mensagens   n  Não  foi  encontrada  na  documentação  à  época  uma  forma   de  alterar  essa  caracterísGca   ¤  A  alternaGva  ESB  ServiceMix  foi  abandonada  por   falhar  em  vários  critérios  da  prova  de  conceito   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 53. Endereçamento  de  Riscos   Resultado  PoC  ServiceMix   Teste Resulta Subcategoria Requisito Pond Realizado? do Integração batch com CRM 15 Sim Ok Interoperabilidade Comunicação com plataforma HLR Nokia 15 Sim Ok Disponibilidade 24 x 7 / Maturidade 99,9% 20 Sim Falha Integridade dos elementos 25 Sim Falha Tolerância a falhas Interrupção para erros técnicos 20 Não - Reestabelecimento após erro técnico 20 Não - Recuperação de falhas Reestabelecimento de nó 15 Sim Ok Registro de resultados de todos comandos 25 Sim Falha Execução de 550 mil elementos por hora 16 Sim Falha Uso de tempo Execução diária de 4,5 milhões de elementos 16 Não - Execução 10 15 Sim Ok Adaptabilidade Sistema operacional HPUX 15 Não - Reinstalação de componentes Java/JEE 8 Não - Facilidade de Troca Reinstalação transparente de novos comandos 16 Não - ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 54. O  Desenvolvimento  de  uma   Arquitetura  de  So6ware   ¨  Entendendo  um  Exemplo  Real   ¨  IdenGficação,  Classificação  e  Priorização  dos   Requisitos   ¨  Endereçamento  de  Riscos  e  Provas  de  Conceito   ¨  Representação  da  Arquitetura   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 55. Representação  da  Arquitetura   Documentação  da  Arquitetura   ¨  A  documentação  da  arquitetura  de  so6ware   ¤  Facilita  comunicação  com/entre  stakeholders   ¤  Documenta  antecipadamente  decisões  de  desenho  de   alto  impacto  e  grande  abrangência   ¤  Auxilia  no  esclarecimento  dos  requisitos  do  so6ware   ¤  IdenGfica  e  avalia  possíveis  opções  arquiteturais   ¤  Alimenta  e  impõe  um  contexto  para  o  desenho  do   so6ware   ¤  Propositalmente  oculta  detalhes  menos  importantes   ¨  Modelo  mais  uGlizado:  4+1,  Krutchen   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 56. Representação  da  Arquitetura   Modelo  4+1   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 57. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  +1  =  Casos  de  Uso  (ou  Cenários)   ¤  Relevantes  para  a  modelagem  arquitetural  (risco,   importância  para  o  negócio,  impacto  para  o  cliente,   ou  ponto  de  atenção)   ¨  Visão  Lógica   ¨  Visão  de  Componentes   ¨  Visão  de  Implantação   ¨  Visão  de  Processos   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 58. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  +1  =  Casos  de  Uso  (ou  Cenários)   ¤  Exemplo  didáGco   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 59. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  +1  =  Casos  de  Uso  (ou  Cenários)   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 60. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  +1  =  Casos  de  Uso  (ou  Cenários)   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 61. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  Lógica   ¤  Exemplo  didáGco   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 62. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  Lógica   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 63. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  Lógica   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 64. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  Lógica   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 65. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  de  Componentes   ¤  Exemplo  didáGco   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 66. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  de  Componentes   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 67. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  de  Implantação   ¤  Exemplo  didáGco   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 68. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  de  Implantação   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 69. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  de  Implantação   ¤  Exemplo  real   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 70. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  de  Processos   ¤  Exemplo  didáGco   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 71. Representação  da  Arquitetura   Modelo  4+1   ¨  Visão  de  Processos   ¤  Exemplo  real   WLI Endpoint Control Bus Input Channel Mapper C C NE Channel Message C Normalizer Channel Adapter Dispatcher Mapper Mapper Mapper Mapper C C Normalizer Provisioning Content Splitter Content Based NE Channel Message C Channel Adapter Channel - In Enricher Router Dispatcher Mapper Polling C C NE Channel Message C Channel Adapter Dispatcher Message Translator Normalizer Provisioning Aggregator Network Reply Channel - Out Channel Output Channel History Channel Store WLI Endpoint ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 72. Representação  da  Arquitetura   Modelo  4+1   ¨  Nem  todas  visões  são  sempre  necessárias   ¨  As  visões  complementam-­‐se  umas  às  outras   ¨  Capturam  interesses  de  múlGplos  stakeholders   ¨  Permitem  cruzar  as  informações  para  validação  do   modelo   ¨  Representam  uma  estratégia  para  miGgação  de  riscos   do  projeto   ¨  Permitem  realizar  o  vínculo  entre  o  problema  e  a   solução   ¨  Fornecem  coerência  arquitetural   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 73. Representação  da  Arquitetura   Documento  de  Arquitetura  de  So6ware   ¨  O  DAS  deve  prover  uma  visão  abrangente  da   arquitetura  do  so6ware   ¨  Além  das  visões  arquiteturais,  sugere-­‐se   referenciar  também:   ¤  Requisitos  de  Qualidade  (ISO  9126)   ¤  Restrições  ou  Decisões  Arquiteturais   ¤  Arquitetura  de  Referência   ¤  Mecanismos  de  Análise  e  Desenho   ¤  Cenários  de  Atributos  de  Qualidade   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 74. Representação  da  Arquitetura   Documento  de  Arquitetura  de  So6ware   ¨  Requisitos  de  Qualidade   ¤  ISO  9126   Categoria   Subcategoria   Requisito   Prior   Comp   Pond   Maturidade   Disponibilidade  24  x  7  /  99,9%   4   5   20   Tolerância  a  falhas   Integridade  dos  elementos   5   5   25   Confiabilidade   Interrupção  para  erros  técnicos   5   4   20   Reestabelecimento  após  erro  técnico   5   4   20   Recuperação  de  falhas   Reestabelecimento  de  nó   3   5   15   Registro  de  resultados  de  todos  comandos   5   5   25   Operabilidade   Interface  web  para  configuração   3   2   6   Usabilidade   Interface  web  para  monitoração   4   4   16   Entendimento   Facilidade  de  entendimento  das  interfaces   3   2   6   Aprendizado   Facilidade  de  aprendizado  das  interfaces   3   2   6   Execução  de  550  mil  elementos  por  hora   4   4   16   Execução  diária  de  4,5  milhões  de  elementos   4   4   16   Uso  de  tempo   Priorização  de  elementos   4   3   12   Eficiência   Modificação  de  prioridade  dos  elementos   3   5   15   Eficiência  na  manipulação  de  filas   4   5   20   Uso  de  recursos   Várias  conexões  simultâneas  com  NE   4   3   12   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 75. Representação  da  Arquitetura   Documento  de  Arquitetura  de  So6ware   ¨  Restrições  ou  Decisões  Arquiteturais   ¤  Conjunto  de  restrições  pré-­‐existentes   ¤  Princípios  Arquiteturais,  PolíGcas  etc   ¨  Exemplos:   Sistema  deve  integrar-­‐se  com  ferramenta  de  monitoração  HP  Open  View   Sistema  deve  expor  serviço  para  integração  com  plataforma  SOA   Implementação  deve  uGlizar  servidor  de  aplicação  WebLogic  10  e  SGBD   Oracle  10g   Sistema  deve  seguir  as  políGcas  de  segurança  do  cliente   Aplicações  web  devem  ser  compa‚veis  com  Internet  Explorer  6  (ou   superior)  e  Firefox  2  (ou  superior)   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 76. Representação  da  Arquitetura   Documento  de  Arquitetura  de  So6ware   ¨  Restrições  ou  Decisões  Arquiteturais   ¨  Exemplos:   ¤  Fundamentar  serviços  em  JMS   ¤  UGlizar  mecanismos  failover  e  load  balancing   n  Store-­‐And-­‐Forward   n  Persistência  em  SGBD  e/ou  arquivo   n  RetentaGvas  automáGcas  de  execução     n  Supervisão  de  sobrecarga   n  Filas  e  tópicos  distribuidos   n  Clustering   ¤  Supervisão  aGva   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 77. Representação  da  Arquitetura   Documento  de  Arquitetura  de  So6ware   ¨  Arquitetura  de  Referência   ¤  EsGlos  Arquiteturais   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 78. Representação  da  Arquitetura   Documento  de  Arquitetura  de  So6ware   ¨  Arquitetura  de  Referência   ¤  EsGlos  Arquiteturais   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 79. Representação  da  Arquitetura   Documento  de  Arquitetura  de  So6ware   ¨  Mecanismos  de  Análise  e  Desenho   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 80. Representação  da  Arquitetura   Documento  de  Arquitetura  de  So6ware   ¨  Mecanismos  de  Análise  e  Desenho   Análise Design Implementação Persistência SGBD Relacional Oracle 10g Mapeamento Objeto/ JPA / Toplink Relacional Gerência de Auditoria de Apache log4J erros execução Registro em bancos relacional Graphics Model-view- Java Server Faces controller Conteúdo dinâmico XHTML Facelets Java Standard Tag Library Java Server Pages Custom tag libraries/tag files ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 81. Representação  da  Arquitetura   Documento  de  Arquitetura  de  So6ware   ¨  Mecanismos  de  Análise  e  Desenho   Análise Design Implementação Gerência de N.A. EJB contêiner / WLS transação Segurança Criptografia DES Java Cryptographic Architecture Tempo Temporização CommonJ Comunicação Mensagem JMS/ EJB contêiner / WLS Batch / XML Flat file / Apache Xerces Protocolos Telnet, Apache Commons Net HTTP RMI Java RMI CORBA Borland Visibroker client ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 82. Representação  da  Arquitetura   Documento  de  Arquitetura  de  So6ware   ¨  Mecanismos  de  Análise  e  Desenho   Análise Design Implementação Comunicação / Content Enricher N.A. EIP Channel Splitter Mapper Recipient List Message Dispatcher Message Translator Channel Adapter Message Filter Aggregator Endpoint Loan Broker Piper and Filter Normalizer Polling ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 83. Representação  da  Arquitetura   Documento  de  Arquitetura  de  So6ware   ¨  Mecanismos  de  Análise  e  Desenho   Característica Sub-característica Implementação Manutenibilidade Testabilidade JUnit Testabilidade CruiseControl Facilidade de instalação Facilidade de instalação Groovy Funcionalidade Interoperabilidade Confiabilidade Tolerância  a  eventos  anormais WLS Recuperabilidade   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 84. Representação  da  Arquitetura   Documento  de  Arquitetura  de  So6ware   ¨  Cenários  de  Atributos  de  Qualidade   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 85. Representação  da  Arquitetura   Documento  de  Arquitetura  de  So6ware   ¨  Cenários  de  Atributos  de  Qualidade   ¤  Desempenho   Fração  do  cenário   Valores     Fonte   Fonte  de  ordens  de  serviço  (CRM)   EsMmulo   Chegada  periódica  150  eventos  por  segundo  (OS’s)   Artefato   Sistema   Ambiente   Modo  normal  (fila  média  global  de  120K  eventos)   Resposta   Processamento  normal  dos  eventos   Métrica  de  resposta   Throughput  de  150  eventos  por  segundo   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 86. Representação  da  Arquitetura   Documento  de  Arquitetura  de  So6ware   ¨  Cenários  de  Atributos  de  Qualidade   ¤  Confiabilidade   Fração  do  cenário   Valores     Fonte   Externo  ao  sistema  (plataforma)   EsMmulo   Erro  recebido  da  plataforma   Artefato   Adaptador  de  rede   Ambiente   Operação  normal  ou  degradada   Resposta   •  Registro  em  log  e  histórico   •  Mensagem  é  re-­‐inserida  na  fila  para  processamento  posterior   •  Espera  entre  retentaGvas  para  não  sobrecarregar  a  plataforma   •  Vazão  é  degradada  na  medida  que  aumenta  número  de  erros   Métrica  de   •  Não  se  perde  nenhuma  informação   resposta   •  Todas  mensagens  que  obGveram  erro  são  processadas   normalmente  após  remoção  do  es‚mulo   ©  Alessandro  Kieras.  Twi2er:  @kierasbr  
  • 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