DEPARTAMENTO DE COMPUTAÇÃO PROPOSTA DE PROJETO DE PESQUISA INPE

Transcrição

1 DEPARTAMENTO DE COMPUTAÇÃO D E C O M PROPOSTA DE PROJETO DE PESQUISA INPE Projeto de Integração do Ambiente de Modelagem TerraME com a Linguagem de Programação LUA Área: Ciência da Computação Local de realização: Departamento de Computação Universidade Federal de Ouro Preto Coordenador: Equipe: Prof. Dr. Tiago Garcia de Senna Carneiro Prof. Dr. Tiago Garcia de Senna Carneiro Estudante Bach. Cien. Comp. Raian Vargas Maretto U F O P UNIVERSIDADE FEDERAL DE OURO PRETO

2 Índice 1 ÍNDICE. 2 2 INTRODUÇÃO.3 3 REVISÃO DA LITERATURA A LINGUAGEM DE PROGRAMAÇÃO LUA O AMBIENTE DE MODELAGEM TERRAME A Linguagem de Modelagem TerraME TÉCNICAS DE PROGRAMAÇÃO APLICADAS NO FRAMEWORK TERRAME Estendendo a linguagem LUA por meio de Programação Genérica Emprego do Padrão de Projeto Wrapper Emprego do Padrão de Projeto Proxy Emprego do Dialeto Handle-Body OBJETIVOS.22 5 JUSTIFICATIVAS METODOLOGIA REQUISITOS CRONOGRAMA DE EXECUÇÃO DO PROJETO INFRA-ESTRUTURA DISPONÍVEL RECURSOS PRETENDIDOS EQUIPAMENTOS E MATERIAL PERMANENTE METAS E INDICADORES DE AVALIAÇÃO.. 30 BIBLIOGRAFIA..32 2

3 2Introdução O TerraME (TerraLib Modeling Environment) é um ambiente para o desenvolvimento de modelos espaciais dinâmicos baseado em um modelo híbrido entre os modelos de autômatos celulares e os modelos baseados em agentes, chamado autômatos celular aninhado ou, simplesmente, Nested-CA (Carneiro, 2006). Este modelo foi especialmente projetado para o desenvolvimento e simulação de modelos para processos biofísicos e sócio-econômicos, nos quais os espaço celulares estão associados à bases de dados geográficos gerenciadas por um Sistema de Informação Geográfica (SIG), especificamente, a biblioteca TerraLib (Câmara et al. 2002). Para facilitar a representação dos modelos, o ambiente TerraME provê uma linguagem de programação de alto nível, também chamada TerraME, que é uma extensão da linguagem de programação LUA (Ierusalimschy, Figueiredo et al. 1996). LUA é uma linguagem de programação livre e de código aberto projetada para estender aplicações, possui todas as construções de uma linguagem de programação de uso geral, possui sintaxe extremamente simples, e uma máquina de execução pequena e eficiente. LUA fornece uma API (Application Programming Interface ou Interface de Programação de Aplicativos) que permite uma aplicação C++ trocar dados com programas escritos em LUA ou estender sua maquina de execução e seu sistema de tipo pelo registro de novas funções ou novos tipos de dados implementados em C ou C++. LUA é atualmente a linguagem mais utilizada na produção de jogos, uma aplicação com muitas características em comum com a modelagem de sistemas terrestres. O desenvolvimento de mundos virtuais e dos personagens que o habitam é similar ao desenvolvimento de uma representação para uma determinada área geográfica com os sistemas, processos e atores que nela existem. 3

4 Apesar do núcleo de TerraME estar completamente implementado, sua integração com a linguagem de programação LUA precisa ser finalizada, pois a API TerraME em C++ não foi completamente registrada no ambiente de execução LUA. Desta maneira, o modelador não tem à sua disposição todas as funcionalidades do framework TerraME através da linguagem de modelagem TerraME. Apesar de ser o produto final de uma tese de doutorado, a documentação do ambiente TerraME ainda é insuficiente. O documento de especificação precisa ser consistido com a atual implementação, e o manual do usuário, com exemplos de uso precisa ser elaborado. Documentar o projeto TerraME é importante para tornar mais eficiente o processo de manutenção e evolução de seu código e o processo de treinamento de usuários e novos desenvolvedores. Este trabalho tem por objetivo a completa integração do ambiente de modelagem TerraME com a linguagem de programação LUA. Para isso, a API C++ do framework TerraME será totalmente registrada no ambiente de execução LUA. E a inclusão dos novos tipos de dados introduzidos pelo framework TerraME no sistema de tipo da linguagem LUA será finalizada. O produto resultante deste trabalho terá seu código fonte documentado, por meio da metodologia suportada pelo projeto DOXYGEN, disponível até esta data em Serão elaborados tutoriais contendo exemplo de uso desse produto, além de um manual de referência para a linguagem de modelagem TerraME. 4

