OTIMIZAC˘AO DE DESEMPENHO DE SISTEMA~ GIS DE MONITORAMENTO DE...

UNIVERSIDADE DO ESTADO DO AMAZONAS - UEA

ESCOLA SUPERIOR DE TECNOLOGIA

ENGENHARIA DE COMPUTACAO

ANDRE LUIZ DO CANTO PORTELA

OTIMIZACAO DE DESEMPENHO DE SISTEMA

GIS DE MONITORAMENTO DE SENSORES

MICROPROCESSADOS COM A GOOGLE MAPS

API

Manaus

2011


OTIMIZACAO DE DESEMPENHO DE SISTEMA GIS DE

MONITORAMENTO DE SENSORES MICROPROCESSADOS COM A

GOOGLE MAPS API

Trabalho de Conclusao de Curso apresentado

a banca avaliadora do Curso de Engenharia

de Computacao, da Escola Superior de

Tecnologia, da Universidade do Estado do

Amazonas, como pre-requisito para obtencao

do tıtulo de Engenheiro de Computacao.

Orientador: Prof. M. Sc. Andre Luiz Printes

Manaus 2011

ii

Universidade do Estado do Amazonas - UEA

Escola Superior de Tecnologia - EST

Reitor:

Jose Aldemir de Oliveira

Vice-Reitor:

Marly Guimaraes Fernandes da Costa

Diretor da Escola Superior de Tecnologia:

Mario Augusto Bessa de Figueiredo

Coordenador do Curso de Engenharia de Computacao:

Danielle Gordiano Valente

Coordenador da Disciplina Projeto Final:

Raimundo Correa de Oliveira

Banca Avaliadora composta por: Data da Defesa: 22 / 12 /2011.

Prof. M.Sc. Andre Luiz Printes (Orientador)

Prof. M.Sc. Edgard Luciano Oliveira da Silva

Prof. M.Sc. Tiago Eugenio de Melo

CIP - Catalogacao na Publicacao

P832o PORTELA, Andre

Otimizacao de desempenho de sistema GIS de monitoramento de sensores

microprocessados com a Google Maps API / Andre Portela; [orientado por]

Prof. MSc. Andre Luiz Printes - Manaus: UEA, 2011.

65 p.: il.; 30cm

Inclui Bibliografia

Trabalho de Conclusao de Curso (Graduacao em Engenharia de Computa-

cao). Universidade do Estado do Amazonas, 2011.

CDU: 004

iii


OTIMIZACAO DE DESEMPENHO DE SISTEMA GIS DE

MONITORAMENTO DE SENSORES MICROPROCESSADOS COM A

GOOGLE MAPS API

Trabalho de Conclusao de Curso apresentado

a banca avaliadora do Curso de Engenharia

de Computacao, da Escola Superior de

Tecnologia, da Universidade do Estado do

Amazonas, como pre-requisito para obtencao

do tıtulo de Engenheiro de Computacao.

Aprovado em: 22 / 12 /2011BANCA EXAMINADORA

Prof. Andre Luiz Printes, Mestre

UNIVERSIDADE DO ESTADO DO AMAZONAS

Prof. Edgard Luciano Oliveira da Silva, Mestre


Prof. Tiago Eugenio de Melo, Mestre


v

Agradecimentos

Ao finalizar este trabalho, apos quase tres

anos, tive o prazer de contar com a amizade

e o incentivo de pessoas que tornaram mais

suave este caminho. A elas, agradeco:

A minha “famılia”, que ficou privada de mi-

nha companhia diversas vezes, mas sempre

me incentivou e apoiou.

Aos meus colegas de faculdade, e professores,

com quem pude dividir alegrias e angustias

durante o tempo em que fiquei na faculdade

e as pessoas que trabalham ou trabalharam

comigo e me apoiaram fortemente a concluir

esta etapa da minha vida profissional.

vi

Resumo

O objetivo deste trabalho e tratar problemas caracterısticos de desempenho atraves de

otimizacao e quantificar as alteracoes destas caracterısticas pos-otimizacao. Uma abor-

dagem estruturada e sistematica e utilizada para caracterizar elementos de desempenho,

identificar problemas potenciais atraves de testes, definir e implementar estrategias de

otimizacao e realizar uma analise comparativa pos-otimizacao em sistema computacional

Mashup chamado de SGT. Sistema este que utiliza a Google Maps API para atribuir

caracterısticas de sistemas de informacao geografica (GIS ) ao monitoramento remoto de

sensores microprocessados, cuja finalidade e aferir parametros eletricos de transformadores

de energia em uma rede de distribuicao.

Palavras Chave: otimizacao de desempenho, testes de desempenho, Mashup, SGT,

Google MAPS API, GIS.

vii

Abstract

This work’s objective is to handle performance problems through tuning and to

quantify changes in the post-optimization characteristics. A structured and systematic

approach is used to characterize performance elements, identify potential problems through

tests, define and implement tuning strategies and make a post-optimization comparative

analysis in a Mashup computational system called SGT. This system uses Google Maps

API to provide geographic information systems (GIS) characteristics to remote monitoring

of microprocessed sensors which have the purpose of assess eletrical parameters of power

transformers in a power system network.

Key-words: optimization, performance tuning, performance tests, Mashup, SGT, Goo-

gle Maps API, GIS.

viii

Sumario

Lista de Tabelas x

Lista de Figuras xi

Lista de Codigos xii

1 Introducao 1

2 Mapeamento de elementos do sistema 6

2.1 Caracterizacao de propriedades qualitativas . . . . . . . . . . . . . . . . . 7

2.2 Tecnicas arquiteturais para selecionar elementos de desempenho . . . . . . 9

2.2.1 Descricao arquitetural . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.2 Views de desempenho . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.3 Perspectivas arquiteturais . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.4 Armadilhas arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Selecao de elementos de desempenho . . . . . . . . . . . . . . . . . . . . . 14

2.3.1 Identificacao e priorizacao de stakeholders . . . . . . . . . . . . . . 15

2.3.2 Particionamento de interesses dos stakeholders selecionados . . . . . 17

2.3.3 Priorizacao de requisitos funcionais . . . . . . . . . . . . . . . . . . 18

2.3.4 Consolidacao de requisitos extra-funcionais . . . . . . . . . . . . . . 18

3 Testes de desempenho 22

3.1 Definicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Metas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3.1 Identificando o ambiente de teste . . . . . . . . . . . . . . . . . . . 27

3.3.2 Casos de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.3 Cenarios de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

ix

3.3.4 Ferramentas de teste . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.5 Testes de carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.6 Testes de desempenho . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5 Problemas Potenciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Otimizacao de desempenho 34

4.1 Definicao de metas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.1 Diminuicao do tempo de carregamento dos mapas . . . . . . . . . . 34

4.1.2 Aumento da velocidade de interacao com os mapas . . . . . . . . . 35

4.2 Definicao de estrategias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.1 Utilizar XHTML simples . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.2 Utilizar cluster de marcadores . . . . . . . . . . . . . . . . . . . . . 37

4.2.3 Limitar o carregamento de marcadores a area visıvel do mapa . . . 39

4.2.4 Realizar o carregamento por streaming de marcadores . . . . . . . . 41

4.2.5 Estrategias selecionadas . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 Taticas de implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3.1 Cluster baseado em grid . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3.2 Cluster baseado em distancia . . . . . . . . . . . . . . . . . . . . . 44

4.4 Implementacao das otimizacoes . . . . . . . . . . . . . . . . . . . . . . . . 45

4.5 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.6 Analise Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5 Conclusoes 61

Referencias Bibliograficas 63

x

Lista de Tabelas

1.1 Transformadores de distribuicao monofasicos instalados ate o ano de 2006 e

de 2007 no Brasil por regiao [SdSOM08] . . . . . . . . . . . . . . . . . . . 4

2.1 Propriedades Qualitativas de Software [Fai10] . . . . . . . . . . . . . . . . 8

2.2 Perdas anuais devido a violacao da regra dos 8 segundos [Sub06] . . . . . . 20

2.3 Ponto de vista dos usuarios no tempo de resposta [Sub06] . . . . . . . . . . 21

3.1 Primeira bateria de testes de carga . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Primeira bateria de testes de desempenho . . . . . . . . . . . . . . . . . . 31

4.1 Segunda bateria de testes de carga . . . . . . . . . . . . . . . . . . . . . . 57

4.2 Segunda bateria de testes de desempenho . . . . . . . . . . . . . . . . . . . 58

xi

Lista de Figuras

1.1 Elementos do SGT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Balanceamento de propriedades qualitativas [BLKW95] . . . . . . . . . . . 9

2.2 Aplicando perspectivas as views [RW05] . . . . . . . . . . . . . . . . . . . 11

2.3 Framework Conceitual IEEE1471 [Soc00] . . . . . . . . . . . . . . . . . . . 12

2.4 Ciclo fechado de iteracao [Vec08] . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Elementos do SGT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Experiencia de utilizacao do web-site [Sav00] . . . . . . . . . . . . . . . . . 19

2.7 Porcentagem de usuarios que abandonam web-sites [Sav00] . . . . . . . . . 20

3.1 Sistemas cliente-servidor [HQN03] . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Arquitetura tıpica de sistemas web [HQN03] . . . . . . . . . . . . . . . . . 24

3.3 Elementos do SGT na internet . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4 Interface da Ferramenta JMeter . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5 Resultados da primeira bateria de teste de carga . . . . . . . . . . . . . . . 31

3.6 Resultados da primeira bateria de testes de desempenho . . . . . . . . . . 32

4.1 Requisicao HTTP detalhada [Kil98] . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Marcadores proximos renderizados individualmente [LM] . . . . . . . . . . 39

4.3 Marcadores proximos renderizados em cluster [LM] . . . . . . . . . . . . . 39

4.4 Carregamento de todos os marcadores [LM] . . . . . . . . . . . . . . . . . 40

4.5 Carregamento dos marcadores presentes na area visıvel do usuario [LM] . . 41

4.6 Posicao dos marcadores nos grids [LM] . . . . . . . . . . . . . . . . . . . . 43

4.7 Clusters em seus respectivos grids [LM] . . . . . . . . . . . . . . . . . . . . 43

4.8 Grande numero de marcadores no mapa [LM] . . . . . . . . . . . . . . . . 44

4.9 Clusters agrupados por distancia [LM] . . . . . . . . . . . . . . . . . . . . 45

4.10 Representacao dos elementos do Django no modelo MVC . . . . . . . . . . 46

4.11 Ciclo de vida simplificado de uma requisicao HTTP para a exibicao do mapa 47

xii

4.12 Resultados da segunda bateria de testes de desempenho . . . . . . . . . . . 58

4.13 Resultados da segunda bateria de teste de carga . . . . . . . . . . . . . . . 59

4.14 Comparacao entre as duas baterias de teste de carga . . . . . . . . . . . . 60

4.15 Comparacao entre as duas baterias de teste de desempenho . . . . . . . . . 60

xiii

Lista de Codigos

3.3.1 Exemplo de codigo de instrumentacao JavaScript . . . . . . . . . . . . . . 30

4.2.1 Chamada da Google Static Maps API em codigo XHTML [Goo] . . . . . . 37

4.2.2 Exemplo JavaScript da utilizacao de marcadores [Sve10] . . . . . . . . . . 38

4.2.3 Trecho de codigo JavaScript usando AJAX para recuperacao de marcadores 42

4.4.1 Trecho do arquivo settings.py . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.4.2 Funcao Mostrar Mapa() no arquivo views.py . . . . . . . . . . . . . . . . . 48

4.4.3 Extrutura XHTML do arquivo mapa.xhtml . . . . . . . . . . . . . . . . . . 49

4.4.4 Funcao load() do arquivo mapa.xhtml . . . . . . . . . . . . . . . . . . . . . 50

4.4.5 Objeto Map() do arquivo mapa.xhtml . . . . . . . . . . . . . . . . . . . . . 51

4.4.6 Funcao iniciar pontos() do arquivo mapa.xhtml . . . . . . . . . . . . . . . 52

4.4.7 Funcao carregar pontos normal() do arquivo mapa.xhtml . . . . . . . . . . 53

4.4.8 Funcao atualizarPontosUR() do arquivo mapa.xhtml . . . . . . . . . . . . . 53

4.4.9 Funcao carregar pontos ajax() do arquivo mapa.xhtml . . . . . . . . . . . . 54

4.4.10Funcao Carregar MapaAjax() do arquivo views.py . . . . . . . . . . . . . . 54

4.4.11Template mapa2.xhtml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.4.12Funcao load() modificada do arquivo mapa.xhtml . . . . . . . . . . . . . . 56

