Universidade Federal de Pernambuco Centro de Informatica

Transcrição

1 Universidade Federal de Pernambuco Centro de Informatica Pos-Graduac~ao em Ci^encia da Computac~ao CMF: um framework multi-plataforma para desenvolvimento de aplicac~oes para dispositivos moveis Dissertac~ao de Mestrado por Tiago Guedes Ferreira Barros Recife 24 de Agosto de 2007

2 UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORM ATICA TIAGO GUEDES FERREIRA BARROS CMF: um framework multi-plataforma para desenvolvimento de aplicac~oes para dispositivos moveis Este trabalho foi apresentado a Pos-Graduac~ao em Ci^encia da Computac~ao do Centro de Informatica da Universidade Federal de Pernambuco como requisito parcial para a obtenc~ao do grau de Mestre em Ci^encia da Computac~ao. ORIENTADOR: Prof. Dr. Andre Lus de Medeiros Santos CO-ORIENTADOR: Prof. Dr. Geber Lisboa Ramalho Recife, 24 de Agosto de 2007

3 Barros, Tiago Guedes Ferreira CMF: um framework multi-plataforma para desenvolvimento de aplicações para dispositivos móveis / Tiago Guedes Ferreira Barros. Recife : O Autor, viii, 92 folhas : il., fig., tab. Dissertação (mestrado) - Universidade Federal de Pernambuco. CIn. Ciência da computação, Inclui bibliografia. 1. Engenharia de software. 2. Aplicações para celulares. 3. Frameworks de aplicações. 4. Linux. 5. Brew. I. Título CDD (22.ed.) MEI

4 Dissertarc~ao de Mestrado apresentada por Tiago Guedes Ferreira Barros a Pos-Graduac~ao em Ci^encia da Computac~ao do Centro de Informatica da Universidade Federal de Pernambuco, sob o ttulo \CMF: Um Framework Multi-plataforma para Desenvolvimento de Aplicac~oes para Dispositivos Moveis", orientada pelo Prof. Andre Lus de Medeiros Santos e aprovada pela Banca Examinadora formada pelos professores: Visto e permitida a impress~ao. Recife, 24 de agosto de 2007.

5 - AGRADECIMENTOS Que a forca do medo que tenho, n~ao me impeca de ver o que anseio. Que a arte nos aponte uma resposta, mesmo que ela n~ao saiba, E que ninguem a tente complicar, porque e preciso simplicidade para faz^e-la orescer... Porque metade de mim e a criac~ao, e na outra habita o criador. fadaptado de Metade, de Oswaldo Montenegro.g Agradeco a Deus e aos meus pais, pela vida, e dedico este trabalho a eles. Gostaria de registrar meus agradecimentos como um reconhecimento sincero da dedicac~ao das muitas pessoas que, direta ou indiretamente, contriburam para a realizac~ao deste trabalho. Agradeco a minha famlia, pelo apoio, compreens~ao e incentivo, n~ao so durante o perodo da pos-graduac~ao, mas em todos os momentos importantes de minha vida. Agradeco a minha noiva, Carine, pessoa maravilhosa, por todo carinho, compreens~ao e ajuda durante o decorrer do meu curso. Agradeco tambem aos meus orientadores e amigos Andre Santos e Geber Ramalho e a todos os Mestres que contriburam para a minha formac~ao acad^emica, pessoal e prossional. Um agradecimento especial aos demais professores componentes da banca, Sergio Cavalcante e Sergio Soares, pela paci^encia e por todas as contribuic~oes dadas a este trabalho. N~ao poderia deixar de agradecer aos amigos que contriburam efetivamente no desenvolvimento desta dissertac~ao: Mauro Silva, Angelo Ribeiro, Gustavo Eliano, Tarciana Mello e Nara Lyra, apoiando-me e incentivando-me sempre. Agradeco tambem aos amigos Pedro Lages, Edilson Mendes, Eduardo Peixoto, Saulo Dourado, Karina Limongi, Eduardo Jose e Ricardo Couto, por sua efetiva participac~ao na construc~ao do Gluon, ferramenta desenvolvida e utilizada neste trabalho. Agradeco a Chico Buarque, Vincius de Moraes, Tom Jobim, Toquinho e Oswaldo Montenegro, compositores das musicas que escutei e que me inspiraram durante toda a escrita desta dissertac~ao. Por m agradeco a todos os meus amigos, que contriburam de todas as formas para a realizac~ao deste trabalho. i

6 RESUMO Com o crescimento da tecnologia de telefonia celular, estes dispositivos passaram cada vez mais a focar seus objetivos em processamento e transmiss~ao de dados. Devido ao seu grande poder de conectividade e a sua mobilidade, os celulares tambem se tornaram uma potencial plataforma para o desenvolvimento de aplicac~oes. Desta forma, os fabricantes de aparelhos passaram a disponibilizar plataformas de desenvolvimento para que terceiros pudessem desenvolver aplicac~oes para os seus celulares. A primeira iniciativa neste sentido foi a inclus~ao de uma maquina virtual Java nos telefones TDMA e GSM; e um ambiente de execuc~ao de aplicac~oes chamado BREW, para CDMA. Com a evoluc~ao do hardware dos dispositivos, comecou-se a adotar sistemas operacionais abertos como: Symbian; Windows Mobile; e Embedded linux. Estes sistemas operacionais tambem permitem o desenvolvimento de aplicac~oes por terceiros. Assim, percebe-se que n~ao existe uma plataforma padr~ao para desenvolvimento de aplicac~oes para dispositivos moveis. Para que uma aplicac~ao possa ser instalada no maior numero de dispositivos possvel, esta deve ser portada entre as diferentes plataformas de desenvolvimento. Alem disto, todas estas plataformas de desenvolvimento s~ao dirigidas a eventos. No entanto, elas n~ao oferecem uma arquitetura que facilite o desenvolvimento de aplicac~oes desta forma. O objetivo deste trabalho e especicar e implementar um framework de aplicac~oes para dispositivos moveis que minimize o esforco de porting de aplicac~oes entre as plataformas. Deve ser disponibilizada tambem uma arquitetura que auxilie o desenvolvimento de aplicac~oes dirigidas a eventos. Alem disto, visa-se propor uma soluc~ao para um ambiente de desenvolvimento multi-plataforma que seja integrado ao Framework proposto e auxilie na interoperabilidade do desenvolvimento em varias plataformas diferentes. Este objetivo foi alcancado atraves da implementac~ao do CMF - C.E.S.A.R Mobile Framework - framework multi-plataforma de aplicac~oes para dispositivos moveis; e do Gluon, ambiente de desenvolvimento para estes dispositivos. O CMF auxilia o desenvolvimento de aplicac~oes dirigidas a eventos e permite que uma aplicac~ao que foi desenvolvida para uma determinada plataforma possa ser executada em outras plataformas, sem que seu codigo seja alterado. O Gluon possibilita um aumento de produtividade no desenvolvimento destas aplicac~oes, automatizando varias tarefas de congurac~ao de ambiente, compilac~ao e depurac~ao do codigo, permitindo que o desenvolvedor foque no desenvolvimento da aplicac~ao. Palavras-chave: Aplicac~oes para celulares, BREW, Embedded Linux, Frameworks de Aplicac~oes, Dispositivos Moveis, Ambientes de desenvolvimento, IDE, Eclipse, Padr~oes de Projeto, MVC. ii

7 ABSTRACT With the growth of cell phone technology, these devices started focusing on data applications and data transmission, becoming platforms for software development. In parallel, device manufacturers started opening their platforms for third-party development. The rst initiative towards to this was to include a Java Virtual Machine into TDMA and GSM phones; and an execution environment called BREW for CDMA phones. With devices' hardware evolution, some operating systems were also developed for mobile devices, such as Symbian, Windows Mobile and Embedded Linux. These operating systems also allow third-party application development. Due to the number of platforms, there is no standard development platform for mobile devices. Application developers needs to port the applications among these platforms to reach a great number of supported devices. Another point to be considered is that all development platforms are event-driven but the platforms' architecture does not have good event handling support. According to these scenarios, the main goal of this work is to specify and implement an application framework for mobile devices that minimize the porting eort among the platforms. This Framework shall also have an event-driven architecture to assist mobile applications development. It is also part of the goal, a proposal for an integrated development environment that uses the proposed framework and helps the platform interoperability. This goal was reached by implementation of CMF - C.E.S.A.R Mobile Framework, a multi-platform framework for developing mobile applications; and by the implementation of Gluon, an integrated development environment for mobile devices. CMF assists development of event-driven applications and enables the application execution on more than one platform without changing the application's code. Gluon leverages development productivity by automating environment conguration tasks and setup of compiling and debugging environments, making developer to focus on application development. Keywords: Cellphone Applications, BREW, Embedded Linux, Application Frameworks, Mobile Devices, Integrated Decvelopment Environments (IDE), Eclipse, Design Patterns, MVC. iii

8 SUMARIO Captulo 1 Introduc~ao Contexto Motivac~ao Trabalhos Relacionados Interface com Usuario Abstrata (AUI) Maquinas Virtuais Contribuic~oes Organizac~ao Captulo 2 Plataformas de Desenvolvimento para Dispositivos Moveis Introduc~ao J2ME BREW Symbian OS Windows Mobile Embedded Linux Qt GTK Comparando plataformas Captulo 3 CMF - Metodologia, Requisitos e Arquitetura Introduc~ao Metodologia Requisitos Funcionais [RF001] - Ponto de entrada da aplicac~ao [RF002] - Acesso a tela [RF003] - Gerenciamento de telas [RF004] - Gerenciamento de telas - Classe base [RF005] - Gerenciamento de telas - Traduc~ao de eventos [RF006] - Maquina de estados [RF007] - Maquina de estados - Classe base para estados [RF008] - Maquina de estados - Despacho de eventos [RF009] - Maquina de estados - Comunicac~ao entre os servicos [RF010] - Acesso as informac~oes do sistema [RF011] - Servicos iv

9 sumario v [RF012] - Recursos Requisitos N~ao-Funcionais [RNF001] - Portabilidade [RNF002] - Desempenho [RNF003] - Escopo do Framework [RNF004] - Extensibilidade [RNF005] - Internacionalizac~ao Arquitetura Estrutura Din^amica Ambiente de Desenvolvimento Ferramentas de Desenvolvimento em BREW Ferramentas de Desenvolvimento em Linux Proposta de Integrac~ao dos Ambientes de Desenvolvimento Captulo 4 CMF - Implementac~ao Introduc~ao Implementac~ao do CMF Tipos de dados Ponto de Entrada da Aplicac~ao BREW Embedded Linux Classe de Aplicac~ao Gerenciador de Objetos Maquina de Estados Estados da Aplicac~ao Dispositivo Graco BREW Embedded Linux Gerenciador de Telas Telas da Aplicac~ao Chamadas ao Sistema Servicos do sistema Testes de conformidade Estados do CCT Telas Captulo 5 Gluon - Um Ambiente Integrado de Desenvolvimento Introduc~ao A plataforma Eclipse A arquitetura de plug-ins do Eclipse CDT - Eclipse C/C++ Development Tooling Gluon

10 sumario vi 5.4 Componentes do ambiente Gluon Implementac~ao do Gluon Integrac~ao do Gluon com ferramentas externas Compilac~ao Depurac~ao Simulac~ao Integrac~ao com SDKs Screenshots Captulo 6 Estudo de Caso Introduc~ao Metodologia do Estudo de Caso Escopo do Estudo de Caso Apresentac~ao dos Resultados Quantidade de linhas de codigo(kloc) Esforco Tamanho Desempenho Considerac~oes Finais Captulo 7 Conclus~ao e Trabalhos Futuros Contribuic~oes Problemas Encontrados Trabalhos Futuros

11 LISTA DE FIGURAS 1.1 Arquitetura Java para dispositivos moveis NET Compact Framework Pers, congurac~oes e API's de J2ME Modelo de negocios de BREW Desenvolvimento de uma aplicac~ao BREW Symbian Application Framework Diagrama de classes de Qt Padr~ao MVC Diagrama de classes UML do CMF Construc~ao de uma aplicac~ao no CMF Inicializac~ao de uma aplicac~ao usando o CMF Din^amica do tratamento de eventos de uma aplicac~ao usando o CMF Estrutura do repositorio do codigo do CMF Diagrama de estados da aplicac~ao CCT Arquitetura da plataforma Eclipse Arquitetura dos plug-ins do Eclipse Relacionamento entre o Gluon e o CDT Tela inicial do Gluon Gluon: depurac~ao de codigo no simulador Resultado das medidas de linhas de codigo (KLOC) Resultado das medidas de esforco Resultado das medidas de tamanho da aplicac~ao Resultado das medidas de tempo de execuc~ao Resultado da analise das metricas para o CMF vii

12 LISTA DE TABELAS 2.1 Comparac~ao entre as plataformas Criterios para escolha das plataformas Pontuac~ao das plataformas de acordo com os criterios Estimativa de implementac~ao do Gluon Comparac~ao das funcionalidades do Gluon em relac~ao ao ambiente de desenvolvimento atual para BREW Ordem de implementac~ao das aplicac~oes do estudo de caso Resultado das medidas de linhas de codigo (KLOC) Resultado das medidas de esforco Resultado das medidas de tamanho da aplicac~ao Resultado das medidas de desempenho Resultado das metricas calculadas para o CMF viii

13 - CAP ITULO 1 INTRODUC ~AO Neste captulo sera apresentada uma introduc~ao ao desenvolvimento de aplicac~oes para dispositivos moveis. Tambem ser~ao apresentadas as diversas plataformas de desenvolvimento existentes, bem como o funcionamento do processo de porting de aplicac~oes entre dispositivos e entre diferentes plataformas. Finalmente, e feita uma breve apresentac~ao da proposta de trabalho, abordando o escopo e sua contribuic~ao. 1.1 CONTEXTO Com o crescimento da tecnologia de telefonia celular, estes dispositivos, que antes eram centrados na transmiss~ao de voz, passaram cada vez mais a focar seus objetivos em processamento e transmiss~ao de dados. Tirar fotos, receber s ou navegar na web est~ao se tornando atividades comuns aos celulares atuais. Devido ao seu grande poder de conectividade e a sua mobilidade, os celulares tambem se tornaram uma potencial plataforma para o desenvolvimento de aplicac~oes. Desenvolver aplicac~oes para estes dispositivos e bastante diferente de desenvolver aplicac~oes para PC's. Devido a sua arquitetura fechada e baixo poder de processamento, principalmente nos primeiros celulares, cada fabricante de dispositivos terminou por desenvolver seu prorio hardware e, consequentemente, seu proprio sistema operacional. Estes sistemas operacionais, alem de todo o software e o hardware do dispositivo como um todo, s~ao as informac~oes mais importantes do telefone para os fabricantes. Devido a isso, os fabricantes n~ao permitem que terceiros conhecam seus sistemas proprietarios a m de que desenvolvam suas proprias aplicac~oes. Ent~ao, neste incio, os proprios fabricantes passaram a desenvolver aplicac~oes acessorias, principalmente jogos, para adicionar um diferencial aos seus dispositivos. No entanto, os fabricantes n~ao conseguiam desenvolver aplicac~oes na escala necessaria, o que terminou por faz^e-los procurar formas de disponibilizar o desenvolvimento de aplicac~oes para outras empresas. A primeira iniciativa neste sentido foi a inclus~ao da maquina virtual java nos dispositivos TDMA[BKNR03]. Isto permitiu o desenvolvimento de aplicac~oes em J2ME[SUN], subconjunto da linguagem java, para dispositivos com limitac~ao de processamento e memoria. O aparecimento das tecnologias de comunicac~ao digital GSM e CDMA abriram novas possibilidades para o desenvolvimento de aplicac~oes. O CDMA, desenvolvido pela Qualcomm[QUA], ja previa o desenvolvimento de aplicac~oes no seu incio, incorporando o ambiente de desenvolvimento BREW aos chipsets dos telefones. Em GSM, os fabricantes passaram a experimentar e utilizar sistemas operacionais abertos, como Windows 1

14 1.2 motivac ~ao 2 Mobile[MICa], Symbian[SYM] e Embedded Linux[HOL02], o que, somado a J2ME, aumentou bastante a quantidade de alternativas para o desenvolvimento de aplicac~oes. Atualmente temos diversas plataformas para o desenvolvimento de aplicac~oes para celulares. Estas plataformas s~ao disponibilizadas pelos fabricantes de dispositivos para que outras empresas desenvolvam aplicac~oes para os seus aparelhos, aumentando assim, o valor percebido pelos clientes. Portanto, hoje existem diversas empresas especializadas no desenvolvimento de aplicac~oes para celulares e o maior problema enfrentado por elas e fazer com que suas aplicac~oes funcionem no maior numero de aparelhos possvel, ou seja, elas precisam portar estas aplicac~oes para os dispositivos desejados. Veremos com mais detalhes os problemas inerentes ao porting de aplicac~oes na proxima sec~ao. 1.2 MOTIVAC ~AO Do ponto de vista da interface com o usuario, os celulares possuem geralmente con- gurac~oes de hardware muito parecidas. Todos possuem tela, um teclado numerico, softkeys, alto-falantes e microfone, conex~ao de rede, e alguns possuem c^amera e conex~ao bluetooth. No entanto, como visto na Sec~ao 1.1, estes dispositivos possuem diferentes plataformas de desenvolvimento. Abaixo segue uma descric~ao das tecnologias mais utilizadas: J2ME - Java 2 Micro Edition [SUN]: possui uma boa aceitac~ao por parte dos desenvolvedores, pois Java e uma linguagem de facil programac~ao e possui uma portabilidade satisfatoria. Como pontos negativos, temos o baixo desempenho e algumas limitac~oes na API. BREW - Binary Runtime Environment for Wireless [QUA]: desenvolvido pela Qualcomm, e um ambiente de execuc~ao para telefones CDMA que permite rodar aplicac~oes em linguagem C. Possui a vantagem de rodar mais rapido do que Java e permite acesso a quase todos os elementos do hardware disponvel nos telefones CDMA. Symbian OS [SYM]: Symbian e um consorcio de empresas de telefonia para o desenvolvimento de um sistema operacional para celulares. O Symbian OS possui o conceito de \open standard operating system" (sistema operacional de padr~ao aberto) o que permitiu, pela primeira vez, que fossem desenvolvidas aplicac~oes para celulares assim como s~ao desenvolvidas para PC's. Embedded Linux [HOL02]: Vers~ao do SO Linux para sistemas embarcados. Tem o seu uso crescente principalmente em telefones celulares. O desenvolvimento de aplicac~oes e feito em C ou C++, utilizando-se vers~oes reduzidas de frameworks gracos como QT e GTK. Windows Mobile [MICa]: Sistema operacional para celulares baseado no Windows. Constitui um sub-conjunto das funcionalidades do Windows, de forma que a programac~ao e o acesso aos recursos do hardware s~ao feitos da mesma maneira que