5 3Revisão da Literatura Esta seção apresenta uma revisão sobre os conceitos e as tecnologias que serão utilizadas para a realização deste trabalho. 3.1 A Linguagem de Programação LUA A linguagem de programação LUA (Ierusalimschy, Figueiredo et al. 1996) é uma linguagem de programação imperativa, procedimental, pequena e leve, que fornece construções para descrição de dados baseadas em tabelas associativas e semântica extensível. LUA é tipada dinamicamente, interpretada a partir de bytecodes, e possui gerenciamento automático de memória para coleta de lixo. LUA é uma linguagem de extensão, projetada para ser usada como linguagem de configuração, acoplada a um programa hospedeiro, escrito na linguagem de programação C ou C++. Esses programas em geral podem acoplar códigos à máquina virtual LUA, para permitir prototipagem rápida e acesso programável pelo usuário à tecnologia implementada pela aplicação através de uma linguagem de alto nível. É muito comum o uso de LUA como um interpretador stand-alone, onde o código LUA é a linha de execução principal. O programador escreve todo o código da sua aplicação em LUA, sem precisar ter conhecimento da API em C. Nessa situação, o ambiente de programação é formado pelas funções prédefinidas em LUA, acrescidas das bibliotecas padrão da linguagem e dos pacotes de extensão adicionados. Ao invés de fornecer uma gama de construções diretamente na linguagem, LUA fornece meta-mecanismos para a implementação de construções naturais a linguagens de 5

6 programação orientadas a objetos, como por exemplo, meta-mecanismos para a implementação de classes e herança. Estes meta-mecanismos proporcionam uma economia de conceitos e mantém a linguagem concisa, permitindo também que a linguagem seja estendida de maneiras não convencionais. 3.2 O Ambiente de Modelagem TerraME O ambiente de modelagem TerraME posssui uma arquitetura em camadas, onde os componentes de uma camada implementam seus serviços fazendo chamadas aos serviços oferecidos por componentes da camada imediatamente inferior. As maiores vantagens deste tipo de arquitetura são a maior facilidade no reuso das camadas e o fato de que as dependências dentro do software são mantidas localmente. Na primeira camada, a biblioteca TerraLib oferece serviços de gerenciamento e análise de dados geográficos, além de funções adicionais para manipulação de séries temporais desse tipo de dado. A segunda camada é o Framework TerraME, que provê serviços para modelagem, simulação, calibração e validação de modelos dinâmicos espacialmente explícitos. O framework TerraME é uma implementação C++ de código aberto do modelo de autômatos celulares aninhados (Carneiro 2006), Nested-CA. A terceira camada da arquitetura implementa o interpretador da linguagem de modelagem TerraME, que estende a linguagem de programação LUA pela inclusão dos serviços e dos tipos de dados fornecidos pelo framework TerraME. A ultima camada, chamada camada de aplicação, é onde se encontram os modelos desenvolvidos pelos usuários do ambiente de modelagem TerraME. A figura abaixo mostra como se dá o relacionamento entre as camadas do ambiente TerraME. 6

7 Figura 3.1 Arquitetura em camadas do ambiente de modelagem TerraME. Requisições são movidas do nível mais alto para o nível mais baixo, e as respostas para as requisições trafegam no sentido oposto. As diferentes camadas da arquitetura TerraME refletem diretamente os diferentes tipos de usuários do ambiente. Programadores C++, podem desenvolver modelos diretamente sobre a API do framework TerraME. Nesse nível, não existem restrições quanto à representação geométrica dos objetos espaciais. Estes podem ser pixels em uma imagem, células em uma grade celular, ou pontos, linhas e polígonos em um mapa vetorial armazenado em um banco de dados TerraLib. Contudo, alterações no código do modelo exigirão a compilação do mesmo. A discussão a respeito de aspectos de implementação do modelo entre membros de uma equipe multidisciplinar é prejudicada pela complexa sintaxe da linguagem C++. Usuários que não possuem conhecimentos da linguagem de programação C++, podem representar seus modelos na linguagem de modelagem TerraME. Neste nível, os objetos geográficos são representados apenas como células contidas em um espaço celular TerraLib, que por sua vez, é uma grade bidimensional de células retangulares e multivaloradas. Porém, qualquer alteração no código do modelo não implicará na sua compilação, porque TerraME é uma linguagem interpretada. Este fato beneficia a rápida 7