4.4.13Funcao carregar pontos normal() alterada no arquivo mapa.xhtml . . . . . 57

Capıtulo 1

Introducao

Otimizacao de desempenho e a adaptacao da velocidade de um sistema computacional aos

requisitos de velocidade impostos pelo mundo real [LM02] e e um processo tipicamente

iterativo e realizado em etapas de testes, coletas de dados e otimizacoes. O objetivo

deste processo e resolver problemas caracterizados pelo nao atendimento de requisitos de

desempenho e insatisfacao de usuarios dos sistemas em questao [MFB+07].

Testes e otimizacao de desempenho sao frequentemente tratados mais como arte do que

como ciencia. Testes de desempenho em aplicacoes web sao particularmente faceis, e facil

projetar cenarios nao-realistas, coletar e medir dados de desempenho irrelevantes e utilizar

os metodos errados para sumarizar e apresentar os resultados [MFB+07].

As disciplinas de teste e otimizacao de desempenho sao chamadas de arte por inumeras

obras [Sav00], [Sub06] e [MFB+07]. Porem, porque sao chamadas de arte e nao de ciencia

ou engenharia? Arte pode ser definida como a capacidade humana de criacao, enquanto

que a definicao de engenharia trata sobre a aplicacao de conhecimento cientıfico e empırico

na definicao de estruturas e processos [dHF08].

A afirmacao de que softwares estao ficando mais complexos e uma constante no mundo

do desenvolvimento de software [Som06]. Portanto, a aplicacao de conhecimentos e me-

todos puramente cientıficos nos seus testes e otimizacoes de desempenho tambem vem

apresentando complexidade ascendente. Com o crescimento da complexidade dos softwa-

res atualmente desenvolvidos, nao utilizar boas praticas de engenharia de software para

atividades como definicao de requisitos ”extra-funcionais”, validacao destes requisitos e re-

2

trabalho arquitetural para adequacao das propriedades qualitativas de um sistema deixa

de ser uma opcao e passa a ser uma necessidade crescente.

A conformidade clara com os requisitos de desempenho em sistemas computacionais e

essencial para a entrega de valor para seus stakeholders. Portanto, e importante que os

limiares de operacao do sistema sejam caracterizados adequadamente atraves de metodos

de validacao dos requisitos. Entretanto, mesmo para grandes projetos de software, e muito

comum que sistemas computacionais possuam objetivos de desempenho vagos, incompletos

e ambıguos, o que os torna excepcionalmente difıceis de validar [RW05].

Uma tarefa excepcionalmente difıcil e identificar a necessidade da realizacao de teste e

otimizacao de desempenho para um determinado sistema computacional. Quando nao se

possui uma base de comparacao e ainda mais difıcil, pois ha a possibilidade de se argu-

mentar ate mesmo sobre a existencia de tal necessidade. Portanto, na falta de requisitos

explıcitos de desempenho, e perfeitamente factıvel utilizar a experiencia do usuario final

como referencia [Vec08].

SGT atende por Sistema de Gerenciamento de Trafos - o termo trafo, neste trabalho,

sera utilizado como sinonimo de transformador de energia eletrica - e um sistema compu-

tacional cujo objetivo e monitorar remotamente as caracterısticas de transformadores de

energia eletrica em uma dada rede de distribuicao. A figura 1.1 exibe os elementos que

compoem o SGT e as suas respectivas interacoes.

3

Figura 1.1: Elementos do SGT

As unidades remotas sao sensores microprocessados localizados nos trafos da rede de

distribuicao e sua funcao e monitorar as caracterısticas eletricas de cada trafo. Estes

sensores se comunicam com uma aplicacao de sensoriamento localizada em um servidor

que recebe as informacoes dos sensores, as persiste no banco de dados e envia tarefas

especıficas para estes sensores provenientes de comandos da aplicacao web.

A aplicacao web se comunica com a aplicacao de sensoriamento atraves de agendamentos

de comandos inseridos no banco de dados e leitura dos dados dos sensores, este elemento

gerencia o sistema e e efetivamente operado por seus usuarios atraves de um browser que

acessa sua interface web.

Pela caracterıstica das redes de distribuicao de energia eletrica as quais o sistema se

propoe a monitorar, existe o potencial de monitoramento de milhares de transformadores,

conforme mostra a tabela 1.

4

Tabela 1.1: Transformadores de distribuicao monofasicos instalados ate o ano de 2006 e de2007 no Brasil por regiao [SdSOM08]

Transformadores de distribuicao 1 Φinstalados no ano de 2006 e 2007

Regiao Quantidade no ano de 2006 Quantidade no ano de 2007Nordeste 190.228 216.617

Norte 67.263 105.173Sul 364.000 389.782

Sudeste 759.325 774.259Centro Oeste 53.678 66.277

Total 1.434.494 1.552.107

Pelo potencial de gerenciar milhares de unidades remotas, o sistema possui uma funci-

onalidade para exibir estes elementos em um mapa geografico. Quando as informacoes a

serem comunicadas possuem distribuicao geografica - sejam elas dados demograficos, ambi-

entais ou dados eletricos sobre transformadores - mapas apresentam informacoes de forma

mais clara do que qualquer representacao tabular, tal qual graficos apresentam informacoes

numericas de uma forma de facil entendimento [Kro05].

O sistema utiliza a Google Maps API para exibir um mapa da regiao monitorada e

plotar marcadores que representam a localizacao de cada unidade remota. Isto classifica

a aplicacao web do sistema como uma aplicacao Mashup, pois reune diferentes fontes de

dados e servicos para criar uma experiencia unica ao usuario final [Ogr09]. Portanto, o

sistema pode ser classificado como uma aplicacao Mashup com caracterısticas GIS, o que

impacta nas consideracoes sobre priorizacoes de desempenho do sistema.

Neste contexto, o presente trabalho tem como objetivo utilizar uma abordagem estru-

turada e sistematica para caracterizar elementos de desempenho do sistema, identificar

problemas potenciais atraves de testes, definir estrategias de otimizacao para enderecar

problemas identificados e realizar uma analise comparativa para quantificar as mudancas

de desempenho do sistema apos o processo de otimizacao.

Para tanto, aspectos de desempenho serao selecionados baseados em taticas arquite-

turais de mapeamento de propriedades qualitativas e serao testados utilizando-se tecnicas

de teste especıficas. O objetivo destes testes e apontar problemas no sistema e para os

problemas encontrados serao desenvolvidas estrategias de tuning que posteriormente serao

implementadas e analisadas para determinar seu impacto no desempenho final do sistema.

5

Esta monografia esta organizada da seguinte forma: o capıtulo 2 discorre sobre

taticas arquiteturais de mapeamento de propriedades qualitativas do sistema e seleciona

elementos especıficos para serem inicialmente testados; no capıtulo 3 sao abordados os

testes de desempenho, a metodologia utilizada para realiza-los, seus resultados obtidos,

problemas potenciais e sao levantadas hipoteses iniciais sobre as caracterısticas do sistema;

o capıtulo 4 apresenta as metas da otimizacao, suas definicoes estrategicas, taticas,

diferentes implementacoes, resultados obtidos e analises comparativas entre os dados dos

testes iniciais e os testes pos-otimizacao; por fim, as conclusoes sao realizados no capıtulo

5, assim como sugestoes para trabalhos futuros.

Capıtulo 2

Mapeamento de elementos do sistema

Enquanto existe um consenso crescente da importancia de desempenhar atividades arqui-

teturais na vanguarda das equipes de desenvolvimento de software, ainda existe pouca

concordancia quanto aos limites entre requisitos de software, arquitetura e projeto. A falta

de definicao clara e concisa do papel da arquitetura de software e mais problematica, devido

a seriedade dos problemas que os projetos de software precisam resolver [RW05].

• A expectativa de usuarios e outros stakeholders em termos de funcionalidades, prazo,

orcamento, flexibilidade e capacidade tem se tornado muito mais exigentes;

• Prazos longos de desenvolvimento resultam em mudancas de escopo contınuas e con-

sequentemente em mudancas na arquitetura e projeto do sistema;

• Os sistemas atuais estao cada vez mais complexos funcional e estruturalmente e

frequentemente sao construıdos a partir de uma mistura de componentes prontos,

personalizados e construıdos sob demanda;

• Poucos sistemas existem isoladamente, espera-se da maior parte dos sistemas que eles

sejam capazes de interagir e trocar informacoes com outros sistemas;

• Projetar corretamente a estrutura funcional do sistema e apenas parte do problema,

o modo como o sistema se comporta (suas propriedades qualitativas) e tao crıtico a

sua eficacia quanto o que ele desempenha funcionalmente;

Caracterização de propriedades qualitativas 7

Diferente da engenharia de software (no que tange a arquitetura de software), outras

engenharias como a naval, quımica e civil (apenas para citar algumas) se apoiam em seculos

de teoria e boas praticas bem estabelecidas. A existencia destas boas praticas tem uma

consequencia muito importante em termos de uniformidade na abordagem para resolver

problemas. Apesar de engenheiros diferentes criarem projetos diferentes para resolver os

mesmos problemas, com a utilizacao de boas praticas, eles tendem a utilizar processos e

tecnicas muito similares para conduzir e apresentar seus projetos [RW05].

Na engenharia de software existem algumas praticas que sao concenso unanime entre

seus profissionais para combater a crescente complexidade dos sistemas computacionais.

Pode-se citar o particionamento de problemas em problemas menores e mais trataveis,

a aplicacao do conhecimento adquirido pela resolucao de problemas anteriores e o uso

intensivo de abstracoes, pois as abstracoes removem detalhes desnecessarios, diminuem o

numero de fatores a serem considerados e facilitam a analise de problemas [Fai10].

Neste capıtulo, serao apresentadas algumas tecnicas arquiteturais para o mapeamento

das propriedades qualitativas de um sistema computacional, caracterizacao de elementos

de desempenho e selecao de elementos de interesse do sistema.

2.1 Caracterizacao de propriedades qualitativas

Propriedades qualitativas sao requisitos ”extra-funcionais”, mais conhecidos como requi-

sitos nao-funcionais, embora o termo extra-funcional seja etimologicamente mais preciso

neste contexto, pois trata de requisitos que vao alem das funcionalidades do sistema com-

putacional [Fai10].

Entender as propriedades qualitativas de um sistema e essencial para a arquitetura de

um software pois a arquitetura influencia ativamente quais qualidades o software consegue

alcancar e em que nıvel ele as atende. Inspecoes arquiteturais triviais podem arruinar a qua-

lidade de um software, enquanto que e necessario planejamento cuidadoso para promove-la.

Idealmente, condicoes testaveis podem ser especificadas para definir as qualidades de-

sejadas, tais como ”eventos de super-aquecimento de transformadores devem ser exibidos

aos usuarios em no maximo 5 segundos durante 98% do tempo”. Na pratica e difıcil escre-

ver bons testes para algumas qualidades tais como usabilidade, desempenho e seguranca

Caracterização de propriedades qualitativas 8

(apenas para citar algumas). Algumas propriedades qualitativas sao melhor analisadas

utilizando um ponto de vista particular [RW05].

A tabela 2.1 mostra algumas propriedades qualitativas comumente referenciadas como

sendo ortogonais as funcionalidades.

Tabela 2.1: Propriedades Qualitativas de Software [Fai10]Pontos de Vista Propriedades Qualitativas

Tempo de execucao Desempenho LatenciaVazaoEficienciaEscalabilidade

Confianca DisponibilidadeConfiabilidadeSeguranca

Seguranca ConfidencialidadeIntegridadeDisponibilidade

Usabilidade Integridade Conceitual / ConsistenciaTempo de deploy Modificabilidade Modularidadee desenvolvimento Interoperabilidade

PortabilidadeIntegrabilidadeIntegridade Conceitual / ConsistenciaExtensabilidadeConfigurabilidade

ReusabilidadeSuportabilidadeInstalabilidadeTestabilidade

As propriedades qualitativas exibidas na tabela 2.1 possuem uma granularidade maior

do que categorias mais abragentes como desempenho. Esse aumento de granularidade e

necessario para permitir a analise de propriedades que podem interferir umas nas outras.

Um exemplo disto e a possibilidade de melhorias na escalabilidade do sistema impactarem

negativamente na sua latencia ou na sua seguranca.

E importante frisar que interferencias entre propriedades dos sistemas e um problema

antigo e tambem um dos maiores desafios do desenvolvimento de software. Projetistas pre-

cisam analisar o custo-benefıcio de propriedades conflitantes com o compromisso de atender