15 1.3 trabalhos relacionados 3 a programac~ao para desktops. Pode-se desenvolver em C++ ou para a plataforma.net (C# ou VB.NET). Cada uma das tecnologias citadas possui uma forma de desenvolvimento diferente. A maioria delas e baseada em eventos, no entanto, n~ao disp~oem de uma estruturac~ao arquitetural adequada ao desenvolvimento de aplicac~oes baseadas em eventos e estados. Alem disto, apesar de J2ME estar presente em quase todos os aparelhos GSM (que representam 62% do mercado[int06]), as aplicac~oes que necessitam de um maior controle ou acesso ao dispositivo n~ao s~ao escritas em J2ME, o que nos leva a concluir que ainda n~ao existe uma tecnologia completamente dominante no desenvolvimento de aplicac~oes para dispositivos moveis e portar aplicac~oes entre estas plataformas se faz necessario. O problema de porting de aplicac~oes e bastante potencializado no ^ambito dos dispositivos moveis. Diversas empresas est~ao focando os seus esforcos no porting de aplicac~oes, tanto para aumentar a distribuic~ao das suas aplicac~oes quanto para fazer desta atividade o seu principal negocio. Existem dois principais problemas a serem atacados quando estamos portando uma aplicac~ao: a customizac~ao da interface; e a diferenca entre as plataformas de desenvolvimento. A customizac~ao da interface consiste em adaptar a interface da aplicac~ao para diversos dispositivos. Esta adaptac~ao consiste basicamente em alterac~oes no tamanho da tela e layout das teclas, menus e opc~oes. Apesar de parecer simples, 30% do tempo de desenvolvimento e gasto na resoluc~ao deste problema de porting. Existem diversos estudos e iniciativas como [CPS04] [PHA00] [PQ02] [EVP00] [EVP01] [MHP00] que tratam o problema de customizac~ao de interface. Portar uma aplicac~ao entre diferentes plataformas de desenvolvimento e uma atividade que requer mais esforco do que apenas customizar a sua interface. As diferencas de API, formas de acesso aos recursos do hardware, linguagens de programac~ao e interac~ao com o dispositvo s~ao apenas alguns dos problemas inerentes a esta tarefa. 1.3 TRABALHOS RELACIONADOS Nesta sec~ao ser~ao abordados os princpios dos sistemas concebidos para funcionarem em diversas plataformas. A maioria das pesquisas aponta para abstrac~ao da interface graca, atraves de uma linguagem descritiva, e para a migrac~ao das aplicac~oes sobre uma maquina virtual como as alternativas para desenvolvimento destes sistemas Interface com Usuario Abstrata (AUI) Diversas pesquisas est~ao sendo feitas no sentido de desenvolver sistemas multiplataforma. A maioria destas pesquisas [MHP00] [EVP00] [EVP01] considera a abstrac~ao da interface com o usuario como alternativa para o desenvolvimento de aplicac~oes. Alguns trabalhos [PHA00] [PQ02] visam a utilizac~ao de linguagens descritoras de interface baseadas em XML como UIML - User Interface Markup Language. Estas linguagens permitem abstrair e descrever os objetos comuns de uma interface com o usuario, denindo objetos de interface can^onicos sendo implementados nas diferentes plataformas.

16 1.3 trabalhos relacionados 4 Desta forma, uma interface descrita em UIML pode ter sua implementac~ao em J2SE para desktops, e em J2ME para celulares, mapeando a descric~ao da interface nos controles de interface inerentes a cada plataforma. Seguindo esta mesma linha, algumas pesquisas [CPS04] visam transformar as interfaces para que se adaptem aos diferentes tamanhos de tela e formas de entrada de dados (teclado ou touch screen, por exemplo). Neste caso, n~ao existe uma linguagem de descric~ao de interface, mas sim uma API com um conjunto de controles abstratos sobre a qual a aplicac~ao e construda. Estes controles abstratos possuem correspondentes concretos em cada plataforma, que s~ao instanciados dinamicamente dependendo da plataforma que a aplicac~ao esta rodando. No entanto, abstrair e adaptar a interface e apenas uma parte do problema de portar uma aplicac~ao de uma plataforma para outra. Todas as pesquisas que apontam neste sentido consideram que as diferentes plataformas possuem uma mesma API ou forma de programac~ao, e a diferenca entre elas e apenas na dimens~ao da tela e forma de entrada de dados. Desta forma, estas abordagens n~ao resolvem o problema de porting quando o mesmo ocorre entre plataformas com API's e ate linguagens de programac~ao diferentes Maquinas Virtuais Uma outra abordagem para o desenvolvimento de sistemas portaveis seria a utilizac~ao de maquinas virtuais. Uma maquina virtual e uma camada de software que abstrai o sistema operacional, provendo a aplicac~ao toda API necessaria. A maquina virtual tambem e responsavel por garantir a seguranca na execuc~ao da aplicac~ao e por interpretar o codigo da aplicac~ao e executa-lo no sistema correspondente. As principais maquinas virtuais para dispositivos moveis s~ao: Maquina Virtual Java[SUN]: interpreta J2ME;.NET Compact Framework [MICa]: maquina virtual do Windows Mobile.NET. A arquitetura Java para dispositivos moveis e dividida em 3 camadas sobre o sistema operacional: a maquina virtual propriamente dita (KVM); os pers; e as congurac~oes. Figura 1.1. Arquitetura Java para dispositivos moveis A KVM - Kilobyte Virtual Machine - e a base da arquitetura, responsavel por interpretar e executar o codigo Java e abstrair o sistema operacional. Sobre a maquina virtual s~ao denidas as congurac~oes, que s~ao um conjunto mnimo de classes que prov^eem as

17 1.4 contribuic ~oes 5 funcionalidades basicas para as categorias de dispositivos. Sobre a congurac~ao, s~ao denidos os pers, API's de alto-nvel que disponibilizam um ambiente de execuc~ao completo e direcionado para os dispositivos alvo. O.NET Compact Framework possui duas partes principais: a Common Language Runtime (CLR) e a.net Compact Framework Class Library. A CLR e responsavel por gerenciar, interpretar e executar o codigo das aplicac~oes, que e gerado em forma de bytecode (linguagem intermediaria). A.NET Compact Framework Class Library e um conjunto de API's para a construc~ao de aplicac~oes. Estas API's v~ao desde a criac~ao de janelas e controles gracos ate gerenciamento de dados e Web Services. Uma das vantagens do.net e a possibilidade de escrever codigo em varias linguagens de programac~ao. Figura 1.2..NET Compact Framework Apesar de possuir boa portabilidade das aplicac~oes, devido a uma API comum aos dispositivos, as maquinas virtuais n~ao conseguem resolver o problema do desenvolvimento de aplicac~oes multi-plataforma completamente, pois a interface com o usuario ainda e dependente da interface do dispositivo. Alem disto, as maquinas virtuais possuem problema de desempenho, visto que o codigo das aplicac~oes e interpretado. A falta de acesso aos recursos mais especcos do hardware tambem e outro problema, pois as API's implementadas s~ao apenas as API's comuns a todos os dispositivos. 1.4 CONTRIBUIC ~OES O objetivo deste trabalho e facilitar o desenvolvimento de aplicac~oes para dispositivos moveis, particularmente, telefones celulares, atraves da construc~ao do CMF - CESAR Mobile Framework - um framework multi-plataforma para o desenvolvimento de aplicac~oes para dispositivos moveis. Portanto, propusemos uma nova arquitetura para desenvolvimento de aplicac~oes que facilite este desenvolvimento provendo um suporte a maquina de estados e que seja dirigida a eventos, para padronizar a forma de comunicac~ao entre a aplicac~ao e o dispositivo. Assim, poderemos implementar este Framework em varias plataformas, possibilitando que as aplicac~oes sejam escritas da mesma forma e usando uma mesma API, independente da plataforma escolhida. Escolhemos a linguagem de programac~ao C++ para a implementac~ao do Framework, visto que e a linguagem comum entre a maioria das plataformas de desenvolvimento de

18 1.5 organizac ~ao 6 aplicac~oes para dispositivos moveis, com excec~ao de J2ME. Alem do desenvolvimento de um framework multi-plataforma, construimos tambem um ambiente integrado de desenvolvimento, baseado na plataforma Eclipse, para que possamos realmente ter um ganho de produtividade ao alternarmos o desenvolvimento entre as plataformas. Portanto, dois problemas foram alvo desta proposta: Facilitar o desenvolvimento de aplicac~oes atraves de um suporte a maquinas de estados e eventos, bem como atraves da utilizac~ao de um ambiente integrado de desenvolvimento para as plataformas alvo, visto que as outras IDE's n~ao oferecem um ambiente integrado para mais de uma plataforma; E tambem resolver o problema de porting de aplicac~oes entre diferentes plataformas, provendo uma API comum para o desenvolvimento e abstraindo as interfaces individuais de cada plataforma para a disponibilizac~ao de uma interface comum. 1.5 ORGANIZAC ~AO Este trabalho esta organizado como segue: O Captulo 2 apresenta as plataformas mais utilizadas para o desenvolvimento de aplicac~oes para dispositivos moveis, os conceitos existentes no desenvolvimento de aplicac~oes para estes dispositivos bem como uma comparac~ao entre as diversas plataformas. Os requisitos e a proposta de arquitetura do Framework implementado ser~ao apresentados no Captulo 3. O Captulo 4 apresenta os detalhes da implementac~ao do Framework, bem como as restric~oes de implementac~ao assumidas devido as diversas plataformas. A implementac~ao de uma ferramenta para desenvolvimento integrado de aplicac~oes sera apresentado no Capitulo 5. No Captulo 6 ser~ao apresentados estudos de caso nos quais foi utilizado o Framework desenvolvido. Finalmente, o Captulo 7 conclui o trabalho e sugere possveis caminhos a serem abordados para trabalhos futuros.

19 - CAP ITULO 2 PLATAFORMAS DE DESENVOLVIMENTO PARA DISPOSITIVOS MOVEIS Neste captulo ser~ao apresentadas as principais plataformas de desenvolvimento de aplicac~oes para dispositivos moveis. Para cada plataforma, sera apresentado um breve historico, quais as linguagens de programac~ao disponveis e como e feito o desenvolvimento de aplicac~oes. Finalmente, sera feita uma analise comparativa entre as plataformas abordadas. 2.1 INTRODUC ~AO Como pudemos perceber no Captulo 1, foram citadas maquinas virtuais, ambientes de execuc~ao e sistemas operacionais como alternativas para o desenvolvimento de aplicac~oes para celulares. Estas alternativas ser~ao chamadas de \plataformas de desenvolvimento" daqui por diante. Uma plataforma de desenvolvimento e um conjunto de: linguagem de programac~ao; API; ambiente de desenvolvimento; e ambiente de execuc~ao. Levando em conta estas caractersticas, e possvel fazer uma comparac~ao entre estas plataformas, mesmo que elas sejam sistemas operacionais, maquinas virtuais ou ambientes de execuc~ao, que possuem naturezas completamente diferentes. Ent~ao, neste captulo, ser~ao descritas cada uma das principais plataformas de desenvolvimento para dispositivos moveis, abordando as caractersticas citadas acima e realizando uma comparac~ao entre estas plataformas. 2.2 J2ME A primeira iniciativa no sentido de desenvolvimento de aplicac~oes para celulares foi Java 2 Micro Edition - J2ME, uma vers~ao do ambiente JAVA para dispositivos com limitac~oes de memoria e processamento, como celulares, PDAs e sistemas embarcados em geral. J2ME esta presente em quase todos os telefones GSM, que, de acordo com a Wireless Intelligence [INT06], possua cerca de 62% do mercado de telefones moveis em Junho de Para rodar nestes dispositivos, a linguagem precisaria ser bastante simplicada e otimizada, removendo os componentes que n~ao est~ao presentes ou n~ao s~ao utilizados. Sua arquitetura foi dividia em tr^es camadas: a maquina virtual propriamente dita; os pers; e as congurac~oes, como visto na Sec~ao

20 2.2 j2me 8 A maquina virtual de J2ME e a KVM - Kilobyte Virtual Machine. Ela e a base da arquitetura, devendo ser implementada para cada dispositivo. Na KVM e criada uma camada de software que abstrai o sistema operacional e garante a portabilidade. Sobre a maquina virtual s~ao denidas as congurac~oes, que s~ao um conjunto mnimo de classes que prov^eem as funcionalidades basicas para as categorias de dispositivos. Atualmente existem 2 congurac~oes: CLDC - Connected Limited Device Conguration, projetada para dispositivos com conex~oes de rede intermitentes, processadores mais lentos e memoria limitada, como os telefones celulares e alguns PDA's; CDC - Connected Device Conguration, congurac~ao para dispositivos com mais memoria e poder de processamento, e uma conex~ao com uma maior largura de banda. Um exemplo s~ao os set-top boxes, sistemas de telemetria de veculos e PDA's mais poderosos. Sobre a congurac~ao s~ao denidos os pers, API's de alto-nvel que disponibilizam um ambiente de execuc~ao completo e direcionado para os dispositivos alvo 1. O perl utilizado para telefones celulares e o MIDP - Mobile Information Device Prole. Este perl prov^e as principais funcionalidades requeridas pelas aplicac~oes para celulares, como interface com o usuario, conectividade, manipulac~ao de arquivos e gerenciamento da aplicac~ao em geral. Figura 2.1. Pers, congurac~oes e API's de J2ME Atualmente, os telefones celulares implementam a congurac~ao CLDC 1.1 e o perl MIDP 2.0. Este perl possui as seguintes funcionalidades implementadas: Interface com o usuario: a partir do pacote microedition.lcdui e possvel ter acesso a interface com o usuario, no caso a tela e o teclado do dispositivo. Este acesso pode ser feito tanto em alto nvel quanto em baixo nvel. O acesso a tela em 1 Entende-se por dispositivos alvo os dispositivos que implementam o determinado perl.

21 2.2 j2me 9 alto nvel constitui no uso de controles de telas prontos, como bot~oes, combo-boxes e caixas de texto. Ja o acesso em baixo nvel signica o desenho direto de primitivas gracas; Armazenamento persistente: atraves do microedition.rms e possvel armazenar registros da aplicac~ao de forma persistente; Rede: e possvel criar conex~oes via sockets ou com protocolos de mais alto nvel como HTTP atraves do pacote microedition.io; Media: J2ME possui uma API especca para tocar e controlar media de diversos formatos. Esta API esta disponvel no pacote microedition.media; Jogos: foi incorporado na vers~ao 2.0 do MIDP um pacote especco para o desenvolvimento de jogos chamado o microedition.lcdui.game. Este pacote possui classes responsaveis por tratar diversos problemas encontrados no desenvolvimento de aplicac~oes deste tipo. Alem das funcionalidades padr~ao includas no MIDP 2.0, varios fabricantes incluem API's especcas de acordo com a disponibilidade do hardware no dispositivo. Estas funcionalidades s~ao baseadas nas JSR's (Java Specication Request ) aprovadas pela SUN. Desta forma, o conjunto nal de API's suportadas por um dispositivo varia bastante, dependendo da quantidade de JSR's implementadas. Esta caracterstica prejudica um pouco a portabilidade das aplicac~oes em J2ME, pois a utilizac~ao de uma JSR pode implicar na diculdade de portar a aplicac~ao para um dispositivo que n~ao possua esta JSR implementada. O desenvolvimento de aplicac~oes em J2ME inicia-se com um WTK - Wireless Toolkit - que e um conjunto de ferramentas para o desenvolvimento nesta plataforma. Um WTK e composto pela implementac~ao da congurac~ao e do perl escolhido, bem como documentac~ao e ferramentas para simulac~ao de aplicac~oes. Este toolkit integra-se com o JDK - Java Development Kit - kit de desenvolvimento Java, que possui compiladores, maquina virtual para PC e todas as ferramentas necessarias para o desenvolvimento Java. O WTK padr~ao para desenvolvimento e o da SUN [WTK]. No entanto, cada fabricante de dispositivos termina por disponibilizar seu proprio WTK. Cada WTK proprietario e customizado para os telefones do fabricante especco, com as API's extras que os mesmos prov^eem e documentac~ao adicional, alem de ferramentas para comunicac~ao e depurac~ao no dispositivo. Alem do WTK, o desenvolvedor tambem pode utilizar IDE's para facilitar o desenvolvimento. A IDE mais utilizada para desenvolvimento em J2ME e o Eclipse [Ecla] com o plug-in EclipseME [Eclb]. Esta IDE integra os diversos WTK's com o ambiente desenvolvimento Eclipse, unicando todas as ferramentas e facilitando o desenvolvimento. As aplicac~oes em J2ME consistem em dois arquivos: JAD - Java Application Descriptor Arquivo que descreve a aplicac~ao java, contendo informac~oes como: quais as classes que v~ao ser executadas; nome e cone da aplicac~ao; permiss~oes que a aplicac~ao possui; tamanho em bytes; vers~oes de congurac~ao; e perl utilizados na aplicac~ao.

22 2.3 brew 10 JAR - Java Archive Arquivo compactado que possui todas as classes da aplicac~ao ja compiladas para bytecode, os arquivos de recursos (imagens, por exemplo) e um arquivo Manifest que descreve o conteudo do JAR. Estes arquivos devem ser instalados no telefone para que a aplicac~ao esteja disponvel para a execuc~ao. 2.3 BREW Seguindo o caminho de Java, a Qualcomm desenvolveu o BREW[QUA] - Binary Runtime Environment for Wireless (Ambiente de Execuc~ao Binario para Dispositivos Moveis). Neste ambiente, as aplicac~oes s~ao desenvolvidas em linguagem C ou C++, compiladas, e rodam em um chip separado do processador principal do dispositivo, o que possibilita uma performance melhor em relac~ao a J2ME. Alem de um ambiente de execuc~ao para rodar aplicac~oes, BREW possui um modelo de negocios muito bem estruturado, o qual esta representado na Figura 2.2[NAS03]. Figura 2.2. Modelo de negocios de BREW Este modelo de negocios esta baseado em um sistema de distribuic~ao de aplicac~oes, o BDS - BREW Distribution System, e consiste nos seguintes passos: i) O desenvolvedor cria suas aplicac~oes e passa por um processo de certicac~ao, o True BREW Test, que garante que a aplicac~ao esta dentro dos padr~oes de BREW e n~ao vai danicar o telefone nem prejudicar o usuario; ii) Uma vez certicada, a aplicac~ao passa a fazer parte do Virtual Maketplace, especie de \vitrine" na qual as operadoras buscam por aplicac~oes;

23 2.3 brew 11 iii) Ao ser escolhida pela operadora, a aplicac~ao passa a fazer parte do seu catalogo de aplicac~oes, o qual ca disponvel para o usuario, atraves de um menu no aparelho; iv) Quando o usuario compra a aplicac~ao atraves deste catalogo, a cobranca pela aplicac~ao e feita e distribuda entre a Qualcomm (8%), a operadora (12%) e o desenvolvedor (80%), dentro de um sistema de billing completamente integrado com o resto do BDS. Para o desenvolvedor, BREW oferece uma API para acesso as varias funcionalidades dos dispositivos. O uso desta API se da no acesso a interfaces (em vez de objetos), que possuem um conjunto de func~oes associadas para acessar suas funcionalidades. Estas interfaces possuem um identicador unico e implementam o padr~ao de projeto reference counting [MUL02] para gerenciar a alocac~ao e desalocac~ao de memoria. O desenvolvimento em BREW e feito em cima de um SDK - Software Development Kit - disponibilizado pela Qualcomm. Este SDK e composto por: um conjunto de headers que denem a API; as bibliotecas que implementam esta API para o simulador; o simulador propriamente dito; ferramentas para edic~ao dos arquivos de recursos, download e logging da aplicac~ao no telefone; e outras ferramentas para debug e automac~ao de testes. O SDK tambem conta com um plug-in que o integra no Microsoft Visual Studio, facilitando o desenvolvimento no simulador. No entanto, para executar a aplicac~ao no telefone e necessario um compilador para ARM. Alem disto, e preciso escrever os makeles e rodar este compilador em linha de comando. A vers~ao mais atual do SDK, quando foi escrito este trabalho, e a 3.1.5, de abril de Esta vers~ao suporta acesso a varios elementos do hardware do dispositivo: Acesso ao sistema: a interface IShell permite acesso as funcionalidades do sistema operacional, como gerenciamento do tempo de vida da aplicac~ao, manipulac~ao de eventos, uso de timers, criac~ao de dialogos, informac~oes do dispositivo, acesso ao arquivo de recursos, etc. Interface com o usuario: BREW disponibiliza as interfaces IDisplay e IDialog para acesso a tela do dispositivo. IDisplay fornece uma API de baixo nvel para desenho e manipulac~ao de primitivas gracas, enquanto IDialog possibilita a criac~ao de controles gracos pre-formatados, como bot~oes, caixas de texto e menus, atraves da interface IControl. Sistema de arquivos: BREW fornece pleno acesso ao sistema de arquivos do dispositivo atraves das interfaces IFileMgr e IFile. Rede: existe a possibilidade de criac~ao de conex~oes atraves de sockets TCP e UDP, bem como a utilizac~ao de protocolos de mais alto nvel como HTTP e HTTPS, usando INetMgr, ISocket e IWeb. Media: BREW disponibiliza a interface IMedia para gravar e reproduzir media (audio e vdeo) nos mais diferentes formatos de codicac~ao.

24 2.3 brew 12 Agenda: e possvel manipular contatos na agenda do dispositivo, atraves de IAddrBook e IAddrRec. Ligac~oes: a interface ICall oferece a possibilidade de efetuar chamadas telef^onicas atraves de BREW. Perifericos: todos os perifericos do telefone, como c^amera, bateria e rede wi, possuem interface associadas para a sua manipulac~ao. Uma aplicac~ao em BREW e formada por um conjunto de elementos: um arquivo MIF (Module Information File) que descreve as principais informac~oes da aplicac~ao, como nome da aplicac~ao, cone, nvel de acesso aos recursos do sistema operacional e outras classes e extens~oes utilizadas; o codigo-fonte da aplicac~ao, escrito em C/C++; e, opcionalmente, arquivos de recursos BAR (BREW Applet Resource), onde s~ao armazenados imagens, textos e denic~oes de dialogos usados na aplicac~ao. Figura 2.3. Desenvolvimento de uma aplicac~ao BREW BREW da suporte ao desenvolvimento de aplicac~oes de duas formas: procedural ou orientado a objeto. Utilizando uma abordagem procedural, e obrigatorio declarar uma func~ao para tratar os eventos gerados pelo ambiente e uma estrutura para conter as variaveis da aplicac~ao, ja que n~ao se pode trabalhar com variaveis globais. Ao inicializar a aplicac~ao, o ambiente de execuc~ao de BREW cria uma inst^ancia desta estrutura, registra a func~ao de tratamento de eventos e, opcionalmente, pode registrar uma func~ao para ser chamada quando a aplicac~ao for encerrada. Ja com a abordagem orientada a objeto, deve-se criar uma classe que herda atributos e metodos da estrutura AEEApplet. Por heranca, esta classe ira possuir, como atributos, ponteiros para as interfaces IShell, IDisplay e IModule que representam, respectivamente, a interface de acesso aos recursos do sistema, a interface de acesso a tela e a interface de acesso a outras aplicac~oes ou extens~oes utilizadas. Esta classe tambem deve

