UNIVERSIDADE ANHEMBI MORUMBI EVANDRO GREZELI DE BARROS NEVES FELIPE FERREIRA DE OLIVEIRA SOUSA PEDRO ANDRES MINGORANCE

Tamanho: px
Começar a partir da página:

Download "UNIVERSIDADE ANHEMBI MORUMBI EVANDRO GREZELI DE BARROS NEVES FELIPE FERREIRA DE OLIVEIRA SOUSA PEDRO ANDRES MINGORANCE"

Transcrição

1 UNIVERSIDADE ANHEMBI MORUMBI EVANDRO GREZELI DE BARROS NEVES FELIPE FERREIRA DE OLIVEIRA SOUSA PEDRO ANDRES MINGORANCE UM ESTUDO SOBRE TESTES DE DESEMPENHO COM APLICAÇÃO PRÁTICA UTILIZANDO A FERRAMENTA JMETER São Paulo 2011

2 EVANDRO GREZELI DE BARROS NEVES FELIPE FERREIRA DE OLIVEIRA SOUSA PEDRO ANDRES MINGORANCE UM ESTUDO SOBRE TESTES DE DESEMPENHO COM APLICAÇÃO PRÁTICA UTILIZANDO A FERRAMENTA JMETER Orientadora: Profa. Msc. Regiane Aparecida Marucci. Trabalho de Conclusão de Curso apresentado como exigência parcial para a obtenção do título de Bacharel em Sistemas de Informação da Universidade Anhembi Morumbi. São Paulo 2011

3 EVANDRO GREZELI DE BARROS NEVES FELIPE FERREIRA DE OLIVEIRA SOUSA PEDRO ANDRES MINGORANCE UM ESTUDO SOBRE TESTES DE DESEMPENHO COM APLICAÇÃO PRÁTICA UTILIZANDO A FERRAMENTA JMETER Trabalho de Conclusão de Curso apresentado como exigência parcial para a obtenção do título de Bacharel em Sistemas de Informação da Universidade Anhembi Morumbi. Aprovado em Nome do orientador/titulação/ies Nome do convidado/ titulação/ies Nome do convidado/ies

4 O tamanho não importa. Olhe para mim, julga-me pelo meu tamanho? E não deve mesmo. Minha aliada a Força é, e poderosa aliada ela é. A vida a cria, e a faz crescer. Sua energia nos cerca e nos une. Luminosos seres somos nós, não essa rude matéria. Precisa a Força sentir à sua volta, aqui, entre nós, na árvore, na pedra em tudo, sim. Yoda, Star Wars

5 RESUMO A área de desenvolvimento de software atualmente é uma das áreas que mais atraem grandes investimentos, não apenas de grandes empresas, mas também de pequenas e médias (B2M Magazine, 2011), buscando a agilidade e automação que sistemas desenvolvidos oferecem para a produtividade da empresa. Com este investimento em novos produtos e com intuito de dar facilidade ao usuário, se faz necessário que estes novos produtos tenham a qualidade esperada pelo usuário final, assim a área de qualidade de software assume um papel importante neste contexto. Além de possuir um software sem erros, o mesmo tem que ter a resposta quase que imediata, dando a percepção ao usuário de estabilidade e eficiência do sistema. Neste cenário complexo e atual, os testes de desempenho têm o objetivo de oferecer segurança à equipe envolvida no desenvolvimento de software para que o sistema esteja de acordo com os requisitos não funcionais exigidos no inicio do projeto, por meio de métricas e relatórios assertivos, definidos para que todas as metas desejadas sejam atingidas. Considerando este contexto, neste trabalho são apresentados os diferentes tipos de teste de desempenho sugeridos na literatura mundial e como estes podem ser aplicados utilizando uma ferramenta de apoio, chamada JMeter. Também são apresentadas as características da plataforma Android, destinada ao desenvolvimento de aplicativos móveis, que foi utilizada neste trabalho para gerar o conhecimento necessário para o desenvolvimento de um aplicativo que apresenta gráficos gerenciais oriundos de um tipo de teste de desempenho aplicado em uma arquitetura e-commerce hipotética. PALAVRAS CHAVE: Teste de Software. Teste Não Funcional. JMeter. Desempenho.

6 ABSTRACT The software development today is one of the areas that attract large investments, not just from big companies but also small and medium enterprises (B2M Magazine, 2011), seeking the flexibility and efficiency that automated systems offer to the company's productivity. With this investment of those new products which objective is to give ease to the user, it is necessary that these new investment products have the expected quality by the end user, having a major role to the quality software area. In addition to owning a software without bugs, it must have also an on the fly answer, giving the user the perception of stability and efficiency. In this complex scenario, the performance tests are intended to reassure the team involved in developing software that the system is in agreement with non-functional requirements required in the project began, returning assertive reports and metrics that ensure the desired goals are attained. This paper will shown different techniques of performance test suggested in the global literature and how these can be applied using a tool to support these specific tests, called JMeter. Is also given the focus to characteristics of the Android platform for developing mobile applications, with the initial purpose on this theoretical study was to generate the knowledge necessary to develop an application that presented managerial charts which provided data from a specific performmance test on an e- commerce web portal. KEY WORDS: Software Test. Non Functional Software Test. JMeter. Performance.

7 LISTA DE FIGURAS Figura 1: O Ciclo de vida clássico Figura 2: Visão de testes de caixa preta Figura 3: Visão de testes de caixa branca Figura 4: Complexidade da definição do tempo de resposta Figura 5: Uma metodologia para o teste de desempenho Figura 6: Exemplo de definição de cenário e carga de trabalho Figura 7: Tela inicial da ferramenta JMeter Figura 8: Principais elementos de um teste de desempenho Figura 9: Tela de parametrização do componente Grupo de usuários Figura 10: Diagrama de classes do Grupo de usuários Figura 11: Requisições agrupadas no elemento Testador Figura 12: Componente Testador do tipo Requisição HTTP Figura 13: Exemplo de campo preenchido para pesquisa no site Google Figura 14: Aggregate Graph é um ouvinte disponível para apresentar um gráfico de tempo de resposta de um teste executado Figura 15: Ao acionar o botão configurar, é possível customizar o tipo de informação escrita no relatório de saída do relatório Figura 16: Indicador visual que mostra que está em execução 1 processo de Figura 17: Fim de uma execução de teste Figura 18: Exemplo de execução de teste utilizando o JMeter Figura 10: Campo parametrizado no arquivo jmeter.properties Figura 20: Possibilidade de execução remota de um script Figura 21: Imagem da arquitetura da plataforma Android Figura 22: Ciclo de vida de uma atividade Figura 23: Arquitetura típica de um Web Site de múltiplas camadas Figura 24: Caso de teste para efetuar uma compra com sucesso desenvolvido para o JMeter Figura 25: Pirâmide de usuários simultâneos utilizando o JPetStore Figura 26: Atributos definidos para o caso de teste no JMeter Figura 27: Distribuição de usuários simultâneos utilizando o JPetStore Figura 28: Desenho técnico da solução JPlotMeter...64

8 Figura 29: Diagrama de classe servidor de aplicações Figura 30: Diagrama de caso de uso Figura 31: Diagrama de classes do aplicativo JPlotMeter

9 LISTA DE TABELAS Tabela 1: Tabela de tempo de resposta por transações transacionais Tabela 2: Tabela de tempo de resposta de serviços Web Tabela 3: Tabela comparativa entre as principais ferramentas de teste de desempenho software livre do mercado Tabela 4: Caso de teste da funcionalidade de compra de um animal Tabela 5: Caso de teste da funcionalidade de pesquisa de um animal Tabela 6: Descrição do caso de Uso Consultar desempenho do site... 66

10 LISTA DE GRÁFICOS Gráfico 1: Demonstração dos eixos do JPlotMeter...68 Gráfico 2: Demonstração das legendas no JPlotMeter...68

11 LISTA DE ABREVIATURAS E SIGLAS API APK BSD CPU CSV DEX FTP GUI GPL HTML JEE JSE JVM LAN OHA REST RMI RTT SDK SQL TI V & V WAN Application Programming Interface Android Package File Berkeley Software Distribution Central Processing Unit Comma Separated Values Dalvik Executable File Transfer Protocol Graphical User Interface General Public License HyperText Markup Language Java Enterprise Edition Java Standart Edition Java Virtual Machine Local Area Network Open Handset Alliance Representational State Transfer Remote Method Invocation Round Time Trip Software Development Kit Structured Query Language Tecnologia de Informação Verificação e Validação Wide Area Network

12 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS JUSTIFICATIVA ABRANGÊNCIA ESTRUTURA DO TRABALHO TESTE DE SOFTWARE MODELO DE PROCESSO DE SOFTWARE VERIFICAÇÃO E VALIDAÇÃO TESTES FUNCIONAIS Estratégias adotadas em um ciclo de testes funcionais TESTES NÃO FUNCIONAIS Testes Estruturais Testes de Desempenho Ferramentas de Apoio a testes de desempenho JMETER ARQUITETURA DA FERRAMENTA PRINCIPAIS FUNCIONALIDADES SIMULAÇÃO DE USUÁRIOS VIRTUAIS SIMULAÇÃO DE REQUISIÇÕES RELATÓRIOS Métricas geradas MANEIRAS PARA EXECUÇÃO DE UM TESTE Interface gráfica Linha de comando Execução remota PLATAFORMA ANDROID ARQUITETURA DA PLATAFORMA CARACTERÍSTICAS DO SISTEMA OPERACIONAL RECURSOS OPERACIONAIS APLICATIVOS EXECUTADOS NO ANDROID ELABORAÇÃO DE UM TESTE DE ESFORÇO USANDO O JMETER ANALISANDO A ARQUITETURA EM UM TESTE DE DESEMPENHO... 56

13 5.1.1 Camada WEB Camada de Aplicação Camada de Dados ESCOLHA DE UM TESTE DE DESEMPENHO CRIAÇÃO DE UM CASO DE TESTE DE DESEMPENHO JPLOTMETER: UM RELATÓRIO GERENCIAL PARA O ANDROID ARQUITETURA DA SOLUÇÃO MÉTRICAS COLETADAS DO JMETER PARA GERAÇÃO DO GRÁFICO INTEGRAÇÃO COM O SISTEMA OPERACIONAL ANDROID CONCLUSAO TRABALHOS FUTUROS REFERÊNCIAS ANEXO A IDENTIFICADORES DE CRIAÇÃO DE MÉTRICAS UTILIZADAS PELO JMETER ANEXO B API S DE MAIOR UTILIZAÇÃO PARA DESENVOLVIMENTO NO ANDROID ANEXO C RESPONSABILIDADES DOS MÉTODOS PRESENTES NO CICLO DE VIDA DE UMA ATIVIDADE NO ANDROID APÊNDICE A MODELO LÓGICO DA BASE JPETSTORE APÊNDICE B CONFIGURAÇÃO DO HARDWARE DO SERVIDOR DA APLICAÇÃO JPETSTORE APÊNDICE C LOG OPERACIONAL DA FERRAMENTA JMETER APÊNDICE D MODELAGEM BANCO DE DADOS JPLOTMETER... 82

14 14 1 INTRODUÇÃO "Teste de Software é o processo com o intuito de encontrar erros em um programa ou sistema em execução (MYERS, 2004, p. 20). Esta definição citada por Myers (2004, p. 20) reforça o motivo pelo qual cada dia mais empresas se preocupam com a qualidade do seu software, investindo em grandes equipes para encontrar os defeitos inseridos em tempo de programação, seja por má interpretação da especificação funcional ou falta de mão de obra qualificada (GUERRA; COLOMBO, 2009). Por falta de tempo de cronograma de projeto ou por pouca experiência da equipe de desenvolvimento envolvida, as fábricas de software se preocupam em entregar o sistema conforme o esperado, porém não se preocupando em como o produto foi desenvolvido. Por estes motivos, muitos dos sistemas hoje em produção, acabam tendo problemas de desempenho e mesmo de segurança, por não ter tido uma validação destes requisitos ainda no seu ciclo de testes (GUERRA; COLOMBO, 2009). Diante do que foi exposto, este trabalho expõe as melhores práticas propostas por autores brasileiros e internacionais que servem de apoio para testes de desempenho e demonstra a aplicação de um dos tipos de teste de desempenho utilizando uma ferramenta Open Source chamada JMeter. O resultado da execução servirá de dado de entrada para demonstração através de um gráfico gerencial implementado para a plataforma móvel Android, apresentando o tempo médio de resposta por página ao final de cada ciclo de execução. 1.1 OBJETIVOS O objetivo deste trabalho consiste em apresentar os diferentes tipos de testes de desempenho propostos na literatura, tendo em vista aplicar um destes tipos de teste de desempenho, o teste de esforço, em uma arquitetura e-commerce hipotética. Este teste foi escolhido por poder potencializar o comportamento da degradação da performance de um sistema por buscar o seu ponto de ruptura. Para isso, é demonstrada a utilização da ferramenta Open Source de testes de desempenho chamada JMeter. Finalmente, é desenvolvido um aplicativo de relatório

15 15 gerencial para dispositivos móveis na plataforma Android, chamado de JPlotMeter, que demonstra através de um gráfico a média de tempo de resposta por páginas do portal e-commerce escolhido, com base em informações históricas armazenadas com resultados da execução de cenários de teste através do JMeter. 1.2 JUSTIFICATIVA Atualmente, as empresas investidoras em TI estão cada vez mais preocupadas em aplicar testes funcionais em suas aplicações, pelo fato de não ter uma aplicação com problemas em produção. De certa forma, esta preocupação tem contribuído para ciclos de testes mais bem definidos ao longo do desenvolvimento do software, tendo em vista a sua qualidade (GUERRA; COLOMBO, 2009). Em contrapartida, ainda são poucas as empresas que investem em testes não funcionais, principalmente em testes de desempenho, pela necessidade de conhecimento mais técnico sobre ferramentas e a própria arquitetura envolvida, e aquelas que assim o fazem, ainda não tem uma idéia muito clara dos diferentes tipos de teste e dos momentos mais adequados para cada um deles, além das possíveis ferramentas que podem ser utilizadas para a simulação de usuários virtuais (GUERRA; COLOMBO, 2009). 1.3 ABRANGÊNCIA Este trabalho visa definir de forma clara testes de desempenho e também gerar um relatório gerencial de fácil acesso, resultado da execução de cenários de testes utilizando o JMeter em uma aplicação Web. Portanto, é o foco deste trabalho: a) Demonstração prática de um dos tipos diferentes de Testes de Desempenho; b) Criação de uma aplicação para geração de um relatório gerencial para dispositivos móveis na plataforma Android, com base em resultados de execução de testes com o JMeter. Ressalta-se que não é foco deste trabalho: a) Ciclo de Desenvolvimento de software; b) Boas práticas em um ciclo de desenvolvimento de software;

