Revista Icceeg Numero 5

Volume 1 Nmero 5 Dezembro de 2012
REVISTA JUNIOR - ICCEEg
Revista Junior de Iniciao Cientfica em Cincias Exatas e Engenharia
ISSN 2236-0093
Revista Jr de Iniciao Cientfica em Cincias Exatas e Engenharia
FOCO A ICCEEg um peridico semestral de publicao digital dos cursos nas reas de cincias exatas e engenharia que tem por objetivos: Divulgar pesquisas pertinentes nas reas da computao, automao, sistemas da informao, matemtica aplicada e licenciatura, de interesse das comunidades educacional, cultural, cientfica e tecnolgica; Estimular o intercmbio de informao cientfica entre as diversas subreas; Estimular a produo cientfica a nvel de graduao.
SUBMISSES O artigo deve ser original e destinado exclusivamente para a ICCEEg, ou seja, no ter sido publicado em nenhum outro veculo, seja anais de evento, revista ou peridico; Trabalhos apresentados em eventos sero aceitos desde que no tenham sido publicados integralmente em anais, devendo ser autorizados, por escrito, pela entidade organizadora do evento, quando as normas do mesmo assim exigirem, ou em situaes especialmente definidas pela comisso editorial da revista; Os artigos devem estar relacionados diretamente com trabalhos de iniciao cientfica.
Tpicos Aceitos As submisses devem ser artigos tcnicos e cientficos acerca de temas das reas computao, automao, sistemas de informao, matemtica aplicada e licenciatura. Exemplos de tpicos so, dentre outros: Sistemas Multiagentes Aprendizado de Mquina Minerao de dados Engenharia de Software Interface Humano-Computador Bancos de Dados Problemas Inversos Processamento de Imagens Computao Grfica Computao de alto desempenho Problemas de Localizao Fluxos em redes Modelagem por grafos Problemas de coberturas de conjuntos Geometria na atualidade Formao Continuada de Professores de Matemtica
EDITORES Prof. Dra. Diana Francisca Adamatti Prof. Dra. Graaliz Pereira Dimuro Prof. Dra. Karina S. Machado Mestrando Tau Milech Cabreira
ICCEEg - Revista Junior de Iniciao Cientfica em Cincias Exatas e Engenharia vol. 1 n 5 Universidade Federal do Rio Grande: Rio Grande / RS FURG, 2012 Semestral ISSN 2236-0093
Revista Jr de Iniciao Cientfica em Cincias Exatas e Engenharia
ARTIGOS
Modelo de Computao em Nuvem e sua Aplicabilidade, de Eduardo Jacobi, Pedro Popiolek, Vincius Hax, Jnata Tyska, Nelson Duarte e Odorico Mendizabal 1-10
Um Jogo de Estratgias Aplicando Tcnicas de Inteligncia Artificial, de Franthiesca da Silva e Diana Adamatti 11-19
A Avaliao como Ferramenta Motivadora do Processo Ensino-Aprendizagem em Matemtica, de Simone Escouto da Rosa e Martiela Vaz de Freitas 20-25
Gerenciamento de Desvios em Malha Frrea Utilizando Agentes Autnomos Reativos , de Jean Paul Barddal e Fabrcio Enembreck 26-34
Um Estudo sobre Testes de Desempenho com Aplicao Prtica Utilizando a Ferramenta JMeter, de Evandro Neves e Regiane Marucci 35-42
ICCEEg: 1 (5) - Dezembro 2012
O Modelo de Computao em Nuvem e sua Aplicabilidade

E. Bacelar, P. Popiolek, V. Hax, J. Tyska, N. Duarte, O. Mendizabal
ResumoAtualmente departamentos de TI precisam adaptarse s mudanas de negcio sem ocasionar custo excessivo ou complexo gerenciamento para as organizaes. Porm, melhorias em infraestruturas convencionais e esforos para adaptar aplicaes existentes podem no ser compatveis a esta demanda. Buscando solues inteligentes para atender estes requisitos, este artigo trs uma viso geral sobre Computao em Nuvem, um novo paradigma para gerenciamento eficiente de recursos computacionais e proviso de servios sob demanda. Maior flexibilidade, adaptao e economia so algumas de suas vantagens. Esta pesquisa inclui a terminologia atual e os tipos de servio e nuvens disponveis. Alm disso, apresentada uma implementao de nuvem computacional. Onde so discutidos detalhes sobre a infraestrutura, softwares utilizados, forma de gerenciamento e servios a serem disponibilizados. Palavra-ChaveComputao em Nuvem, Mquinas Virtuais, Eucalyptus, Virtualizao.
I. INTRODUO
om o crescimento e globalizao das organizaes, os sistemas de informao tambm necessitam evoluir rapidamente para acompanhar e atender novos requisitos de negcio. Cada vez mais h uma exigncia para que aplicaes corporativas adaptem-se s demandas do mercado em tempo e com custos satisfatrios, sem perda de qualidade. Neste contexto, a maioria dos sistemas computacionais modernos baseia-se em infraestruturas amplamente distribudas, possibilitando o desenvolvimento de aplicaes
E. Bacelar aluno de graduao em Sistemas de Informao na Universidade Federal do Rio Grande FURG (e-mail: eduardobacelar@furg.br). P. Popiolek aluno de graduao em Engenharia de Computao na Universidade Federal do Rio Grande FURG (e-mail: p.f.popilek@furg.br). V. Hax mestrando em Engenharia de Computao na Universidade Federal do Rio Grande FURG. Atualmente atua como Analista de Tecnologia de Informao na mesma instituio (e-mail: viniciushax@furg.br). J. Tyska mestre em Modelagem Computacional pela Universidade Federal do Rio Grande FURG. Atualmente atua como Analista de Tecnologia de Informao na mesma instituio (e-mail: jonatatyska@gmail.com). N. Duarte doutor em Informtica pela Pontifcia Universidade Catlica do Rio de Janeiro. Atua como professor no Centro de Cincias Computacionais da Universidade Federal do Rio Grande FURG (e-mail: dmtnldf@furg.br). O. Mendizabal mestre em Cincia de Computao pela Pontifcia Universidade Catlica do Rio Grande do Sul (PUCRS). Atua como professor no Centro de Cincias Computacionais da Universidade Federal do Rio Grande FURG (e-mail: odoricomendizabal@furg.br).
colaborativas, maior compartilhamento de recursos e aumento no desempenho e disponibilidade. Nas ltimas dcadas, vrias aplicaes e plataformas distribudas foram propostas, desde modelos de aplicao cliente/servidor, redes ponto a ponto (P2P), arquiteturas multicamadas e orientadas a servios, aglomerados e grades computacionais [1]-[2]-[3]-[4]. Embora os modelos de aglomerados e grades computacionais oferecessem compartilhamento de recursos em grande escala, considerando inclusive o acesso a recursos globalmente distribudos, o gerenciamento e poltica de acesso aos nodos computacionais restringiram o uso destes modelos apenas academia. Outra caracterstica destes modelos de computao o alto custo para a manuteno de uma infraestrutura de grande poder computacional. Com o surgimento da Computao em Nuvem ( Cloud Computing), os modelos de programao distribuda em larga escala tornam-se mais atrativos ao usurio final. O enfoque em servios talvez seja a principal razo para a boa aceitao e utilizao das nuvens computacionais. Inspirado em servios comuns do cotidiano como, por exemplo, distribuio de energia eltrica ou servios de telefonia, este modelo visa proviso de servios computacionais sob demanda. Esta abordagem tira a responsabilidade das empresas em administrar servios bsicos de infraestrutura e servios, permitindo que estas despendam mais recursos no negcio propriamente dito. No modelo de Computao em Nuvem possvel oferecer, por exemplo, servios de armazenamento de dados sem que o cliente disponha de uma infraestrutura prpria dedicada. Portanto, tanto a infraestrutura quanto a interface da aplicao so disponibilizadas pela nuvem. Servios podem ser adaptados s necessidades do cliente, sem que este participe da instalao, configurao ou manuteno do produto. Alm disso, recursos, como mquinas virtuais, podem ser acessados pelo cliente em qualquer lugar, a qualquer momento, tambm sem a necessidade de envolvimento com o gerenciamento desta infraestrutura. Alm desta nova viso de como aplicaes e infraestrutura podem ser oferecidas em ambientes distribudos, outra razo para o sucesso das Nuvens Computacionais decorrente da evoluo tecnolgica. O uso de virtualizao associado a boas tcnicas de proviso de recursos permite um melhor aproveitamento dos recursos oferecidos, maior economia e flexibilidade na configurao de ambientes. O aumento da largura de banda e maiores taxas de transferncia de dados em redes de comunicao, assim como o aumento na capacidade

de processamento dos computadores atuais, oferece melhor desempenho, possibilitando ao provedor de servios garantir nveis de qualidade de servio compatveis aos requisitos dos usurios. Este trabalho relata um estudo sobre Computao em Nuvem, envolvendo conceitos, tecnologias existentes e os modelos de servio oferecidos. Alm de descrever a terminologia associada aos modelos de servio, tambm feito um detalhamento sobre mquinas virtuais e sua utilizao em Nuvens Computacionais. Alm disso, ser apresentada a Nuvem Computacional do C3 (Centro de Cincias Computacionais) da Universidade Federal do Rio Grande FURG, que foi implantada como parte deste trabalho. Finalizando este estudo, tambm so discutidas algumas aplicaes usuais no contexto das Nuvens Computacionais, que sero integradas futuramente Nuvem do C3. A prxima seo faz uma introduo sobre Nuvens Computacionais e seus conceitos. A Seo 3 apresenta mquinas virtuais e sua aplicao em computao em nuvem. A implementao de uma nuvem computacional descrita na Seo 4 e concluses e trabalhos futuros so discutidos na Seo 5. II. COMPUTAO EM NUVEM Embora a Computao em Nuvem esteja empregada na indstria e na academia, com modelos de servios e tecnologias j consolidados, este conceito ainda recente, no havendo consenso em sua definio. Segundo o National Institute of Standards and Technology (NIST) [5], Computao em Nuvem Um modelo que permite acessar, de maneira conveniente e sob demanda, recursos configurveis de computao (por exemplo, rede, servidores, armazenamento, aplicaes e servios) que podem ser rapidamente adquiridos e liberados com o mnimo de esforo de gerenciamento ou interao com o provedor dos servios. Um levantamento sobre definies e conceitos para Nuvem Computacional apresentado em [6]. Os autores descrevem mais de 20 definies para Computao em Nuvem e demonstram como este modelo evoluiu do modelo de grades computacionais. Neste trabalho ser adotada a viso do NIST, que aponta as seguintes caractersticas sobre computao em nuvem: compartilhamento de recursos; acesso aos recursos sob demanda; proviso destes recursos usando um modelo de servios; e facilidade em acessar e configurar servios oferecidos. Com relao ao provisionamento de recursos, diferentes tipos de recursos podem ser oferecidos. Desde aplicativos, plataformas para desenvolvimento, ou mesmo a disponibilizao de servidores ou desktops virtuais, tudo atravs da Internet. As prximas sees apresentam uma viso geral dos principais modelos de servios, de acordo com os tipos de recursos disponibilizados. Outros trabalhos tambm descrevem estes modelos de servios [7]-[8]-[9], assim como [10], que prope uma ampla taxonomia para os tipos de servios comumente oferecidos. A. SaaS (Software-as-a-Service)
Neste modelo de servio, aplicaes so executadas e hospedadas em uma Nuvem de uma organizao. Estas aplicaes so pagas por tempo de uso (pay-as-you-go) e no necessrio aquisio de uma cpia de uso. Toda a rea de gerenciamento da aplicao, como atualizaes, manuteno e monitoramento, ficam sob responsabilidade do provedor de servio. Esta abordagem evita que o usurio se envolva com aspectos tecnolgicos. Dessa forma, o cliente do servio far uso da aplicao com o foco apenas no negcio e no no gerenciamento de recursos e infraestrutura de sua organizao. Como exemplo, um editor de texto no modelo tradicional precisa de uma cpia para uso e sua respectiva licena para funcionar em um computador. O usurio adquire esta licena para uso 24h, 7 dias por semana, mesmo que no o utilize a noite ou nos finais de semana. Se ele tiver que trabalhar em casa para suprir o trabalho do escritrio e tiver que usar outro computador, precisar de uma segunda licena, aumentando gastos e inflexibilidade ao usurio. No modelo SaaS, esse problema resolvido, pois o usurio paga apenas pelo que usa e pode utilizar a mesma licena em qualquer lugar, a qualquer instante, bastando que o usurio tenha acesso um computador ligado Internet. Ferramentas corporativas, que antes exigiam investimento financeiro elevado e requisitos especficos de infraestrutura, como ferramentas para Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Business Process Management (BPM), encontram-se disponveis no modelo SaaS [11]-[12]-[13]-[14]. Dentre as vantagens deste modelo destacam-se o valor de investimento atrativo, alm de exigir pouca ou nenhuma mudana na infraestrutura da empresa. B. IaaS (Infrastructure-as-a-Service) Este modelo oferece infraestruturas virtuais para os clientes. Portanto, no necessrio que o cliente adquira mquinas fsicas, mas sim permitir que este acesse mquinas virtuais com as caractersticas desejveis. O cliente no tem controle sobre a infraestrutura em que a mquina reside, porm ele escolhe o sistema operacional, memria disponvel, ncleos de processamento, etc.. ainda permitido que ele utilize e instale aplicativos compatveis a configurao da mquina virtual por ele escolhida. A Seo 3 descreve o funcionamento das mquinas virtuais que, alm de serem usadas no modelo IaaS, tambm so utilizadas na construo da infraestrutura da nuvem em geral. Neste tipo de servio o cliente pagar um determinado valor por tempo de uso, sendo o custo depende das caractersticas da mquina virtual e/ou pelo nmero de instncias utilizadas. Se ele alugar uma mquina com alta capacidade de processamento e armazenamento de dados, pagar um valor mais alto do que para uma mquina inferior. Empresas podem ainda adquirir um nmero elevado de mquinas virtuais para cada perodo do ano, aumentando e diminuindo sua infraestrutura conforme a necessidade de seu negcio. Este modelo, alm de diminuir consideravelmente os gastos da empresa com hardware e suporte, tambm ocasiona economia

de energia e oferece melhor aproveitamento de espao fsico. C. PaaS (Plataform-as-a-Service) Este modelo de servio oferece ao usurio uma plataforma de desenvolvimento completa e remotamente hospedada na Nuvem. Taurion [15] define esta plataforma como uma plataforma para criao e teste de aplicaes. Neste modelo de servio so disponibilizadas ferramentas para desenvolvimento, administrao e gerenciamento, alm de servios de runtime. Portanto, possvel utilizar IDEs (Integration Development Toolkit), compiladores, ferramentas para gerenciamento e controle de verso ou ferramentas para teste de sistemas, incluindo teste automatizado ou teste de desempenho, por exemplo. PaaS pode ser dividido em dois tipos distintos, chamados PaaS aberto e PaaS fechado. O primeiro utiliza plataformas padro, mantendo compatibilidade com todos os outros PaaS abertos, o que possibilita a livre migrao. J o PaaS fechado, composto por plataforma nica ou proprietria, de impossvel migrao. A forma de cobrana deste servio varia de empresa para mpresa. Por exemplo, a empresa Heroku calcula o valor a ser cobrado atravs dos dynos, onde quatro dynos equivalem a um ncleo de CPU. Quanto mais dynos o cliente exige mais ele pagar. O cliente pode tambm aumentar a capacidade de seu ambiente de teste para aplicativos (Shared Database), pagando por este aumento de capacidade. Exemplos deste modelo de servio so o Google App Engine [16] e Aneka [17]. A Figura 1 ilustra o funcionamento geral de uma nuvem computacional e as atividades de um provedor de servios em nuvem. Provedores so capazes de implantar novos servios (SaaS, IaaS ou PaaS) e torn-los acessveis aos clientes atravs da Internet. O gerenciamento da infraestrutura fsica na qual estes servios esto alocados de responsabilidade do provedor de servio, que deve fazer sua manuteno e proviso de recursos, de modo a garantir nveis de qualidade de servio estipulados em contrato. Os clientes, uma vez que tenham contrato de servios com o provedor, acessam a infraestrutura da nuvem usufruindo dos servios oferecidos.
3
se faz necessrio a utilizao de nveis mais rigorosos de privacidade. Nesse caso, toda a infraestrutura de Nuvem montada para um pblico restrito, no sendo oferecidos servios ao mercado em geral. 2. Nuvem Pblica: Infraestrutura criada para o pblico em geral ou grandes grupos industriais, normalmente utilizado por empresas que fornecem SaaS. 3. Nuvem Hbrida: Infraestrutura formada por no mnimo duas nuvens, uma pblica e outra privada. Este modelo apresenta o benefcio da utilizao de recursos disponveis em nuvens pblicas, ao mesmo tempo em que se beneficia da segurana das nuvens privadas. 4. Nuvem Comunitria: Infraestrutura formada por uma Nuvem privada e compartilhada, onde h troca de informaes, dados, pesquisas, etc. Normalmente utilizada por grupos com o mesmo objetivo, como, por exemplo, uma infraestrutura de nuvem compartilhada entre universidades. Esta Nuvem pode ser administrada por uma das organizaes do grupo ou por uma organizao fora dele responsvel apenas por administr-la. A Figura 2 ilustra a poltica de administrao de nuvens comunitrias com administrao feita por provedor externo ou interno ao grupo que compe a nuvem.
Nuvem Comunitria Provedor Externo Provedor Interno
Universidade 1 Universidade N Universidade 2
Universidade 1 Universidade N Universidade 2
Universidade 7
Universidade 3
Provedor/Administrador da Nuvem
Universidade 3
Universidade 6
Universidade 4
Universidade 6
Universidade 4
Universidade 5
Universidade 5
Entrada
Entrada
Provedor/Administrador da Nuvem
Fig. 2. Nuvem Comunitria com administrao interna e externa
Clientes
Provedor Gerenciamento
Acesso e Gerenciamento Sistema Operacional Servios Plataforma de Desenvolvimento
Apenas Acesso Aplicaes
Nveis de Acordo de Servio
IaaS
Infraestrutura VM 11 Aplicati VM VM 1
vos
PaaS
VM 11 Aplicati VM VM 1
vos
SaaS
VM 11 Aplicati VM VM 1
vos
Implantao
... VM n
... VM n ...
... VM n
Manuteno Monitoramento
Hardware 1
Hardware 2
Hardware n
Fig. 1. Nuvem Computacional
Com relao implementao, as Nuvens Computacionais tambm podem ser divididas em: 1. Nuvem Privada: Infraestrutura utilizada exclusivamente por uma ou mais empresas ou agncias governamentais, onde
D. Tecnologias para Computao em Nuvem Esta seo discute tecnologias relacionadas implementao de infraestruturas e servios para computao em nuvem. Empresas como a Amazon, Google e Microsoft, tm suas prprias infraestruturas de nuvem computacional, oferecendo servios ao mercado. 1. Amazon Web Services - AWS A Amazon, uma das empresas pioneiras em IaaS, oferece atualmente o conjunto de servios Amazon Web Services (AWS). Dentro deste conjunto de servios encontram-se servios conhecidos como Amazon Simple Storage Service (S3), que fornece um ambiente virtual na Web para armazenamento ilimitado de qualquer tipo de dados e recuperao dos mesmos. O dado armazenado pode variar de 1 byte a 5 GB e seu local de armazenamento pode ser definido como um sistema de pastas e subpastas acessveis pelos sistemas operacionais atuais. Este ambiente pode ser coletivo ou individual, sendo possvel configurar restries de acesso para cada objeto armazenado no S3 [18]-[19]. O Amazon

Elastic Compute Cloud (EC2) outro servio Web oferecido dentro do AWS. Basicamente ele disponibiliza mquinas virtuais baseadas no sistema operacional Linux. Este servio garante total flexibilidade infraestrutura do usurio, permitindo que aumento ou reduo da capacidade de computao baseado na sua demanda. Se for necessrio aumentar temporariamente a capacidade de computao, podese ativar instncias virtuais rapidamente e aps o uso exclulas. Dentro do AWS existem outros servios como Amazon SimpleDB (SDB), Amazon Simple Queue Service (SQS), Amazon Virtual Private Cloud (VPC) [20]- [9]. 2. Google Application Engine A empresa Google disponibiliza servios PaaS, atravs da plataforma de desenvolvimento Web Google Application Engine ou App Engine. Nesta plataforma, possvel criar aplicaes Web utilizando a nuvem da Google, que possui ambientes para desenvolvimento Java, Python e Go. Alm disso, a App Engine foi projetada para ser independente de linguagem de programao, ento futuramente ter compatibilidade com outras linguagens de programao. Este servio oferece um sistema de armazenamento chamado Datastore, baseado em uma estrutura escalvel de armazenamento de dados definida por BigTable, ambos desenvolvidos pela Google [20]. 3. Azure A Microsoft entrou no mercado com o Windows Azure, o PaaS da Microsoft, uma plataforma de servios projetada como ambiente de desenvolvimento e hospedagem de servios e aplicaes Web. Esta plataforma possibilita ao seu utilizador criar aplicaes baseados em .NET com as ferramentas do Azure e armazen-las na nuvem da Microsoft. Com o Azure, tambm possvel programar em C#, C++, PHP e outras linguagens suportados pela plataforma .NET. O Windows Azure fornece um conjunto de servios para seus usurios, sendo os mais utilizados: a) Windows Azure AppFabric: um middleware para desenvolvimento, implementao e controle de aplicaes dentro do Windows Azure. Junto a esta plataforma so disponibilizadas outras ferramentas para auxiliar o programador a desenvolver seus aplicativos: H servios orientados mensagens baseado em Service Bus, garantindo persistncia e fcil distribuio de mensagens; Controle de acesso plataforma, o Access Control, para desenvolvimento em equipe, e o Caching para cache de dados em memria e outros componentes para integrao de sistemas e automatizao do desenvolvimento. b) SQL Azure: um Sistema Gerenciador de Banco de Dados relacional baseado no Windows Server e no SQL Server. Ele oferece a escalabilidade e funcionalidades de um Datacenter flexvel, pois consegue lidar com diferentes tipos de carga. Ele tambm dimensiona e particiona os dados, enquanto seus dados crescem. Todo o gerenciamento e instalao so de responsabilidade da Microsoft. c) Windows Azure Storage Service: o servio de armazenamento nas nuvens (Bancos de Dados da Microsoft) oferecido pelo Azure, seus dados podem ser armazenados de quatro formas: Binary Large Objects (BLOBs) que armazena
4
dados binrios como arquivos ou imagens; Queues que armazena filas de mensagens, usadas para troca de informao entre os servios do Azure; Tables que armazena informao estruturada com alta disponibilidade e escalabilidade; e Windows Azure Drive que funcionam como discos locais e nele que esto armazenados os BLOBs. 4. MapReduce/Hadoop Um servio muito conhecido de nuvem computacional o MapReduce, um modelo de programao e framework desenvolvido pelo Google, para facilitar o processamento e manipulao de grandes volumes de dados de forma paralela e/ou distribuda em aglomerados. O sistema controla as operaes de tolerncia a falha, balanceamento de carga e escalonamento de I/O permitindo ao usurio abstrao de concorrncia com alta disponibilidade. O MapReduce processa dados em duas etapas bsicas: a primeira, chamada de Map ou Mapeamento, gera um conjunto intermedirio de pares chave/valor da cada entrada de dados (a forma deste conjunto definida pelo usurio) antes de passar para segunda etapa. O framework ordena os conjuntos de pares pelas chaves e agrupa todos os valores de mesma chave em um par, criando um novo conjunto intermedirio de pares chave (lista de valores). Em seguida executada a segunda etapa, Reduce ou Reduo. Nesta etapa, cada novo par intermedirio processar todos os valores de uma mesma chave e gerar um novo conjunto final de pares chave/valor. Em resumo, na etapa de Mapeamento so encontrados dados que, depois de ordenados pelo framework, so indexados e os resultados agrupados. Hoje existem diversas implementaes baseadas em MapReduce, como: Disco, Skynet, FileMap, Greenplum e, em especial, Hadoop um framework open source desenvolvido em linguagem Java que permite a criao de aplicaes distribudas no modelo MapReduce. Essas aplicaes so utilizadas para processar grandes volumes de dados em ambientes "clusterizados", o Hadoop pode armazenar e processar petabytes de informao facilmente, pois ele distribui dados e processamento atravs de clusters automaticamente. O Hadoop tem um sistema de arquivos distribudo prprio, o Hadoop Distributed File System (HDFS). Este separa os arquivos de uma entrada em blocos de dados e os divide entre os nodos do cluster criando um ambiente de execuo paralela. Para maior segurana, o HDFS cria cpias idnticas dos blocos de arquivos de cada nodo em outros nodos, como meio de recuperar blocos de dados caso na ocorrncia de falhas. 5. Eucalyptus Para fins de pesquisa, h interesse em estudar desempenho, segurana e confiabilidade do modelo de Computao em Nuvem, no bastando, portanto, utilizar infraestrutura e servios disponveis no mercado. Neste contexto que se destaca o Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems ou Eucalyptus [21]-[22], desenvolvido pela Universidade da Califrnia e comercializado atualmente como Eucalyptus Systems Inc. O Eucalyptus um software gratuito de cdigo aberto, que permite criar nuvens pblicas ou privadas, sendo compatvel