25 2.3 brew 13 ter metodos estaticos para inicializac~ao e nalizac~ao da aplicac~ao (alocac~ao e desalocac~ao dos objetos utilizados) e para tratar os eventos enviados a aplicac~ao, da mesma forma como temos estas func~oes na abordagem procedural. Vale salientar que o processo de execuc~ao e o mesmo para as duas abordagens. Desta forma, ao implementar os metodos de inicializac~ao e nalizac~ao da aplicac~ao, bem como o metodo de tratamento de eventos, tem-se toda implementac~ao necessaria para uma aplicac~ao BREW. Ent~ao, basta tratar os eventos desejados e escrever a logica da aplicac~ao para reagir a estes eventos. Abaixo segue exemplo do codigo inicial de uma aplicac~ao em BREW, onde temos: Func~ao de criac~ao da aplicac~ao: int AEEClsCreateInstance(AEECLSID ClsId,IShell * pishell, IModule * pmod,void ** ppobj) { *ppobj = NULL; if(aeeapplet_new( sizeof(helloworld), // HelloWorld struct ClsId, pishell, pmod, (IApplet**)ppObj, // HelloWorld handle event function (AEEHANDLER)HelloWorld_HandleEvent, NULL)) { return(aee_success); } } return (EFAILED); Func~ao de tratamento de eventos: static boolean HelloWorld_HandleEvent(AEEApplet * pme, AEEEvent ecode, uint16 wparam, uint32 dwparam) { AECHAR str[] = {'H','e','l','l','o',' ','B','R', 'E', 'W', '\0'}; switch (ecode) { case EVT_APP_START: //clear screen (default color is white)

26 2.3 brew 14 IDISPLAY_ClearScreen(pMe->m_pIDisplay); // draw string IDISPLAY_DrawText(pMe->m_pIDisplay, AEE_FONT_BOLD, str, -1, 0, 0, 0, IDF_ALIGN_CENTER IDF_ALIGN_MIDDLE); //update screen IDISPLAY_Update(pMe->m_pIDisplay); //we have successfully handled this message return(true); case EVT_APP_STOP: return(true); case EVT_KEY: // if any key is pressed, finishes app ISHELL_CloseApplet(pMe->m_pIShell, FALSE); return(true); } default: break; } return(false); A func~ao de criac~ao da aplicac~ao basicamente aloca memoria para a aplicac~ao ao chamar a func~ao utilitaria AEEApplet_New. Ela preenche a estrutura inicial da aplicac~ao AEEApplet com os ponteiros para as interfaces IShell, IModule e IDisplay. Uma vez inicializada com sucesso, a aplicac~ao esta apta a receber eventos que s~ao enviados para a func~ao tratadora de eventos da aplicac~ao, neste caso HelloWorld_HandleEvent. Os eventos EVT_APP_START e EVT_APP_STOP s~ao os eventos obrigatorios para toda aplicac~ao BREW e s~ao enviados quando a aplicac~ao e iniciada e nalizada, respectivamente. Neste exemplo, ao receber o evento EVT_APP_START, o texto \Hello BREW" sera impresso na tela do dispositivo. Ao ser pressionada qualquer tecla, o evento EVT_KEY e enviado para a func~ao HelloWorld_HandleEvent. O tratamento deste evento naliza a aplicac~ao ao chamar a func~ao ISHELL_CloseApplet().

27 2.4 symbian os SYMBIAN OS Estabelecida como uma empresa independente em 1998, Symbian surgiu como um consorcio formado pelas maiores empresas da industria de comunicac~ao sem o: Nokia, Panasonic, Motorola, Psion, Samsung Electronics, Siemens e Sony Ericsson. A intenc~ao destas empresas foi desenvolver um sistema operacional para dispositivos moveis que fosse aberto e padr~ao, a partir do sistema operacional EPOC. Devido a estas caractersticas, tornou-se possvel o desenvolvimento de aplicac~oes, por parte de terceiros, para os dispositivos que possussem este sistema operacional. Estas aplicac~oes s~ao desenvolvidas em codigo nativo, sendo executado pelo processador do dispositivo, diferentemente de J2ME e BREW. Atualmente, a Nokia comprou as ac~oes da Motorola e da Psion, tornando-se detentora de cerca de 70% das ac~oes, e, desta forma, estabelecendo as regras de evoluc~ao deste sistema operacional. Tambem e importante notar que, por ser um sistema operacional, o desenvolvimento de aplicac~oes para Symbian difere bastante de J2ME e BREW. Inclusive ja existe uma KVM que roda em cima de Symbian, possibilitando o desenvolvimento de aplicac~oes em J2ME para este sistema operacional. A API do Symbian OS fornece um framework de desenvolvimento de aplicac~oes. Desta forma, e necessario apenas herdar algumas classes reimplementado alguns metodos. Entretanto, para satisfazer as restric~oes do desenvolvimento para sistemas embarcados, deve-se implementar uma serie de praticas denidas como Symbian Coding Idioms [NOK02]. O sistema operacional Symbian permite o desenvolvimento de aplicac~oes em C++, as quais s~ao instaladas no dispositivo em forma de uma biblioteca de ligac~ao din^amica, ou DLL. Isto e necessario para que n~ao seja preciso reiniciar o dispositivo toda vez que uma aplicac~ao for instalada. Desta forma, as \aplicac~oes DLL" devem prover uma func~ao de acesso externo que serve justamente para instanciar a aplicac~ao, permitindo que a mesma seja executada. O Symbian OS pode ter varios tipos de interface graca com o usuario, as mais comuns s~ao a UIQ e a Series 60, discutidas a seguir: UIQ: interface para dispositivos que possuem uma tela com dimens~oes entre 4x6 cm a 6x8 cm e tela sensvel ao toque (touch screen). O Sony Ericsson P800 e um exemplo de dispositivo com esta interface. Maiores informac~oes podem ser encontradas em [UIQ]. Series 60 : de acordo com [NOKb], a plataforma Series 60 e um padr~ao de interface com o usuario criada pela Nokia, mas aberta a todos os dispositivos que utilizem o Symbian OS. E voltada para smartphones, que possuem uma tela de 176x220 Pixels. O Nokia 3650 e o Nokia N-Gage s~ao exemplos de telefones com esta interface. Estes dois modelos de interface com o usuario estendem de um mesmo framework de controle e interface com o usuario, o UIKON (User Interface and Control Framework ), que e a base do framework para desenvolvimento de aplicac~oes [NOK02] para o Symbian

28 2.4 symbian os 16 OS. Para cada tipo de interface com o usuario e criada uma extens~ao do UIKON: a plataforma Series 60 utiliza o AVKON, enquanto o UIQ utiliza o QIKON. Podemos encontrar maiores detalhes sobre as diferencas entre estas extens~oes e como fazer o porting de uma plataforma para a outra em [JOD02]. Para utilizar o framework de aplicac~oes Symbian, o desenvolvedor deve implementar as seguintes classes [NOK02]: Figura 2.4. Symbian Application Framework i) Classe da Aplicac~ao: o ponto de entrada do programa. Esta classe prov^e a inicializac~ao da aplicac~ao, sendo a primeira classe a ser instanciada pelo framework. Tambem e responsavel por instanciar a classe de documento. ii) Classe de Documento: responsavel por gerenciar a parte persistente (arquivos) da aplicac~ao. Atraves desta classe, e possvel denir ou associar quais os tipos de arquivos (extens~oes) s~ao suportados e gerenciados por uma determinada aplicac~ao. E importante notar que nem todas as aplicac~oes possuem documentos associados. No entanto esta classe deve existir, pois instancia a classe de interface com o usuario. iii) Classe de Interface com o Usuario (UI ): esta classe prov^e o gerenciamento da interface com o usuario, realizando o tratamento de eventos, tais como: pressionamento de teclas; posicionamento do ponteiro (no caso de touch screens); abertura/fechamento de arquivos; entre outros. Tambem e responsavel pela criac~ao da(s) classe(s) de visualizac~ao. iv) Classe de Visualizac~ao (View): esta classe representa tudo o que esta sendo mostrado na tela, recebendo da classe de UI os comandos para desenhar e atualizala. E importante salientar que uma aplicac~ao pode ter varias views, sendo a classe de UI responsavel por gerencia-las e denir qual view estara ativa.

29 2.5 windows mobile 17 v) Motor ou nucleo da aplicac~ao (ApplicationEngine): esta classe, implementada pelo desenvolvedor, e o que contem toda a logica da aplicac~ao, implementa seus algoritmos e prov^e os pontos de acesso para a classe de UI. As classes de aplicac~ao, documento, UI e view que devem ser desenvolvidas, herdam de classes correspondentes do UIKON (ou de uma de suas extens~oes: AVKON para Series 60 e QIKON para UIQ) e possuem as suas funcionalidades basicas implementadas. Entretanto a classe nucleo da aplicac~ao (ApplicationEngine) n~ao possui correspondente no UIKON, devendo ser criada pelo desenvolvedor. Tambem e importante salientar que o Symbian OS n~ao implementa a linguagem C++ padr~ao, n~ao fornecendo suporte a alguns recursos da linguagem tais como: a STL - Standard Template Library (Biblioteca de classes template padr~ao); e RTTI - Run-Time Type Information (Informac~ao de tipos em tempo de execuc~ao). Para desenvolver aplicac~oes para o Symbian OS e necessario o SDK da vers~ao do sistema operacional correspondente. Para Symbian, alem da divis~ao de interfaces gracas entre UIQ e Series 60, cada uma destas interfaces possui diferentes vers~oes. A vers~ao mais atual da Series 60 e a 3rd Edition Feature Pack 3. A terceira edic~ao do Symbian OS e baseada na Interface Binaria para Aplicac~oes (ABI - Application Binary Interface) para a arquitetura ARM. A ABI e uma padr~ao desenvolvido pela propria ARM que determina como os arquivos executaveis e as bibliotecas ir~ao funcionar juntos. Isto signica que e necessario utilizar outros compiladores para gerar codigo binario para o Symbian OS terceira edic~ao, e este binario n~ao e mais compatvel com os binarios das vers~oes anteriores. O desenvolvimento de aplicac~oes para o Symbian OS tambem utiliza um SDK, que contem: os arquivos de cabecalho com a denic~ao da API e o simulador; um compilador para ARM, para gerar codigo binario que possa ser executado no dispositivo; e um IDE para edic~ao e facilidade de desenvolvimento do codigo fonte. A Nokia lancou, no nal de 2005, um conjunto de IDE's baseados no Eclipse chamado carbide.c++. O carbide.c++ passou ent~ao a ser o ambiente de desenvolvimento ocial do Symbian OS para a Nokia e integra todas as ferramentas e SDK's em uma unica aplicac~ao. Este ambiente possui as vers~oes Express, disponvel sem custo e que oferece as operac~oes basicas de desenvolvimento; Developer, que adiciona as funcionalidades de debug no dispositivo e design de interface; Professional, que possui ferramentas para analise de performance das aplicac~oes; e OEM, com ferramentas para criac~ao de telefones incluindo suporte a ROM e JTAG WINDOWS MOBILE Criado em 1996 pela Microsoft, o sistema operacional Windows CE serve de base para todas as vers~oes do windows para dispositivos moveis. Este sistema operacional e uma vers~ao reduzida do Windows para desktops, contendo as principais funcionalidades da 2 Joint Test Action Group - JTAG. Padr~ao IEEE que dene uma arquitetura para testes em placas de circuito impresso que usa boundary scan. Este metodo permite o teste das interconex~oes e sinais de um circuito atraves da programac~ao de celulas de teste.

30 2.6 embedded linux 18 API WIN32. A base do Windows CE e o que dene a vers~ao encontrada nos dispositivos atuais: o Windows Mobile. Assim como o Symbian OS, o Windows Mobile possui vers~oes diferentes de interface com o usuario: Windows Mobile Professional: com tela sensvel ao toque, sem teclado e resoluc~ao a partir de 240x320 pixels; Windows Mobile Standard: vers~ao do Windows para hardwares com teclado de telefone, telas de menor resoluc~ao (a partir de 176x220) e sem ser sensveis a toque. Antes das vers~oes atuais, existiram o Windows Mobile 2003 Second Edition, Windows Mobile 2003, Pocket PC 2002, Smartphone 2002, e Pocket PC Todas estas vers~oes eram baseadas em vers~oes anteriores do Windows CE. O desenvolvimento de aplicac~oes para o Windows Mobile pode ser feito de duas formas: utlizando a API nativa do sistema operacional ou escrevendo codigo para rodar no Microsoft.NET Compact Framework, vers~ao mobile do.net para desktops. O ambiente de desenvolvimento do Windows Mobile e composto pelo SDK da vers~ao correspondente, que contem todos os arquivos de cabecalho da API e os simuladores; e do Microsoft Visual Studio, IDE que possui completa integrac~ao com o SDK e com os compiladores da Microsoft utilizados para gerar codigo binario para o simulador e para o dispositivo. Para todas as outras plataformas apresentadas neste captulo, foi descrito o desenvolvimento e o codigo de uma aplicac~ao basica nesta plataforma. O Windows Mobile n~ao fez parte do escopo de implementac~ao deste trabalho, como pode ser visto na Sec~ao 3.2. Desta forma, n~ao sera apresentada a forma de desenvolvimento de aplicac~oes. O desenvolvimento de aplicac~oes baseadas em janelas e igual ao do Windows para desktops e maiores detalhes podem ser encotrados em [MICa] [MICb] [MICc]. 2.6 EMBEDDED LINUX O Embedded Linux e um sistema operacional para sistemas embarcados baseado no Linux. Nesta vers~ao do Linux, o seu nucleo foi modicado para suportar algumas funcionalidades presentes nos dispositivos embarcados. Assim como o Linux para desktops, o Embedded Linux possui varias distribuic~oes ativas. Basicamente, a diferenca entre estas distribuic~oes s~ao o conjunto de funcionalidades disponveis na vers~ao basica e o conjunto de hardware suportado. Na pratica, cada fabricante de hardware adota uma das distribuic~oes comerciais e customiza essa distribuic~ao para o seu dispositivo. Atualmente existem diversos grupos com intenc~ao de padronizar o conjunto de funcionalidades que deve estar presente nas distribuic~oes Linux para sistemas embarcados. Entre estes grupos, est~ao includos: CE Linux Forum, o Linux Foundation, Linux Phone Standards Forum, LiMo Foundation, Embedded Linux Consortium e o OpenMoko. O desenvolvimento de aplicac~oes para embedded linux segue exatamente o mesmo modelo do desenvolvimento de aplicac~oes para o linux do PC. No entanto, como a maioria das distibuic~oes Embedded Linux n~ao possui console e nem os telefones celulares

31 2.6 embedded linux 19 possuem interface adequada para rodar aplicac~oes em linha de comando, as distribuic~oes Embedded Linux possuem implementac~oes dos principais frameworks gracos existentes para Linux, Qt e GTK. Assim, implementar uma aplicac~ao Embedded Linux e basicamente, seguir um dos padr~oes de frameworks gracos existentes: Qt ou GTK. N~ao existe um ambiente de desenvolvimento unico ou padr~ao para Embedded Linux. Basicamente e necessario um editor de textos, como o pico, nano ou xemacs, e a compilac~ao e feita em linha de comando, usando o GCC ou outro compilador para ARM. E possvel tambem congurar o Eclipse com o plug-in CDT para desenvolver para esta plataforma. Existem alguns simuladores para ARM que podem ser usados para rodar a aplicac~ao antes de instalar no hardware nal. No entanto, estes simuladores devem possuir o mesmo ambiente graco que a distribuic~ao escolhida, e esta congurac~ao geralmente ca a cargo do desenvolvedor. Na pratica, apenas as plataformas com SDK bem denido, como o Maemo da Nokia ou o Qtopia da Trolltech possuem simuladores que n~ao demandam instalac~ao e congurac~oes avancadas do desenvolvedor. O Embedded Linux disponibiliza API's para acesso a todos os recursos do hardware existentes no dispositivo: Acesso ao sistema operacional: todas as chamadas do sistema operacional, como timers, threads e as outras func~oes padr~ao da libc e posix est~ao presentes. Interface Graca: acesso ao sistema de janelas e a criac~ao dos elementos gracos basicos e fornecida atraves do Qt. Acesso a rede: a API de sockets padr~ao do Linux pode ser utilizada para criar conex~oes de rede. Sistema de arquivos: o sistema de arquivos e acessado atraves das API's padr~ao do Linux. Dispositivos de entrada e sada: todos os recursos de entrada e sada de dados no Linux s~ao mapeados no sistema de arquivos como \arquivos de stream" e podem ser acessados atraves da API padr~ao. Nestes dispositivos est~ao includos a parte de audio; conex~ao serial; conex~ao USB; e Bluetooth. E importante salientar que, de acordo com o hardware do dispositivo e com a distribuic~ao do Linux utilizada, outras API's e recursos podem estar presentes e disponveis na API. A seguir, ser~ao apresentados os dois principais frameworks gracos disponveis para Embedded Linux Qt O framework graco Qt 3 foi desenvolvido pela Trolltech [TRO] em Sua proposta era ser um sistema graco, orientado a objetos e multi-plataforma, funcionando 3 Pronuncia-se \cute" em ingl^es, e signica bonito ou gracioso.

32 2.6 embedded linux 20 inicialmente em Windows e Linux. Em 1997, este framework foi adotado para ser a base do KDE [GNUf] tornando-se, de fato, um padr~ao para desenvolvimento graco em linux. Em 2000, a Trolltech lancou o Qtopia Core, base do Qt para dispositivos moveis. O Qtopia Core passou ent~ao a ser o padr~ao graco para Linux em telefones celulares e PDA's. Recentemente a Trolltech lancou o Greenphone[TRO04], implementac~ao de refer^encia do Qtopia para telefones celulares. Atualmente, a Motorola, Nokia, Panasonic, NEC e outros est~ao adotando o Embedded Linux como uma alternativa de plataforma de software para seus telefones celulares, o que nos leva a vislumbrar um crescimento desta plataforma nos proximos anos. O desenvolvimento de aplicac~oes em Qt segue um modelo de conex~oes, com elementos chamados \slots" e \signals". Podemos considerar os \signals" como eventos e os \slots" como os tratadores destes eventos. Ao conectarmos os eventos a estas func~oes tratadoras de eventos, as func~oes s~ao automaticamente chamadas quando os eventos s~ao disparados. Estas func~oes s~ao chamadas func~oes de callback. Uma aplicac~ao Qt e composta por um objeto da classe Qapplication e um ou varios \Widgets", que s~ao elementos gracos basicos, que podem ser compostos para formar novos elementos. Estes elementos emitem os sinais (eventos) para a nossa aplicac~ao, que deve implementar \slots" para tratar estes sinais. Esta arquitetura simples fornece a base para a implementac~ao de aplicac~oes em Qt. A portabilidade do Qt e atingida ao portar os \Widgets" para as plataformas desejadas. No entanto, o Qt tambem n~ao fornece nenhuma estrutura para implementar aplicac~oes como maquina de estados. Na Figura 2.5 temos o diagrama de classes dos principais widgets de Qt. QObject e a base da estrutura de classes. Desta classe, herdam as 3 classes principais do framework : i) QApplication: representa a aplicac~ao propriamente dita, possuindo metodos para criar e executar uma aplicac~ao Qt. ii) QWidget: classe base para um componente de tela. Este componente pode ser uma janela, um bot~ao ou qualquer controle de interface com o usuario, que s~ao representados por classes que derivam de QWidget. iii) QLayout: funciona como um agrupador de widgets. Dene como os widgets ser~ao visualizados e dispostos na tela. Abaixo temos a implementac~ao de uma aplicac~ao simples em Qt. #include <QApplication> #include <QLabel> #include <QPushButton> #include <QVBoxLayout> int main(int argc, char *argv[]) { // Creating application QApplication app(argc, argv);

33 2.6 embedded linux 21 Figura 2.5. Diagrama de classes de Qt // creating basic widgets (label and pushbutton) QLabel *label = new QLabel("Hello Qt!"); QPushButton *button = new QPushButton("Quit"); // connecting clicked() signal to app->quit() slot QObject::connect(button, SIGNAL(clicked()), &app, SLOT(quit())); // creating window QWidget *window = new QWidget; window->setwindowtitle("hello Qt!"); // creating a vertical layout to hold // the label and the button QVBoxLayout *layout = new QVBoxLayout; layout->addwidget(label); layout->addwidget(button);

34 2.6 embedded linux 22 // set layout to window window->setlayout(layout); // display it window->show(); } // execute application return app.exec(); Esta aplicac~ao cria dois widgets, uma string \Hello Qt!" e um bot~ao \Quit". Estes widgets s~ao alinhados verticalmente e dispostos num terceiro widget, chamado window, que representa a janela da aplicac~ao. Esta janela ent~ao e requisitada para ser exibida na tela. Desta forma, quando nossa aplicac~ao e executada ao chamar app.exec();, a janela e seus widgets s~ao exibidos GTK GTK+ (The Gimp Toolkit)[GNUe] e uma biblioteca para a criac~ao de interfaces gracas, assim como Qt. E chamada de Gimp Tool Kit pois foi escrita para desenvolver o GIMP (GNU Image Manipulation Program ), programa de manipulac~ao de imagens da GNU. Esta biblioteca foi construda baseada no GDK (Gimp Drawing Kit) que e basicamente um wrapper para as func~oes gracas de baixo nvel do sistema de janelas X [XFR] e para o gdk-pixbuf que e uma biblioteca para manipulac~ao de imagens em baixo nvel. Atualmente, o GTK+ esta em sua vers~ao 2 e e a base para o Gnome (GNU Network Object Model Environment )[GNUa] ambiente graco desktop para sistemas UNIX. GTK+ e escrita em C e possui licensa LGPL. No entanto existem diversos bindings de GTK para outras linguagens, como C++, C#, Objective C, Python, Perl, Free Pascal, Java e Eiel. Em dispositvos moveis, o GTK+ e usado como base de ambientes como o GPE Palmtop[GPE] e o Maemo[NOKa]. Aplicac~oes em GTK+ tambem possuem o conceito de tratamento de eventos (sinais) atraves de func~oes de callback. A aplicac~ao e construda ao criarmos widgets e conectarmos os eventos recebidos por estes widgets com as devidas func~oes de tratamento de eventos, de maneira analoga ao Qt. Abaixo temos a implementac~ao de uma aplicac~ao simples em GTK+. #include <gtk/gtk.h> int main( int argc, char *argv[] ) { /* GtkWidget is the storage type for widgets */ GtkWidget *window; /* This is called in all GTK applications.

35 2.7 comparando plataformas 23 * Arguments are parsed from the command line * and are returned to the application. */ gtk_init (&argc, &argv); /* create a new window */ window = gtk_window_new (); /* Connect signal to X in the upper corner */ g_signal_connect(g_object(window), "delete_event", G_CALLBACK(gtk_main_quit), NULL); /* Add example label to window */ gtk_container_add(gtk_container(window), GTK_WIDGET(gtk_label_new("Hello World!"))); /* and the window */ gtk_widget_show (window); /* All GTK applications must have a gtk_main(). * Control ends here and waits for an event * to occur (like a key press or mouse event). */ gtk_main (); } return 0; Esta aplicac~ao cria dois widgets, uma janela e um label (string de texto). No incio, e chamada a func~ao gtk_init() para inicializar o sistema graco. Depois, a janela e criada e o sinal delete_event e conectado a func~ao de callback gtk_main_quit. Este sinal e enviado ao pressionar o bot~ao "X" que fecha a janela. A func~ao gtk_main_quit encerra o loop de execuc~ao da func~ao gtk_main e encerra o programa. Ent~ao, o widget contendo o texto "Hello World!" e adicionado a janela e ela e exibida atraves da chamada a func~ao gtk_widget_show. Por m, gtk_main e chamada para que a aplicac~ao entre num laco a espera de eventos. 2.7 COMPARANDO PLATAFORMAS O documento J2ME & Symbian OS: A Platform Comparison [NOK03] faz uma comparac~ao entre o Symbian OS e J2ME. Apesar de serem esferas diferentes, pois J2ME e executada em uma maquia virtual que roda sobre um sistema operacional e Symbian e um sistema operacional, esta comparac~ao foi feita sob o ponto de vista do desenvolvedor, visando vericar o que cada plataforma oferece para o desenvolvimento de aplicac~oes. O trabalho \Analise de tecnologias de desenvolvimento de jogos para dispositivos moveis" [BKNR03] tambem realiza comparac~oes e acrescenta informac~oes sobre o desenvovimento em BREW. Desta forma, foi possvel acrescentar as plataformas Windows

36 2.7 comparando plataformas 24 Mobile e Embedded Linux a estas comparac~oes. O resultado pode ser visto na Tabela 2.1.

