ARQUITETURA DE
  SOFTWARE
  Uma visão prática do mundo real
QUEM SOMOS
Saulo Arruda (http://sauloarruda.eti.br)
  Quase especialista em MPS pela UFLA
  Gerente de Produção da Agence
  Coordenador do JUG-MS
  Instrutor do SENAC-MS
  Desenvolvedor há 10 anos
QUEM SOMOS
Jefferson Moreira (http://jeffmor.com)
 Quase especialista em Engenharia de Software pela
 UNIDERP/Anhanguera
 Desenvolvedor da Agence
 Coordenador do JUG-MS
 Instrutor do SENAC-MS
 Desenvolvedor há 6 anos
POR ONDE COMEÇAR?
Qual problema será resolvido?
Quais são as restrições?
Como vamos resolver o problema?
PROCESSO DE
DESENVOLVIMENTO
O PROBLEMA
Cliente: Consultoria de Marketing
Projeto: Programa de Melhoria do Índice de
Satisfação do Cliente (ISC) para Montadoras de
Veículos
Envolvidos: Consultoria, Montadora, Clientes da
Montadora, Agence, Instituto de Pesquisa
Escopo: Desenvolvimento do Sistema para
processamento dos indicadores e exibição dos
relatórios.
AS RESTRIÇÕES
O sistema deve atender clientes de várias áreas, não
somente montadoras;
Hoje, existem 2 soluções implementadas que
possuem as seguintes limitações:
  Problemas de performance e confiabilidade;
  Flexibilidade para atender mudanças solicitadas
  pelo cliente;
O PROCESSO
Etapas do Programa de Melhoria do Índice de
Satisfação do Cliente (ISC):
  Realização de Pesquisa com os Clientes
  Processamento e Geração dos Indicadores
  Disponibilização dos Relatórios
Esse processo é realizado semanalmente;
Periodicamente, a consultoria compila um relatório
analítico apresentando recomendações para melhoria
do ISC
O PROCESSO
O SISTEMA
O Sistema a ser desenvolvido abrange apenas a
geração de indicadores e apresentação dos
relatórios;
As pesquisas serão realizadas pelo Instituto de
Pesquisa, que enviará semanalmente uma planilha
eletrônica (.xls) com os resultados;
O relatório analítico será elaborado pela consultoria
usando ferramentas de terceiros;
VISÃO GERAL DA
ARQUITETURA
Linguagem de Programação: Java 5
Banco de Dados: PostgreSQL 8+
Frameworks e componentes:
 Objetos de Negócio: EJB 3.0
 Persistência: JPA 1.1
 Web: JSF 1.2 + Facelets + RichFaces
Servidor de Aplicação: JBoss 5
MOTIVOS DAS
DECISÕES
Por que Java?
Spring, JBoss Seam ou EJB 3?
Struts, Spring MVC ou JSF?
JBoss, Glassfish ou Websphere?
POR QUE JAVA?
Open Source
“Independente” de plataforma
“Excelente” API
Ecossistema amplo de Frameworks
Sistemas distribuídos “sem complicação”
E acima de tudo por conta da Plataforma Java
PLATAFORMA JAVA
SPRING, JBOSS SEAM
OU EJB 3?
Spring
 IoC, DI, Transaction API, vários frameworks
 integrados, excelente API para Web e Desktop.
JBoss SEAM
 DI, Bijeção, Novos Escopos e apenas para web.
EJB3 (nossa escolha)
 Spring+, container de EJB, especificação JEE,
 sistema distribuídos.
STRUTS, SPRING MVC
OU JSF?
Struts
  Validadores, Anotações e Legado.
Spring MVC
  Simples, Direto e Binding.
JSF (nossa escolha)
  Especificação, Validadores, Conversores,
  Componentes, Templates, Facelets, JSF 2.0 saindo.
JBOSS, GLASSFISH OU
WEBSPHERE?
GlassFish
  Implementação de referência JEE, integrado com NetBeans e
  dizem ser o mais rápido.

Websphere
  Pago, fácil configuração e a maioria das empresas tentando
  migrar para a versão 6.x

JBoss (nossa escolha)
  Suporte SOA, Leve, Robusto, JMX, Equipe com Know How,
  extensivo suporte AOP, representatividade no Brasil.
JAVA PERSISTENCE API
Substitui os Entity Beans
EJB/JPA QL
Provedores (Hibernate, Oracle Toplink, Apache JPA)
Extensões específicas de provedores (Cache,
estatísticas, JMX, Criteria)
Lazy Loading usando EJB.
Falta Criteria API (previsto para JPA 2.0)
POSTGRESQL
Open Source
Performance satisfatória
Ambiente Linux ou BSD (preferencialmente)
Dificuldade em Tuning (otimização)
Escalabilidade prejudicada em servidores
compartilhados
Dificuldade na Manutenção (VACUUM, ANALYZE)
CASOS DE USO
Importar Pesquisas
Gerar Indicadores
Conferir Indicadores
Publicar Indicadores
Manter Questionários
Consultar Acompanhamento Mensal
Consultar Dashboard
IMPORTAR PESQUISAS
Escopo: Sistema ISC - Processamento
Nível: Objetivo do Usuário
Ator Primário: Consultor
Pré-condições: Usuário autenticado
Garantias de Sucesso: Pesquisas importadas com
sucesso
Garantias Mínimas: Lista de erros da importação
IMPORTAR PESQUISAS
Cenário de Sucesso Principal:
1. O consultor seleciona a empresa, o questionário e a
   planilha com as pesquisas (arquivo xls)
2. O sistema processa a planilha e importa as
   pesquisas
3. O consultor confere o resultado da importação
IMPORTAR PESQUISAS
Extensões:
  2a. O arquivo não pôde ser lido:
    1. O sistema apresenta descrição do erro
    2. O consultor corrige e repete o passo 1 ou
    finaliza o caso de uso
  2-3a. Algumas linhas do arquivo estão inválidas:
    1. O continua e apresenta os erros no final
    2. O consultor corrige e repete o passo 1 ou
    finaliza o caso de uso
IMPORTAR PESQUISAS
Requisitos Especiais:
  RF01. Ao importar a pesquisa é necessário
  identificar a empresa para a qual foi feita;
  RF02. Ao importar a pesquisa é necessário
  identificar o responsável pelo atendimento;
  RP01. A importação de 1.000 pesquisas não pode
  demorar mais que 2 minutos;
Frequência de ocorrência: Semanalmente
IMPORTAR PESQUISAS
Mockup de Telas:
IMPORTAR PESQUISAS
MODELO DE DOMÍNIO
DIAGRAMA DE CLASSE
(NEGÓCIO)
DIAGRAMA DE CLASSE
(WEB)
DIAGRAMA DE
SEQUÊNCIA
DIAGRAMA DE
COMPONENTES
PROBLEMAS DA
IMPLEMENTAÇÃO
Performance: O tempo de importacão de 1 pesquisa
(60 questões) é de 0,5 s. Para 1.000 pesquisas
precisamos de mais de 8 min. Os maiores
questionários tem 200 questões.
Funcionalidade: A API POI consegue ler um
arquivo de até 5 Mb (OutOfMemoryError). Um
arquivo de 1.000 pesquisas com 200 chega a 8 Mb.
TESTES UNITÁRIOS
Classe base (AbstractModelTestCase)
Fixtures para dados de testes usando arquivos de
Bean do Spring
Injeção de objetos usados no teste
Criação do banco de dados
Controle transacional
Simulação dos objetos do container
TESTES DE
INTEGRAÇÃO
Testes usando objetos remotos do container EJB
Integração de todas as funcionalidades, usando
arquivos reais enviados pelo cliente
Uso de profiler para mensurar performance
Assertions baseado em planilhas enviadas pelo cliente
TESTES FUNCIONAIS
Plano de testes em planilha excel
Realização dos testes no final de cada iteração
Criação de evidências de testes
Execução de testes de regressão
Automatização de testes funcionais?
  Selenium/Webdriver (quem sabe no futuro)
TESTE DE CARGA
Teste de carga das telas de relatório
Uso de JMeter para implementação e execução
Execução remota de testes para simulação de vários
usuários (Ex.: 3 máquinas com 500 usuários cada)
Profiler para mensurar uso de processador e memória
Teste em ambiente de pré-produção com a
configuração do servidor de produção e simulação
real do número de usuários
OTIMIZAÇÕES
Refactoring de métodos críticos
Otimização/refactoring de consultas SQL
Otimização de índices no banco de dados
Implementação de Cache (ehcache)
Tuning do Servidor de Banco de Dados
Tuning de Servidor de Aplicação
Tuning de configurações do Sistema Operacional
CONCLUSÃO
CONCLUSÃO
Lições aprendidas
CONCLUSÃO
Lições aprendidas
 Processo de desenvolvimento:
CONCLUSÃO
Lições aprendidas
 Processo de desenvolvimento:
   Focado na Arquitetura;
CONCLUSÃO
Lições aprendidas
 Processo de desenvolvimento:
   Focado na Arquitetura;
   Dirigido por Casos de Uso;
CONCLUSÃO
Lições aprendidas
 Processo de desenvolvimento:
   Focado na Arquitetura;
   Dirigido por Casos de Uso;
   Iterativo e Incremental;
CONCLUSÃO
Lições aprendidas
 Processo de desenvolvimento:
   Focado na Arquitetura;
   Dirigido por Casos de Uso;
   Iterativo e Incremental;
 Testes antes da implantação (integração, funcional
 e carga/stress)
PERGUNTAS?
OBRIGADO!
Contatos para Treinamento, Shows, Funerais e etc.
Saulo Arruda
 E-mail: sauloarruda@gmail.com
 Blog: http://sauloarruda.eti.br
Jefferson Moreira
 E-mail: jeffmor@gmail.com
 Blog: http://jeffmor.com

Arquitetura de Software

  • 1.
    ARQUITETURA DE SOFTWARE Uma visão prática do mundo real
  • 2.
    QUEM SOMOS Saulo Arruda(http://sauloarruda.eti.br) Quase especialista em MPS pela UFLA Gerente de Produção da Agence Coordenador do JUG-MS Instrutor do SENAC-MS Desenvolvedor há 10 anos
  • 3.
    QUEM SOMOS Jefferson Moreira(http://jeffmor.com) Quase especialista em Engenharia de Software pela UNIDERP/Anhanguera Desenvolvedor da Agence Coordenador do JUG-MS Instrutor do SENAC-MS Desenvolvedor há 6 anos
  • 4.
    POR ONDE COMEÇAR? Qualproblema será resolvido? Quais são as restrições? Como vamos resolver o problema?
  • 5.
  • 6.
    O PROBLEMA Cliente: Consultoriade Marketing Projeto: Programa de Melhoria do Índice de Satisfação do Cliente (ISC) para Montadoras de Veículos Envolvidos: Consultoria, Montadora, Clientes da Montadora, Agence, Instituto de Pesquisa Escopo: Desenvolvimento do Sistema para processamento dos indicadores e exibição dos relatórios.
  • 7.
    AS RESTRIÇÕES O sistemadeve atender clientes de várias áreas, não somente montadoras; Hoje, existem 2 soluções implementadas que possuem as seguintes limitações: Problemas de performance e confiabilidade; Flexibilidade para atender mudanças solicitadas pelo cliente;
  • 8.
    O PROCESSO Etapas doPrograma de Melhoria do Índice de Satisfação do Cliente (ISC): Realização de Pesquisa com os Clientes Processamento e Geração dos Indicadores Disponibilização dos Relatórios Esse processo é realizado semanalmente; Periodicamente, a consultoria compila um relatório analítico apresentando recomendações para melhoria do ISC
  • 9.
  • 10.
    O SISTEMA O Sistemaa ser desenvolvido abrange apenas a geração de indicadores e apresentação dos relatórios; As pesquisas serão realizadas pelo Instituto de Pesquisa, que enviará semanalmente uma planilha eletrônica (.xls) com os resultados; O relatório analítico será elaborado pela consultoria usando ferramentas de terceiros;
  • 11.
    VISÃO GERAL DA ARQUITETURA Linguagemde Programação: Java 5 Banco de Dados: PostgreSQL 8+ Frameworks e componentes: Objetos de Negócio: EJB 3.0 Persistência: JPA 1.1 Web: JSF 1.2 + Facelets + RichFaces Servidor de Aplicação: JBoss 5
  • 12.
    MOTIVOS DAS DECISÕES Por queJava? Spring, JBoss Seam ou EJB 3? Struts, Spring MVC ou JSF? JBoss, Glassfish ou Websphere?
  • 13.
    POR QUE JAVA? OpenSource “Independente” de plataforma “Excelente” API Ecossistema amplo de Frameworks Sistemas distribuídos “sem complicação” E acima de tudo por conta da Plataforma Java
  • 14.
  • 16.
    SPRING, JBOSS SEAM OUEJB 3? Spring IoC, DI, Transaction API, vários frameworks integrados, excelente API para Web e Desktop. JBoss SEAM DI, Bijeção, Novos Escopos e apenas para web. EJB3 (nossa escolha) Spring+, container de EJB, especificação JEE, sistema distribuídos.
  • 17.
    STRUTS, SPRING MVC OUJSF? Struts Validadores, Anotações e Legado. Spring MVC Simples, Direto e Binding. JSF (nossa escolha) Especificação, Validadores, Conversores, Componentes, Templates, Facelets, JSF 2.0 saindo.
  • 18.
    JBOSS, GLASSFISH OU WEBSPHERE? GlassFish Implementação de referência JEE, integrado com NetBeans e dizem ser o mais rápido. Websphere Pago, fácil configuração e a maioria das empresas tentando migrar para a versão 6.x JBoss (nossa escolha) Suporte SOA, Leve, Robusto, JMX, Equipe com Know How, extensivo suporte AOP, representatividade no Brasil.
  • 19.
    JAVA PERSISTENCE API Substituios Entity Beans EJB/JPA QL Provedores (Hibernate, Oracle Toplink, Apache JPA) Extensões específicas de provedores (Cache, estatísticas, JMX, Criteria) Lazy Loading usando EJB. Falta Criteria API (previsto para JPA 2.0)
  • 20.
    POSTGRESQL Open Source Performance satisfatória AmbienteLinux ou BSD (preferencialmente) Dificuldade em Tuning (otimização) Escalabilidade prejudicada em servidores compartilhados Dificuldade na Manutenção (VACUUM, ANALYZE)
  • 21.
    CASOS DE USO ImportarPesquisas Gerar Indicadores Conferir Indicadores Publicar Indicadores Manter Questionários Consultar Acompanhamento Mensal Consultar Dashboard
  • 22.
    IMPORTAR PESQUISAS Escopo: SistemaISC - Processamento Nível: Objetivo do Usuário Ator Primário: Consultor Pré-condições: Usuário autenticado Garantias de Sucesso: Pesquisas importadas com sucesso Garantias Mínimas: Lista de erros da importação
  • 23.
    IMPORTAR PESQUISAS Cenário deSucesso Principal: 1. O consultor seleciona a empresa, o questionário e a planilha com as pesquisas (arquivo xls) 2. O sistema processa a planilha e importa as pesquisas 3. O consultor confere o resultado da importação
  • 24.
    IMPORTAR PESQUISAS Extensões: 2a. O arquivo não pôde ser lido: 1. O sistema apresenta descrição do erro 2. O consultor corrige e repete o passo 1 ou finaliza o caso de uso 2-3a. Algumas linhas do arquivo estão inválidas: 1. O continua e apresenta os erros no final 2. O consultor corrige e repete o passo 1 ou finaliza o caso de uso
  • 25.
    IMPORTAR PESQUISAS Requisitos Especiais: RF01. Ao importar a pesquisa é necessário identificar a empresa para a qual foi feita; RF02. Ao importar a pesquisa é necessário identificar o responsável pelo atendimento; RP01. A importação de 1.000 pesquisas não pode demorar mais que 2 minutos; Frequência de ocorrência: Semanalmente
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
  • 33.
    PROBLEMAS DA IMPLEMENTAÇÃO Performance: Otempo de importacão de 1 pesquisa (60 questões) é de 0,5 s. Para 1.000 pesquisas precisamos de mais de 8 min. Os maiores questionários tem 200 questões. Funcionalidade: A API POI consegue ler um arquivo de até 5 Mb (OutOfMemoryError). Um arquivo de 1.000 pesquisas com 200 chega a 8 Mb.
  • 34.
    TESTES UNITÁRIOS Classe base(AbstractModelTestCase) Fixtures para dados de testes usando arquivos de Bean do Spring Injeção de objetos usados no teste Criação do banco de dados Controle transacional Simulação dos objetos do container
  • 35.
    TESTES DE INTEGRAÇÃO Testes usandoobjetos remotos do container EJB Integração de todas as funcionalidades, usando arquivos reais enviados pelo cliente Uso de profiler para mensurar performance Assertions baseado em planilhas enviadas pelo cliente
  • 36.
    TESTES FUNCIONAIS Plano detestes em planilha excel Realização dos testes no final de cada iteração Criação de evidências de testes Execução de testes de regressão Automatização de testes funcionais? Selenium/Webdriver (quem sabe no futuro)
  • 37.
    TESTE DE CARGA Testede carga das telas de relatório Uso de JMeter para implementação e execução Execução remota de testes para simulação de vários usuários (Ex.: 3 máquinas com 500 usuários cada) Profiler para mensurar uso de processador e memória Teste em ambiente de pré-produção com a configuração do servidor de produção e simulação real do número de usuários
  • 38.
    OTIMIZAÇÕES Refactoring de métodoscríticos Otimização/refactoring de consultas SQL Otimização de índices no banco de dados Implementação de Cache (ehcache) Tuning do Servidor de Banco de Dados Tuning de Servidor de Aplicação Tuning de configurações do Sistema Operacional
  • 39.
  • 40.
  • 41.
  • 42.
    CONCLUSÃO Lições aprendidas Processode desenvolvimento: Focado na Arquitetura;
  • 43.
    CONCLUSÃO Lições aprendidas Processode desenvolvimento: Focado na Arquitetura; Dirigido por Casos de Uso;
  • 44.
    CONCLUSÃO Lições aprendidas Processode desenvolvimento: Focado na Arquitetura; Dirigido por Casos de Uso; Iterativo e Incremental;
  • 45.
    CONCLUSÃO Lições aprendidas Processode desenvolvimento: Focado na Arquitetura; Dirigido por Casos de Uso; Iterativo e Incremental; Testes antes da implantação (integração, funcional e carga/stress)
  • 46.
  • 47.
    OBRIGADO! Contatos para Treinamento,Shows, Funerais e etc. Saulo Arruda E-mail: sauloarruda@gmail.com Blog: http://sauloarruda.eti.br Jefferson Moreira E-mail: jeffmor@gmail.com Blog: http://jeffmor.com