16 16 c) Testes Funcionais; d) Funcionamento da plataforma Android; e) Análise de hardware; f) Arquitetura de servidor. 1.4 ESTRUTURA DO TRABALHO O trabalho proposto foi dividido de maneira que seja possível compreender como um ciclo de testes está presente dentro do ciclo de desenvolvimento de um software. No capítulo 2, é feita uma explanação sobre o modelo de desenvolvimento de software clássico e o modelo V e como os ciclos de testes funcionais e não funcionais estão presentes em cada um deles. Também é feita uma apresentação sobre ferramentas de apoio aos testes de desempenho disponíveis no mercado. No capítulo 3, o funcionamento arquitetural da ferramenta de testes de desempenho JMeter é explicado, bem como seus componentes são utilizados para a realização de testes. O capítulo 4 apresenta as principais características e o funcionamento do sistema operacional voltado para dispositivos móveis, conhecido como Android. Este capítulo tem um maior enfoque sobre como os aplicativos são executados neste sistema operacional. No capítulo 5, são apresentadas as diferentes camadas em um portal de compras Web e aplicado o ciclo de vida de um teste de desempenho, desde a sua concepção, execução e armazenamento do resultado das informações obtidas através destas execuções. O capítulo 6 apresenta o protótipo operacional do relatório gerencial desenvolvido para o Android, cuja informação de entrada para criação do gráfico é oriundo das execuções previamente armazenadas durante os ciclos de teste. As conclusões e os trabalhos futuros para continuidade deste trabalho são apresentados no capítulo 7 e, por fim, este documento é encerrado com as referências bibliográficas que foram utilizadas para o seu desenvolvimento.

17 17 2 TESTE DE SOFTWARE Segundo MYERS (2004) teste de software, é o processo de executar um programa com o intuito de encontrar erro. O ser humano tem a tendência de trabalhar orientado a objetivos. Portanto, caso o objetivo estabelecido de um ciclo de testes seja demonstrar que o software não possui erros, será escolhida uma massa de dados para teste que indique isto e casos de teste que não ofereçam a cobertura necessária para encontrar erros. Agora caso o objetivo seja identificar erros, a massa de dados para o teste e o conjunto de casos de teste terá a grande probabilidade de atingir os objetivos. Este tipo de pensamento agrega muito mais a um ciclo de desenvolvimento de software (MYERS, 2004). 2.1 MODELO DE PROCESSO DE SOFTWARE O ciclo de desenvolvimento de software contém três fases genéricas definição, desenvolvimento e manutenção que são encontradas independentemente da área de aplicação, do tamanho e complexidade do projeto ou do paradigma de engenharia de software escolhido para o desenvolvimento. Em um ciclo de vida clássico conhecido também como cascata, como pode ser visto na figura 1, sugere-se uma abordagem sistemática e sequencial ao desenvolvimento de software, que se inicia no nível do sistema e avança ao longo da análise, projeto, codificação teste e manutenção (PRESSMAN, 2005). Análise e Engenharia de Sistemas Análise de requisitos de software Projeto Codificação Teste Manutenção Figura 1: O Ciclo de vida clássico. Fonte: PRESSMAN (2005)

18 18 De acordo com a figura 1, o ciclo de vida clássico é composto pelas seguintes fases: a) Análise e engenharia de sistemas: Uma vez que o software sempre faz parte de um sistema mais amplo, o trabalho inicia-se com o estabelecimento dos requisitos para todos os elementos do sistema e prossegue com a atribuição de certo subconjunto desses requisitos ao software. Essa visão do sistema é essencial quando o software deve fazer interface com outros elementos, tais como hardware, pessoas e bancos de dados. A análise e a engenharia de sistemas envolvem a coleta dos requisitos em nível do sistema, tendo uma pequena quantidade de projeto e uma grande parte de análise de alto nível. b) Análise de requisitos de software: O processo de coleta dos requisitos é intensificado e concentrado especificamente no software. Para entender a natureza do programa a ser construído, o engenheiro (analista) de software deve compreender o domínio da informação para o software, bem como a função, desempenho e interface exigidos. Os requisitos, tanto para o sistema como para o software, são documentados e revistos com o cliente. c) Projeto: O projeto de software é, de fato, um processo de múltiplos passos que se concentra em quatro atributos distintos do programa: estrutura de dados, arquitetura de software, detalhes procedimentais e caracterização de interface. O processo de elaboração do projeto traduz as exigências numa representação do software que pode ser avaliada quanto à qualidade antes que a codificação se inicie. Como os requisitos, o projeto é documentado e torna-se parte da configuração do software. d) Codificação: O projeto deve ser traduzido numa forma legível por máquina. A etapa de codificação executa essa tarefa. Se o projeto for executado detalhadamente, a codificação pode ser executada mecanicamente. e) Testes: Assim que o código for gerado, inicia-se a realização de testes do programa. O processo de realização de testes concentra-se nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas, e concentram-se também nos aspectos funcionais externos, ou seja,

19 19 realizando testes para descobrir erros e garantir que a entrada definida produza resultados reais que concordem com os resultados exigidos. f) Manutenção: Provavelmente, o software sofrerá mudanças depois que for entregue ao cliente. Isto se dá, principalmente, em função da descoberta de erros, da necessidade de adaptação do software ao ambiente externo ou, também, do acréscimo de requisitos funcionais ou não ao software. A manutenção de software reaplica cada uma das etapas precedentes do ciclo de vida a um programa existente e não a um novo. No modelo clássico, cada estágio deve ser bem definido e aprovado junto ao cliente antes que o processo prossiga para o estágio seguinte. Atividades fundamentais ao processo como especificação, o desenvolvimento, a validação e a evolução do software são representadas como fases separadas no processo, como a especificação de requisitos, o projeto de software, a implementação, os testes e assim por diante (SOMMERVILLE, 2007). 2.2 VERIFICAÇÃO E VALIDAÇÃO Verificação e validação é um processo utilizado para averiguar se um produto, serviço ou sistema está cumprindo com o especificado e se está em acordo com as definições pré-estabelecidas no seu planejamento (SOMMVERILLE, 2007). Este modelo surgiu como um processo de melhoria ao problema de reatividade existente no modelo de desenvolvimento clássico. O processo de Verificação e de Validação (V & V), embora seja facilmente confundidos, não é a mesma coisa. De forma sutil, esses dois conceitos podem ser definidos como a seguir: Validação: estamos construindo o produto certo? Verificação: estamos construindo certo o produto? Por essas definições pode-se observar que o papel da verificação envolve checar se o software cumpre com suas especificações. É preciso verificar se o sistema cumpre com seus requisitos funcionais e não funcionais especificados. Já a validação é um processo mais genérico. É necessário assegurar que o software atenda às expectativas do cliente, e isso vai além de checar a

20 20 conformidade do sistema com suas especificações, a fim de mostrar que o software faz o que o cliente espera que faça, exatamente como foi especificado. Segundo Sommervile (2007), dentro dos processos de V & V, duas técnicas de checagem e análise de sistemas podem ser utilizadas: 1. As inspeções de software, que analisam e verificam as representações do sistema. Como o documento de requisitos, os diagramas de projeto e o código-fonte do programa. As inspeções podem ser aplicadas em todos os estágios do processo. As inspeções de software e as análises automatizadas são técnicas estáticas de V & V, uma vez que não requerem que o sistema seja executado. 2. Testes de software, consite em verificar se o software desenvolvido está sendo executado conforme esperado, com dados de testes pertinentes, examinando as saídas dele e o seu comportamento operacional. Os testes são uma técnica dinâmica de verificação e validação porque trabalham com uma representação executável do sistema. Para apoiar a equipe encarregada de gerenciar e executar um ciclo de teste de software é criado um ou mais artefatos chamados de plano de teste. Além de ser um documento gerencial, os planos de testes se destinam também aos engenheiros de software envolvidos em projetar e realizar os testes de sistema. Este documento é destinado também à equipe técnica para ter uma visão geral dos testes de sistema. Os planos de testes também fornecem informações ao pessoal responsável por assegurar que os recursos apropriados de hardware e software estejam disponíveis para o grupo de teste. 2.3 TESTES FUNCIONAIS Teste funcional, também chamado de teste caixa preta (BARTIÉ, 2002), é o mais utilizado nas empresas desenvolvedoras de software, em seus ciclos de testes. Ele é mais usado, por ser mais fácil, quando comparado ao teste caixa branca que será abordado no item Um dos pontos de ser mais fácil é pelo fato de não ter que demandar tempo para análise de código-fonte e conceitos implementados internamente no software, porém ele não é o menos importante na categoria de

21 21 testes, por ter regras de negócio envolvidas no software. Este tipo de teste está demonstrado na figura 2. Estímulos Produzidos Resultados Gerados Figura 2: Visão de testes de caixa preta. Fonte: BARTIÉ (2002) Como pode ser visto na figura 2, a função do teste funcional é garantir que todos os requisitos funcionais declarados no escopo do projeto/software estão sendo de fato satisfeitos. Ele testa se o algoritmo inserido no software produz os resultados esperados, através de estímulos de massa de dados de entrada (inputs) e a verificação da resposta correta da aplicação (outputs). Encontra-se com mais facilidade mão de obra qualificada para modelar os testes funcionais, pois não exige muito conhecimento da parte interna do software (código fonte, framework utilizado e etc) do funcionário alocado para esta função. O grande problema é saber se todos os cenários de testes estão de fato sendo atingidos. Para isto na seção seguinte apresentam-se as estrat égias de um ciclo de testes funcionais Estratégias adotadas em um ciclo de testes funcionais Depois que o software é construído, começa a fase de testes de alto nível, onde os critérios estabelecidos nos requisitos funcionais devem ser testados. O teste de validação é a garantia final de que o software está atendendo a todas as exigências funcionais. Os erros estão presentes, e se o engenheiro de Software não os encontrar, o cliente o fará (PRESSMAN, 2005). Nesta etapa, é necessário se ter um plano de testes, que define como selecionar as técnicas de testes, delimitar o escopo a ser testado, planejar a alocação dos recursos necessários em termos de ambiente de testes, definir ferramentas de apoio aos testes, treinamento e alocação de pessoal.

22 22 Para o processo de software no modelo de Verificação e Validação já apresentado no item 2.2, Myers (2004) diz que os componentes de um bom plano de teste são os seguintes: 1) Objetivo: Cada fase de teste deve ter um objetivo definido. 2) Critérios de Conclusão: Critérios devem ser concebidos para especificar quando cada fase do teste pode ser dada por completa. 3) Horários: Estipular horários no calendário é necessário para cada fase. Eles devem indicar quando os casos de testes serão concebidos, escritos e executados. 4) Responsabilidades: Devem ser identificadas para cada fase, as pessoas (recursos) que irão conceber, escrever, executar e controlar os casos de teste e também quem irá fazer a reparação dos erros encontrados. Faz-se necessário definir alguém como sendo a pessoa que irá apresentar o relatório de erros. 5) Biblioteca de casos de teste e padrões: Em projetos grandes é necessário métodos de identificação sistemáticos, escrever e guardar os casos de teste. 6) Ferramentas: Devem ser identificadas quais ferramentas serão necessárias para fazer os testes, incluindo quem irá desenvolver ou adquirilas, como serão utilizados e quando. 7) Tempo de Computador: Este é um plano para saber quantos computadores e por quanto tempo eles serão utilizados para cada fase de teste. Isso inclui desktops máquinas necessárias para o teste de instalação, servidores usados para aplicações de compilação e se necessário servidores Web para aplicações baseadas na Web, dispositivos de redes, e assim por diante. 8) Configuração de hardware: Se faz necessário quando tem se que configurar dispositivos ou hardwares especiais. É necessário um plano que descreva os requisitos, como vão ser cumpridos e quando eles serão necessários. 9) Integração: Faz parte do plano de teste uma definição de como o programa será integrado. Sistemas contendo grandes subsistemas ou programas podem ser reunidos de forma incremental, utilizando-se a

23 23 abordagem top-down ou bottom-up. Se este for o caso, um plano de integração é necessário. O plano de integração do sistema define a ordem da integração e a capacidade funcional de cada versão do sistema. 10) Procedimento de controle: Devem ser identificados vários meios para controlar aspectos do progresso dos testes, incluindo a localização das propensões de erros dos módulos e estimativa do progresso com respeito ao cronograma, recursos e critérios de conclusão. 11) Procedimento de depuração: Devem ser definidos mecanismos para a comunicação de erros detectados, acompanhamento do progresso das correções e implementação das correções no sistema. Também deve fazer parte do plano de depuração os horários, responsabilidades, ferramentas e tempo de computador/recursos. 12) Teste de regressão: É realizado depois de se fazer uma melhoria funcional ou um reparo pontual no programa. Seu objetivo é determinar se a alteração regrediu algum aspecto já testado no programa. O teste geralmente é realizado por re-execução de um subconjunto de casos de teste. Teste de regressão é importante, pois o programa fica muito mais propenso a erros com mudanças e alterações de códigos. Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto (MYERS, 2004, p. 41). Pode-se definir um caso de teste, como sendo um conjunto específico de entradas (input) de teste, condições de execução e resultados esperados identificados com a finalidade de avaliar um determinado aspecto de um item de teste-alvo. Os casos de teste podem ser motivados por vários fatores, mas normalmente incluirão um subconjunto dos requisitos e dos riscos envolvidos no projeto. 2.4 TESTES NÃO FUNCIONAIS Os testes não funcionais são verificações da qual o desenvolvedor ou o testador, tem que avaliar se os requisitos não funcionais especificados no começo

24 24 do projeto estão de fato sendo atendidos. Existem algumas categorias de testes não funcionais, sendo elas (BARTIÉ, 2002): a) Teste de Usabilidade; b) Teste Estrutural; a. Teste de Performance (Desempenho); b. Teste de Configuração (Ambiente); c. Teste de Confiabilidade e Disponibilidade; d. Teste de Recuperação; e. Teste de Contingência; c) Teste de Compatibilidade (Versionamento); d) Teste de Segurança; e) Teste de Instalação; As próximas seções apresenta-se conceitos gerais dos Testes Estruturais, com mais enfoque enfoque nos testes de desempenho por ser o objetivo deste trabalho Testes Estruturais Também conhecido como teste de caixa branca (BARTIÉ, 2002), consiste em avaliar o comportamento interno dos componentes do software. Diferentemente do teste de caixa preta, que apenas verifica a saída (output) em relação à entrada (input), o teste estrutural consiste em destrinchar o código fonte, fazendo com que a entrada passe por todos os caminhos lógicos implementados no software, como pode ser visto na figura 3. Caminho A Início do Processamento Término do Processamento Caminho B Figura 3: Visão de testes de caixa branca. Fonte: BARTIÉ (2002)

25 25 Pressman (2005), afirma que os defeitos encontrados pelo teste caixa preta não são os mesmos encontrados pelo teste caixa branca. Pelos seguintes motivos: a) Erros lógicos e pressuposições incorretas são inversamente proporcionais à probabilidade de que um caminho em um programa seja executado. O processamento cotidiano tende a ser bem entendido, enquanto o processamento de um caso especial tende a cair por terra. b) Muitas vezes acredita-se que um caminho lógico não tem a probabilidade de ser executado quando, de fato, ele pode ser executado regularmente. Ou seja, podem-se cometer erros de projeto que são descobertos somente quando se inicia a atividade de teste do caminho. c) Erros tipográficos são aleatórios. Quando um programa é traduzido para código-fonte da linguagem de programação, é provável que alguns erros de digitação ocorram. Muitos deles serão descobertos pela verificação de sintaxe do ambiente de desenvolvimento, mas outros passarão sem ser detectados até que os testes se iniciem. É possível que exista um erro tipográfico tanto num caminho lógico obscuro como num caminho da corrente principal Testes de Desempenho Com o desenvolvimento tecnológico atual e soluções propostas para o mundo coorporativo, a infra-estrutura que dá suporte aos serviços na Web compreende muitos recursos de hardware diferentes, desde estações de trabalho dos clientes, servidores com seus processadores e subsistemas de armazenamento, além dos recursos não previstos na especificação funcional como LANs, WANs, balanceadores de carga e roteadores. Ainda existe a complexidade de processamento de software com diferentes servidores de aplicação, camadas middlewares, sistemas de gerenciamento de banco de dados, sistemas operacionais e diferentes ambientes arquiteturais se comunicando entre si (Alta e Baixa plataforma). Todos estes ingredientes somados a uma codificação complexa sem se preocupar com boas práticas de programação, tornam ainda mais complexo definir aonde pode existir um problema de desempenho (MENASCÉ; ALMEIDA, 2003).