com o API da Amazon, EC2 API, permitindo fcil migrao de seus aplicativos de uma nuvem para outra. Esse software , atualmente, uma boa soluo de Computao em Nuvem privada para clientes VMware, suportando tambm outros gerenciadores de mquinas virtuais, como Xen e KVM. Em [21]-[22] apresentada sua arquitetura, composta por cinco componentes: a) Node Controller ou Controlador de N (NC): Executa em todos os nodos da nuvem, ou seja, mquinas fsicas da nuvem que hospedaro as mquinas virtuais. Este controlador responsvel pelo gerenciamento das mquinas virtuais (VMs Virtual Machines), podendo iniciar, parar e colher informaes sobre as VMs. O NC subordinado ao Controlador de Cluster (CC), portanto, para acess-lo necessrio faz-lo por intermdio do CC. b) Cluster Controller ou Controlador de Cluster (CC): responsvel por gerar as solicitaes de execuo das VMs. A partir de requisies aos NC ele recolhe dados sobre as VMs de um Cluster ou rede privada. Ele tambm responsvel pelo escalonamento das requisies de instanciao das mquinas virtuais entre os NC e balanceamento de carga. este componente que decide em qual NC ser melhor atribuir uma tarefa especfica, tomando essa deciso baseado em dados coletados sobre requisies e carga dos nodos. Dentro de uma nuvem podem existir mltiplos Controladores de Clusters. c) Storage Controller ou Controlador de Armazenamento (SC): um bloco de armazenamento elstico mais interno do sistema. neste mdulo que so armazenados os dados dos Nodos em volumes. O SC compatvel com EC2, podendo ser utilizado como bloco de armazenamento. Sua utilizao permite a persistncia de dados nas instncias do Eucalyptus. d) Walrus (W): Walrus um componente de armazenamento do tipo put/get que utiliza tecnologias de Web Services. Ele possui interface com usurio compatvel com a API Amazon Simple Storage Service (Amazon S3), sendo possvel inserir e retirar dados do Walrus. O Walrus armazena dados dos usurios e tambm imagens de VMs. e) Cloud Controller ou Controlador de Nuvem (CLC): Este o nico componente da arquitetura que usurios possuem acesso direto a partir da Internet. Ele responsvel por atender requisies referentes manipulao de mquinas virtuais e fornecimento de informaes sobre o estado das VMs. Para obter estas informaes, o CLC comunica-se diretamente com o CC. O CLC controla tambm o armazenamento de dados dos usurios e do sistema ( Walrus), possibilitando ao usurio e/ou administrador obterem informaes sobre os recursos disponveis e o estado atual do sistema. dentro do CLC que esto s interfaces para usurios e administradores, normalmente implementadas em SOAP, Query ou Web, tornando mais simples o uso e a viso da Nuvem. A Figura 3 mostra uma possvel estrutura de Nuvem Eucalyptus. Os elementos da arquitetura podem compartilhar um mesmo servidor ou encontrarem-se dispostos separadamente. Como exemplo, veja o SC e o CC no Cluster 1 e no Cluster 2. Esses elementos podem ser organizados na infraestrutura de diferentes maneiras. O SC e CC podem estar localizados em uma mesma mquina fsica ou podem estar em
5
mquinas independentes. No entanto, para se obter uma melhor escalabilidade e desempenho, recomendada maior distribuio entre os elementos da arquitetura. Outro aspecto importante a homogeneidade do hardware empregado nos nodos de processamento de cada cluster.
Arquitetura Eucalyptus WEB SOAP QUERY
CLC Database
SC
CC
CC SC
NC NC NC
NC NC NC
NC NC NC
NC NC NC
NC NC NC
NC NC NC
Cluster 1
Cluster 2
Fig. 3. Arquitetura do Eucalyptus
III. MQUINAS VIRTUAIS A. Caractersticas Bsicas Virtualizao de servidores refere-se aplicao de tcnicas que permitem o particionamento de recursos de servidores fsicos entre vrios sistemas operacionais que executam concomitantemente em uma mesma mquina fsica. A disponibilizao de parte desses recursos feita atravs do uso de Mquinas Virtuais (VMs - Virtual Machines) que, atravs de uma instncia de um SO (Sistema Operacional), so capazes de acessar os recursos fsicos do computador de modo transparente ao usurio. Portanto, esta definida como uma duplicata isolada e eficiente de uma mquina real [23]. Em ambientes virtualizados, alm da presena do SO que executado diretamente sobre hardware fsico (SO hospedeiro), VMs e SOs executados sobre hardwares virtuais (SOs hspedes ou visitantes), existe o monitor de mquinas virtuais (VMM - Virtual Machine Monitor) [24]. O VMM, tambm conhecido por Hypervisor, responsvel pelo gerenciamento e controle dos recursos compartilhados pela mquina fsica (por exemplo, processador, memria, disco rgido e dispositivos de E/S). Em outras palavras, o VMM implementa uma camada de software com o encargo de fazer o escalonamento e o tratamento de instrues destas VMs. Tambm responsabilidade do VMM fornecer ao SO visitante a abstrao de VM [25]. A Figura 4 representa uma possvel disposio dos elementos descritos.

VM 1 VM VM11
Aplicativos Aplicativos Aplicativos SO Hspede SO SOHspede Hspede
6
A paravirtualizao, diferentemente da virtualizao total, necessita que os SOs hspedes tenham o cdigo fonte alterado. Essa alterao feita para que os SOs hspedes faam chamadas de hypervisor ao invs de executarem instrues sensveis. Assim, dito que o SO hspede possui cincia de estar sendo executado sobre uma VM. B. Principais VMMs Existentes Existem diversas solues em software disponveis para distribuies Linux ou Windows, que provm suporte a virtualizao de servidores. Porm, nem todas so baseadas na virtualizao total e/ou paravirtualizao. H outros tipos de virtualizao: emulao (ou simulao) e virtualizao em nvel de sistema operacional. Tambm importante salientar que a emulao no considerada como um tipo de virtualizao por alguns autores [27]. Sero apresentadas nesta seo as principais ferramentas de virtualizao em uso atualmente. 1. VMware Infraestrutura de virtualizao que oferece diversas aplicaes para suporte a ambientes virtualizados. A maioria so aplicaes comerciais, sendo algumas gratuitas, com recursos reduzidos. A abordagem empregada na virtualizao de servidores nos produtos VMware a virtualizao total. Os produtos gratuitos existentes que realizam essa tcnica so: VMware vSphere Hypervisor e VMware Server. O primeiro executa diretamente sobre o hardware, sendo este um SO hospedeiro com hypervisor tipo 1. J o segundo instalado como aplicao no SO hospedeiro, ou seja, um hypervisor tipo 2. Em se tratando de produtos da VMware, comum a utilizao dos termos bare metal e hosted para se designarem respectivamente os tipos 1 e 2 de hypervisors. O SO hospedeiro quem fornece o suporte aos dispositivos atravs do VMDriver. Estas diferenas entre as duas tecnologias podem ser observada nas Figuras 5 e 6.
VM 1 VM VM11
Aplicativos Aplicativos Aplicativos SO Hspede SO Hspede SO Hspede
... VM n
Aplicativos SO Hspede
SO Hospedeiro
Hypervisor Hardware
Fig. 4. Modelo de virtualizao hbrida.
Atualmente, possvel encontrar diferentes abordagens na implementao de virtualizao de servidores, as principais so: virtualizao total e paravirtualizao. O que essencialmente as difere a maneira na qual os Hypervisors tratam a execuo de instruo sensvel por SOs visitantes. Assim chamada por Popek e Goldberg em 1974 [23], instruo sensvel so todas as instrues que executam apenas em modo supervisrio, como por exemplo: instrues que modificam ou lem o estado de registradores; e instrues de comunicao com dispositivos (ex. instrues que geram interrupes de E/S). Esses pesquisadores tambm propuseram o conceito de instruo privilegiada, instrues que so capturadas por armadilha (trap) em programas executando no modo usurio. Estas armadilhas indicam ao SO qual interrupo deve ser executada em modo supervisrio, permitindo que interrupes sejam geradas no modo usurio, porm tratadas posteriormente pelo sistema operacional em modo privilegiado. A virtualizao total pode ser implementada de duas maneiras. A mais atual utiliza hypervisor tipo 1, desenvolvido para CPUs com arquitetura x86 estendida com suporte a virtualizao. J para CPUs 386 e sucessoras, sem tal suporte, usa-se o hypervisor tipo 2. Em ambas as implementaes, as VMs executam em modo usurio e os SOs hspedes em modo supervisrio. A unio dessas duas caractersticas acarreta na execuo de instruo sensvel em modo usurio. Isso poderia ser um problema, pois, se no houvesse nenhum tipo de tratamento, estas falhariam e o SO hspede pararia de funcionar. Cada um dos hypervisors possui um comportamento prprio ao lidar com essa situao. Estes comportamentos so conhecidos por: captura e emulao (trap-and-emulate) ou traduo binria [26]. Com a utilizao do hypervisor tipo 1, ocorrer trap-andemulate. Em hardware com suporte a virtualizao, existe uma armadilha a espera de instruo sensvel executada em modo usurio. Quando a armadilha captura alguma instruo com esse perfil, o hypervisor inspeciona a origem da instruo capturada. Caso esta tenha sido executada por algum SO hspede, o hypervisor executar a instruo. Caso contrrio, o hypervisor emula a tomada de deciso que o hardware teria ao se deparar com uma instruo sensvel executada em modo usurio por um processo qualquer. A traduo binria, feita por hypervisors tipo 2, varre o cdigo binrio de execues em busca de instrues sensveis. Quando alguma encontrada, esta substituda por uma chamada a uma rotina de hypervisor, que, por sua vez, ir executar a instruo e simular a execuo ao SO hspede. As demais instrues so executadas diretamente no hardware.
... VM n
VMware vSphere Hypervisor
Hardware
Fig 5. VMware vSphere Hypervisor: virtualizao total, hypervisor tipo 1
VM 1 VM VM11
Aplicativos Aplicativos Aplicativos SO Hspede SO SOHspede Hspede
... VM n
VMware Server SO Hospedeiro Hardware

Fig. 6. VMware Server: virtualizao total, hypervisor tipo 2

2. Xen Hypervisor Software de cdigo aberto sob licena GPL2 (GNU General Public License), com suporte a paravirtualizao e virtualizao total (hypervisor tipo 1). Essa ferramenta faz distino entre os SOs hspedes totalmente virtualizados e paravirtualizados, nomeando-os respectivamente de Domain U PV Guests (PV - Paravirtualizion) e Domain U HVM Guests (HVM - Hardware Virtual Machine). Os domnios U (domU) so chamados de no-privilegiados. Divergindo ao conceito de SO hospedeiro, existe um domnio privilegiado, formalmente conhecido por Domain 0 Guest (dom0). Conforme sugere o nome dos domnios, apenas existem SOs virtualizados (hspedes) em ambientes com a presena do Xen Hypervisor. Alm das diferenas j discutidas quanto aos tipos de virtualizao, para entender o funcionamento dessa tecnologia fundamental saber a diferena de domnio privilegiado (domnio 0) e domnios no-privilegiados (domnios U) [28]. O domnio 0 assim como os demais PV Guests, necessita de um ncleo modificado. O que o faz privilegiado a possibilidade de acesso direto ao hardware. Isso possvel atravs dos drivers fsicos de dispositivos de entrada/sada existentes nele. Tambm se encontram presentes drivers especiais que tratam requisies provenientes das VMs dos domnios U para acesso a rede e disco. A VM do domnio 0 sempre a primeira a ser executada pelo hypervisor, pois, em adio s caractersticas recm descritas, o domnio 0 possui carter administrativo. atravs dele que so criadas, inicializadas e terminadas as outras VMs. Diferente dos PV Guests, HVM Guests no possuem drivers virtuais que interagem com os drivers especiais presentes no domnio 0. Essa ausncia devido ao fato de que os HVM Guests no foram modificados. Por esse motivo, os SOs que compe esses domnios comportam-se da mesma maneira que se comportariam caso fossem executados sobre mquina fsica. Cabe ao Xen virtual firmware simular a existncia da BIOS (Basic Input/Output System) e ao QEMU emular o hardware disponvel para as VMs dos HVM Guests [29]. Veja na Figura 7 algumas vias de interao entre o Xen Hypervisor e seus domnios PV.
VM (dom0) Aplicativos de Gerenciamento SO Modificado Drivers Reais
Gerenciamento de CPU e Memria
7
Ubuntu e Red Hat Enterprise Linux que outrora davam suporte ao Xen Hypervisor, voltaram-se para adoo do KVM como principal VMM. Assim como VMware e Xen, o KVM capaz de efetuar Live Migration. Essa caracterstica permite a transferncia de uma mquina virtual em execuo para outro servidor hospedeiro, sem que haja o desligamento ou perda de informaes do estado atual da VM. Portanto, possvel efetuar manuteno de infraestrutura ou balanceamento de carga em servidores hospedeiros sem interrupo de execuo. C. Hypervisors em Nuvens Grandes empresas que oferecem servios em nuvem computacional possuem hypervisors prprios para a virtualizao da infraestrutura. A implementao desses hypervisors visam extrair o melhor aproveitamento do tipo especfico de suas infraestruturas computacionais. A empresa Amazon utiliza o Xen Hypervisor com alteraes personalizadas no cdigo fonte. O Windows Azure utiliza o Wazure Hypervisor, soluo no comercial, baseada em uma soluo fornecida pela prpria empresa, o Hyper-V.
IV. IMPLEMENTAO DE UMA NUVEM A. Infraestrutura Disponvel Atualmente o C3 possui um ambiente de teste exclusivo para estudos de computao em nuvem e computao de alto desempenho. A infraestrutura para implantao de nuvem computacional composta por trs servidores Dell PowerEdge T300 e um switch. Cada servidor possui processadores Intel Xeon com quatro ncleos X3363 - 2,83GHz, 8GB de memria RAM DDR2, 1TB em disco rgido e quatro interfaces de rede padro Gigabit Ethernet. A seguir so apresentados alguns aspectos referentes implementao da nuvem, seu gerenciamento e servios oferecidos. A documentao completa com as instrues de instalao e configurao esto disponveis em [30]. B. Softwares Utilizados e Instalao Como sistema operacional utilizou-se o Ubuntu Server verso 11.04. Os demais softwares para a implantao da nuvem computacional foram o Eucalyptus e o KVM. A instalao dos componentes do Eucalyptus foi distribuda da seguinte maneira: Cloud Controller e Walrus, assim como o Storage Controller e Cluster Controller instalados em um mesmo servidor; o Node Controller foi configurado em um terceiro servidor. A Figura 8 mostra a disposio da infraestrutura da nuvem e sua rede interna.
PV VM 1 VM VM(domU (domUPV) PV)

Aplicativos Aplicativos Aplicativos SO Modificado SO SOModificado Modificado
Drivers Virtuais Drivers Virtuais Drivers Virtuais
... PV VM n
Aplicativos SO Modificado
Drivers Virtuais
HVM 1 VM VM11
Aplicativos Aplicativos Aplicativos SO Hspede SO Hspede SO Hspede
... HVM n
Virtual firmware QEMU
Xen Hypervisor
Dispositivos de E/S
Hardware
Fig. 7. Componentes do Xen, hypervisor e domnios [29]
3. KVM Kernel-based Virtual Machine, software de cdigo aberto para o suporte a virtualizao total, possui hypervisor tipo 1. Esse software foi concebido para executar instncias de servidores virtualizados sem interface grfica. Nos ltimos anos o KVM alcanou boa parte do mercado de virtualizao de servidores para distribuies Linux. Distribuies como

Administrador Usurios
8
D. Servios Oferecidos Sero apresentados nesta seo alguns servios a serem implementados na nuvem computacional do C3. Estes servios tm por objetivo atender demandas de ampliao de infraestrutura, de processamento de dados, alm de propor aplicaes especficas para a instituio, para suporte s atividades de ensino, pesquisa e extenso. Mesmo que a universidade no vise lucro com a prestao de servios, ainda assim obtm-se benefcios em manter infraestrutura de servios e infraestrutura em nuvem computacional. Por exemplo, o consumo de energia e gastos com infraestrutura de hardware deve reduzir, visto que vrios servidores podem executar em instncias virtuais, no havendo necessidade em execut-los em infraestrutura fsica dedicada. Alm disso, esperado que o tempo para configurao e manuteno de servios e servidores seja diminudo, aumentando a disponibilidade e manutenibilidade da infraestrutura. 1. Servios para Centro de Processamento de Dados Diversos servios comuns em CPDs (Centros de Processamento de Dados) apresentam uma demanda significativa de hardware. Com a utilizao de uma nuvem computacional, possvel designar um conjunto de mquinas virtuais para execuo de servidores de e-mail, sistema de arquivos remotos, servidores de ftp, etc. Com este modelo est prevista uma diminuio nos custos com hardware e consumo de energia, sem comprometer a qualidade dos servios oferecidos. O modelo de computao em nuvem prov o gerenciamento destes recursos e a possibilidade de migrao de mquinas virtuais para outros nodos computacionais, alm de rpida recuperao de configuraes pr-definidas, no caso de necessitar reparos. 2. Repositrios de Dados Pretendem-se utilizar servios da nuvem para controle e acesso dos dados na nuvem. Dados de um usurio podero ser transferidos a qualquer momento para a nuvem, de qualquer dispositivo com acesso a interface desta aplicao. Desta forma, a facilidade de acesso e disponibilidade de dados deve ser incrementada. Sistemas de controle de verso, middleware orientados a mensagem, e tcnicas de replicao de dados e tolerncia a falhas, devem fazer parte da soluo proposta. Alm disso, para aumentar a acessibilidade dos dados por diversos dispositivos, pretende-se montar uma arquitetura orientada a servios capaz de atender requisies provenientes dos mais diversos dispositivos, como computadores pessoais, dispositivos mveis, etc. 3. Pool de Aplicaes Em uma nuvem computacional possvel disponibilizar uma variedade de aplicaes com acesso sob demanda. Portanto, o usurio poder escolher, dentre um conjunto de aplicaes oferecidas pela nuvem, quais ele quer usar sem se preocupar com a localizao ou configurao da aplicao. Como exemplos podem ser citados aplicativos para gerncia de tarefas, agendas pessoal ou global, fruns, gerncia e edio de sites, entre outras.
Cloud Controller Walrus
Internet
Switch
Cluster Controller Storage Controler Node Controller

Fig. 8. Infraestrutura da nuvem computacional do C3
Nesta infraestrutura apenas o Cloud Controller e o Walrus tem acesso direto a rede externa, os demais componentes so acessados indiretamente pelo repasse de pacotes, ou seja, o 1 o servidor (CLC/W) faz o roteamento dos pacotes para o 2 o servidor (CC/SC) que, por sua vez, faz o roteamento para o 3 o servidor (NC). C. Gerenciamento A administrao da nuvem feita remotamente. O controle pode ser feito atravs de interfaces grficas como Hybridfox e Eucalyptus Web User Interface, ou pelo prprio terminal. Todas as formas usam direta ou indiretamente os comandos providos pela ferramenta euca2ools, que um conjunto de ferramentas fundamental para o controle e gerenciamento da nuvem. Por exemplo, com o euca2ools possvel criar e manipular VMs, instncias virtuais, volumes e snapshots (gerenciador de backup de volumes). A Tabela 1 mostra as combinaes de VM que podem ser disponibilizadas pela Nuvem do C3. Cabe ressaltar, que estes tipos so configurveis de acordo com a necessidade dos utilizadores da nuvem, porm podem ser alterados apenas usurios administradores da nuvem.
Table I Variables to be considered on the evaluation of interaction techniques
Tipo de VM m1.small c1.medium m1.large m1.xlarge c1.xlarge
CPUs 1 1 2 2 4
Memria 192 MB 256 MB 512 MB 1024 MB 2048 MB
Disco 2 GB 5 GB 10 GB 20 GB 20 GB