os requisitos dos usuarios. Usualmente este custo-benefıcio e alcancado atraves do controle

de varias propriedades, o que leva a um melhor comportamento geral do software. A figura

Técnicas arquiteturais para selecionar elementos de desempenho 9

2.1 exibe um modelo para representar o conflito de escolha de propriedades qualitativas

em sistemas computacionais.

Figura 2.1: Balanceamento de propriedades qualitativas [BLKW95]

2.2 Tecnicas arquiteturais para selecionar elementos

de desempenho

Como dito anteriormente, boas praticas em disciplinas de engenharia sao extremamente

importantes para consolidar as metodologias envolvidas em seus projetos. Reconhecendo

esta importancia, em 1995 um grupo de planejamento arquitetural de software formado por

membros do Institute of Electrical and Electronic Engineers (IEEE ) comecou a trabalhar

em um conjunto de boas praticas que posteriormente foi chamado de padrao IEEE-STD-

1471-20001, tambem conhecido como ”Recommended Practice for Architectural Description

of Software-Intensive Systems”.

O objetivo do IEEE-1471 foi definir a direcao para a incorporacao de consideracoes

arquiteturais de software aos padroes do instituto, estabelecer um framework conceitual e

vocabulario proprio para consideracoes de arquitetura em sistemas computacionais, iden-

tificar e promover praticas arquiteturais promissoras e permitir a evolucao destas praticas

1A partir de agora referenciado apenas como IEEE-1471.


acompanhando a evolucao das tecnologias relevantes.

O IEEE-1471 e um tipo de padrao IEEE conhecido como pratica ”recomendada” pelo

instituto e uma dada organizacao tem a completa responsabilidade de decidir quando e

como empregar as praticas contidas no padrao. Ele se aplica aos interesses arquiteturais de

projetos de software e considera que descricoes arquitetonicas podem estar em conformidade

com estas praticas. Porem, sistemas, processos, organizacoes, metodos e ferramentas nao

podem pois estas praticas foram construıdas em torno de conhecimento empırico utilizando

termos como ”deve”, ”deveria”e ”pode” [Soc00].

Uma tecnica largamente utilizada por arquitetos de software e particionar os requisitos

do software em visoes ou views2 separadas, porem co-relacionadas de modo que cada view

descreve um aspecto separado da arquitetura e todas as visoes juntas descrevem o sistema

inteiro. Uma view e uma representacao parcial da estrutura do sistema que analisa os

aspectos relevantes aos interesses de determinados stakeholders [RW05].

O IEEE criou um padrao a partir desta tecnica propondo o conceito de ”ponto de

vista”ou viewpoint. Viewpoints sao colecoes de modelos, princıpios e convencoes para cons-

trucao de uma visao. Em outras palavras, sao um framework para capturar conhecimento

arquitetonico reutilizavel.

Porem, a criacao de views e viewpoints precisa ser guiada por perspectivas mais

amplas para que a soma de todas as views seja consistente. E exatamente por isso que

o [Soc00] define o conceito de perspectivas arquiteturais. Estas perspectivas sao colecoes

de atividades e taticas utilizadas para garantir que o sistema exibe um conjunto particular

de propriedades qualitativas e sao aplicadas nas views considerando-se limitacoes de

tempo e recursos para analisar e modificar uma dada arquitetura para que esta atenda a

propriedades definidas pelas views como mostra figura 2.2.

2Ao longo deste trabalho, esta terminologia sera utilizada apenas para se adequar a termino-logia encontrada nas obras de referencia.


Figura 2.2: Aplicando perspectivas as views [RW05]

2.2.1 Descricao arquitetural

Uma descricao arquitetural e uma colecao de artefatos que documentam uma ar-

quitetura de uma forma independente de notacao e tem como objetivo definir termos e

conceitos para as consideracoes arquiteturais, servir de base para a evolucao de um aspecto

arquitetural onde exista pouco terminologia comum e prover os meios para consideracoes

arquitetonicas no contexto dos stakeholders do sistema, ciclo de vida e usos das descricoes

arquiteturais. A figura 2.3 a seguir exibe uma representacao deste framework conceitual.


Figura 2.3: Framework Conceitual IEEE1471 [Soc00]

A partir deste modelo, podemos identificar alguns elementos-chave das descricoes

arquiteturais que sao os stakeholders, as views e os viewpoints que se relacionam direta e

indiretamente com a arquitetura de um dado sistema.

2.2.2 Views de desempenho

A utilizacao de views tem como premissa a consideracao de alguns pontos tais como

quem sao os stakeholders a quem a view se destina, quanto de entendimento tecnico estes

stakeholders possuem, quais sao os interesses dos stakeholders que a view pretende tratar,

entre outras [RW05].


As views que tratam sobre desempenho, focam exclusivamente nas propriedades qua-

litativas correspondentes que sao latencia, vazao, eficiencia, escalabilidade, entre outras.

Sua meta e possibilitar a previsibilidade da operacao do sistema de acordo com o perfil

de desempenho tracado para o sistema e tratar o aumento dos volumes de processamento

de dados pelo mesmo. Estas views se aplicam a quaisquer sistemas complexos, com pro-

jecoes de significativas expansoes futuras, com requisitos de desempenho ambiciosos ou

simplesmente pouco claros e ate mesmo inexistentes [RW05].

2.2.3 Perspectivas arquiteturais

Atividades frequentemente envolvidas na criacao de perspectivas arquiteturais e con-

solidacao das views sao a captura dos requisitos de desempenho do sistema, criacao de

modelos de desempenho, conducao de testes praticos, avaliacao dos resultados contra os

requisitos levantados e retrabalho na arquitetura para atender estes requisitos (tambem

conhecido como otimizacao do desempenho do sistema) [Fai10].

Estas atividades podem ser encadeadas de acordo com a metodologia do ciclo fechado

de iteracao (Closed Loop cycle) como mostra a figura 2.4. O ciclo fechado de iteracao

pressupoe a definicao clara dos requisitos de desempenho e inicia-se com a coleta dos dados

de desempenho do sistema. Em seguida, esses dados sao analisados para que problemas

possam ser identificados. Baseando-se nos problemas identificados sao criadas estrategias e

implementacoes alternativas para tratar estas questoes. Por fim, os elementos selecionados

sao testados novamente para que se possa decidir por iniciar um novo ciclo ou encerrar as

iteracoes de otimizacao.

Seleção de elementos de desempenho 14

Figura 2.4: Ciclo fechado de iteracao [Vec08]

2.2.4 Armadilhas arquiteturais

Causas comuns de insucesso no emprego destas tecnicas sao algumas armadilhas no

momento de empregar perspectivas para a criacao e definicao de views. Para evitar tais

armadilhas ha a necessidade de consideracoes cuidadosas para que as perspectivas tratem

de um conjunto pequeno, fechado e intimamente relacionado de interesses em propriedades

qualitativas, entender que frequentemente haverao conflitos entre solucoes sugeridas por

diferentes perspectivas e e necessario balancea-las de acordo com uma priorizacao das

propriedades mais importantes para o sistema (com a ajuda dos stakeholders) [RW05].

2.3 Selecao de elementos de desempenho

Idealmente, todo software de aplicacao crıtica deveria possuir um conjunto completo,

consistente e factıvel de requisitos de desempenho e escalabilidade, porem, na pratica estes


requisitos sao muitas vezes tratados com uma prioridade menor do que os requisitos fun-

cionais do software, pois estes sao definidos em termos de negocio significativos aos seus

usuarios. Requisitos como ser capaz de lidar com a gerencia de ate 3000 transformadores

em uma rede de distribuicao de energia sao uteis pois definem as necessidades reais de

stakeholders, porem precisam ser quebrados em objetivos mais especıficos e quantitativos

para que em cima dos quais seja possıvel realizar testes e analises [RW05].

2.3.1 Identificacao e priorizacao de stakeholders

Na ausencia da especificacao de requisitos ”extra-funcionais” detalhados para questoes

de desempenho no sistema, serao identificados stakeholders principais para estas proprie-

dades, isto auxiliara na determinacao e priorizacao de interesses na perspectiva de desem-

penho.

Tomemos a figura 2.5 como exemplo:

Figura 2.5: Elementos do SGT

De forma imediata podemos identificar os operadores do sistema que o acessarao atra-


ves de brownsers como importantes stakeholders do mesmo, os operadores precisam ter

condicoes de opera-lo de forma adequada mesmo nas situacoes de grande volume de moni-

toramento para que o sistema possua valor agregado.

Por conta disto, e factıvel definir os operadores do sistema como stakeholders que pos-

suem interesse nas propriedades de desempenho do sistema. Outros possıveis stakeholders

seriam os analistas de dados que podem agregar os dados gerados pelo sistema de monito-

racao para inferir informacoes de negocios de grande valor para a organizacao como tempo

de vida util medio, plano de capacidade, necessidade de manutencoes preventivas, etc.

Ao identificar dois possıveis stakeholders, precisamos definir como propriedades de de-

sempenho impactam nos interesses de ambos para que seja possıvel priorizar algumas pers-

pectivas.

Analistas de dados podem estar mais interessados em propriedades de desempenho

do banco de dados para que possam realizar suas analises de forma a nao comprometer

o funcionamento geral do sistema e ainda assim atender a janelas de tempo necessarias

para que suas analises sejam valiosas para a organizacao. Operadores do sistema, por

outro lado, estao mais interessados no desempenho do front-end, pois o utilizam direta e

frequentemente para administrar o sistema, esta administracao dos recursos monitorados

e crıtica para a operacao do sistema, cujo principal objetivo e fornecer informacoes em

tempo habil para a tomada de decisao a cerca dos ativos monitorados [MFB+07].

De posse destas informacoes e possıvel priorizar os esforcos arquiteturais de desempenho

para tratar as questoes mais crıticas e/ou importantes do sistema, limitando-as por tempo

e recursos disponıveis para tal. Como a operacao direta do sistema para detectar eventuais

ameacas ao patrimonio da organizacao, a princıpio, e mais crıtica do que a extracao de

informacoes gerenciais que serao utilizados no medio e longo prazo, e razoavel concentrar

os esforcos arquiteturais de desempenho primeiramente nos interesses dos operadores do

sistema [MFB+07].

Sendo assim, apesar de existirem diversas questoes passıveis de preocupacoes de oti-

mizacao, como o desempenho do software executado em cada sensor microprocessado, a

comunicacao dos sensores com a aplicacao de sensoriamento, a interacao desta aplicacao

com o banco de dados e a operacao do proprio banco de dados, os esforcos de desempe-

nho neste trabalho se restringirao a experiencia de utilizacao do sistema por parte de seus


operadores e administradores.

2.3.2 Particionamento de interesses dos stakeholders seleciona-

dos

Novamente, mesmo com esta restricao, ainda existe uma gama enorme de consideracoes

possıveis e novamente e necessario quebra-las em partes menores e prioriza-las para que seja

possıvel trata-las. Em resumo, pode-se analisar todos os funcionais da aplicacao web do

sistema e particiona-los em grupos menores com objetivos e propriedades de desempenho

diferentes e prioriza-los [MFB+07].

Os requisitos funcionais desta aplicacao podem ser basicamente divididos em 3 grandes

grupos:

1. A representacao visual dos dados monitorados que utiliza mapas para apresentar a

distribuicao geografica destes dados;

2. A representacao tabular dos mesmos dados;

3. A administracao coletiva e individual de unidades remotas;

Representacao visual de dados monitorados

Este grupo de requisitos trata da exibicao grafica de dados no mapa e da interacao

dos operadores com o mesmo. Tem como caracterıstica a criticidade em desempenho de

operacao, pois pode potencialmente lidar com milhares de unidades remotas em uma mesma

tela e isto e um risco a boa operacao do sistema.

Representacao tabular de dados monitorados

Este grupo de requisitos trata da exibicao textual dos dados em tabelas e interacao

dos operadores com o mesmo. Tambem e crıtica para a operacao do sistema, pois tambem

precisa disponibilizar informacao para tomada de decisao em tempo habil. Difere do grupo

anterior pela natureza das aplicacoes web que ja possuem metodos bem consolidados de

tratar questoes de desempenho de tabelas promovendo por exemplo o uso de paginacao

dos dados.


Administracao coletiva e individual de unidades remotas

Este grupo de requisitos trata da insercao de comandos coletivos ou individuais das

unidades remotas, bem como a manutencao de seu cadastro. Caracteriza-se pelo envio de

comandos dos operadores do sistema as unidades remotas e manutencao cadastral das mes-

mas. Sua criticidade de desempenho e diretamente proporcional a quantidade de usuarios