8 prototipagem de modelos. Além disso, os fatos da linguagem TerraME possuir uma sintaxe extremamente simples e de seus tipos terem nomes muito próximos ao domínio de sua aplicação, modelagem ambiental, facilitam o entendimento e escrita de modelos por equipes multidisciplinares A Linguagem de Modelagem TerraME A linguagem de modelagem TerraME estende o sistema de tipos e máquina virtual da linguagem de programação LUA com a inclusão de novos tipos e serviços específicos para o desenvolvimento de modelos dinâmicos espacialmente explícitos. Os seguintes tipos são fornecidos: Scale: utilizado para representar o conceito de escala e permitir o desenvolvimento de modelos que considerem múltiplas escalas. CellularSpace, Cell, Neighborhood: utilizados para representar o espaço, suas propriedades e relações topológicas. GlobalAutomaton, LocalAutomaton, State, JumpCondition, FlowCondition, e Trajectory: utilizados para representar o comportamento de sistemas, processos ou atores que dinamicamente alteram as propriedades do espaço e interagem entre si. Timer, Event, e Message: utilizados para representar o tempo e definir o momento e a ordem na qual os modelos comportamentais serão executados durante a simulação. 8

9 3.3 Técnicas de Programação Aplicadas no Framework TerraME Entre as técnicas de programação utilizadas no desenvolvimento do framewrok TerraME estão o emprego dos padrões de projeto de software wraper, composite e proxy, além do dialeto handle-body (Gamma, 2005). Padrões de projeto de software descrevem soluções elegantes e reutilizáveis para problemas recorrentes no desenvolvimento de softwares orientados a objetos. Um padrão de projeto estabelece um nome, define o problema, a solução, quando aplicar esta solução e quais são as suas conseqüências. Dialetos são padrões de projeto de software que se aplicam a somente uma linguagem de programação para superar alguma limitação ou desvantagem que própria linguagem ofereça ao projeto. O wrapper C++ para a linguagem TerraME foi implementado por meio da técnica de programação genérica, uma classe parametrizada recebe como parâmetro a classe C++ que será registrada no ambiente de execução TerraME. A mesma técnica foi utilizada para permitir a implementação do padrão de projeto composite e do dialeto handle-body na forma templates C++. Desta forma, o emprego desses padrões de projeto a diferentes classes exige somente a instanciação de uma classe que receba como parâmetro a classe à qual o padrão de projeto será aplicado. Por exemplo, composite<cell> e composite<cellularspace> são, respectivamente, um composite de células e um composite de espaços celulares. As técnicas aplicadas permitem a reutilização do código TerraME com modificações mínimas, além de auxiliar no desenvolvimento do mesmo, pois os padrões de projeto se repetem de forma constante em diferentes sistemas ou subsistemas Estendendo a linguagem LUA por meio de Programação Genérica Binding é um termo usado para denotar a chamada de um recurso a partir de um programa para o qual esse recurso não é nativo. Um binder C++ para LUA tem, portanto, o objetivo de permitir que objetos e funções de um pacote em C++ possam ser instanciados e 9

10 ligados a um identificador definido na linguagem LUA através do qual o programador poderá utilizá-los, como mostra a figura 3.1. Figura 3.1 Através de um identificador LUA, o programador faz uma chamada a um objeto C++. É através do Binder que a ligação entre o identificador e o objeto será concretizada. O binder funciona como se fosse um tradutor. Quando um programa em LUA instancia um objeto C++ ou faz uma chamada a um de seus métodos, é o binder quem traduz as operações realizadas no ambiente de execução LUA em operações de mesma semântica no ambiente de execução C++. As dificuldades no desenvolvimento de binders C++ para LUA estão associadas principalmente a dois fatos: 1) As interfaces dos objetos C++ podem conter tipos inexistentes em LUA como, por exemplo, um parâmetro cuja classe foi definida pelo programador. 2) A API LUA não foi projetada para registrar classes C++ em LUA, somente funções cujas assinaturas são do tipo int () (lua_state*) podem ser registradas. Isto é, funções que recebem uma pilha de execução LUA como parâmetro e retornam um valor inteiro. No projeto TerraME, o binder C++ para LUA chamado Luna (Plaozzi 2006) foi utilizado para registrar as interfaces C++ das classes do framework TerraME no ambiente de execução da linguagem LUA. O binder Luna é implementado como um template C++ que recebe como parâmetro a interface a ser registrada. O código apresentado na figura 3.2 exemplifica como o binder Luna foi utilizado para estender a linguagem LUA pela inclusão dos novos tipos de dados do framework TerraME em seu sistema de tipos. 10