4. Pool de Recursos De forma similar ao pool de aplicaes, a nuvem tambm oferecer um pool de recursos. O usurio poder solicitar mquinas virtuais com configuraes especficas e ento trabalhar na instncia solicitada. Esta abordagem comum no processo de desenvolvimento de software, por exemplo, nas atividades de teste de sistema. Uma equipe de testes pode verificar a compatibilidade dos sistemas desenvolvidos em ambientes com diferentes configuraes de hardware ou ainda com diferentes sistemas operacionais.
9
Implications, in: IEEE/ACM International Conference on Grid Computing, 7th, IEEE Computer Society, 2006. J. A. Stankovic, A perspective on distributed computer systems, Computers, IEEE Transactions on, C-33, vol. 12, pp. 11021115, 1984. P. Mell, and T. Grance. (2009). The NIST Definition of Cloud Computing. National Institute of Standards and Technology. [Online] Gaithersburg: National Institute of Standards and Technology. Disponvel em: http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909616. L. M. Vaquero, L. R. Merino, J. Caceres, and M. Lindner, A Break in the Clouds: Towards a Cloud Definition, ACM SIGCOMM Computer Communication Review, vol. 39, no. 1, pp. 5055, 2008. A. Lenk, M. Klems, J. Nimis, S. Tai, and T. Sandholm, Whats In side the Cloud? An Architectural Map of the Cloud Landscape, in: ICSE Workshop on Software Engineering Challenges of Cloud Computing, CLOUD 09, IEEE Computer Society: 2009. F. R. C. Sousa, L. O. Moreira, and J. C. Machado, Computao em Nuvem: Conceitos, Tecnologias, Aplicaes e Desafios, in: ERCEMAPI 2009, SBC: 2009. J. Varia, Cloud Architectures. Amazon, 2008. Disponvel em: http://jineshvaria.s3.amazonaws.com/ public/cloudarchitecturesvaria.pdf. B. P. Rimal, E. Choi, and I. Lumb, A Taxonomy and Survey of Cloud Computing Systems, in: International Joint Conference on INC, IMS and IDC, 5th, NCM: 2009. Acumatica. Acumatica Cloud ERP Software. Disponvel em: http://www.acumatica.com/. Appian. Appian Cloud BPM. Disponvel em: http://www.appian.com/. Netsuite. NetSuite ERP Cloud. Disponvel em: http://www.netsuite.com. Salesforce. SalesForce Social Enterprise. Disponvel em: http://www.salesforce.com/br/?ir=1. C. Taurion, Cloud Computing: Computao em Nuvem: Transformando o Mundo da Tecnologia da Informao. So Paulo: Brasport, 2009. Google. Google App Engine. Disponvel em: http://code.google.com. X. Chu, K. Nadiminti, C. Jin, S. Venugopal, and R. Buyya. Aneka: Next-Generation Enterprise Grid Platform for e-Science and e-Business Applications. In: IEEE International Conference on e-Science and Grid Computing, 3th, 2007. M. Ambrust, A. Fox, R. Griffith, A. D. Joseph, R. H. Katz, A. Konwinski, G. Lee, D. A. Patterson, A. Rabkin, and M. Zaharia. View of Cloud Computing. Communications of the ACM, vol. 4, pp. 5058, 2010. M. R. Palankar, A. Iamnitchi, M. Ripeanu, and S. Garfinkel, Amazon S3 for Science Grids: a Viable Solution? in: International Workshop on Data-Aware Distributed Computing, DADC 08, 2008. M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. H. Katz, A. Konwinski, G. Lee, D. A. Patterson, A. Rabkin, and M. Zaharia. (2009, Maio). Above the Clouds: A Berkeley View of Cloud Computing. Berkeley University of California. [Online]. Disponvel em: http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf. Acessado em: 02/04/2012. S. Liu, Y. Liang, and M. Brooks, Eucalyptus: a Web Service-Enabled e-Infrastructure, in: Conference of the Center for Advanced Studies on Collaborative Research, CASCON 07, IBM: 2007. D. Nurmi, R. Wolski, C. Grzegorczyk, G. Obertelli, S. Soman, L. Youseff, and D. Zagorodnov. The Eucalyptus Open -Source CloudComputing System, in: IEEE/ACM International Symposium on Cluster Computing and the Grid, 9th, 2009. G. J. Popek, and R. P. Goldberg, Formal Requirements for Virtualizable Third Generation Architectures. Communications of the ACM, vol. 7, pp. 412421, 1974. J. E. Smith, and R. Nair, An overview of virtual machine architectures. Binghamton: Binghamton University, 2004.Disponvel em: http://www.cs.binghamton.edu/ ~kchiu/cs552-f04/papers/smith-04.pdf. D. M. F. Mattos. (2008). Virtualizao: Vmware e xen. [Online] Disponvel em: http://www.gta.ufrj.br/grad/ 08_1/virtual/artigo.pdf. A. S. Tanenbaum, Sistemas Operacionais Modernos. SP: Pearson, 2009.
[4] [5]
[6]
[7]
V. CONCLUSO E TRABALHOS FUTUROS Este artigo apresentou um estudo sobre infraestruturas usadas na construo de nuvens computacionais. A definio de nuvem computacional, assim como os conceitos relacionados a este modelo de computao foram destacados, juntamente com a descrio de algumas ferramentas de suporte a nuvem e mquinas virtuais. Foi feita uma anlise dos principais tipos de servios oferecidos por nuvens computacionais, com a finalidade de mostrar ao leitor o potencial destas infraestruturas em ambientes corporativos e acadmicos. Para ilustrar um estudo de caso real, foi discutida a implementao de uma nuvem computacional no C3 da universidade FURG. Foram descritos o hardware utilizado, ferramentas de controle da nuvem e de gerenciamento de recursos virtuais. Uma das contribuies deste artigo dar subsdios ao leitor, permitindo que esta infraestrutura possa ser reproduzida. Aps a implantao da nuvem computacional em nosso centro, vislumbramos a implementao de uma srie de servios. Tais servios foram listados e detalhados ao longo deste artigo. A implementao destes servios ser feita em trabalhos futuros, bem como a avaliao dos benefcios que estes venham a trazer. Como trabalhos futuros, alm da implementao de novos servios, pretende-se pesquisar tcnicas de monitoramento e gerenciamento de recursos, utilizando a infraestrutura da nuvem do C3. Portanto, iremos avaliar como identificar, em tempo de execuo, o desempenho das mquinas virtuais ativas. Baseado nos dados de monitoramento sero propostas tcnicas preventivas para minimizar os efeitos de degradao de desempenho que certas aplicaes podem ocasionar. Esta anlise est relacionada verificao de nveis de acordo de servio e qualidade de servios com cargas de trabalho variveis. REFERNCIAS
[1] F. Cappello, S. Djilali, G. Fedak, T. Herault, F. Magniette, V. Nri, and O. Lodygensky, Computing on Large-Scale Distributed Systems: XtremWeb Architecture, Programming Models, Security, Tests and Convergence with Grid, Future Generation Computer Systems, vol. 3, pp. 417437, 2005. G. Coulouris, J. Dollimore, and T. Kindberg, Distributed Systems Concepts and Design. Boston: Addison Wesley, 1994. A. Iosup, C. Dumitrescu, D. Epema, H. Li, H. and L. Wolters. How are Real Grids Used? The Analysis of Four Grid Traces and its [8]
[9]
[10]
[11] [12] [13] [14] [15]
[16] [17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25] [26]
[2] [3]

[27] D. B. Gonalves, J. C. J. Vahl, White paper virtualizao. Campinas: Polis de Tcnologia, 2008. Disponvel em: http://www.sensedia.com/br/anexos/ wp_virtualizacao.pdf. [28] P. Barham, P. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, and A. Warfield, Xen and the art of virtualization, in: ACM Symposium on Operating Systems Principles. 2003 SOSP '03. [29] A. Carissimi. Virtualizao: da teoria a solues, in: Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos (SBRC), SBC: 2008. [30] Relatrio Tcnico 2012/01: Instalao de Nuvem Computacional utilizando o Eucalyptus, C3, Centro de Cincias Computacionais. 2012. Disponvel em: http://www.hpc.c3.furg.br/arquivos/download/rt-201201-instalacao-eucalyptus.pdf.
10
11
Um Jogo de Estratgia Aplicando Tcnicas de Inteligncia Artificial

Franthiesca V. da Silva e Diana F. Adamatti
Abstract This work deals with the utilization of Artificial Intelligence (AI) applied to Electronic Games. Firstly, it presents a brief introduction of eletronic games development. In a second moment, the definition and comparison of AI and Game AI, in the scope of this work, are presented. To exemplify and apply the acquired knowledge, a prototype of a strategy game was developed using the AI techniques.
jogos. Na seo 4 est a proposta desse trabalho, apresentando o jogo propriamente dito. J a seo 5 trata dos detalhes de implementao do jogo. E finalmente, na seo 6 esto as concluses do trabalho e propostas de trabalhos futuros. II. JOGOS ELETRNICOS A. Definio de Jogo "Um jogo uma atividade ou ocupao voluntria (podendo ser fsica ou mental), exercida dentro de limites determinados de tempo e espao, segundo regras livremente criadas, mas absolutamente obrigatrias, dotado de um fim em si mesmo, e cuja finalidade recreao [9]. Um jogo eletrnico um jogo concebido em formato de software, conectado a um dispositivo de vdeo e outro dispositivo de entrada de dados, que permite ao jogador interagir com ele Weiszflog,2004 apud [6]. B. Histria dos Jogos Eletrnicos O precursor dos jogos eletrnicos foi, em 1958, William Hinginbothan que, utilizando um osciloscpio, criou um prottipo de um jogo de tnis, chamado Tennis for Two. O primeiro jogo considerado eletrnico, de fato, foi o Spacewar!, um jogo de guerra espacial desenvolvido por Steve Russel, estudante do Massachusetts Institute of Technology (MIT), em 1961 [4]. Em 1967, Ralph Baer fez o primeiro jogo interativo para televiso, chamado Chase [1]. Em 1970, a Magnovax comprou a idia de Baer e baseou-se nela para criar o vdeo game Odyssey, considerado o primeiro console da histria, dois anos mais tarde [7]. Ainda em 1970, o jogo Spacewar! comeou a ser implementado em uma verso para fliperama por Nolan Bashnell, chamada de Computer Space. A empresa Nutting Associates comprou o jogo e em 1972 aparece o primeiro fliperama da histria. Nesse ano, Bashnell junto com Ted Dabney, funda sua prpria empresa, a Atari, que em seu primeiro ano, com ajuda do engenheiro Al Alcorn lana o famoso jogo Pong [10], [1]. Nos anos seguintes, vrias outras empresas seguem o exemplo da Atari e entram no mercado, entre elas esto a Taito, Midway e Namco. Em 1976, a empresa Farchild lana o primeiro console que utilizava cartuchos, o Channel F. Foi um dos primeiros sistemas eletrnicos a usar o recm inventado microchip.
Index Terms Artificial Intelligence, Game AI, Real-Time Strategy
I.
INTRODUO
A academia, a rea de Inteligncia Artificial (IA) um tema rico para estudo e pesquisa. Na rea de jogos, o que os deixa mais perto da realidade, que torna as personagens, sejam elas pessoas, animais, carros ou avies, etc., mais verossmeis. Mas existem diferenas entre a IA Acadmica (ou Tradicional) e a IA para jogos (Game AI). E a principal diferena entre elas o que cada uma busca: a acadmica visa principalmente buscar soluo para problemas difceis e tenta imitar e entender alguns comportamentos humanos atravs de agentes inteligentes. J na IA para jogos o objetivo a diverso, e o que importa so as impresses do usurio quanto ao resultado gerado [19]. Para a Game AI no importa a resposta dada pelo sistema inteligente nem como ele funciona internamente. O que interessa como o sistema atua, e no o que ele pensa [22]. O principal objetivo deste artigo desenvolver um jogo de estratgia utilizando tcnicas tradicionais de IA, tornando-o inteligente e de alto nvel para o usurio. Este artigo est dividido em 6 sees. Na seo 2 so apresentados os jogos eletrnicos. A seo 3 trata sobre a Inteligncia Artificial e as principais tcnicas aplicadas a
Franthiesca V. da Silva mestranda do Programa de Ps-Graduao em Modelagem Computacional da Universidade Federal do Rio Grande (PPGMC/FURG). E-mail: thiescavaladao@gmail.com Diana F. Adamatti professora doutora do Centro de Cincias Computacionais e do Programa de Ps-Graduao em Modelagem Computacional da Universidade Federal do Rio Grande (C3/PPGMC/FURG). E-mail: dianaadamatti@furg.br

Ainda nesse ano a Warner Communications compra a Atari. Em 1977, lanado o Studio II, da RCA, com quatro jogos na memria principal e jogos extras em cartuchos; lanado o Atari 2600 [21], [1] e Shigeru Miyamoto (criador do Mario e do Donkey Kong) entra para a Nintendo [7]. No fim da dcada de 70 so lanados vrios jogos que ficaram famosos, como: Football, Lunar Lander e Asteroids da Atari e Space Invaders da Midway. Em 1979, surge a empresa Capcom. Os anos 80 foram o auge dos jogos de fliperamas. E foi quando surgiram os primeiros consoles de 8-bits: Famicon, da Nintendo, conhecido como NES (Nintendo Entertainment System) e Master System, da SEGA. Alm do lanamento dos jogos Donkey Kong, Pac-man e Tron, foi fundada a empresa Activision e iniciou-se movimentao no setor de jogos para computador com a On-Line Systems. Em 1983, devido ao grande nmero de jogos ruins no mercado e o lanamento dos computadores pessoais aconteceu a Crash dos Jogos, crise que afetou e levou falncia grande parte das empresas de videogames. A Atari, fortemente afetada pela crise reage com o console Atari 7800. No final da dcada, o mercado de jogos comea a se erguer novamente. Em 1989, a SEGA apresenta o Mega Drive, primeiro console de 16 bits e a Nintendo lana o Game Boy, primeiro videogame porttil [21]. A dcada de 1990 comea com o Super Mario Bros. 3, o jogo de cartucho mais vendido no mundo e a Nintendo surge com o sucessor do NES, o SNES (Super Nintendo Entertainment System). No ano seguinte a SEGA apresenta o primeiro jogo do personagem Sonic [4]. E as duas empresas se tornam lderes do mercado. [21] Nesse ano lanado o primeiro jogo em 3D para computador, o Wolfstein 3D. Nos anos seguintes, segue-se a batalha dos bits. Para concorrer com o SNES, de 16-bits, a SEGA lana o Sega Saturn de 32-bits. Aps, em 1994, surge o PlayStation, da Sony, que revolucionou com grficos e jogabilidade superiores. Em 1996, a Nintendo apresenta o Nintendo 64, com 64-bits, trazendo franquias j existentes, tais como Mario, Zelda e Donkey Kong Villiegas,2000 apud [21]. A dcada de 2000 j comea com o lanamento do PlayStation 2 da Sony, quebrando as vendas do Dreamcast da Sega, lanado no ano anterior. O PlayStation 2 tinha 128bits e usava como mdia CD ou DVD. Com o fim do Dreamcast, a Sega passou apenas a produzir jogos [21], [4]. Nessa poca, a Microsoft decide entrar na competio e coloca seu console Xbox na disputa [10]. E, em seguida, a Nintendo lanou seu novo console porttil, o Game Boy Advance. Em 2004, surge outro porttil da empresa, o Nitendo Dual Screen ou Nintendo DS e o porttil da Sony, o PSP [4]. Atualmente esto concorrendo fortemente no mercado, o PlayStation 3 da Sony, o Xbox 360 da Microsoft, com seu inovador acessrio, o Kinect, e o Nintendo Wii, o primeiro console que trouxe a possibilidade de jogar com os movimentos do corpo. Os consoles da prxima gerao j esto em desenvolvimento e, em um futuro prximo, sero lanados o sucessor do Xbox 360 e o PlayStation 4.
12
C. Tipos de Jogos Existem diversas divises para os jogos. Aqui, apresenta-se a mais comumente utilizada. Jogos de Ao Em geral, neste gnero, o jogador emerge em um mundo catico onde seu objetivo a sobrevivncia para alcanar o final do jogo [13]. Neste gnero esto includos os jogos de Tiro, sejam eles em primeira (do ingls First Person Shooter ou FPS) ou terceira pessoa e os jogos de luta. Nos FPS, o jogador colocado na perspectiva do personagem, atrs de uma arma, na tela s aparecem as mos do personagem [22]. Podem ser citados como exemplo os jogos Doom, Call of Duty: Modern Warfare 3 e Battlefield Bad Company 2. Em jogos de terceira pessoa (Third-Person Shooter ou TPS), segundo Vieira (2005) [22] a perspectiva normalmente atrs do jogador. So exemplos de TPS a srie Resident Evil e a srie Max Payne. O sub-gnero de luta enfatiza o combate corpo-a-corpo entre dois jogadores. Em geral, so baseados em artes marciais como os jogos da srie Mortal Kombat. Jogos de Aventura uma estria interativa em que o jogador colocado no papel do personagem principal e ele deve superar obstculos para alcanar um determinado objetivo. Focam na resoluo de quebra-cabeas e em explorao e coleo de objetos [3], [13]. Alguns exemplos de jogos de aventura so Super Mario e Prince of Persia. Jogos de Estratgia Jogos de estratgia enfatizam habilidades de pensamento e planejamento para alcanar a vitria. Este o tipo de jogo que estamos focando neste trabalho, por isso ele ser mais detalhado na prxima seo. Jogos de Simulao Tem como objetivo simular atividades ou comportamentos da vida real. Abrange um grande nmero de sub-gneros, tais como: simuladores de corrida, de voo e de cidades, gerenciamento e construo, e at simuladores de vida real [13], [22]. Alguns exemplos desse tipo so: Fligth Simulator, Need For Speed: Shift, The Sims 3 e Sim City. Jogos de Interpretao de Personagem Jogos de Interpretao de Personagens, ou RPG (do ingls, Role-playing game), tem origem nos jogos de mesa e tabuleiro que tem como base a criatividade e a cooperao entre os jogadores. Neste gnero o jogador tambm assume o papel do protagonista, mas agora em uma estria bem mais complexa em um mundo aberto, onde pode-se andar livremente para qualquer direo desejada, e onde as aes do jogador influenciam no rumo da histria, podendo ela ter vrios finais diferentes. Em geral h muita interao com os NPC (NonPlayer Characters) e possvel customizar a aparncia e

habilidades do protagonista. Tem como uma das principais caractersticas a evoluo do personagem ao longo do jogo, que pode ganhar novas habilidades, armas, poderes, etc. [13], [3], [5]. Alguns exemplos de jogos desse tipo so The Legend of Zelda, Diablo II e Dragon Age: Origins. Jogos de Esporte So jogos que simulam esportes do mundo real [13]. Neste gnero, geralmente o mundo do jogo e as regras exercidas neste mundo so bastante conhecidos dos jogadores [3]. So exemplos: Pro Evolution Soccer e NBA. Jogos On-Line Jogos on-line na verdade englobam todos os outros tipos de jogos. O que os diferencia poder jog-los atravs da internet podendo interagir com outros jogadores que tambm so reais [13]. Atualmente h uma grande popularizao desse gnero. D. Jogos de Estratgia O conceito de estratgia originou-se das estratgias militares e hoje aplicado nas mais diversas reas, desde o entretenimento at o contexto de negcios [6]. A estratgia militar lida com o planejamento e conduo de campanhas, o movimento e diviso de foras, cooperativismo, entre outras caractersticas. Em jogos de estratgia, em geral, o jogador controla um exrcito e precisa usar sua estratgia militar e sua habilidade de coletar e gerenciar recursos para tomar ou defender territrios, ou destruir inimigos, de forma a alcanar a vitria [13], [22]. Jogos de estratgia podem ser de dois tipos: baseados em turno ou em tempo real. Nos baseados em turno, cada jogador tem um determinado tempo para montar seu planejamento e executar suas aes. Um jogando de cada vez, tal como na maioria dos jogos de tabuleiro, como xadrez e o jogo WAR. So exemplos de jogos baseados em turno: Civilization e Total War. J em jogos em tempo real, conhecidos como RTS (Real-Time Strategy), a todo o momento o jogador tem que pensar e reavaliar suas estratgias e executar suas aes. Todas as aes do jogador e dos adversrios ocorrem ao mesmo tempo [22], [15]. Alguns exemplos de RTSs so os jogos da srie Age of Empires, Stronghold e Starcraft.
13
B. IA e Jogos Eletrnicos Atualmente os jogadores querem ser desafiados e querem que a cada jogada tenham uma experincia nova e nica. Os oponentes tem que ser atrativos e devem ter comportamentos verossmeis. Por isso, cada vez mais necessrio o uso de IA em jogos digitais. A Tabela 3.1 apresenta a utilizao da IA em jogos eletrnicos. Tabela 3.1: Linha de Tempo do uso de IA em Jogos [19], [2].
IA Utilizada Sem IA Descrio Spacewar! Primeiro jogo de computador. Para 2 jogadores Pong Verso eletrnica do tnis de mesa Inimigos comeam a aparecer Space Invaders Inimigos so padronizados, mas atiram de volta. Considerado o primeiro jogo clssico com nveis, score 47, controles simples a dificuldade crescente no decorrer do jogo Pac-Man Fantasmas com movimento padronizado, mas cada fantasma possui uma personalidade Um microcomputador vence um jogador profissional de xadrez pela primeira vez Karate Champ (Data East, 1984) um dos primeiros jogos de luta um contra um, com o computador como adversrio Herzog Zwei (TechnoSoft, 1990) - O primeiro RTS a surgir e o mundo experimenta pela primeira vez uma pssima implementao do algoritmo de pathfinding. Doom (id Software, 1993) incio oficial da era dos FPS BattleCruiser: 3000AD (Take Two Software, 1996) Primeiro uso de redes neurais em um jogo comercial Deep Blue derrota o atual campeo de xadrez Gary Kasparov Half Life A inteligncia artificial em jogos encontra-se em seu auge. O jogo faz grande uso de linguagens de script. Black & White (Lionhead Studios, 2001) Utiliza criaturas que usam aprendizado por reforo e observao. F.E.A.R Utiliza tcnica de Plannig Ano 1962 1972 1974 1978
1980
Padres
1983 1984
1990
Mquinas de Estado Finito
1993 1996
1997 1998
Vrias Tcnicas
2001
2005
III. INTELIGNCIA ARTIFICIAL A. Definio de IA difcil encontrar um consenso entre os autores sobre o que Inteligncia Artificial (IA). O dicionrio Oxford [23] diz que a IA corresponde a uma rea de pesquisa sobre computadores simulando o comportamento inteligente. J, segundo Millington (2006), a capacidade dos computadores de executarem tarefas que humanos e animais podem realizar.
Neste contexto, funde-se um pouco da IA Tradicional com a Game AI. Muitas das tcnicas contidas na Tabela 1 so de IA Tradicional, porm sua implementao cria comportamentos apropriados somente dentro do contexto do jogo Tozour,2002 apud [10]. Por isso, elas podem ser consideradas Game AI. Muitas outras tcnicas utilizadas pelos desenvolvedores de jogos no so consideradas tcnicas de IA. Porm especialistas e acadmicos concordam que houve uma rpida evoluo no desenvolvimento de IA na indstria de jogos e que, em termos de resultados e solues prticas para certos problemas, ela parece estar muito frente do meio acadmico. Novas tcnicas de IA Tradicional podem levar anos sendo formuladas e pode-se levar mais tempo ainda criando estudos formais para prov-las Woodcock,1999 apud [10].

Jogos recentes cada vez mais comeam a utilizar de tcnicas mais avanadas de IA para deixar seus jogos mais atrativos. E o uso frequente de outras tcnicas de Game AI, como scripts para determinar comportamento, talvez faam com que no futuro ela seja mais bem aceita pela rea acadmica. C. Tcnicas de IA Aplicadas a Jogos Mquinas de Estado Finito Mquinas de Estado Finito, do ingls Finite State Machines (FSM), tambm conhecidas como Autmatos Finitos, so estruturas lgicas compostas por um conjunto finito de estados e regras de transio entre estes estados [18]. FSM no considerada uma tcnica de IA, tradicionalmente, mas pode sim ser considerada uma tcnica de inteligncia artificial dentro da Game AI. Sipser (2007) [20] apresenta uma definio formal para as Mquinas de Estado Finito. Uma FSM uma 5-tupla (Q, , , q0, F), onde: 1. Q um conjunto finito conhecido como os estados, 2. um conjunto finito chamado o alfabeto 3. : Q x Q a funo de transio, 4. q0 Q o estado inicial, e 5. F que est contido ou igual a Q o conjunto de estados de aceitao. A funo de transio responsvel por mapear o estado atual da FSM e um dado de entrada pertencente ao alfabeto para um novo estado. A cada interao um dado de entrada lido, se houver uma funo de transio correspondente com o estado atual e a entrada, obtem-se o novo estado. Esse processo continua at que no haja mais estados de entrada para serem lidos ou chegue-se ao estado de aceitao. No contexto de jogos, as FSM so usadas para definir os estados em que um personagem pode se encontrar e situaes que o faro mudar de estado. O personagem apresentar um determinado comportamento dentro do jogo a partir de seu estado atual [10]. Aes e comportamentos esto associados a cada estado [12]. Alm disso, a FSM no necessita reconhecer a linguagem, pois seu objetivo apenas gerar o comportamento dos personagens [15]. Lgica Fuzzy Na Lgica Fuzzy possvel mapear informaes imprecisas ou vagas da mesma forma como os seres humanos costumam fazer [14], [5]. Por exemplo, se no se sabe ao certo a altura de algum pode-se dizer que ela muito baixa, baixa, mais alta ou alta. baseada na Teoria dos Conjuntos Fuzzy, em que possvel que um elemento pertena apenas parcialmente a um conjunto. Grau de Pertinncia o nome de um valor que diz o quanto um elemento pertence a um determinado conjunto [16], [18].
14
A Lgica Fuzzy permite que termos lingusticos, ou variveis lingusticas, como baixa, alta, muito longe, etc., possam ser processados numericamente. Para tal, necessrio convert-los em funes de pertinncia, que atribuiro os graus de pertinncia de cada termo de Barros e Bassanezi,2006 apud [11]. Na Figura 3.1, possvel ver o exemplo de uma funo de pertinncia, onde a varivel temperatura apresenta dois termos lingusticos (valores fuzzy).
Figura 3.1: Exemplo de uma funo de pertinncia [14]. Mquinas de Estados Fuzzy Pode-se usar a Lgica Fuzzy juntamente com as Mquinas de Estado, gerando ento uma Mquina de Estados Fuzzy ou FuSM (do ingls, Fuzzy State Machine). A definio formal de uma Mquina de Estados Fuzzy igual a de uma Mquina de Estados Finitos. Mas, nela, as regras de transio podem conter valores fuzzy para determinar ou no a mudana de estado. Sendo assim, possvel ter uma mquina de estados em que os estados no esto s ativos ou inativos, mas tambm podem estar muito ativos ou pouco ativos [18], [17]. Como a Lgica Fuzzy permite situaes intermedirias, uma FuSM pode no se encontrar exatamente em um nico estado por vez, mas pode estar em vrios estados ao mesmo tempo [18]. Um jogo com FuSM diminui a previsibilidade da tomada de deciso e torna cada NPC com comportamento mais individual. Flocking O Flocking um algoritmo que foca em tcnicas para coordenao de movimentos em grupo. muito utilizado para gerenciamento do comportamento de rebanhos, bandos e bots em jogos de FPS e em jogos de estratgia [3]. No Flocking, cada membro do grupo precisa guardar informaes de outros membros que esto a certa distncia dele, dentro de um determinado raio. Este raio o raio de vizinhana Buckland,2005 apud [5].

