DESENVOLVIMENTO DE IDE PARA PLATAFORMA OMAP
Larissa Lucena Vasconcelos¹, Raul Fernandes Herbster², Joseana Macêdo Fechine³
1 Aluna do Curso de Ciência da Computação, integrante do PET-Computação, Depto. de Sistemas e Computação DSC/UFCG, Campina Grande, PB, e-mail: larissa@dsc.ufcg.edu.br
2 Aluno do Curso de Ciência da Computação, Depto. de Sistemas e Computação DSC/UFCG, Campina Grande, PB, e-mail: raul@dsc.ufcg.edu.br
3 Professora do Depto. de Sistemas e Computação DSC/UFCG, Tutora do PET-Computação, Campina Grande, PB, e-mail: joseana@dsc.ufcg.edu.br
RESUMO
– Desenvolver software trabalhando com uma única interface torna o trabalho mais rápido e menos árduo. Portanto, verificou-se a necessidade do desenvolvimento de um IntegratedDevelopment Environment (IDE) para a plataforma OMAP, integrando as ferramentas existentes
em um único ambiente, e assim, facilitando a tarefa do desenvolvedor de aplicações para a referida plataforma.
ABSTRACT
– Developing software using just one interface makes work become faster and less arduous. Therefore, the necessity of developing an Integrated Development Environment (IDE) for the OMAP platform was verified, generating the integration of some tools in a single environment and facilitating the OMAP platform developer’s task.(Palavras-chave: IDE, OMAP, Eclipse)
1. INTRODUÇÃO
Desenvolver software trabalhando com uma única interface torna o trabalho mais rápido e menos árduo. Entretanto, para plataformas recentemente lançadas, é rara a existência de ferramentas que dêem suporte ao desenvolvimento voltado para aquelas.
O processo de desenvolvimento acaba se tornando mais lento, devido ao uso de ferramentas isoladas, cada uma auxiliando no desempenho de uma dada tarefa, o que obriga o desenvolvedor a mudar constantemente de ambiente e tendo ainda que integrar as tarefas manualmente, dificultando em um nível elevado o seu trabalho.
Portanto, verificou-se a necessidade do desenvolvimento de um Integrated Development
Environment (IDE) para a plataforma OMAP [OMAP], integrando as ferramentas existentes em um
único ambiente, e assim, facilitando a tarefa do desenvolvedor de aplicações para a referida plataforma.
O objetivo deste projeto foi, resumidamente, integrar Eclipse e Scratchbox através de um
plug-in1, utilizando o framework2 CDT/Eclipse [ECLIPSE].
Este projeto fez parte das atividades de pesquisa da autora, seguindo o tripé do Programa PET.
1 Software anexado a um aplicativo ou IDE que acrescenta funcionalidades a este.
2 Estrutura de suporte que pode incluir linguagens de script e bibliotecas de código e que serve de apoio para desenvolvimento de outro projeto.
1.1. Conceitos Básicos
Esta subseção se dedica a descrever alguns conceitos que são de fundamental importância para o entendimento das demais seções.
1.1.1. Integrated Development Environment (IDE)
O ato de programar não é unicamente escrever código fonte. Também é preciso documentar o código, escrever testes, fazer o projeto do software, entre outras tarefas que se revezam durante o período de programação. Quando um programador tem que mudar de ambiente a cada tarefa que ele vai desempenhar, perde-se muito tempo, já que ele deve se adaptar a cada nova interface e ainda gerenciar a integração das mesmas.
Este fato torna difícil a aceitação de uma nova tecnologia, pois além do tempo de aprendizagem da nova tecnologia por parte do programador, este ainda tem que aprender a trabalhar em novos ambientes.
IDE é uma ferramenta que integra várias outras em um ambiente único, facilitando o trabalho do programador. E sendo este ambiente de boa qualidade, o trabalho ficará cada vez mais produtivo.
Eclipse é uma IDE amplamente utilizada atualmente. É escrita em Java e bastante flexível, podendo ser utilizada no desenvolvimento de aplicações para Java, C++, Phyton. Além de possibilitar a integração de ferramentas para, por exemplo, fazer testes de unidade3 do código.
1.1.2. Cross-Compilation
Compilar uma aplicação no processador que vai executá-la pode ser um processo muito dispendioso em termos de tempo. No intuito de minimizar este problema, surgiu recentemente a idéia de compilar o software num processador mais rápido do que o processador que vai executá-lo, porém o processador que compila não o executa nativamente, já que o código foi compilado para uma arquitetura diferente. Esta é a chamada cross-compilation [CROSS-COMPLILATION].
O Scratchbox [SCRATCHBOX] é um cross-compiler toolkit que auxilia no desenvolvimento de software embutido (embarcado) para o sistema operacional Linux. O Scratchbox,, como outros
cross-compilers, além de fazer a cross-compilation, ainda provê um ambiente que emula a
plataforma alvo (que vai executar a aplicação) com todas as características desta, sendo esse tipo de ferramenta muito útil para o desenvolvimento de aplicações embutidas.
1.1.3. OMAP
A plataforma OMAP é destinada a aplicações embutidas, por exemplo: PDA´s (Personal Digital Assistant) e celulares. Processadores desenvolvidos sob esta plataforma comportam aplicações de alto desempenho e baixo consumo de energia, por isso são apropriados para sistemas embutidos. E também suportam tecnologias como Bluetooth, Infravermelho e LAN wireless, através de extensões de hardware [HERBSTER, 2005], ou seja, um hardware adicional que implementa determinada tecnologia.
A seção 2 descreverá, em linhas gerais, o processo de desenvolvimento utilizado durante este projeto. A seção posterior relatará os resultados deste trabalho. A seção 4 discorrrerá sobre conclusões e discussões sobre o projeto e a seção subseqüente versará sobre as referências utilizadas como base para a elaboração do presente artigo.
2. METODOLOGIA
Nesta seção será descrito brevemente o processo de desenvolvimento de software utilizado no trabalho.
O processo foi baseado em XP1 [SAUVÉ], pelas diversas características condizentes com o mesmo, tendo, porém, uma equipe dedicada a testes.
2.1 Equipe
A equipe foi dividida, desempenhando alguns papéis, descritos a seguir. - Cliente
o
Descrever a funcionalidade desejada e se disponibilizar para tirar dúvidas e aprimorar as User Stories (funcionalidades) em qualquer momento;o
Descrever os requisitos não funcionais do software e os testes de aceitação;o
Definir o plano de release de software;o
Escolher User Stories para cada iteração.- Desenvolvedor
o
Ajudar a obter User Stories e requisitos não funcionais junto ao Cliente;o
Durante a fase de planejamento de releases, elaborar um projeto arquitetural;o
Durante o planejamento de releases, estimar, aproximadamente, o tempo de desenvolvimento de User Stories;o
Durante o planejamento de iteração: – Dividir as User Stories em Tarefas– Estimar, com precisão, o tempo de desenvolvimento de Tarefas – Escolher Tarefas para desenvolver;
o Elaborar o esquema lógico dos dados, se necessário.
o Escrever o código das tarefas, incluindo os testes de unidade; o Integrar as tarefas realizadas ao restante do código do projeto;
o
Executar Test Review a pedido do gerente do projeto. - Gerenteo Conduzir as atividades de planejamento;
o
Alocar reviewers de testes;o Avaliar riscos e lidar com aqueles descobertos; o Manter o progresso do projeto.
2.2 Atividades
As atividades realizadas se dividiram em cinco partes apresentadas a seguir.
1.
Planejamento: abrange a escrita de User Stories (funcionalidades), levantamento de requisitos não funcionais, planejamento de releases e de iteração;2. Projeto: se divide em projeto arquitetural e refatoramento constante;
3.
Testes: inclui a elaboração de testes de aceitação4 e de unidade, assegurando que osoftware se comporta de maneira desejada a cada situação testada;
4.
Integração: quando se utiliza o controle de versão, garantindo que o software com o qual o programador vai trabalhar está em sua versão mais atualizada. Assegura-se isto fazendo check-out (adquirir a versão mais atualizada do projeto para desenvolver uma tarefa) antes de iniciar o desenvolvimento e fazendo check-in (atualizar o projeto, acoplando a tarefa que acabou de ser desenvolvida) ao finalizar o desenvolvimento; 4 Testes que definem que tarefa cada módulo do software deve desempenhar quando estiver concluído.5.
Acompanhamento: atividade que assegura a manutenção do progresso do projeto, sendo desempenhada pelo gerente.3. RESULTADOS
O resultado deste trabalho consistiu no desenvolvimento de um plug-in OMAP SDK 1.0, utilizado na plataforma Linux (de preferência uma distribuição Debian), tendo sido desenvolvida para Eclipse 3.1, CDT 3.0 e Scratchbox 0.9.8.
As funcionalidades da versão 0.5 são:
• Criação de um novo projeto OMAP SDK;
•
Geração automática do arquivo Makefile com duas targets (processadores alvo) já definidas;•
Wizard para criação de targets do ambiente Scratchbox;•
Wizard para configuração do protocolo SBRSH;•
Seleção da target ativa no ambiente Scratchbox;•
Execução da aplicação no Scratchbox;• Depuração da aplicação utilizando o GDB ou o GDBServer;
Este plug-in utiliza a plataforma CDT que possui quatro principais plug-ins, sendo cada um destinado a uma tarefa diferente: depuração (C/C++ Debug) que serve para encontrar certos erros de lógica no código; launch [ECLIPSE] que é formado por um conjunto de configurações as
quais possibilitam a particularização do modo de execução de um programa; build, [ECLIPSE]
sendo este um processo que deriva resources (projetos, arquivos e diretórios) de outros resources e/ou atualiza resources já existentes; e core que representa o editor do código, busca de palavras no mesmo, etc.
Na Figura 1 é apresentada a arquitetura deste plug-in (circulada), bem como a sua integração com o Eclipse.
Figura 1 – Arquitetura do Plug-in OMAP SDK [HERBSTER, 2005]. 4. CONSIDERAÇÕES FINAIS
Ao perceber a dificuldade para se trabalhar com uma nova plataforma, principalmente a necessidade de conhecimento sobre todas as ferramentas de apoio ao desenvolvimento para a referida plataforma, decidiu-se desenvolver um SDK para OMAP.
O processo de desenvolvimento foi baseado no já existente XP1, sendo a equipe dividida entre gerente, cliente, desenvolvedor e as atividades definidas como planejamento, projeto, testes, integração e acompanhamento.
O resultado do projeto foi o plug-in OMAP SDK utilizada em Linux e desenvolvido para Eclipse 3.1, CDT 3.0 e Scratchbox 0.9.8.
Alguns problemas foram observados durante o processo de desenvolvimento deste projeto como falta de documentação de ferramentas que foram utilizadas, fase de adaptação com as mesmas e falta de familiarização com os padrões que um código de plug-in do Eclipse deve seguir.
Um possível trabalho futuro seria o desenvolvimento de um plug-in para testes de unidade para C como o CUnit [CUNIT], a exemplo do que já existe para Java, o JUnit [JUNIT].
5. REFERÊNCIAS BIBLIOGRÁFICAS