37 2.7 comparando plataformas 25 Tamanho permitido para as aplicac~oes Penetrac~ao Mercado no Instalac~ao por download pela rede telef^onica Executa como codigo-nativo Linguagem de programac~ao principal Alguns bytes pende mem. telefone) Outras linguagens de programac~ao Comunicac~ao por sockets J2ME BREW Symbian OS Atualmente permite alguns kilo bytes Grande e em crescimento kilo (de- da do Grande nos Estados Unidos e em crescimento Alguns mega bytes Medio e em crescimento Sim Sim Possvel, mas evitado por causa do tamanho das aplicac~oes Embedded Linux Alguns mega bytes Pequeno e em crescimento N~ao N~ao Sim Sim Sim Sim Windows Mobile Alguns mega bytes Pequeno e em crescimento Possvel, mas evitado por causa do tamanho das aplicac~oes Java C C++ C e C++ C e C++ Nenhuma C++ e Java Java e Python Java, Python, Perl e outras Sim Sim Sim Sim Sim Em alguns aparelhos N~ao Sim Sim Sim Animac~ao 2D Sim Sim Sim Sim Sim Animac~ao 3D Em alguns aparelhos Sim Sim N~ao N~ao Exibe Vdeos Sim Sim Sim Sim Sim Suporte a MIDI e WAV Acesso a SMS Em alguns aparelhos Acesso a agenda e calendario do aparelho Conex~ao via Infravermelho ou Bluetooth Efetua chamadas telef^onicas Sim Sim Sim Sim Sim Em alguns aparelhos Sim Sim Sim Sim Sim Sim Sim Sim Sim Sim Sim Sim Sim Tabela 2.1. Comparac~ao entre as plataformas Java, C# e VB.NET

38 - CAP ITULO 3 CMF - METODOLOGIA, REQUISITOS E ARQUITETURA Neste captulo sera apresentada a metodologia utilizada para o desenvolvimento do CMF. Tambem ser~ao denidos os principais requisitos funcionais e n~ao-funcionais do Framework. Alem disto, sera apresentada a arquitetura denida para o CMF, levando em conta todas as semelhancas e diferencas das diversas plataformas de desenvolvimento de aplicac~oes para dispositivos moveis. 3.1 INTRODUC ~AO Conforme visto no Captulo 2, as diversas plataformas de desenvolvimento para dispositivos moveis possuem uma grande semelhanca: todas s~ao dirigidas a eventos. Isto signica que estas plataformas prove^em alguma forma de receber eventos do dispositivo e envia-los para a aplicac~ao, geralmente atraves da chamada a um metodo ou func~ao tratadora de eventos. A partir desta analise apresentada no Captulo 2 sobre as diferentes plataformas, tracamos uma metodologia para o desenvolvimento do Framework, que sera detalhada a seguir. 3.2 METODOLOGIA A implementac~ao do CMF foi realizada seguindo duas abordagens: Bottom-Up Algumas aplicac~oes foram desenvolvidas nas plataformas apresentadas no Captulo 2. A partir do desenvolvimento destas aplicac~oes, torna-se possvel conhecer cada uma das plataformas e como ocorre a interac~ao entre a plataforma e a aplicac~ao. Alem disto, podemos identicar as semelhancas e diferencas entre elas. Top-Down E formulada uma vis~ao global do Framework sem detalhamento de seus componentes internos. Esta macro-arquitetura e ent~ao detalhada para cada componente do Framework, ate atingir um nvel de detalhe que valide o modelo e seja possvel sua implementac~ao. A utilizac~ao das duas abordagens em conjunto tem como principal objetivo gerar um equilbrio que evita os problemas inerentes a cada uma delas. A abordagem bottomup evita que seja construdo um framework generico demais (problema causado pela 26

39 3.2 metodologia 27 utilizac~ao da abordagem top-down). Enquanto a abordagem top-down evita que o framework termine por car bastante especializado no tipo de aplicac~ao que e utilizado na sua construc~ao (problema inerente a abordagem bottom-up). Considerando estas duas abordagens, foi tracado um plano de desenvolvimento para a construc~ao do CMF. O escopo denido neste plano contempla o desenvolvimento de aplicac~oes nas cinco plataformas apresentadas anteriormente: Symbian, BREW, J2ME, Windows Mobile e Embedded Linux. Estas aplicac~oes foram desenvolvidas de acordo com a demanda de clientes do C.E.S.A.R. Na plataforma Symbian, foram implementados dois jogos. Para BREW, foram implementadas uma aplicac~ao de sincronizac~ao de informac~oes pessoais e um cliente do VNC (Virtual Network Computing ), esta ultima sendo portada para Embedded Linux. Para Windows Mobile, desenvolvemos uma aplicac~ao de captura e identicac~ao de audio. Por m, em J2ME, foram desenvolvidas aplicac~oes de compartilhamento de imagens e execuc~ao de apresentac~oes tipo slide-show. O objetivo principal da execuc~ao deste plano foi entender o funcionamento de cada uma das plataformas, conhecer as formas 1 e ambientes de desenvolvimento e tentar identicar os pontos em comum entre elas. De acordo com esta experi^encia de desenvolvimento de aplicac~oes nas varias plataformas, foram denidos quais os criterios relevantes para a escolha das plataformas iniciais do Framework. As plataformas foram ent~ao ordenadas dentro de cada criterio e, dentro desta ordem, receberam pontos de acordo com a sua relev^ancia e suas caractersticas. Este processo de decis~ao formal ira indicar as plataformas com maior pontuac~ao dentro dos critarios denidos. A partir desta indicac~ao, ser~ao denidas quais as duas plataformas que ir~ao formar o escopo inicial de implementac~ao do CMF. Abaixo listaremos os criterios denidos, junto com a explanac~ao da sua import^ancia e a escala de pontuac~ao de cada um. A adoc~ao de um peso em cada criterio visa denir a import^ancia do criterio em relac~ao aos outros. Numero de dispositivos Devem ser priorizadas as plataformas com o maior numero de dispositivos no mercado, para que o CMF tenha a maior abrang^encia possvel. Este criterio sera pontuado em escala de 1 a 5 com peso 2. Facilidade de desenvolvimento As plataformas com uma maior facilidade de desenvolvimento de aplicac~oes devem ser priorizadas, pois tendem a ser mais adotadas pelos desenvolvedores. Este criterio sera pontuado em escala de 1 a 5 com peso 1. Linguagem de programac~ao C/C++ A linguagem de programac~ao das plataformas devera ser igual, na vers~ao inicial do Framework. Isto reduz esforco e riscos com a realizac~ao de transformac~ao automatica entre linguagens (que n~ao esta no escopo deste trabalho). Devido a 1 Entende-se por formas de desenvolvimento as linguagens de programac~ao e API's utilizadas, mecanismos de comunicac~ao entre a aplicac~ao e a plataforma e as formas de acesso aos recursos do hardware.

40 3.2 metodologia 28 exist^encia de apenas uma plataforma que utilize linguagem Java, a linguagem de programac~ao do CMF sera inicialmente C ou C++. Portanto, este criterio sera pontuado da seguinte forma: 5 - para plataformas com suporte a linguagem C ou C++; 0 - para as outras. Este criterio tem peso 1. Portabilidade A plataforma deve prover compatibilidade com vers~oes anteriores, alem de mecanismos para reduzir o esforco de porting de aplicac~oes entre dispositivos com interface (tela e teclado) diferente. Isto e necessario para que o CMF possa evoluir junto com a plataforma alvo 2 e seja compatvel entre os dispositivos da mesma plataforma, sem a necessidade de reescrita do Framework a cada evoluc~ao da vers~ao da platafroma escolhida ou a cada novo dispositivo suportado. Este criterio possui grande import^ancia e sera pontuado em escala de 1 a 5, com peso 3. Desempenho As plataformas devem ser priorizadas de acordo com seu desempenho. O desempenho inclui n~ao somente numero de instruc~oes por segundo, mas tambem a quantidade de memoria disponvel e o tamanho maximo permitido para uma aplicac~ao. Isto permite uma maior exibilidade no desenvolvimento de aplicac~oes para a plataforma. Este criterio sera pontuado de 1 a 5 com peso 2. Acesso aos recursos do hardware A quantidade de recursos do hardware que podem ser acessados pela plataforma dene a ordem de prioridade deste criterio. Este criterio dene a abrang^encia inicial do Framework. Como o CMF sera desenvolvido para varias plataformas, o conjunto de recursos suportados pelo Framework devera ser o denominador comum entre as plataformas alvo. Este criterio sera pontuado de 1 a 5 com peso 2. A Tabela 3.1 mostra o enquadramento das plataformas de desenvolvimento em cada um dos criterios citados acima. Este enquadramento foi obtido atraves da implementac~ao das aplicac~oes conforme o plano de desenvolvimento do CMF e do estudo inicial de desenvolvimento de aplicac~oes para cada uma das plataformas abordadas conforme visto no Captulo 2. As pontuac~oes de cada plataforma nos criterios estabelecidos foram somadas e este resultado pode ser visto na Tabela 3.2. A partir deste resultado, pode-se perceber que Symbian foi apontada como a plataforma mais indicada. No entanto, a partir da experi^encia de desenvolvimento de aplicac~oes nesta plataforma, foi possvel perceber que Symbian possui diversos pontos de diverg^encia entre as outras plataformas. Os dois principais pontos s~ao: Padr~ao Two Phase Constructor [Sym02] O desenvolvimento de aplicac~oes em Symbian segue o padr~ao Two Phase Constructor. De acordo com este padr~ao, a alocac~ao din^amica de memoria n~ao deve 2 Entende-se por plataforma alvo cada uma das plataformas de desenvolvimento de aplicac~oes para dispositivos moveis consideradas para o desenvolvimento do Framework.

41 3.2 metodologia 29 Criterios Prioridade das plataformas (Pontuac~ao) Numero de dispositivos Facilidade de desenvolvimento Linguagem de programac~ao C e C++ Portabilidade Desempenho Acesso aos recursos do hardware Tabela 3.1. Criterios para escolha das plataformas ser realizada dentro dos contrutores dos objetos. Em vez disto, deve-se ter um metodo estatico new que e responsavel por construir o objeto em duas fases: alocar memoria para o objeto propriamente dito, chamando o seu construtor e colocando este objeto dentro de uma estrutura de gerenciamento de memoria chamada Cleanup Stack; e depois, chamar o metodo ConstructL que e responsavel por alocar a memoria din^amica para os atributos do objeto. Isto se faz necessario para evitar vazamento de memoria (memory leak ), pois, caso n~ao exista memoria suciente para alocac~ao dos atributos do objeto, a Cleanup Stack e responsavel por desalocar o objeto e todos os seus atributos previamente alocados. Arquitetura cliente-servidor[nok02] Todos os servicos relativos ao sistema operacional s~ao implementados seguindo uma arquitetura cliente-servidor. Nesta arquitetura, os servidores gerenciam os recursos para diversos clientes. Desta forma, as aplicac~oes que desejam acessar recursos do hardware devem fazer requisic~oes aos servidores destes recursos. Estes servidores entregam os servicos requisitados atraves de classes-cliente que tratam estes servicos. Portanto, para compatibilizar Symbian com outras plataformas, deve-se implementar nestas outras plataformas todos estes mecanismos deste sistema operacional. Isto implica em fazer um framework que implemente o framework de aplicac~oes Symbian em cada uma das plataformas. Comecamos a desenvolver o CMF em Symbian, no entanto, devido aos motivos apresentados anteriormente, foi decidido que Symbian n~ao faria parte do escopo inicial do CMF. Assim, as duas plataformas selecionadas foram as que obtiveram maior pontuac~ao

42 3.2 metodologia 30 Plataforma Pontuac~ao Tabela 3.2. Pontuac~ao das plataformas de acordo com os criterios depois de Symbian, segundo os criterios utilizados: BREW e Embedded Linux. Este resultado esta ilustrado na Tabela 3.2. Depois de denidas as plataformas, foi escolhida a vers~ao da plataforma a ser utilizada. Para BREW, temos basicamente uma evoluc~ao da mesma plataforma entre as diferentes vers~oes. Ent~ao foi denido que o CMF seria implementado na vers~ao mais nova disponvel no momento de incio da implementac~ao, o BREW Para o Embedded Linux, temos diversas distribuic~oes, da mesma forma que temos varias distribuic~oes para PC's. Assim, foi escolhida a distribuic~ao disponibilizada pela MontaVista, que utiliza o Qtopia como framework graco, pois posuamos acesso a esta distribuic~ao e a todo o ambiente de desenvolvimento. Depois de escolhidas as plataformas de desenvolvimento e suas vers~oes, planejamos os seguintes passos: i) Elicitac~ao dos requisitos Levantar os requisitos funcionais e n~ao-funcionais necessarios ao Framework. ii) Denic~ao da arquitetura Denir uma arquitetura inicial para o CMF, levando em considerac~ao a estrutura de desenvolvimento de aplicac~oes nas diversas plataformas. iii) Implementac~ao do Framework em BREW Implementar o CMF em BREW para validac~ao da arquitetura. iv) Implementac~ao de uma aplicac~ao de testes Em paralelo a implementac~ao do Framework e necessario implementar uma aplicac~ao para usar e rodar o CMF. Esta aplicac~ao tambem deve ser responsavel por testar cada um dos modulos implementados. v) Correc~oes na arquitetura De acordo com o uso do CMF para implementac~ao da aplicac~oes de testes, ajustes na arquitetura proposta devem ser feitos.

43 3.3 requisitos funcionais 31 vi) Porting do Framework para Embedded Linux Uma vez implementado e testado em BREW, o CMF deve ser portado para a segunda plataforma alvo. vii) Execuc~ao da aplicac~ao de testes em Embedded Linux Dever~ao ser avaliados os esforcos para portar a aplicac~ao de testes para Embedded Linux. Esta aplicac~ao idealmente devera rodar na vers~ao de Embedded Linux do CMF com o menor numero de alterac~oes possvel. viii) Implementac~ao de aplicac~oes para validac~ao da proposta Dever~ao ser implementadas duas aplicac~oes utilizando o CMF para que seja possvel coletar dados deste desenvolvimento. Os dados de desenvolvimento incluem numero de linhas de codigo, tamanho do arquivo binario da aplicac~ao, tempo de desenvolvimento e tempo de execuc~ao. ix) Analise dos resultados Metricas de esforco e numero de linhas de codigo devem ser analisadas para aplicac~oes desenvolvidas com e sem o Framework. Esta comparac~ao tem por objetivo medir e analisar a efetividade do CMF. Nas duas sec~oes a seguir, ser~ao detalhados requisitos elicitados para o CMF. Classicamos estes requisitos seguindo a abordagem denida por Sommerville[SOM04], na qual os requisitos funcionais s~ao denidos como aqueles que \descrevem o que o sistema deve fazer", enquanto todos os outros requisitos s~ao considerados n~ao-funcionais. 3.3 REQUISITOS FUNCIONAIS Os requisitos funcionais do CMF foram elicitados a partir das necessidades basicas do desenvolvedor ao implementar aplicac~oes para dispositivos moveis. Foram realizadas entrevistas com desenvolvedores de aplicac~oes para estas plataformas e este resultado foi consolidado no conjunto de requisitos descritos a seguir [RF001] - Ponto de entrada da aplicac~ao E necessario que o Framework possua uma classe base que represente a aplicac~ao. Esta classe sera responsavel por receber os eventos de START, STOP, PAUSE e RESUME. Ao receber estes eventos, o metodo abstrato correspondente deve ser chamado. O desenvolvedor devera construir sua aplicac~ao herdando desta classe e implementando os metodos abstratos [RF002] - Acesso a tela O Framework devera disponibilizar uma classe que representa a tela do dispositivo. Esta classe devera prover metodos para desenho de texto e imagens na tela.

44 3.3 requisitos funcionais [RF003] - Gerenciamento de telas O Framework devera prover um mecanismo para o gerenciamento das telas da aplicac~ao. Este gerenciamento inclui a troca da tela ativa e o empilhamento das telas apresentadas para que seja possvel voltar para a tela anterior [RF004] - Gerenciamento de telas - Classe base Todas as telas da aplicac~ao dever~ao herdar de uma classe base que denira os metodos que dever~ao ser implementados por todas as telas para o gerenciamento de telas do Framework [RF005] - Gerenciamento de telas - Traduc~ao de eventos Eventos de tecla enviados para a aplicac~ao tambem dever~ao ser tratados pelo gerenciador de telas[rf003]. Este gerenciador ira enviar o evento para ser traduzido pela tela atual, de acordo com o que estiver sendo exibido no momento [RF006] - Maquina de estados A aplicac~ao desenvolvida no Framework devera ser modelada como uma maquina de estados. O Framework devera prover uma classe que represente e controle esta maquina de estados [RF007] - Maquina de estados - Classe base para estados O Framework devera disponibilizar uma classe base para os estados da aplicac~ao. Esta classe deve possuir os metodos que ser~ao chamados ao entrar e sair do estado, bem como denir o mecanismo de tratameto dos eventos pelo estado [RF008] - Maquina de estados - Despacho de eventos A classe disponibilizada no requisito [RF006] sera responsavel por receber eventos enviados a aplicac~ao e envia-los para o estado corrente [RF009] - Maquina de estados - Comunicac~ao entre os servicos Todos os servicos oferecidos pelo Framework, que funcionem de forma assncrona, tais como timers, conex~ao de rede, etc, dever~ao se comunicar 3 com a aplicac~ao atraves do envio de eventos [RF010] - Acesso as informac~oes do sistema O CMF devera prover uma classe que represente a plataforma alvo e forneca metodos de acesso as suas informac~oes, como: data e hora atual; enviar eventos para o sistema; 3 Entende-se por comunicar o envio e recebimento das requisic~oes ou chamadas feitas ao servico.

45 3.4 requisitos n~ao-funcionais 33 informar os servicos disponveis; e criar os objetos destes servicos [RF011] - Servicos O Framework devera prover classes para acesso aos servicos da plataforma. Estas classes dever~ao ser escalaveis 4 e independentes para permitir que possam estar ausentes caso a plataforma n~ao possua o servico implementado [RF012] - Recursos O CMF devera prover um mecanismo para acesso aos arquivos de recursos 5 aplicac~ao. da 3.4 REQUISITOS N ~AO-FUNCIONAIS Esta sec~ao descreve os requisitos n~ao-funcionais do CMF. Estes requisitos foram elicitados de acordo com as necessidades do Framework e suas caractersticas de interoperabilidade [RNF001] - Portabilidade As aplicac~oes escritas usando o CMF n~ao devem ter nenhum conhecimento da plataforma alvo na qual o Framework esta implementado. Desta forma, nenhuma chamada as API's nem nenhum tipo de dado da plataforma alvo devem estar disponveis para as classes da aplicac~ao [RNF002] - Desempenho O desempenho e um criterio bastante importante para aplicac~oes que s~ao executadas em dispositivos com baixo poder de processamento. Para testar este requisito, faz-se necessario estipular um limite caso haja perda de desempenho ao se utilizar o CMF. Desta forma, estabelecemos que o desempenho da aplicac~ao desenvolvida com o CMF n~ao devera ser mais do que 10% maior do que o desempenho da mesma aplicac~ao escrita sem o Framework. O desempenho deve ser medido a partir do tempo de execuc~ao de uma aplicac~ao desenvolvida com o CMF e sem ele [RNF003] - Escopo do Framework O CMF e um framework de aplicac~oes. Desta forma, seu escopo esta limitado aos mecanismos necessarios para tratamento de eventos e estados. Incompatibilidades gracas e elementos de interface graca (como bot~oes, menus, etc.) n~ao est~ao no escopo inicial do CMF. 4 Escalavel signica que o conjunto de classes pode variar de acordo com a disponibilidade dos servicos na plataforma alvo. Alem disto, a aus^encia de uma classe de servico n~ao deveria impactar no resto do Framework. 5 Recursos s~ao dados usados pela aplicac~ao durante sua execuc~ao, como strings e imagens.

46 3.5 arquitetura [RNF004] - Extensibilidade O CMF devera prover um mecanismo para adic~ao de novas funcionalidades (servicos) de forma que n~ao cause impacto na sua arquitetura original [RNF005] - Internacionalizac~ao O processo de carga de recursos do Framework devera prover internacionalizac~ao de acordo com o idioma denido no dispositivo. 3.5 ARQUITETURA A arquitetura do CMF foi projetada baseada no padr~ao de projeto MVC (Model- View-Controller ) [KP98]. O MVC e bastante utilizado no desenvolvimento de aplicac~oes para dispositivos moveis pois determina a separac~ao de uma aplicac~ao em tr^es entidades. O Model e formado por classes que representam os dados da aplicac~ao. A View tem por objetivo realizar a apresentac~ao destes dados e capturar os eventos do usuario; sendo representada pelas telas. O Controller faz a ligac~ao entre o Model e a View, realizando o tratamento dos eventos, atuando sobre o Model e alterando os elementos da View para representar a nova forma dos dados. A Figura 3.1 representa o diagrama de classes UML [BRJ98] para o padr~ao de projeto MVC. Figura 3.1. Padr~ao MVC A partir dos requisitos e da metodologia utilizada para a sua denic~ao, o padr~ao MVC foi instanciado para o contexto de aplicac~oes para dispositivos moveis. Dois nveis a mais foram sugeridos para que a manipulac~ao de eventos seja realizada de maneira mais eciente e escalavel.

47 3.5 arquitetura 35 Esta extens~ao do MVC e chamada StateMVC [BSE07] e consiste em compor os padr~oes de projeto State [GJV94] e Manager [Som97] com o MVC. A composic~ao de padr~oes de projeto foi primeiramente abordada por Dirk Riehle [Rie97] na confer^encia OOPSLA'97 (Object-oriented programming, systems, languages, and applications - Programac~ao orientada a objetos, sistemas, linguagens e aplicac~oes). Riehle arma que a interac~ao de padr~oes de projeto dentro de uma composic~ao cria uma sinergia que confere a este conjunto uma singularidade. Em vez de apenas uma soma de outros padr~oes, torna-se um padr~ao novo. Portanto, no StateMVC, o Controller do MVC e formado pelos padr~oes State e Manager. Isto permite distribuir o tratamento de eventos da aplicac~ao, antes centralizado em um unico metodo, entre diversas classes que representam os estados da aplicac~ao. Modelar a aplicac~ao como maquina de estados tambem contribui para a sua modularidade e extensibilidade, ao permitir o desacoplamento de suas funcionalidades. Alem desta alterac~ao no Controller, a View do MVC tambem foi implementada atraves do padr~ao Manager. Um gerenciador e responsavel por controlar o conjunto de telas da aplicac~ao, denindo a tela ativa e renderizando-a 6 quando necessario Estrutura O diagrama de classes UML que representa esta arquitetura pode ser visto na Figura 3.2. Para a nomenclatura das classes da arquitetura do CMF, foi adotado o seguinte padr~ao de codicac~ao: Todas as classes pertencentes ao Framework dever~ao iniciar seu nome com CMF_. Isto permite a identicac~ao imediata da classe como sendo parte do CMF bem como evita conitos caso a plataforma alvo possua uma classe com o mesmo nome da classe do CMF. Antes do nome descritivo de cada classe, deve ser adicionada uma letra que representa o tipo desta classe: T para classes basicas compostas de atributos que n~ao fazem alocac~ao din^amica de memoria; C para classes basicas que alocam os seus atributos dinamicamente; M para classes abstratas, que representam um ponto de extens~ao do Framework ; e, por m, R para classes que representam servicos da plataforma. A seguir, cada classe componente desta arquitetura sera descrita. Application - A classe CMF_CApplication representa o ponto de entrada do Framework. Esta classe faz a ligac~ao entre a plataforma e o CMF, sendo responsavel por chamar os metodos do CMF quando receber noticac~oes e eventos da plataforma. Algumas plataformas n~ao permitem alocac~ao de memoria estatica, de forma que o padr~ao de projeto Singleton [GJV94] n~ao pode ser utilizado para as classes do Framework que devem possuir uma unica inst^ancia. Portanto, CMF_CApplication tambem e responsavel por instanciar estas classes na inicializac~ao da aplicac~ao. 6 Entende-se por renderizar, o processo de desenhar todos os elementos gracos que comp~oem a tela da aplicac~ao.