26 26 Uma requisição feita na Web gasta uma parte do seu tempo em processamento dentro da arquitetura da aplicação e outra parte esperando nas filas pelos recursos. Para uma aplicação Web, os pedidos feitos podem ser decomposto em duas diferentes áreas (MENASCÉ; ALMEIDA, 2003): 1. Tempos de Serviço: Tempo gasto usando vários recursos, como processadores, discos e redes. 2. Tempos de Espera: Tempo gasto esperando para usar recursos que estão sendo mantidos por outros pedidos paralelamente. Para o usuário final, existe uma única percepção, o tempo de resposta. Este, por sua vez, pode ser dividido em dois componentes: 1. Tempo de Rede: Todo o tempo gasto pelas mensagens trafegadas entre o navegador do usuário e o Web Site. 2. Tempo no Web Site: Todas requisições processadas internamente pela arquitetura do Web Site. Dentro destes dois componentes, ainda existem outros conceitos como podem ser visualizados na figura 4, que demonstram como um tempo de resposta pode ser totalizado (MENASCÉ; ALMEIDA, 2003). Tempo de Resposta Tempo da Rede Tempo do Web Site Latência Tempo de Transmissão Tempo de serviço CPUs Discos LANs Tempo de fila CPUs Discos LANs Figura 4: Complexidade da definição do tempo de resposta. Fonte: MENASCÉ; ALMEIDA (2003) Com um desmembramento do custo do tempo da rede no universo do tempo de resposta, a latência é formada pelo número de ida e volta (RTT) envolvidos na

27 27 troca de mensagens entre o navegador do cliente e o site, além do tempo de transmissão, que é o tempo necessário para a transmissão de todos os bytes. O tempo gasto por este mesmo pedido do usuário, na arquitetura do web site pode ser decomposto em dois componentes principais, conforme indicado na figura 4. O tempo de serviço é o período de tempo durante o pedido que está recebendo serviço de um recurso, como CPU, disco, LAN. Este mesmo pedido pode visitar um destes recursos, várias vezes, antes que seja concluído. Com esta frequente troca de contexto do processo no processador, estes acabam sendo enfileirados gerando assim o outro componente chamado de tempo de fila. Dentro deste cenário de complexidade arquitetural a percepção do desempenho pode se tornar algo subjetivo e que deve estar em acordo com o que é esperado de resposta pelo usuário final da aplicação. A percepção do desempenho não tem um consenso específico que defina o quão rápido um sistema deva ser principalmente para tempos de resposta em serviços Web. As métricas de desempenho para processos transacionais na alta plataforma sugeridos por Miller (1968) suportam a idéia de um tempo que o homem acredita que sua solicitação está sendo processada, caso a mesma retorne em um tempo inferior a 1 segundo, como pode ser visto na tabela 1, enquanto estudos estatísticos voltados para serviços web mais recentes (ZONA, 1999) apontam uma regra de que o tempo aceitável para resposta de uma página e ou serviço web até a desistência de um usuário é de 8 segundos. Tabela 1: Tabela de tempo de resposta por transações transacionais. Tempo de Resposta 0,1 segundo 1 segundo 10 segundos Fonte: MILLER (1968) Comentário É o limite de tempo em que o usuário sente que a aplicação está respondendo imediatamente. É o limite de tempo para que o fluxo de pensamentos do usuário se mantenha contínuo, apesar de que o usuário notará a demora no processamento. É o limite máximo de espera para manter a atenção do usuário na tela. Com a crescente demanda de serviços web e com o aumento da inclusão digital de mais usuários, a regra proposta pelo survey da Zona Research inc (1999) já não pode ser aplicada exigindo um ganho de desempenho em grandes

28 28 corporações com o medo de perda de rentabilidade líquida ou desistência destes usuários implicando em visitas a web sites concorrentes. Um estudo conduzido por Bhatti, Bouch e Kuchinsky (2000), observou como os usuários reagiam quando eles eram direcionados a usar um web site para configurar e comprar um computador. O estudo identificou que existia frustração quando o tempo de resposta era por volta de 10 segundos. Por outro lado, essa tolerância diminuía de 10 para 4 segundos quando o processo de configuração de compra do computador estava próximo do fim. Spool (2001) conduziu outro estudo com diversos usuários que deveriam visitar 10 sites diferentes e utilizar os recursos dos sites conforme o interesse de cada um. Cada usuário deveria pontuar a velocidade de cada site conforme a sua percepção. Ao final dos testes, percebeu-se que o site considerado o mais devagar de todos pelos usuários era, na verdade, o mais rápido de todos, com um tempo de resposta de 8 segundos. Por outro lado, um site corporativo mundial de compras foi considerado o mais rápido de todos, no entanto, o seu tempo de resposta era de 36 segundos. Concluíram que essa percepção contraditória está ligada aos elementos visuais da página. Em média, os usuários gastam cerca de 4 segundos lendo cada elemento. Este site corporativo oferece vários elementos interessantes do ponto de vista do usuário, dessa forma, após a requisição de uma operação, o usuário gasta vários segundos lendo esses elementos, o que torna a percepção de que o tempo de resposta do site é inferior aos 36 segundos mensurados. Um estudo mais recente publicado por Barber (2007) sugere que acima de 5 a 8 segundos de espera para o usuário já é considerado frustrante, como pode ser visto na tabela 2, e que o tempo considerado típico para o usuário é de 2 a 5 segundos. Tabela 2: Tabela de tempo de resposta de serviços Web. Tempo de Resposta Abaixo de 3 segundos De 2 a 5 segundos Tipico De 5 a 8 segundos Lento De 8 a 15 segundos Frustante Acima de 15 segundos Inaceitável Fonte: BARBER (2007) Comentário Resposta imediata Diante de um cenário subjetivo que depende única e exclusivamente da aplicação Web e do que é esperado da mesma em termos de desempenho, o consenso comum para avaliar o desempenho de uma aplicação é através do tempo

29 29 de resposta e a taxa de processamento da aplicação (MENASCÉ; ALMEIDA, 2003) (ALMEIDA; MENASCÉ; DOWDY, 2004). Além destas duas métricas principais para medição de desempenho, ainda é possível utilizar-se de outras para verificar o desempenho dos serviços na web, sendo elas: a) Tempo de Resposta de ponta a ponta: A soma total do tempo da rede ao tempo de processamento. b) Tempo de Resposta do site: O valor do tempo de espera da requisição do usuário ser completamente atendida. c) Erros por segundo: Qualquer falha no processo de interação com o servidor, como, por exemplo, um estouro na fila de conexões de usuários ignorando todas as requisições que possam ser feitas. d) Visitantes por dia: Demonstra a capacidade atual da aplicação sem degradação do tempo, sendo possível ter o cenário esperado por tempo de desempenho dos serviços prestados. e) Hits: Um único pedido de página pode gerar vários hits, dependendo dos tipos de arquivos incluídos na página HTML solicitada. Uma maneira de determinar qual será a experiência do usuário utilizando os serviços web é através dos testes de desempenho. O objetivo principal de um teste de desempenho é entender qual o desempenho do serviço sob condições de carga de trabalho que reflitam a realidade ou uma projeção da mesma. É importante que estes testes sejam planejados com antecedência e com presença imprescindível da equipe de desenvolvimento, produção e planejamento de capacidade. A chave para obtenção de sucesso nestes tipos de teste é a simulação fiel do ambiente de produção e cenários de carga de trabalho, de modo que os resultados dos testes coincidam com o mundo real da melhor maneira possível e caso a aplicação ainda não esteja disponível ao usuário final já possa ser implantada com a verificação e com o conhecimento dos limites computacionais da mesma. Os testes a serem aplicados devem incluir situações que representam uma atividade típica do sistema e situações de pico, de modo a determinar o comportamento do serviço em ambas às situações. Basicamente podem ser

30 30 definidos três tipos de testes de desempenho caracterizados pela intensidade de carga gerada (MENASCÉ; ALMEIDA, 2003): a) Teste de Carga: É criada uma carga simulada imitando o cenário de demanda típica do sistema, para saber como a aplicação se comporta. b) Teste de esforço: Como o sistema se comporta sob condições extremas (situação atípica), utilizando os cenários de pior caso utilizando a carga mais pesada do que o esperado. Este tipo de teste também é conhecido como Teste de Stress (BARTIÉ, 2002) (MEIER et al., 2007). c) Teste de pico: Testado em condições muito específicas, quando a carga é muitas vezes maior do que a média e em um pequeno espaço de tempo. Este tipo de teste também é conhecido como Spike Test (MEIER et al., 2007). Além destas definições básicas de testes de desempenho, é possível citar testes mais específicos a serem feitos dependendo do resultado esperado pelo usuário (MEIER et al., 2007). a) Capacity Test: Este tipo de teste é destinado para obtenção de resposta sobre qual a capacidade da arquitetura no seu formato original e o quanto é necessário ela crescer dependendo da demanda desejada de usuários. Uma técnica estratégica voltada a determinar um crescimento de arquitetura. b) Component Test: Teste de desempenho voltado a uma única camada da aplicação, cujo objetivo é definir o quanto a mesma isoladamente atende a demanda solicitada e qual o seu tempo de resposta. Teste isolado utilizado para identificação de gargalos específicos da arquitetura. c) Endurance Test: O objetivo deste teste é analisar como a arquitetura se comporta sobre condições contínuas de cargas normais de usuários em um período de tempo superior ao real. A partir do estudo teórico realizado, sobre os tipos de testes de desempenho em suas diferentes nomenclaturas citadas por Menascé (2003) e para os testes de desempenho mais especíifico citados por Meier et al. (2007), obtevese assim, os seguintes tipos. Teste de Carga, Teste de esforço, Teste de Pico, Capacity Test, Component Test, Endurance Test. Ressalta-se que para demonstrar os resultados do relatório gerencial proposto neste trabalho optou-se pelo teste de esforço.

31 31 Assim como nos testes funcionais que possuem um ciclo bem definido dentro da sua etapa de teste, os testes de desempenho também têm uma metodologia definida (MENASCÉ; ALMEIDA, 2003) como pode ser visto na figura 5. Definir objetivos do teste Entender o ambiente Especificar o plano de teste Definir a carga de trabalho do teste Configurar o ambiente de teste Executar os testes Analisar os resultados do teste Figura 5: Uma metodologia para o teste de desempenho. Fonte: MENASCÉ; ALMEIDA (2004) Podem existir diversos tipos de objetivos a se alcançar com um teste de desempenho, alguns exemplos possíveis (MENASCÉ; ALMEIDA, 2003): a) Determinar a capacidade do servidor Web. b) Descobrir o número máximo de usuários simultâneos que um serviço na Web aceita dentro dos limites acordados. c) Determinar a quantidade de requisições simultâneas da camada de aplicação. d) Identificar enfileiramentos na infra-estrutura do serviço Web.

32 32 e) Identificar a degradação do tempo de resposta percebido pelo usuário final ao crescimento das baterias de testes. f) Descobrir a capacidade do servidor de banco de dados. g) Identificar as funções Web que mais oneram a aplicação. Após a definição dos objetivos desejados a atingir com o teste, é necessário ter bem definido qual o ambiente que o mesmo será executado. Nesta etapa do trabalho, busca-se descobrir que tipo de infra-estrutura está rodando a aplicação (informações de servidores, se existe algum serviço terceiro) e quais os softwares envolvidos nesta infra-estrutura (sistemas operacionais, middleware, aplicações, banco de dados). Assim como no teste funcional, é necessário ter definido um plano de teste coerente que busque simular os passos dos usuários na aplicação. Este processo é o mais importante para se ter um resultado que busque atingir a expectativa dos objetivos, pois um cenário mal definido pode apresentar uma execução que não estimule de maneira correta o ambiente (MENASCÉ; ALMEIDA, 2003). Diferentemente dos testes de caixa preta, estes testes buscam englobar apenas cenários cujo final resulte em sucesso e os fluxos mais utilizados pelos usuários, procurando uma distribuição da sua carga de trabalho em percentual de uso e freqüência (BARBER, 2004), como pode ser visto na figura 6. Figura 6: Exemplo de definição de cenário e carga de trabalho. Fonte: BARBER (2004) Após a construção e definição dos cenários juntamente com a sua carga, é necessário efetuar a instrumentação com ferramentas de medição para monitorar cada camada do ambiente enquanto os testes são executados (Servidores Web, Servidores de Aplicação, Sistemas de banco de dados, Sistemas operacionais). Estes testes podem ser executados utilizando dois métodos (MENASCÉ; ALMEIDA, 2003):

33 33 1) Teste Manual: Exigindo a quantidade de mão de obra desejada para obter a quantidade total de requisições definida no objetivo do teste e também uma alta sincronia entre os envolvidos para simular a carga necessária no tempo necessário. 2) Teste Automático: Que utiliza a simulação de usuários virtuais responsáveis em fazer o papel dos usuários reais e são comandados por uma controladora única. Por facilidade, é mais comum a utilização do segundo método para execução destes testes de desempenho, pois o mesmo exige uma equipe reduzida tendo como um único pré-requisito que os envolvidos conheçam os cenários de testes e saibam utilizar a ferramenta que fará a simulação destes usuários virtuais. Ao final da execução dos testes, a última etapa da metodologia é iniciada, com o início da coleta dos dados das ferramentas que monitoram os ambientes e com base nestas informações são feitas as sugestões de melhoria e otimização para todas as camadas do ambiente, onde nem sempre estas sugestões resultam em ampliação de capacidade de processamento de hardware, podendo ser sugestões de otimização de comandos de banco de dados e engenharia baseada em modificações de complexidades algorítmicas de códigos da aplicação. O teste de desempenho é um método comum utilizado para determinar como os usuários experimentarão o desempenho de um serviço na Web, utilizando-se das abordagens específicas para cada tipo de cenário de carga desejado a simular Ferramentas de Apoio a testes de desempenho Com a necessidade de simular os usuários virtuais que representarão os usuários reais, existem diversas ferramentas livres ou pagas que podem atender às necessidades definidas para cenários específicos de testes de desempenho. Estas ferramentas têm como característica comum conter os seguintes itens: a) Requisições: Suporte a diversos tipos de requisições Web que sejam passíveis de parametrização e adequação de maneira customizável, atendendo as necessidades do teste de desempenho.