Com essas informaes possvel seguir as 3 regras principais, ilustradas pela Figura 3.2, para implementao do algoritmo [19], [12]: Separao: os membros do grupo devem manter certa distncia um do outro, de forma a evitar colises. Alinhamento: o grupo deve mover-se junto, por isso necessrio que cada unidade do grupo, mantenha sua direo alinhada direo dos membros vizinhos. Coeso: o grupo deve permanecer unido e o movimento de um membro deve se dar em relao posio de seus vizinhos. Por isso, deve-se calcular a posio mdia da vizinhana e o resultado ser a nova posio da unidade. No Flocking, para seguir as regras, necessrio apenas ter o estado atual dos membros do grupo. A falta de necessidade de guardar informaes anteriores para sua execuo faz com que ele seja uma boa opo em relao memria [3].
15
Edifcios e Cenrio. Eles podem ser divididos em elementos de Ambiente ou Caracteres. Elementos do Jogo Recursos: Os recursos so constitudos de pedra, madeira e comida. Eles so necessrios para criao de novos edifcios e unidades, tanto soldados quanto trabalhadores. Eles podem ser extrados dos seguintes quatro objetos presentes no cenrio: Pedra, para obter pedra, rvore para obter madeira, e Vaca ou Planta para obter comida. Edifcios: Existem dois tipos de edifcios, o Edifcio Central e o Quartel. O quartel onde podem ser criados novos soldados e o Edifcio Central onde ficam armazenados os recursos e onde possvel criar novos trabalhadores. Mapa: onde todos os elementos aparecem e interagem. Alguns podem ser fixos como as Plantas e outros podem andar livremente como os Trabalhadores. Caracteres Soldado: Os soldados so responsveis pelas batalhas contra os inimigos. Ele podem manter suas posies, caminhar ao longo do mapa, realizar ataques, sejam eles individuais ou em grupo, e podem morrer. Trabalhador: Os trabalhadores so os elementos mais complicados e operantes do jogo. Eles so responsveis pela coleta e armazenamento dos recursos, necessrios para evoluo do exrcito, pela construo e reparo de edifcios. Alm disso, eles so capazes de fugir dos inimigos e at de se defender. C. IA Utilizada no Jogo Mquinas de Estado Finito Dado um evento interno possvel transitar pelos estados presentes nas quatro Mquina de Estados Finitos desenvolvidas para o jogo: trs gerais, uma para cada elemento principal do jogo, e uma para o grupo. No caso da FSM de grupo, para um grupo de soldados. A FSM dos Edifcios, visualizada na Figura 4.1, a mais simples. Inicialmente um edifcio pode ser construdo, depois ele passa para o estado PRONTO. Desse estado possvel ficar num ciclo indeterminado de ser atacando e ser reparado, at o momento em que ele totalmente destrudo, chegando ao estado DESTRUIDO que eliminar o elemento Edifcio do cenrio, e a mquina finalizada.
Figura 3.2: Trs regras do Flocking [19].
IV. PROPOSTA DO JOGO A ideia deste trabalho desenvolver um jogo de estratgia, em tempo real, aplicando tcnicas de Inteligncia Artificial, em um ambiente grfico 2D. A. Definio do Jogo O jogo formado por duas equipes, controladas pelo computador: a Equipe A e a Equipe B, uma jogando contra a outra. A estratgia baseia-se no controle de recursos e na descoberta do melhor momento para atacar o inimigo. A primeira equipe que destruir todo o exrcito inimigo e destruir todos os edifcios centrais do adversrio ganha o jogo. B. Elementos do Jogo Os elementos do jogo so: Soldado, Trabalhador, Recursos,
Figura 4.1: FSM dos Edifcios

locomover em direo aos inimigos e atacaro em conjunto. A Figura 4.2 apresenta a FSM dos Soldados. Como pode ser visto, os soldados comeam no estado NASCENDO, e logo depois de ser criado passa para o estado PARADO, onde ficar aguardando ocorrer algo que ative a transio e o leve a mudar de estado. Se ele detectar um inimigo prximo a ele, poder passar para o estado ATACANDO, onde ele entrar em combate com um ou mais inimigos, sendo um inimigo qualquer trabalhador, soldado ou edifcio do time oposto. Durante o combate, o soldado pode ter sua vida zerada, passando para o estado MORTO e sendo eliminado do cenrio, ou pode vencer o combate voltando ao estado PARADO ou CAMINHANDO. Neste caso, por exemplo, ele pode vencer o combate e decidir voltar para perto de seus edifcios. Quando ocioso por muito tempo, o soldado pode decidir ir para o estado CAMINHADO e consequentemente mudar para uma nova posio.
16
Figura 4.3: FSM dos Trabalhadores
Figura 4.4: FSM do Grupo Flocking No jogo, o flocking usado para gerenciar o movimento e o ataque em grupo executado pelos soldados. Quando vrios soldados decidem atacar o adversrio ao mesmo tempo chamada a funo de flocking que permitir que eles faam uma movimentao ordenada e conjunta em direo ao alvo de ataque. O Flocking aplicado na mquina de estados do grupo, e chamado logo depois que todos os soldados foram avisados do ataque em grupo. Esse momento pode ser visto na Figura 4.4, na seta em vermelho. V. IMPLEMENTAO E TESTE DO JOGO PROPOSTO A. Tecnologias Utilizadas Para o desenvolvimento do jogo foi utilizada a linguagem de programao C++, juntamente com a biblioteca grfica ALLEGRO, nos ambientes de desenvolvimento DEV-C++ e CodeBlocks. Foi adotada a programao orientada a objetos, a partir do uso de classes e objetos da linguagem. ALLEGRO uma biblioteca de software livre e cdigo fonte aberto para desenvolvimento de jogos eletrnicos. multi-plataforma e fornece suporte para grficos 2D e 3D, manipulao de imagens, produo de texto, sada de udio, manipulao de arquivos, entrada de dados pelo teclado e mouse, entre outros [8].
Figura 4.2: FSM dos Soldados A FSM do trabalhador (Figura 4.3) tambm comea no estado NASCENDO. Quando parado, o trabalhador pode decidir buscar recursos. Neste caso, pode coletar e armazenar esses recursos, ou pode construir ou reparar um edifcio, quando ele julgar necessrio ou quando o edifcio tiver sido atacado, mas no destrudo, respectivamente. Em qualquer desses estados, com exceo do NASCENDO, o trabalhador pode perceber um inimigo prximo. Ele ento tentar fugir. Caso o inimigo esteja muito prximo ele tentar atacar para se defender, mas inevitavelmente morrer, pois sua fora e vida so muito pequenas. Caso consiga fugir, voltar ao estado PARADO, onde avaliar novamente qual ser sua deciso. A FSM do grupo (Figura 4.4) executada somente quando necessrio realizar um ataque em grupo, que se dar quando vrios soldados estiverem mudando ao mesmo tempo para o estado ATACANDO. Depois de iniciada a FSM, ser acionado um aviso para que os soldados possam juntar-se para executar o algoritmo de flocking. Eles, ento, iro se

Para o desenvolvimento do jogo fora utilizadas vrias funes bsicas da biblioteca alm da tcnica de double buffering. A funo allegro_init, por exemplo, responsvel por inicializar a biblioteca declarando algumas variveis globais e reservando memria. So utilizadas tambm as funes set_color_depth e set_gfx_mode, responsveis pelas configuraes bsicas de vdeo, create_bitmap e load_bitmap responsveis por criar e carregar as imagens que sero usadas no jogo, e a funo draw_sprite, que desenha as imagens carregadas na tela. Para representar o cenrio e elementos do jogo, juntamente coma a biblioteca ALLEGRO, foram utilizados arquivos de bitmap que esto listados na Tabela 5.1. Tabela 5.1: Bitmaps do Jogo
Imagem Descrio da Imagem
17
B. Classes Gerais do Jogo As classes gerais do jogo so: Ambiente, Soldado, Edificio, Trabalhador, Recurso, Pedra, Arvore, Vaca e Planta. Esto representadas na Figura 5.1. A classe Ambiente onde tudo acontece. Todas as demais classes e principais funes de IA so executadas a partir da classe Ambiente. Nela onde so inicializados todos os elementos grficos referentes a cada classe e ao mapa do jogo. Todas as classes, exceto a Ambiente, apresentam as variveis int x e int y que so responsveis por guardar as coordenadas de cada elemento dentro do jogo, seja ele fixo ou mvel. J int vida e int vida_max, presentes nas classes Trabalhador, Soldado e Edifcio, so responsveis por guardar o valor da vida que o elemento tem no momento e a vida com a qual ele nasce, respectivamente. Caso a vida seja menor que a vida_max, poder ocorrer alguma mudana de estado dos elementos, sendo que se ela chegar zero, significa que o Trabalhador ou Soldado foi morto, ou o Edifcio foi destrudo, levando a sua excluso do cenrio. Todas a classes que geram recursos possuem a varivel quantidade, que diz qual a quantidade de recursos que pode ser extrada dela. Caso a quantidade chegue a zero o elemento desaparece do mapa. C. Mquina de Estados Finito Como dito na seo anterior, existem trs mquinas de estados gerais e uma do grupo. Elas so representadas pelas seguintes funes: void percorre_estados_edificios(); void percorre_estados_soldado() void percorre_estados_trabalhador() void percorre_estados_grupo(); As trs mquinas de estado gerais so inicializadas logo depois dos elementos do jogo, e permanecem rodando at que o jogo seja finalizado. J a FSM do grupo, vlida para um grupo de soldados, s executada quando determinada ao ocorre dentro do jogo. Quando a mquina de estados do grupo acionada, a mquina de estado de cada soldados salva em seu estado anterior. Terminada a execuo do grupo (Flocking), cada um volta a executar a sua mquina de estados, e assim por diante. Dentro de cada mquina de estado esto as demais funes de suma importncia para a IA do jogo, tal como, deteco de inimigos e movimentao. D. Flocking O Flocking se baseia nos trs conceitos explicados na seo III-C. Como os bitmaps dos soldados no mudam, independentemente para qual lado ele est indo, para manter a direo simplesmente passada a coordenada de destino para todos os soldados envolvidos no flocking. A coordenada de destino ser o local onde ocorrer o ataque e poder se obtida atravs da funo de deteco de inimigo.
Trabalhador da Equipe A
Trabalhador da Equipe B
Soldado da Equipe A
Soldado da Equipe B
Edifcio Central Equipe A
Edifcio Central Equipe B
Quartel Equipe A
Quartel Equipe B
Vaca
rvore
18
O soldado perceber o inimigo caso ele se aproxime de sua rea de deteco. A funo responsvel por verificar esta aproximao a detecta_inimigo_sold. A rea de deteco um raio em volta do soldado. Ento, caso algum inimigo penetre nesse raio, a funo retornara um valor positivo, e o soldado imediatamente mudar seu estado para ATACANDO, como visto na Figura 5.3.
Figura 5.3: Exemplo de deteco de um inimigo No caso de metade dos soldados ou mais estiverem no estado ATACANDO ao mesmo tempo ser chamada a FSM do grupo, onde eles iro tentar se comunicar e executar o flocking. Tendo a coordenada os soldados comeam a se mover em direo a ela e comeam a se aproximar uns dos outros. Dada uma maior aproximao cada soldado examina a sua vizinhana e caso ele esteja muito perto de seu vizinho ele ir mudar o sentido do movimento, se mover por alguns ciclos neste sentido, e retomar o sentido original, ligeiramente mais afastado de seu vizinho. Quando ele faz este movimento, pode se aproximar de outro soldado, que ento repetir o mesmo processo. Alcanada as coordenadas de destino, a FSM do grupo finalizada e dado o prosseguimento com as mquinas de estado individuais. E. Interfaces e Testes Realizados Na Figura 5.4, possvel ver a interface do jogo ao inicilo.
Figura 5.1: Diagrama de Classes do Jogo
Figura 5.4: Interface inicial do jogo. Ainda na configurao inicial possvel visualizar as

equipes A, esquerda, e B, direita (Figura 5.5).
19
Futuramente, espera-se incluir as Mquinas de Estado Fuzzy ao jogo, o qual era inicialmente desejado para este trabalho, mas infelizmente no foi possvel. Outro objetivo futuro aprofundar os testes sobre o jogo, realizando testes de desempenho computacional e uma anlise comparativa detalhada do funcionamento do jogo executando as tcnica de IA separadamente.
REFERNCIAS
[1] M. Bellis, Computer and Video Game History. Disponvel em <http:// http://inventors.about.com/library/inventors/blcomputer_videogames.htm > Acessado em 18 de Novembro de 2011. [2] A. J. Champandard, An Overview of the AI Architecture Inside the F.E.A.R. SDK. Disponvel em < http://aigamedev.com/open/article/fearsdk/>. Acessado em 05 de Novembro de 2011. [3] M. Da Luz, Mairlo. Desenvolvimento de Jogos de Computador. 2004. 117 f. Projeto Final de Graduao. Departamento de Matemtica e Computao Universidade Federal de Itajub (UNIFEI). Itajub, 2004 [4] R. Demaria, J. L. Wilson, High Score! The Illustrated History of Eletronic Games, 2nd Editon. Emeryville: McGraw-Hill/Osborne. 2004. [5] E. Fujita, Algoritmos de IA para Jogos. Projeto Final de Graduao. Departamento de Computao. Universidade Estadual de Londrina (UEL). Londrina, 2005. [6] P. Ghemawat, A Estratgia e o Cenrio de Negcios. Porto Alegre: Bookman, 2007. [7] G. G. Granada, Framework de Tcnicas Inteligentes Voltado a Jogos Eletrnicos. Projeto Final de Graduao. Universidade Federal do Rio Grande. Rio Grande, 2011. [8] J. S. Harbour, Game Programming All in One, Third Edition. Thomson Course Technology PTR. Boston, 2007. [9] H. Japiassu, D. Marcondes, icionrio Bsico de Filosofia. Jorge Zahar Editora: Rio de Janeiro, 1996. [10] A. Kishimoto, Inteligncia Artificial em Jogos Eletrnicos. So Paulo, 2004. [11] C. A. Madsen, A. FURG Smart Games: Um Framework para Jogos Inteligentes. Universidade Federal do Rio Grande. Qualificao de Dissertao de Mestrado em Modelagem Computacional. Rio Grande, 2011. [12] I. Millington, Artificial Intelligence for Games. San Francisco: Elsevier. 2006. [13] F. C. Morais, Desenvolvimento de Jogos Eletrnicos. Belo Horizonte, 2009. [14] L. A. Mozelli, Controle Fuzzy para Sistemas Takagi-Sugeno: Condies Aprimoradas e Aplicaes. Dissertao de Mestrado. Universidade Federal de Minas Gerais. Belo Horizonte, 2008. [15] S. Rabin, AI Game Programming Wisdom. Hingham: Charles River Media. 2002. [16] S. Rezende, O. Sistemas Inteligentes. Barueri: Manole.2003. [17] P. Ribeiro, IA e Jogos. Seminario 1 Mestrado em Informtica e Sistemas Universidade de Coimbra, 2003. [18] G. L. Santos, dos. Mquinas de Estados Hierrquicas em Jogos Eletrnicos. 2004. 54f. Tese de Mestrado. Pontifcia Universidade Catlica do Rio de Janeiro (PUC-Rio). Rio de Janeiro, 2004. [19] B. Schwab, AI Game Engine Programming. Hingham: Charles River Media. 2009. [20] M. Sipser, Introduo Teoria da Computao. So Paulo: Thomson Learning. 2007. [21] R. Tengan, IA em Jogos. Projeto Final de Graduao. Faculdade de Tecnologia de Praia Grande. Praia Grande, 2006. [22] V. Vieira, Revolution AI Engine: Desenvolvimento de um motor de Inteligncia Artificial para a criao de jogos eletrnicos. 75f. Projeto Final de Graduao. Centro de Informtica Universidade Federal de Pernambuco. Recife, 2005. [23] S. Wehmeier, Oxford Advanced Learners Dictionary. Oxford: Oxford University Press. 2000.
Figura 5.5: Equipe A e Equipe B Na Figura 5.6 possvel ver um grupo de soldados iniciando o processo de flocking.
Figura 5.6: Soldados em flocking VI. CONCLUSO Com o aumento do nvel de exigncia dos jogadores e da capacidade de processamento dos computadores, vai ser cada vez mais exigido um avano da inteligncia artificial aplicada em jogos. E devido ao seu crescimento e valorizao, a tendncia que a Game AI, seja gradualmente melhor aceita e incorporada rea acadmica. possvel que no futuro tenhase agentes inteligentes que aprendam com maneira de jogar dos jogadores e deixem os jogos mais desafiadores. Schwab (2009) [19] afirma que os agentes dentro dos jogos, inclusive, podero ser dotados de emoes e personalidades bem definidas. Esse avano na IA em jogos, juntamente com os novos equipamentos e tecnologias, como o Kinect, que so apenas um comeo para esse novo tipo de iteratividade, deixaro os jogos eletrnicos muito mais imersivos e, esperase, divertidos. A ideia de criar um jogo para este trabalho foi fazer um pouco do que os jogos fazem para ns, ou seja, deixar a experincia e o aprendizado mais divertidos e interessantes. No foi possvel aplicar todas as tcnicas desejadas, porm isso no diminuiu em nada o conhecimento adquirido ao longo de seu desenvolvimento. O jogo serve como um prottipo do que ainda pode ser realizado com tcnicas conhecidas de IA, alm da Game AI.
20
A avaliao como ferramenta motivadora do processo ensino-aprendizagem em matemtica

Simone Escouto da Rosa, Martiela Vaz de Freitas
Resumo Com objetivo de demonstrar a importncia da avaliao, suas diferentes formas e finalidades no mbito escolar, para promover mudanas no processo ensino-aprendizagem, foi feita a leitura e discusso do que se apresenta de forma diversa em nossa literatura com respeito a instrumentos e formas de avaliao. So feitas consideraes a respeito do posicionamento de alguns autores frente avaliao e ao processo avaliativo como um todo. So ainda apresentados instrumentos que podem ser utilizados no processo, de forma a no empregar somente os meios tradicionais como forma de obter informaes sobre os estudantes, provocando aes e reaes na comunidade escolar, passando a envolver tambm pais e professores com vistas a gerar maior comprometimento com o processo de avaliao. Trata a respeito do processo que se mostra insuficiente como avaliao dentro da disciplina de Matemtica, em especial, e busca alternativas que podem resultar em melhorias no processo do ensino e da aprendizagem dessa disciplina. Palavras-chave Avaliao. Ensino-aprendizagem. Matemtica.
transformao e compreenso. Com isso, estimular o interesse do educando, despertando a vontade e a capacidade de investigao e soluo de problemas. O artigo est estruturado de forma a apresentar, em primeira instncia, o que se entende por avaliao no mbito geral da educao e em que ela est baseada, apresentando um breve histrico sobre o tema. Alm disso, traz alguns instrumentos de avaliao que podem, conforme o caso, servir como base para um melhor julgamento do aprendizado do educando para posteriormente discutir a respeito de quais os melhores objetos de avaliao podem ser utilizados, em especial no que se refere ao ensino de matemtica.
II. ENSINO X AVALIAO O ensino tradicional, baseado em aulas expositivas centradas na figura do professor onde cabe ao estudante a assimilao do que lhe transmitido, vem sendo questionado ao longo do sculo XX com as intensas discusses motivadas pelas descobertas da psicologia do desenvolvimento e a abordagem socioconstrutivista, feitas por Jean Piaget (18961980) e Lev Vygotsky (1896-1934). Nesse sentido novas propostas comearam a ser construdas. Na Frana surgiu a Didtica da Matemtica como rea do saber, despontando vrios pesquisadores. No Brasil foi nas dcadas de 1950 e 1960 que os educadores passaram a se preocupar com o processo de ensino. O foco dessa tendncia que coloca o educando no centro do processo de aprendizagem apresentar a ele situaesproblema para resolver. Sandra Baccarin, em [17], do grupo Compasso - UnB, que trabalha com pesquisas em Educao Matemtica, diz que o docente tem o papel de mediador, ajudando a construir os conceitos e fazendo com que o estudante tenha conscincia do que faz na hora de responder as questes. Cabe ao educando, nessa perspectiva, pensar em possveis caminhos para resolv-las, formulando hipteses sem a necessidade de apresentar respostas imediatas. a que ele usa a prpria lgica para produzir. Assim, comeamos a preparar os jovens para pensar de forma autnoma, destaca Cristiano Muniz, em [17], coordenador adjunto do Programa de PsGraduao em Educao da Universidade de Braslia (UnB). Nesse sentido, Freire introduz a Pedagogia da Autonomia explicando suas razes para analisar a prtica pedaggica do professor em relao autonomia de ser e de saber do
I. INTRODUO
STE artigo desenvolve uma reflexo sobre como tem se dado a educao e, inerente a ela, questes como o processo ensino-aprendizagem, o que avaliar dentro do ensino em matemtica, como isso ocorre ao longo da trajetria escolar do indivduo, qual o processo de avaliao mais comum. Reflete se possvel considerar outros meios mais coerentes como forma de avaliao do que os tradicionalmente estabelecidos. A partir dessas reflexes, busca responder como despertar no estudante, atravs da avaliao, a capacidade de posicionar-se de maneira crtico-construtiva, questionando a realidade, formulando problemas e resolvendo-os, utilizando o pensamento lgico-criativo. Assim, desenvolvendo o sentimento de confiana para a construo do conhecimento, de suas capacidades a partir da gerao de auto-estima e persistncia na busca de solues, de forma a pensar em conhecimento matemtico como uma maneira de
Artigo submetido em Setembro, 2012. Simone Escouto da Rosa Licenciada em Matemtica pela Universidade Federal do Rio Grande FURG, Especialista em Metodologia do Ensino em Matemtica e Fsica pela FATEC/FACINTER e Mestre em Modelagem computacional pela Universidade Federal do Rio Grande FURG (e-mail: simonerosa.mat@gmail.com). Martiela Vaz de Freitas Licenciada em Matemtica pela Universidade Federal do Rio Grande FURG e Mestranda do Programa de Ps Graduao em Modelagem Computacional da Universidade Federal do Rio Grande FURG (e-mail: martielafreitas@gmail.com)