simultaneos do sistema que irao gerar stress nos seus recursos funcionais.

2.3.3 Priorizacao de requisitos funcionais

Para priorizar estes grupos de requisitos pode-se levar em consideracao o ambiente no

qual o sistema esta inserido, a quantidade de usuarios simultaneos tende a ser baixa com

picos estimados em 25 usuarios (informacao proveniente da empresa), portanto, a estima-

tiva de carga para o stress das funcionalidades de administracao das unidades remotas e

baixa o que justifica sua baixa priorizacao frente aos demais grupos funcionais.

Por outro lado, a estimativa de carga de dados para representacao visual e alta. De

acordo com a tabela 1.1, em 2007 foram instalados 105.173 transformadores na rede de

distribuicao de energia eletrica apenas para a regiao norte. Portanto, e possıvel tratar com

prioridade os dois primeiros grupos de requisitos funcionais (representacao visual e tabular

dos dados monitorados). Sendo que o primeiro, por exibir maior valor funcional e por

apresentar potencial tecnico maior de problemas de desempenho relacionados sera o grupo

funcional escolhido como alvo das analises propostas neste trabalho.

2.3.4 Consolidacao de requisitos extra-funcionais

Para os requisitos funcionais selecionados, existem requisitos extra-funcionais direta-

mente relacionados com as propriedades qualitativas de interesse dos stakeholders. Requi-

sitos extremamente comuns na literatura e proporcionalmente importantes como a “regra

dos 8 segundos” e a velocidade de interacao na operacao do sistema podem ser tomados

como pontos de partida para avaliar propriedades qualitativas de interesse [ZR99].

A regra dos 8 segundos diz que a maioria dos usuarios espera no maximo 8 segundos para

um determinado web site carregar [Sav00], a partir deste espaco de tempo a experiencia dos


usuarios se torna ruim o suficiente para que eles pensem em tomar alguma outra decisao

como ilustra a figura 2.6. Obviamente este tempo e influenciado por um numero muito

grande de variaveis tais como tamanho da pagina a ser carregada, potenciais gargalos de

desempenho no servidor web, velocidade da conexao nos dois pontos (brownser e servidor

web) e etc, porem como estas variaveis estao intimamente relacionadas, a melhoria de uma

delas causa uma melhoria no aspecto geral desta questao.

Figura 2.6: Experiencia de utilizacao do web-site [Sav00]

A figura 2.7 mostra a porcentagem de usuarios que tendem a abandonar a utilizacao

de servicos de web-site baseando-se no tempo de resposta.


Figura 2.7: Porcentagem de usuarios que abandonam web-sites [Sav00]

A tabela 2.2 exibe estimativa de perdas financeiras anuais devido a violacao da regra

dos 8 segundos.

Tabela 2.2: Perdas anuais devido a violacao da regra dos 8 segundos [Sub06]Industria Perdas em vendas em milhoes de dolares

Seguros $40Turismo e viagens $34

Imprensa $14Alimentos $9

Financas Pessoais $5Musica $4

Recibos de escritorio $3Textil $3

A velocidade de interacao do sistema pode ser definida como a quao rapido o sistema

responde a interacoes realizadas por seus usuarios e e representada na tabela 2.3.


Tabela 2.3: Ponto de vista dos usuarios no tempo de resposta [Sub06]Tempo de resposta Ponto de vista do usuario

< 0.1 segundo Sensacao de reacao instantanea do sistema< 1.0 segundo Sensacao pequena de atraso, porem o

usuario continua focado no web site< 10 segundos Tempo maximo que o usuario fica focado

no web site, sua atencao ja esta na zona de distracao> 10 segundos Grande probabilidade do usuario ser distraıdo

do atual web site e perder interesse

Para o sistema, a zona de distracao significa que o usuario pode potencialmente consi-

derar outras alternativas funcionais da aplicacao web na tentativa de atingir suas intencoes.

Em outras palavras, se os mesmos dados podem ser exibidos nas formas graficas e textual e

uma delas apresentar elevado tempo de exibicao, e grande a probabilidade de que o usuario

tente utilizar a fonte de dados alternativa.

No escopo deste trabalho, serao considerados os seguintes requisitos de desempenho:

• Regra dos 8 segundos (as telas que exibem dados no mapa deverao carregar em tempo

menor ou igual a 8 segundos);

• Velocidade de interacao (o usuario deve possuir no maximo uma pequena sensacao

de atraso ao interagir com o sistema mesmo durante a monitoracao de 3000 unidades

remotas);

Estes itens sao diretamente afetados pelas propriedades de latencia, vazao, eficiencia

e escalabilidade da aplicacao web do sistema. A priorizacao destes elementos se deu

com base na criticidade de interesses de desempenho de potenciais stakeholders do sistema.

Capıtulo 3

Testes de desempenho

Enquanto a internet oferece conectividade em dispositivos, ela nao oferece controle sobre

o ambiente dos dispositivos clientes ou sobre todas as etapas envolvidas na comunicacao

entre dispositivos clientes e servidores. Diante deste cenario, para realizar testes efetivos

em aplicacoes web e necessario conhecer os sistemas e tecnologias a serem testados de forma

a reduzir o numero de variaveis ambientais tornando o problema menor e tratavel [Ngu01].

Um sistema puramente web pode possuir qualquer numero de servidores fısicos, cada

um fornecendo um ou mais tipos de servicos tais como servicos e paginas web, servidores

de aplicacao, banco de dados e etc. E possıvel colocar em perspectiva alguns elementos

deste tipo de sistema tal qual exibe a figura 3.1.

23

Figura 3.1: Sistemas cliente-servidor [HQN03]

Esta forma de tratar aplicacoes cliente-servidor e valida para muitos sistemas presentes

na internet, porem, nao para todos. A figura 3.2, por exemplo, mostra de forma um pouco

mais detalhada uma estrutura tıpica de aplicacoes web.

24

Figura 3.2: Arquitetura tıpica de sistemas web [HQN03]

A figura 3.2 demonstra que sistemas web sao essencialmente distribuıdos por natureza,

porem a arquitetura deste tipo de sistema pode ficar ainda mais complexa, como e o caso

do sistema analisado. O sistema analisado neste trabalho incorpora caracterısticas comuns

de sistemas web e as combina com caracterısticas de monitoramento remoto de sensores

como demonstra a figura 3.3 a seguir.

Figura 3.3: Elementos do SGT na internet

Neste cenario o numero de variaveis a ser considerado e muito alto e as simplificacoes

certas sao necessarias para tornar os testes executaveis, controlados, porem nao irreais.

Definição 25

3.1 Definicao

Testes de desempenho sao os tipos de teste com o objetivo de determinar a capacidade

de resposta, vazao, confiabilidade e escalabilidade de um sistema sob determinada carga de

trabalho. Sao testes frequentemente utilizados para avaliar a maturidade de um software

a ser lancado em producao em termos de conformidade com criterios de desempenho,

comparar caracterısticas entre multiplos sistemas ou configuracoes (benchmarking), achar

fontes de problemas (gargalos de desempenho) e suportar o processo de otimizacao de

desempenho [MFB+07].

3.2 Metas

Os testes de desempenho realizados neste trabalho possuem as metas de identificacao de

problemas de desempenho associados aos objetivos tracados no capıtulo 2 que e caracterizar

elementos de desempenho atrelados ao ponto de vista dos operadores do sistema, isto

e, usuarios que utilizarao sua interface web para realizar o monitoramento das unidades

remotas.

Para o primeiro requisito, regra dos 8 segundos definida na secao 2.3.4, o sistema deve

possuir um tempo de resposta as requisicoes para a pagina grafica de monitoramento de

unidades remotas inferior a 8 segundos para o acesso concorrente de 25 usuarios, dada uma

carga de ate 3000 unidades remotas cadastradas no banco de dados.

Para o segundo requisito (velocidade de interacao), o sistema deve ser capaz de res-

ponder a interacoes do usuario com a pagina grafica de monitoracao (a saber, cliques de

mouse em marcadores especıficos do mapa) em um tempo maximo de ate 1 segundo para

uma carga de ate 3000 unidades remotas exibidas na tela.

3.3 Metodologia

A figura 3.3 mostra que, para o sistema analisado, a aplicacao web e a aplicacao de

sensoriamento possuem baixo acoplamento atraves do banco de dados. A aplicacao de

sensoriamento se comunica com as unidades remotas recolhendo os dados das mesmas e

Metodologia 26

inserindo-os no banco de dados e conferindo eventuais agendamentos de comandos realiza-

dos pela aplicacao web. A aplicacao web, por sua vez, consome estes dados e realiza estes

agendamentos inserindo informacoes especıficas no banco.

Em funcionamento, o sistema estabelece apenas uma relacao indireta entre a aplicacao

web, a aplicacao de sensoriamento e as unidades remotas. Por tanto, esta fora do escopo

deste trabalho analisar as questoes de desempenho relacionadas a aplicacao de sensoria-

mento e as unidades remotas.

O impacto das atividades das mesmas possui impacto funcional maior do que o de

desempenho, isto nao quer dizer que o desempenho da aplicacao web nao seja afetado.

Grandes volumes de unidades remotas significam grandes volumes de marcadores a serem

monitorados nos mapas e eventos associados a estas unidades remotas sao igualmente

refletidos nos mapas. Porem, para fins de testes, estas situacoes podem ser emuladas

realizando carga previa do banco de dados compartilhado.

Os requisitos funcionais analisados, nao requerem respostas das unidades remotas a

comandos agendados pela aplicacao web. A real dependencia e que unidades remotas

estejam cadastradas e possuam dados de localizacao e de parametros eletricos validos. Isto

torna simples a criacao da massa de dados, uma vez que e necessario apenas criar entidades

que representam unidades remotas hipoteticas e atribuir valores validos ao seus atributos

de medicao.

A metodologia adotada nos testes de desempenho deste trabalho consistiu basicamente

em:

• Identificar o ambiente de testes;

• Modelar o uso estimado da aplicacao;

• Criar casos de teste especıficos;

• Selecionar ferramentario de teste;

• Criar massa de testes;

Metodologia 27

3.3.1 Identificando o ambiente de teste

O servidor de teste e um laptop HP-Pavilion dv4-1125br com o Ubuntu 11.10 64bits

instalado. Este servidor e host do banco de dados Mysql 5.1, do servidor web Apache

2.2.20 que hospeda a aplicacao web do sistema. A aplicacao e executada pelo interpretador

python 2.7.2 e o navegador utilizado e o firefox versao 8.0.

O servidor de testes possui uma conexao com internet de 10 Mbps e os testes devem

ser executados fora dos horarios de pico de utilizacao do provedor de internet (apos as

22h e antes das 8h) de forma a minimizar possıveis impactos decorrentes de variacao da

velocidade do link de internet.

3.3.2 Casos de teste

Os casos de testes da aplicacao sao simples pela caracterıstica das funcionalidades ana-

lisadas. A partir dos requisitos levantados, foram desenvolvidos dois casos de testes:

1. Depois de logado, o usuario de testes deve clicar em um link na tela inicial da aplicacao

para exibir a tela de monitoramento grafico. O tempo total desta requisicao sera

medido utilizando diferentes cenarios de teste;

2. Depois de logado e na tela grafica de monitoramento, o usuario de testes deve clicar

em um marcador para que seja aberta uma janela de informacoes caracterıstica da

Google Maps API. O tempo total da execucao deste codigo sera medido utilizando

diferentes cenarios de teste;

3.3.3 Cenarios de teste

Os cenarios de teste desenvolvidos para a execucao dos testes sao igualmente simples e

apenas requerem a criacao de massas de dados de diferentes volumetrias, foram criados 5

cenarios de testes.

As volumetrias adotadas foram (em registros de unidades remotas e seus respectivos

atributos eletricos): 10, 50, 100, 1000 e 3000.

Metodologia 28

Os cenarios especıficos dos testes de carga possuem a caracterıstica de serem executados

concorrentemente por 25 usuarios de teste diferentes (threads criadas pelo JMeter) para

refletir as condicoes de concorrencias que serao encontradas em producao.

3.3.4 Ferramentas de teste

Foram selecionadas tres ferramentas especıficas para os testes:

• JMeter;

• Programa de criacao de massa de dados escrito em C++;

• Codigo JavaScript de instrumentacao inserido diretamento no codigo da aplicacao;

JMeter

O JMeter e uma ferramenta consagrada para testes de desempenho e carga em apli-

cacoes web, soap, banco de dados, entre outras. Foi escolhido como ferramenta devido a

sua flexibilidade de configuracao, suporte a multithreading para emular acessos concorren-