34 34 b) Controladora de agentes: Um componente específico que permita o controle dos usuários virtuais que serão executados em um ciclo de teste de desempenho. c) Agentes virtuais: Componente parametrizável que execute as requisições previamente programadas pelo software cujo papel será simular o usuário real da aplicação. As ferramentas disponíveis no mercado, tanto software livre quanto pagas, possuem pelo menos estes itens. Podem possuir também componentes a mais que agregam ao cenário da realidade da simulação destes agentes virtuais para um teste de desempenho. O objetivo deste trabalho é apresenta e trabalhar com ferramentas de software livre, porém como existem várias disponíveis no mercado na tabela 3 é apresentado um comparativo entre as mais populares ferramentas do mercado, segundo métricas de maior quantidade de número de downloads do site Opensource (OPENSOURCE, 2011). Pelo fato do grupo ter mais experiência com linguagem de programação Java e por ter suporte técnico necessário em fóruns e listas de discussões, a ferramenta escolhida pelo grupo a ser apresentada é o JMeter. Pelo fato também da ferramenta ter uma interface gráfica, isto facilita no processo de criação de um teste de desempenho podendo inclusive ter a possibilidade de depurar o mesmo em busca de possíveis erros antes de uma execução.

35 35 Tabela 3: Tabela comparativa entre as principais ferramentas de teste de desempenho software livre do mercado. Critério de Avalição Protocolos Funções de Execução Programação em script's Extensibilidade Testes distribuídos Descrição JMeter OpenSTA Webload Protocolos de comunicação que são possíveis simular nas ferramentas Execução do script, facilidade de depuração de um script A possibilidade de manipular os protocolos capturados através de linguagem de script's Possibilidade de aumentar a funcionalidade da ferramenta através de módulos próprios desenvolvidos Possibilidade de executar um teste em diversas máquinas distribuidas dentro de uma rede HTTP,HTTPS, FTP, SOAP/XML- RPC, JMS, JDBC Possui uma interface gráfica permitindo a visualização da execução do script Utiliza linguagem Beanshell/Java Pode ser gerado uma nova versão da aplicação com o desenvolvimento Java de novas telas utilizando SDK do motor Suporta múltiplas máquinas a serem controladas por uma única instância para execução HTTP 1.0 / 1.1 / HTTPS (SSL), SOAP/XML Apenas atráves de log's Linguagem própria chamada "SCL", utiliza o motor da linguagem BASIC Apenas através de script's "SCL" é possível incluilos através importação de aos testes já criados Suporta múltiplas máquinas a serem controladas por uma única instância para execução HTTP/S, WAP, AJAX, ActiveX, Java Apenas atráves de log's Utiliza Javascript Apenas através de Javascript é possível inclui-los através de importação aos testes já criados Não oferece suporte Escalabilidade Possibilidade da ferramenta gerar um número específico de usuários virtuais e gerencia-los de maneira satisfatória a concluir um teste sem oferecer risco de travamento Recurso utilizado para criação de usuário é a memória RAM. Não existe limitação de criação destes usuários virtuais. Recurso utilizado para criação de usuário é a memória RAM. Não existe limitação de criação destes usuários virtuais. Recurso utilizado para criação de usuário é a memória RAM. Não existe limitação de criação destes usuários virtuais. Suporte Técnico Fonte: Os autores (2011) Possibilidade de buscar informações e auxilio aos desenvolvedores da ferramenta Fórum próprio de desenvolvedores entusiastas e comunidade Suporte apenas com equipe de criação da ferramenta Suporte apenas com equipe de criação da ferramenta, através de um plano de contrato.

36 36 3 JMETER JMeter é um aplicativo desktop Open Source cujo objetivo principal é testar e medir o desempenho e comportamento funcional de aplicações cliente/servidor, aplicações estas que podem tanto ser Web quanto aplicações FTP (JMETER, 2011). O idealizador e primeiro desenvolvedor desta ferramenta foi Stefano Mazzocchi, do grupo Apache Software Foundation. Nos primórdios a ferramenta tinha o objetivo principal de fazer testes de desempenho no Apache JServ (HALILI, 2008), que mais tarde foi substituído pelo Apache Tomcat. Desde então a comunidade de desenvolvedores entusiastas ao JMeter vem em processo contínuo de desenvolvimento e expansão, adicionando novas funcionalidades para testes de desempenho destinados a servidores FTP, servidores de banco de dados, servidores de aplicação e Servlets Java. 3.1 ARQUITETURA DA FERRAMENTA Desenvolvida na linguagem Java e por ser Open Source, é uma ferramenta altamente extensível a criação de componentes adicionais pela comunidade digital através da sua API (JMETER, 2011). Por ser desenvolvido em Java, o JMeter pode ser utilizado em qualquer sistema operacional que tenha pelo menos uma JVM 1.3. A ferramenta possui uma interface gráfica GUI (Java Swing), que atua como se fosse um cliente de uma arquitetura cliente/servidor, onde estes são simulados no componente denominado grupo de usuários, que por sua vez instanciam a quantidade de processos desejados no container da ferramenta simulando assim requisições reais. Com os cenários criados e executados na ferramenta, é possível medir tempo de resposta e diversos outros componentes de servidores envolvidos no teste como uso de CPU, utilização de memória e utilização de recursos específicos. A interface do usuário é dividida em dois painéis principais. No painel mais a esquerda, como pode ser visto na figura 7, é onde fica a árvore de execução do teste, inicialmente mostrando já dois componentes ao usuário, o item Plano de teste que irá conter todos os passos seguidos para execução de um teste, e a área de trabalho, onde ficam os componentes de apoio para criação de um cenário.

37 37 Figura 7: Tela inicial da ferramenta JMeter. Fonte: Os autores (2011) 3.2 PRINCIPAIS FUNCIONALIDADES Um plano de teste de desempenho típico consiste em pelo menos um grupo de usuários, controladores lógicos, testador, ouvintes, temporizadores, asserções e configurações de ambiente, como podem ser visto na figura 8. Figura 8: Principais elementos de um teste de desempenho. Fonte: Os autores (2011) Cada um destes elementos tem como papel (HALILI, 2008): a) Grupo de Usuários: É neste componente que é definida a quantidade de usuários virtuais que o teste irá simular. É necessário que todos os componentes envolvidos no teste estejam aninhados a este componente. b) Ouvinte: Fornece as informações coletadas pelos testes executados no JMeter.

38 38 c) Configuração de ambiente: Atuam diretamente ao componente Testador. Estas configurações são responsáveis pelo funcionamento real das solicitações de usuários, como por exemplo, configurações de cookies de sessão. d) Controlador lógico: Responsável por agrupar o componente de testador. É nele que pode ser inserida a lógica necessária para tomada de decisões no cenário de teste. e) Temporizador: Componentes que permitem inserir pausa ou atrasos esperados entre as requisições, caso seja necessário. f) Testador: É onde ficam definidos os passos do usuário. g) Asserção: Componente que permite fazer verificações que testam os retornos das requisições feitas, assegurando assim que está de acordo com o esperado. 3.3 SIMULAÇÃO DE USUÁRIOS VIRTUAIS Um dos elementos essenciais do JMeter é o Grupo de usuários. É neste elemento que são feitas as configurações necessárias para simular as múltiplas cargas que estimulam o comportamento do servidor sob condições de testes. É possível com este componente agendar execuções de testes, como pode ser visto na figura 9. Figura 9: Tela de parametrização do componente Grupo de usuários. Fonte: Os autores (2011) Este componente é uma implementação abstrata de uma classe chamada ThreadGroup, como pode ser visto na figura 10, pertencente ao pacote core do

39 39 JMeter, que é a responsável por definir as configurações apresentadas no painel da interface gráfica ao usuário. Figura 10: Diagrama de classes do Grupo de usuários. Fonte: Os autores (2011) Dentro desta classe estão definidos os seguintes objetos: a) RAMP_TIME: Uma variável do tipo String que recebe o valor definido no campo tempo de inicialização. Este tempo é definido pelo usuário de quanto em quanto tempo os usuários virtuais devem entrar para fazer uma execução. b) SCHEDULER: Uma variável do tipo String responsável em instanciar ou não o método se será utilizado, o campo de agendamento pelo teste. c) START_TIME: Variável absoluta do tipo String que recebe o valor da hora de início que o teste foi agendado. d) END_TIME: Variável absoluta do tipo String que recebe o valor da hora de fim que o teste foi agendado. e) DURATION: Variável absoluta do tipo String que recebe o tempo total que a execução agendada deve ser executada. f) DELAY: Variável absoluta do tipo String que recebe o atraso definido para a execução agendada. Já dentro da classe AbstractThreadGroup, tem as implementações dos seguintes objetos:

40 40 a) ON_SAMPLE_ERROR: Variável do tipo String que verifica qual ação a tomar, caso alguma requisição do usuário tenha erro, podendo ser elas: a. ON_SAMPLE_ERROR_CONTINUE: Corresponde ao campo Continuar, caso alguma requisição apresente erro. b. ON_SAMPLE_ERROR_STOPTHREAD: Corresponde ao campo Interromper o usuário virtual, caso alguma requisição apresente erro. c. ON_SAMPLE_ERROR_STOPTEST: Corresponde ao campo Interromper teste, caso alguma requisição apresente erro, aquele cenário especifico é interrompido ao final do mesmo. d. ON_SAMPLE_ERROR_STOPTEST_NOW: Corresponde ao campo Interromper Teste Agora, caso alguma requisição apresente erro, aquele cenário é interrompido no momento. b) NUM_THREADS: Variável do tipo String que é a responsável em criar o número de thread s virtuais que representarão os usuários. c) MAIN_CONTROLLER: Variável do tipo String que cria o componente Grupo de Usuários nas propriedades da arquitetura. 3.4 SIMULAÇÃO DE REQUISIÇÕES Com o elemento grupo de usuários definido em um plano de teste, é necessário que este tenha as requisições que façam realmente o papel de um usuário real. Com o JMeter é possível simular diversos tipos de requisições diferentes (JMETER, 2011), dentre elas: 1) Web HTTP, HTTPS 2) SOAP 3) Banco de dados via JDBC 4) LDAP 5) JMS 6) Mail POP3(S) e IMAP(S) Todas estas requisições ficam agrupadas, como pode ser visto na figura 11, dentro do grupo chamado Testador, que fica disponível sendo um elemento filho na hierarquia de um plano de teste, contido dentro do Grupo de Usuários.

41 41 Figura 11: Requisições agrupadas no elemento Testador. Fonte: Os autores (2011) Internamente, cada protocolo possui uma implementação específica pertinente a cada uma das requisições pertencente ao pacote de códigos \src\protocol\. Estas requisições são utilizadas pelo componente grupo de usuário para simular o protocolo desejado a ser utilizado em um cenário de teste de desempenho. Cada uma das requisições tem os campos específicos que montam uma mensagem de acordo com a sua solicitação. O testador mais comumente utilizado em testes de desempenho é a Requisição HTTP (HALILI, 2008). Este testador é responsável em montar a mensagem destinada a um servidor especificado nos seus campos para simulação de ação do usuário, como pode ser visto na figura 12. Figura 12: Componente Testador do tipo Requisição HTTP. Fonte: Os autores (2011) Cada um dos campos preenchidos é acrescentado à mensagem que é enviada para um servidor. Nem todos os campos são de preenchimento obrigatórios (HALILI, 2008), exceto: a) Nome do servidor ou IP: Caminho único para acesso ao servidor testado

42 42 b) Número da porta: Qual a porta disponível pelo servidor a receber requisições, se esta ficar em branco é adotada a porta padrão 80. c) Método: Neste combo box é possível escolher dentro dos possíveis métodos de requisição a ser montado, sendo dois os principais: a. GET: Ao indicar no cabeçalho da mensagem que a requisição destinada ao servidor é deste tipo, o servidor procura internamente o que a mensagem enviada está procurando e entrega a solicitação ao usuário. b. POST: Caso no cabeçalho da mensagem esteja este método, junto com a mensagem deve haver pelo menos um campo preenchido pelo usuário destinado ao servidor como uma ordem, e o servidor deve responder esta requisição conforme o esperado pelo usuário. d) Enviar parâmetros com a requisição: Caso o campo método seja do tipo POST, é necessário que alguns campos esperados pelo servidor estejam presentes neste campo. É necessário um prévio conhecimento da aplicação para preencher este campo, pois é preciso que seja passado como parâmetro campos com nomes válidos e valores esperados pelo servidor, como pode ser visto na figura 13. Figura 13: Exemplo de campo preenchido para pesquisa no site Google. Fonte: Os autores (2011) 3.5 RELATÓRIOS O JMeter possui uma série de relatórios que auxiliam na análise do resultado de um teste de desempenho ou simplesmente no momento de depuração de um script desenvolvido. Os relatórios do JMeter estão agrupados no componente Ouvinte, que por sua vez colhem informações dos Testadores e apresentam-nas seja como uma

43 43 tabela, um gráfico, uma árvore de execução ou simplesmente em saída texto escrita em um arquivo do tipo log (HALILI, 2008). Cada Ouvinte demonstra as informações coletadas de um modo específico, como por exemplo, a coleta do tempo de resposta de uma página especifica, como pode ser visto na figura 14. Figura 14: Aggregate Graph é um ouvinte disponível para apresentar um gráfico de tempo de resposta de um teste executado. Fonte: JMETER (2011) A coleta feita pelo JMeter para conseguir montar este gráfico pode ser escrita em um arquivo de saída do tipo jtl, uma extensão própria utilizada pela ferramenta que salva as informações contidas na tabela de apoio que é utilizada para montagem do gráfico apresentado. Todos os ouvintes disponibilizados nativamente para o JMeter possuem um campo em comum, que é a opção de configuração de arquivo de escrita, como pode ser visto na figura 15.

44 44 Figura 15: Ao acionar o botão configurar, é possível customizar o tipo de informação escrita no relatório de saída do relatório. Fonte: Os autores (2011) Como a principal funcionalidade do JMeter é simular usuários virtuais e não apresentar relatórios gerenciais gráficos, estes relatórios disponibilizados podem consumir muito recurso computacional da estação que estiver executando a ferramenta, pois estes gráficos são gerados em tempo de execução necessitando uma quantidade alocada de memória física disponibilizada pela máquina virtual que instanciou o JMeter (HALILI, 2008) Métricas geradas Como medir qual o ponto em cada um dos servidores envolvidos em um teste tem o desempenho degrado ou algum gargalo aparece? (HALILI, 2008, p. 68). Com um plano de teste bem equilibrado tendo um crescente número de grupo de usuários virtuais distribuídos de maneira que seja possível verificar o momento de ruptura de desempenho de determinadas funcionalidades. As principais métricas contidas para uma análise simples de tempo de resposta por página consistem em coletas de hit s por páginas e o tempo levado para a resposta de uma solicitação ao servidor (MENASCÉ; ALMEIDA, 2003). Basicamente, é em cima destas duas métricas que o JMeter monta o relatório de tempo de resposta por páginas em tempo de execução. Cada processo disparado pelo grupo de usuários tem um identificador interno que permite o controle das métricas de maneira individual, estes identificadores podem ser vistos no anexo A.