educando. Enfatiza a necessidade de respeito ao conhecimento que o educando traz para a escola, visto ser ele um sujeito social e histrico, e da compreenso de que formar o educando muito mais que apenas trein-lo para o desempenho de suas habilidades. Ensinar, para [10], requer aceitar os riscos que tudo aquilo que novo traz consigo, enquanto inovao, enriquecimento, e rejeitar quaisquer formas de discriminao que separe as pessoas em raa, classes, entre outros. ter certeza de que faz parte de um processo inconcluso, apesar de saber que o ser humano um ser condicionado, portanto h sempre possibilidades de interferir na realidade a fim de modific-la. Acima de tudo, ensinar exige respeito autonomia do ser do educando. Atravs das observaes da prtica pedaggica, pode-se notar que h pouca utilizao de estratgias e recursos que possibilitem uma aula mais dinmica e prazerosa, proporcionando ao educando uma ao crtica e reflexiva na construo do seu conhecimento. Os recursos utilizados devem ser mistos, no podendo o professor se prender em apenas um tipo (ou quadro-negro, ou vdeo, por exemplo). O ideal seria uma mescla de instrumentos para tornar a aula mais interessante tanto para os educandos quanto para o professor. ressaltado por [10], ainda, que s podemos ter real entendimento dos educandos a partir do momento em que nos dispomos a ouv-los com pacincia e criticidade. Nesse momento o educador se torna realmente capaz de se comunicar com ele. Quando o estudante entende o contedo, utiliza sua bagagem de estudos para enunciar conceitos daquilo que foi proposto, conseguindo dar exemplos. No entanto, fora da sua situao de contexto no h aplicaes para ele. J quando ele compreende o contedo a ele apresentado, demonstra capacidade de estabelecer relaes, com exemplos e contraexemplos, fazendo com que aquele no seja mais um contedo isolado de todo o resto. A partir da compreenso o educando capaz de utilizar o que lhe foi ensinado para resolver questes que teoricamente no saberia resolver anteriormente, segundo [5]. Se o que almejamos em nossas aulas que a educao se d de forma completa, tanto com um estudante que participa e compreende o que faz quanto com um professor reflexivo que repensa sua pratica e aprende com ela, existe a necessidade de que a educao que relacione o fazer com o viver. Como temos visto, a educao concebida como um conjunto de experincias, de vivncias, as quais ocorrem de forma a agregar conhecimento ao educando. necessrio que se construa toda uma condio favorvel para que processo ensino-aprendizagem se d plenamente. Porm, mesmo com todo esforo em mudar a forma como ensinamos e apesar de a avaliao ser uma prtica ampla que permite ao educando a observao, a reflexo e o julgamento das melhores opes, os meios de avaliar o processo de aprendizagem seguem pouco explorados.
21
Para [20], a avaliao deve ser contnua, ou seja, no apenas em perodos especficos do ano letivo. Deve tambm ser compatvel com os objetivos propostos que servem como guia do processo educacional e que realmente cumpra o papel de diagnstico. Nesse contexto [20] diz ainda que a avaliao deve abranger todas as instncias do desenvolvimento do educando: cognitivo, afetivo e psicomotor, e que, para isso, faa-se uso da diversidade de formas existentes para avaliar. De acordo com [4], nas duas primeiras dcadas do sculo XX o modo de avaliar foi baseado nos estudos de Robert Thorndike, buscando o desenvolvimento de testes padro para aferir as habilidades dos estudantes, enquanto as pesquisas avaliativas consideravam principalmente a mudana do comportamento humano. essa informao a respeito do progresso do indivduo e do grupo que o educador busca ao avaliar seus educandos. Pois, ela se faz necessria para que se possa realizar uma melhor anlise de quais so as dificuldades e os pontos fortes do estudante com relao a determinado assunto abordado. assim que o professor pode planejar-se e auxiliar seus educandos a alcanar seus objetivos durante o perodo escolar. Assim, desde o incio do sculo XX, a avaliao atravessa pelo menos quatro geraes, que segundo [11], apresentado por [9], seriam: Mensurao: aqui avaliao e medida so sinnimos. Os testes so determinsticos, com inteno de verificar se o processo de ensino gera bons produtos a partir dos educandos. Em geral esse tipo de avaliao descontextualizada, pois os conhecimentos so o nico alvo e possuem a finalidade de comparar um estudante ou grupo aos demais e, assim, se reduz aplicao de testes e atribuio de notas que funcionam como uma classificao em perodos determinados. Descritiva: tida como avaliao educacional, surgiu como uma busca do melhor entender o processo de avaliao. Enquanto a gerao da mensurao oferecia apenas dados a respeito do educando, fazia-se necessrio exprimir quais eram os seus objetivos em sala de aula. Assim no se limitava em medir apenas, ia alm no sentido de descrever o que era sucesso e dificuldade com relao a objetivos estabelecidos, principalmente objetivos comportamentais do educando. Julgamento: nascida por volta do final dos anos sessenta tratava da necessidade de superar os pontos fracos da avaliao questionando os testes padronizados e a atribuio de notas somente. A avaliao deveria facilitar a tomada de decises que regem o processo ensino-aprendizagem de forma que a obteno de informao fosse alm dos resultados dos educandos em provas e testes, passando a avaliar o processo como um todo, envolvendo o professor, o estudante e a comunidade escolar em geral. nessa altura que surge a diferenciao entre os conceitos de avaliao somativa e avaliao formativa, onde, de acordo com [16], o segundo modelo de avaliao d maior nfase ao aprender, gerando mudanas nos demais nveis educacionais, como currculo, gesto escolar, organizao da sala de aula, tipos de atividades e o prprio jeito de avaliar a turma. Na

avaliao formativa no h como pressuposto nenhum tipo de punio ou de premiao. Ela prev que os estudantes possuem ritmos diferentes em seu processo de aprendizagem. A avaliao formativa aquela com a funo controladora que ocorre ao longo do processo de ensino-aprendizagem com o intuito de averiguar se os educandos esto atingindo os objetivos previstos. Portanto, a avaliao formativa consiste, basicamente, em avaliar se o estudante supera gradativamente cada etapa da aprendizagem antes de prosseguir para uma etapa subseqente do processo. Com a utilizao da avaliao formativa o professor consegue detectar certas deficincias apresentadas no seu trabalho, permitindo com que haja a reformulao da sua maneira de ensinar, aperfeioamento de suas tcnicas e orientao para melhoria de seu trabalho didtico. formativa no sentido em que indica como os educandos esto se modificando em direo aos objetivos desejados [2]. Durante este tipo de avaliao podemos acompanhar o desenvolvimento dos estudantes ao longo do processo e observar como esto superando as etapas ou alcanando os objetivos traados. Enquanto a avaliao somativa definida como sendo aquela avaliao cujo sua funo bsica de classificar os educandos de acordo com os nveis de aproveitamento ao final do curso ou perodo letivo, para [3] a avaliao somativa objetiva avaliar de maneira geral o grau em que os resultados mais amplos tm sido alcanados ao longo e final de um curso. A classificao do educando se d de acordo com o rendimento atingido, tendo como parmetro os objetivos previstos. A avaliao somativa se baseia nos contedos e procedimentos avaliadores, como provas, teste objetivo, dissertaes argumentativas. Os trs tipos de avaliao devem ser utilizadas juntas ou conjugadas para garantir o sucesso do sistema avaliativo. Em maior ou menor grau podemos observar que algumas dessas trs geraes pelas quais passou a avaliao ainda prevalecem no sistema educativo, mas se mostram insuficientes para que a avaliao do processo ensinoaprendizagem seja ampla. As principais dificuldades/limitaes dessas tendncias esto no fato de avaliarem programas ou sistemas educativos, refletindo o ponto de vista de quem os produziu no necessariamente lhe repassando responsabilidade de forma que essas sejam distribudas diretamente aos professores e estudantes. Falham ao dificultarem a diversificao de abordagem ou procedimentos e a pluralidade de valores, inclusive ao dependerem basicamente do mtodo cientfico, o que acaba em avaliaes descontextualizadas. Assim, em suma, seria necessrio um tipo de avaliao que fosse interativo. Nesse sentido, [11] propem para a avaliao, uma quarta gerao: Negociao: fundamentado no paradigma construtivista, h a ruptura epistemolgica com as geraes anteriores. Tratase da gerao que dar retorno na medida das dificuldades
22
existentes. Desenvolve-se a partir das preocupaes existentes com relao ao objetivo da avaliao, seja ele um programa, projeto, curso, entre outros. De acordo com isso, [21] mostra que a finalidade da avaliao , de acordo com a quarta gerao, fornecer informaes a respeito do processo pedaggico que permitam aos agentes escolares envolvidos decidir sobre que mudanas e redirecionamentos se fazem necessrios de forma a garantir a aprendizagem do estudante. Ao escolher os instrumentos de avaliao professor deve verificar se as estratgias didticas de ensino esto coerentes e correspondem s expectativas para a coleta de informaes sobre a aprendizagem dos educandos. Com a utilizao de tais instrumentos a visualizao do professor deve ser clara, podendo observar se os estudantes esto ou no atingindo os objetivos propostos. Este tipo de diversificao deve ser usada para o favorecimento de todos que compe o ambiente escolar, nunca pensando em facilitar para aqueles que possuem mais facilidade em se motivarem com atividades escolares ou excluir os que no se adaptam. O processo de avaliao deve ser utilizado de maneira democrtica, visando favorecer a todos os estudantes do ambiente escolar, com o intuito de fazer com que os educandos se manifestem a fim de mostrar o que muitas vezes fica inibido na prova objetiva. Segundo [15], o instrumento de avaliao deve ter uma elaborao objetiva e ter clareza de comunicao. Dessa maneira, [8] distingue quatro pontos principais para qualquer instrumento de avaliao, que seriam: (a) suporte, (b) estrutura, (c) materiais e (d) situao social, a qual nunca neutra independente de qual seja. O suporte poderia ser entendido como sendo a escrita, a oralidade, o desenho e o corpo como formas de expresso, sendo que cada indivduo possui suas preferncias com relao a essas formas de comunicao. Cada eixo trabalhado pode conter tambm estruturas variadas, o suporte escrito pode, por exemplo, solicitar ao educando para resumir, completar, enunciar, entre outros. Os materiais que fazem parte dos instrumentos de avaliao devem ser cuidadosos quanto linguagem que apresentam, pois podem provocar a inibio ou rejeio caso contenham termos que possuam significado desconhecido por parte do estudante. E ainda podem surgir certos bloqueios afetivos caso os materiais possuam alguma conotao social. A forma como o instrumento de avaliao aplicado tem grande influncia tambm sobre o desempenho do estudante. Se alguns preferem trabalhar de forma isolada e obtm bons resultados em avaliaes escritas, outros correm o risco de bloqueios perante a folha em branco e sentir que so o nico alvo do professor. Isso no significa que se deva introduzir uma avaliao para cada educando, segundo sua preferncia. Porm, a diversificao do objeto de avaliao possvel, e essa inteno de sermos justos que nos leva a criar diferenciados tipos de avaliao.

Assim destaca [1], dizendo que tendo como foco os objetivos curriculares que incluem competncias no domnio do conhecimento, capacidade, atitudes e valores, os educadores devem procurar meios variados de recolhimento de dados para melhor avaliar o educando, recorrendo para tanto a relatrios, desempenhos orais e outros trabalhos que registrem de forma prtica esses dados. Destaca-se, portanto, a importncia da diversificao do instrumento de avaliao, visto que o professor deve considerar que os estudantes possuem ritmo de aprendizado e respostas diferentes aos estmulos aplicados. III. INSTRUMENTO DE AVALIAO Instrumentos de avaliao devem ser entendidos como sendo os recursos utilizados pra se coletar e analisar as informaes provenientes do processo de ensino com intuito de ampliar a aprendizagem dos educandos. Como vimos, no somente existem vrias tcnicas, mas tambm diferenciados instrumentos de avaliao, a saber: a prova, a prova objetiva, a prova oral, a prova prtica, o portflio, trabalhos individuais e em grupo e tambm a auto-avaliao. Prova: as estratgias de avaliao devem ser articuladas em seu perodo devidamente estabelecido de acordo com o desenvolvimento do trabalho pedaggico junto s reflexes e temas a serem abordados. Cada tipo de prova, dissertativa ou oral, deve ser aplicada em funo das diferenas e necessidades de aprendizagem presente em cada educando. A prova oral est diretamente ligada ao fator emocional do educando. Este recurso pode ser utilizado com o intuito de se medir a habilidade de expresso e de comunicao do educando. necessrio considerar as reaes apresentas pelos educandos, alguns se sentem totalmente bloqueados, no conseguem se expressar e travam no momento da fala, outros so hbeis quanto a este ponto ficando totalmente vontade. O recurso deve avaliar alguns itens, como opinies, atitudes, fala e habilidade se expressar oralmente. Sua aplicao recomendada apenas para comprovao das capacidades citadas anteriormente. J a prova dissertativa um instrumento avaliativo de grande importncia no processo educativo, porm utilizado de forma incorreta dentro do ambiente escolar. Este instrumento tem sido compreendido por educandos e professores como um recurso pedaggico que visa garantir que uma aula ministrada ser mais interessante. Expresses do tipo: anotem tudo o que foi dito, prestem ateno neste tpico, pois de suma importncia para a avaliao, como vocs no se calam, considero a matria dada so comuns nas salas de aula. Na avaliao tradicional, o processo de aprender se refere ao mecanismo de transcrio de informaes muitas vezes sem que o educando compreenda realmente o que est fazendo. A prova deve ser, portanto, um recurso pedaggico avaliativo a ser elaborado de acordo com os objetivos a serem atingidos,
23
com foco na anlise de uma aprendizagem significativa do educando. Trabalho em grupo: deve ser realizado de forma cooperativa. necessrio que cada componente trabalhe com o tema proposto para que se obtenha um resultado satisfatrio da equipe. Neste tipo de avaliao deve ser levado em considerao a aprendizagem de cada membro e a capacidade de realizar um trabalho de colaborao. A apresentao pode ser feita de forma oral, pelo grupo, de acordo com o que foi proposto pelo professor, atravs de uma nota atribuda coletivamente e individualmente, por meio de uma avaliao escrita feita pelo grupo. Todavia, [18] alerta sobre os problemas ao se avaliar as atividades em grupo e diferencia o que seriam educandos que trabalham em grupos de estudantes que trabalham cooperando. O autor defende que papel do professor a habilidade de propor aos grupos de educandos uma gama de atividades que possam ser realizadas em diferentes nveis de complexidade por todos os integrantes do grupo respeitando sua diversidade, de forma que o resultado seja um trabalho onde o esforo coletivo foi compartilhado. O portflio consiste em uma coleo de trabalhos realizados pelos educandos ao longo do perodo letivo. A sua elaborao deve ser de responsabilidade tanto do professor como do estudante, os quais decidem em conjunto o que incluir no portflio, em que condies, com que objetivos e qual o processo de avaliao, de acordo com [14]. Ao interagir com o professor o educando ter mais oportunidades de intervir e de assumir responsabilidades no seu processo educativo, de acordo com [19]. No portflio so includos diversos trabalhos, inclusive os matemticos, que registram as atividades realizadas pelos educandos. importante que o estudante faa reflexes relativas a esses trabalhos, resultando em atitudes que vo contribuir para a conscientizao referente s dificuldades e a sua evoluo. Considera-se a perspectiva auto-avaliativa como uma vantagem do portflio em relao aos outros instrumentos de avaliao. Para [24], o desenvolvimento dessa capacidade requer que o estudante ao se auto-avaliar saiba por que razo e para que finalidade ele faz isso. Eles necessitam perceber que a autoavaliao colabora para a reorganizao do trabalho pedaggico. De acordo com [12], durante a fase de auto-avaliao o professor dever apresentar aos educandos algumas indicaes que conduzam ao desenvolvimento de diversos nveis de reflexo: documentao (escolhi este trabalho porque...); comparao (este trabalho enriquece o meu portflio porque...); e integrao (o meu dossi revela um progresso porque...). Assim, segundo [6], portflio poder definir-se como um instrumento pedaggico com o principal propsito de documentar o desenvolvimento da aprendizagem dos educandos.

IV. INSTRUMENTOS DE AVALIAO EM MATEMTICA No que tange ao ensino de matemtica, surgem novas perspectivas de avaliao que consistem em valorizar a participao mais efetiva do educando em seu prprio processo de aprendizagem. Isso faz com que o estudante se torne mais responsvel por seu rendimento, deixando de ser um ente passivo durante as aulas e se interesse mais pelos contedos a serem ministrados pelo docente. Nesse sentido, acredita-se que o ensino da Matemtica e sua avaliao devem caminhar juntos, ou seja, compor uma ao conjunta. No deve ser simplesmente uma constatao de resultados, mas deve levar em considerao toda a trajetria do educando ao longo do seu processo de ensino, observando seus avanos e suas dificuldades, considerando-as como parte do processo de construo do seu conhecimento. Costumeiramente o estilo tradicional de avaliao com perguntas fechadas e realizadas em tempo pr-definido que predomina como instrumento de avaliao em Matemtica, segundo [1]. No entanto, esse instrumento no parece trazer respostas altura no que tange aos princpios que orientam as avaliaes anteriormente apresentadas, dado que no torna possvel a incluso de questes que facilitem o aproveitamento produtivo do erro, no estimulando o raciocnio e a apresentao de interpretaes ou argumentaes. Trata-se de um instrumento de avaliao que no permite ao professor o retorno de dados significativos sobre aspectos importantes da disciplina, tampouco favorece o desenvolvimento das competncias necessrias para que se promova a autoavaliao. No mbito da educao em Matemtica existem mtodos que melhor se ajustam as metas educacionais possivelmente propostas por parte do professor, com relao ao desenvolvimento de seus educandos. Pode-se dizer apenas que os mtodos apresentados a seguir ainda so pouco explorados em sala de aula, mas que se revestem de grande potencial educativo. Relatrio escrito: definido por [23] como sendo a produo por meio escrito que permite ao educando a descrio, a anlise, a crtica, a produo escrita onde descrita e analisada determinada situao ou atividade. a oportunidade que o educando possui de aprender a registrar por escrito sua capacidade de raciocnio, desenvolvendo interesse pela pesquisa e responsabilidade, contribuindo para a construo de uma viso nova da atividade matemtica, de acordo com [22] e [23]. Teste em duas fases: normalmente composto por questes diferenciadas, com possibilidade de respostas curtas, de resposta aberta e de ensaio, segundo [13]. Realizada em diferentes momentos ao longo do perodo letivo pode ocorrer primeiramente em sala de aula com durao limitada e, posteriormente, num perodo de tempo maior. Aps a primeira fase, o professor traz para o educando uma classificao do teste identificando as falhas mais graves e apresentando possveis caminhos de resoluo. com base
24
nesses caminhos que o educando partir para a segunda fase. Desta maneira possvel, tanto para o professor quanto para o estudante, o acesso as suas classificaes. Segundo [7] e [13], o processo se completaria com a atribuio de uma classificao final que contemple o desempenho do educando ao longo das duas fases. Portflio: deve conter trabalhos que documentem as atividades matemticas do educando a ser avaliado, atuando como parte importante da elaborao de uma reflexo sobre essas atividades, para que assim possa desenvolver uma atitude reflexiva com relao a sua prpria aprendizagem, favorecendo a conscientizao de suas dificuldades e seus avanos ao longo de seu desenvolvimento. Esses meios de avaliao visam verificar e quantificar os resultados do processo de aprendizagem no seu decorrer (incio, meio e final), de forma a superar as dificuldades, corrigir as falhas e incentivar o educando a continuar buscando sua evoluo.
V. CONSIDERAES FINAIS Neste trabalho foi explorado o instrumento avaliao. Com isso percebemos que o professor precisa qualificar-se constantemente na busca de novas alternativas e instrumentos que estimulem e incentivem a participao dos educandos, provocando o questionamento sobre os tpicos abordados em aula, sugerindo e contribuindo com o aprendizado e auxiliando na construo do conhecimento, desenvolvendo a autoconfiana, a concentrao, a ateno e o raciocnio do educando. A avaliao uma fase importante do processo educativo. o momento em que as capacidades do educando podem ser exploradas e no qual o professor deve usar a autocrtica para avaliar se as metodologias e avaliaes esto desenvolvendo o aprendizado do educando. Pode-se afirmar que a escola desempenha um papel fundamental no processo de ensinoaprendizagem no sentido de oferecer condies adequadas nos aspectos estruturais e pedaggicos, os quais contribuem para a formao dos educandos. Com isso no se pretende extinguir a avaliao tradicional, mas permitir com que o educando possa aprender o conhecimento matemtico a partir de alternativas com o intuito de que ele progrida em seus estudos. O educador, para revolucionar sua forma de avaliar, necessita mudar sua postura educacional, ou seja, refletir sobre sua metodologia e sobre a maneira como seleciona os tpicos e os objetivos que devero ser alcanados com o seu trabalho. A avaliao no se d separada de um projeto pedaggico. Ela acompanha todo o processo de aprendizagem, portanto necessrio que o professor tenha um plano de ensino elaborado que direcione o seu trabalho educativo. Em face ao exposto, preciso que a instituio de ensino pense sobre a maneira de avaliar o discente em seu processo de ensino e de aprendizagem, buscando atravs de novas alternativas superar a avaliao tradicional e remeter a escola e

seus educadores a mudanas fundamentais para que o processo de ensino ocorra de forma significativa. REFERNCIAS
[1] Associao de Professores de Matemtica. Matemtica 2001 Recomendaes para o ensino e aprendizagem da Matemtica, Lisboa: Associao de Professores de Matemtica & Instituto de Inovao Educacional. 1998. BLOOM, B. S.; HASTINGS, J.; MADAUS, G. F. Manual de avaliao formativa e somativa do aprendizado escolar. So Paulo: Pioneira, 1971. BLOOM, B. S. et al. Taxionomia de Objetivos Educacionais e Domnio Cognitivo: Domnio Cognitivo. Volume 1, Porto Alegre: Globo, 1983. BORBA, A. M. de & FERRI, C. Avaliao: contexto e perspectivas. Revista de Divulgao Cientfica da Universidade do Vale do Itaja Alcance. Itaja SC: ano IV, n.02, p.47-55, jul/dez/1997 CARVALHO, A. M. P. de. A pesquisa em sala de aula e a formao de professores.In: A pesquisa em ensino de cincias no Brasil: alguns recortes. NARDI, R. (org.)So Paulo: Escrituras Editora, 2007 CROWLEY, M. Student mathematics portfolio: More than a display case. In D. Lambdin; P. Kehle & R. Preston (Eds.), Emphasis on assessment, readings from NCTMs School-Based Journals. Virginia: N.C.T.M. 1993. De LANGE, J. Mathematics, Insight and Meaning. Ultrecht: OW & OC. 1987. FERRAZ, M. J. et al Instrumentos de avaliao: diversificar preciso In: Pensar avaliao, melhorar a aprendizagem/IIE. Lisboa: IIE, 1994. Disponvel em: <http://www.dgidc.minedu.pt/secundario/Documents/instrumentos_avaliacao.pdf> Acesso em 09/03/2011. FIRME, T. P. Avaliao: tendncias e tendenciosidades. Ensaio: Avaliao e polticas pblicas em educao. Rio de Janeiro: Fundao Cesgranrio, v. 1, n. 2, p. 5 - 12, jan./mar. 1994. FREIRE, P. Pedagogia da autonomia: saberes necessrios prtica educativa. 29. ed. So Paulo: Paz e Terra, 1996. GUBA, E. G. e LINCOLN, Y. S. Fourth Generation Evaluation. Londres: SAGE Publications. 1989 LAMBDIN, D. V. & WALKER, V. L. (1994). Planning for Classroom Porteflio Assessment. Emphasis on Assessment, Readings from School- Based Journals. National Council of Teachers of Mathematics, Reston (1996), (p. 95-101) LEAL, L. Avaliao da aprendizagem num contexto de inovao curricular. Lisboa: APM. 1992. LEAL, M. L. Portflio ou Pasta do Educando. Educao e Matemtica, 42, 11-12. Lisboa. 1997. LUCKESI, C.C. Avaliao da aprendizagem escolar. 14 ed. So Paulo:Cortez, 2002. PELEGRINI, D. . Avaliar para ensinar, no para dar nota. In: A Revista do Professor Nova Escola, n 159 jan/fev, 2002. POLATO, A. O que ensinar em matemtica. Revista Nova Escola. Ed. 216, out. 2008. Disponvel em: <http://revistaescola.abril.com.br/matematica/fundamentos/assimturma-aprende-mesmo-panoramas-perspectivas-427209.shtml >. Acesso em: 12 jan. 2011. SALINAS, D. Prova amanh: entre a teoria e a realidade. Porto Alegre: Artmed, 2004. SANTOS, L.. Auto-avaliao regulada: porqu, o qu e como? In P. Abrantes & F. Arajo (Coords.), Avaliao das aprendizagens, das concepes s prticas (pp. 75-84). Lisboa: Ministrio da Educao e Departamento da Educao Bsica. 2002. SOUSA, S. Z. L. Revisando a teoria da avaliao da aprendizagem: In Clarilza Prado Souza. (Org.) Avaliao do Rendimento Escolar 2 ed. Campinas SP: Papirus, 1991 (Coleo Magistrio: formao e trabalho pedaggico) SOUZA, C. P. de (org). Avaliao do rendimento escolar. 3 ed. Campinas: Papirus, 1993. VALADARES, J. & GRAA, M. Avaliando para melhorar a aprendizagem. Lisboa: Pltano Edies Tcnicas. 1999. VARANDAS, J. M. Avaliao de investigaes matemticas: Uma Experincia. Lisboa. 2000. [24] VILLAS BOAS, B. M . Portflio, avaliao e trabalho pedaggico. Campinas: Papirus, 2004.
25
[2] [3] [4] [5] [6]
[7] [8]
[9] [10] [11] [12]
[13] [14] [15] [16] [17]
[18] [19]
[20]
[21] [22] [23]
26
Gerenciamento de Desvios em Malha Frrea Utilizando Agentes Autnomos Reativos