tes a aplicacao. E permitir gravacao das requisicoes HTTP realizadas a aplicacao web do

sistema. A figura 3.4 exibe a interface da ferramenta.

Metodologia 29

Figura 3.4: Interface da Ferramenta JMeter

Programa de criacao de massa de dados

Este programa, escrito com a unica finalidade de criar registros no banco de dados que

representam unidades remotas monitoradas, pode ser parametrizado com a volumetria de

unidades remotas a ser inserida no banco de dados.

Instrumentacao JavaScript

Simples codigo JavaScript inserido diretamente no codigo da aplicacao para fins de

teste. Apresenta-se na forma de uma funcao wrapper que encapsula a funcionalidade do

codigo a ser testado e mede o seu tempo de execucao. O codigo 3.3.1 a seguir exibe um

exemplo deste codigo de instrumentacao que possui precisao maxima de 1 milisegundo.

Resultados Obtidos 30

1 function instrumentingWrap() {2 var start = new Date().getMilliseconds();3 // codigo especıfico a ser medido4 var stop = new Date().getMilliseconds();5 var executionTime = stop - start;6 alert("funcaoMedida() executou em " + executionTime + " milisegundos");7 }

Codigo 3.3.1: Exemplo de codigo de instrumentacao JavaScript

3.3.5 Testes de carga

Os testes de carga foram executados em baterias de 10 testes para cada cenario de

teste e o resultado das execucoes destes testes foi condensado em uma media. Em outras

palavras, tomando-se como exemplo o caso de teste 1: o mesmo foi executado 10 vezes

para o cenario de 100 unidades remotas no banco, em seguida foi extraıda a media dos

resultados destes testes.

3.3.6 Testes de desempenho

Os testes de desempenho tambem foram executados em baterias de 10 testes para cada

cenario de teste e o resultado foi condensado em uma media. Em exemplo: o codigo de

instrumentacao para a exibicao da janela de informacao foi executado 10 para o cenario de

500 unidades remotas no banco, em seguida esses resultados foram sumarizados em uma

media.

3.4 Resultados Obtidos

A tabela 3.1 condensa os resultados obtidos, apos a realizacao da primeira bateria de

testes de carga (caso de teste 1).

Tabela 3.1: Primeira bateria de testes de cargaQtd. marcadores 10 50 100 1000 3000Tempo de carga 2.589s 10.741s 26.628s 50.234s 130.401s

Ja a tabela 3.2 sumariza os resultados obtidos apos a execucao da primeira bateria de

testes de desempenho (caso de teste 2).


Tabela 3.2: Primeira bateria de testes de desempenhoQtd. marcadores 10 50 100 1000 3000

Tempo de execucao 0.020s 0.081s 0.628s 1.723s 2.613s

As figuras 3.5 e 3.6 exibem os graficos destes resultados.

Figura 3.5: Resultados da primeira bateria de teste de carga

Problemas Potenciais 32

Figura 3.6: Resultados da primeira bateria de testes de desempenho

3.5 Problemas Potenciais

A partir dos resultados obtidos, e possıvel identificar dois problemas de desempenho. O

primeiro problema esta na capacidade de carga do sistema, seu tempo de resposta maximo

ficou 1630% acima do limite esperado (8 segundos).

O segundo problema esta no tempo de resposta de interacao do sistema que apresenta

um valor 261.3% acima do limite maximo esperado (1 segundo).

Estes dados caracterizam problemas de desempenho no sistema significando que o sis-

tema nao atende as propriedades qualitativas dos requisitos descritos no capıtulo 2 (secao

2.3.4).

Varias hipoteses podem ser levantadas a partir destes resultados:

• Baixo desempenho dos algoritmos presentes na aplicacao web;

• Pouca otimizacao do banco de dados (pouco desempenho na execucao de queries);

• Conexao de dados lenta com a Google Maps API ;

• Alto trafego de dados com os servidores Google;

Problemas Potenciais 33

Estas hipoteses servirao de insumos para elaboracao de estrategias de otimizacao e os

resultados obtidos a partir da implementacao destas estrategias eliminarao as hipoteses

incorretas.

A breve investigacao destas hipoteses ocorrera na forma de analise dos resultados obti-

dos apos a otimizacao implementada, sendo que os resultados obtidos determinarao se as

hipoteses apresentam problemas solucionados pelas implementacoes.

Capıtulo 4

Otimizacao de desempenho

4.1 Definicao de metas

As metas de otimizacao para a aplicacao web do sistema sao melhorar a experiencia de

usuario diminuindo o tempo de carregamento para a exibicao dos mapas e aumentando a

velocidade de interacao do usuario com os mesmos.

Estas metas, apesar de genericas e abrangentes, fornecem um bom ponto de partida

para o inıcio das atividades de otimizacao. E necessario, porem, que as mesmas sejam bem

definidas em termos quantitativos para que sejam mensuraveis.

Uma armadilha comum em atividades de otimizacao e a falta de definicao quantificavel

de objetivos de melhoria, o que torna difıceis as posteriores analises e avaliacoes de resul-

tados obtidos. Em geral, a falta de conformidade clara com os objetivos das atividades e

uma causa comum ao insucesso das iniciativas de melhoria de desempenho.

Para este trabalho serao utilizadas metas que sao conhecidas como metas de qualidade

de servico (QoS - Quality of Service) e que estao intimamente ligadas com a capacidade

de resposta do sistema (responsiveness) [RW05] e sao descritas a seguir.

4.1.1 Diminuicao do tempo de carregamento dos mapas

O tempo de carregamento de paginas web pode ter inumeras variaveis, tais como desem-

penho do sistema operacional e do hardware do cliente da requisicao, do modem utilizado,

da rede pela qual a requisicao trafega, de possıveis roteadores, de backbones na internet,

do hardware, sistema operacional, software e sistema de arquivos do servidor e inclusive

do conteudo do banco de dados [Kil98].

A figura 4.1 detalha as etapas seguidas pela requisicao de uma pagina web a uma

Definição de metas 35

aplicacao web ate a sua resposta efetiva ao browser que realizou a solicitacao.

Figura 4.1: Requisicao HTTP detalhada [Kil98]

Como e possıvel observar, o numero de variaveis envolvida e alto. Para que a meta da

diminuicao do tempo de carregamento dos mapas seja definida de forma objetiva, pode-se

utilizar uma abordagem cientıfica para reduzir ao maximo o numero de variaveis ambientais

e substituı-las por constantes que posteriormente servirao para possibilitar a reproducibi-

lidade dos resultados e a comparacao com resultados anteriores e posteriores [Vec08].

Portanto, define-se como meta de diminuicao do tempo de carregamento dos mapas o

carregamento de 3000 marcadores no mapa em um tempo inferior a 8 segundos em um

ambiente identico ao ambiente onde os testes iniciais foram conduzidos.

4.1.2 Aumento da velocidade de interacao com os mapas

O aumento da velocidade de interacao com os mapas tem, por sua vez, reduzida intera-

cao com os outros componentes do sistema - seus elementos ficam em grande parte contidos

no browser cliente na forma de codigo JavaScript e elementos DOM - e elevada dependencia

em um servico externo (Google Maps API ). Estas sao condicoes verdadeiramente inospitas

para a quantificacao de metas de otimizacao pois suas validacoes dependerao de instrumen-

tacao manual da operacao do sistema (codigo JavaScript medindo tempos de resposta), o

que, segundo o princıpio da incerteza de Heisenberg [Hut03], produzira perturbacoes no

sistema observado.

Definição de estratégias 36

Contudo, para as intencoes desta meta, estas perturbacoes serao desconsideradas, uma

vez que aproximacoes de ordem de grandeza menor do que as medicoes pretendidas sao

consideradas suficientemente validas para analise.

Finalmente, define-se como meta de aumento da velocidade de interacao com os mapas

a medida indireta de sua velocidade atraves do tempo de resposta de interacao com o web

site, dado que o mesmo nao devera ser maior do que 1 segundo para uma carga de 3000

marcadores no mapa em um ambiente de testes identico ao dos testes iniciais.

4.2 Definicao de estrategias

Para o atingimento destas metas de desempenho e necessario realizar retrabalhos arqui-

teturais no sistema de modo que o comportamento seja adequado. Antes que o retrabalho

seja realizado, ele precisa ser planejado e projetado para tal, utilizando os mesmos compro-

missos de propriedades qualitativas explanados no capıtulo 2 e tambem os compromissos

funcionais utilizados na construcao do sistema. Colocado de uma outra forma, a otimizacao

de desempenho nao deve causar prejuızos funcionais e nem ”extra-funcionais” [RW05].

As estrategias de otimizacao devem ser criadas a partir de hipoteses levantadas na

analise de dados inicial dos testes do sistema e avaliadas a partir de seus potenciais impactos

nas propriedades qualitativas do sistema. Na avaliacao das estrategias, deve ser levado

em consideracao os compromissos com algumas propriedades qualitativas do sistema que

podem ser afetadas como usabilidade e mantenabilidade [Fai10].

Uma heurıstica antiga da engenharia de software [RW05] diz que sistemas computacio-

nais tendem a passar 80% do seu tempo executando 20% do seu codigo. A implicacao em

desempenho e que as estrategias de otimizacao devem focar nestes 20% do sistema.

4.2.1 Utilizar XHTML simples

Uma das hipoteses de problemas potenciais levantadas na secao 3.5 e que o volume de

codigo JavaScript utilizado para plotar os marcadores seja excessivamente grande, o que

onera o tempo de carregamento da pagina. Este panorama pode ser evitado ao remover

grande parte do codigo JavaScript da pagina, deixando apenas marcacoes HTML expostas

ao navegador e pouco codigo JavaScript com o proposito apenas de realizar navegacao.

Existe uma API da famılia Google Maps API chamada de Static Maps API que nao


utiliza JavaScript nem qualquer carregamento dinamico da pagina. Esta API fornece um

webservice que renderiza o mapa com base nos parametros de URL enviados por meio

de uma solicitacao HTTP padrao e o retorna como uma imagem passıvel de exibicao na

pagina web [Goo]. O codigo 4.2.1 exemplifica uma chamada a esta API :

1 <html>2 <header>3 <title>Hello World Google Static Maps</title>4 </header>5 <body>6 <img src="http://maps.google.com/maps/api/staticmap?center=34.420831,7 -119.698190&zoom=11&markers=34.417390,-119.805830|34.419938,-119.6780208 &size=500x300&sensor=false"/>9 </body>

10 </html>

Codigo 4.2.1: Chamada da Google Static Maps API em codigo XHTML [Goo]

Esta estrategia diminui bastante a comunicacao com o servidores da Google pois os

resultados das requisicoes sao apenas imagens, por outro lado, a complexidade de interacao

do usuario anteriormente tratada pela API JavaScript da Google e transferida para o

sistema, o que aumenta custos de manutencoes evolutivas e corretivas.

A utilizacao desta API tambem diminui os limites de escalabilidade do sistema, uma

vez que sua polıtica de limites de uso restringe um valor diario de 1000 solicitacoes que

retornem imagens diferentes para um mesmo utilizador. Outro limite e que as URLs da

Google Static Maps API sao restritos a 2048 caracteres, o que pode limitar a marcacao de

uma quantidade massiva de marcadores [Goo].

Outra desvantagem desta abordagem e a perda de funcionalidades RIA (Rich Internet

Applications). Funcionalidades antes comuns como o arrastar e soltar em um mapa para

movimentar a area monitorada nao serao mais possıveis e sera responsabilidade do sistema

prover funcionalidades que as substituam.

Os potenciais ganhos em desempenho proporcionados por esta estrategia afetam outras

propriedades qualitativas do sistema, tais como mantenabilidade, escalabilidade e funcio-

nabilidade. Portanto, esta estrategia nao sera implementada.

4.2.2 Utilizar cluster de marcadores

Esta abordagem e constituıda no agrupamento de marcadores no mapa, existem diver-

sas tecnicas e algoritmos para realizar este agrupamento. O agrupamento e geralmente


realizado para aumentar o desempenho do codigo JavaScript que controla e plota marca-

dores no mapa segundo criterios como por exemplo, um limiar de quantidade excessiva de

marcadores no mapa. Esta abordagem possui vantagens como melhorar significativamente

o desempenho da interacao com o mapa, facilitar sua leitura e interpretacao reduzindo a

quantidade de elementos visıveis [Sve10].

O codigo 4.2.2 exibe um exemplo adaptado de [Sve10] sobre como usar cluster de

marcadores utilizando a Google Maps API, este exemplo foi utilizado como ponto de partida

para a implementacao de clusterizacao.

1 window.onload = function() {2

3 var options = {4 zoom: 3,5 center: new google.maps.LatLng(37.09, -95.71),6 mapTypeId: google.maps.MapTypeId.ROADMAP7 };8 var map = new google.maps.Map(document.getElementById(’map’), options);9

10 var markers = [];11

12 for (var i = 0; i < 1000; i++) {13

14 var lat = getRandomLat();15 var lng = getRandomLng();16 var latlng = new google.maps.LatLng(lat, lng);17

18 var marker = new google.maps.Marker({position: latlng});19

20 markers.push(marker);21

22 var markerclusterer = new MarkerClusterer(map, markers);

Codigo 4.2.2: Exemplo JavaScript da utilizacao de marcadores [Sve10]

As figuras 4.2 e 4.3 ilustram como clusters agrupam grupos de marcadores.


Figura 4.2: Marcadores proximos renderizados individualmente [LM]

Figura 4.3: Marcadores proximos renderizados em cluster [LM]

4.2.3 Limitar o carregamento de marcadores a area visıvel domapa

A limitacao do carregamento de marcadores a area visıvel do mapa tem o potencial de

diminuir consideravelmente a quantidade de marcadores processados dependendo da sua


utilizacao por parte do usuario. Esta estrategia parte do princıpio de que e nao e possıvel

prever as acoes do usuario, uma vez que o mapa e carregado e portanto carregar marcadores

que estao localizados fora da area visıvel e disperdıcio de processamento, uma vez que o

usuario pode nunca navegar para estas areas.

Uma desvantagem desta abordagem e a adicao de complexidade adicional no carrega-

mento dos marcadores para limitar a quantidade de marcadores processados. Este aumento

na complexidade do codigo pode aumentar os custos de manutencoes corretiva e evolutiva.

As figuras 4.4 e 4.5 exibem a diferenca entre carregar todos os marcadores e carregar

apenas os marcadores contidos na area visıvel.

Figura 4.4: Carregamento de todos os marcadores [LM]


Figura 4.5: Carregamento dos marcadores presentes na area visıvel do usuario [LM]

4.2.4 Realizar o carregamento por streaming de marcadores

Estrategia consagrada por sites de publicacao de conteudo multimıdia como o youtube

para diminuir substancialmente o tempo de acesso ao conteudo. Os marcadores sao divi-

didos em grupos pequenos e enviados ao browser aos poucos, permitindo que o primeiro

acesso do usuario demore um tempo significativamente menor do que se fosse necessario

carregar o conteudo de forma monolıtica.

E disponibilizado ao usuario de forma rapida uma pequena parte dos marcadores. En-

quanto o usuario e livre para interagir com as informacoes ja disponıveis na tela, o browser

realiza sucessivamente pequenas requisicoes AJAX de marcadores e os disponibiliza ime-

diatamente apos recebe-los como exemplificado no codigo 4.2.3. Esta estrategia tende a

melhorar muito a latencia de acesso do site e, no primeiro acesso, causar um efeito de

explosao de informacao na tela.

Táticas de implementação 42

1 function carregar_pontos_ajax(page){2 $.ajax({3 url: ’/admin/monitoramento/mapa/carregarAjax/’+page+’/?finalizado=’4 +finalizado,5 success: function(content) {6 eval(content);7 }8 });9 pagina_atual=parseInt(pagina_atual,10)+parseInt(1,10);

10 }

Codigo 4.2.3: Trecho de codigo JavaScript usando AJAX para recuperacao de marcadores

4.2.5 Estrategias selecionadas

As estrategias selecionadas foram carregar marcadores por streaming e agrupa-los em

clusters. Dado o seu baixo impacto em outras propriedades qualitativas do sistema como

manutencao e usabilidade.

A estrategia de utilizacao de paginas XHTML simples foi descartada pela caracterıstica

indesejada de possuir alto impacto na usabilidade dos mapas, aumentar a complexidade de

manutencao da aplicacao web e diminuir a escalabilidade do sistema.

Por sua vez, a estrategia de limitar o carregamento dos marcadores foi excluıda apenas

por limitacao de recurso de tempo para a bateria de otimizacao.

4.3 Taticas de implementacao

Para implementar o streaming de marcadores foi necessario criar chamadas AJAX para

a realizacao da query que antes retornava todos os marcadores. Esta query foi alterada -

limitando-se arbitrariamente em 10 o numero de registros retornados - para que o controle

dos pacotes seja realizado via JavaScript.

Existem varias algoritmos para a criacao de clusters de marcadores em mapas, alguns

analisados foram:

4.3.1 Cluster baseado em grid

O cluster baseado em grid funciona dividindo o mapa em varios quadrados que mudam

de tamanho conforme o nıvel de zoom em que o mapa se encontra e agrupando todos os

marcadores dentro de um mesmo quadrado em clusters. As figuras 4.6 e 4.7 ilustram este

processo.


Figura 4.6: Posicao dos marcadores nos grids [LM]

Figura 4.7: Clusters em seus respectivos grids [LM]

Apesar de sua implementacao ser direta e simples e seu desempenho extremamente

rapido existe um problema com esta abordagem. Durante o agrupamento dos marcadores,


existe a possibilidade de marcadores muito proximos estarem em quadrados diferentes, isto

pode levar a uma grande imprecisao visual apos o agrupamento dos marcadores.

4.3.2 Cluster baseado em distancia

Esta tecnica e similar a anterior com a a diferenca de que ao inves de criar quadrados

fixos no mapa para agrupar os marcadores, este agrupamento e realizado de acordo com

a distancia de cada marcador para centroides dinamicos de clusters. Estes centroides sao

criados com base em criterios relativos as posicoes dos marcadores na mapa, enquanto

que a distancia de agrupamento e parametrizada. As figuras 4.8 e 4.9 exemplificam este

processo.

Figura 4.8: Grande numero de marcadores no mapa [LM]

Implementação das otimizações 45

Figura 4.9: Clusters agrupados por distancia [LM]

A implementacao desta tecnica e um pouco mais complexa do que a anterior, porem

produz resultados visuais muito mais precisos para o agrupamento. A Google Maps API

possui recursos de agrupamento de marcadores em cluster que implementa um comporta-

mento bem similar ao descrito anteriormente e tambem disponibiliza funcionalidades para

o controle de parametros de agrupamento.

Portanto, para o agrupamento de marcadores em cluster foi escolhida a tecnica de

clusterizacao baseada em distancia usando os mecanismo de agrupamento disponibilizados

pela Google Maps API.

4.4 Implementacao das otimizacoes

As principais tecnologias utilizadas pela aplicacao web do sistema sao XHTML, CSS,

Python e JavaScript. Outras tecnologias (frameworks) sao utilizadas para adicionar fun-

cionalidades a aplicacao web, os frameworks de interesse para este trabalho sao Django1 e

Google Maps API 2.

1Framework para aplicacoes web escrito em Python e que roda em servidores web.2Framework escrito em JavaScript e que roda em browsers para incorporar servicos de mapas

do Google a aplicacoes web.


O Django utiliza um Design Pattern conhecido como MVC 3 cujo objetivo e isolar as

regras de negocio da aplicacao de sua interface de usuario, isto permite o desenvolvimento

e edicao separados destas partes [HKM08]. No MVC, o modelo e o codigo que representa

as entidades que sao tratadas pela aplicacao e os dados que podem ser persistidos. A visao

utiliza o modelo para exibir dados ao usuario e suas interacoes com o mesmo disparam a

execucao de codigo do controlador. O controlador, por sua vez, recebe entrada de dados

atraves da visao, processa estes dados utilizando o modelo e inicia uma resposta ao usuario

que sera exibida pela visao [SM02]. A figura 4.10 exibe uma representacao simplificada do

MVC e seus elementos correlatos no Django.

Figura 4.10: Representacao dos elementos do Django no modelo MVC

As taticas de implementacao escolhidas impactam em como o modelo da aplicacao e

exibido e processado, porem, devido ao baixo acoplamento proporcionado pelo MVC, nao

foi necessario realizar modificacoes no modelo da aplicacao. A figura 4.11 exibe de forma

simplificada o ciclo de vida do processamento de uma requisicao HTTP para a exibicao do

mapa no sistema, os elementos modificados aparecem na cor verde.

3Acronimo para Model View Controller


Figura 4.11: Ciclo de vida simplificado de uma requisicao HTTP para a exibicao do mapa

No arquivo settings.py, onde sao realizadas configuracoes globais globais da aplicacao

web, foi adicionada uma constante para representar a quantidade de marcadores a ser

transferida durante cada requisicao. O trecho de interesse deste arquivo e exibido no

codigo 4.4.1.

1 //Codigo omitido para simplificac~ao2 DEBUG = false3 QUANTIDADE_PONTOS_PAGINA=104 FLAG_STATUS_NORMAL = 05 TEMPLATE_DEBUG = DEBUG6 //Codigo omitido para simplificac~ao

Codigo 4.4.1: Trecho do arquivo settings.py

Esta constante, QUANTIDADE PONTOS PAGINA, sera utilizada nas funcoes que

processam a requisicao HTTP para definir o tamanho maximo de um conjunto de registros

a ser retornado pela query que busca informacoes sobre as unidades remotas no banco de

dados, este e o ponto de partida para a implementacao do streaming de marcadores.

A funcao que processa a requisicao para acessar a pagina do mapa na aplicacao esta

exibida no codigo 4.4.2.


1 #Codigo omitido para simplificac~ao2 def Mostrar_Mapa( request ):3 if request.user.is_authenticated():4 normal = []5 zoom = 126 ur_quant = Equipamento_Posto_UR.objects.filter( ativo = True ).count()7 unidades_quant = ( ur_quant + QUANTIDADE_PONTOS_PAGINA -1 ) / QUANTIDADE_PONTOS_PAGINA8 normal = Equipamento_Posto_UR.objects.filter(ativo = True)[:QUANTIDADE_PONTOS_PAGINA]9 return render_to_response(’monitoramento/mapa.xhtml’,

10 { ’title’ : ’Mapa’,’unidades_quant’:unidades_quant,’ur_quant’:ur_quant,11 ’x’:-3.0665700064299997 ,’y’:-59.989471435546875,’google_key’:GOOGLE_KEY,12 ’zoom’:zoom , ’is_popup’ : request.GET.get(’_popup’),13 ’FLAG_STATUS_NORMAL’:FLAG_STATUS_NORMAL, ’UR_normal’ : normal},14 context_instance = RequestContext(request, {}) )15 else:16 return HttpResponseRedirect(’/admin/’)17 #Codigo omitido para simplificac~ao

Codigo 4.4.2: Funcao Mostrar Mapa() no arquivo views.py

Esta funcao realiza algumas configuracoes necessarias para a exibicao correta do mapa,

realiza uma query para buscar os primeiros registros de unidades remotas e renderiza o

template principal de exibicao do mapa que e o arquivo mapa.xhtml parcialmente exibido

no codigo 4.4.3.

1 {% extends "admin/base_site.html" %}2 {% load i18n admin_modify adminmedia %}3 {% block extrahead %}{{ block.super }}4 {% block header %}5 <meta http-equiv="content-type" content="text/html; charset=utf-8"/>6 <script type="text/javascript" src="/site_media/js/jquery-1.4.2.min.js"></script>7 <script src="/site_media/js/jquery-ui-1.8.4.custom.min.js"></script>8 {% endblock %}9 {% block content %}

10 <div id="content-main">11 <input type="hidden" name="_popup" value="1" />12

13 14

15 <input type="hidden" value=0 id="alterar_normal"></input>16


19 20

21 <input type="checkbox" id="check_normal" name="registrado"22 onclick="alterar_pontos(’normal’)"/>23 <span id="n_normal">0</span>24


27 <script src="http://maps.google.com/maps?file=api&v=2&key={{ google_key }}"28 type="text/javascript">29 </script>30

31 </div>32 <body onload="load()" onunload="GUnload(),fechar()"><p>33 <div id="map" style="width: 100%; height: 1000px;"></div>34 </body>35 {% endblock %}36

Codigo 4.4.3: Extrutura XHTML do arquivo mapa.xhtml

O codigo 4.4.3 omite alguns trechos de codigo para aumentar a claridade do mesmo.

Apesar deste arquivo possuir a extensao .xhtml ele nao e um arquivo XHTML valido.

O Django utiliza sua propria Template Engine4 que consiste em inserir o resultado da

avaliacao de variaveis e expressoes Python em zonas especıficas nas marcacoes XHTML.

O codigo 4.4.4 exibe uma das funcoes JavaScript omitidas no codigo 4.4.3 chamada

load() cujo proposito e iniciar o mapa provido pela Google Maps API.

4Framework interno para renderizar paginas web a partir de modelos.


1 var map;2 var janela;3 var points_normal = [];4 var flag_normal = {{FLAG_STATUS_NORMAL}};5 var data_hora_atualizacao_evento=0;6 var temp_normal = [];7 var pagina_atual=0;8 //Codigo omitido para simplificac~ao9 function load(){

10 var map_points = [];11 map = new Map( ’map’ , {{ x }} , {{ y }} , {{ zoom }} );12 map.gmap.addControl(new GSmallMapControl());13 map.gmap.disableDoubleClickZoom();14 map.gmap.enableScrollWheelZoom();15 iniciar_pontos();16 window.opener.location.reload();17 setTimeOut("atualizarPontosUR()",500);18 }19 //Codigo omitido para simplificac~ao

Codigo 4.4.4: Funcao load() do arquivo mapa.xhtml

A funcao load() faz uso do objeto Map() que cria um mapa com suporte para adicionar

marcadores no mesmo. O codigo 4.4.5 exibe a definicao deste objeto.


1 //Codigo omitido para simplificac~ao2 function Point(lat,long,html,url,icon) {3 this.gpoint = new GMarker(new GLatLng(lat,long),{icon:icon,});4 this.html = html;5 this.url = url;6 }7 //Codigo omitido para simplificac~ao8 function Map(id,lat,long,zoom) {9 this.id = id;

10 this.gmap = new GMap2(document.getElementById(this.id));11 this.gmap.setCenter(new GLatLng(lat, long), zoom);12 this.addmarker = addmarker;13 function addmarker(point) {14 if (point.html) {15 GEvent.addListener(point.gpoint, "mouseover", function() {16 var tabs = [];17 tabs.push(new GInfoWindowTab(’Nome’, point.html[0]));18 tabs.push(new GInfoWindowTab(’Serial’, point.html[1]));19 point.gpoint.openInfoWindowHtml(’<h3>Codigo: <hover_text>’ + point.html[0] +20 ’<p><h3>Evento: <hover_text>’ + point.html[2] + ’<p>’ +21 ’<h2><h3>Endereco: <p><hover_text>’ + point.html[1]);22 });23 GEvent.addListener(point.gpoint, "mouseout", function() {24 point.gpoint.closeInfoWindow();25 });26 }27 if (point.url){28 GEvent.addListener(point.gpoint, "click", function(latlng) {29 function abrir(URL) {30 var width = 350;31 var height = 250;32 var left = 99;33 var top = 99;34 if( janela ){35 janela.close()36 }37 janela = window.open(URL,’janela’);38 janela.focus();39 }40 abrir(’/admin/monitoramento/unidade/’ + point.url + ’/?_popup=1&&monitorar=1&&mapa=1’);41 });42 }43 this.gmap.addOverlay(point.gpoint);44 }45 }46 //Codigo omitido para simplificac~ao