45 45 Tendo estas métricas geradas nativamente pelo JMeter, é comum obter diversos outros relatórios gerados por desenvolvedores entusiastas da ferramenta e disponibilizados para todos no próprio portal de adicionais criados pela comunidade open source (JMETER PLUGIN, 2011). Porém, como citado por Halili (2008), ter um plano de teste com muitos gráficos gerados na ferramenta podem causar um problema de desempenho na própria, mascarando assim resultados ou até mesmo tendo insuficiência de recursos físicos para a execução de um teste. 3.6 MANEIRAS PARA EXECUÇÃO DE UM TESTE Com a criação de um cenário de teste concluída e as monitorações feitas nos servidores envolvidos, tudo já está de acordo para a execução de um cenário de teste de desempenho utilizando o JMeter. O JMeter disponibiliza três maneiras para execução de um teste (JMETER, 2011): 1) Interface gráfica 2) Linha de comando 3) Execução remota Interface gráfica Através da interface gráfica é possível acompanhar a quantidade de processos que estão sendo criados e executados enquanto um teste está em andamento, como pode ser visto na figura 16. Figura 16: Indicador visual que mostra que está em execução 1 processo de 100. Fonte: Os autores (2011) Quando uma execução feita pela interface gráfica é finalizada, o indicador da quantidade de processos criados torna a ficar 0 e sua cor fica novamente cinza, como pode ser visto na figura 17.

46 46 Figura 17: Fim de uma execução de teste. Fonte: Os autores (2011) Os gráficos gerados pelo JMeter só podem ser obtidos com a execução no modo gráfico (JMETER, 2011) Linha de comando Por ter uma interface amigável e de fácil utilização, comumente execuções de testes de desempenho no JMeter são feitas através da sua interface gráfica. Porém, dependendo da quantidade de usuários a serem simuladas, as características físicas da máquina escrava não necessitam atender a demanda tendo, como por exemplo, uma quantidade de memória física disponível para a JVM do JMeter suficiente para a quantidade de processos, caso contrário pode ser afetada a velocidade e a frequência que estes processos são encaminhados ao servidor (HALILI, 2008). Como o JMeter é um aplicativo JAVA, para executar um teste sem utilizar a interface, é necessário invocá-lo através de uma janela de comando informando os parâmetros desejados na linha de comando, como pode ser visto na figura 18. jmeter -n -t meu_teste.jmx -l log.jtl Figura 18: Exemplo de execução de teste utilizando o JMeter. Fonte: JMETER (2011) Onde cada uma das opções corresponde a (JMETER, 2011): -n: Comando específico indicando que o JMeter será executado sem a interface gráfica. -t: Nome do plano de teste criado no JMeter utilizando a interface gráfica. -l: Nome do arquivo de saída que será gerado contendo os resultados da execução.

47 Execução remota É possível executar o JMeter de maneira distribuída, tendo uma instância como nó escravo (servidor JMeter) e suas máquinas que poderão controlar sua execução. Para isso, é necessário que todas as máquinas envolvidas estejam executando a mesma versão de JMeter e preferencialmente com a mesma versão do JAVA instalado (JMETER, 2011), além disso, toda a massa de dados utilizada pelos cenários (como arquivos do tipo csv) devem estar localmente em cada uma das máquinas. Para executar o JMeter no modo remoto, é necessário executá-lo através da instância jmeter-server. Ao executar a instância através deste modo, o JMeter registra uma porta RMI (Remote Method Invocation) dinâmica por onde as máquinas que irão controlá-la possam se comunicar. Com o nó servidor em execução, é necessário efetuar uma parametrização nas máquinas distribuídas. No arquivo de propriedades do JMeter (diretório_instalação/bin/jmeter.properties), no campo remote_hosts deve ser adicionado o IP da máquina servidora que está sendo executada a instância jmeterserver, como pode ser visto na figura 19. Figura 10: Campo parametrizado no arquivo jmeter.properties. Fonte: Os autores (2011) Ao definir neste arquivo que o JMeter terá uma máquina servidora para execução, estará disponível na sua interface gráfica no menu Executar a opção Executar remoto, com o IP do endereço servidor para parametrização, como pode ser visto na figura 20.

48 48 Figura 20: Possibilidade de execução remota de um script. Fonte: Os autores (2011) Este tipo de execução é feita quando a máquina disponibilizada para criação dos scripts não atende a configuração necessária para simulação da quantidade de usuários desejados para um teste mais pesado, podendo assim criar os scripts em uma máquina e executar o teste em outra com maior capacidade de processamento físico (HALILI, 2008).

49 49 4 PLATAFORMA ANDROID É uma plataforma para tecnologia móvel completa, envolvendo um pacote com programa para celular, já com um sistema operacional, middleware, aplicativos e interface do usuário (PEREIRA; SILVA, 2009). O Android foi construído com a intenção de permitir aos desenvolvedores criar aplicações móveis que possam tirar total proveito do que um aparelho portátil possa oferecer. Por ser open source, pode ser sempre adaptado a fim de incorporar novas tecnologias. A plataforma está em constante evolução, já que as comunidades de desenvolvedores estarão trabalhando em conjunto para construir aplicações móveis inovadoras. 4.1 ARQUITETURA DA PLATAFORMA Em Novembro de 2007 o Google anunciou que estava à frente da OHA (Open Handset Alliance) disponibilizando o SDK (Software Development Kit) dias depois. Era esperado que o lançamento de um telefone celular fosse feito, porém foi feito o anúncio de algo mais complexo: Uma plataforma completa para dispositivos móveis batizada de Android. A arquitetura da plataforma Android é dividida em cinco partes fundamentais: Kernel Linux, bibliotecas, ambiente de execução, framework e aplicativo (PEREIRA; SILVA, 2009). A figura 21 ilustra tais camadas conforme a posição em que se encontram. Figura 21: Imagem da arquitetura da plataforma Android. Fonte: PEREIRA, SILVA (2009)

50 50 Cada uma destas camadas presente na figura 21 possui uma funcionalidade específica, sendo elas explicadas nos itens abaixo. a) Applications: Esta camada é destinada a todos os aplicativos fundamentais do Android, todos escritos utilizando a sintaxe Java. Portanto, é nesta camada que os programas criados são executados pela máquina virtual Dalvik. b) Application Framework: nesta camanda se encontram todas as API s e recursos utilizados pelos aplicativos desenvolvidos. Pode ser encontrada como, por exemplo, as classes visuais, listas, grades, caixas de texto, botões, view system (componente responsável para construção de aplicativos) e content provider (componente responsável por uma aplicação acessar informações de outra aplicação). Os principais elementos desta camada são (PEREIRA; SILVA, 2009): a. Activity Manager: É responsável pelo gerenciamento de todas as atividades, quando ela é iniciada e quando é terminada. b. Package Manager: Utilizada pelo activity manager para ler as informações dos pacotes de arquivos Android. O package manager se comunica com o resto do sistema e diz quais os pacotes estão sendo utilizados. c. Window Manager: Responsável por gerenciar as apresentações de janelas. d. Content Providers: Compartilha os dados entre os aparelhos, possibilitando a troca de informações entre os aplicativos. e. View System: Disponibiliza todo o tratamento gráfico para as aplicações. c) Libraries: Esta camada disponibiliza um conjunto de bibliotecas compiladas na linguagem C/C++ utilizadas pelo sistema. Além destas, possui também bibliotecas destinadas a área multimídia, visualização de camadas 2D e 3D, funções específicas para navegadores web, funções de aceleração de hardware, renderização 3D, fontes bitmap e funções de acesso ao banco SQLite. Todos os recursos destas bibliotecas estão disponíveis para o desenvolvimento de aplicativos (MURPHY, 2008). Dentre as principais bibliotecas, é possível destacar (PEREIRA; SILVA, 2009):

51 51 a. Freetype: Renderização de fontes e bitmaps. b. System C Library: Uma implementação derivada da biblioteca C padrão sistema (libc) do tipo Berkeley Software Distribution (BSD). Esta implementação resultou na geração de uma biblioteca desenvolvida exclusiva para o Android, chamada C Bionic. c. Webkit: Biblioteca baseada no código aberto do navegador webkit (WEBKIT, 2011). É nesta API que estão disponíveis os web services embarcados ao Android. Dentro desta biblioteca está disponível o Apache Jakarta Commons HttpClient, que por sua vez permite o acesso direto utilizando a arquitetura do tipo REST (Representational State Transfer) proposta por Fielding (2000), que propõe a utilização de transferências de estados entre o cliente-servidor de maneira bem definida, utilizando sinônimos. d. SQLite: Engine de banco de dados relacional, implementado em C, que dá suporte a base de dados acima de 2 terabytes. e. SGL: Responsável pelos gráficos 2D subjacentes. f. Surface Manager: Responsável por prover o acesso aos subsistemas de exibição, como as camadas 2D e 3D. g. Media Libraries: Uma biblioteca baseada no PacketVideo s OpenCORE (PACKET, 2011), que dão suporte a formatos populares de áudio e vídeo. h. LibWebCore: Bibliotecas específicas destinadas ao navegador Android. i. 3D Libraries: Implementação baseada nas API s do OpenGL ES 1.0 (OPENGL, 2011). d) Android Runtime: Nesta camada contida dentro das Libraries do Android, é onde uma instância da máquina virtual Dalvik, criada para cada aplicação executada no Android, é executada (PEREIRA; ALMEIDA, 2009). A Dalvik (DALVIK, 2011) é uma máquina virtual com melhor desempenho, maior integração com a nova geração de hardware e projetada para executar várias máquinas virtuais paralelamente.

52 52 O Core Libraries inclui um grupo específico de bibliotecas que fornece a maioria das funcionalidades disponíveis nas principais bibliotecas nativas da linguagem Java, como estrutura de dados, acesso a arquivos, acesso a redes e gráficos. e) Linux Kernel: Esta camada atua como abstração entre o hardware e o resto da pilha de software. É utilizado como Kernel Linux a versão 2.6 para serviços centrais do sistema, tais como segurança, gestão de memória, gestão de processos, pilha de protocolos de rede e modelo de drivers. Um dos componentes a se destacar desta camada é o Binder, responsável por obter e enviar para a aplicação requerente a interface de serviço da aplicação requerida, possibilitando assim a comunicação inter-processos. É nesta camada também que se encontra o sistema de gerenciamento de energia do Android, onde um aplicativo requisita o gerenciamento de energia e o driver de energia do kernel passa a checar periodicamente todos os dispositivos que não estão sendo utilizados por aplicações e o desliga. 4.2 CARACTERÍSTICAS DO SISTEMA OPERACIONAL Com o kernel embarcado no Android, o Sistema Operacional possui um Application Framewok que permite o reuso e a substituição de componentes e uma máquina virtual (Dalvik), que é a responsável por executar softwares escritos na linguagem Java e compilada num formato especial de bytecodes. Possui ainda um navegador baseado no Webkit Engine, também usado pelo Safari, um ambiente gráfico e gerenciador de pacotes, biblioteca de compilação 2D e 3D, um banco de dados sendo executado na engine SQLite para armazenar os dados estruturados, suporte para mídias: áudio, vídeo, formatos de imagens (MPEG4, H.264, MP3, AAC, AMR,JPG, PNG e GIF), telefonia GSM, bluetooth, EDGE, 3G e WiFi, câmera, GPS, compasso e acelerômetro.

53 RECURSOS OPERACIONAIS Apesar do Android usar como linguagem de programação nativa Java, em seu sistema operacional não existe uma JVM, mas sim a máquina virtual Dalvik que é otimizada para execuções em dispositivos moveis (LECHETA, 2009). Cada aplicação do Android roda seu próprio processo em uma instância da máquina virtual Dalvik (uma instância especial responsável por criar outras instâncias da JVM). Essa máquina virtual foi escrita para ser rodada eficientemente com múltiplas instâncias e executa arquivos de extensão dex, ainda no formato bytecode desenhado para ocupar menos espaço e carregar rapidamente. Estes arquivos dex e outros recursos como imagem são compactados em um único arquivo com a extensão apk que representa a aplicação final, pronta para ser instalada e finalmente executada. 4.4 APLICATIVOS EXECUTADOS NO ANDROID O Android possui APIs que permitem total modificação por meio de programação do seu conteúdo. Porém, não é necessário sempre utilizar de modificações destas APIs para implementação de softwares, pode-se apenas utilizar o que já está desenvolvida nelas para implementações. As APIs disponibilizadas com maior utilização para o desenvolvimento (PEREIRA; SILVA, 2009) podem ser vistas no Anexo B contido neste documento. Existem quatro elementos da aplicação essenciais para que o sistema Android possa instanciar e executar softwares desenvolvidos, sendo eles (PEREIRA; SILVA, 2009): Activities: É representado por uma tela na aplicação. Possui uma interface composta por Views, consistindo de várias telas que respondem a eventos previamente programados. Cada atividade é uma especialização da classe Activity, que possui um ciclo de vida específico (MURPHY, 2008), que pode ser visto na figura 22.

54 54 Activity Executando OnCreate() OnStart() OnResume() OnPause() OnResume() OnResume() OnStart() OnRestart() Parada *Kill OnStop() Interrompida OnDestroy() *Kill Finalizada Figura 22: Ciclo de vida de uma atividade. Fonte: MURPHY (2008) Quando uma atividade é iniciada, ela é colocada no topo da pilha de atividades e seu estado é modificado para execução. As atividades abaixo que está em execução somente passará para o estado de Executando quando a atividade em execução for finalizada. A responsabilidade de cada método presente no ciclo de vida de uma atividade (PEREIRA; SILVA, 2009) pode ser vista no Anexo C presente neste documento. Cada estado representado na figura 22 tem uma função específica neste ciclo de vida de uma atividade, sendo elas: 1) Executando: Atividade ativa no visor do dispositivo. 2) Parada: Atividade que perdeu o foco para outra atividade, mantém suas informações de estado, porém não interage com o usuário. 3) Interrompida: Caso uma atividade não esteja sendo utilizada pelo usuário, ela mantém as suas informações de estado. 4) Finalizada: O sistema remove a atividade da memória, caso esteja interrompida temporariamente ou estiver parada.

55 55 O sistema pode finalizar as atividades que estiverem no estado Parada ou Interrompida, caso necessite de memória, chamando os métodos OnDestroy() e OnStop() representados como kill na figura 22. a) Services: Todo código que não possui uma interface com o usuário, que são executados em segundo plano e não são interrompidos quando existe uma troca de atividade pelo usuário. Ao contrário do Activity, este elemento possui um ciclo de vida próprio e uma vida curta (PEREIRA; SILVA, 2009), estes são mantidos como um serviço ativo até que seja recebido uma outra ordem. Uma vez conectado com o serviço, pode-se comunicar com este através de uma interface apresentada para o usuário. b) Broadcast Receivers: Este elemento é acionado através de eventos externos, como por exemplo, o acionar de uma ligação telefônica ou quando existem redes disponíveis. c) Content Provider: Quando existe a necessidade de compartilhamento dos dados de uma aplicação com outras aplicações, este é o elemento utilizado, que basicamente compartilha os dados entre os aplicativos. Os elementos activities, services e Broadcast Receivers são ativados por mensagens assíncronas, chamadas Intents, diferentemente dos Content Providers, que são ativados por pedidos de um Content Resolver. Um intent é um objeto que detém o conteúdo de uma mensagem (PEREIRA; SILVA, 2009). Por exemplo, para uma activity, poderia transmitir o pedido de mostrar uma foto, e para um Broadcast, poderia anunciar que a bateria está descarregada.