48 3.5 arquitetura 36 Figura 3.2. Diagrama de classes UML do CMF As classes instanciadas por CMF_CApplication s~ao CMF_CSystem, CMF_CScreenManager e CMF_CStateMachine, alem da aplicac~ao propriamente dita. Applet - A classe CMF_MApplet representa uma aplicac~ao. Cada aplicac~ao implementada com o CMF deve herdar desta classe e implementar os seus metodos abstratos para inicializac~ao (OnStartApplet), nalizac~ao (OnStopApplet), pausa (OnPauseApplet) e continuac~ao (OnResumeApplet) da aplicac~ao. System - CMF_CSystem faz a interface com o sistema operacional da plataforma. As

49 3.5 arquitetura 37 plataformas nas quais o sistema operacional ja e abstrado, como BREW e J2ME, ja possuem classes que realizam este papel, como a interface IShell de BREW e o pacote java.lang de J2ME. A classe CMF_CSystem tambem e responsavel por permitir o acesso e criac~ao das classes que encapsulam as diversas API's da plataforma. Esta classe implementa o padr~ao de projeto Factory Method [GJV94], utilizando metodos template de C++, o que dene uma classe padr~ao para a criac~ao das classes de APIs (plug-ins). Esta estrutura sera detalhada abaixo. State Machine - CMF_CStateMachine e a classe responsavel por gerenciar os estados da aplicac~ao. Os estados, ao serem criados, registram-se na classe CMF_CStateMachine e est~ao prontos para executar, de acordo com o uxo de estados denido pela aplicac~ao. Esta classe deve prover metodos para mudar o estado atual da aplicac~ao, bem como para tratar os eventos e envia-los para o estado correspondente. Abstract State - CMF_MState representa um estado da aplicac~ao. Esta e uma classe abstrata, da qual todos os estados concretos devem herdar. Possui um mecanismo para registrar os metodos como tratadores de eventos. Desta forma, quando um evento e enviado para a aplicac~ao, o metodo do estado atual que foi registrado para tratar este evento e chamado. Screen Manager - CMF_CScreenManager e responsavel por gerenciar as telas da aplicac~ao. Possui metodos para denir a tela ativa, bem como para enviar os eventos de tecla para serem traduzidos pela tela atual. Alem disto, o Screen Manager e responsavel por chamar o metodo Paint da tela atual sempre que for necessario renderizar a tela. Displayable - A classe CMF_CDisplayable e uma classe abstrata da qual todas as telas da aplicac~ao devem herdar. Ela possui metodos para exibic~ao dos dados da aplicac~ao na tela do dispositivo. As telas devem implementar os metodos OnActivate e OnInactivate que s~ao chamados quando estas se tornam ativas ou inativas, respectivamente. Tambem devem implementar os metodos TranslateEvent para traduzir um evento de tecla em sua func~ao correspondente na tela e Paint para desenhar os objetos na tela do aparelho. Dialog - Como a maioria das telas das aplicac~oes seguem um padr~ao bem conhecido, foi implementada no CMF a classe CMF_CDialog. Esta classe representa uma tela mais elaborada, que possui ttulo, softkeys e imagem de fundo. Desta forma, operac~oes comuns, como fazer o highlight das softkeys s~ao tratadas nesta classe. plug-ins - O CMF implementa os servicos providos pela plataforma atraves de uma arquitetura de plug-ins. Cada servico, como: sistema de arquivos, rede ou multimdia; e implementado como um plug-in, cando completamente isolado do resto do Framework. Desta forma, e possvel adicionar ou remover servicos sem alterar o codigo do resto do Framework Din^amica A Figura 3.3 representa o diagrama de sequ^encia da construc~ao de uma aplicac~ao que usa o CMF. A aplicac~ao tomada por exemplo implementa dois estados (StateA e StateB) e uma tela (Screen1), que s~ao classes concretas que herdam de CMF_MState e

50 3.5 arquitetura 38 CMF_CDisplayable, respectivamente. Figura 3.3. Construc~ao de uma aplicac~ao no CMF O primeiro metodo chamado, ao inicializar a aplicac~ao, e o construtor da classe da aplicac~ao que herda de CMF_MApplet. A chamada deste metodo e feita pela classe CMF_CApplication, que deve estar integrada com a plataforma de desenvolvimento escolhida de forma que ele seja chamado na inicializac~ao da aplicac~ao. Este construtor recebe os objetos do Framework que s~ao essenciais para a execuc~ao da aplicac~ao: System, StateMachine e ScreenManager. No construtor, deve-se instanciar os dados da aplicac~ao, chamar o metodo Construct do CMF_CScreenManager e do CMF_CStateMachine e tambem instanciar todos os estados e telas. Cada estado criado e responsavel por denir quais os eventos que ele vai tratar e quais os metodos responsaveis por tratar cada evento, atraves do metodo MapEvent. No seu construtor, apos chamar o metodo Construct de CMF_MState, que e responsavel por alocar a tabela de eventos do estado, deve-se chamar o metodo MapEvent para cada evento a ser tratado pelo estado. Desta forma sera criado o mapeamento entre o evento e o metodo deste estado que ira tratar o evento. Depois da criac~ao dos estados, as telas da aplicac~ao tambem devem ser criadas. Cada tela deve herdar da classe CMF_MDisplayable. No seu construtor, esta classe se adiciona ao ScreenManager e torna-se elegvel para ser exibida por algum estado. E importante notar que n~ao e necessario manter refer^encias para os estados e telas na classe que representa o Model (que herda de CMF_CApplet). Uma vez adicionados aos seus respectivos Managers, estes ir~ao controlar seu ciclo de vida e destruir estes objetos no nal da aplicac~ao.

51 3.5 arquitetura 39 Na Figura 3.4 podemos ver a sequ^encia de inicializac~ao da aplicac~ao. Depois de todos os estados e telas da aplicac~ao serem instanciados, o metodo StartApp da classe que herda de CMF_MApplet e chamado, o qual deve denir o estado inicial do CMF_CStateMachine. Figura 3.4. Inicializac~ao de uma aplicac~ao usando o CMF Ao denir o estado inicial, o metodo OnEnter deste estado e chamado, devendo inicializar os dados necessarios ao estado e denir qual sera a tela apresentada, atraves do metodo ChangeScreen de CMF_CScreenManager. O metodo ChangeScreen e responsavel por chamar o metodo OnInactivate da tela anterior (caso exista uma tela anterior), para que seus dados sejam removidos da memoria, e chamar o metodo OnActivate da tela atual, para que os dados desta tela sejam criados na memoria. Depois disto, sera chamado o metodo Paint para que a tela atual seja desenhada. Depois desta inicializac~ao, a aplicac~ao aguardara por eventos para serem tratados pelo estado atual. A Figura 3.5 mostra o diagrama de sequ^encia para dois exemplos de tratamento de eventos pela aplicac~ao, um evento de OK, e um evento de EXIT. A sequ^encia do tratamento de qualquer outro evento e analoga a estes mostrados. Quando a aplicac~ao recebe um evento, o metodo HandleEvent de CMF_CStateMachine e chamado. Este metodo verica qual e o estado atual da aplicac~ao e envia este evento para ser tratado, chamando o metodo HandleEvent deste estado. Caso o evento seja um evento de tecla, este evento sera traduzido antes de ser enviado ao estado, de acordo com a tela que esta sendo apresentada. No exemplo do primeiro evento, se a tecla pressionada for a softkey da esquerda e, na tela, esta tecla representa a func~ao OK, o evento de softkey da esquerda sera traduzido para o evento OK. Depois de traduzido, o estado ira vericar qual e o metodo responsavel por tratar este evento e ira chama-lo para que execute. A execuc~ao do metodo tratador do evento podera acarretar em alterac~oes no modelo ou na visualizac~ao da aplicac~ao, atraves de chamadas de metodos de CMF_MApplet e CMF_CScreenManager, respectivamente. Tambem e possvel mudar o estado da aplicac~ao, alterando o estado atual atraves do metodo ChangeState de CMF_CStateMachine.

52 3.6 ambiente de desenvolvimento 40 Figura 3.5. Din^amica do tratamento de eventos de uma aplicac~ao usando o CMF 3.6 AMBIENTE DE DESENVOLVIMENTO Assim como existem diferencas no desenvolvimento de aplicac~oes nas plataformas de dispositivos moveis, estas diferencas tambem est~ao presentes nos seus ambientes de desenvolvimento. A seguir ser~ao descritas as principais ferramentas que comp~oem os ambientes de desenvolvimento das plataformas alvo Ferramentas de Desenvolvimento em BREW O ambiente de desenvolvimento BREW e composto dos seguintes elementos: BREW SDK: O Software Development Kit para o BREW e provido pela Qualcomm e contem os seguintes elementos: BREW Simulator ; todos os arquivos de cabecalho e bibliotecas necessarias para compilar uma aplicac~ao BREW para o simulador; ferramentas para baixar a aplicac~ao no aparelho; ferramentas para fazer logging da aplicac~ao; e ferramentas para a execuc~ao de testes automaticos na aplicac~ao.

53 3.6 ambiente de desenvolvimento 41 MS Visual Studio: Visual Studio e a IDE ocial suportada pelo SDK. O SDK tambem contem um plug-in wizard para cirar projetos BREW no Visual Studio. RealView Development Suite - RVDS: O RVDS e a evoluc~ao do ADS (ARM Development Suite), um conjunto de compiladores para gerar codigo binario para o processador ARM dos aparelhos. Embora seja composto por ferramentas bem conhecidas e amplamente utilizadas, o ambiente de desenvolvimento BREW possui algumas falhas de integrac~ao entre as ferramentas Ferramentas de Desenvolvimento em Linux Existem diversas formas de se desenvolver aplicac~oes para Embedded Linux. Cada distribuic~ao prov^e o seu conjunto de ferramentas e ate alguns SDK's para ajudar o desenvolvedor a congurar melhor o seu ambiente. No desenvolvimento deste trabalho utilizamos o MontaVista Linux como plataforma alvo Linux para o CMF. Para esta distribuic~ao, n~ao existiam ambientes de desenvolvimento consolidados nem SDK's. Montamos o nosso proprio ambiente de desenvolvimento com os seguintes elementos: Maquina Linux: foi utilizado um PC com o sistema operacional Linux para o desenvolvimento, por ter maior compatibilidade com o sistema nal que tambem e Linux. GCC ARM cross-compiler (compilador cruzado 7 ): no Linux do PC foi instalado o GCC ARM Toolchain 8 para gerar codigo binario para o processador ARM do aparelho. NEdit: editor de texto para criac~ao e edic~ao do codigo fonte. N~ao foi utilizado nenhum simulador para rodar a aplicac~ao durante o perodo de desenvolvimento. O Framework foi desenvolvido e testado diretamente na plataforma alvo. Como pudemos perceber, os ambientes de desenvolvimento das plataformas escolhidas s~ao bastante diversos. Os problemas gerados por esta diversidade e uma proposta de soluc~ao ser~ao apresentados na sec~ao a seguir Proposta de Integrac~ao dos Ambientes de Desenvolvimento Um dos fatores que inuenciam no tempo de desenvolvimento e o ambiente utilizado. As atividades de congurac~ao do ambiente de desenvolvimento e manutenc~ao do mesmo terminam por aumentar o tempo de desenvolvimento total de uma aplicac~ao. 7 Compilac~ao cruzada signica que o codigo e compilado para uma arquitetura de processador que n~ao e a mesma que esta sendo utilizada para o desenvolvimento. 8 Conjunto de compiladores, ligadores e montadores que fazem compilac~ao cruzada.

54 3.6 ambiente de desenvolvimento 42 No contexto multi-plataforma, isto ca bem mais evidente: ao fazer o porting de uma aplicac~ao entre plataformas diferentes, o passo de congurar o ambiente de desenvolvimento antes de portar o codigo propriamente dito e uma atividade que leva tempo e n~ao e necessariamente o foco do desenvolvedor. Assim sendo, mesmo com um framework que faca a abstrac~ao da plataforma alvo, con- gurar e manter o ambiente de desenvolvimento para cada uma das plataformas diculta a implementac~ao da aplicac~ao. Portanto, um ambiente integrado de desenvolvimento multi-plataforma pode ser utilizado em conjunto com o Framework de desenvolvimento para complementar o processo de desenvolvimento como um todo. Isto faz com que o desenvolvedor n~ao tenha que se ater aos detalhes de infra-estrutura e possa dedicar-se completamente ao desenvolvimento da aplicac~ao propriamente dita. Alem disto, um ambiente de desenvolvimento multi-plataforma proporciona uma agilidade na interoperabilidade entre as plataformas que permite a vericac~ao da corretude da aplicac~ao em cada plataforma durante o processo de desenvolvimento inicial. Desta forma, para podermos utilizar o CMF em diversas plataformas sem que tenhamos que trocar de ambiente de desenvolvimento, temos que compatibilizar este ambiente, criando um ambiente integrado que funcione para todas as plataformas utilizadas com o CMF. Para isto, propusemos e implementamos o Gluon, ambiente integrado de desenvolvimento multi-plataforma, baseado no Eclipse e no plug-in CDT. Este ambiente de desenvolvimento sera descrito no Captulo 5.

55 - CAP ITULO 4 CMF - IMPLEMENTAC ~AO Neste captulo ser~ao vistos detalhes de implementac~ao do Framework nas plataformas abordadas neste trabalho. Tambem ser~ao mostrados os principais problemas na implementac~ao e como estes problemas foram resolvidos. 4.1 INTRODUC ~AO A implementac~ao do CMF foi iniciada depois de denidos os seus requisitos e a sua arquitetura. As plataformas escolhidas para a implementac~ao foram BREW e Embedded Linux. A plataforma BREW adotada e a baseada na vers~ao Para a plataforma Embedded Linux foi escolhida a distribuic~ao MontaVista pois possui o framework graco Qtopia, a vers~ao do Qt para dispositivos moveis. 4.2 IMPLEMENTAC ~AO DO CMF O principal objetivo do CMF e permitir que uma aplicac~ao escrita para uma plataforma seja portada para outra plataforma com o menor esforco de alterac~ao de codigo possvel. Assim, o primeiro passo da implementac~ao do Framework foi denir as suas classes atraves dos seus arquivos de cabecalho. Todos os arquivos de cabecalho do Framework s~ao comuns a todas as plataformas, com exec~ao dos arquivos que denem os tipos de dados, como sera visto na Sec~ao A inclus~ao destes arquivos na compilac~ao foi feita atraves de diretivas de compilac~ao condicional. Da mesma forma, qualquer outra incompatibilidade entre as plataformas foi resolvida desta maneira. Depois de denidas as assinaturas das classes do CMF, partimos para a implementac~ao destas classes em cada uma das plataformas alvo. Esta implementac~ao foi feita primeiro para BREW, e depois portada para Embedded Linux. Utilizamos o subversion[tig] como ferramenta de controle de vers~ao. Foi montada uma arvore de diretorios para os arquivos de cabecalho (parte comum) e uma arvore de diretorios para cada uma das plataformas alvo, conforme pode ser visto na Figura 4.1. Os arquivos-fonte que s~ao comuns as duas plataformas foram criados na estrutura de BREW e foi feito um link simbolico para estes arquivos na estrutura de Linux. Estas abordagens garantem uma melhor manutenabilidade do codigo, permitindo que as alterac~oes estejam auto-contidas e que n~ao haja duplicac~ao de codigo entre as plataformas. Nas sec~oes a seguir ser~ao discutidas as implementac~oes de cada um dos modulos do CMF, de acordo com a sua denic~ao na Sec~ao Arquitetura. 43

56 4.2 implementac ~ao do cmf 44 Figura 4.1. Estrutura do repositorio do codigo do CMF Tipos de dados O primeiro ponto a ser tratado na implementac~ao do CMF foi a compatibilizac~ao dos tipos de dados. Cada plataforma declara tipos de dados especcos para representar e acessar servicos do sistema redenindo os tipos basicos 1 que s~ao utilizados nas func~oes e metodos. Desta forma, e necessario denir um conjunto de tipos que sera utilizado pelas aplicac~oes desenvolvidas com o CMF. Este conjunto de tipos e mapeado nos tipos especcos de cada plataforma, fazendo com que o mapeamento entre os tipos seja direto. Caso algum tipo de uma das plataformas alvo n~ao implemente determinado metodo ou funcionalidade necessaria, esta devera ser implementada no tipo denido pelo CMF. Assim, foi criado um arquivo de cabecalho para a denic~ao de tipos para cada plataforma. Estes arquivos foram colocados sobre diretiva de compilac~ao condicional para que apenas o arquivo da plataforma para o qual o CMF esteja sendo compilado seja adicionado a compilac~ao Ponto de Entrada da Aplicac~ao BREW Conforme visto na Sec~ao 2.3, as aplicac~oes BREW s~ao modulos que podem ser carregados dinamicamente. Para isso, toda aplicac~ao BREW deve imple- 1 Um tipo basico e um tipo de dado que n~ao e composto por outros tipos de dados, como o tipo inteiro, o tipo caracter, o tipo boleano e outros.

57 4.2 implementac ~ao do cmf 45 mentar a interface IApplet. Os SDK's de BREW ja fornecem o codigo desta interface implementado, de forma que o desenvolvedor precisa apenas declarar uma estrutura que herda 2 de AEEApplet adicionando os membros que sejam necessarios a sua aplicac~ao. Depois, basta implementar os metodos para alocar e desalocar memoria para esta estrutura e um metodo para tratar eventos (HandleEvent). Pelo fato da API de BREW ser escrita na linguagem C e o desenvolvimento do CMF ter sido feito na linguagem C++, foi necessario fazer uma nova implementac~ao da interface IApplet de BREW. Esta implementac~ao dene uma classe, a CMF_CApplication, para ser usada no lugar da estrutura AEEApplet. Assim, um objeto da classe CMF_CApplication e construdo no lugar da estrutura AEEApplet padr~ao de BREW, e o seu metodo HandleEvent e chamado para enviar os eventos para o CMF. Com isto, esta classe devera implementar um construtor e um destrutor para alocar e desalocar a memoria dos objetos usados na aplicac~ao, e o metodo HandleEvent para o tratamento de eventos. Neste metodo, s~ao denidos quais os eventos que ser~ao tratados pelo Framework e quais os eventos que ser~ao enviados para a aplicac~ao. A declarac~ao desta classe pode ser vista a seguir. class CMF_CApplication { public: // Constructor CMF_CApplication(IShell* ishell, IDisplay* idisplay); // Destructor ~CMF_CApplication(); // Event handler. All events sent to the // application are handled by this method. bool HandleEvent(UINT16 aecode, UINT16 awparam, UINT32 adwparam); private: /// CMF System object CMF_CSystem *isystem; /// CMF Applet object CMF_MApplet *iapplet; /// CMF State Machine object CMF_CStateMachine *istatemachine; /// CMF Screen Manager object CMF_CScreenManager *iscreenmanager; /// CMF Graphics Context object CMF_CGraphicsContext *igc; 2 Na linguagem C, e possvel fazer uma heranca de uma estrutura ao declarar a estrutura-m~ae como sendo o primeiro elemento da estrutura-lha. Assim, os membros da estrutura-m~ae estar~ao nas mesmas posic~oes de memoria da estrutura-lha e esta pode ser utilizada onde a estrutura-m~ae e requerida.