Codigo 4.4.5: Objeto Map() do arquivo mapa.xhtml

A funcao load() tambem realiza uma chamada a funcao iniciar pontos() que instancia os

marcadores a serem inseridos no mapa, configura aspectos visuais dos mesmos e configura

a funcao carregar pontos normal() para ser executada apos um segundo. O codigo 4.4.6

mostra a definicao desta funcao.


1 //Codigo omitido para simplificac~ao2 function iniciar_pontos(){3 var points = [];4 {% for unidade in UR_normal %}5 var icon = new GIcon();6 icon.image = "/site_media/img/icons/green.png";7 icon.shadow = "/site_media/img/icons/shadow.png";8 icon.iconSize = new GSize(16, 27);9 icon.shadowSize = new GSize(26, 28);

10 icon.iconAnchor = new GPoint(6, 20);11 icon.infoWindowAnchor = new GPoint(5, 1);12 points.push([ {{ unidade.relacao.posto.latitude }} , {{ unidade.relacao.posto.longitude }} ,13 [’{{ unidade.relacao.posto.substacao }}{{ unidade.relacao.posto.codigo }}’,14 ’{{ unidade.relacao.posto.logradouro }}, {{ unidade.relacao.posto.bairro }}’,15 ’’,],16 ’{{ unidade.dados.id_ur }}’,17 icon18 ]);19 {% endfor %}20 for (var i in points){21 var point = new Point(points[i][0],points[i][1],points[i][2],points[i][3],points[i][4]);22 temp_normal.push(point);23 }24 setTimeout( "carregar_pontos_normal()" , 1000 );25 }26 //Codigo omitido para simplificac~ao