56 56 5 ELABORAÇÃO DE UM TESTE DE ESFORÇO USANDO O JMETER Este capítulo apresenta os passos necessários para a elaboração de um teste de esforço usando o JMeter. Como o JMeter é uma ferramenta cujo objetivo não é analisar o desempenho de aplicações WEB e sim executar testes de desempenho, neste trabalho propôs-se a criação de um aplicativo para apresentar os resultados de uma execução de testes de desempenho para a plataforma Android. Para o desenvolvimento deste aplicativo, foi necessária a criação de uma arquitetura hipotética de uma loja do tipo e-commerce para ser elaborado um teste de esforço utilizando o JMeter. Para que assim fosse possível ter insumos suficientes para o funcionamento do relatório gerencial desenvolvido para o Android, o JPlotMeter. Portanto, nas próximas seções está descrita de forma sucinta a arquitetura lógica deste portal. 5.1 ANALISANDO A ARQUITETURA EM UM TESTE DE DESEMPENHO As aplicações baseadas na Web normalmente são enquadradas em uma arquitetura de três camadas. A primeira camada nesta arquitetura, também chamada de apresentação, incorpora a interface de usuário com os serviços na Web. É nesta camada onde o usuário final preenche as informações que serão inseridas na aplicação. Na camada seguinte, onde estas informações preenchidas são processadas, é chamada de camada do negócio ou camada de aplicação. É nesta que estão encapsuladas uma coleção de regras para implementar a lógica da aplicação. Finalmente, os dados solicitados por este servidor de aplicação são processados por um servidor de banco de dados, onde são consistidas as informações de negócio. Esta distribuição das camadas pode ser vista na figura 23. Figura 23: Arquitetura típica de um Web Site de múltiplas camadas. Fonte: Os Autores (2011)

57 57 Neste trabalho utiliza-se uma aplicação baseada na arquitetura típica de um e-commerce, o JPetStore (JPETSTORE, 2011). O JPetStore é uma loja virtual cujo objetivo é efetuar vendas de animais pela internet, armazenando as informações em um banco de dados. Esta aplicação foi proposta originalmente pela Sun como uma loja virtual que utiliza conceitos do Java EE. Nos próximos itens, é abordado como cada um destes serviços dispostos na arquitetura proposta foram implementados Camada WEB O software do servidor WEB, também conhecido como servidor HTTP, é um programa que controla o fluxo de dados recebido e emitido em um computador conectado a uma intranet ou à internet. (MENASCÉ, ALMEIDA, 2003, p. 117). Esta é a camada responsável em atender os pedidos HTTP que são enviados pelos clientes através da rede. O servidor estabelece a conexão solicitada entre o cliente e ele mesmo, envia as informações solicitadas e retorna ao modo de escuta. Para agilizar este processo de pedidos, os servidores WEB tratam mais de um pedido por vez. Estes servidores WEB fazem mais do que enviar apenas páginas HTML. Um site ganha dinamismo oferecendo interatividade e efeitos especiais, utilizando programas instalados no cliente, como por exemplo Java, ActiveX e Dynamic HTML. Com estes programas instalados do lado do cliente, o tempo de resposta de requisições ao servidor pode diminuir, pois evita o uso de rede e possíveis atrasos no servidor. Os servidores WEB convencionais normalmente rodam no espaço do usuário, tornando as trocas de contexto necessárias para cada operação de I/O de disco pelo servidor. Na arquitetura do JPetStore o servidor WEB adotado para fazer a apresentação das páginas ao usuário é o Apache HTTP Server Camada de Aplicação Um servidor de aplicação é o software que trata de todas as operações da aplicação entre os clientes baseados em um navegador e o banco de dados. Nesta camada, as solicitações são feitas à camada WEB.

58 58 O objetivo do servidor de aplicação é disponibilizar uma aplicação desenvolvida sem que a mesma esteja exposta diretamente a rede. Com isso, assim que é concluida uma aplicação a mesma é instalada dentro deste servidor de aplicação para que seja possível usuários externos acessa-la. O JPetStore foi idealizado para utilizar o padrão de desenvolvimento Java EE, cujo diferencial para o Java SE é que este é tolerante a falhas em sistemas desenvolvidos multi-camadas e utiliza de bibliotecas específicas para este tipo de tráfego de informação. Portanto, para ter o motor de negócio do JPetStore funcionando, a aplicação foi instalada no servidor de aplicação chamado GlassFish Camada de Dados É nesta camada que as solicitações feitas à camada WEB são consistidas, caso seja assim esperado. Um servidor de banco de dados executa e gerencia aplicações de processamento de transação. Ele pode ser um sistema de banco de dados relacional, que dá suporte a procedimentos armazenados, que pode emitir pedidos SQL ao banco de dados. Estes servidores de gerenciamento de dados devem garantir que os dados permaneçam integros por todo o ambiente distribuído, através do uso de recursos como bloqueio de dados, coerência e replicação. Para consistir nas transações efetuadas no JPetStore, o sistema de gerenciamento de banco de dados escolhido foi o MySQL. A modelagem deste banco de dados pode ser vista no Apêndice A. 5.2 ESCOLHA DE UM TESTE DE DESEMPENHO Para que fosse possível potencializar a demonstração do relatório de tempo médio de resposta por página desenvolvido para o Android, foi escolhido o teste de esforço, que é o tipo de teste de desempenho que oferece maiores insumos para visualização da degradação de utilização dos recursos computacionais. Para a criação de um ciclo de teste de esforço, inicialmente é necessário mapear as funcionalidades da aplicação que se deseja aplicar o teste. Assim que as funcionalidades são mapeadas é necessário também que se tenha um histórico de utilização das mesmas para que seja possível mensurar a criação da carga que será

59 59 utilizada em uma bateria de testes, assim como as informações necessárias a serem utilizadas pelos agentes virtuais que simularam os testes. 5.3 CRIAÇÃO DE UM CASO DE TESTE DE DESEMPENHO Com a fundamentação teórica proposta por Meyer levantada neste trabalho, foram definidos dois casos de teste de desempenho, utilizando duas funcionalidades da aplicação. A primeira refere-se ao fluxo de compra de um animal e a segunda, à pesquisa de um animal. Estes fluxos funcionais estão representados na forma de um caso de teste nas tabelas 4 e 5. Tabela 4: Caso de teste da funcionalidade de compra de um animal. Título: Compra com sucesso de um animal Objetivo: Efetuar a compra de um animal qualquer no site JPetStore recebendo a mensagem do sistema de procedimento efetuado com sucesso. Pré-Condição: Estar logado na aplicação com um usuário registrado no aplicativo JPetStore Pós-Condição: Ter feito a compra do animal com sucesso PASSOS RESULTADOS ESPERADOS 1. Entre no site da aplicação; 1. Deverá abrir a página home da aplicação. 2. Clique em Sign in ; 2. Deverá retornar ao usuário dois campos para efeutar login na aplicação. 3. Informe no campo Username e password informações válidas e clique em Login ; 3. Deverá abrir a página home da aplicação com a opção Sign Out e My Account aparecendo no banner da página. 4. Ao lado esquerdo da página, escolha uma das 4. Ao clicar em uma das categorias, deverá categorias dos animais disponíveis (Fish, Dogs, retornar ao usuário uma outra página contendo Cats, Reptiles, Birds); os animais disponiveis naquela categoria. 5. Clique em um dos animais presentes na lista; 5. Deverá ser listado os tipos de animais 6. Clique em um dos animais listados para ver o detalhe do mesmo; disponíveis para aquela categoria. 6. Deverá retornar ao usuário detalhes do animal selecionado, inclusive listando a quantidade do mesmo em estoque. 7. Clique em Add to cart ; 7. Deverá retornar ao usuário a página Shopping Cart com a quantidade total de pedidos feito pelo mesmo. 8. Clique em Proced to Checkout ; 8. Deverá retornar ao usuário a página Checkout Summary contendo as informações do pedido do usuário. 9. Clique em Continue ; 9. Será listado ao usuário os seus dados pessoais de cadastro. 10. Clique em Continue ; 10. Será apresentado ao usuário um resumo da transação, contendo o endereço de cobrança e de entrega. 11. Clique em Confirm ; 11. Deverá retornar ao usuário a mensagem Thank you, your order has been submitted Clique em Sign Out ; 12. Fim do caso de teste. Fonte: Os autores (2011)

60 60 Tabela 5: Caso de teste da funcionalidade de pesquisa de um animal Título: Pesquisa com sucesso de um animal Objetivo: Efetuar a pesquisa de um animal qualquer no site informando sua categoria. Pré-Condição: Ter acesso ao aplicativo JPetStore Pós-Condição: Ter feito a pesquisa de um animal pela sua categoria com sucesso PASSOS RESULTADOS ESPERADOS 1. Entre no site da aplicação; 1. Deverá abrir a página home da aplicação. 2. Informe no campo de texto ao lado do botão 2. Deverá retornar ao usuário todos os animais Search uma das categorias de animais presentes na categoria informada. disponíveis e clique no botão Search ; 3. Clique em um dos animais retornados para 3. Deverá retornar as informações do animal. ver o seu detalhe; 4. Volte a página inicial da aplicação clicando no logo presente no banner; Fonte: Os autores (2011) 4. Deverá retornar a página inicial da aplicação. Fim do caso de teste. Estes casos de teste propostos devem refletir os passos que o usuário virtual realizará na execução do teste de esforço. Para isto, as inserções HTTP para cada passo proposto no caso teste da navegação do usuário são desenvolvidas no JMeter, obtendo como resultado final um plano de teste que pode ser visto na figura Figura 24: Caso de teste para efetuar uma compra com sucesso desenvolvido para o JMeter. Fonte: Os Autores (2011)

61 61 Para execução deste teste de desempenho no cenário hipotético proposto, tomou-se como premissa que a aplicação suporta em pico, 100 usuários simultâneos, isto significa que a aplicação está em 100% de utilização do site ao atingir esta quantidade de usuários simultâneos. De base nesta informação, foi criada uma pirâmide de usuários, que pode ser vista na figura 25, que demonstra a quantidade de usuários para os ciclos de testes que foram executados. Acima de 100 usuários, o conceito do teste de esforço já está agindo sobre a aplicação, conforme definição deste conceito de teste apresentado no capítulo 2 (seção 2.4.2), chegando a base da pirâmide com até 400% a mais da carga esperada pelo site. Figura 25: Pirâmide de usuários simultâneos utilizando o JPetStore. Fonte: Os Autores (2011) Para cada nível da pirâmide executado, devem ser definidos os parâmetros de tempo de duração da bateria e quantidade de usuários que devem estar concorrendo simultaneamente por ciclo. Na figura 26 estes atributos estão definidos para o teste hipotético em questão, onde cada ciclo tem o tempo de 5 minutos de execução e todos os usuários concorrem simultâneamente desde o instante segundo 0.

62 62 Figura 26: Atributos definidos para o caso de teste no JMeter. Fonte: Os Autores (2011) Como serão dois cenários envolvidos nesta execução, cada cenário tem um peso específico para a quantidade de usuários utilizando a aplicação, sendo necessário definir a carga de usuário conforme definido no capítulo 2 (seção 2.4.2). Na figura 27 pode ser visto o percentual da execução no portal JPetStore para cada um dos níveis da pirâmide de usuários. Figura 27: Distribuição de usuários simultâneos utilizando o JPetStore. Fonte: Os Autores (2011) Tendo definido os casos de testes, a criação do script que simulará um usuário real, a quantidade de usuário que executará este script e o percentual de carga por funcionalidade, pode-se considerar finalizada a parte da criação de um teste de desempenho. A aplicação foi instalada em um único servidor, cuja configuração de hardware do mesmo pode ser vista no Apêndice B deste documento. A previsão de duração do tempo da execução do ciclo de teste completo era de 45 minutos, já que o objetivo proposto era de executar os 9 níveis presentes na

63 63 pirâmide de usuários, conforme na figura 25. Porém no nível 7 da pirâmide, cujo total de usuário simultâneos era de 225 o que representa 125% a mais de carga esperada pela aplicação a execução foi encerrada, pois o servidor apresentou um alto consumo de CPU. Como o objetivo deste trabalho não é mensurar o desempenho do hardware e sim demonstrar a utilização do aplicativo JPlotMeter desenvolvido para o Android, foi decidido que com a execução realizada já se possuia informações suficientes. No Apêndice C presente neste documento, é possível visualizar um trecho do log obtido no JMeter com informações do ínicio da execução do teste de esforço e o instante final da mesma.

64 64 6 JPLOTMETER: UM RELATÓRIO GERENCIAL PARA O ANDROID Este capítulo apresenta como foi desenvolvida a arquitetura da solução proposta, quais foram as métricas coletadas do teste executado no JMeter e a integração do aplicativo desenvolvido para o sistema operacional Android consumindo estas informações para construção do gráfico gerencial. 6.1 ARQUITETURA DA SOLUÇÃO Os resultados das execuções dos testes feitos no JMeter armazenados em uma tabela temporária criada para o JPlotMeter são processados e expostos por um webservice para que o aplicativo no Android pudesse receber estas informações e gerar o gráfico. Um desenho técnico da aplicação pode ser visto na figura 28. Figura 28: Desenho técnico da solução JPlotMeter. Fonte: Os Autores (2011) No servidor com o JPlotmeter foram desenvolvidas quatro classes, dentre elas a AppService, HandleReturn, ConnectionMySql e a JaxWsImpl, como poder ser visto no diagrama de classes apresentado na figura 29. A classe AppService é responsável em fornecer a informação já tratada para o aplicativo no Android, onde o método consulta através de uma conexão JDBC uma tabela simples criada no MySQL, e trata as informações coletadas retornando insumo suficiente para atender a necessidade de gerar o gráfico referente ao tempo médio de resposta por ciclo de teste executado. A estrutura e script de criação do banco de dados podem ser vistas no Apêndice D.

65 65 Figura 29: Diagrama de classe servidor de aplicações. Fonte: Os Autores (2011) Para um melhor entendimento em relação à interação do usuário com o aplicativo, o diagrama de casos de uso foi elaborado, como pode ser visto na figura 30. Na tabela 6, apresenta-se a interação do usuário com o aplicativo que é bem simples. O usuário precisa ter o aplicativo JPlotMeter instalado no seu dispositivo móvel com Android. Em seguida, abrir o aplicativo que o mesmo se encarregará de mostrar o gráfico gerencial de tempo médio de resposta na tela do dispositivo. Figura 30: Diagrama de caso de uso. Fonte: Os Autores (2011)

66 66 Tabela 6: Descrição do caso de Uso Consultar desempenho do site DETALHES Nome do Caso de Uso UC1 Consulta desempenho do site Versão 1.0 Autor Os Autores Criado em: 06/10/2011 Notas: O aplicativo deverá disponibilizar, um gráfico gerencial com a análise do tempo de resposta do site ecommerce JPetStore. O aplicativo deverá disponibilizar um botão para poder atualizar os dados mostrados no gráfico. Fluxos: Fluxo Básico E01 Erro de conexão Fonte: Os autores (2011) Notas 1. O usuário abre o aplicativo JPlotMeter do seu aparelho móvel. 2. O aplicativo apresenta o gráfico gerencial. 3. Fim do Caso de uso. 1. O usuário abre o aplicativo JPlotMeter do seu aparelho móvel. 2. O aplicativo não consegue conexão com o webservice no lado do servidor, apresentando a seguinte mensagem: Verifique a conexão com o servidor. 3. Fim do Caso de uso. Tipo Fluxo Básico Fluxo de Excessão 6.2 MÉTRICAS COLETADAS DO JMETER PARA GERAÇÃO DO GRÁFICO Conforme fundamentado no capítulo 3, a cada usuário simulado pelo JMeter é gerado uma série de informações sobre a sua execução. Para o protótipo de relatório gerencial JPlotMeter, apenas três destas métricas foram necessárias: 1. Time Taken: Representa o tempo de espera desde uma solicitação do usuário ao servidor até o retorno; 2. Time Stamp: O carimbo contendo data e horário da solicitação do usuário; 3. CSIUri: É o rótulo da URL solicitada pelo usuário. Estas métricas foram armazenadas em uma tabela histórica e transitadas pela aplicação do lado do servidor para aplicação presente na plataforma Android, gerando assim a criação do gráfico representativo do tempo médio de resposta de cada uma das páginas. Para que fosse possível ter informações suficientes para a demonstração do funcionamento do relatório, foram programadas para que a cada 5 minutos de uma bateria fosse executado a pirâmide de usuários hipotética apresentada no capítulo 5