58 4.2 implementac ~ao do cmf 46 }; CMF_CApplication e responsavel por criar todos os objetos do CMF que estar~ao disponveis para a aplicac~ao, alem da classe da aplicac~ao propriamente dita Embedded Linux Para Embedded Linux, tambem foi criada uma classe CMF_CApplication. Esta classe possui dois atributos a mais que a sua vers~ao em BREW: um objeto QApplication e um objeto QWidget, que representam a aplicac~ao e a janela principal, respectivamente. Alem dos atributos, foi adicionado o metodo Run() a esta classe. Este metodo e responsavel por denir os atributos do display (objecto da classe QWidget) e chamar o metodo exec() de QApplication para que a aplicac~ao entre no loop de recebimento e tratamento de eventos. O codigo abaixo mostra a declarac~ao desta classe para a plataforma Embedded Linux. class CMF_CApplication { public: // Constructor CMF_CApplication(int &argc, char** argv); // Destructor ~CMF_CApplication(); // Executes the Qt application int Run(); // Event handler. All events sent to the // application are handled by this method. bool HandleEvent(UINT16 aecode, UINT16 awparam, UINT32 adwparam); private: /// CMF System object CMF_CSystem *isystem; /// CMF Applet object CMF_MApplet *iapplet; /// CMF State Machine object CMF_CStateMachine *istatemachine; /// CMF Screen Manager object CMF_CScreenManager *iscreenmanager; /// CMF Graphics Context object CMF_CGraphicsContext *igc; };

59 4.2 implementac ~ao do cmf Classe de Aplicac~ao Conforme visto na Sec~ao 3.5.1, a classe CMF_MApplet representa uma aplicac~ao no CMF. Esta classe recebe os principais objetos do CMF: CMF_CScreenManager, CMF_CStateMachine e CMF_CSystem para acessar as funcionalidades da plataforma. Ao criar uma aplicac~ao, esta deve herdar da classe CMF_MApplet e implementar seus metodos abstratos. Os metodos que devem ser implementados obrigatoriamente s~ao: Construct Neste metodo, todos os estados e telas que v~ao ser utilizados pela aplicac~ao devem ser contrudos e a memoria alocada. Alem disto, os metodos Construct da maquina de estados e do gerenciador de telas devem ser chamados informando o numero de estados e telas da aplicac~ao, respectivamente. OnStartApplet Metodo chamado pelo CMF quando a aplicac~ao e inicializada. Neste ponto, todos os objetos do CMF e os estados e telas da aplicac~ao ja est~ao criados. OnStopApplet Metodo chamado pelo CMF quando a aplicac~ao e nalizada. Neste ponto, pode-se desalocar a memoria usada pela aplicac~ao e nalizar todas as operac~oes pendentes. Esta classe n~ao possui nenhuma depend^encia com a plataforma alvo, apenas dene um conjunto de metodos da aplicac~ao que ser~ao chamados pelo CMF. Assim, a sua implementac~ao e igual nas duas plataformas. Abaixo temos a declarac~ao da classe CMF_MApplet. class CMF_MApplet { public: // Class constructor. CMF_MApplet( CMF_CSystem *asystem, CMF_CStateMachine *astatemachine, CMF_CScreenManager *ascreenmanager); // Method that shall be implemented // to construct all applet objects. virtual int Construct() = 0; // Method that is called when applet starts virtual void OnStartApplet(UINT32 adwparam) = 0; // Method that is called when applet stops virtual void OnStopApplet(UINT32 adwparam) = 0; // Method that is called when applet is suspended virtual void OnSuspendApplet(){} // Method that is called when applet resumes

60 4.2 implementac ~ao do cmf 48 // its execution after being suspended virtual void OnResumeApplet(){} // inline method that returns the Screen Manager inline CMF_CScreenManager* ScreenManager(); // inline method that returns the State Machine inline CMF_CStateMachine* StateMachine(); // inline method that returns the System object inline CMF_CSystem* System(); protected: // Screen Manager object CMF_CScreenManager *iscreenmanager; // State Machine object CMF_CStateMachine *istatemachine; // System object CMF_CSystem *isystem; }; Gerenciador de Objetos Esta classe representa um gerenciador generico de objetos. E uma classe template 3 que implementa o padr~ao de projeto Manager[Som97]. CMF_CObjectManager possui metodos para adicionar objetos e reaver objetos de acordo com o seu identicador. Alem disto, possui metodos para alocar e desalocar memoria para os objetos gerenciados. Abaixo e mostrado o codigo desta classe template em C++. template <typename T> class CMF_CObjectManager { public: // default constructor CMF_CObjectManager() { this->imaxobjects = 0; this->iobjecttable = NULL; } // Method used to allocate memory for manager void Construct(const UINT16 &amaxobjects) 3 Template, em C++, representa uma classe que implementa um determinado comportamento que independe do tipo de dados utilizado. Desta forma, o tipo de dado pode ser parametrizado e pode-se instanciar esta classe para qualquer tipo de dado.

61 4.2 implementac ~ao do cmf 49 { } this->imaxobjects = amaxobjects; this->iobjecttable = new T*[aMaxObjects]; for (int i=0; i < amaxobjects; i++) { this->iobjecttable[i] = NULL; } // destructor virtual ~CMF_CObjectManager() { DeleteAll(); } // add an object to the manager int Add(T *aobject, const UINT16 &aid) { int ret = -1; if (aid < imaxobjects) { this->iobjecttable[aid] = aobject; ret = aid; } } return ret; // retrieves an object from the manager T* Get(const UINT16 &aid) const { T *object = NULL; if (aid < imaxobjects) { object = iobjecttable[aid]; } } return object; // delete all objects from manager

62 4.2 implementac ~ao do cmf 50 void DeleteAll() { for (int i=0; i<imaxobjects; i++) if (iobjecttable[i]!= NULL) delete iobjecttable[i]; } delete[] iobjecttable; private: // Array of pointers to objects T **iobjecttable; }; // Max number of objects UINT16 imaxobjects; Maquina de Estados A classe CMF_CStateMachine implementa um gerenciador de estados. Esta classe herda do gerenciador generico CMF_CObjectManager, instanciando-o para a classe CMF_MState. CMF_CStateMachine Possui dois metodos principais: HandleEvent, que e responsavel por receber os eventos enviados pela plataforma e encaminha-los para o estado ativo; e ChangeState, que permite a mudanca do estado ativo e chama os metodos OnExit do estado anterior e EnterFunction do estado que se tornara ativo. Como esta classe n~ao possui nenhum codigo dependente de plataforma, temos apenas uma implementac~ao desta classe para todas as plataformas alvo. Abaixo e mostrada a declarac~ao da classe CMF_CStateMachine. class CMF_CStateMachine : public CMF_CObjectManager<CMF_MState> { public: // Class constructor CMF_CStateMachine(); private: // Receive all events and send them to current active state int HandleEvent(UINT16 aecode, UINT16 awparam, UINT16 adwparam); // Change current active state int ChangeState(const UINT16 &aid); // Active state

63 4.2 implementac ~ao do cmf 51 }; CMF_MState *icurrentstate; Estados da Aplicac~ao As classes estados da aplicac~ao devem ser implementadas herdando da classe base dos estados do CMF: CMF_MState. Esta classe possui dois conjuntos de metodos. Os metodos auxiliares, que devem ser utilizados para que a arquitetura proposta para a maquina de estados funcione; e os metodos abstratos, que devem ser implementados pelos estados que herdam desta classe. Os metodos auxiliares s~ao: Construct Metodo de CMF_MState responsavel por construir a tabela de eventos do estado. Deve ser chamado no construtor da classe, informando o numero de eventos que o estado ira tratar. MapEvent Este metodo deve ser chamado para mapear cada evento a ser tratado pelo estado no metodo responsavel por trata-lo. HandleEvent Metodo responsavel por receber o evento da maquina de estados e chamar o metodo do estado responsavel por tratar este evento. Abaixo s~ao descritos os metodos abstrados da classe CMF_MState: OnEnter Metodo chamado quando o estado se torna ativo pela primeira vez. Geralmente deve ser utilizado para alocac~ao de memoria que deve permanecer alocada mesmo que o estado se torne inativo. OnResume Este metodo e chamado em todas as outras vezes, com excec~ao da primeira, em que o estado se torna ativo. Geralmente e utilizada para inicializar o estado. Caso este metodo n~ao seja implementado nas classes que herdam de CMF_MState, sua implementac~ao padr~ao chamara o metodo OnEnter. OnExit Metodo chamado quando o estado estava ativo e torna-se inativo. Deve ser uilizado para desalocar memoria que n~ao sera mais utilizada pelo estado. Alem destes metodos, a classe CMF_MState declara alguns tipos de dados que ser~ao utilizados no mecanismo de tratamento de eventos. Foi denido o tipo CMF_TEventHandler que representa um metodo tratador de eventos do estado. Este novo tipo e um ponteiro para metodos da classe CMF_MState e recebe dois par^ametros, um de 16 bits e outro de 32 bits, que s~ao os par^ametros do evento a ser

64 4.2 implementac ~ao do cmf 52 tratado. Desta forma, todos os metodos tratadores de eventos implementados nas classes que herdam de CMF_MState devem ter esta mesma assinatura. A classe CMF_TEvent e uma classe privada de CMF_MState e representa um evento da tabela de eventos do estado. Esta classe contem apenas dois atributos, o identicador do evento e um ponteiro para o metodo (do tipo CMF_TEventHandler) que deve ser chamado para tratar o evento. Assim, ao receber um evento, o estado verica na tabela de eventos se existe alguma entrada para este evento e chama o metodo correspondente. Abaixo segue a declarac~ao da classe CMF_MState. class CMF_MState { public: // Event Handler method pointer typedef bool (CMF_MState::*CMF_TEventHandler)(UINT16 awparam, UINT32 adwparam); // State enter function pointer /** This is a pointer to the method that will be called when state becomes active. This method is OnEnter if it is the first time the state becomes active or OnResume if it is not the first time */ typedef void (CMF_MState::*CMF_StateEnterFunction)(); // Class construction CMF_MState(CMF_MApplet *aapplet, UINT16 aid); // Construct method. /** This method shall be called to allocate memory on event handler table for all events that shall be handled by the state. */ int Construct(UINT32 amaxevent); // Class destructor. ~CMF_MState(); // Handle events sent to the state. int HandleEvent(UINT16 aecode, UINT16 awparam, UINT32 adwparam); // Map events into event handlers (methods) int MapEvent(UINT16 aeventcode, CMF_TEventHandler aeventhandler); // Method that is called when state becomes active by first time virtual void OnEnter(){} // Method that is called when state becomes active virtual void OnResume(){OnEnter();} // Method that is called when state is active and becomes inactive virtual void OnExit(){}

65 4.2 implementac ~ao do cmf 53 // Calls the correct enter function (OnEnter / OnResume) virtual void EnterFunction(); protected: // pointer to the applet CMF_MApplet *iapplet; private: // CMF_TEvent represents an event in the state. /** This class holds the event code and the Event handler (method from state).*/ class CMF_TEvent { public: // Event code UINT16 ieventcode; // Event handler CMF_TEventHandler ieventhandler; }; }; // event table that holds all events handled by this state CMF_TEvent *ieventtable; // max number of events that this state can handle UINT32 imaxevents; // current number of events registered in the state UINT32 icurrentnumevents; // Enter function pointer CMF_StateEnterFunction ienterfunction; Embora tipo CMF_TEventHandler represente um ponteiro para metodo da classe CMF_MState, os metodos que ser~ao utilizados como tratadores de eventos pertencem as classes que representam os estados da aplicac~ao (e que herdam de CMF_MState). Desta forma, e necessario fazer um cast entre o metodo da classe derivada e o tipo CMF_TEventHandler que representa um ponteiro para metodo da classe base. Abaixo segue um exemplo da chamada do metodo MapEvent, mostrando o cast necessario. // Construct event table Construct(STATE_MAX_EVENT); // Map each event ID into the targeted event handler MapEvent(EVT_BACK, static_cast <CMF_TEventHandler> (&CState1::OnBack)); MapEvent(EVT_START, static_cast <CMF_TEventHandler> (&CState1::OnStart));

66 4.2 implementac ~ao do cmf 54 Este cast so ira funcionar em C++ se a classe derivada n~ao possuir heranca multipla 4. Pois sem possuir heranca multipla, o ponteiro this da classe derivada ca na mesma posic~ao de memoria do ponteiro this da classe base, sendo o this do objeto em quest~ao utilizado, mesmo quando se tem um ponteiro para um metodo da classe base. Este mecanismo funciona da mesma forma que o dynamic binding 5 funciona para metodos virtuais sobrepostos (overhided). Abaixo temos o trecho de codigo do metodo HandleEvent. Este codigo mostra como o metodo tratador de evento da classe derivada e chamado atraves do ponteiro para metodo da classe base. int CMF_MState::HandleEvent(UINT16 aecode, UINT16 awparam, UINT32 adwparam) { int ret = CMF_FAIL; } // walk through event table, searching for the // event that has same event code as the aecode parameter for (int i=0; i<icurrentnumevents; i++) { if ((ieventtable[i].ieventcode == aecode) && (ieventtable[i].ieventhandler!= NULL)) { // when event is found, call the handler // passing the parameters ret = (this->*(ieventtable[i].ieventhandler))(awparam, adwparam); } } return ret; Neste codigo e possivel ver o uso do operador "->*" que serve para desreferenciar o ponteiro para metodo que esta na variavel ieventhandler Dispositivo Graco O acesso a tela do dispositivo da-se atraves da classe CMF_RGraphicsContext. Esta classe possui metodos que implementam as principais primitivas de desenho, alem de metodos para escrita de texto na tela e desenho de imagens. Esta classe e completamente dependente da plataforma, visto que acessa as funcionalidades de desenho do dispositivo. Assim, foi feita uma implementac~ao para BREW 4 A linguagem C++ possui um mecanismo de heranca em que uma classe derivada pode herdar de mais de uma classe base. 5 Ligac~ao din^amica. Mecanismo que permite uma chamada ao metodo do objeto que esta na memoria, e n~ao ao metodo da classe do ponteiro que aponta para o objeto.

67 4.2 implementac ~ao do cmf 55 e outra para Embedded Linux. Para compatibilizar as duas plataformas, a classe CMF_GRAPHICS_DATA foi denida contendo os tipos de dado para cada uma das plataformas e CMF_RGraphicsContext herda desta classe. A partir dos objetos contidos na classe CMF_GRAPHICS_DATA, foram implementados todos os metodos de manipulac~ao dos elementos gracos da classe CMF_RGraphicsContext. Abaixo segue o codigo que declara esta classe, com todos os metodos de manipulac~ao graca implementados. class CMF_CGraphicsContext : public CMF_MPlugin, private CMF_GRAPHICS_DATA { public: // Class constructor CMF_CGraphicsContext(CMF_CSystem *asystem):cmf_mplugin(asystem){} // Construct method virtual int Construct(); // Class destructor virtual ~CMF_CGraphicsContext(); // Set primary display to be the active display int SetPrimaryDisplay(); // Set secondary display to be the active display int SetSecondaryDisplay(); // Set current display to full screen mode int SetFullScreen(int avalue); // clear the screen void ClearScreen(); // Updates current display by performing // all pending drawing operations. void Renderize(); // returns current screen width int Width(); // returns current screen height int Height(); // set drawing foreground color CMF_TRGB SetFGColor(CMF_TRGB acolor); // set drawing background color CMF_TRGB SetBGColor(CMF_TRGB acolor); // set drawing area CMF_TRect SetDrawingArea(CMF_TRect &arect); // retrieves drawing area CMF_TRect GetDrawingArea();

68 4.2 implementac ~ao do cmf 56 //////////////////////////////////////////////////////// // image related functions //////////////////////////////////////////////////////// // Retrieves image width and height void GetImageSize(CMF_TImage* aimage, int* awidth, int* aheight); // Draw the image in the specified position void Draw(CMF_TImage* aimage, int ax, int ay); //////////////////////////////////////////////////////// // text related functions //////////////////////////////////////////////////////// // Calculates string width and height in pixels based // on string chars and font used void MeasureString(const CMF_TString* atext, CMF_TFont afont, UINT16 *awidth, UINT16 *aheight); // Draw the string in the specified position with // specified font void Draw(const CMF_TString* atext, CMF_TFont afont, int ax, int ay, UINT32 aalign=0); //////////////////////////////////////////////////////// // rectangle drawing functions //////////////////////////////////////////////////////// // Draw the edges of a rectangle (with no filling) void DrawFrame(const CMF_TRect* arect, CMF_TRGB acolor); // Draw a filled rectangle void DrawRect(const CMF_TRect* arect, CMF_TRGB acolor); protected: // screen height int iheight; // screen width int iwidth; }; A seguir, ser~ao mostradas as denic~oes da classe CMF_GRAPHICS_DATA para cada uma das plataformas alvo BREW abaixo segue a denic~ao da classe CMF_GRAPHICS_DATA para BREW. class CMF_GRAPHICS_DATA

69 4.2 implementac ~ao do cmf 57 { }; public: IDisplay *pidisplay1; IDisplay *pidisplay2; IDisplay *pcurrentdisplay; AEEDeviceInfo di; Esta classe possui ponteiros para as inst^ancias das telas interna e externa do dispositivo, alem de uma estrutura responsavel por obter as informac~oes gracas, como tamanho da tela, quantidade de cores e outras propriedades. Manipulando estes atributos e possvel implementar todos os metodos declarados em CMF_RGraphicsContext Embedded Linux para Embedded Linux, a classe CMF_GRAPHICS_DATA foi denida de acordo com o codigo abaixo. class CMF_GRAPHICS_DATA { public: QImage *pdisplay; CMF_CWidget *pdisplaydevice; CMF_TRGB CMF_TRGB CMF_TRect ifgcolor; ibgcolor; idrawingrect; }; Esta classe implemeta double buering 6 possuindo uma imagem pdisplay na qual s~ao efetuadas todas as operac~oes gracas e um widget que representa a tela, onde a imagem pdisplay e desenhada sempre que houver um evento de pintura enviado pela plataforma Gerenciador de Telas As telas da aplicac~ao s~ao gerenciadas pela classe CMF_CScreenManager. Esta classe herda do gerenciador generico CMF_CObjectManager, instanciando-o para a classe CMF_MDisplayable, que e a classe base das telas. O CMF ja adiciona todas as telas da aplicac~ao no CMF_CScreenManager assim que elas s~ao criadas. O construtor do gerenciador de telas recebe um objeto da classe gerenciador graco para enviar este objeto para o metodo paint das telas. Os principais metodos desta classe s~ao: ChangeScreen, responsavel por trocar a tela ativa, chamando os metodos OnInactivate da tela anterior e OnActivate da proxima tela; e TranslateEvent que ira 6 Tecnica de pintura geralmente utilizada em jogos, na qual todos os elementos s~ao desenhados em uma area fora da tela e depois esta area e desenhada na tela de uma vez.

70 4.2 implementac ~ao do cmf 58 enviar o evento para a tela ativa, para que este evento seja traduzido de acordo com o que estiver sendo mostrado na tela. Abaixo, temos o codigo que declara a classe CMF_CScreenManager. class CMF_CScreenManager : public CMF_CObjectManager<CMF_CDisplayable> { public: // class constructor CMF_CScreenManager(CMF_CSystem *asystem, CMF_CGraphicsContext* agc); // class destructor ~CMF_CScreenManager(); // Methods to return the active screen inline UINT16 GetActiveScreenId(); inline CMF_CDisplayable* GetActiveScreen(); // Method to change the active screen int ChangeScreen(UINT16 aid); // Method to translate an event according to // active screen UINT16 TranslateEvent(UINT16 aevin, UINT16 akey, UINT32 adwparam ); // Repaint method that is called by platform when // active screen must be repainted void Repaint(); private: // Active screen UINT16 iactivescreenid; // System object CMF_CSystem* isystem; // Graphics context object CMF_CGraphicsContext* igc; }; Telas da Aplicac~ao As telas da aplicac~ao s~ao classes que herdam de CMF_CDisplayable. O construtor de CMF_CDisplayable recebe o gerenciador de telas e um numero identicador para a tela como par^ametros, adicionando esta tela no gerenciador com este identicador.

71 4.2 implementac ~ao do cmf 59 CMF_CDisplayable dene um conjunto de metodos que devem ser implementados por todas as telas da aplicac~ao: OnActivate: metodo chamado quando a tela torna-se ativa. OnInactivate: este metodo e chamado quando a tela torna-se inativa. Paint: metodo chamado quando o Framework necessita pintar a tela ativa. Este metodo recebe uma inst^ancia do CMF_RGraphicsContext para realizar as operac~oes de pintura. TranslateEvent: metodo chamado pela maquina de estados para traduzir os eventos de teclas recebidos. Estes eventos s~ao traduzidos ou consumidos pela tela, de acordo com os controles existentes na mesma. Abaixo temos a declarac~ao da classe CMF_CDisplayable. Como esta classe n~ao possui nenhuma depend^encia com a plataforma alvo, sua implementac~ao e a mesma para todas as plataformas do CMF. class CMF_CDisplayable { public: // class constructor CMF_CDisplayable(CMF_CScreenManager *ascreenmanager, UINT16 aid); // Paints the displayable on screen // The default implementation does nothing. virtual int Paint(CMF_CGraphicsContext *agc) {return CMF_SUCCESS;} // Method that is called when displayable // becomes active (visible) virtual int OnActivate(){return CMF_SUCCESS;} // Method that is called when displayable becomes // inactive (no visible) virtual int OnInactivate(){return CMF_SUCCESS;} // Method used to translate key events into user events // depending on controls that are on screen virtual UINT16 TranslateEvent(UINT16 aecode, UINT16 akey, UINT32 akeyflags); // Method to retrieve the screen manager object.

72 4.2 implementac ~ao do cmf 60 inline CMF_CScreenManager * ScreenManager(); protected: // ScreenManager object. CMF_CScreenManager *iscreenmanager; }; Chamadas ao Sistema As chamadas ao sistema 7 s~ao providas pela classe CMF_CSystem. Esta classe possui metodos para: enviar eventos para a maquina de estados, que ser~ao tratados pelo estado ativo; terminar a aplicac~ao; e metodos que recuperam a data e hora do sistema. Com o desenvolvimento das plataformas alvo, esta classe pode ser expandida para suportar threads e execuc~ao paralela, alarmes, informac~oes do sistema, gerac~ao de numeros aleatorios, informac~oes sobre memoria e outras funcionalidades referentes ao sistema operacional. Esta classe herda de CMF_OBJECT_DATA, uma denic~ao do CMF que signica o objeto base da plataforma alvo. Para Embedded Linux esta denido como QObject enquanto que em BREW, e a interface IBase. Estes duas classes representam as classes base da arquitetura de Embedded Linux e BREW, respectivamente. Alem de herdar de CMF_OBJECT_DATA, CMF_CSystem possui um atributo da classe CMF_SYSTEM_DATA, que representa os objetos do sistema necessarios ao funcionamento do CMF e aos metodos da classe CMF_CSystem. Abaixo temos a denic~ao desta classe para as duas plataformas alvo iniciais do CMF. BREW class CMF_SYSTEM_DATA { public: IShell *pishell; IDisplay *pidisplay; UINT32 iclassid; }; Embedded linux class CMF_SYSTEM_DATA { public: CMF_CApplication *pcmfapp; QApplication *papp; QWidget *pdisplay; QTimer *ptimer; 7 Conhecidas como system calls, s~ao chamadas as func~oes do sistema operacional ou func~oes que o sistema operacional deveria prover.

73 4.2 implementac ~ao do cmf 61 }; UINT32 iclassid; Abaixo temos a declarac~ao da classe CMF_CSystem. class CMF_CSystem: public CMF_OBJECT_DATA { public: // Class constructor CMF_CSystem(CMF_SYSTEM_DATA *adata); // Class destructor ~CMF_CSystem(); // Terminates the applet int Exit(bool agotoidle=false); // Send an event to the system. unsigned char SendEvent(UINT16 aecode, UINT16 awparam, UINT32 adwparam); // Post an event into event queue bool PostEvent(UINT16 aecode, UINT16 awparam, UINT32 adwparam); // Get time from handset UINT32 GetTime(); // Get up time from handset UINT32 GetUpTime(); // Get date of handset CMF_TDate GetDate(); }; // System Data used by other classes // that depends on the platform CMF_SYSTEM_DATA *idata; Servicos do sistema Os servicos do sistema s~ao implementados atraves de um sistema de plug-ins. Cada plug-in implementa uma API especca da plataforma, como sistema e arquivos, rede, som, gracos, acesso a camera entre outras. Estes plug-ins devem funcionar de forma completamente independente, para que seja possvel adicionar e remover plug-ins de acordo com os servicos existentes no hardware e na plataforma alvo. Todos os servicos do sistema herdam de uma classe base, CMF_MPlugin. Assim como a classe CMF_CSystem, esta classe tambem herda de CMF_OBJECT_DATA, classe base da plataforma alvo.

74 4.3 testes de conformidade 62 CMF_MPlugin possui como atributo um objeto da classe CMF_CSystem, responsavel por prover acesso aos objetos do sistema operacional para os plug-ins. Alem deste atributo, que deve ser passado no construtor da classe, esta classe possui o metodo Construct, que deve ser chamado para a construc~ao do plug-in e alocac~ao dos recursos necessarios para o seu funcionamento. Cada servico, por ser completamente dependente da plataforma alvo, possui implementac~oes diferentes em cada uma das plataformas, devendo ser portado e reescrito para cada nova plataforma suportada pelo CMF. Abaixo segue o codigo que representa a declarac~ao da classe CMF_MPlugin. class CMF_MPlugin : public CMF_OBJECT_DATA { public: // Class constructor CMF_MPlugin(CMF_CSystem *asystem) { this->isystem = asystem; } // Method that can be used by plugin to // initialize and allocate all needed resources virtual int Construct(){return CMF_SUCCESS;} protected: // CMF_CSystem object CMF_CSystem *isystem; }; Na proxima sec~ao, sera abordada a implementac~ao de uma aplicac~ao que usa as diversas funcionalidades providas pelo CMF e que foi utilizada para testar estas funcionalidades. 4.3 TESTES DE CONFORMIDADE Para garantir a corretude da implementac~ao do Framework, foi desenvolvida uma aplicac~ao de testes para o CMF, chamada CCT (CMF Compliance Tests). Esta aplicac~ao possui dois modulos: o primeiro executa os testes de forma automatica, gerando um relatorio com o resultado destes testes; o segundo permite interatividade com o usuario e explora a utilizac~ao dos componentes desenvolvidos no Framework, permitindo que o usuario dena quais testes que ser~ao executados e observe o seu resultado. Por ser tambem uma aplicac~ao CMF, o CCT deve possuir os seus componentes basicos: um Applet, estados e telas. A classe CMF_CCCTApplet e o ponto de entrada da aplicac~ao, herdando de CMF_MApplet e implementado os seus metodos abstratos. Alem disto, esta classe tambem possui o plug-in CMF_CResources responsavel por acessar os recursos da aplicac~ao.

75 4.3 testes de conformidade 63 Nesta aplicac~ao, utilizamos o padr~ao de projeto AbstractFactory[GJV94] para criar os elementos de interface. A abstrac~ao e obtida em C++ atraves do metodo template que cria as telas, de acordo com o seu tipo. Desta forma, foi implementada uma classe chamada CMF_CCCTResFactory, de acordo com a declarac~ao a seguir: class CMF_CCCTResFactory : public CMF_CObject { public: // construction and destruction CMF_CCCTResFactory(CMF_CResources *aresources); int Construct(); ~CMF_CCCTResFactory(); // create methods CMF_CSoftkey *CreateSoftkey(UINT16 alabelid, UINT16 aevent); CMF_CMenu *CreateMenu(); template <class T> T* CreateDialog(T* adialog, CMF_CScreenManager *ascreenmanager, UINT16 aid, UINT16 atitleid); private: // resource attributes used to create // interface objects, such as images, fonts // and color definitions }; Os principais metodos desta classe s~ao CreateSoftkey, CreateMenu e CreateDialog. CreateSoftkey e CreateMenu ir~ao criar objetos CMF_CSoftkey e CMF_CMenu com valores padr~ao para fonte, cores e imagens de fundo. O metodo CreateDialog e um metodo template que ira criar cada tela da aplicac~ao e denir seus atributos: template <class T> T* CreateDialog(T* adialog, CMF_CScreenManager *ascreenmanager, UINT16 aid, UINT16 atitleid) { // retrieve dialog title from resources CMF_TString buffer[cmf_str_max_length]; iresources->getstring(atitleid, buffer,

76 4.3 testes de conformidade 64 CMF_STR_MAX_LENGTH); // create an object from desired dialog adialog = new T(aScreenManager, aid); if (adialog) { // set its default attributes, such as // title and background images, default font // and colors adialog->settitle(buffer, ititleimage); adialog->setbackground(ibgimage, ibgcolor); adialog->setforeground(ibgcolor, ifont); } } return adialog; Como pode ser visto no codigo acima, todas as telas da aplicac~ao ser~ao criadas com a mesma apar^encia, mesmo pertencendo a classes diferentes. Abaixo segue trecho de codigo que mostra como ca a chamada do metodo CreateDialog para criar as telas do CCT. Os par^ametros s~ao, respectivamente: um ponteiro para a tela a ser criada (para que o compilador consiga denir qual e a classe usada no template); o ScreenManager ; o ID da tela; e o ID da string ttulo da tela. // main menu dialog menudialog = iresfactory->createdialog(menudialog, ScreenManager(), E_CCT_SCREEN_MAIN_MENU, IDS_CCT_APPLICATION_NAME); Nas proximas sec~oes veremos os detalhes da implementac~ao desta aplicac~ao, bem como sua divis~ao em estados e tambem as telas implementadas Estados do CCT O diagrama de estados do CCT pode ser visto na Figura 4.2. Para esta aplicac~ao, foram denidos os seguintes estados: StateSplash Estado responsavel por apresentar a tela de entrada da aplicac~ao. Este estado trata dois eventos: EVT_CCT_ANY_KEY, que representa qualquer tecla pressionada; e EVT_CMF_TIMER, que representa um evento enviado pelo timer. Os dois eventos s~ao tratados pelo mesmo metodo, que e responsavel por mudar o estado para o StateMenu.

77 4.3 testes de conformidade 65 Figura 4.2. Diagrama de estados da aplicac~ao CCT StateMenu O estado StateMenu representa o menu principal da aplicac~ao, apartir do qual podemos selecionar quais testes iremos executar. Trata os eventos gerados pela tela de menu para cada um dos itens, que correspondem aos plug-ins que ser~ao testados. Desta forma, adicionar testes para mais plug-ins signica apenas escrever um estado tratando os seus eventos e adicionar a mudanca para este estado no menu principal. StateAutoTest Estado responsavel por gerar eventos para realizac~ao de testes automaticos. E um super-estado 8 do qual todos os estados de testes de plug-ins devem herdar. Trata o evento EVT_CCT_NEXT_TEST, responsavel por avancar automaticamente entre os estados de testes de plug-ins. StateAny Este estado e uma super classe da qual todos os outros estados, com excec~ao do StateMenu e StateSplash, devem herdar. Ele possui o tratamento para o evento BACK que altera o estado atual para o estado StateMenu. 8 Super-estado signica que este estado e uma classe base para os outros estados.

78 4.3 testes de conformidade 66 StateFile, StateTimer, StateMedia e StateSocket Estados que representam o conjunto de testes realizados para os plug-ins especcos. Estes estados tratam os eventos EVT_CCT_START e EVT_CCT_STOP que representam a solicitac~ao de incio e de m da bateria de testes da API, respectivamente. Alem disto, tratam eventos especcos gerados por cada um dos plug-ins Telas A aplicac~ao CCT possui apenas tr^es telas. A primeira, CMF_CCCTSplashScreen, representa a tela de entrada da aplicac~ao. Esta tela exibe apenas uma imagem de fundo e e ativada pelo estado StateSplash. A tela CMF_CCCTMenuDialog representa o menu principal. Cada item de menu corresponde a um teste especco e leva a aplicac~ao para o estado correspondente a este teste. CMF_CCCTMenuDialog e visvel sempre que o estado StateMenu for o estado ativo. Por m, a tela CMF_CCCTResultDialog representa a tela que apresenta o resultado dos testes. Esta tela torna-se visvel sempre que a aplicac~ao vai para um dos estados de testes de plug-ins. Sua func~ao e exibir o progresso e os resultados dos testes. O principal metodo desta tela e mostrado a seguir: int CMF_CCCTResultDialog::Write(CMF_TString *astring) { int ret = -1, i; // if there is less than imaxlines if (icurrline < imaxlines) { ilines[icurrline] = astring->duplicate(); ret = ++icurrline; Scroll(1); } // else it is needed to delete first line else { // delete first line delete[] ilines[0]; // move all lines 1 line up for (i=0; i<icurrline-1; i++) { ilines[i] = ilines[i+1]; } // add this line as last line ilines[i] = astring->duplicate(); ret = icurrline;

79 4.3 testes de conformidade 67 } } return ret; O metodo Write escreve uma string na tela. Esta tela possui um buer de imaxlines linhas as quais podem ser vistas ao rolar a tela para cima ou para baixo. Caso o estado escreva mais do que imaxlines linhas nesta tela, as primeiras a serem escritas s~ao removidas, de forma que as ultimas imaxlines linhas possam ser vistas, como numa la FIFO 9. No Captulo 6 veremos os estudos de caso realizados com o CMF. Estes estudos de caso incluem a aplicac~ao CCT, para realizac~ao de analises comparativas da eciencia de escrita de codigo usando o CMF. 9 First In, First Out. O primeiro a entrar e o primeiro a sair.

80 - CAP ITULO 5 GLUON - UM AMBIENTE INTEGRADO DE DESENVOLVIMENTO Neste captulo sera abordado o ambiente de desenvolvimento criado para o CMF. Este ambiente e chamado Gluon e tem por objetivo integrar todas as ferramentas utilizadas no desenvolvimento de aplicac~oes para as plataformas alvo. 5.1 INTRODUC ~AO Como p^ode ser visto no Captulo 2, cada plataforma de desenvolvimento para dispositivos moveis possui um ambiente de desenvolvimento especco, com um conjunto de ferramentas e funcionalidades. Alem disto, como foi mostrado na Sec~ao 3.6, a compatibilizac~ao dos ambientes de desenvolvimento e um dos fatores determinantes para a agilidade na portabilidade das aplicac~oes entre as plataformas. O desenvolvimento da ferramenta Gluon visa justamente promover esta compatibilizac~ao entre os ambientes de desenvolvimento, proporcionando uma maior produtividade na implementac~ao e no porting das aplicac~oes que utilizam o CMF. O nome Gluon vem dos gluons, partculas sub-at^omicas que interagem com os quarks para formar o nucleo do atomo. Gluon (do ingl^es glue + on) signica juntar, integrar, colar; justamente o sentido da ferramenta que e de integrar as varias ferramentas de desenvolvimento para dispositvos moveis em um unico ambiente. Para o desenvolvimento desta ferramenta, foi escolhida a plataforma Eclipse[Ecla], pois e uma plataforma de codigo aberto, escrita em Java e completamente extensvel e modular, permitindo o agregamento de funcionalidades e facilitando a implementac~ao de novos ambientes de desenvolvimento. 5.2 A PLATAFORMA ECLIPSE O Eclipse e uma plataforma designada para a construc~ao de ambientes de desenvolvimento integrados (do ingl^es Integrated Development Environment - IDE ) escrita na linguagem Java e distribuda na forma de codigo aberto. No entanto, esta plataforma e uma composic~ao de componentes; ao utilizar um sub-conjunto destes componentes podem ser criadas aplicac~oes diversas[cr06]. Desta forma, foram construdas varias ferramentas de desenvolvimento utilizando o Eclipse. Ao adicionar os componentes de desenvolvimento Java (chamado JDT - Java Development Tools), o Eclipse se transforma em um ambiente de desenvolvimento para 68

81 5.2 a plataforma eclipse 69 esta linguagem. Se adicionarmos os componentes de desenvolvimento C/C++ ( CDT - C/C++ Development Tooling ), o Eclipse ira se transformar em um IDE para desenvolvimento em C/C++. Se quisermos um IDE com capacidade para desenvolvimento em Java e C++, basta adicionarmos os componentes do CDT e JDT em conjunto. Com isto, e possvel perceber que a extensibilidade e a possibilidade de integrac~ao de varias ferramentas em um unico ambiente s~ao as pricipais caractersticas do Eclipse. Abaixo s~ao descritos os principais componentes que fazem parte da estrutura base do Eclipse: Platform Runtime: e o nucleo do Eclipse e tem a func~ao de inicializar o ambiente e carregar todos os outros componentes. Workspace: componente que representa o diretorio de trabalho no sistema de arquivos e contem todos os projetos do usuario. Workbench: E a interface graca, e representa a janela do Eclipse. Contem todos os menus, barras de ferramentas, esquemas de visualizac~oes e editores. Team: componente responsavel por integrar o Eclipse com uma ferramenta de controle de vers~ao. Help: responsavel por apresentar a documentac~ao do Eclipse e de todos os outros componentes. Figura 5.1. Arquitetura da plataforma Eclipse A Figura 5.1 ilustra esta estrutura, destacando os principais componentes e API's da arquitetura do Eclipse. Tambem pode-se perceber a possibilidade de extens~ao do Eclipse ilustrada pelos elementos que est~ao plugados na estutura base. Um dos pontos principais e o mais visvel ao usuario e o workbench. Assim, iremos descrever abaixo os principais elementos que comp~oem o Workbench do Eclipse.

82 5.2 a plataforma eclipse 70 View: corresponde a generalizac~ao de uma area delimitada dentro da janela do Eclipse. Cada view pode representar diversos elementos, como editores, arvores de diretorio, itens de congurac~ao, entre outros. Editor: e uma view associada a um determinado formato de arquivo e e congurado para editar este formato. Geralmente o editor apresenta o arquivo com uma serie de controles associados que permitem uma melhor visualizac~ao e manipulac~ao dos dados desse arquivo. Perspectiva: uma perspectiva representa um conjunto de views e sua organizac~ao dentro do workbench. Por exemplo, a perspectiva de edic~ao de codigo normalmente apresenta um editor para a linguagem correspondente, uma view com uma arvore de diretorios, mostrando os arquivos que fazem parte do projeto e uma view com a estrutura logica (classes, metodos, atributos); enquanto uma perspectiva de depurac~ao para esta mesma linguagem deve possuir outras views como a sada do console, valores das variaveis que est~ao sendo analisadas, lista dos breakpoints, entre outras. Wizard: um wizard e um conjunto de passos (telas) que ir~ao guiar ou ajudar o usuario a realizar determinada atividade. Os wizards s~ao bastante comuns na criac~ao dos projetos, mas podem aparecer em outras situac~oes nas quais o usuario deve executar um conjunto denido de passos, como a criac~ao de uma nova classe no projeto. A customizac~ao do Eclipse para servir como ferramenta de desenvolvimento em uma determinada linguagem signica estender os elementos acima para realizar as func~oes necessarias ao desenvolvimento na linguagem especca. A seguir, sera descrito o funcionamento da plataforma, como tambem a din^amica de integrac~ao dos componentes no Eclipse e o mecanismo para extens~ao destes componentes A arquitetura de plug-ins do Eclipse A Plataforma Eclipse e composta por um nucleo, chamado de Platform Runtime, e diversos modulos, chamados plug-ins. O nucleo da plataforma e responsavel por identicar e carregar os plug-ins na inicializac~ao, enquanto os plug-ins implementam efetivamente as funcionalidades desejadas. Todas as outras funcionalidades do Eclipse (que n~ao a do nucleo) s~ao descritas como plug-ins e features (conjunto de plug-ins). Um plug-in e a estrutura basica da arquitetura do Eclipse. Os relacionamentos de depend^encias e a comunicac~ao entre plug-ins s~ao descritas atraves de pontos de extens~ao. Cada plug-in declara sua lista de plug-ins que ele depende (estende) e os pontos que ele permite que outros plug-ins estendam. Este relacionamento pode ser visto na Figura 5.2. Existe um arquivo XML (plugin.xml) que descreve e publica todas as depend^encias e pontos de extens~ao de um plug-in. Cada ponto de extens~ao declarado no arquivo plugin.xml deve ter uma interface 1 associada que possui todos os metodos necessarios 1 Aqui considera-se Interface como uma interface da linguagem Java.

83 5.2 a plataforma eclipse 71 Figura 5.2. Arquitetura dos plug-ins do Eclipse para este ponto de extens~ao. Por exemplo, se o plug-in B estende o plug-ins A, ele tem que implementar a interface declarada por A e o arquivo XML deve ter a informac~ao que B vai ser usado quando A precisar de uma classe que implemente esta interface. Com este mecanismo, e possvel desenvolver plug-ins e congurar os plug-ins existentes para realizar as funcionalidades desejadas. E desta forma que o Eclipse se transforma em IDE para Java, C++ e varias outras linguagens de programac~ao. A seguir, sera apresentado o plug-in CDT (C/C++ Development Tooling) do Eclipse. Este plug-ins implementa todas as funcionalidades necessarias para transformar o Eclipse em um IDE para desenvolvimento em C/C++. Por este motivo, o CDT tambem foi utilizado como a base para o desenvolvimento do Gluon CDT - Eclipse C/C++ Development Tooling O CDT e um projeto de codigo aberto (licenciado sobre a licenca CPL 2 da IBM) e implementado completamente na linguagem Java como um conjunto de plug-ins para o Eclipse. Estes plug-ins adicionam perspectivas no Workbench do Eclipse que prov^e o suporte ao desenvolvimento em C/C++ atraves de um conjunto de views, wizards e componentes para edic~ao e depurac~ao do codigo. Embora o CDT seja focado no desenvolvimento de software em C/C++ para o sistema operacional Linux, ele funciona muito bem em todos os ambientes onde existam as ferramentas de compilac~ao e depurac~ao GNU disponveis, como: Win32 (Windows 95/98/Me/NT/2000/XP), QNX Neutrino e Solaris. Cada plug-in do CDT implementa uma determinada funcionalidade requerida pelo processo de desenvolvimento e e administrado separadamente, possuindo seus proprios desenvolvedores, listas de discuss~ao e ferramentas para rastreamento de bugs. Abaixo s~ao descritos os principais plug-ins do CDT: CDT Feature Eclipse: representa a feature CDT para o Eclipse. E o ponto de entrada do CDT dentro do Eclipse e realiza a ligac~ao entre todos os outros plug-ins do CDT. CDT Core: e o nucleo do CDT, provendo as funcionalidades basicas como os 2 Common Public License - disponvel em

84 5.3 gluon 72 editores para C/C++, o parser da linguagem, code completion 3, wizard para cirac~ao de projetos, entre outros. CDT Build: disponibiliza as funcionalidades para compilac~ao nos modos padr~ao e gerenciado. O modo de compilac~ao padr~ao permite que o desenvolvedor crie e edite o makele 4 do projeto, enquanto o modo gerenciado cria e gerencia este makele de acordo com os arquivos e congurac~oes deste projeto. CDT Launch: prov^e o mecanismo para chamada de ferramentas externas, como o compilador e o depurador, alem de simuladores e outros. Funciona como elemento de ligac~ao entre o Core e o Debug. CDT Debug: possui todas as funcionalidades necessarias para realizac~ao da depurac~ao do codigo, congurac~oes de debug e comunicac~ao com os depuradores externos, compatveis com a interface MI (Machine Independent - independente de maquina). A seguir, sera apresentado o ambiente de desenvolvimento multi-plataforma Gluon, destacando sua implementac~ao e interac~ao com o CDT e o Eclipse. 5.3 GLUON O Gluon e um ambiente de desenvolvimento multi-plataforma criado para permitir uma facil interoperabilidade entre as plataformas de desenvolvimento para dispositivos moveis. O principal objetivo do Gluon e facilitar o uso do CMF permitindo a troca de plataforma dentro de um mesmo ambiente de desenvolvimento. Assim, o Gluon visa complementar o CMF fazendo com que o desenvolvedor foque no desenvolvimento da sua aplicac~ao e n~ao precise se preocupar com as congurac~oes do ambiente de desenvolvimento de cada plataforma. A partir do estudo e entendimento da plataforma Eclipse e do CDT, foi tracado um plano de desenvolvimento para Gluon. Seguem abaixo as principais funcionalidades necessarias ao Gluon de acordo com as funcionalidades existentes nos ambientes de desenvolvimento de cada plataforma alvo e com a experi^encia de desenvolvimento do CMF: Application Wizard O Gluon deve fornecer um wizard para criac~ao de projetos 5. Este wizard deve possuir passos para denic~ao das plataformas alvo e das propriedades da aplicac~ao. Congurac~ao do projeto Para cada projeto, deve ser possvel congurar os SDK's e as vers~oes das plataformas alvo que ser~ao utilizadas. 3 Funcionalidade do IDE que permite sugerir a inserc~ao de um comando ou nome baseado na digitac~ao parcial deste comando ou nome. 4 Script com os comandos necessarios para a compilac~ao de um projeto. 5 Um projeto em um IDE signica o conjunto de arquivos e congurac~oes necessarios a implementac~ao de uma aplicac~ao.

85 5.4 componentes do ambiente gluon 73 Congurac~ao dos compiladores O conjunto de compiladores a ser utilizado para cada plataforma deve ser conguravel. Gerenciamento da compilac~ao O Gluon deve prover um mecanismo de gerenciamento dos makeles para cada plataforma, de forma que a compilac~ao seja realizada sem que o desenvolvedor precise editar estes makeles. Integrac~ao com as ferramentas dos SDK's Todas as ferramentas auxiliares presentes nos SDK's das plataformas alvo devem ser acessveis atraves do Gluon. Caso seja possvel, estas ferramentas podem ser integradas em uma view dentro do proprio ambiente de desenvolvimento. Compilac~ao para o simulador Para as plataformas que possuem simuladores, deve ser possvel compilar o codigo para estes simuladores. Suporte a depurac~ao no simulador O Gluon deve fornecer suporte a depurac~ao do codigo no simulador. Compilac~ao para o dispositivo Da mesma forma que a compilac~ao para o simulador, o Gluon deve fornecer integrac~ao com os compiladores para os dispositivos das plataformas alvo. Suporte a depurac~ao no dispositivo O Gluon deve fornecer suporte para depurac~ao cruzada 6 quando esta estiver disponvel na plataforma. no proprio dispositivo, Este conjunto de funcionalidades permitem que o Gluon seja utilizado da mesma forma para cada uma das plataformas alvo aumentando a produtividade do desenvolvimento de aplicac~oes utilizando o CMF. 5.4 COMPONENTES DO AMBIENTE GLUON Foi necessario estender o CDT para implementar as funcionalidades descritas acima que n~ao estavam presentes no ambiente CDT/Eclipse. Desta forma, foram criados componentes no Gluon para realizar estas extens~oes. Abaixo segue uma descric~ao de cada componente do Gluon. Estes componentes ser~ao detalhados na Sec~ao 5.5. Core: responsavel por mostrar os tens de menu, ttulos e algumas congurac~oes gracas. Este componente possui todas as modicac~oes necessarias para a interface graca do Gluon. 6 Depurac~ao cruzada ocorre quando o codigo que esta sendo depurado foi compilado e executa em uma maquina com arquitetura diferente da que esta sendo usada para realizar a depurac~ao. Isto signica que o codigo alvo da depurac~ao n~ao possui o mesmo conjunto de instruc~oes e n~ao executa na maquina que esta realizando a depurac~ao.

86 5.5 implementac ~ao do gluon 74 Launch: responsavel por iniciar a aplicac~ao que se esta desenvolvendo nos modos de execuc~ao e depurac~ao. Debugger: responsavel por denir o ambiente de depurac~ao e chamar o depurador. On-Device Debugger: funcionalidade que congura a conex~ao com o dispositivo e inicializa o depurador no modo de depurac~ao cruzada. Build: responsavel pela criac~ao e manutenc~ao dos makeles de compilac~ao do codigo para o dispositivo e para o simulador. A Figura 5.3 ilustra o relacionamento e a heranca entre o Gluon e o CDT. Figura 5.3. Relacionamento entre o Gluon e o CDT 5.5 IMPLEMENTAC ~AO DO GLUON O Gluon foi implementado de acordo com as funcionalidades esperadas e com a proposta de extens~ao dos componentes do CDT. A Tabela 5.1 mostra a estimativa do tempo de desenvolvimento do Gluon. Devido ao tempo estimado de implementac~ao de todas as funcionalidades do ambiente, o escopo de implementac~ao do Gluon foi reduzido para que os resultados esperados pudessem ser obtidos. Assim, como o Eclipse e o CDT ja funcionam e s~ao utilizados para o desenvolvimento de aplicac~oes para Linux, foi decidido que o escopo do Gluon na abrang^encia deste trabalho seria limitado a plataforma BREW. Um outro motivo e n~ao menos importante e que o ambiente de desenvolvimento atual para BREW, apesar de ser composto por ferramentas conhecidas e bastante utilizadas como o Microsoft Visual Studio e o ARM RealView Development Suite, n~ao possui uma integrac~ao adequada entre estas ferramentas. Desta forma, alcancamos o objetivo de analise e especicac~ao do ambiente de desenvolvimento multi-plataforma e implementamos este ambiente para uma das plataformas

87 5.5 implementac ~ao do gluon 75 Atividade Estudo da plataforma Eclipse Estudo do CDT Remoc~ao dos plug-ins padr~ao do Eclipse que n~ao ser~ao utilizados Customizac~ao da interface Perspectiva BREW Wizard BREW Launch BREW Debug BREW Debug on-device BREW Compiler properties Liux Wizard Liux Launch Linux Debug Linux Debug on-device Linux Compiler properties Tempo estimado 2 semanas 2 semanas 1 semana 4 semanas 4 semanas 6 semanas 3 semanas 5 semanas 8 semanas 4 semanas 6 semanas 2 semanas 6 semanas 10 semanas 3 semanas Tabela 5.1. Estimativa de implementac~ao do Gluon alvo. O Gluon como ambiente de desenvolvimento para BREW superou os resultados esperados, conforme sera mostrado no Captulo 7. O Gluon para BREW possui varias vantagens sobre o ambiente atual de desenvolvimento 7. A Tabela 5.2 mostra estas vantagens. O Gluon para BREW foi desenvolvido durante quase dez meses, por uma equipe de quatro pessoas. Assim como o Eclipse, o Gluon possui codigo aberto e este codigo e distribudo sob a licenca EPL 8. O website do Gluon contem informac~oes sobre como fazer o download e instalar a ferramenta, e esta disponvel em A seguir, ser~ao descritas a integrac~ao do Gluon com as ferramentas externas Integrac~ao do Gluon com ferramentas externas Compilac~ao Para compilac~ao do codigo fonte, o Gluon utiliza os compiladores GNU[GNUb]. O MinGW - Minimalist GNU for Windows [GNUh] e utilizado para compilar o codigo para o simulador, enquanto o GNUDe - GNU Development Environment for ARM [GNUc] e utilizado para compilar o codigo para o dispositivo Depurac~ao O Gluon utiliza o GDB - GNU Debugger [GNUd] para realizar a depurac~ao do codigo. O GDB for MinGW [GNUg] realiza a depurac~ao no simulador enquanto o GNUDe ja possui uma vers~ao do GDB para depurac~ao cruzada. 7 O ambiente atual de desenvolvimento BREW consiste no Visual Studio em conjunto com o ADS - ARM Developer Suite. 8 EPL - Eclipse Public License, disponvel em

88 5.5 implementac ~ao do gluon 76 Funcionalidades Gluon Ambiente atual BREW Application Wizard Acesso as ferramentas do SDK BREW atraves do ambiente Compilac~ao para o simulador Depurac~ao no simulador Compilac~ao para o dispositivo integrada com o ambiente Depurac~ao para o dispositivo integrada com o ambiente Suporte a linguagem C++ de forma nativa no ambiente Framework para o desenvolvimento de aplicac~oes BREW Tabela 5.2. Comparac~ao das funcionalidades do Gluon em relac~ao ao ambiente de desenvolvimento atual para BREW Simulac~ao O Gluon utiliza o simulador disponvel no proprio SDK de BREW para executar as aplicac~oes compiladas para o simulador. Ao executar o simulador, o Gluon realiza as congurac~oes necessarias para que o simulador sempre inicie preparado para executar a aplicac~ao que esta sendo desenvolvida. Estas congurac~oes incluem a passagem da aplicac~ao como par^ametro e a denic~ao dos diretorios da aplicac~ao no simulador Integrac~ao com SDKs O Gluon se integra completamente com os SDK's de BREW a partir da vers~ao Desta forma, consegue ter acesso aos recursos do SDK, possue bot~oes customizados para iniciar as ferramentas auxiliares do SDK e inclui os caminhos dos arquivos de cabecalho da API de BREW no projeto automaticamente Screenshots A Figura 5.4 e a Figura 5.5 mostram alguns screenshots do Gluon.

89 5.5 implementac ~ao do gluon 77 Figura 5.4. Tela inicial do Gluon Figura 5.5. Gluon: depurac~ao de codigo no simulador

90 CAP ITULO 6 ESTUDO DE CASO Neste captulo ser~ao apresentados os resultados da utilizac~ao do Framework de acordo com as aplicac~oes desenvolvidas para este estudo de caso. Inicialmente sera feita uma descric~ao breve de cada aplicac~ao desenvolvida e da metodologia utilizada. A seguir, ser~ao apresentadas as metricas consideradas e a forma de coleta destas metricas. Finalmente os resultados ser~ao apresentados e analisados. 6.1 INTRODUC ~AO O principal objetivo deste estudo de caso e avaliar a efetividade do CMF. Esta efetividade sera medida de acordo com as metricas denidas na Sec~ao 6.3. A partir do resultado da analise das metricas, poderemos listar as vantagens e desvantagens do uso deste Framework bem como a contribuic~ao deste trabalho para o desenvolvimento de software para dispositivos moveis. 6.2 METODOLOGIA DO ESTUDO DE CASO Para a realizac~ao da analise comparativa da efetividade do CMF, duas aplicac~oes foram implementadas nas plataformas alvo. Estas aplicac~oes foram implementadas de duas maneiras: sem utilizar o Framework ; e utilizando-o. Alem disto, para minimizar a inu^encia do fator \conhecimento previo da aplicac~ao" 1 a ordem da implementac~ao das aplicac~oes foi trocada. Um das aplicac~oes foi implementada primeiro com o CMF e depois sem o CMF, enquanto a outra foi implementada primeiro sem o CMF e depois com o CMF. A Tabela 6.1 ilustra a ordem cronologica da implementac~ao das aplicac~oes e da utilizac~ao do CMF. Aplicac~ao 1a Implementac~ao 2a Implementac~ao VNC sem o CMF com o CMF CCT com o CMF sem o CMF Tabela 6.1. Ordem de implementac~ao das aplicac~oes do estudo de caso. A primeira aplicac~ao implementada foi o VNC, conforme citado na Sec~ao 3.2. Esta aplicac~ao foi desenvolvida primeiramente para BREW e depois portada para Embedded 1 Uma aplicac~ao que e implementada pela segunda vez tende a ser melhor otimizada em termos de tamanho, esforco de desenvolvimento e desempenho, pois o desenvolvedor ja conhece os problemas a serem enfrentados e ja os resolveu uma vez. 78

91 6.3 escopo do estudo de caso 79 Linux, ambos sem a utilizac~ao do Framework. Esta aplicac~ao foi escolhida pois nos permite usar varios servicos disponibilizados pela plataforma, como: rede, threads, gracos em baixo nvel, entre outros. A segunda aplicac~ao utilizada neste estudo de caso foi o CCT, uma aplicac~ao de testes implemetada para validar o CMF, conforme descrito na Sec~ao 4.3. Esta aplicac~ao foi construda em conjunto com o CMF em BREW e portada para a segunda plataforma alvo (Embedded Linux). Depois de construdos o CMF e a aplicac~ao de testes (CCT), o VNC foi implementado utilizando o CMF. A intenc~ao era vericar a usabilidade do Framework ao se construir uma aplicac~ao real 2. Por m, o CCT foi implementado sem o CMF, nas duas plataformas alvo deste trabalho. O objetivo era completar a medic~ao da efetividade e da contribuic~ao do Framework para o desenvolvimento. 6.3 ESCOPO DO ESTUDO DE CASO O escopo do estudo de caso dene as metricas que ser~ao consideradas para medir a efetividade do Framework. Estas metricas foram denidas a partir das principais necessidades do desenvolvimento de aplicac~oes para dispositivos moveis: Quantidade de linhas de codigo(kloc 3 ): metrica base para calculo do tamanho do artefato desenvolvido. Foi utilizada a ferramenta SCLC (Source Code Line Counter) para calcular a quantidade de linhas de codigo das aplicac~oes do escopo deste estudo de caso. Tempo de desevolvimento: representa o esforco em horas para o desenvolvimento do artefato. A reportagem do tempo de desenvolvimento foi feita utilizando a ferramenta AllNetic Time Tracker. Tamanho da aplicac~ao: medido em kilo bytes, dene a quantidade de espaco de armazenamento necessario para a aplicac~ao. Este tamanho inclui o codigo da aplicac~ao propriamente dito e todas as bibliotecas necessarias para o seu funcionamento, assim como o tamanho do CMF, quando aplicavel. Este tamanho foi medido considerando a aplicac~ao compilada para ARM e sem informac~oes de depurac~ao. Tempo de execuc~ao: representa o tempo necessario, em milisegundos, para a realizac~ao de operac~oes de processamento. Quanto menor este tempo, melhor o desempenho da aplicac~ao. Para o CCT, esta metrica foi coletada medindo-se o tempo para a realizac~ao do auto teste 4. Para o VNC, esta metrica foi coletada medido-se o tempo de desenho da tela principal. As duas medidas foram realizadas utilizando-se a aplicac~ao compilada para ARM e sem informac~oes de depurac~ao. Alem disto, foram realizadas dez medic~oes de tempo para cada aplicac~ao e calculada 2 Entende-se por aplicac~ao real uma aplicac~ao que n~ao tem o objetivo de testar a plataforma e que possui requisitos e problemas reais. 3 Kilo Lines Of Code - Mil linhas de codigo. 4 Teste automatico que passa por todas as funcionalidades do CMF, conforme descrito na Sec~ao

92 6.4 apresentac ~ao dos resultados 80 a media destas medic~oes, para minimizar a inu^encia de algum fator externo a aplicac~ao nestas medidas. Desta forma, as metricas ser~ao analisadas para cada uma das aplicac~oes deste estudo de caso, e medidas com e sem o CMF, para validar o seu uso. O objetivo desta analise e calcular o percentual de variac~ao da metrica ao se usar o Framework, a partir do percentual de variac~ao de cada uma das aplicac~oes. O percentual de variac~ao de uma metrica signica o quanto o seu valor foi alterado com a utilizac~ao do CMF. Neste estudo de caso, este percentual de variac~ao sera representado pela letra sigma ( ), e sera calculado como sendo a media aritmetica dos percentuais encontrados para cada uma das aplicac~oes. Apesar do escopo deste estudo de caso estar limitado as duas aplicac~oes citadas anteriormente, para cada nova aplicac~ao desenvolvida utilizando o CMF ser~ao coletadas estas mesmas metricas e o percentual de variac~ao de cada metrica sera novamente calculado. Espera-se que com o aumento da quantidade de aplicac~oes implementadas e analizadas, estes valores converjam para o percentual que sera considerado a contribuic~ao nal do CMF para cada uma das metricas analisadas. Assim, os percentuais de variac~ao calculados neste estudo de caso s~ao referentes e dependentes desta implementac~ao inicial do CMF e das aplicac~oes analisadas. 6.4 APRESENTAC ~AO DOS RESULTADOS As metricas denidas na Sec~ao 6.3 foram coletadas para as duas aplicac~oes do escopo deste estudo de caso, de acordo com o procedimento e as ferramentas especicadas. Nas sec~oes a seguir, ser~ao apresentados os resultados destas analises Quantidade de linhas de codigo(kloc) A primeira metrica a ser analisada e a quantidade de linhas de codigo (KLOC ) da aplicac~ao. O objetivo desta analise e tentar entender quantas linhas de codigo evita-se escrever ao se utilizar o CMF. A Tabela 6.2 mostra o resultado da coleta da metrica de KLOC. A coluna CMMTS representa a quantidade de linhas comentadas ou em branco nos arquivos analisados. Vale salientar que todas as aplicac~oes seguiram o mesmo padr~ao de codicac~ao com o mesmo padr~ao de comentarios 5. A coluna NCSL representa a quantidade de linhas de codigo efetivas, ou seja, a quantidade de linhas de codigo que ser~ao transformadas em codigo-objeto. Por m, a coluna Total representa a soma das duas colunas anteriores. Nesta Tabela, foi feita uma comparac~ao da variac~ao do numero de linhas de codigo para cada uma das aplicac~oes, levando em conta o total de linhas e tambem as linhas de codigo efetivas (NCSL). O resutado desta comparac~ao mostrou uma reduc~ao em NCSL de aproximadamente 41% para o CCT e de 23% para o VNC. A reduc~ao de linhas total esta exibida na Tabela 6.2 apenas para ns comparativos, visto que esta quantidade de linhas depende do padr~ao de codicac~ao adotado e da quantidade de comentarios inserida 5 Padr~ao de codicac~ao em C++ do C.E.S.A.R.

93 6.4 apresentac ~ao dos resultados 81 CCT CMMTS NCSL Total (KLOC CCT ) (Total CCT ) Com CMF ,06% -46,81% Sem CMF VNC CMMTS NCSL Total (KLOC V NC ) (Total V NC ) Com CMF ,62% -32,40% Sem CMF Tabela 6.2. Resultado das medidas de linhas de codigo (KLOC). no codigo. A Figura 6.1 ilustra a diferenca na quantidade de linhas de codigo para as duas aplicac~oes deste estudo de caso. Figura 6.1. Resultado das medidas de linhas de codigo (KLOC). Considerando que o CCT foi implementado em conjunto com o CMF, e natural que algumas funcionalidades necessarias a esta aplicac~ao ja estejam incorporadas no Framework. Isto explica o valor de 41% de reduc~ao de NCSL. O percentual de variac~ao de linhas de codigo foi calculado para o CMF de acordo com a Equac~ao 6.1. (KLOC CM F ) = (KLOC CCT ) + (KLOC V N C ) 2 ( 41; 06%) + ( 22; 62%) (KLOC CM F ) = 2 (KLOC CM F ) = 31; 84% (6.1)

94 6.4 apresentac ~ao dos resultados 82 O resultado indica uma reduc~ao de linhas de codigo de (KLOC CM F ) = 31; 84% Esforco A coleta do esforco necessario para a implementac~ao das aplicac~oes pode ser visto na Tabela 6.3. Foram medidas as horas gastas na implementac~ao 6 e depois estas horas foram convertidas para um valor de sta/month, que signica a quantidade de recursos necessarios em um m^es de trabalho, considerando 167 horas trabalhadas por m^es. A medida de sta/month e bastante utilizada na industria de desenvolvimento de software para o calculo de estimativas e do esforco real do desenvolvimento. No entanto, os seus valores n~ao signicam que se aumentarmos a quantidade de recursos, e possvel realizar o trabalho em um tempo proporcionalmente menor. Estes valores servem para normalizar o esforco que e medido em recursos x tempo e obter uma medida absoluta para ns de comparac~ao. CCT Esforco Sta/Month (SM CCT ) Com CMF 103 h 0,62-33,97% Sem CMF 156 h 0,93 VNC Esforco Sta/Month (SM V NC ) Com CMF 183 h 1,10-55,58% Sem CMF 412 h 2,47 Tabela 6.3. Resultado das medidas de esforco. Comparando o valor de sta/month necessario para a implementac~ao do CCT com e sem o Framework, obtivemos uma reduc~ao de aproximadamente 34% no esforco. Ao se realizar esta mesma comparac~ao para o VNC, obtivemos uma reduc~ao de esforco de 55,58%. Comparando a variac~ao do esforco entre as duas aplicac~oes, pode ser considerado que houve inu^encia do fator \conhecimento previo da aplicac~ao" para o VNC. Mesmo assim, a reduc~ao de esforco obtida no CCT mostra que o Framework e realmente efetivo, mesmo para os casos em que se tem um conhecimento previo da implementac~ao da aplicac~ao. A Figura 6.2 mostra a medic~ao da quantidade de esforco para as duas aplicac~oes deste estudo de caso. (SM CM F ) = (SM CCT ) + (SM V N C ) 2 ( 33; 97%) + ( 55; 58%) (SM CM F ) = 2 (SM CM F ) = 44; 78% (6.2) 6 O acompanhamento das horas gastas na implementac~ao faz parte do processo de desenvolvimento do C.E.S.A.R, onde as aplicac~oes deste estudo de caso foram desenvolvidas.

95 6.4 apresentac ~ao dos resultados 83 Figura 6.2. Resultado das medidas de esforco. De acordo com a Equac~ao 6.2, houve uma reduc~ao no esforco ao se utilizar o CMF de (SM CM F ) = 44; 78%. E importante salientar que neste calculo de esforco n~ao estamos considerando o esforco de implementac~ao do CMF. O objetivo e vericar a contribuic~ao do CMF para a reduc~ao do esforco de desenvolvimento considerando o CMF ja implementado Tamanho O tamanho da aplicac~ao nal, em kilo bytes, e uma variavel importante para as aplicac~oes desenvolvidas para dispositivos moveis. Devido a quantidade de memoria de armazenamento reduzida destes dispositivos, e importante que as aplicac~oes possuam um tamanho reduzido. Portanto, foi feita uma comparac~ao entre o tamanho de cada aplicac~ao com e sem o CMF para vericar a inu^encia do CMF nesta metrica. Vale salientar que este tamanho inclui todo o codigo fonte da aplicac~ao, bem como todas as bibliotecas necessarias para a execuc~ao da aplicac~ao, incluindo o codigo do CMF quando aplicavel. A Tabela 6.4 mostra o resultado da coleta da metrica de Tamanho. De acordo com esta Tabela, o uso do CMF aumenta o tamanho da aplicac~ao. Este aumento foi de 7,77% para o CCT e de 10,00% para o VNC. A Figura 6.3 mostra o tamanho das aplicac~oes estudadas, utilizando e sem utilizar o Framework. Assim, o percentual de variac~ao de tamanho para o CMF foi calculado como sendo a media aritmetica do percentual de variac~ao de tamanho das duas aplicac~oes deste estudo

96 6.4 apresentac ~ao dos resultados 84 CCT Tamanho (SIZE CCT ) Com CMF 111 kb 7,77% Sem CMF 103 kb VNC Tamanho (SIZE V NC ) Com CMF 242 kb 10,00% Sem CMF 220 kb Tabela 6.4. Resultado das medidas de tamanho da aplicac~ao. Figura 6.3. Resultado das medidas de tamanho da aplicac~ao. de caso, conforme mostrado na Equac~ao 6.3. De acordo com a Equac~ao 6.3, o tamanho da aplicac~ao aumentou, em media, 8,88% com o uso do CMF. (SIZE CM F ) = (SIZE CCT ) + (SIZE V N C ) 2 7; 77% + 10; 00% (SIZE CM F ) = 2 (SIZE CM F ) = 8; 88% (6.3) Desempenho Para a metrica de desempenho, foi coletado o tempo de execuc~ao das operac~oes principais de cada aplicac~ao, de acordo com o procedimento especicado na Sec~ao 6.3. Vale

97 6.4 apresentac ~ao dos resultados 85 salientar que as proprias instruc~oes para calculo do tempo de execuc~ao interferem no resultado aumentando o tempo de execuc~ao. Para minimizar este fator, foram utilizadas as mesmas instruc~oes de medic~ao de tempo para as vers~oes da aplicac~ao com e sem o CMF. Alem disto, o tempo de execuc~ao foi coletado apenas para a vers~ao em BREW das aplicac~oes. A Tabela 6.5 mostra o resultado do calculo de tempo de execuc~ao. CCT Tempo de Execuc~ao (RUNTIME CCT ) Com CMF 1294 ms 2,29% Sem CMF 1265 ms VNC Tempo de Execuc~ao (RUNTIME V NC ) Com CMF 65 ms 4,84% Sem CMF 62 ms Tabela 6.5. Resultado das medidas de desempenho. A Figura 6.4 mostra o tempo de execuc~ao das aplicac~oes estudadas, utilizando e sem utilizar o Framework. Figura 6.4. Resultado das medidas de tempo de execuc~ao. Os valores para o percentual de variac~ao do tempo de execuc~ao calculados para o CCT e VNC s~ao respectivamente 2,29% e 4,84%. Isto signica que, para as duas aplicac~oes, houve um aumento no tempo de execuc~ao, e consequentemente uma diminuic~ao do desempenho. O calculo do percentual de variac~ao do tempo de execuc~ao para o CMF foi realizado a partir de uma media aritmetica dos valores das aplicac~oes deste estudo de caso. (RUNT IME CM F ) = (RUNT IME CCT ) + (RUNT IME V N C ) 2

98 6.5 considerac ~oes finais 86 2; 29% + 4; 84% (RUNT IME CM F ) = 2 (RUNT IME CM F ) = 3; 57% (6.4) O resultado do percentual de variac~ao do tempo de execuc~ao para o CMF pode ser visto na Equac~ao 6.4. Este valor e de 3,57%, o que signica que, da mesma forma que as duas aplicac~oes, o CMF aumentou o tempo de execuc~ao das aplicac~oes em 3,57% na media. 6.5 CONSIDERAC ~OES FINAIS De acordo com o que foi observado na Sec~ao 6.4, a analise das metricas aqui denidas para o CMF apontou para uma reduc~ao na quatidade de linhas de codigo implemetadas e no tempo de desenvolvimento. No entanto, tambem foi observado um aumento no tamanho da aplicac~ao e no tempo de execuc~ao. A Tabela 6.6 mostra estes valores em conjunto, enquanto a Figura 6.5 ilustra este resultado gracamente. (KLOC CCT ) (SM CCT ) (SIZE CCT ) (RUNTIME CCT ) CMF -31,84% -44,78% 8,88% 3,57% Tabela 6.6. Resultado das metricas calculadas para o CMF. Figura 6.5. Resultado da analise das metricas para o CMF Assim, pode-se concluir que o uso do CMF e bastante indicado para que se obtenha uma reduc~ao no esforco de desenvolvimento e na quantidade de linhas de codigo escritas. Para aplicac~oes que o desempenho seja um fator crtico, o uso do CMF deve ser avaliado de acordo com os valores aceitaveis. Da mesma forma, esta avaliac~ao deve ser feita caso o tamanho da aplicac~ao seja muito importante. No entanto, otimizac~oes ainda podem ser feitas no Framework visando a reduc~ao do tempo de execuc~ao e do tamanho da aplicac~ao.