Codigo 4.4.6: Funcao iniciar pontos() do arquivo mapa.xhtml

A funcao carregar pontos normal() efetivamente adiciona estes marcadores no mapa

(ate um maximo de 10) e agenda a sua propria execucao apos um segundo. Caso existam

mais de 10 marcadores, apenas os primeiros 10 sao adicionados, os outros marcadores

serao adicionados nas execucoes subsequentes desta funcao. Esta funcao e definida no

codigo 4.4.7.


1 //Codigo omitido para simplificac~ao2 function carregar_pontos_normal(){3 if( temp_normal.length != 0 ){4 var max;5 if ( temp_normal.length > 10 ){6 max = 10;7 }else{8 max = temp_normal.length;9 }

10 for ( var i=0 ; i < max ; i++ ){11 points_normal.push( temp_normal[i] );12 map.addmarker( points_normal[ points_normal.length - 1 ] );13 if( !document.getElementById("check_normal").checked ){14 points_normal[ points_normal.length - 1 ].gpoint.hide();15 }16 }17 temp_normal.splice(0,max);18 document.getElementById("n_normal").innerHTML = points_normal.length;19 setTimeout( "carregar_pontos_normal()" , 1000 );20 }21 }22 //Codigo omitido para simplificac~ao

Codigo 4.4.7: Funcao carregar pontos normal() do arquivo mapa.xhtml

O ultimo comando da funcao load() exibida no codigo 4.4.2 e o agendamento da exe-

cucao da funcao atualizarPontosUR() exibida no codigo 4.4.8

1 function atualizarPontosUR(){2 if(finalizado==1){3 finalizado=0;4 pagina_atual=0;5 removeTodosPontos();6 atualizar_pontos_ajax();7 }else{8 carregar_pontos_ajax(pagina_atual);9 }

10 if(finalizado==1){11 setTimeout( "atualizarPontosUR()" , 5000 );12 }else{13 setTimeout( "atualizarPontosUR()" , 800 );14 }15 }

Codigo 4.4.8: Funcao atualizarPontosUR() do arquivo mapa.xhtml

Esta funcao carrega o proximo pacote de marcadores (pagina atual) utilizando a fun-

cao carregar pontos ajax() e se apoia nas regras de negocios de outras funcoes para reini-

ciar o carregamento de marcadores. O codigo 4.4.9 mostra a definicao da funcao carre-

gar pontos ajax().


1 function carregar_pontos_ajax(page){2 $.ajax({3 url: ’/admin/monitoramento/mapa/carregarAjax/’+page+’/?finalizado=’4 +finalizado,5 success: function(content) {6 eval(content);7 }8 });9 pagina_atual=parseInt(pagina_atual,10)+parseInt(1,10);

10 }

Codigo 4.4.9: Funcao carregar pontos ajax() do arquivo mapa.xhtml

Esta funcao realiza uma requisicao assıncrona ao servidor web, avalia imediatamente

o resultado da resposta e atualiza o ındice para que o proximo pacote de marcadores seja

recuperado posteriormente. A funcao no servidor que trata esta requisicao assıncrona e

Carregar MapaAjax() e e exibida no codigo 4.4.10.

1 def Carregar_MapaAjax( request , page_no ):2 data_hora = datetime.now().strftime("%Y-%m-%d %H:%M:%S")3 finalizado = request.GET.get(’finalizado’)4 ur_ = []5 page_no = int(page_no)6 idx_start = page_no * QUANTIDADE_PONTOS_PAGINA7 idx_end = idx_start+QUANTIDADE_PONTOS_PAGINA8 relacoes = Equipamento_Posto_UR.objects.filter(ativo = True)[idx_start:idx_end]9 quant_eventos = Equipamento_Posto_UR.objects.filter( ativo = True).count()

10

11 for relacao in relacoes:12 evento = EventoUR.objects.filter( id__exact=relacao.ur.id_evento_ur )[0:1]13 if(len(evento)>0):14 ur_.append( { ’dados’:relacao.ur , ’relacao’:relacao , ’evento’:evento[0] })15 else:16 ur_.append( { ’dados’:relacao.ur , ’relacao’:relacao , ’evento’:False })17

18 page_cnt = ( quant_eventos + QUANTIDADE_PONTOS_PAGINA -1 ) / QUANTIDADE_PONTOS_PAGINA19

20 return render_to_response(’monitoramento/mapa2.xhtml’ , { ’UR’ : ur_,21 ’page_cnt’ : page_cnt,’ur_cnt’:quant_eventos,22 ’FLAG_STATUS_NORMAL’:FLAG_STATUS_NORMAL,’finalizado’:finalizado,23 ’data_hora’:data_hora }, context_instance = RequestContext(request, {}) )

Codigo 4.4.10: Funcao Carregar MapaAjax() do arquivo views.py

A funcao Carregar MapaAjax() realiza uma query limitando a faixa de resultados para

a pagina atual e retorna a renderizacao do template mapa2.xhtml.

O template mapa2.xhtml e exibido no codigo 4.4.11. Este template instancia os objetos

marcadores retornados pela requisicao AJAX do codigo 4.4.10, remove unidades remotas

que tenham sido excluıdas e verifica se o carregamento de marcadores foi finalizado.


1 {% load i18n admin_modify adminmedia %}2 {% load funcoes_monitoramento %}3 {% load funcoes_admin %}4 var view_normal = document.getElementById("check_normal").checked;5 var points = [];6 var point,endimg;7 var id_tipo_evento_aux;8 var icon,alterar=0;9 {% for unidade in UR %}

10 id_tipo_evento_aux = {{unidade.dados.id_tipo_evento}};11 icon = new GIcon();12 {%ifequal unidade.dados.id_tipo_evento FLAG_STATUS_NORMAL %}13 icon.image = "/site_media/img/icons/green.png";14 {% endifequal %}15 icon.shadow = "/site_media/img/icons/shadow.png";16 icon.iconSize = new GSize(16, 27);17 icon.shadowSize = new GSize(26, 28);18 icon.iconAnchor = new GPoint(6, 20);19 icon.infoWindowAnchor = new GPoint(5, 1);20 alterar=0;21 {%ifequal finalizado 1 %}22 alterar=2;23 for ( var i=0 ; i < points_geral.length ; i++ ){24 if(parseInt(points_geral[i][2],10)==parseInt({{ unidade.dados.id }},10)){25 if(parseInt(points_geral[i][3],10)!=parseInt({{ unidade.dados.id_evento }},10)){26 point = points_geral[i][0];27 map.gmap.removeOverlay(point.gpoint);28 points_geral.splice(i,1);29 alterar=1;30 }else{31 alterar=0;32 }33 break;34 }35 }36 {%endifequal%}37 if (!finalizado){38 point = new Point({{ unidade.relacao.posto.latitude }},39 {{ unidade.relacao.posto.longitude }},40 [’{{ unidade.relacao.posto.substacao }}{{ unidade.relacao.posto.codigo }}’,],41 ’{{ unidade.dados.id_ur }}’,icon);42 temp_normal.push([point]);43 }44 {% endfor %}45 {% for unidade in urs_deletadas %}46 for ( var i=0 ; i < points_geral.length ; i++ ){47 if(parseInt(points_geral[i][2],10)==parseInt({{ unidade.dados.id }},10)){48 a=1;49 point = points_geral[i][0];50 map.gmap.removeOverlay(point.gpoint);51 points_geral.splice(i,1);52 alterar=1;53 break;54 }55 }56 {% endfor %}57 quantidade_total_paginas = parseInt({{page_cnt}},10);58 quantidade_total_urs = parseInt({{ur_cnt}},10);59 if(pagina_atual>quantidade_total_paginas){60 data_hora_atualizacao_evento = ’{{data_hora}}’;61 finalizado=1;62 pagina_atual=parseInt(0,10);63 }64 if(pagina_atual==0){65 data_hora_atualizacao_evento = ’{{data_hora}}’;66 }

Codigo 4.4.11: Template mapa2.xhtml


Com estas implementacoes o streaming de marcadores esta finalizado, porem ainda e

necessario implementar o agrupamento dos marcadores em clusters. Para isso, e necessario