67 67 (seção 5.3), totalizando um período de 45 minutos de coletas armazenadas no banco de dados. 6.3 INTEGRAÇÃO COM O SISTEMA OPERACIONAL ANDROID Para que fosse possível representar as informações coletadas a cada ciclo de execução no JMeter de maneira visual, foi desenvolvido o aplicativo JPlotMeter para o Android. Este aplicativo consiste em duas classes, que podem ser vistas no diagrama de classes na figura 31. A classe LerArquivo é a responsável por consumir as informações do aplicativo no lado do servidor e a classe JPlotMeter é a responsável em tratar as informações e gerar o gráfico em tempo real. Para que o gráfico fosse montado de maneira padronizada, optou-se por utilizar uma API disponível para criação de gráficos, chamada jjoe64 (JJOE64, 2011). Esta API possui métodos já implementados, que recebem valores númericos e textuais para construção do gráfico, seja ele do tipo linha ou do tipo barra. Para uma melhor representação do tempo de resposta das páginas, foi utilizado o gráfico de tipo linha. Figura 31: Diagrama de classes do aplicativo JPlotMeter. Fonte: Os Autores (2011) Ao consumir as informações do lado do servidor, o aplicativo trata estas como um arquivo CSV, que nada mais é do que um texto cujo os valores são separados por algum delimitador, no caso o delimitador é a vírgula. A partir destas informações recebidas, o Time Taken é o responsável em gerar o eixo vertical que é a média de tempo de resposta em segundos e o eixo horizontal é gerado através do Time Stamp, que é a linha temporal da execução, como pode ser visto no gráfico 1.

68 68 Gráfico 1: Demonstração dos eixos do JPlotMeter. Fonte: Os Autores (2011) Cada uma das estátiscas de acesso realizada pela execução no JMeter é armazenada no banco de dados da aplicação pelo lado do servidor com seu respectivo identificador, representado na tabela pela coluna CSIUri. Este campo no gráfico gerado é a legenda, como pode ser visto no gráfico 2, sendo possível assim verificar a variação do tempo de resposta ao longo do tempo da execução, sendo que o somatório do tempo médio de resposta das páginas na última bateria executada se aproximou a 150 segundos de duração. Gráfico 2: Demonstração das legendas no JPlotMeter. Fonte: Os Autores (2011)

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64 direcionados por comportamento 64 5 Estudo de caso Neste capítulo serão apresentadas as aplicações web utilizadas na aplicação da abordagem proposta, bem como a tecnologia em que foram desenvolvidas, o

Leia mais

Linguagem de Programação JAVA. Professora Michelle Nery Nomeclaturas

Linguagem de Programação JAVA. Professora Michelle Nery Nomeclaturas Linguagem de Programação JAVA Professora Michelle Nery Nomeclaturas Conteúdo Programático Nomeclaturas JDK JRE JEE JSE JME JVM Toolkits Swing AWT/SWT JDBC EJB JNI JSP Conteúdo Programático Nomenclatures

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 5 Servidores de Aplicação

Leia mais

CA Nimsoft Monitor para servidores

CA Nimsoft Monitor para servidores DOCUMENTAÇÃO TÉCNICA Setembro de 2012 CA Nimsoft Monitor para servidores agility made possible CA Nimsoft para monitoramento de servidores sumário CA Nimsoft Monitor para servidores 3 visão geral da solução

Leia mais

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 6 - ALGORÍTIMOS PARALELOS MPI - Parallel Virtual Machine e PVM - Parallel Virtual Machine 1. INTRODUÇÃO Inicialmente é necessário conceber alguns conceitos para entendimento dos algoritmos paralelos:

Leia mais

NEVA: Programa para aumento de performance de sites web usando o algoritmo de esteganografia

NEVA: Programa para aumento de performance de sites web usando o algoritmo de esteganografia NEVA: Programa para aumento de performance de sites web usando o algoritmo de esteganografia MÁRCIO PANTOJA LOBATO 1, PEDRO VICTOR PONTES PINHEIRO 1, ROBERTO YURI DA SILVA FRANCO 1, ALESSANDRA NATASHA

Leia mais

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software O que é software? Software e Engenharia de Software Programas de computador Entidade abstrata. Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas

Leia mais

Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga. Um artigo técnico da Oracle Junho de 2009

Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga. Um artigo técnico da Oracle Junho de 2009 Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga Um artigo técnico da Oracle Junho de 2009 Identificação rápida de gargalos Uma forma mais eficiente de realizar testes

Leia mais

Rede de Laboratórios de Produtividade de Software

Rede de Laboratórios de Produtividade de Software Rede de Laboratórios de Produtividade de Software Testes em aplicações WEB Uma Visão Geral Programa de Capacitação em Testes de Software Desktop system WEB system Ambiente de aplicativo da Web Rede de

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com)

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com) ARQUITETURA DE SISTEMAS Cleviton Monteiro (cleviton@gmail.com) Roteiro Definição Documento de arquitetura Modelos de representação da arquitetura Estilos arquiteturais Arquitetura de sistemas web Arquitetura

Leia mais

Aula 1 - Introdução e configuração de ambiente de desenvolvimento

Aula 1 - Introdução e configuração de ambiente de desenvolvimento Aula 1 - Introdução e configuração de ambiente de desenvolvimento Olá, seja bem-vindo à primeira aula do curso para desenvolvedor de Android, neste curso você irá aprender a criar aplicativos para dispositivos

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1 DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1 SUMÁRIO DEFINIÇÃO DE REQUISITOS 4 1. INTRODUÇÃO 4 1.1 FINALIDADE 4 1.2 ESCOPO 4 1.3 DEFINIÇÕES, ACRÔNIMOS

Leia mais

Tecnologia Java. Daniel Destro do Carmo Softech Network Informática daniel@danieldestro.com.br

Tecnologia Java. Daniel Destro do Carmo Softech Network Informática daniel@danieldestro.com.br Tecnologia Java Daniel Destro do Carmo Softech Network Informática daniel@danieldestro.com.br Origem da Tecnologia Java Projeto inicial: Oak (liderado por James Gosling) Lançada em 1995 (Java) Tecnologia

Leia mais

Uma Abordagem usando PU

Uma Abordagem usando PU Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson,

Leia mais

Programação de Computadores - I. Profª Beatriz Profº Israel

Programação de Computadores - I. Profª Beatriz Profº Israel Programação de Computadores - I Profª Beatriz Profº Israel A linguagem JAVA A linguagem Java O inicio: A Sun Microsystems, em 1991, deu inicio ao Green Project chefiado por James Gosling. Projeto que apostava

Leia mais

Uma visão mais detalhada do software HP LoadRunner

Uma visão mais detalhada do software HP LoadRunner Boletim técnico Uma visão mais detalhada do software HP LoadRunner Índice Um novo enfoque no teste de desempenho: a solução HP LoadRunner 3 A solução HP LoadRunner e a terminologia dos testes de desempenho

Leia mais

Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa

Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa Agenda Introdução Aplicações interativas de TV Digital Desafios de layout e usabilidade Laboratório de usabilidade Desafios

Leia mais

PROFESSOR: CRISTIANO MARIOTTI

PROFESSOR: CRISTIANO MARIOTTI PROFESSOR: CRISTIANO MARIOTTI Conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software; Considerado um dos principais mecanismos para se obter software de qualidade

Leia mais

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com REVISÃO ENGENHARIA DO SOFTWARE Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Software Sequencia de Instruções a serem seguidas ou executadas Dados e rotinas desenvolvidos por computadores Programas

Leia mais

7 Utilização do Mobile Social Gateway

7 Utilização do Mobile Social Gateway 7 Utilização do Mobile Social Gateway Existem três atores envolvidos na arquitetura do Mobile Social Gateway: desenvolvedor do framework MoSoGw: é o responsável pelo desenvolvimento de novas features,

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

Considerando-se a especificação de requisitos de um software, é INCORRETO afirmar que esse documento

Considerando-se a especificação de requisitos de um software, é INCORRETO afirmar que esse documento QUESTÕES DE TI QUESTÃO 16 Considerando-se o número de pontos de função para a estimativa do tamanho de um software, é INCORRETO afirmar que, na contagem de pontos, leva-se em consideração A) as compilações

Leia mais

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS)

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Definição Geral: Disciplina de Compiladores Prof. Jorge Bidarra (UNIOESTE) A especificação de requisitos tem como objetivo

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 8 http://www.ic.uff.br/~bianca/engsoft2/ Aula 8-17/05/2006 1 Ementa Processos de desenvolvimento de software Estratégias e técnicas de teste de software (Caps. 13 e 14 do

Leia mais

FERRAMENTAS PARA DESENVOLVIMENTO EM C#

FERRAMENTAS PARA DESENVOLVIMENTO EM C# FERRAMENTAS PARA DESENVOLVIMENTO EM C# Camila Sanches Navarro 1,2, Wyllian Fressatti 2 ¹Universidade paranaense (Unipar) Paranavaí PR Brasil sanchesnavarro@gmail.com wyllian@unipar.br Resumo. Este artigo

Leia mais

INTERLIMS SISTEMA DE GERENCIAMENTO DE INFORMAÇÕES PARA LABORATÓRIOS DE ANÁLISES DE ÁGUA

INTERLIMS SISTEMA DE GERENCIAMENTO DE INFORMAÇÕES PARA LABORATÓRIOS DE ANÁLISES DE ÁGUA INTERLIMS SISTEMA DE GERENCIAMENTO DE INFORMAÇÕES PARA LABORATÓRIOS DE ANÁLISES DE ÁGUA INTERLIMS SISTEMA DE GERENCIAMENTO DE INFORMAÇÕES PARA LABORATÓRIOS DE ANÁLISES DE ÁGUA O InterLIMS se apresenta

Leia mais

Revisão para a prova B2. Conteúdo das Aulas: 10, 11 e 14

Revisão para a prova B2. Conteúdo das Aulas: 10, 11 e 14 Revisão para a prova B2 Conteúdo das Aulas: 10, 11 e 14 Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc.br Disciplina: Serviços de Redes Microsoft Professor:

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo

Leia mais

2 Medição e Acompanhamento

2 Medição e Acompanhamento 2 Medição e Acompanhamento Para verificar a eficácia da aplicação da técnica de desenvolvimento dirigido por testes, foram usadas algumas métricas para determinar se houve melhoria ou degradação no processo

Leia mais

Programação para Web Artefato 01. AT5 Conceitos da Internet

Programação para Web Artefato 01. AT5 Conceitos da Internet Programação para Web Artefato 01 AT5 Conceitos da Internet Histórico de revisões Data Versão Descrição Autor 24/10/2014 1.0 Criação da primeira versão HEngholmJr Instrutor Hélio Engholm Jr Livros publicados

Leia mais

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1 DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1 SUMÁRIO DEFINIÇÃO DE REQUISITOS 4 1. INTRODUÇÃO 4 1.1 FINALIDADE 4 1.2 ESCOPO 4 1.3 DEFINIÇÕES, ACRÔNIMOS

Leia mais

Características do Software

Características do Software Questionamentos Por que tanta demora para entregar? Por que os prazos se atrasam? Por que os custos são altos? Por que não achar todos os erros antes de entregar? Por que dificuldade em medir o progresso

Leia mais

Boas Práticas de Desenvolvimento Seguro

Boas Práticas de Desenvolvimento Seguro Boas Práticas de Desenvolvimento Seguro Julho / 2.012 Histórico de Revisões Data Versão Descrição Autor 29/07/2012 1.0 Versão inicial Ricardo Kiyoshi Página 2 de 11 Conteúdo 1. SEGURANÇA DA INFORMAÇÃO

Leia mais

LEI DE ACESSO A INFORMAÇÃO DIREITO DO CIDADÃO

LEI DE ACESSO A INFORMAÇÃO DIREITO DO CIDADÃO DESCRIÇÃO DO SIGAI O SIGAI (Sistema Integrado de Gestão do Acesso à Informação) é uma solução de software que foi desenvolvida para automatizar os processos administrativos e operacionais visando a atender

Leia mais

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Audrey B. Vasconcelos, Iuri Santos Souza, Ivonei F. da Silva, Keldjan Alves Centro de Informática Universidade

Leia mais

10. Defina Sistemas Distribuídos: Um conjunto de computadores independentes que se apresenta a seus usuários como um sistema único e coerente

10. Defina Sistemas Distribuídos: Um conjunto de computadores independentes que se apresenta a seus usuários como um sistema único e coerente 1. Quais os componentes de um sistema cliente-servidor? Clientes e servidores 2. Na visão do hardware, defina o que é cliente e o que é servidor: Clientes. Qualquer computador conectado ao sistema via

Leia mais

a) Teste das funções do sistema com outros sistemas b) Teste de componentes que em conjunto compõem a função do sistema

a) Teste das funções do sistema com outros sistemas b) Teste de componentes que em conjunto compõem a função do sistema Simulado CTFL- BSTQB Tempo de duração: 60 minutos 1. Considerando as seguintes afirmações: I. 100% de cobertura de sentença (comando) garante 100% de cobertura de desvio II. 100% de cobertura de desvio

Leia mais

Programação para Dispositivos Móveis

Programação para Dispositivos Móveis Programação para Dispositivos Móveis Fatec Ipiranga Análise e Desenvolvimento de Sistemas Aula 02 História do desenvolvimento de software para dispositivos móveis Dalton Martins dmartins@gmail.com São

Leia mais

Questionário. A ferramenta auxilia na alocação de Não (0) x x x. Satisfatório (5) complexidade de um caso de uso? de uso (72) Sim (10)

Questionário. A ferramenta auxilia na alocação de Não (0) x x x. Satisfatório (5) complexidade de um caso de uso? de uso (72) Sim (10) Questionário Nível Avaliado Gerador de plano de teste Gerador de dados Função/característica do produto Gestão dos dados do plano de teste (51) Perguntas Pontuação Selenium BadBoy Canoo A ferramenta auilia

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ ModeloPlanoProjeto_2007_04_24 SIGECO07_PlanoProjeto_2007_09_23 Página

Leia mais

World Wide Web e Aplicações

World Wide Web e Aplicações World Wide Web e Aplicações Módulo H O que é a WWW Permite a criação, manipulação e recuperação de informações Padrão de fato para navegação, publicação de informações e execução de transações na Internet

Leia mais

Resumo: Perguntas a fazer ao elaborar um projeto arquitetural

Resumo: Perguntas a fazer ao elaborar um projeto arquitetural Resumo: Perguntas a fazer ao elaborar um projeto arquitetural Sobre entidades externas ao sistema Quais sistemas externos devem ser acessados? Como serão acessados? Há integração com o legado a ser feita?

Leia mais

Engenharia de Software-2003