11 #include <luna.h> public Cell{ public: Cell( void ){; float getlatency( void ){; void setlatency( float ){; public luacellinterf{ public: luacellinterf( void ){; virtual float getlatency( void ) = 0; virtual void setlatency( float ) = 0; class luacell : public Cell, luacellinterf{ public: luacell( lua_state *L ){ ; int getlatency( lua_state *L ){; int setlatency( lua_state *L ){; private: static const char[] classname; static const Luna<luaCell>::RegType Register; ; const char[] luacell::classname = "TmeCell"; const Luna<luaCell>::RegType luacell::register[] = { { "getlatency", &luacell::getlatency, { "setlatency", &luacell::setlatency, { 0 ; /* Registra a classe luacell em LUA */ Luna<luaCell>::Register(L); Figura 3.2 Código C++ para inclusão do tipo Cell na linguagem LUA. Na figura 3.2, a classe Cell é uma implementação pertencente ao framework TerraME que possui os métodos float getlatency(void) e void setlatency(float) em sua interface. A classe luacellinterf implementa uma interface para o tipo Cell onde todos os métodos possuem assinatura do tipo int () (lua_state *L), como exige a API de LUA. A classe luacell implementa o padrão de projeto wrapper permitindo que objetos Cell do framework TerraME sejam utilizado através da interface luacellinterf. O restante do código registra a classe luacell com o nome TmeCell no sistema de tipos e no ambiente de execução de LUA. 11

12 3.3.2 Emprego do Padrão de Projeto Wrapper O padrão de projeto wrapper, também chamado Adaptador, trabalha fazendo a intermediação entre duas classes com interfaces incompatíveis, permitindo que elas trabalhem em conjunto (Gamma, 2005). Para isto, define-se uma classe que traduz as chamadas entre as classes incompatíveis, fazendo com que estas classes possam trocar informações, podendo adicionar alguma funcionalidade a uma delas, caso seja necessário. Este padrão de projeto foi utilizado para a adaptação das interfaces dos objetos C++ do framework TerraME às interfaces de mesma semântica onde os métodos possuem a assinatura da forma: int () (lua_state*). Por exemplo, para a adaptação da interface do objeto Cell à interface luacellinterf apresentadas na figura 3.2. O padrão wrapper pode ser implementado de duas formas diferentes, como um adaptador de classe ou como um adaptador de objetos. No projeto TerraME, é utilizado o mecanismo de herança múltipla, figura 3.3, de forma que a classe adaptadora herda a interface exigida pela classe cliente, luacellinterf, e também a implementação da classe a ser adaptada, Cell, portanto, um adaptador de classe. luacelinterff: Cell: luacell: Figura 3.3 Classe Adapter herda a interface de Target e a implementação de Adaptee. Para simplificar o código apresentado na figura 3.2, as classes puramente abstratas como, por exemplo, luacellinterf, utilizadas na implementação do padrão de projeto wrapper foram eliminadas. Este fato, permitiu o uso de herança simples para implementação do 12