alterar a funcao Map() para instanciar o cluster de marcadores. Esta alteracao e exibida

no codigo 4.4.12.

1 if (GBrowserIsCompatible()) {2

3 function Point(lat,long,html,url,icon) {4 this.gpoint = new GMarker(new GLatLng(lat,long),{icon:icon,});5 this.html = html;6 this.url = url;7 }8

9 //Codigo omitido para simplificac~ao10 function Map(id,lat,long,zoom) {11 this.id = id;12 this.gmap = new GMap2(document.getElementById(this.id));13 this.gmap.setCenter(new GLatLng(lat, long), zoom);14 this.addmarker = addmarker;15 this.markerclusterer = new MarkerClusterer(this.gmap);16 //Codigo omitido para simplificac~ao17 //this.gmap.addOverlay(point.gpoint);18 this.markerclusterer.addMarker(point.gpoint);19 function addmarker(point) {20 //Codigo omitido para simplificac~ao21 }//Map

Codigo 4.4.12: Funcao load() modificada do arquivo mapa.xhtml

Por fim, e preciso alterar a forma como os marcadores sao adicionados no mapa, ini-

cialmente os marcadores eram adicionados diretamente no mapa, apos a implementacao

do cluster, estes marcadores passam a ser adicionados somente no cluster. Para tanto, a

funcao addmarker() deve ser alterada como mostra o codigo 4.4.13.


1 //Codigo omitido para simplificac~ao2 function addmarker(point) {3 if (point.html) {4 //Codigo omitido para simplificac~ao5 }6 if (point.url){7 GEvent.addListener(point.gpoint, "click", function(latlng) {8 function abrir(URL) {9 var width = 350;var height = 250;

10 var left = 99;var top = 99;11 if( janela ){12 janela.close()13 }14 janela = window.open(URL,’janela’);15 janela.focus();16 }17 abrir(’/admin/monitoramento/unidade/’ + point.url + ’/?_popup=1&&monitorar=1&&mapa=1’);18 });19 }20 this.markerclusterer.addMarker(point.gpoint);21 }22 //Codigo omitido para simplificac~ao

Codigo 4.4.13: Funcao carregar pontos normal() alterada no arquivo mapa.xhtml

4.5 Resultados Obtidos

Apos a selecao das taticas de otimizacao, as mudancas estruturais propostas para a

arquitetura da aplicacao web do sistema foram implementadas e uma nova bateria de

testes de carga e de desempenho foi realizada seguindo a mesma metodologia e ambiente

e casos de testes utilizada no capıtulo 3.

A tabela 4.1 condensa os resultados obtidos apos a realizacao da segunda bateria de

testes de carga.

Tabela 4.1: Segunda bateria de testes de cargaQtd. marcadores 10 50 100 1000 3000Tempo de carga 2.371s 2.732s 2.521s 2.420s 2.684s

Ja a tabela 4.2 sumariza os resultados obtidos apos a execucao da segunda bateria de

testes de desempenho.


Tabela 4.2: Segunda bateria de testes de desempenhoQtd. marcadores 10 50 100 1000 3000

Tempo de execucao 0.082s 0.136s 0.090s 0.291s 0.245s

As figuras 4.12 e 4.13 exibem os resultados da segunda bateria de testes (pos-

otimizacao).

Figura 4.12: Resultados da segunda bateria de testes de desempenho

Análise Comparativa 59

Figura 4.13: Resultados da segunda bateria de teste de carga

4.6 Analise Comparativa

Ao comparar os resultados obtidos na primeira e segunda bateria de testes de carga,

e possıvel observar uma otimizacao drastica de desempenho no tempo de carregamento

da pagina de mapas. A figura 4.14 demonstra que o tempo de carregamento de pagina

apresenta um tempo praticamente constante variando apenas 0.313mS e manteve-se no

mınimo 5.2s aquem dos limites estabelecidos nos cenarios de testes (8s). O motivo deste

resultado e que com a nova implementacao, independente da quantidade de marcadores no

banco de dados o primeiro acesso a tela exibira inicialmente no maximo 10 marcadores.

Ja nos testes de interacao, observou-se um pequeno aumento no tempo de execucao

para a exibicao de uma quantidade pequena de marcadores como demonstra a figura 4.15,

porem mantendo uma degradacao de desempenho muito menor durante a exibicao de uma

quantidade grande de marcadores e mantendo o resultado dos testes abaixo do limite

maximo estabelecido em todos os cenarios de teste. Este aumento no tempo de resposta

para pequenas quantidades de marcadores deve-se ao overhead causado pela adicao de uma

camada adicional de codigo JavaScript, esta pequena diminuicao na capacidade de resposta

Análise Comparativa 60

do sistema foi compensada pelo grande aumento de sua escalabilidade para este requisito.

Figura 4.14: Comparacao entre as duas baterias de teste de carga

Figura 4.15: Comparacao entre as duas baterias de teste de desempenho

Capıtulo 5

Conclusoes

Prazos de entrega cada vez mais curtos, orcamentos cada vez mais enxutos, requisitos

qualitativos cada vez mais agressivos requerem a utilizacao de metodos de engenharia para

tratar estas questoes com viabilidade tecnica e economica.

Antes de aplicar a otimizacao de desempenho no sistema foi essencial caracterizar seus

elementos de interesse atraves da utilizacao do IEEE1471, a utilizacao desta tecnica permi-

tiu a elaboracao de requisitos de desempenho bem definidos (tempo de carga e velocidade

de interacao) a serem analisados durante este trabalho. A existencia destes requisitos e

determinante para o sucesso de projetos de otimizacao.

Nenhuma das hipoteses de causa raiz dos problemas de desempenho foi refutada ou

confirmada por este trabalho, o uso do ciclo fechado de iteracao apenas utiliza as mesmas

como insumo na elaboracao de estrategias de otimizacao e trata os problemas a partir

da sıntese de implementacoes baseadas nas estrategias. O criterio de parada - atingir os

requisitos de desempenho propostos - para a aplicacao do ciclo fechado de iteracao foi

atingido ao final da primeira iteracao, portanto nao foram realizadas iteracoes posteriores.

O streaming de marcadores se revelou uma tecnica excelente para a diminuicao da

latencia de resposta do sistema. No inıcio dos testes, o sistema possuıa um tempo de

resposta exponencial e apos a implementacao desta tecnica o tempo de resposta passou a

ter um comportamento praticamente constante.

O agrupamento de marcadores em clusters se revelou uma tecnica que possui bom po-

tencial para melhoria da velocidade de interacao quando existem quantidades significativas

de marcadores exibidos no mapa. Com uma quantidade pequena de marcadores, e pos-

sıvel que a utilizacao desta tecnica degrade um pouco o desempenho do sistema, isto foi

observado para um numero de marcadores abaixo de 50.

62

Atividades complexas como testes e otimizacao de desempenho de sistemas computaci-

onais, precisam ser realizadas de forma estruturada para que suas iteracoes cumpram com

seus objetivos e a devida agregacao de valor para os stakeholders seja realizada. E preciso

salientar que as alteracoes estruturais dos softwares submetidos a otimizacao impactam no

balanceamento das propriedades qualitativas do sistema e portanto devem ser realizadas

com foco em objetivos de compromisso com os interesses dos stakeholders. Neste complexo

ciclo de ajustes arquiteturais, a utilizacao apropriada de metodos cientıficos e empıricos e

considerada boa pratica para acelerar o retorno de investimento.

Apesar dos resultados obtidos, este trabalho atentou para algumas propriedades quali-

tativas de interesse de stakeholders especıficos (operadores da aplicacao web do sistema),

o que deixa espaco para que trabalhos futuros identifiquem outros stakeholders, mapeiem

seus interesses e os validem de acordo com propriedades qualitativas relacionadas. O sis-

tema analisado continua passıvel de otimizacao de desempenho em diversos componentes

estruturais, tais como seu banco de dados, sua aplicacao de sensoriamento, suas unidades

remotas e mesmo a propria aplicacao web.

Referencias Bibliograficas

[BLKW95] Mario Barbacci, Thomas H. Longstaff, Mark H. Klein, and

Charles B. Weinstock. Quality attributes. software engi-

neering institute, carnegie mellon university. disponıvel em:

http://www.sei.cmu.edu/library/abstracts/reports/95tr021.cfm, 1995.

[dHF08] Aurelio Buarque de Holanda Ferreira. Miniaurelio: o minidicionario da lıngua

portuguesa. Editora Positivo, setima edicao, 2008.

[Fai10] George Fairbanks. Just Enough Software Architecture: A Risk-Driven Appro-

ach. Marshall Brainerd, first edition, 2010.

[Goo] Inc. Google. Google static maps api.

[HKM08] Adrian Holovaty and Jacob Kaplan-Moss. The Definitive Guide to Django:

Web Development Done Right. Apress, first edition, 2008.

[HQN03] Michael Hackett Hung Q. Nguyen, Bob Johnson. Testing Applications on the

Web: Test Planning for Mobile and Internet-Based Systems. 2003. Wiley

Publishing.

[Hut03] Marnie L. Hutcheson. Software Testing Fundamentals: Methods and Metrics.

2003. John Wiley Sons.

[Kil98] Patrick Killelea. Web Performance Tuning: Speeding Up the Web. O’Reilly,

first edition, 1998.

[Kro05] Bill Kropla. Beginning MapServer: Open Source GIS Development. Apress,


REFERÊNCIAS BIBLIOGRÁFICAS 64

[LM] Google Team Luke Mahe, Chris Broadfoot. Too many markers! disponıvel na

url: http://code.google.com/apis/maps/articles/toomanymarkers.html. Aces-

sado em 21 de outubro de 2011.

[LM02] Mike Loukides and Gian-Paolo D. Musumeci. System Performance Tuning.

O’Reilly, second edition, 2002.

[MFB+07] J. D. Meier, Carlos Farre, Prashant Bansode, Scott Barber, and Dennis Rea.

Performance Testing Guidance for Web Applications: Patterns Practices.

Microsoft Corporation, first edition, 2007.

[Ngu01] Hung Q. Nguyen. Testing Applications on the Web: Test Planning for

Internet-Based Systems. 2001. Wiley Publishing.

[Ogr09] Michael Ogrinz. Mashup Patterns: Designs and Examples for the Modern

Enterprise. Addison-Wesley, first edition, 2009.

[RW05] Nick Rozanski and Eoin Woods. Software Systems Architecture: Working with

Stakeholders Using Viewpoints and Perspectives. Addison-Wesley, first edition,

2005.

[Sav00] Alberto Savoia. The science and art of web site load testing. May 2000.

International Conference On Software Testing Analysis Review - Orlando, Fl,

USA.

[SdSOM08] Carlos Azevedo Sanguedo, Ana Angelica da Silva Oliveira, and Car-

mem Polycarpo Medeiros. Relatorio tecnico: Determinacao das perdas

tecnicas dos transformadores de distribuicao instalados nas empresas con-

cessionarias no brasil. disponıvel em: http://www.procobre.org/pt/wp-

content/plugins/download-monitor/download.php?id=15ei=p-tbtv-

iao7ggge7uodxdausg=afqjcnhktqontiothlulxxybp7yopg0toqcad=rja, 2008.

[SM02] Stephen Stelting and Olav Maassen. Applied Java Patterns. Prentice Hall,


REFERÊNCIAS BIBLIOGRÁFICAS 65

[Soc00] IEEE Computer Society. IEEE 1471-2000 IEEE Recommended Practice for

Architectural Description of Software-Intensive Systems. Software Enginee-

ring Standards Committee of the IEEE Computer Society, ieee std 1471-2000

edition, 2000.

[Som06] Ian Sommerville. Software Engineering. Addison-Wesley Publishers, eighth

edition, 2006.

[Sub06] B. M. Subraya. Integrated Approach to Web Performance Testing: A Practi-

tioner’s Guide. IRM Press, first edition, 2006.

[Sve10] Gabriel Svennerberg. Beginning Google Maps API 3. 2010. Apress Publishing.

[Vec08] Paul Del Vecchio. De-mystifying software performance optimization. dis-

ponıvel em: http://software.intel.com/en-us/articles/de-mystifying-software-

performance-optimization, 2008.

[ZR99] Inc. Zona Research. The economic impacts of unacceptable web-site download

speeds. disponıvel em: www.webperf.net/info/wp downloadspeed.pdf, 1999.

OTIMIZAC˘AO DE DESEMPENHO DE SISTEMA~ GIS DE MONITORAMENTO DE...

Documents

Transcript of OTIMIZAC˘AO DE DESEMPENHO DE SISTEMA~ GIS DE MONITORAMENTO DE...