Engenharia de Software-2003 Engenharia de Software-2003 Mestrado em Ciência da Computação Departamento de Informática - UEM Profa. Dra. Elisa H. M. Huzita eng. de software-2003 Elisa Huzita Produto de Software Conceitos Software

Leia mais

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais

2 Auto-sintonia de Bancos de Dados e Agentes de Software

2 Auto-sintonia de Bancos de Dados e Agentes de Software 2 Auto-sintonia de Bancos de Dados e Agentes de Software A uso da abordagem de agentes de software 1 pode trazer benefícios a áreas de aplicação em que é necessário construir sistemas autônomos, ou seja,

Leia mais

Descritivo Técnico. SLAView - Descritivo Técnico Build 5.0 release 4 16/02/2011 Página 1

Descritivo Técnico. SLAView - Descritivo Técnico Build 5.0 release 4 16/02/2011 Página 1 Descritivo Técnico 16/02/2011 Página 1 1. OBJETIVO O SLAview é um sistema de análise de desempenho de redes IP por meio da monitoração de parâmetros de SLA (Service Level Agreement, ou Acordo de Nível

Leia mais

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT Jaqueline Rissá Franco email: jaquerifr@gmail.com Karla Marturelli Mattos Luciano Mathias Doll João Almeida Resumo: Este artigo mostra novas abordagens na

Leia mais

Anexo I - DAS (Documento de Arquitetura de Software) Concurso de Desenvolvimento de Jogos SEBRAE

Anexo I - DAS (Documento de Arquitetura de Software) Concurso de Desenvolvimento de Jogos SEBRAE Anexo I - DAS (Documento de Arquitetura de Software) Concurso de Desenvolvimento de Jogos SEBRAE 1 Sumário Sumário... 2 1 INTRODUÇÃO... 3 1.1 Propósito... 3 1.2 Escopo... 3 1.3 Referências... 3 2 DIRETRIZES...

Leia mais

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento

Leia mais

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS Élysson Mendes Rezende Bacharelando em Sistemas de Informação Bolsista de Iniciação Científica

Leia mais

Java de missão crítica. Um artigo técnico da Oracle

Java de missão crítica. Um artigo técnico da Oracle Java de missão crítica Um artigo técnico da Oracle Java de missão crítica A família de produtos Oracle JRockit é um portfólio abrangente de soluções de tempo de execução de Java que aproveita a JVM básica

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

ADMINISTRAÇÃO DOS RECURSOS DE HARDWARE E SOFTWARE

ADMINISTRAÇÃO DOS RECURSOS DE HARDWARE E SOFTWARE Capítulo 6 ADMINISTRAÇÃO DOS RECURSOS DE HARDWARE E SOFTWARE 6.1 2003 by Prentice Hall OBJETIVOS Qual é a capacidade de processamento e armazenagem que sua organização precisa para administrar suas informações

Leia mais

IBM WebSphere Business Monitor

IBM WebSphere Business Monitor Obtenha visibilidade em tempo real do desempenho dos processos de negócios IBM WebSphere Business Monitor Fornece aos usuários de negócios uma visão abrangente e em tempo real do desempenho dos processos

Leia mais

2 Trabalhos Relacionados

2 Trabalhos Relacionados 2 Trabalhos Relacionados Nesse capítulo, apresentamos os trabalhos relacionados ao GridFS, entrando em mais detalhes sobre os sistemas citados durante a introdução e realizando algumas considerações sobre

Leia mais

Engenharia de Software

Engenharia de Software CENTRO UNIVERSITÁRIO NOVE DE JULHO Profº. Edson T. França edson.franca@uninove.br Software Sistemas Conjunto de elementos, entre os quais haja alguma relação Disposição das partes ou dos elementos de um

Leia mais

Testes Orientação Visão Conceitual em Testes Versão 0.3

Testes Orientação Visão Conceitual em Testes Versão 0.3 Testes Versão 0.3 ori_visao_conceitual_testes.odt 1 de 10 Histórico de Revisões Data Versão Descrição Autor 23/04/2010 0.1 Versão inicial Fernanda Monteiro 07/10/10 0.2 Verificação ortográfica Ana Eckel

Leia mais

ADMINISTRAÇÃO DOS RECURSOS DE HARDWARE E SOFTWARE

ADMINISTRAÇÃO DOS RECURSOS DE HARDWARE E SOFTWARE ADMINISTRAÇÃO DOS RECURSOS DE HARDWARE E SOFTWARE 1 OBJETIVOS 1. Qual é a capacidade de processamento e armazenagem que sua organização precisa para administrar suas informações e transações empresariais?

Leia mais

Automatizando o Data Center

Automatizando o Data Center Este artigo examina uma arquitetura alternativa que suporte a automação do data center e o provisionamento dinâmico sem a virtualização do sistema operacional. por Lori MacVittie Gerente Técnico de Marketing,

Leia mais

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira ENTERPRISE JAVABEANS 3 Msc. Daniele Carvalho Oliveira Apostila Servlets e JSP www.argonavis.com.br/cursos/java/j550/index.html INTRODUÇÃO Introdução Enterprise JavaBeans é um padrão de modelo de componentes

Leia mais

UNIVERSIDADE ESTADUAL DE PONTA GROSSA

UNIVERSIDADE ESTADUAL DE PONTA GROSSA UNIVERSIDADE ESTADUAL DE PONTA GROSSA SECRETARIA MUNICIPAL DE GESTÃO DE RECURSOS HUMANOS CONCURSO PÚBLICO PARA ANALISTA DE SUPORTE 08 DE NOVEMBRO DE 2009... (NOME COMPLETO EM LETRA DE FORMA) INSTRUÇÕES

Leia mais

A partir do XMon é possível:

A partir do XMon é possível: Monitoramento XMon É uma ferramenta para gerenciar o seu ambiente de TI de forma centralizada e constante, obtendo informações precisas da performance de todos os seus ativos e previna possíveis problemas

Leia mais

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS Lilian R. M. Paiva, Luciene C. Oliveira, Mariana D. Justino, Mateus S. Silva, Mylene L. Rodrigues Engenharia de Computação - Universidade de Uberaba (UNIUBE)

Leia mais

Aula 2: RIA - Aplicações Ricas para Internet Fonte: Plano de Aula Oficial da Disciplina

Aula 2: RIA - Aplicações Ricas para Internet Fonte: Plano de Aula Oficial da Disciplina Programação para Internet Rica 1 Aula 2: RIA - Aplicações Ricas para Internet Fonte: Plano de Aula Oficial da Disciplina Objetivo: Identificar as principais características de uma Aplicação Internet Rica.

Leia mais

Projeto OBAA. Relatório Técnico RT-OBAA-07 Grupo Agentes e Ontologias. Proposta de Federação de Repositórios de Objetos Educacionais.

Projeto OBAA. Relatório Técnico RT-OBAA-07 Grupo Agentes e Ontologias. Proposta de Federação de Repositórios de Objetos Educacionais. Edital MCT/FINEP/MC/FUNTTEL Plataformas para Conteúdos Digitais 01/2007 Projeto OBAA Relatório Técnico RT-OBAA-07 Grupo Agentes e Ontologias Proposta de Federação de Repositórios de Objetos Educacionais

Leia mais

SISTEMA DE BANCO DE DADOS. Banco e Modelagem de dados

SISTEMA DE BANCO DE DADOS. Banco e Modelagem de dados SISTEMA DE BANCO DE DADOS Banco e Modelagem de dados Sumário Conceitos/Autores chave... 3 1. Introdução... 4 2. Arquiteturas de um Sistema Gerenciador... 5 3. Componentes de um Sistema... 8 4. Vantagens

Leia mais

AVALIAÇÃO DE DESEMPENHO EM REDES DE COMPUTADORES UTILIZANDO TEORIA DE FILAS 1

AVALIAÇÃO DE DESEMPENHO EM REDES DE COMPUTADORES UTILIZANDO TEORIA DE FILAS 1 AVALIAÇÃO DE DESEMPENHO EM REDES DE COMPUTADORES UTILIZANDO TEORIA DE FILAS 1 Anderson Luis Marchi 2 ; Tiago Boechel 3 ; Juliano Tonizetti Brignoli 4 INTRODUÇÃO A comunicação é uma das maiores necessidades

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

História e Evolução da Web. Aécio Costa

História e Evolução da Web. Aécio Costa Aécio Costa A História da Web O que estamos estudando? Período em anos que a tecnologia demorou para atingir 50 milhões de usuários 3 As dez tecnologias mais promissoras 4 A evolução da Web Web 1.0- Passado

Leia mais

Estudo comparativo entre tecnologias Java: Applet e JWS.

Estudo comparativo entre tecnologias Java: Applet e JWS. Estudo comparativo entre tecnologias Java: Applet e JWS. Clara Aben-Athar B. Fernandes¹, Carlos Alberto P. Araújo¹ 1 Centro Universitário Luterano de Santarém Comunidade Evangélica Luterana (CEULS/ULBRA)

Leia mais

Tecnologia da Informação. Prof. Esp. Lucas Cruz

Tecnologia da Informação. Prof. Esp. Lucas Cruz Tecnologia da Informação Prof. Esp. Lucas Cruz Componentes da Infraestrutura de TI Software A utilização comercial da informática nas empresas iniciou-se por volta dos anos 1960. O software era um item

Leia mais

Fundamentos de Java. Prof. Marcelo Cohen. 1. Histórico

Fundamentos de Java. Prof. Marcelo Cohen. 1. Histórico Fundamentos de Java Prof. Marcelo Cohen 1. Histórico 1990 linguagem Oak; desenvolvimento de software embutido para eletrodomésticos S.O. para o controle de uma rede de eletrodomésticos o surgimento da

Leia mais

AutoTest Um Framework Reutilizável para a Automação de Teste Funcional de Software

AutoTest Um Framework Reutilizável para a Automação de Teste Funcional de Software AutoTest Um Framework Reutilizável para a Automação de Teste Funcional de Software Marcelo Fantinato CPqD Telecom & IT Solutions UNICAMP Instituto de Computação Campinas SP Agenda Motivação Objetivo Automação

Leia mais

Testes de Software. Anne Caroline O. Rocha TesterCertified BSTQB NTI UFPB. Anne Caroline O. Rocha Tester Certified BSTQB NTI UFPB

Testes de Software. Anne Caroline O. Rocha TesterCertified BSTQB NTI UFPB. Anne Caroline O. Rocha Tester Certified BSTQB NTI UFPB Testes de Software 1 AULA 05 FERRAMENTAS TESTE DE CARGA E GERÊNCIA DE TESTE Anne Caroline O. Rocha Tester Certified BSTQB NTI UFPB Conteúdo Programático Aula 05 Ferramentas para gerência dos testes Ferramentas

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

Leia mais

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos

Leia mais

Engenharia de Software

Engenharia de Software Prof. M.Sc. Ronaldo C. de Oliveira ronaldooliveira@facom.ufu.br FACOM - 2011 2 Semana - Paradigmas e Processo de Software : Abrangência possui 3 elementos fundamentais: métodos: como fazer ferramentas:

Leia mais

MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID

MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID Alessandro Teixeira de Andrade¹; Geazy Menezes² UFGD/FACET Caixa Postal 533,

Leia mais

Resumo de TCC Desenvolvimento de um sistema ERP com foco nas tecnologias de software livre / código aberto

Resumo de TCC Desenvolvimento de um sistema ERP com foco nas tecnologias de software livre / código aberto UFSC - Universidade Federal de Santa Catarina CTC Centro Tecnológico INE Departamento de Informática e Estatística INE5631 Projetos I Prof. Renato Cislaghi Resumo de TCC Desenvolvimento de um sistema ERP

Leia mais

Modelo Cascata. Alunos: Bruno Nocera Zanette Pedro Taques

Modelo Cascata. Alunos: Bruno Nocera Zanette Pedro Taques Modelo Cascata Alunos: Bruno Nocera Zanette Pedro Taques Principais Características Gerenciamento Simples das etapas Também conhecido como "Ciclo de Vida Clássico", sugere uma abordagem sistemática e sequencial

Leia mais

Guia Técnicas de Teste Metodologia Celepar

Guia Técnicas de Teste Metodologia Celepar Guia Técnicas de Teste Metodologia Celepar Agosto de 2009 Sumário de Informações do Documento Documento: guiatecnicasteste.odt Número de páginas: 22 Versão Data Mudanças Autor 1.0 17/09/07 Criação. Ariel

Leia mais

Programação Orientada a Objetos

Programação Orientada a Objetos Programação Orientada a Objetos Universidade Católica de Pernambuco Ciência da Computação Prof. Márcio Bueno poonoite@marciobueno.com Fonte: Material da Profª Karina Oliveira Introdução ao Paradigma OO

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

Controlar Aplicações e Serviços com Monitoramento de Rede

Controlar Aplicações e Serviços com Monitoramento de Rede Controlar Aplicações e Serviços com Monitoramento de Rede White Paper Autor: Daniel Zobel, Chefe de Desenvolvimento de Software Paessler AG Publicado em: março/2014 PÁGINA 1 DE 8 Índice Introdução: Evite

Leia mais

Introdução Dalvik Linux 2.6. Android. Diogo de Campos, João Paulo Pizani Flor, Maurício Oliveira Haensch, Pedro Covolan Bachiega

Introdução Dalvik Linux 2.6. Android. Diogo de Campos, João Paulo Pizani Flor, Maurício Oliveira Haensch, Pedro Covolan Bachiega Android Diogo de Campos, João Paulo Pizani Flor, Maurício Oliveira Haensch, Pedro Covolan Bachiega Universidade Federal de Santa Catarina November 18, 2008 Agenda 1 Introdução 2 Dalvik 3 Linux 2.6 Introdução

Leia mais

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial 1 of 14 27/01/2014 17:33 Sistema de Paginação de Esportes Universitários Documento de Arquitetura de Software Versão 1.0 Histórico da Revisão Data 30 de novembro de 1999 Versão Descrição Autor 1.0 Versão

Leia mais

Softwares de Sistemas e de Aplicação

Softwares de Sistemas e de Aplicação Fundamentos dos Sistemas de Informação Softwares de Sistemas e de Aplicação Profª. Esp. Milena Resende - milenaresende@fimes.edu.br Visão Geral de Software O que é um software? Qual a função do software?

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Evolução Edson Moreno edson.moreno@pucrs.br http://www.inf.pucrs.br/~emoreno Sumário Introdução Componentes de um sistema computacional Conceituação Características desejáveis Organização

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

DESAFIO ETAPA 1 Passo 1

DESAFIO ETAPA 1 Passo 1 DESAFIO Um dos maiores avanços percebidos pela área de qualidade de software foi comprovar que a qualidade de um produto final (software) é uma consequência do processo pelo qual esse software foi desenvolvido.

Leia mais

Documento de Requisitos de Rede (DRP)

Documento de Requisitos de Rede (DRP) Documento de Requisitos de Rede (DRP) Versão 1.2 SysTrack - Grupo 1 1 Histórico de revisões do modelo Versão Data Autor Descrição 1.0 30/04/2011 João Ricardo Versão inicial 1.1 1/05/2011 André Ricardo

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Especificação Suplementar

Especificação Suplementar Especificação Suplementar Versão Histórico de Revisões Data Versão Descrição Autor 29/10/2014 2.0 2.1 funcionalidade e segurança de M. Vinícius acesso 30/10/2014

Leia mais