Jean Paul Barddal, Fabrcio Enembreck
Resumo Um dos principais desafios das empresas do setor

ferrovirio de transporte gerenciar a ocupao da malha ferroviria e maximizar o nmero de trens em circulao com segurana simultnea, podendo assim maximizar tambm a receita gerada e minimizar o consumo de combustvel. Este artigo apresenta uma soluo computacional de alto nvel de abstrao para gerar e verificar empiricamente a otimizao do controle automatizado de gerenciamento ferrovirio. apresentado um ambiente de simulao baseado em agentes autnomos reativos. O modelo apresentado permite a execuo de diversas simulaes com parmetros aleatrios de modo automtico. Foram extrados dados relacionados a mtricas de tempo de espera com o propsito de verificar empiricamente o modelo. Para realizar uma anlise do comportamento do sistema multiagente, foram tomados valores para 120 simulaes a fim de verificar a eficcia do mesmo. Com o auxlio do teste T de Student verificou-se que o comportamento atingiu as expectativas do projeto. O sistema multiagente provou-se robusto e eficiente tanto em termos de segurana quanto de otimizao das vias. A interface do ambiente de simulao bastante verstil e permite o fcil entendimento das mtricas adotadas e do funcionamento geral do sistema.
Palavras chave Sistemas multiagente, Inteligncia artificial distribuda, sistemas inteligentes de controle, trens de carga.
I. INTRODUO
dos principais desafios das empresas do setor ferrovirio de transporte gerenciar a ocupao da malha ferroviria e maximizar o nmero de trens em circulao simultnea com segurana, podendo assim maximizar tambm a receita gerada [2]. Na maioria das empresas o controle das vias feito manualmente, atravs de uma central de controle. Geralmente uma via frrea dividida em sees de bloqueio (segmentos de via) que possuem sinalizao especfica e desvios que facilitam a passagem dos trens que podem circular no mesmo ou sentido contrrio de um trem tido como referncia. Para que trens no acabem realizando colises frontais entre si, empresas do ramo ferrovirio acabam realizando planejamento das rotas dos trens
M Recebido em: 26 de Setembro de 2012. Esse trabalho apoiado pelo CNPq e pela PUC-PR. J. P. Barddal aluno de graduao em Cincia da Computao da Escola Politcnica, Pontifcia Universidade Catlica do Paran, 80215-901, CuritibaPR (e-mail: jpbarddal@terra.com.br). F. Enembreck professor pesquisador do Programa de Ps-Graduao em Informtica (PPGIa) da Pontifcia Universidade Catlica do Paran, 802150901, Curitiba-PR (e-mail: fabricio@ppgia.pucpr.br).
manualmente e diversas equipes so responsveis por verificar e efetuar mudanas caso existam atrasos em relao aos horrios [1]. Um dos principais pontos positivos da adoo de um sistema multi-agente o aproveitamento das informaes que cada trem possui. Em abordagens centralizadas, cada trem tende a utilizar as informaes sobre outros trens para seu prprio benefcio. Em uma abordagem descentralizada, os trens se comunicam os outros e tomam decises em conjunto, tendendo a beneficiar o sistema como um todo [7]. Outro problema do controle das malhas frreas o consumo de combustvel dos trens. Tal problema deve-se aos condutores. Empresas como a Amrica Latina Logstica (ALL) realizam torneios como a Copa Diesel, onde os maquinistas da empresa competem entre si. Em cada viagem, computa-se a quantidade de diesel gasto, que pode variar em at 20%, conforme o uso do freio e a velocidade da locomotiva [11]. Ganha um bnus quem conseguir gastar menos por quilmetro rodado. A Copa Diesel simples e eficaz resultou numa economia de 11% no consumo de combustvel. As aes de um maquinista ao conduzir o trem influem diretamente em seu consumo. Todavia, outra causa do consumo excessivo de combustvel so as paradas que os trens so obrigados a fazer durante as viagens [8]. Mesmo com a existncia de inmeros trabalhos propostos com estratgias para alcanar eficincia energtica em sistemas ferrovirios, eles permanecem incompletos ou insuficientes devido s restries impostas pelo desenvolvimento dos modelos. Deste modo, novas solues para melhorar a eficincia do consumo de fontes energticas no transporte ferrovirio so imprescindveis [5]. Este artigo apresenta uma soluo computacional de alto nvel de abstrao para gerar e verificar empiricamente a otimizao do controle automatizado de gerenciamento ferrovirio. Para atingir este objetivo, foi construdo um ambiente de simulao baseado em agentes autnomos reativos. O gerenciamento trata do uso de desvios para eliminar a possibilidade de colises frontais, tratamento de cruzamentos, segurana e a otimizao de rotas. Como resultado, o trabalho realizado estabelece uma viso simplificada de controle e uma interface amigvel de simulao de como funciona a automatizao do uso da malha ferroviria atravs de uma abordagem feita com agentes reativos. II. OBJETIVOS O objetivo inicial deste projeto era desenvolver um modelo de agentes autnomos reativos que fosse capaz de gerenciar o uso de desvios existentes em uma via frrea sem a interveno

humana e de forma descentralizada. Para este projeto os agentes de software percebem o ambiente e tomam decises autnomas baseadas no estado do ambiente, em objetivos locais e prioridades estabelecidas para os trens. A plataforma de desenvolvimento adotada foi o NetLogo, ambiente de desenvolvimento e testes de sistemas multiagente [6]. Os comportamentos dos agentes devem garantir a segurana da viagem de todos os trens, evitando colises e maximizando a utilizao da via. O software de simulao deve permitir ao usurio acompanhar a execuo da simulao com interface amigvel, sendo adicionadas funes para facilitar o entendimento de mtricas como tempo mdio de espera e tempo mdio ponderado de espera do sistema.
27
estas aes no ambiente, o agente conta com atuadores, que modificam o ambiente ao seu redor. Em um nvel de abstrao mais elevado, um agente, fazendo-se uso de sensores de um tipo qualquer, consegue retirar alguma informao do mundo a sua volta, e executa uma ao para atingir um determinado objetivo, entrando assim num estado de satisfao [13]. Um diagrama deste tipo de agente de software apresentado na Figura 2.
III. FUNDAMENTAO TERICA SOLOMON et al descrevem o sistema mais utilizado para gerenciamento de sees de bloqueio, o denominado Interlocking. O sistema interlocking implantado a partir de um complexo modelo de sinalizao ferroviria que pode ser descrito como um conjunto de sinais e suas respectivas aplicaes que geram movimentaes em determinada sequncia para os trens, para que os mesmos se movimentem de maneira apropriada. Os principais fundamentos do interlocking so: Sinais no podem ser gerados a forma de que exista conflitos entre movimentos de trens diferentes; todas as sinalizaes da via devem ser devidamente atualizadas aps a tomada de deciso; uma vez que as sinalizaes foram atualizadas, as mesmas s podem ser modificadas aps o trmino da movimentao do trem que a estava utilizando [10]. Um exemplo de desvio entre vias frreas apresentado na figura 1. Para o desenvolvimento de uma abordagem que seja bastante prxima do interlocking e utilizando agentes reativos, um estudo inicial sobre a arquitetura de agentes fez-se necessrio.
Fig. 2. Diagrama esquemtico de um agente reativo simples. Adaptado de [9].
Ferber institui alguns pontos necessrios para um agente de software [3]: atuar ao seu redor; pode se comunicar diretamente com outros agentes; definido por um conjunto de regras para atingir um grau de satisfao; tem seus prprios recursos; capaz de perceber o seu redor, mesmo que seja de forma limitada; possui apenas uma representao do seu redor, ou at mesmo, nenhuma; possui habilidades e oferece servios; possui a capacidade de se reproduzir; possui comportamento que tende a satisfazer seus objetivos, fazendo-se uso de todos os pontos relacionados acima; Tomando ainda Ferber como referncia, o autor define o conceito de sistema multiagente como um sistema formado pelos seguintes elementos [3]: Um ambiente, definido por um espao que possui volume; Um conjunto de objetos passivos situados nesse ambiente, que possuem posio bem definida, que podem ser percebidos, criados, destrudos e modificados pelos agentes; Um conjunto de objetos, desta vez ativos, que representam a parte funcional do sistema, ou seja, os agentes; Um conjunto de relaes que estabelecem conexes entre qualquer tipo de objeto do sistema; Um conjunto de operaes que podem ser realizadas pelos agentes para manipular os objetos passivos do sistema; Operadores com a funo de representar a
Fig. 1. Exemplo de desvio entre vias frreas [10].
Segundo Wooldridge, um agente um sistema computacional situado em um ambiente e que capaz de desenvolver aes autnomas neste ambiente para atingir seus objetivos. Para obter informaes do ambiente a sua volta, o agente faz uso de sensores, que obtm informaes sobre uma parcela do ambiente ao redor do agente. Para desenvolver

funcionalidade das operaes e a reao do ambiente a esta tentativa de mudana; A adoo da abordagem de sistema multiagente derivada dos estudos do ramo de Inteligncia Artificial, que encontrou nesta mesma abordagem um mtodo de se aproximar da capacidade humana de trabalhar em sociedade. Ns (seres humanos) somos capazes de nos comunicarmos em linguagens de alto nvel, podendo cooperar, coordenar e negociar entre si [13]. As habilidades de comunicao, cooperao, coordenao e negociao entre os agentes so essenciais para a soluo apresentada. Em um ambiente multi-agentes o processo de coordenao entre os agentes dado pelos processos de cooperao e/ou competio. Nos processos de cooperao, os agentes compartilham informaes e/ou resultados com a finalidade de obter um objetivo em comum. Nos processos de competio, os agentes disputam por um recurso ou por executar uma tarefa que resulte na satisfao de seus objetivos ou metas [4]. Neste projeto a cooperao ser dada pela troca de informaes sobre prioridades, e tais dados sero base para a competio, ou seja, quanto maior a prioridade de um trem, antes ele tender a atingir seu objetivo. Tal modelo foi implementado utilizando-se a plataforma NetLogo [6]. NetLogo um software desenvolvido pela Northwestern University do estado de Illinois, Estados Unidos. uma plataforma de desenvolvimento de sistema multiagente interessante para desenvolvimento de sistemas complexos. O desenvolvedor capaz de dar instrues para diversos agentes que operam independentemente. Deste modo possvel explorar as conexes entre os indivduos numa escala pequena, at uma macro escala, reconhecendo o resultado de tais interaes. IV. METODOLOGIA Durante a implementao do projeto, adotou-se a representao de um grafo conexo para representar a malha ferroviria com todos seus desvios e sees de bloqueio. Visualmente, cada crculo representa uma seo de bloqueio (Figura 2), podendo ser ou no, um ponto de entrada ou sada de desvio. Cada conexo, ou seja, link, entre sees de bloqueio representa um trecho de via frrea. Quanto ao desenvolvimento dos comportamentos reativos especficos do projeto, vrios conjuntos de regras foram testados, entretanto desenvolver uma simulao em tempo real tornaria o controle do tempo ineficiente, logo, uma simulao simplificada com eventos discretos foi adotada. Deste modo, os trens realizam movimentos entre arestas do grafo - que simula a malha ferroviria - a cada ciclo de execuo da simulao. Um problema encontrado durante a implementao reativa na tecnologia NetLogo o pseudoparalelismo da execuo das instrues ask. Por exemplo, a instruo ask simula uma requisio para um conjunto de agentes para que todos realizem o mesmo conjunto de instrues, formando assim o comportamento geral do sistema. O problema encontrado que, por ter sido adotada uma abordagem
Fig. 4. Exemplo indevido de execuo.
28
discreta, alguns bloqueios foram percebidos, o que poderia comprometer a simulao tendo em vista a sequncia aleatria de processamento dos agentes. Uma vez que os trens desenvolvem saltos discretos, dependendo da ordem que os mesmos efetuam estes saltos, um deles pode acabar eliminando a possibilidade de movimentao de um prximo, ou pelo contrrio, habilitando a movimentao. As figuras 4 e 5 mostram situaes reais encontradas em simulaes. Analisando-se primeiramente a figura 3, percebe-se que dois trens possuem mesmo sentido, e esto em trechos de vias frreas adjacentes. Na figura 4, tm-se um comportamento indevido dos trens, onde apenas um deles se moveu, e o outro trem realizou uma percepo errada do espao livre que existe a sua frente. A situao apresentada na figura 4 decorre do fato da ordem estocstica em que o ambiente de simulao faz requisies para os trens. Na figura 5, a situao adequada, onde ambos os trens fizeram sua movimentao devidamente pelo grafo.
Fig. 3. Ambiente na sua configurao inicial de testes.
Fig. 5. Exemplo de execuo devido.
Deste modo, uma abordagem iterativa foi estudada e analisada, e parece cumprir o propsito necessrio da simulao. A partir de tais concluses, fez-se um estudo para programar um comportamento cujo objetivo fosse corrigir tais execues fazendo com que sempre trouxessem o mesmo resultado. Para tal feito, adotou-se um comportamento para quando os trens esto em formato de fila, ou seja, esto enfileirados com um mesmo sentido.

Novamente, por se tratar de uma simulao com saltos discretos, a sada encontrada foi a determinao de uma lgica recursiva para os trens. Esta lgica de fcil entendimento e se baseia na seguinte ideia: Existe um trem a minha frente, solicito que o mesmo se movimente, se o mesmo no se movimentar, logo tambm devo permanecer parado, em caso contrrio, ocuparei o prximo link. Deste modo, o ciclo de execuo utilizaria a instruo ask para requisitar a movimentao dos trens, e caso um trem perceba que est dentro de uma fila, requisita a movimentao do trem sua frente, e caso o mesmo no se movimente, o mesmo tambm ser incapaz de se movimentar. Tal comportamento se mostrou bastante eficiente, e seus resultados sero discutidos nas posteriores sees deste artigo. importante ressaltar que este comportamento de fila vlido para todo e qualquer tipo de situao que pode vir a ocorrer nas simulaes, seja em desvios, cruzamentos ou vias frreas simples. Com a resoluo deste problema, restou a implementao dos comportamentos relativos desvios e cruzamentos, a parte mais crtica do projeto. Iniciou-se com o problema do cruzamento, uma vez que a simulao discreta, no possvel que mais de um trem faa uso de um cruzamento por ciclo de execuo, uma vez que tal situao no mundo real seria uma coliso. A partir de tal fato, a abordagem adotada foi a adio de uma varivel de controle nos spots de cruzamento. Tal varivel de controle possui a funo de armazenar um valor que representa o fato de se ele j foi utilizado naquele ciclo de execuo, sendo inicializado com valor nulo a cada novo ciclo. Tomamos como exemplo o modelo de comunicao por marca no ambiente. Posteriormente o trabalho foi focado na resoluo do comportamento para o funcionamento dos desvios. O comportamento dos trens para com os desvios tambm bastante simples. Na primeira verso do comportamento pensou-se em levar em conta o caminho mais curto, verificando se o caminho est vazio, e em caso positivo, o mesmo seria utilizado. Caso contrrio, seria verificado se o caminho mais comprido, ou seja, o desvio em si, poderia ser utilizado. Antes mesmo de ser programado verificou-se que tal comportamento seria inadequado, uma vez que se existisse dois trens, um j ocupando o desvio, e outro verificando tais condies, o mesmo utilizaria o caminho mais curto, gerando assim um problema de deadlock, caso um trem viesse a concorrer por uma posio neste mesmo desvio. Tal configurao de deadlock apresentada na figura 6.
29
ordem contrria, ou seja, dever-se-ia primeiramente verificar o estado do caminho mais comprido (desvio em si) e posteriormente o estado do caminho mais curto, e baseando-se em tais informaes do ambiente, o trem deveria ser capaz de tomar uma deciso vlida. Adotou-se neste ponto os casos possveis apresentados na Tabela 1.
TABELA 1 Estados possveis e respectivos comportamentos dos trens Estado do caminho Estado do desvio Ao mais curto Tenta se movimentar Trem com mesmo Trem com sentido para o caminho mais sentido contrrio curto Tenta se movimentar Trem com mesmo Vazio para o caminho mais sentido curto Trem com sentido Trem com mesmo Tenta se movimentar contrrio sentido para o desvio Trem com sentido Se movimenta para o Vazio contrrio desvio Trem com mesmo Se movimenta para o Vazio sentido desvio Se movimenta Trem com sentido Vazio utilizando o caminho contrrio mais curto Se movimenta Vazio Vazio utilizando o caminho mais curto
Percebe-se que na Tabela 1 existem combinaes possveis que no so apresentadas, uma vez que o prprio comportamento dos trens no os permite, pois causam deadlocks. Tais estados esto listados na tabela 2.
TABELA 2 Estados impossveis Estado do caminho mais curto Estado do desvio Trem com mesmo sentido Trem com mesmo sentido Trem com sentido contrrio Trem com sentido contrrio
Fig. 6. Problema de deadlock. descrito pelo caso onde nenhum dos trens pode se movimentar sem que exista uma coliso, logo nenhum dos trens se movimentar.
Percebeu-se ento que a verificao deveria ser feita na
importante ressaltar neste ponto que existem muitas aes em comum entre diversos estados possveis de um agente, deste modo, seria interessante definir um trecho de cdigo que fosse genrico, entretanto uma das limitaes da plataforma NetLogo a no existncia de passagem de parmetros e valores de retorno em trechos de cdigo. Deste modo, o mesmo cdigo teve de ser repetido, dificultando seu entendimento. A partir destas regras, puderam-se ter os comportamentos dos trens em sua totalidade. Uma vez que todos os comportamentos foram programados, pde-se criar uma interface mais amigvel com o intuito de testar e provar empiricamente o funcionamento do sistema como um todo. Para tal propsito fez-se uso das Equaes 1 e 2 apresentadas, com o objetivo de se estabelecer mtricas para verificao dos tempos de espera do sistema. As medidas de tempo de espera mdio e tempo de espera mdio ponderado do sistema representam a porcentagem do tempo em que o sistema est esttico, ou seja, alguns dos trens presentes no esto em movimento. No caso da mtrica de tempo de espera mdio

ponderado, cada trem possui uma prioridade, ou seja, uma urgncia para chegar ao seu destino. Adotou-se neste projeto que quanto maior o valor da prioridade de um trem, maior sua urgncia dentro do sistema. A equao 1 apresenta o clculo do tempo de espera global do sistema, j a equao 2 apresenta o clculo do tempo de espera ponderado global do sistema, ou seja, a mtrica em que as urgncias dos trens so levadas em considerao.
30
aproximadamente 15,55% do seu tempo foi gasto em espera. Uma vez que as mtricas foram implementadas com sucesso, para facilitar a visualizao e compreenso do usurio, foram adicionados grficos que so atualizados a cada ciclo de execuo, sendo tais mtricas atualizadas constantemente. Na figura 8 apresentado um exemplo de grfico para execuo apresentando a mtrica de tempo mdio de espera do sistema, j a figura 9 apresenta um grfico para a mesma execuo apresentando a mtrica de tempo mdio de espera ponderado.
Equao 1 Equao de tempo de espera global do sistema.
As variveis envolvidas na equao 1 so: n: Quantidade de trens no sistema T: Conjunto de trens participantes do conjunto ti: Trem participante do conjunto T
Fig. 8. Grfico de tempo mdio de espera.
Equao 2 Equao de tempo de espera ponderado global do sistema.
As variveis envolvidas na equao 2 so: n: Quantidade de trens no sistema T: conjunto de trens participantes do conjunto ti: Trem participante do conjunto T pi: Prioridade do trem ti pmx: Maior prioridade dentre as prioridades dos trens do conjunto T Para fazer uso das equaes 1 e 2, fez-se necessrio conhecer a quantidade de movimentos realizados e quantos movimentos deixaram de ser realizados desde o incio da simulao. Para tal feito, adicionou-se em cada trem uma lista de movimentos, onde cada ciclo de execuo que o trem se movimentou representado por um nmero 1 (um) e cada ciclo sem movimentao representado por um nmero 0 (zero). Vale ressaltar que os valores de no movimentao so apenas armazenados na lista caso j exista um valor de movimentao na mesma, ou seja, o sistema no penalizado pelo trem que esteja inerte desde o incio da simulao. Um exemplo de lista de movimentos de um trem apresentado na Figura 6.
Fig. 9. Grfico de tempo mdio de espera ponderado.
Finalizado o comportamento e as mtricas, fez-se necessrio um trabalho de validao do experimento. Para facilitar a obteno de dados para posterior anlise, a interface foi aprimorada para possibilitar simulaes com diferentes quantidades de execues e apresentao de tais dados em forma de arquivo externo em formato CSV (comma-separated values). A escolha da adoo de tal formato dada pelo fato de que o mesmo compatvel com a ferramenta Excel, facilitando assim o trabalho do teste de hiptese, que ser apresentado posteriormente. A figura 10 apresenta a interface de simulao terminada.
Fig. 7. Exemplo de lista de movimentos de um trem.
Percebe-se que na figura 7 apresenta-se uma lista de movimentos de um trem qualquer que por sua vez esteve ativo por 7 (sete) ciclos dentre 9 (nove) totais de execuo em uma simulao. Adotando-se a Equao 1 em nvel local, ou seja, somente para este trem, infere-se que o mesmo possui aproximadamente 22,2% de seu tempo gasto em espera. Adotando-se para um exemplo, que o mesmo trem possui uma prioridade de valor 7 (sete), num intervalo possvel entre 1 (um) e 10 (dez), sendo este o limite mximo e aquele o limite mnimo, utilizando a equao 2 em nvel local inferimos que
Fig. 10. Interface final da simulao.
Os arquivos gerados pela simulao so compostos por trs colunas, o primeiro arquivo relativo aos tempos mdios de

