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

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

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

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

5.
Arquitetura de So6ware

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20.
Arquiteto de So6ware

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

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

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

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

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

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

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

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

29.
O Desenvolvimento de uma Arquitetura de So6ware

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

87.
Conclusões

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

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

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

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

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