13 padrão de projeto wrapper no desenvolvimento da integração do framework TerraME com a linguagem LUA. A figura 3.4 apresenta o código correspondente o aplicação do padrão de projeto wrapper à classe Cell do framework TerraME. public Cell{ public: Cell( void ){; float getlatency( void ){; void setlatency( float ){; class luacell : public Cell { public: luacell( lua_state *L ){ ; int getlatency( lua_state *L ){ lua_pushnumber(l, Cell::getLatency()); return 1; ; int setlatency( lua_state *L ){ Cell::setLatency( lual_checknumber(l, 1) ); return 0; ; private: static const char[] classname; static const Luna<luaCell>::RegType Register; ; Figura 3.4 Código do wrapper utilizado para adaptar a interface do objeto Cell à interface exigida pela API LUA, onde todos os métodos devem ter assinatura do tipo int () (lua_state*) Emprego do Padrão de Projeto Proxy Um proxy provê uma referência para um objeto com o objetivo de controlar a forma na qual este é instanciado ou utilizado. No projeto TerraME, proxies definidos no ambiente de execução da linguagem TerraME garantem que os objetos C++ do framework TerraME sejam criados e utilizados de maneira correta. Estes proxies verificam se todos os parâmetros necessários à criação dos objetos C++ foram fornecidos e garantem a validade de seus valores. Desta forma, evita-se que o uso incorreto das interfaces dos objetos C++ dê origem a erros graves em tempo de execução, enquanto que a ausência dessas verificações no código C++ confere maior desempenho ao mesmo. 13

14 Portanto, o presente projeto usa uma variedade do padrão de projeto proxy denominada remote proxy, que provê um representante local para um objeto em um espaço de endereçamento diferente. Isto permite que objetos no espaço de endereçamento LUA sirvam como proxies para objetos no espaço de endereçamento C++. A figura 3.5 ilustra o código do padrão de projeto proxy como aplicado no projeto TerraME para a criação e uso de objetos do tipo Cell. function Cell( attrtab ) local cobj = TmeCell(); local metaattr = { cobj_ = cobj, past = {, getlatency = function(self) return self.cobj_:getneighborhood( index ); end, setlatency = function( self, value ) if( value > 0 ) then self.cobj_:setlatency( value ); end end, ; local metatable = { index = metaattr ; if( attrtab == nil ) then attrtab = {; end setmetatable(attrtab, metatable); cobj:setreference(attrtab); return attrtab; end Figura 3.5 Código LUA que implementa um proxy para o objeto Cell perntecente ao framework C++ do ambiente de modelagem TerraME. Na figura 3.5, a função construtora Cell( attrtable ) instancia um objeto C++ que foi registrado sob o nome TmeCell, conforme ilustra a figura 3.2. Depois, para todos métodos pertencentes a esse objeto, ela define métodos de mesmo nome que delegam sua execução ao objeto C++ que foi instanciado. Antes, porém, verifica se os valores passados como parâmetros aos métodos são validados. 14

15 3.3.4 Emprego do Dialeto Handle-Body O padrão handle-body, também chamado Bridge, tem por objetivo separar a interface de um objeto de sua implementação, de modo que elas possam variar fácil e independentemente. É chamado de dialeto por vários autores por ser um padrão de projeto especifico para a linguagem de programação C++, na qual o conceito de Interface não existe da mesma maneira que, por exemplo, em Java. No projeto TerraME, este padrão foi implementado na forma de um template C++ que é utilizado para desacoplar a interface da classe recebida como parâmetro de sua implementação. As interfaces das classes e suas implementações são mantidas em hierarquias de classes separadas. Todas as operações definidas nas interfaces são implementadas em termos das operações abstratas da interface da implementação. Isto garante que as interfaces e as implementações possam variar independentemente, inclusive em tempo de execução. A figura 3.6 mostra como o padrão handle-body foi implementado utilizando-se a técnica de programação genérica. O código apresentado implementa um coletor de lixo, do termo inglês garbage collector, simples e eficiente para os objetos do framework TerraME. Ele garante que as interfaces instanciadas sempre possuam uma referência valida para uma implementação e que implementações que não sejam referenciadas por nenhuma interface sejam automaticamente destruídas. Isto elimina erros devido à gerência incorreta de memória e por uso de referências inválidas. 15

16 template <class T> class Interface { public: Interface<T>( ){ pimpl_ = new T; pimpl_->attach(); virtual ~Interface<T>(){ pimpl_->detach(); Interface<T>( const Interface& interf ):pimpl_( interf.pimpl_ ) { pimpl_->attach(); Interface<T>& operator=( const Interface& interf) { if ( this!= &interf ) { interf.pimpl_->attach(); pimpl_->detach(); pimpl_ = interf.pimpl_; return *this; protected: // referência para a implementação T *pimpl_; ; class Implementation { public: // Constructor: zero references when the object is being built Implementation(): refcount_ ( 0 ){ // Increases the number of references to this object void attach (){ refcount_++; // Decreases the number of references to this object. // Destroy it if there are no more references to it void detach (){ if ( --refcount_ == 0 ) delete this; // Returns the number of references to this object int refcount(){ return refcount_; private: // Destructor virtual ~Implementation(){ // No copy allowed Implementation(const Implementation&); // Implementation Implementation& operator=(const Implementation&){return *this; int refcount_; // the number of references to this class ; Figura 3.6 O padrão handle-body implementado como templates C++. A figura 3.7 ilustra como o padrão handle-body foi utilizado para desacoplar a interface do objeto Cell pertencente ao framework TerraME de sua implementação. 16

17 class Cell : public Interface<CellImpl> { public: void setlatency( float value ) { pimpl_->setlatency( value ); float getlatency( void ) { return pimpl_->getlatency(); ; class CellImpl : public Implementation { public: float getlatency( void ) { return latency; void setlatency( float value ) { latency = value; private: float latency; ; Figura 3.7 O padrão handle-body aplicado à classe Cell do framework TerraME Emprego do padrão Composite O padrão composite tem por objetivo compor estruturas de objetos agrupados hierarquicamente, para possibilitar que uma classe cliente trate de maneira uniforme objetos individuais e composição desses objetos. Para isto, utiliza-se composição recursiva para que o cliente não tenha que fazer a distinção entre os objetos e as composições, criando-se uma classe abstrata, que representa tanto as primitivas (objetos individuais) como as composições de objetos. No projeto TerraME, o padrão composite é utilizado extensivamente. Por exemplo, um espaço celular (CellulaSpace) é um composite de células (Cell) de forma que todo um espaço celular possa ser tratado como uma única célula. Assim, da mesma forma que o valor de um atributo pode ser obtido para qualquer célula, uma métrica definida sobre esse atributo também pode ser obtida para todo o espaço celular, por exemplo, a média simples dos valores desse atributo em cada célula. Da mesma maneira, uma escala (Scale) é definida como um composite de modelos (Model), onde modelos podem ser objetos do tipo: CellularSpace, GlobalAutomaton, LocalAutomaton, Timer, e Scale. Autômatos são máquinas de estados representadas como composite de elementos do tipo State ou Trajectory. Este último, representa a trajetória de uma autômato sobre um espaço celular. Por sua vez, cada estado (State) é representado como um composite de regras (JumpConditions e FlowConditions). Por fim, relógios (Timer) são representados como composite de pares eventos-mensagem (Event, Message). A 17

18 figura 3.8 apresenta o tipo Scale definido como um composite dos demais modelos do framework TerraME. Figura 3.8 Uma escala é a composição de espaço celulares, autômatos, relógios e escalas aninhadas. Uma vez que foi necessário utilizar o padrão composite várias vezes, para maximizar a reutilização de seu código, este foi implementado como uma classe parametrizada que recebe como parâmetro o tipo dos elementos que serão agregados. Ainda com objetivo de maximizar o reuso do código e flexibilizar ao máximo sua implementação, o dialeto handle-body foi aplicado sobre versão genérica do padrão composite. Desta maneira, o padrão composite se apresenta em duas hierarquias separadas, uma relativa a interface composite e outra relativa à implementação do padrão. Assim, a interface do padrão foi completamente separada de sua implementação. Fato que permite, para uma instância do padrão, a troca em tempo de execução da sua implementação. A figura 3.9 ilustra as hierarquias de classes que implementam o padrão composite. Figura 3.9 Hierarquia de classes da versão genérica do padrão composite. 18

19 A figura 3.10 apresenta trechos do código fonte que permitem entender como, no framework TerraME, o padrão composite foi implementado genericamente e sua interface desacoplada de sua implementação. template <typename CpstImpl > class CompositeInterface : public Interface< CpstImpl > { public: typedef typename CpstImpl::T TElemnt; // Element type typedef typename CpstImpl::TKey Indx; // Element index typedef typename CpstImpl::iterator iterator; // Element iterator // Add a new component void add ( const TElemnt& comp ){ pimpl_->add( comp ); //Return the i-th component TElemnt& operator [] ( Indx i ) { return (*pimpl_)[ i ]; template <typename TElemnt> class vectorcomposite : public Implementation { public: typedef TElemnt T; typedef int TKey; typedef typename vector<t>::iterator iterator; // Add a new component void add ( const T& comp ) { components_.push_back ( comp ); //Return the i-th component T& operator [] ( int i ) { return components_[ i ]; protected: vector<t> components_; ; template <typename TIndx, typename TElmnt > class mapcomposite : public Implementation { public: typedef pair<tindx,telmnt> T; typedef TIndx TKey; typedef typename map<tkey,telmnt, less<tkey> >::iterator iterator; // Add a new component void add ( const T& comp ) { components_.insert( map<tkey,telmnt>::value_type(comp.first, comp.second) ); //Return the i-th component T& operator [] ( TKey k ){ map<tkey,telmnt,less<tkey> >::iterator location = components_.find( k ); return (T&)(*location); protected: map<tkey, TElmnt, less<tkey> > components_; ; Figura 3.10 Trechos do código fonte do framework TerraME que implementam de forma genérica o padrão de projeto de software composite. Contudo, ao se implementar o padrão composite utilizando a técnica de programação genérica, compromete-se o polimorfismo desejado para os métodos definidos na interface CompositeInterface<TCpstImpl>. Por exemplo, a definição: 19

20 class Scale : public CompositeInterface< vectorcomposite<model> > não permite que objetos do tipo CellularSpace, Automaton, Timer e Scale possam ser agrupados pelo padrão composite, pois o compilador não consegue, em tempo de compilação, resolver chamadas polimórficas aos métodos da classe como, por exemplo: scale1.add( cellularspace1 ); scale1.add( automaton1 ); scale1.add( timer1 ); scale1.add(scale2 ); Desta maneira, o tipo Scale do framework TerraME foi implementado através de herança múltipla de cinco diferentes tipos de interfaces para composite, como mostra o trecho de código fonte apresentado na figura Uma escala (Scale) é uma interface para um vector Composite de espaço celulares (CellularSpace), é uma interface para um vectorcomposite de autômatos globais (GlobalAutomaton), é uma interface para um vectorcomposite de autômatos locais (LocalAutomaton), é uma interface para um multimapcomposite de relógios (Timer) parcialmente ordenados pelo tempo neles registrados, e é uma interface para um multimap Composite de escalas (Scale) parcialmente ordenadas pelo tempo registrado no seu primeiro relógio interno. Esta duas últimas estruturas temporais permitem que o simulador TerraME execute as ações de simulação na ordem cronológica correta. Class ScaleImpl : public Implementation { public: void config( float fintime ) { if( fintime > 0 ) { finaltime_ = fintime; else finaltime_ = 0; float getfinaltime( ) { return finaltime_; private: float finaltime_; ; 20

21 class Scale; typedef Interface<ScaleImpl> ScaleInterf; typedef CompositeInterface< vectorcomposite<localagent> > LocalAgentCompositeInterf; typedef CompositeInterface< vectorcomposite<globalagent> > GlobalAgentCompositeInterf; typedef CompositeInterface< vectorcomposite<cellularspace> > CellularSpaceCompositeInterf; typedef CompositeInterface< multimapcomposite<float,scale> > TimeScalePairCompositeInterf; typedef CompositeInterface< multimapcomposite<float,timer> > TimeTimerPairCompositeInterf; class Scale : public Model, public ScaleInterf, public CellularSpaceCompositeInterf, public LocalAgentCompositeInterf, public GlobalAgentCompositeInterf, public TimeTimerPairCompositeInterf, public TimeScalePairCompositeInterf { public: void config( float fintime ) { ScaleInterf::pImpl_->config( fintime ); void add ( CellularSpace &cs ){ CellularSpaceCompositeInterf::add ( cs ); void add ( LocalAgent &agent ){ LocalAgentCompositeInterf::add ( agent ); void add ( GlobalAgent &agent ){ GlobalAgentCompositeInterf::add ( agent ); void add ( const pair<float,scale> &timescalepair ){ TimeScalePairCompositeInterf::add ( timescalepair ); void add ( const pair<float,timer> &timetimerpair ){ TimeTimerPairCompositeInterf::add ( timetimerpair ); Figura 3.11 No framework TerraME, uma escala é definida como uma interface para cinco diferentes tipos de composites. 21

22 4Objetivos O presente projeto tem por objetivo dirimir as limitações atuais da integração do framework TerraME com a linguagem LUA. Para isso, a API C++ do framework TerraME será completamente registrada no ambiente de execução da linguagem de programação LUA. Dessa forma, usuários que só conheçam a linguagem TerraME poderão utilizar todos os recursos que o ambiente de modelagem TerraME lhes oferecei, sem que seja necessário conhecimento sobre a linguagem de programação C++. Além disso, este projeto também tem como objetivo, a documentação do framework TerraME, consistir seu documento de especificação com a implementação do framework, e elaborar um manual do usuário, com exemplos de uso. 22

23 5Justificativas Atualmente, o ambiente de modelagem TerraME se encontra em um estado avançado de desenvolvimento, visto que vem sendo utilizado, sem problemas, para o desenvolvimento de modelos ambientais completos que encontram amplo respaldo na comunidade internacional como, por exemplo, o modelo CLUE para mudança de uso e de cobertura do solo (Veldkamp 1996) e o modelo TROLL para dinâmica de florestas tropicais (Chave 1999). Apesar de ter seu núcleo completamente implementado na forma de um framework C++, a API desse núcleo não foi totalmente registrada no ambiente execução da linguagem de modelagem TerraME. Desta maneira, suas funcionalidades não são totalmente acessíveis através da linguagem TerraME. Este fato limita a gama de modelos que poderiam ser desenvolvidos através do seu uso, obrigando o uso da linguagem C++ para o desenvolvimento de tais modelos. Portanto, é importante que sua integração seja realizada para ampliar o uso do ambiente de modelagem TerraME. A documentação do produto de software resultante deste trabalho é de suma importância para as atividades de manutenção e evolução deste produto. Ela facilitará o treinamento de futuros desenvolvedores e usuários do ambiente de modelagem TerraME. 23

24 6Metodologia O desenvolvimento deste projeto utilizará a metodologia de desenvolvimento de software em espiral com prototipagem de releases e versões. Dessa forma, as etapas de concepção, projeto, implementação, teste e documentação serão executadas de forma cíclica, e a cada ciclo será obtida uma nova versão documentada do aplicativo TerraME. 6.1 Requisitos O sistema deverá conter os seguintes requisitos: * O ambiente de desenvolvimento TerraME, com todas as suas funcionalidades registradas, tendo o usuário, acesso a todas essas funcionalidades através da linguagem TerraME. * Um sistema documentado, de forma a facilitar sua manutenção, evolução e treinamento de usuários e futuros desenvolvedores. Dessas forma, será possível, a partir da linguagem TerraME, ter acesso a todas as funcionalidades do ambiente de desenvolvimento TerraME. Tendo também, com a documentação completa, uma otimização do processo de evolução e manutenção do TerraME. 6.2 Arquitetura Quanto a integração do framework TerraME com LUA, a arquitetura se resume a utilização dos padrões proxy, binder e wraper (adapter), que são os responsáveis por esta comunicação, assim como mostra a figura 6.1: 24

25 Figura 6.1 Representação da comunicação da API C++ do framework TerraME com LUA, através dos padrões proxy, binder e adapter. Como é mostrado na figura acima, ao na ligação da linguagem TerraME ao framework TerraME, um proxy verifica se os valores passados como parâmetro são válidos e também se todos os parâmetros necessários para a criação dos objetos C++ foram passados corretamente, de forma a garantir que os objetos C++ sejam criados e utilizados corretamente. O binder traduz as operações realizadas na linguagem TerraME para operações de mesma semântica no framework TerraME (API C++), registrando as interfaces C++ das classes do framework TerraME no ambiente de execução da linguagem LUA e permitindo que os objetos possam ser instanciados e ligados a identificadores na linguagem TerraME. O wraper adapta a interface das classes do framework TerraME às interfaces de mesma semântica com assinatura aceita pela linguagem LUA (métodos com assinaturas do forma int() (lua_state*)), para que possam trocar informações entre si Atividades Durante este projeto, serão realizadas as seguintes fases: PRIMEIRA FASE PROJETO Atividade Revisão bibliográfica sobre a linguagem LUA, com ênfase na sua API C++. 25

26 Atividade 1.2 Revisão bibliográfica sobre ambiente de modelagem TerraME, sua arquitetura, organização e as técnicas de programação aplicadas em seu Framework. Atividade 1.3 Implementação de uma pequena aplicação C++ e sua exportação para LUA. Esta aplicação será utilizada como exemplo, para poder entender como será feita esta exportação. Atividade 1.4 Verificar os pontos da integração com LUA que precisam ser implementados, complementados ou corrigidos. SEGUNDA FASE DESENVOLVIMENTO Atividade 2.1 Correção dos pontos falhos na integração com LUA. Atividade 2.2 Complementação das partes Incompletas dessa integração. Atividade 2.3 Implementação das partes que ainda não existem nessa integração. TERCEIRA FASE TESTES Atividade 3.1 Teste e depuração do ambiente de modelagem, estudando as falhas observadas para que seja proposta a elas uma solução. QUARTA FASE DOCUMENTAÇÃO Atividade 4.1 Complementar o atual documento de especificação, consistindo-o inclusive com a nova implementação. Atividade 4.2 Elaboração de um manual do usuário: documento que ensina como usar o ambiente de modelagem, trazendo consigo alguns exemplos de uso. 26

27 7Cronograma de execução do projeto Pretende-se executar o projeto respeitando o seguinte cronograma de execução: Ano 1 MESES Atividades PROJETO DESENVOLVIMENTO TESTE 3.1 DOCUMENTAÇÃO

28 8Infra-estrutura disponível O laboratório associado INPE/UFOP para modelagem e simulação de sistemas terrestres (TerraLAB) não possui equipamentos de computação e nem mobiliários, de forma que todas as pesquisas desenvolvidas por sua equipe são realizadas ou nos domicílios de seus membros ou nos laboratórios de ensino do departamento de computação da Universidade Federal de Ouro Preto. 28

29 9Recursos pretendidos Para o desenvolvimento deste trabalho, são necessários os seguintes recursos, além daqueles existentes no laboratório TerraLAB e especificados na seção anterior: 9.1 Equipamentos e Material Permanente 29

30 10Metas e indicadores de avaliação Como dito anteriormente, este projeto tem as seguintes metas: * Dirimir as limitações atuais da integração do framework TerraME com a linguagem LUA, registrando completamente sua API C++ na linguagm LUA, tornando assim todas as funcionalidades do ambiente de modelagem TerraME acessíveis através da linguagem TerraME. * Documentar o framework TerraME, consistindo o documento de especificação com a sua implementação, e elaborando um manual do usuário, com exemplos de uso, facilitando os processos de manutenção e evolução do produto. * Divulgar resultados da pesquisa em congressos e revistas especializadas contribuindo com a difusão das técnicas de modelagem e simulação de sistemas terrestres. conhecimento. * Contribuir para a formação de recursos humanos especializados nessa área do avaliação: As metas acima poderão ser atingidas com base nos seguintes indicadores de * Entrega, em três etapas, de versões documentadas do aplicativo, para planejamento de rotas; protótipo em 3 meses, versão beta em 6 meses, release ao final de 1 ano. * Produção, no oitavo mês de execução do projeto, de um artigo completo para submissão em anais de eventos científico da área. * Apresentação de um trabalho em evento científico nacional da área. * Produção de relatório técnico-científico ao final do projeto, detalhando a metodologia adotada para tratar o problema. Esse relatório estará disponível na homepage do coordenador do projeto, a partir de link s na sua página inicial ( 30

31 * Desenvolvimento, ao final do projeto, de uma nova versão do ambiente de modelagem TerraME, totalmente integrado com a linguagem de programação LUA, e documentado, como proposto neste projeto. 31

32 Bibliografia Chave, J. (1999). "Study of structural, successional and spatial patterns in tropical rain forests using TROLL: a spatially explicit forest model." Ecological Modelling. Palozzi, Lenny (2006). LTN-5 A template class for binding C++ to Lua, LUA Technical Notes, disponivel em: Veldkamp, A. and L. O. Fresco (1996). "CLUE: a conceptual model to study the Conversion of Land Use and its Effects." Ecological Modelling 85: Ierusalimschy, Programming in LUA (1996) Gamma, E., Helm, R.; Johnson, R.; Vlissides, J., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional; 1a. Edição (1995) 32