espera e o segundo arquivo relativo ao tempo de espera mdio ponderado. O motivo para tal construo ser apresentado na seo de resultados deste artigo, uma vez que ela faz parte da avaliao do modelo. Um problema encontrado no trmino do projeto foi a existncia de outro tipo de deadlock. O problema encontrado decorrente do grande nmero de trens acessando um mesmo segmento de via e bastante especfico, ocorre somente quando existem 8 (oito) ou mais trens disputando um desvio sendo que cada metade deste conjunto possui o mesmo sentido e esto em comportamento de fila. Este deadlock gerado estritamente pelo fato de que a disposio dos trens feita de modo aleatrio e no pelo comportamento em si, que tenta exatamente eliminar este tipo de problema. Este tipo de deadlock est apresentado visualmente na figura 11. Uma vez que este deadlock detectado durante uma simulao, a mesma representada no arquivo pelo valor -1 (menos um) e sua execuo descartada, passando assim para uma prxima disposio de trens, se houver.
31
diferentes prioridades tende a simplificar o problema, sendo esperado que essas configuraes produzam resultados melhores do que aqueles onde os trens possuem a mesma prioridade, pois introduzem mais informao no processo decentralizado de tomada de deciso. Para o teste de hiptese citado anteriormente, foram realizadas tomadas de dados com o propsito de se obter 20 (vinte) execues vlidas, cada uma composta pelas trs configuraes apresentadas previamente, para trs quantidades diferentes de trens: 15 trens 17 trens 20 trens A tomada de dados para 15 trens apresentada nos apndices A e B. A tomada de dados para 17 trens apresentada nos apndices C e D. Finalmente a tomada de dados para 20 trens apresentada nos apndices E e F. VI. DISCUSSO A partir dos dados apresentados na seo de resultados adotou-se um fator de confiana de 95% para o teste de hiptese de Student. O teste T de Student utiliza conceitos estatsticos para rejeitar ou no uma hiptese nula [12]. As tabelas 3, 4 e 5 apresentam os intervalos para os dados obtidos das simulaes. Os smbolos P3, P2 e P1 indicam a quantidade de prioridades existente em cada cenrio: 3, 2 e 1 respectivamente. Quando os limites do intervalo so menores que 0 (zero), pode-se afirmar que os tempos do primeiro cenrio so significativamente menores do que os tempos do segundo cenrio. Por outro lado, se 0 (zero) est entre os limites do intervalo, no h diferena significativa entre os cenrios e, no terceiro caso, (0 menor que os limites do intervalo), o segundo cenrio melhor que o primeiro. Percebeu-se ento que os tempos de espera realmente so otimizados quando os comportamentos utilizam as prioridades dos trens, sendo que P3 melhor que P2 e P2 melhor que P1, em todos os experimentos realizados. Conclui-se ento que os trens tendem a continuar em movimento, pois o tempo mdio de espera do sistema significativamente menor. Em termos prticos isso melhora o consumo mdio de combustvel do sistema e permite que um conjunto maior de trens ocupe o mesmo trecho de malha, minimizando os principais problemas definidos nos objetivos deste trabalho.
TABELA 3 Intervalos de confiana para simulaes com 15 trens # de trens 15 Tipo de Normal Ponderada exper. Prioridades P3 e P2 P2 e P1 P3 e P2 P2 e P1 Int. de [-10,00;[-2,78;-0,65] [-2,60;-0,61] [-8,00;-2,00] conf. 0,7]
Fig. 11. Exemplo de deadlock. Neste caso de deadlock, sua ocorrncia causada pela quantidade excessiva de trens e sua distribuio ser aleatria.
V. RESULTADOS Uma vez que as mtricas foram implementadas e testadas e se mostrando coerentes com o estudo, e com uma interface capaz de gerar diversas quantidades de execues, fez-se necessrio realizar um teste verificando se a execuo dos trens com diferentes prioridades realmente influencia o resultado final da simulao. Para tal realizao, adotou-se que cada execuo da simulao deveria ser divida em 3 (trs) configuraes, a primeira realizando a tomada de dados com todos os trens em um mesmo nvel de prioridade, a segunda com dois nveis de prioridade e a ltima com trs nveis de prioridade. Percebe-se nos apndices A, B, C, D, E e F trs colunas com valores, a primeira coluna est relacionada com a primeira configurao e assim por conseguinte. Para realizao de um teste emprico de hiptese fez-se uso do teste T de Student tentando provar que a execuo de uma simulao com as prioridades diferentes significativamente melhor do que uma simulao onde todos os trens apresentam a mesma prioridade. Uma vez que o arquivo de tomada de dados fornece dados sobre uma mesma disposio de trens, e um valor de tempo de espera para cada configurao de prioridades, podese testar se a configurao com 3 (trs) nveis de prioridade melhor que a configurao com 2 (dois) nveis. Analogamente pode-se verificar se a configurao com 2 (dois) nveis melhor que a de somente 1 (um) nvel. Deste modo, por induo, pode-se comprovar que os comportamentos so vlidos e os resultados pertinentes, ou seja, realmente otimizam a utilizao dos desvios. A existncia de trens com

TABELA 4 Intervalos de confiana para simulaes com 17 trens # de trens 17 Tipo de Normal Ponderada exper. Prioridades P3 e P2 P2 e P1 P3 e P2 P2 e P1 Int. de [-13,75;[-9,62;[-3,56;-1,58] [-3,92;-1,29] conf. 7,77] 3,98] TABELA 5 Intervalos de confiana para simulaes com 20 trens # de trens 20 Tipo de Normal Ponderada exper. Prioridades P3 e P2 P2 e P1 P3 e P2 P2 e P1 [-16,85;[-12,93;Int. de conf. [-4,45;-0,67] [-2,94;-0,19] 10,88] 1,94]
32
APNDICE
APNDICE A Tempos mdios de espera obtidos 15 trens 1 nvel de prioridade 2 nveis de prioridade 3 nveis de (%) (%) prioridade(%) 16,24 15,52 13,27 14,41 12,93 10,38 15,91 11,4 8,85 25 23,3 23,3 18,71 18,45 16,27 18,49 13,45 11,61 23,14 19,13 11,65 14,29 9,59 7,04 15,76 15,24 10,9 17,79 17,28 15,72 13,04 13,04 13,04 17,46 17,02 11,86 8,59 8,8 8,06 28,81 28 26,32 12,88 12,88 12,88 7,41 8,26 5,66 16,79 14,17 14,84 17,89 19,51 23,62 17,48 10,53 10,53 13,27 10,48 10,91 APNDICE B Tempos mdios de espera ponderados obtidos 15 trens 1 nvel de prioridade 2 nveis de prioridade 3 nveis de prioridade (%) (%) (%) 18 8,89 6,44 15 7,67 5,56 30,14 11,14 14,89 26,12 12,11 10,44 28,11 11,78 7,89 18,24 24,44 9,44 35 26,44 17,11 49 25,89 15,67 18 38,44 17,11 18,31 31,33 7,11 23 16,44 10,33 23 14,89 15,22 5 2,89 1,1 10 7,78 4,56 26 19,11 21,44 19 27,56 17 25 23 18,33 6 4,78 5,22 17 12,89 7,33 54 30,56 31,67
Uma vez que os resultados foram satisfatrios para o modelo de sistema multiagente pde-se verificar que um comportamento robusto foi criado e que atendeu as expectativas iniciais do projeto, como verificado anteriormente. VII. CONCLUSO Como apresentado nas sees anteriores, o sistema proposto robusto e atende os requisitos iniciais do projeto. Os agentes propostos so autnomos e atuam de forma descentralizada. O comportamento dos agentes se demonstrou extremamente eficiente em termos de segurana sendo que em nenhuma das simulaes vlidas qualquer tipo de coliso foi encontrada. O comportamento assim prov uma maximizao da utilizao das vias frreas, e tal resultado percebido pelo fato de que o tempo de espera dos trens minimizado. A simulao possui uma interface amigvel cujo principal propsito de facilitar o entendimento e apresentao das mtricas de tempos de espera adotados. Todavia importante ressaltar que existe a possibilidade que este modelo apresentado no ser o mais verossmil com sistemas reais de transporte ferrovirio por se tratar de uma simulao discreta. Partindo-se deste ponto, ressalta-se o interesse de transportar esse modelo para uma simulao contnua, tendo este projeto como base adicionando-se assim controles de acelerao e frenagem tentando assim verificar a influncia do modelo apresentado.

APNDICE C Tempos mdios de espera obtidos 17 trens 1 nvel de prioridade 2 nveis de prioridade 3 nveis de prioridade (%) (%) (%) 32,09 27,5 26,38 17,65 14,86 11,89 26,15 29,5 21,95 26,14 25,5 22,92 14,5 14,29 8,06 32,24 22,56 17,69 32,18 26,51 26,38 10,32 9,17 7,63 24,06 19,59 17,58 18,77 16,67 14,73 15 15 14,39 38,6 29,47 28,78 20,63 19,62 12,59 15,03 12,75 11,56 24,46 22,78 19,65 27,89 26,92 23,56 11,97 10,07 7,41 18,06 16,44 16,44 29,33 27,4 24,82 21,3 18,27 18,27 APNDICE D Tempos mdios de espera ponderados obtidos 17 trens 1 nvel de prioridade 2 nveis de prioridade 3 nveis de prioridade (%) (%) (%) 60 34,56 28,89 27 17 7,11 34 28,78 13,44 38 26,33 23,22 18 7 5 31,11 23 22,22 59 52,33 44,33 20 15,44 11,44 26 13,11 7,78 45 22 15,67 45 37,11 34,78 43 41,56 12 31 25,22 10,44 23 10,33 8 41 25,67 24,11 49 30,44 26,78 14 8,44 7,22 27 24,56 15 26 14 11,22 44 28,89 21 APNDICE E
33
Tempos mdios de espera obtidos 20 trens 1 nvel de prioridade 2 nveis de prioridade 3 nveis de prioridade (%) (%) (%) 21,09 20,57 22,45 15,79 12,06 16 22,55 25,39 23,53 19,25 19,89 18,13 10,77 10,94 13,43 30,41 25 22,41 26,63 23,84 23,56 14,75 13,84 12,6 15,57 7,43 10,32 17,53 12,59 14,38 21,76 21,22 20,6 37,89 29,11 16,85 24,64 23,56 21,17 19,07 19,25 15,42 22,7 17,54 12,64 26,35 24,14 22,39 18,52 17,65 16,67 24,82 23,53 11,86 17,76 16,2 19,59 28,73 21,51 19,88 APNDICE F Tempos mdios de espera ponderados obtidos 20 trens 1 nvel de prioridade 2 nveis de prioridade 3 nveis de prioridade (%) (%) (%) 31 17,89 16,33 24 14,44 14,22 49,33 46 25,22 36 27 21,89 14 9,56 8,33 59 33,33 24,89 49 23,78 18,67 27 25,53 20,64 26 9,33 8,56 27 11,33 8 97 41,33 26 52 37,33 30,3 30,36 25,84 19,44 41 29,89 14,89 42 36,33 27,78 46 18,89 13,3 46,3 42,22 24,22 25,22 19 8 20 9,78 8,11 24 17,78 9
REFERNCIAS
[1] ABBINK, E. MOBACH, D. FIOOLE, P. KROON L. HEIJDEN E. WIJNGAARDS N. "Actor-agent for train driver rescheduling". Publicado em: AAMAS '09, Erasmus University Rotterdam, Netherlands, Volume 1, p. 513-520. 2009. BARDDAL, J. P. ENEMBRECK, F. "Gerenciamento de desvios em malha frrea: uma abordagem baseada em agentes autnomos reativos". Publicado em: XX SEMIC. Disponvel em: <http://www2.pucpr.br/reol/semic/trabalho.php?dd0=6431&dd90=be8c7 64061&dd10=view.html> Acesso em: 7 dez. 2012. FERBER, J. Multi-agent systems: An introduction to Distributed Artificial Intelligence. 1 edio. New York: Editora Addison Wesley Longman, 1999. 509 p. GUERRERO, J. DOMNGUEZ, L. GUDWIN, R. GOMIDE, F. "Controle de trfego de trens utilizando sistemas multi-agentes". Publicado em: Agent's Day - CBComp 2002. Campinas: UNICAMP, 2002. LEITE, A. "Um esquema para reduo do consumo de combustvel em sistemas de conduo frrea baseado em otimizao distribuda de restrio". Curitiba: Pontifcia Universidade Catlica do Paran. 2009.
[2]
[3]
[4]
[5]

85 f. Dissertao (Mestrado em Informtica) - Programa de PsGraduao em Informtica, Pontifcia Universidade Catlica do Paran, 2009. NORTHWESTERN University. NETLOGO. Chicago, Illinois. Disponvel em: <http://ccl.northwestern.edu/netlogo/> Acesso em: 2 fev. 2012. PARKES, D. UNGAR, L. "An auction-based method for descentralized trains scheduling". Agents '01, New York: NY, USA, p. 43-50, 2001. PEREIRA, O. C. Solues de Otimizao da Eficincia Energtica de uma Ferrovia de Carga. Dissertao de Mestrado. Ri o de Janeiro: Pontifcia Universidade Catlica do Rio de Janeiro, 2009. RUSSELL, S. NORVIG, P. Inteligncia artificial. 2 edio. Rio de Janeiro: Editora Campus-Elsevier, 2004. 1021 p. SOLOMON, B. Railroad signaling. 1 edio. Minneapolis: Editora Voyageur Press, 2010. 160 p. TODESCHINI, M. Nos trilhos da ALL. Disponvel em: <http://epocanegocios.globo.com/Revista/Common/0,,EMI7144816642-3,00-NOS+TRILHOS+DA+ALL.html> WILCOX, Rand R. Introduction to Robust Estimation and Hypothesis Testing. 1 ed. San Diego, California: Academic Press, 1997. 296 p. WOOLDRIDGE, M. "Multiagent Systems". 2a edio. West Sussex, United Kingdom:Wiley, 2009. 484 p.
34
[6]
[7] [8]
[9] [10] [11]
[12] [13]
35
Um estudo sobre testes de desempenho com aplicao prtica utilizando a ferramenta JMeter
Evandro Grezeli de Barros Neves e Regiane Aparecida Marucci
ResumoEste artigo descreve o resultado de um estudo sobre testes de desempenho aplicado teste de desempenho aplicado em uma arquitetura e-commerce hipottica utilizando uma ferramenta de apoio, chamada JMeter. Com as informaes geradas como resultado desta execuo, foi utilizada como dados de entrada para o desenvolvimento de um aplicativo que apresenta grficos gerenciais de tempo de resposta da aplicao testada. Palavras-chave Teste de Software. Teste No Funcional. JMeter. Desempenho.
I.
INTRODUO
c. Teste de Confiabilidade e Disponibilidade; d. Teste de Recuperao; e. Teste de Contingncia; c) Teste de Compatibilidade (Versionamento); d) Teste de Segurana; e) Teste de Instalao; Os testes de caixa branca[3], consiste em avaliar o comportamento interno dos componentes do software. Diferentemente do teste de caixa preta, que apenas verifica a sada (output) em relao entrada (input), o teste estrutural consiste em destrinchar o cdigo fonte, fazendo com que a entrada passe por todos os caminhos lgicos desenvolvidos no software, como pode ser visto na figura 1.
"Teste de Software o processo com o intuito de encontrar erros em um programa ou sistema em execuo [1]. Esta definio citada por Myers refora o motivo pelo qual cada dia mais empresas se preocupam com a qualidade do seu software, investindo em grandes equipes para encontrar os defeitos inseridos em tempo de programao, seja por m interpretao da especificao funcional ou falta de mo de obra qualificada. Por falta de tempo de cronograma de projeto ou por pouca experincia da equipe de desenvolvimento envolvida, as fbricas de software se preocupam em entregar o sistema conforme o esperado, porm no se preocupando em como o produto foi desenvolvido. Por estes motivos, muitos dos sistemas hoje em produo, acabam tendo problemas de desempenho e mesmo de segurana, por no ter tido uma validao destes requisitos ainda no seu ciclo de testes. Diante do que foi exposto, este artigo expe uma breve descrio das melhores prticas propostas por autores brasileiros e internacionais que servem de apoio para testes de desempenho [2].
II.
Incio do Processamento
Figura 1. Viso de testes de caixa branca, de Barti.
TESTES NO FUNCIONAIS
Os testes no funcionais so verificaes da qual o desenvolvedor ou o testador, tem que avaliar se os requisitos no funcionais especificados no comeo do projeto esto de fato sendo atendidos. Existem algumas categorias de testes no funcionais, sendo elas [3]: a) Teste de Usabilidade; b) Teste Estrutural; a. Teste de Performance (Desempenho); b. Teste de Configurao (Ambiente); ______________________________
Evandro Grezeli de Barros Neves graduado como bacharel em Sistemas de informao na Universidade Anhembi Morumbi (UAM). E-mail: egrezeli@gmail.com Regiane Aparecida Marucci professora mestre do Centro de Cincia Computacionais da Universidade Anhembi Morumbi (UAM). E-mail: remarucci@anhembimorumbi.edu.br
Pressman [4], afirma que os defeitos encontrados pelo teste caixa preta no so os mesmos encontrados pelo teste caixa branca. Pelos seguintes motivos: a) Erros lgicos e pressuposies incorretas so inversamente proporcionais probabilidade de que um caminho em um programa seja executado. O processamento cotidiano tende a ser bem entendido, enquanto o processamento de um caso especial tende a cair por terra. b) Muitas vezes acredita-se que um caminho lgico no tem a probabilidade de ser executado quando, de fato, ele pode ser executado regularmente. Ou seja, podem-se cometer erros de projeto que so descobertos somente quando se inicia a atividade de teste do caminho. c) Erros tipogrficos so aleatrios. Quando um programa traduzido para cdigo-fonte da linguagem de programao, provvel que alguns erros de digitao ocorram. Muitos deles sero descobertos pela verificao de sintaxe do ambiente de desenvolvimento, mas outros passaro sem ser detectados at que os testes se iniciem. possvel que exista um erro tipogrfico tanto num caminho lgico obscuro como num caminho da corrente principal. III. TESTES DE DESEMPENHO
Com o desenvolvimento tecnolgico atual e solues propostas para o mundo coorporativo, a infra-estrutura que d suporte aos servios na Web compreende muitos recursos de hardware diferentes, desde estaes de trabalho dos clientes, servidores com seus processadores e subsistemas de armazenamento, alm dos recursos no previstos na

especificao funcional como Local Area Network (LAN), Wireless Area Network (WAN), balanceadores de carga e roteadores. Ainda existe a complexidade de processamento de software com diferentes servidores de aplicao, camadas middlewares, sistemas de gerenciamento de banco de dados, sistemas operacionais e diferentes ambientes arquiteturais se comunicando entre si (Alta e Baixa plataforma). Todos estes ingredientes somados a uma codificao complexa sem se preocupar com boas prticas de programao, tornam ainda mais complexo definir aonde pode existir um problema de desempenho [5]. Uma requisio feita na Web gasta uma parte do seu tempo em processamento dentro da arquitetura da aplicao e outra parte esperando nas filas pelos recursos. Para uma aplicao Web, os pedidos feitos podem ser decomposto em duas diferentes reas [5]: 1. Tempos de Servio: Tempo gasto usando vrios recursos, como processadores, discos e redes. 2. Tempos de Espera: Tempo gasto esperando para usar recursos que esto sendo mantidos por outros pedidos paralelamente. Para o usurio final, existe uma nica percepo, o tempo de resposta. Este, por sua vez, pode ser dividido em dois componentes: 1. Tempo de Rede: Todo o tempo gasto pelas mensagens trafegadas entre o navegador do usurio e o Web Site. 2. Tempo no Web Site: Todas requisies processadas internamente pela arquitetura do Web Site. Dentro destes dois componentes, ainda existem outros conceitos como podem ser visualizados na figura 2, que demonstram como um tempo de resposta pode ser totalizado.
36
A percepo do desempenho no tem um consenso especfico que defina o quo rpido um sistema deva ser principalmente para tempos de resposta em servios Web. As mtricas de desempenho para processos transacionais na alta plataforma sugeridos por Miller [6] suportam a idia de um tempo que o homem acredita que sua solicitao est sendo processada, caso a mesma retorne em um tempo inferior a 1 segundo, como pode ser visto na tabela 1, enquanto estudos estatsticos voltados para servios web da decada de 90 [7] apontam uma regra de que o tempo aceitvel para resposta de uma pgina e ou servio web at a desistncia de um usurio de 8 segundos.
TABELA 1. TEMPO DE RESPOSTA POR TRANSAES TRANSACIONAIS Tempo de Resposta 0,1 segundo 1 segundo 10 segundos Comentrio o limite de tempo em que o usurio sente que a aplicao est respondendo imediatamente. o limite de tempo para que o fluxo de pensamentos do usurio se mantenha contnuo, apesar de que o usurio notar a demora no processamento. o limite mximo de espera para manter a ateno do usurio na tela.
Figura 2. Complexidade da definio do tempo de resposta, de Menasc e Almeida.
Com um desmembramento do custo do tempo da rede no universo do tempo de resposta, a latncia formada pelo nmero de ida e volta envolvidos na troca de mensagens entre o navegador do cliente e o site, alm do tempo de transmisso, que o tempo necessrio para a transmisso de todos os bytes. O tempo gasto por este mesmo pedido do usurio, na arquitetura do site pode ser decomposto em dois componentes principais, conforme indicado na figura 2. O tempo de servio o perodo de tempo durante o pedido que est recebendo servio de um recurso, como Central Processing Unit (CPU), disco, LAN. Este mesmo pedido pode visitar um destes recursos, vrias vezes, antes que seja concludo. Com esta frequente troca de contexto do processo no processador, estes acabam sendo enfileirados gerando assim o outro componente chamado de tempo de fila. Dentro deste cenrio de complexidade arquitetural a percepo do desempenho pode se tornar algo subjetivo e que deve estar em acordo com o que esperado de resposta pelo usurio final da aplicao.
Com a crescente demanda de servios web e com o aumento da incluso digital de mais usurios, a regra proposta pelo survey da Zona Research inc [7] j no pode ser aplicada exigindo um ganho de desempenho em grandes corporaes com o medo de perda de rentabilidade lquida ou desistncia destes usurios implicando em visitas a web sites concorrentes. Um estudo conduzido por Bhatti, Bouch e Kuchinsky [8], observou como os usurios reagiam quando eles eram direcionados a usar um web site para configurar e comprar um computador. O estudo identificou que existia frustrao quando o tempo de resposta era por volta de 10 segundos. Por outro lado, essa tolerncia diminua de 10 para 4 segundos quando o processo de configurao de compra do computador estava prximo do fim. Spool [9] conduziu outro estudo com diversos usurios que deveriam visitar 10 sites diferentes e utilizar os recursos dos sites conforme o interesse de cada um. Cada usurio deveria pontuar a velocidade de cada site conforme a sua percepo. Ao final dos testes, percebeu-se que o site considerado o mais devagar de todos pelos usurios era, na verdade, o mais rpido de todos, com um tempo de resposta de 8 segundos. Por outro lado, um site corporativo mundial de compras foi considerado o mais rpido de todos, no entanto, o seu tempo de resposta era de 36 segundos. Concluram que essa percepo contraditria est ligada aos elementos visuais da pgina. Em mdia, os usurios gastam cerca de 4 segundos lendo cada elemento. Este site corporativo oferece vrios elementos interessantes do ponto de vista do usurio, dessa forma, aps a requisio de uma operao, o usurio gasta vrios segundos lendo esses elementos, o que torna a percepo de que o tempo de resposta do site inferior aos 36 segundos mensurados. Um estudo mais recente publicado por Barber [10] sugere que acima de 5 a 8 segundos de espera para o usurio j

considerado frustrante, como pode ser visto na tabela 2, e que o tempo considerado tpico para o usurio de 2 a 5 segundos.
37
a) Teste de Carga: criada uma carga simulada imitando o cenrio de demanda tpica do sistema, para saber como a aplicao se comporta. b) Teste de esforo: Como o sistema se comporta sob condies extremas (situao atpica), utilizando os cenrios de pior caso utilizando a carga mais pesada do que o esperado. Este tipo de teste tambm conhecido como Teste de Stress [3] [12]. c) Teste de pico: Testado em condies muito especficas, quando a carga muitas vezes maior do que a mdia e em um pequeno espao de tempo. Este tipo de teste tambm conhecido como Spike Test [12]. Alm destas definies bsicas de testes de desempenho, possvel citar testes mais especficos a serem feitos dependendo do resultado esperado pelo usurio [12]. a) Capacity Test: Este tipo de teste destinado para obteno de resposta sobre qual a capacidade da arquitetura no seu formato original e o quanto necessrio ela crescer dependendo da demanda desejada de usurios. Uma tcnica estratgica voltada a determinar um crescimento de arquitetura. b) Component Test: Teste de desempenho voltado a uma nica camada da aplicao, cujo objetivo definir o quanto a mesma isoladamente atende a demanda solicitada e qual o seu tempo de resposta. Teste isolado utilizado para identificao de gargalos especficos da arquitetura. c) Endurance Test: O objetivo deste teste analisar como a arquitetura se comporta sobre condies contnuas de cargas normais de usurios em um perodo de tempo superior ao real. A partir do estudo terico realizado, sobre os tipos de testes de desempenho em suas diferentes nomenclaturas citadas por Menasc [5] e para os testes de desempenho mais especifico citados por Meier et al. [12], obtevese assim, os seguintes tipos. Teste de Carga, Teste de esforo, Teste de Pico, Capacity Test, Component Test, Endurance Test. Ressalta-se que para demonstrar os resultados do relatrio gerencial proposto neste artigo optou-se pelo teste de esforo. Assim como nos testes funcionais que possuem um ciclo bem definido dentro da sua etapa de teste, os testes de desempenho tambm tm uma metodologia definida [5] como pode ser visto na figura 3.
TABELA 2. TEMPO DE RESPOSTA POR SERVIOS WEB Tempo de Resposta Abaixo de 3 segundos De 2 a 5 segundos De 5 a 8 segundos De 8 a 15 segundos Acima de 15 segundos Comentrio Resposta imediata Tipico Lento Frustrante Inaceitvel
Diante de um cenrio subjetivo que depende nica e exclusivamente da aplicao Web e do que esperado da mesma em termos de desempenho, o consenso comum para avaliar o desempenho de uma aplicao atravs do tempo de resposta e a taxa de processamento da aplicao [11]. Alm destas duas mtricas principais para medio de desempenho, ainda possvel utilizar-se de outras para verificar o desempenho dos servios na web, sendo elas: a) Tempo de Resposta de ponta a ponta: A soma total do tempo da rede ao tempo de processamento. b) Tempo de Resposta do site: O valor do tempo de espera da requisio do usurio ser completamente atendida. c) Erros por segundo: Qualquer falha no processo de interao com o servidor, como, por exemplo, um estouro na fila de conexes de usurios ignorando todas as requisies que possam ser feitas. d) Visitantes por dia: Demonstra a capacidade atual da aplicao sem degradao do tempo, sendo possvel ter o cenrio esperado por tempo de desempenho dos servios prestados. e) Hits: Um nico pedido de pgina pode gerar vrios hits, dependendo dos tipos de arquivos includos na pgina Hypertext Markup Language solicitada. Uma maneira de determinar qual ser a experincia do usurio utilizando os servios web atravs dos testes de desempenho. O objetivo principal de um teste de desempenho entender qual o desempenho do servio sob condies de carga de trabalho que reflitam a realidade ou uma projeo da mesma. importante que estes testes sejam planejados com antecedncia e com presena imprescindvel da equipe de desenvolvimento, produo e planejamento de capacidade. A chave para obteno de sucesso nestes tipos de teste a simulao fiel do ambiente de produo e cenrios de carga de trabalho, de modo que os resultados dos testes coincidam com o mundo real da melhor maneira possvel e caso a aplicao ainda no esteja disponvel ao usurio final j possa ser implantada com a verificao e com o conhecimento dos limites computacionais da mesma. Os testes a serem aplicados devem incluir situaes que representam uma atividade tpica do sistema e situaes de pico, de modo a determinar o comportamento do servio em ambas s situaes. Basicamente podem ser definidos trs tipos de testes de desempenho caracterizados pela intensidade de carga gerada [5]:
Figura 3. Uma metodologia para o teste de desempenho, de Menasc e Almeida.

Podem existir diversos tipos de objetivos a se alcanar com um teste de desempenho, alguns exemplos possveis [5]: a) Determinar a capacidade do servidor Web. b) Descobrir o nmero mximo de usurios simultneos que um servio na Web aceita dentro dos limites acordados. c) Determinar a quantidade de requisies simultneas da camada de aplicao. d) Identificar enfileiramentos na infra-estrutura do servio Web. e) Identificar a degradao do tempo de resposta percebido pelo usurio final ao crescimento das baterias de testes. f) Descobrir a capacidade do servidor de banco de dados. g) Identificar as funes Web que mais oneram a aplicao. Aps a definio dos objetivos desejados a atingir com o teste, necessrio ter bem definido qual o ambiente que o mesmo ser executado. Nesta etapa do trabalho, busca-se descobrir que tipo de infra-estrutura est rodando a aplicao (informaes de servidores, se existe algum servio terceiro) e quais os softwares envolvidos nesta infra-estrutura (sistemas operacionais, middleware, aplicaes, banco de dados). Assim como no teste funcional, necessrio ter definido um plano de teste coerente que busque simular os passos dos usurios na aplicao. Este processo o mais importante para se ter um resultado que busque atingir a expectativa dos objetivos, pois um cenrio mal definido pode apresentar uma execuo que no estimule de maneira correta o ambiente [5]. Diferentemente dos testes de caixa preta, estes testes buscam englobar apenas cenrios cujo final resulte em sucesso e os fluxos mais utilizados pelos usurios, procurando uma distribuio da sua carga de trabalho em percentual de uso e freqncia [13], como pode ser visto na figura 4.
38
mesmo exige uma equipe reduzida tendo como um nico prrequisito que os envolvidos conheam os cenrios de testes e saibam utilizar a ferramenta que far a simulao destes usurios virtuais. Ao final da execuo dos testes, a ltima etapa da metodologia iniciada, com o incio da coleta dos dados das ferramentas que monitoram os ambientes e com base nestas informaes so feitas as sugestes de melhoria e otimizao para todas as camadas do ambiente, onde nem sempre estas sugestes resultam em ampliao de capacidade de processamento de hardware, podendo ser sugestes de otimizao de comandos de banco de dados e engenharia baseada em modificaes de complexidades algortmicas de cdigos da aplicao. O teste de desempenho um mtodo comum utilizado para determinar como os usurios experimentaro o desempenho de um servio na Web, utilizando-se das abordagens especficas para cada tipo de cenrio de carga desejado a simular. IV.
ELABORAO DE UM TESTE DE ESFORO USANDO O JMETER
Figura 4. Exemplo de definio de cenrio e carga de trabalho, de Barber.
Aps a construo e definio dos cenrios juntamente com a sua carga, necessrio efetuar a instrumentao com ferramentas de medio para monitorar cada camada do ambiente enquanto os testes so executados (Servidores Web, Servidores de Aplicao, Sistemas de banco de dados, Sistemas operacionais). Estes testes podem ser executados utilizando dois mtodos [5]: 1) Teste Manual: Exigindo a quantidade de mo de obra desejada para obter a quantidade total de requisies definida no objetivo do teste e tambm uma alta sincronia entre os envolvidos para simular a carga necessria no tempo necessrio. 2) Teste Automtico: Que utiliza a simulao de usurios virtuais responsveis em fazer o papel dos usurios reais e so comandados por uma controladora nica. Por facilidade, mais comum a utilizao do segundo mtodo para execuo destes testes de desempenho, pois o
Neste item apresentado os passos realizados para a elaborao de um teste de esforo usando o JMeter. Como o JMeter uma ferramenta cujo objetivo no analisar o desempenho de aplicaes online e sim executar testes de desempenho, neste trabalho props-se a criao de um aplicativo para apresentar os resultados de uma execuo de testes de desempenho para a plataforma Android. Para o desenvolvimento deste aplicativo, foi necessria a criao de uma arquitetura hipottica de uma loja do tipo ecommerce para ser elaborado um teste de esforo utilizando o JMeter. Para que assim fosse possvel ter insumos suficientes para o funcionamento do relatrio gerencial desenvolvido para o Android, o JPlotMeter. Portanto, nas prximas sees est descrita de forma sucinta a arquitetura lgica deste portal.. As aplicaes baseadas na internet normalmente so enquadradas em uma arquitetura de trs camadas. A primeira camada nesta arquitetura, tambm chamada de apresentao, incorpora a interface de usurio com os servios na online. nesta camada onde o usurio final preenche as informaes que sero inseridas na aplicao. Na camada seguinte, onde estas informaes preenchidas so processadas, chamada de camada do negcio ou camada de aplicao. nesta que esto encapsuladas uma coleo de regras para implementar a lgica da aplicao. Finalmente, os dados solicitados por este servidor de aplicao so processados por um servidor de banco de dados, onde so consistidas as informaes de negcio. Esta distribuio das camadas pode ser vista na figura 5.
Figura 5. Arquitetura tpica de um Site online de mltiplas camadas.

No estudo realizado utilizou-se uma aplicao baseada na arquitetura tpica de um e-commerce, o JPetStore [14]. O JPetStore uma loja virtual cujo objetivo efetuar vendas de animais pela internet, armazenando as informaes em um banco de dados. Esta aplicao foi proposta originalmente pela Sun como uma loja virtual que utiliza conceitos do Java Enterprise Edition. Para que fosse possvel potencializar a demonstrao do relatrio de tempo mdio de resposta por pgina desenvolvido para o Android, foi escolhido o teste de esforo, que o tipo de teste de desempenho que oferece maiores insumos para visualizao da degradao de utilizao dos recursos computacionais. Com base neste portal, foram criados seguindo a fundamentao proposta por Myers [1] dois casos de teste que serviram como script para o desenvolvimento dos testes de esforo, utilizando duas funcionalidades da aplicao. A primeira refere-se ao fluxo de compra de um animal e a segunda, pesquisa de um animal. Para execuo deste teste de desempenho no cenrio hipottico proposto, tomou-se como premissa que a aplicao suporta em pico, 100 usurios simultneos, isto significa que a aplicao est em 100% de utilizao do site ao atingir esta quantidade de usurios simultneos. De base nesta informao, foi criada uma pirmide de usurios, que pode ser vista na figura 6, que demonstra a quantidade de usurios para os ciclos de testes que foram executados. Acima de 100 usurios, o conceito do teste de esforo j est agindo sobre a aplicao, conforme definio deste conceito de teste apresentado anteriormente, chegando base da pirmide com at 400% a mais da carga esperada pelo site.
39
Figura 7. Atributos definidos para o caso de teste no JMeter.
Como sero dois cenrios envolvidos nesta execuo, cada cenrio tem um peso especfico para a quantidade de usurios utilizando a aplicao, sendo necessrio definir a carga de usurio conforme definido anteriormente. Na figura 8 pode ser visto o percentual da execuo no portal JPetStore para cada um dos nveis da pirmide de usurios.
Figura 8. Distribuio de usurios simultneos utilizando o JPetStore.
Figura 6. Pirmide de usurios simultneos utilizando o JPetStore.
Para cada nvel da pirmide executado, devem ser definidos os parmetros de tempo de durao da bateria e quantidade de usurios que devem estar concorrendo simultaneamente por ciclo. Na figura 7 estes atributos esto definidos para o teste hipottico em questo, onde cada ciclo tem o tempo de 5 minutos de execuo e todos os usurios concorrem simultneamente desde o instante segundo 0.
Tendo definido os casos de testes, a criao do script que simular um usurio real, a quantidade de usurio que executar este script e o percentual de carga por funcionalidade, pode-se considerar finalizada a parte da criao de um teste de desempenho. A previso de durao do tempo da execuo do ciclo de teste completo era de 45 minutos, j que o objetivo proposto era de executar os 9 nveis presentes na pirmide de usurios, conforme na figura 6. Porm no nvel 7 da pirmide, cujo total de usurio simultneos era de 225 o que representa 125% a mais de carga esperada pela aplicao a execuo foi encerrada, pois o servidor apresentou um alto consumo de CPU. Como o objetivo deste trabalho no mensurar o desempenho do hardware e sim demonstrar a utilizao do aplicativo JPlotMeter desenvolvido para o Android, foi decidido que com a execuo realizada j se possuia informaes suficientes. V.
JPLOTMETER: UM RELATRIO GERENCIAL PARA O ANDROID
Os resultados das execues dos testes feitos no JMeter armazenados em uma tabela temporria criada para o JPlotMeter so processados e expostos por um webservice para que o aplicativo no Android pudesse receber estas informaes e gerar o grfico. Um desenho tcnico da aplicao pode ser visto na figura 9.
40
Cada usurio simulado pelo JMeter gera uma srie de informaes sobre a sua execuo. Para o prottipo de relatrio gerencial JPlotMeter, trs destas mtricas rudimentares foram necessrias: 1. Time Taken: Representa o tempo de espera desde uma solicitao do usurio ao servidor at o retorno; 2. Time Stamp: O carimbo contendo data e horrio da solicitao do usurio; 3. CSIUri: o rtulo da Uniform Resource Locator (URL) solicitada pelo usurio. Estas mtricas foram armazenadas em uma tabela histrica e transitadas pela aplicao do lado do servidor para aplicao presente na plataforma Android, gerando assim a criao do grfico representativo do tempo mdio de resposta de cada uma das pginas. Para que fosse possvel ter informaes suficientes para a demonstrao do funcionamento do relatrio, foram programadas para que a cada 5 minutos de uma bateria fosse executada a pirmide de usurios hipottica, totalizando um perodo de 45 minutos de coletas armazenadas no banco de dados. Para que fosse possvel representar as informaes coletadas a cada ciclo de execuo no JMeter de maneira visual, foi desenvolvido o aplicativo JPlotMeter para o Android. Este aplicativo consiste em duas classes, que podem ser vistas no diagrama de classes na figura 12. A classe LerArquivo a responsvel por consumir as informaes do aplicativo no lado do servidor e a classe JPlotMeter a responsvel em tratar as informaes e gerar o grfico em tempo real. Para que o grfico fosse montado de maneira padronizada, optou-se por utilizar uma Application Programming Interface (API) disponvel para criao de grficos, chamada jjoe64 [15]. Esta API possui mtodos j implementados, que recebem valores nmericos e textuais para construo do grfico, seja ele do tipo linha ou do tipo barra. Para uma melhor representao do tempo de resposta das pginas, foi utilizado o grfico de tipo linha.
Figura 9. Desenho tcnico da soluo JPlotMeter.
No servidor com o JPlotmeter foram desenvolvidas quatro classes, dentre elas a AppService, HandleReturn, ConnectionMySql e a JaxWsImpl, como poder ser visto no diagrama de classes apresentado na figura 10. A classe AppService responsvel em fornecer a informao j tratada para o aplicativo no Android, onde o mtodo consulta atravs de uma conexo Java Data Base Connection (JDBC) uma tabela criada no MySQL, e trata as informaes coletadas retornando insumo suficiente para atender a necessidade de gerar o grfico referente ao tempo mdio de resposta por ciclo de teste executado.
Figura 10. Diagrama de classe servidor de aplicaes.
Para um melhor entendimento em relao interao do usurio com o aplicativo, o diagrama de casos de uso foi elaborado, como pode ser visto na figura 11. O usurio precisa ter o aplicativo JPlotMeter instalado no seu dispositivo mvel com Android. Em seguida, abrir o aplicativo que o mesmo se encarregar de mostrar o grfico gerencial de tempo mdio de resposta na tela do dispositivo.
Figura 12. Diagrama de classes do aplicativo JPlotMeter.
Figura 11. Diagrama de caso de uso.
Ao consumir as informaes do lado do servidor, o aplicativo trata estas como um arquivo Comma Separated Values (CSV), que nada mais do que um texto cujo os valores so separados por algum delimitador, no caso o delimitador a vrgula. A partir destas informaes recebidas, o Time Taken o responsvel em gerar o eixo vertical que a mdia de tempo de resposta em segundos e o eixo horizontal gerado atravs do Time Stamp, que a linha temporal da execuo, como pode ser visto no grfico apresentado na figura 13.
41
gerado, no sendo necessrio uma outra execuo ou at mesmo rever as informaes coletadas. VI. CONCLUSES E TRABALHOS FUTUROS
Figura 13. Demonstrao dos eixos do JPlotMeter.
Cada uma das esttiscas de acesso realizada pela execuo no JMeter armazenada no banco de dados da aplicao pelo lado do servidor com seu respectivo identificador, representado na tabela pela coluna CSIUri. Este campo no grfico gerado a legenda, como pode ser visto no grfico apresentado na figura 14, sendo possvel assim verificar a variao do tempo de resposta ao longo do tempo da execuo, sendo que o somatrio do tempo mdio de resposta das pginas na ltima bateria executada se aproximou a 150 segundos de durao.
Figura 14. Demonstrao das legendas no JPlotMeter.
O resultado identificado na execuo do teste de esforo aplicado no portal e-commerce durante o perodo das 09:00 at s 09:24, no qual se identificou uma limitao fsica do servidor na bateria de 225 usurios, refletido com um gradativo aumento do tempo mdio de resposta por pgina representado pelo grfico apresentado na figura 32, comportamento este que est diretamente ligado com o consumo excessivo de CPU do servidor, monitorado de maneira visual durante a execuo do ciclo de teste. Como o cenrio hipottico inicial proposto para aplicao nas configuraes fsicas especficas o servidor suportava, em condies de pico, 100 usurios simultneos. Foi possvel constatar em uma execuo de teste de esforo que a aplicao atende a demanda sem apresentar falhas ou quedas de at 225 usurios simultneos. Neste caso, observou-se que o limitante para esta quantidade de usurios foi o consumo de CPU do servidor. A quantidade de informaes obtidas foi suficiente para que o grfico de tempo de resposta mdio das pginas fosse
Com o levantamento terico bibliogrfico realizado neste trabalho foi possvel convergir os diferentes conceitos sobre testes de desempenho e demonstrar um planejamento para se realizar a execuo de um destes tipos de teste, o teste de esforo. Para a demonstrao do teste de esforo, foi desenvolvida uma arquitetura hipottica controlada, contendo as camadas de banco de dados, de aplicao e de web. Esta arquitetura possibilitou efetuar o teste escolhido e armazenar as mtricas para futura utilizao. Uma vez implementada a arquitetura do JPetStore, foram escolhidas duas funcionalidades e elaborados dois casos de teste de esforo. A partir da execuo destes casos de teste, foi possivel coletar algumas mtricas para demonstrao do aplicativo JPlotMeter para a plataforma Android. Sua funcionalidade principal a demonstrao de um relatrio gerencial apresentando em forma de um grfico, o tempo mdio de resposta por pginas da aplicao. O aplicativo JPlotMeter no depende exclusivamente dos dados gerados da execuo do teste de esforo no portal JPetStore, sendo possvel reaproveita-lo em outros portais. Para isto, necessrio que os dados coletados de outra execuo de um teste de desempenho qualquer sejam inseridos na tabela do JPlotMeter de maneira que o webservice da aplicao possa expor as mesmas para gerao do grfico no Android. A partir do tipo de informaes coletadas pelas execues feitas na aplicao e-commerce e apresentada pela aplicao JPlotMeter, projeta-se que seja possvel expandir para mais um grfico as informaes visuais gerando um grfico de throughput, que consiste em apresentar a mdia de requisies por usurio em um determinado perodo. Alm deste grfico, existe a possibilidade de melhoria do JPlotMeter adicionando novas funcionalidades ou reformulao da sua funcionalidade principal desenvolvida. Pelo fato da aplicao que coleta a informao do lado do servidor ser esttica, tambm projeta-se a possibilidade de migrar o cliente para outros sistemas operacionais disponveis para arquitetura mveis, como o IOS da Apple e o Microsoft Windows Phone da Microsoft. Finalmente, tambm projeta-se que para uma prxima verso do aplicativo seja possvel integrar a sada das informaes geradas para cada usurio executado no JMeter diretamente com a base de dados do JPlotMeter, no sendo necessrio assim tratar esta informao antes de import-la para o banco de dados. REFERNCIAS BIBLIOGRFICAS
[1] [2] Myers, Glenford J.. The Art of Software Testing. 2 ed. New Jersey: John Wiley & Sons Inc, pp. 20-149, 2004. Guerra, Ana Cervigni; Colombo, Regina Maria Thienne. Tecnologia da Informao: qualidade de produto de software. Brasilia: PBQP, pp. 429, 2009. Barti, Alexandre. Garantia de Qualidade de Software. 3 ed. So Paulo: Campus, pp. 131-327, 2002. Pressman, Roger S.. Engenharia de Software. 6 ed. So Paulo: Pearson Makron Books, pp. 323-522, 2005.
[3] [4]

[5] Menasc, Daniel A., Almeida, Virgilio A. F.. Planejamento de Capacidade para servios na Web: Mtricas, modelos e mtodos. So Paulo: Campus Elsevier, pp. 54-298, 2003. Miller, Robert B.. Response time in man-computer conversational transactions. New York: International Business Machine Corporation, in press. Zona, Research inc.. User trends: The 8-second rule of I-commerce. A Zona Research survey on web-page download speeds and electronic commerce. Info World, 1999. Bhatti, Nina, Bouch, Anna, Kuchinsky, Allan (04/2011). Integrating User-Perceived Quality into web Server design. 9th International World Wide Web Conference [Online]. Disponvel em: http://portal.acm.org/citation.cfm?id=346245 Spool, Jared M.. An interview with Jared Spool of User Interface Engineering, conducted by John Rhodes, WebWorld, 2001. Barber, Scott (04/2011). How fast does a website need to be? [Online]. Disponvel em: http://www.perftestplus.com/resources/how_fast.pdf Almeida, Virgilio, Menasc, Daniel A., Dowdy, Larry W.. Performance by Design: Computer Capacity Planning by Example. New Jersey: Prentice Hall, pp. 15-197, 2004. Meier, J. D. et al. Performance Testing Guidance for Web Applications. Redmond: Microsoft Press, pp. 13-143, 2007. Barber, Scott (11/2012). User experience, not metrics part 3: Modeling individual user patterns [Online]. Disponvel em: http://www.perftestplus.com/resources/UENM3.pdf JPetStore Site Oficial (11/2012) [Online]. Disponvel em: http://www.oracle.com/technetwork/java/petstore1-3-1-02-139690.html Jjoe64 Site Oficial (09/2011) [Online]. Disponvel em: http://www.jjoe64.com/p/graphview-library.html
42
[6]
[7]
[8]
[9] [10] [11]
[12] [13]
[14] [15]

Revista Icceeg Numero 5

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Revista Icceeg Numero 5

Загружено:

Авторское право:

Доступные форматы

Volume 1 Nmero 5 Dezembro de 2012

REVISTA JUNIOR - ICCEEg

Revista Junior de Iniciao Cientfica em Cincias Exatas e Engenharia

Volume 1 Nmero 5 Dezembro de 2012

Volume 1 Nmero 5 Dezembro de 2012

Revista Jr de Iniciao Cientfica em Cincias Exatas e Engenharia

Volume 1 Nmero 5 Dezembro de 2012

Revista Jr de Iniciao Cientfica em Cincias Exatas e Engenharia

ICCEEg: 1 (5) - Dezembro 2012

O Modelo de Computao em Nuvem e sua Aplicabilidade

ICCEEg: 1 (5) - Dezembro 2012

ICCEEg: 1 (5) - Dezembro 2012

Universidade 1 Universidade N Universidade 2

Universidade 1 Universidade N Universidade 2

Fig. 2. Nuvem Comunitria com administrao interna e externa

Acesso e Gerenciamento Sistema Operacional Servios Plataforma de Desenvolvimento

Apenas Acesso Aplicaes

Nveis de Acordo de Servio

Fig. 1. Nuvem Computacional

ICCEEg: 1 (5) - Dezembro 2012

ICCEEg: 1 (5) - Dezembro 2012

Fig. 3. Arquitetura do Eucalyptus

ICCEEg: 1 (5) - Dezembro 2012

Fig. 4. Modelo de virtualizao hbrida.

VMware vSphere Hypervisor

VMware Server SO Hospedeiro Hardware

ICCEEg: 1 (5) - Dezembro 2012

PV VM 1 VM VM(domU (domUPV) PV)

Fig. 7. Componentes do Xen, hypervisor e domnios [29]

ICCEEg: 1 (5) - Dezembro 2012

Cloud Controller Walrus

Cluster Controller Storage Controler Node Controller

Tipo de VM m1.small c1.medium m1.large m1.xlarge c1.xlarge

Memria 192 MB 256 MB 512 MB 1024 MB 2048 MB

ICCEEg: 1 (5) - Dezembro 2012

[11] [12] [13] [14] [15]

ICCEEg: 1 (5) - Dezembro 2012

ICCEEg: 1 (5) - Dezembro 2012

Um Jogo de Estratgia Aplicando Tcnicas de Inteligncia Artificial

Index Terms Artificial Intelligence, Game AI, Real-Time Strategy

ICCEEg: 1 (5) - Dezembro 2012

ICCEEg: 1 (5) - Dezembro 2012

Mquinas de Estado Finito

ICCEEg: 1 (5) - Dezembro 2012

ICCEEg: 1 (5) - Dezembro 2012

Figura 3.2: Trs regras do Flocking [19].

Figura 4.1: FSM dos Edifcios

ICCEEg: 1 (5) - Dezembro 2012

Figura 4.3: FSM dos Trabalhadores

ICCEEg: 1 (5) - Dezembro 2012

Edifcio Central Equipe A

Edifcio Central Equipe B

ICCEEg: 1 (5) - Dezembro 2012

Figura 5.1: Diagrama de Classes do Jogo

ICCEEg: 1 (5) - Dezembro 2012

ICCEEg: 1 (5) - Dezembro 2012

A avaliao como ferramenta motivadora do processo ensino-aprendizagem em matemtica

ICCEEg: 1 (5) - Dezembro 2012

ICCEEg: 1 (5) - Dezembro 2012

ICCEEg: 1 (5) - Dezembro 2012

ICCEEg: 1 (5) - Dezembro 2012

ICCEEg: 1 (5) - Dezembro 2012

[2] [3] [4] [5] [6]

[9] [10] [11] [12]