ÍNDICE ANALÍTICO. iii

Transcrição

1 ÍNDICE ANALÍTICO 1. INTRODUÇÃO OBJETIVOS DESENVOLVIMENTO (MATERIAIS E MÉTODOS) O AMBIENTE EXPSEE A ARQUITETURA PROPOSTA PARA O EXPSEE A PLATAFORMA LINUX CATEGORIAS DE SOFTWARE LIVRE Free Software e Open Source Public Domain Copylefted Semi-Free Software, Shareware e Freeware RESULTADOS PARCIAIS E DISCUSSÃO MECANISMOS DEFINIDOS PARA IMPLANTAR O EXPSEE NA PLATAFORMA LINUX Linguagem de Programação Construção de Interface com o Usuário (GUI) Padrão de Comunicação Interprocessos Sistema Gerenciador de Banco de Dados EXEMPLO DE MAPEAMENTO OBJETO-RELACIONAL USANDO O OBJECTBRIDGE EXEMPLO DE MANIPULAÇÃO DE OBJETOS GRÁFICOS JAVA COM O JHOTDRAW CONCLUSÕES PARCIAIS REFERÊNCIAS BIBLIOGRÁFICAS DOCUMENTAÇÃO DAS CLASSES IMPLEMENTADAS PARA O SISTEMA EXEMPLO 7.2 REPOSITÓRIO XML COM AS CONFIGURAÇÕES PARA O MAPEAMENTO OBJETO- RELACIONAL UTILIZANDO O OBJECTBRIDGE iii

2 ÍNDICE DE FIGURAS FIGURA 1: ARQUITETURA DE COMPONENTES PROPOSTA PARA O EXPSEE [GIM02] FIGURA 2: CATEGORIAS DE SOFTWARE LIVRE E NÃO-LIVRE [GNU01A] FIGURA 3: ARQUITETURA DA PLATAFORMA JAVA 2 - J2SE 1.4 [SUN02] FIGURA 4: DIAGRAMA DE CLASSES DO JHOTDRAW [JHD02] FIGURA 5: DIAGRAMA DE CLASSES DA APLICAÇÃO EXEMPLO FIGURA 6: ATRIBUTOS DE OBJETOS JAVA MAPEADOS PARA O SGBDR MYSQL FIGURA 7: MANIPULAÇÃO DE OBJETOS GRÁFICOS JAVA COM O OBJECTBRIDGE ÍNDICE DE TABELAS TABELA 1: SQL DAS ENTIDADES DA APLICAÇÃO EXEMPLO TABELA 2: RESUMO DO MAPEAMENTO DOS MECANISMOS SUN SOLARIS E LINUX iv

3 1. INTRODUÇÃO Desde 1994 o grupo de Engenharia de Software da Universidade Estadual de Maringá vem desenvolvendo o ambiente ExPSEE - Experimental Process-centered Software Engineering Environment - sob a coordenação da professora Dra. Itana Maria de Souza Gimenes (DIN-UEM) apoiado por projetos financiados pelo CNPq. Vários artigos nacionais e internacionais, apresentações em congressos, trabalhos de graduação e orientações de mestrado relacionados ao ExPSEE foram realizados [Gim02]. O ExPSEE é um ambiente de engenharia de software que permite a cooperação no desenvolvimento e execução de processos de software e a integração de ferramentas CASE 1. O ambiente visa oferecer uma plataforma experimental para alunos de graduação e pós-graduação, assim como investigar novas tecnologias sobre processos de software e mecanismos para sua modelagem e automação. A versão operacional do ExPSEE vem sendo desenvolvida na plataforma Sun Solaris [Sun01], utilizando o sistema gerenciador de banco de dados orientado a objetos ObjectStore [Obj95], além de outros mecanismos de implementação. Alguns dos mecanismos utilizados na versão atual do ExPSEE são sistemas proprietários e seus custos são altos se comparados a alternativas existentes, como, por exemplo, os mecanismos disponíveis para o sistema operacional Linux [Lin00]. O objetivo deste projeto é pesquisar mecanismos alternativos para se construir uma variante do ExPSEE para a plataforma Linux oferecendo, assim, uma alternativa de custo mais baixo, mais flexível e de fácil manutenção. Este relatório apresenta os estudos realizados e os resultados obtidos com relação à avaliação de mecanismos alternativos para a migração do ExPSEE para a plataforma Linux. 1 CASE - Computer-Aided Software Engineering. 5

4 2. OBJETIVOS Este projeto está dividido em duas etapas principais: a primeira fase, em que será estudado e avaliado o projeto e funcionamento atual do ambiente ExPSEE, e definidos os mecanismos equivalentes para executá-lo na plataforma Linux; e a segunda fase, em que será implementado um protótipo do ambiente na plataforma Linux utilizando os mecanismos definidos na primeira etapa. Será também realizada uma análise das estratégias de continuidade da migração do ambiente para a plataforma Linux. Ao final de cada etapa será feita uma avaliação dos respectivos resultados. A primeira etapa deste projeto tem dois objetivos principais, sendo eles: o estudo e a avaliação do projeto e funcionamento da versão atual do ExPSEE; e o estudo e a definição de recursos equivalentes para a execução do ExPSEE na plataforma Linux. Resumindo, os objetivos da primeira fase do projeto são: estudar e avaliar o projeto e funcionamento atual do ExPSEE; estudar e definir os mecanismos equivalentes para executar o ExPSEE na plataforma Linux; e avaliar os resultados parciais obtidos. 6

5 3. DESENVOLVIMENTO (MATERIAIS E MÉTODOS) Um dos fatores mais importantes no processo de desenvolvimento de software é a qualidade do produto final. Contudo, para se obter tal qualidade, faz-se necessário o emprego de técnicas, recursos e ferramentas nas fases que compõem o ciclo de vida do software. Um exemplo de técnica utilizada é a mensuração de software. O uso de ferramentas CASE durante o processo de desenvolvimento de software contribui muito para o aumento da qualidade do produto. Contudo, um dos problemas no emprego e uso de ferramentas CASE é que geralmente tais ferramentas possuem finalidades diferentes e, dessa forma, acabam sendo utilizadas de forma isolada, sem qualquer tipo de integração. É nesse contexto que surge o Projeto ExPSEE [Gim99a], que propõe um ambiente capaz de integrar ferramentas CASE permitindo a cooperação no desenvolvimento e execução de processos de software. As próximas seções apresentam o ambiente ExPSEE, definições sobre ambientes de engenharia de software, sua arquitetura e a implementação atual. Fez parte da última fase do ExPSEE [Gim02] definir uma arquitetura de software compatível com a arquitetura da WfMC (Workflow Management Coalition) [Wmc01]. Assim, como estratégia de desenvolvimento, temos: o estudo da nova arquitetura do ExPSEE, desenvolvida em projeto paralelo [Gim02] e definida segundo os padrões da WfMC; a implementação de um exemplo mostrando as funcionalidades mais genéricas do framework de manipulação de objetos gráficos; e a implementação de um exemplo utilizando o framework de mapeamento de objetos Java para um SGBDR O AMBIENTE EXPSEE A busca por qualidade no processo de desenvolvimento de software levou os desenvolvedores à produção de ferramentas CASE em larga escala com o intuito de automatizar algumas tarefas como, por exemplo, documentação de projeto e controle de versões. É possível citar várias ferramentas utilizadas durante o processo de software como, por exemplo: Rational Rose [Rat01], usada na modelagem em projetos que 2 SGBDR - Sistema Gerenciador de Banco de Dados Relacional. 7

6 seguem o paradigma de orientação a objetos; e ERWin [Cas01], usada na modelagem de banco de dados. Apesar dessas ferramentas terem sucesso em suas funções, ainda existe a necessidade de integra-las de forma que possam interagir entre si, permitindo o aproveitamento das informações produzidas por cada uma delas e pelas demais bem como permitindo uma maior comunicação entre elas. Os ambientes de engenharia de software - SEE s (Software Engineering Environment) - fornecem mecanismos capazes de suportar a integração de ferramentas CASE, permitindo a redução no esforço e manutenção do processo de desenvolvimento. Um SEE permite que se tenha o controle sobre quando, onde e por quem uma ferramenta poderá ser utilizada. Estas facilidades estão ligadas diretamente à maneira como cada ferramenta se comporta dentro do ambiente e como se comunica com as outras ferramentas [Yan97]. Um SEE deve possuir algumas características básicas [Gim94] como: ser flexível; permitir o reuso de componentes internos; prover o controle de acesso e a evolução de objetos compartilhados; apoiar o controle de versões e configurações; permitir o trabalho cooperativo entre os desenvolvedores; permitir a comunicação entre as ferramentas; e ser extensível. Existem também os chamados PSEE s - Process-centered Software Engineering Environment - que se caracterizam por apoiar a descrição e execução de processos para auxiliar e controlar as atividades envolvidas na produção e manutenção de um software [Gim94]. Os PSEE s baseiam-se na definição explícita do processo por meio do qual os artefatos de software serão concebidos, projetados, desenvolvidos e distribuídos. Estes ambientes utilizam um modelo de processos que permite a descrição de regras, procedimentos, interações entre usuários, artefatos e requisitos. É necessária ainda uma linguagem para definir, especificar e executar o processo. A diferença entre um SEE e um PSEE depende do grau de suporte a processo que o ambiente provê. O projeto ExPSEE visa desenvolver um ambiente de engenharia de software orientado a processo, e vem sendo desenvolvido desde Este projeto estabeleceu uma base de pesquisa na área de ambientes de engenharia de software que permite tanto investigações sobre os mecanismos do ambiente quanto sobre métodos e ferramentas para o desenvolvimento de software. 8

7 O ambiente ExPSEE permite a integração de ferramentas CASE com o intuito de investigar e aplicar novas tecnologias no processo de desenvolvimento de software. O ExPSEE oferece, ainda, mecanismos de apoio a modelagem e automação de processos. Para a construção do ExPSEE na plataforma Sun Solaris [Sun01] foram empregados alguns recursos necessários, divididos em categorias. Os recursos empregados e suas respectivas categorias são: Linguagem de Programação: C++; Ferramentas de Auxílio à Construção de Interface com o Usuário (GUI 3 ): Tcl/TK, Tcl é uma linguagem script simples para desenvolvimento de aplicações de controle e extensão. TK é um toolkit para o sistema X-Window [Ous94]; Padrão de Comunicação Interprocessos: RPC, para a construção de programas distribuídos com chamadas de procedimentos remotos muito similar às chamadas de procedimentos convencionais [Cou95]; Sistema Gerenciador de Banco de Dados: SGBDOO ObjectStore, seguindo o paradigma adotado e a linguagem de programação C++. O ExPSEE segue o paradigma de orientação a objetos, e sua modelagem utilizou a notação UML (Unified Modeling Language) [Omg01]. O ExPSEE possui três subsistemas principais [Uku98]: Gerenciamento de Processos: contém as classes do gerenciador de processos de software do ambiente; Gerenciamento de Banco de Dados: são os serviços realizados pelo SGBDOO ObjectStore [Obj95]; Gerenciamento de Interface: contém um conjunto de interfaces utilizadas pelo gerenciador de processos para fazer a comunicação com o usuário. O gerenciador de processos do ExPSSE baseia-se no padrão Process Manager [Wei98]. Este gerenciador é o subsistema mais importante dentre os três citados, pois este é responsável por controlar a criação, modificação e execução dos processos de software, dando manutenção ao estado atual de cada tarefa e do processo como um todo. O gerenciador de processos também controla a disponibilidade de alocação de recursos 3 GUI - Graphical User Interface 9

8 utilizados nas tarefas, bem como o controle dos cargos do processo, assegurando que nenhum direito seja violado [Gim99b]. O gerenciador de processos do ExPSEE é composto por vários módulos gerenciadores, que interagem entre si e comunicam-se com o SGBDOO ObjectStore. O gerenciador de arquiteturas de processo é responsável pelo controle e gerenciamento da construção e manutenção de arquiteturas de processo de software e sua instanciação através da definição de processos de software. Este gerenciador possui duas interfaces com o usuário: O Process Architecture Builder, responsável pela definição de arquiteturas de processo; e o Project Manager, responsável pela criação e gerenciamento de projetos de software, através da instanciação e execução desses processos. Após o processo de software ter sido instanciado, as tarefas deste processo já podem ser programadas. As tarefas, inicialmente, estão no estado instanciada. No ExPSEE, cada tarefa passa por um conjunto de estados, desde o estado inicial instanciada até o estado final terminada. O gerenciador de atores é responsável pelo controle e gerenciamento dos atores existentes no sistema e envolvidos nos processos de software. Este módulo possui algumas funções, como cadastramento, alterações e remoção de atores do sistema e alocação de atores para ocupar cargos em processos de software e desempenhar as tarefas relacionadas a esses cargos. O gerenciador de ferramentas é responsável pelo controle e gerenciamento das ferramentas existentes no sistema e envolvidas nos processos de software. Este módulo possui algumas funções, como: cadastramento, alterações e remoção de ferramentas do sistema e alocação de ferramentas para serem usadas na execução de tarefas em processos de software. As funções relacionadas aos cadastros das ferramentas são requisitadas pelo usuário através de sua interface, o System Tool Manager. Os demais módulos do gerenciador de processos e suas funções são: gerenciador de tarefas: responsável pelo controle e gerenciamento das tarefas e ações a serem realizadas no processo de software; gerenciador de artefatos: responsável pelo controle e gerenciamento dos artefatos utilizados e produzidos pelas tarefas através das ferramentas; gerenciador de cargos: responsável pelo controle e gerenciamento dos cargos existentes no processo de software a serem ocupados pelos atores presentes no processo; e 10

9 gerenciador de ações: responsável pelo controle e gerenciamento das ações que as ferramentas desempenham sobre os artefatos do processo de software. 3.2 A ARQUITETURA PROPOSTA PARA O EXPSEE Em sua terceira fase, o Projeto ExPSEE teve a arquitetura do seu ambiente concebida de forma compatível à arquitetura da WfMC, baseada em componentes [Gim02]. Esta arquitetura de componentes proposta tomou como base o padrão Process Manager [Wei98], e serve para orientar o projeto interno e a integração dos componentes do ambiente ExPSEE. Esta arquitetura contém informações importantes sobre o domínio em que ela atua, tais como características dos relacionamentos entre os componentes e ainda informações sobre integração do sistema como um todo. A arquitetura de componentes proposta para o ambiente ExPSEE é mostrada na Figura 1. A notação de arquitetura de componentes adotada foi o Diagrama de Componentes de Chessman e Daniels [Che01]. Extern Application Manager IInvokeExternApplicationMgt Process Architecture Manager ICreateArchitectureMgt ISelectArchitectureMgt IObjectStoreMgt IInstantiateArchitectureMgt Object Manager Project Manager IProgramTaskMgt ISelectResourceMgt Graphic Interface Manager Resource Allocation Manager IAllocateResourceMgt IScheduleTaskMgt Interpreter IExecuteScriptMgt Task Scheduler IExecuteTaskMgt Figura 1: Arquitetura de Componentes Proposta para o ExPSEE [Gim02]. Esta arquitetura é formada pelos seguintes componentes [Gim02]: GraphicInterface - responsável pela interação do usuário com o sistema gerenciador de processos; 11

10 ProcessArchitectureMgr - responsável pelo controle e gerenciamento da construção e manutenção de arquiteturas de processo de software; ProjectMgr - responsável pela criação e gerenciamento de projetos de software, através da instanciação e execução desses processos; TaskScheduler - responsável pelo controle e gerenciamento das tarefas e ações a serem realizadas no processo de software; ResourceAllocationMgr - responsável pela alocação de recursos necessários como, por exemplo, atores, ferramentas e artefatos, na realização dos projetos; ExternApplicationMgr - responsável pelo gerenciamento das aplicações externas invocadas durante a definição e execução de um processo; ObjectMgr - responsável pelo relacionamento com o sistema gerenciador de banco de dados; Interpreter - permite a linguagem de programação de processos executar as tarefas através do gerenciador de tarefas. Uma descrição mais detalhada de cada um dos componentes e suas respectivas interfaces e métodos pode ser encontrada em [Gim02]. 3.3 A PLATAFORMA LINUX O Linux nasceu no inicio da década 90, quando um estudante, Linus Torvalds do Departamento de Ciência da Computação da Universidade de Helsinki na Finlândia, estava insatisfeito com o DOS/Windows. Assim, ele simplesmente resolveu construir um sistema operacional alternativo para o seu microcomputador 386. No início, o kernel projetado baseava-se no Minix (versão simples para fins educacionais do UNIX), e precisava do Minix para ser executado [Min96]. Porém, ajudado por muitos voluntários, Linus conseguiu criar um kernel próprio, sem ser baseado nas demais versões do UNIX. O código fonte resultante é estável, rápido e poderoso [Com02]. Escrito o kernel houve a necessidade de construir um conjunto de aplicativos e bibliotecas para poder formar um sistema operacional completo. Muitos destes aplicativos já existiam, na época, devido ao Projeto GNU [Gnu01a]. Existiam, ainda, muitos outros aplicativos que funcionavam em ambientes UNIX, mas em plataformas proprietárias como Sun Solaris, HP-UX e AIX. 12

11 O fundamento do Linux é o código aberto (Free Software ou Open Source, discutidos na próxima Seção). A disponibilidade do código-fonte de alguns sistemas possibilitou a criação de um sistema operacional robusto, versátil e de fácil utilização [Com02]. Algumas características da plataforma Linux são: implementação independente da especificação POSIX, com a qual todas as versões do UNIX padrão estão convencionadas; desenvolvido para PCs baseados em processadores 386/486/Pentium, mas atualmente também roda em computadores Alpha da DEC, Sparcs da SUN, máquinas M68000, MIPS e PowerPCs; escrito inteiramente sem o uso de código proprietário em seu interior; disponível na forma de código objeto, bem como em código fonte; O Linux pode ser livremente distribuído nos termos da GNU General Public License [Gnu01d]; O Linux possui todas as características que o usuário pode esperar de um UNIX moderno, incluindo: multitarefa real; memória virtual; biblioteca compartilhada; Demand loading ; gerenciamento de memória próprio; executáveis copy-onwrite compartilhados; rede TCP/IP (incluindo SLIP/PPP/ISDN); e X Windows. Vários setores estão adotando a plataforma Linux como uma alternativa de custos de manutenção menores como, por exemplo, a companhia que administra os metrôs da capital de São Paulo, que recentemente adotou tal plataforma e seus aplicativos disponíveis. Outro exemplo é a proposta do Projeto Software Livre do Governo do Estado do Rio Grande do Sul [Pro02], que criou leis para que os órgãos públicos do estado adotem plataformas não-proprietárias, como a plataforma Linux e seus aplicativos, com o intuito de diminuir os gastos com pagamento de licenças de softwares e plataformas, além de suas manutenções. Segundo o The Linux Counter Project [Cou02], uma organização sem propósitos lucrativos criada em maio de 1999, existem hoje cerca de usuários e desenvolvedores registrados da plataforma Linux no mundo inteiro, o que é um número bastante expressivo. Atualmente existem os mais variados tipos de aplicações desenvolvidas para a plataforma Linux, que vão desde clientes de até servidores de impressão e web 13

12 servers. Isto contribui muito para a migração de aplicações desenvolvidas para rodarem em plataformas proprietárias para a plataforma Linux. Além disso, existem várias distribuições Linux, dentre as quais podemos citar: Caldera; Conectiva, distribuição brasileira [Con01]; Debian; Mandrake; RedHat; Slackware; Suse; TechLinux; e TurboLinux. Algumas diferenças entre as distribuições são [Com02]: Estrutura dos diretórios: atualmente todas as distribuições Linux seguem um mesmo padrão, o FHS (File HierarchySystem); Biblioteca básica Libc: contém funções básicas para o funcionamento do sistema operacional Linux. Quando uma nova versão da Libc é lançada, algumas distribuições adotam a nova versão, enquanto que outras são mais conservadoras, e conseqüentemente alguns programas podem funcionar em algumas distribuições e não funcionar em outras. Com relação a esses itens, existe um movimento chamado LSB (Linux Standard Base) que propõe uma padronização maior. Isso ajuda especialmente os vendedores de produtos de software que não distribuem o código fonte dos programas, mas sem eliminar as características próprias das distribuições. O sistema de pacotes, por exemplo, não vai ser padronizado. Visto todas estas características, acredita-se que a plataforma Linux seja ideal para a migração do ExPSEE, já que esta vai ao encontro dos propósitos deste projeto que é a utilização somente de mecanismos open source para a construção, execução e disponibilidade do ambiente ExPSEE. Acredita-se, ainda, que a plataforma Linux continuará em constante ascensão, permitindo que cada vez mais projetos possam ser desenvolvidos de forma que o conceito open source possa se difundir ainda mais, contribuindo com o avanço e descoberta de novas tecnologias. Os conceitos relacionados a free software, open source, entre outros, serão discutidos na Seção a seguir. 3.4 CATEGORIAS DE SOFTWARE LIVRE Existem vários mecanismos não proprietários disponíveis para a plataforma Linux, mas cada um enquadra-se em uma categoria de software, com características e 14

13 restrições de uso diferentes. Dessa forma, é necessária uma discussão a respeito de tais categorias, mostrando suas características principais. A Figura 2 apresenta as categorias de software livre e não-livre. Pode-se observar na Figura 2 que os termos free software e open source abrangem as mesmas categorias. A seguir são descritos os termos e as categorias de software livre. Figura 2: Categorias de Software Livre e Não-Livre [Gnu01a] FREE SOFTWARE E OPEN SOURCE Segundo o Projeto GNU, free software é o software que o usuário tem a liberdade de executar, copiar, distribuir, estudar, modificar e melhorar [Gnu01b]. Mais precisamente, o usuário do software possui os seguintes direitos: liberdade de executar o programa, para qualquer propósito; liberdade de estudar como o programa funciona, e adaptá-lo às suas necessidades. A pré-condição para isso é o acesso ao código do programa; liberdade de redistribuir cópias; e liberdade de melhorar o programa, e distribuir as melhorias ao público para o benefício de toda a comunidade. A pré-condição para isso é o acesso ao código do programa. 15

14 Um programa é considerado free software se os seus usuários possuírem todos esses direitos. O usuário está livre para redistribuir cópias, com ou sem modificações, de forma gratuita ou exigindo uma taxa para a sua distribuição, a qualquer um e em qualquer lugar. Isto significa que o usuário não precisa requisitar ou pagar pelo uso do software. O usuário também tem a liberdade de fazer mudanças e usá-lo de forma privada, sem ao menos mencionar que o software utilizado existe. Se o usuário publicar suas mudanças, ele não é requisitado a notificar tais mudanças. Um outro termo muito utilizado pela comunidade é Open Source. Este termo abrange os mesmos critérios que o termo free software. Segundo a definição [Ope01], open source não significa apenas acesso ao código-fonte. Os termos de distribuição de software open source devem obedecer aos seguintes critérios: Redistribuição Livre: a licença não deve restringir nenhuma parte de vender ou oferecer o software como um componente de uma distribuição de software agregado contendo programas de várias fontes diferentes. A licença não deve exigir um royalty ou outra taxa para tal venda; Código Fonte: o programa deve incluir o código fonte, e deve permitir a distribuição tanto na forma de código fonte como compilada; Trabalhos Derivados: a licença deve permitir modificações e trabalhos derivados, além de sua distribuição sob os mesmos termos da licença do software original; Integridade do Código Fonte do Autor: a licença pode restringir o código fonte de ser distribuído em forma modificada somente se a licença permitir a distribuição de arquivos de patch com o código fonte com o propósito de modificar o programa em tempo de compilação. A licença deve explicitamente permitir a distribuição de software construído a partir do código fonte modificado. A licença pode exigir que trabalhos derivados tenham um nome ou versão diferente dos do software original; Sem Discriminação Contra Pessoas ou Grupos: a licença não deve discriminar contra nenhuma pessoa ou grupo de pessoas; Sem Discriminação Contra Campos de Trabalho: a licença não deve restringir ninguém de fazer uso do programa em um campo específico de 16

15 trabalho. Por exemplo, ela não pode restringir o programa de ser usado em uma empresa, ou de ser usado para pesquisa genética; Distribuição da Licença: os direitos atribuídos ao programa devem ser aplicados a todos a quem o programa for redistribuído sem a necessidade da execução de uma licença adicional por essas partes; A Licença Não Deve Ser Específica a um Produto: os direitos atribuídos ao programa não podem depender do programa ser parte de uma distribuição de software em particular. Se o programa for extraído dessa distribuição e usado ou distribuído dentro dos termos da licença, todas as partes do programa redistribuído devem ter os mesmos direitos quanto àqueles que são garantidos junto com a distribuição do software original; A Licença Não Deve Restringir Outro Software: a licença não deve ter restrições a outro software que é distribuído junto com o software licenciado. Por exemplo, a licença não deve exigir que todos os programas distribuídos em um mesmo meio devem ser open source PUBLIC DOMAIN Um software public domain é um software que o usuário não precisa adquirir seus direitos autorais. É um caso especial de non-copylefted free software, o que significa que algumas cópias ou versões modificadas podem não ser livres de alguma maneira. É comum pessoas usarem o termo public domain com a intenção de estarem se referindo a free software ou software disponível de forma gratuita. Contudo, public domain é um termo legal e significa precisamente not copyrighted [Gnu01a]. Outra categoria importante é a Copylefted ( direitos revertidos ). Um software copylefted é um free software cujos termos de distribuição não permitem que o redistribuidor adicione qualquer restrição ao redistribuir ou modificar o software. Isto significa que toda cópia do software, mesmo se modificada, deve ser free software. Este é um tipo de licença que garante a gratuidade do software, mesmo que este seja modificado várias vezes [Gnu01c]. 17

16 COPYLEFTED Copylefted é um conceito genérico que inclui três outras categorias: GPL (General Public Licence), LGPL (Lesser General Public Licence) e GFDL (General Free Documentation Licence). A licença do tipo GNU GPL [Gnu01d] garante a liberdade de compartilhar e alterar produtos de software livres, garantindo que o software será livre e gratuito para os seus usuários. Esta Licença Pública Geral aplica-se à maioria dos produtos de software da FSF (Free Software Foundation) [Fsf01] e a qualquer outro programa cujo autor decida aplicá-la. A GPL foi desenvolvida para garantir que: o usuário tenha a liberdade de distribuir cópias de software livre e cobrar por isso, se quiser; o usuário receba o código fonte ou tenha acesso a ele, se quiser; o usuário possa mudar o software ou utilizar partes dele em novos programas livres e gratuitos. A licença do tipo LGPL [Gnu01e] é baseada na GPL, sua ancestral. A LGPL é chamada de lesser, pois dá menos liberdade ao usuário do que a GPL. Isto dá aos desenvolvedores de produtos de software livres menos vantagens sobre programas proprietários. As desvantagens do uso da LGPL são a razão para se usar mais a GPL, contudo, a LGPL provê vantagens em certas circunstâncias. Por exemplo, em raras ocasiões, pode acontecer um amplo uso de uma determinada biblioteca livre, tornando-a padrão. Dessa forma, programas proprietários devem permitir o uso de tal biblioteca. Outro exemplo é quando uma biblioteca livre possui as mesmas funcionalidades do que uma biblioteca proprietária amplamente usada. Neste caso, há pouco lucro limitando a biblioteca livre ao software livre SEMI-FREE SOFTWARE, SHAREWARE E FREEWARE Existem outros três termos também importantes e bastante utilizados pela comunidade: semi-free software, shareware e freeware. O emprego destes termos normalmente gera algumas confusões e contradições. Um semi-free software [Gnu01a] é o software que não é free software, mas permite aos usuários copiar, distribuir e modificar, incluindo distribuições de versões 18

17 modificadas, desde que este não tenha um propósito lucrativo. Segundo o projeto GNU, o software semi-free é muito melhor que o software proprietário, porém os usuários não podem usa-lo em um sistema operacional free. É impossível incluir um software semi-free em um sistema operacional free, pois os termos de distribuição para o sistema operacional, como um todo, são o conjunto de termos de distribuição de todos os programas contidos no sistema operacional. Adicionando um programa semi-free a um sistema tornaria tal sistema inteiro semi-free. Um software shareware [Gnu01a] é um software que permite aos usuários redistribuir cópias, porém qualquer pessoa que continuar a usar tais cópias deve pagar uma taxa por sua licença de uso. Shareware não é free software nem semi-free software, devido a duas razões: na maioria dos softwares, o código-fonte não está disponível. Sendo assim, o usuário não pode modificar o programa; o software shareware não possui permissão para ser copiado e instalado sem que se pague uma taxa por sua licença, mesmo que este seja usado em atividades não-lucrativas. Segundo o projeto GNU, o termo freeware [Gnu01a] não possui uma definição clara aceita, mas é comumente usada para programas que permitem redistribuição, mas não permitem modificação, além de não dispor do código-fonte. Um software freeware não é um free software, porém muitas pessoas confundem seu significado e acabam usando o termo freeware, referindo-se a free software. Os dois termos são parecidos, mas possuem significados totalmente divergentes. 19

18 4. RESULTADOS PARCIAIS E DISCUSSÃO Como já citado na Seção 2, um dos objetivos fundamentais da primeira etapa deste projeto foi o estudo e a definição de mecanismos equivalentes aos já utilizados na implementação do ExPSEE na plataforma Sun Solaris para que seja possível portar o ambiente para a plataforma Linux. Vários mecanismos foram estudados e avaliados, possibilitando uma análise acerca dos mecanismos disponíveis seguindo o conceito de open source. Como visto na Seção 3.4, isto acontece devido ao fato de que se utilizarmos somente mecanismos open source, o ExPSEE se tornará um ambiente também open source, o que vai ao encontro dos objetivos pré-estabelecidos para este projeto. Após tais estudos e avaliações foram definidos os mecanismos capazes de implementar e executar o ExPSEE na plataforma Linux. Dessa forma, temos como resultado principal, da primeira etapa deste projeto, a definição dos mecanismos para implementar e executar o ExPSEE na plataforma Linux. Como estratégia de escolha de tais mecanismos, foram implementados exemplos de utilização dos frameworks ObJectBridge e JHotDraw. A Seção 4.1 apresenta os mecanismos definidos e que serão empregados para a construção da versão do ExPSEE para Linux. A Seção 4.2 apresenta um exemplo de utilização do ObJectBridge, enquanto a Seção 4.3 apresenta um exemplo de utilização do JHotDraw. 4.1 MECANISMOS DEFINIDOS PARA IMPLANTAR O EXPSEE NA PLATAFORMA LINUX Os mecanismos necessários para implementar e executar o ExPSEE na plataforma Linux, assim como os necessários para se construir um SEE, foram divididos em quatro categorias principais: linguagem de programação; construção de interface com o usuário (GUI); padrão de comunicação interprocessos; e sistema gerenciador de banco de dados. A seguir são apresentados tais mecanismos em suas respectivas categorias. A versão open source do ambiente ExPSEE, assim como a versão atual, seguirá o paradigma de orientação a objetos. 20

19 4.1.1 LINGUAGEM DE PROGRAMAÇÃO A linguagem de programação definida para implementar o ExPSEE foi Java. Java faz parte de uma tecnologia emergente no mercado mundial e dispõe de uma série de recursos para utilização em aplicações tanto científicas quanto comerciais. Os estudos realizados [Sun02] e a aceitação da comunidade acadêmica a respeito desta tecnologia, indicam que Java pode ser utilizada na migração do ExPSEE para a plataforma Linux. A linguagem Java é totalmente orientada a objetos, sobrepondo-se à linguagem utilizada para implementação da versão atual do ExPSEE, o C++. Além disso, Java possui um estenso toolkit, o Swing, que permite a implementação de interfaces gráficas com o usuário através de vários componentes dinâmicos. Outro ponto muito importante é que Java é uma linguagem de domínio público. Além disso, existem vários ambientes de desenvolvimento baseados em Java que também são de domínio público. Java pode também manipular alguns mecanismos de comunicação interprocessos existentes como CORBA [Omg01] e/ou RMI [Sun02]. A Figura 3 apresenta a arquitetura da plataforma padrão Java 2. Esta arquitetura é composta por uma série de API s e toolkits, dentre as quais pode-se citar: API s JDBC e RMI; e toolkits Java 2D, Swing, e AWT. Figura 3: Arquitetura da Plataforma Java 2 - J2SE 1.4 [Sun02]. 21

20 4.1.2 CONSTRUÇÃO DE INTERFACE COM O USUÁRIO (GUI) Para a construção das interfaces gráficas com os usuários será utilizado o toolkit Swing [Sun02] pertencente à plataforma Java 2. Swing passou a ser a biblioteca padrão para a construção de GUI s a partir da plataforma Java 2 substituindo a antiga biblioteca AWT (Abstract Window Toolkit). A AWT deixou de ser atualizada, passando somente a fazer parte da plataforma Java 2. Visto que a biblioteca Swing está sendo constantemente atualizada e que esta possui uma ampla coleção de elementos gráficos que permitem a interação com os usuários, optou-se por utilizá-la na construção de GUI s para o protótipo do ambiente ExPSEE. O ExPSEE possui interfaces em que há a necessidade de se manipular objetos gráficos que representam elementos de processo de software. O toolkit Swing não possui suporte a objetos gráficos como elipses, retângulos, entre outros. Dessa forma, optou-se por utilizar o framework JHotDraw [Jhd02]. O JHotDraw é um framework baseado em dois predecessores: o HotDraw [Hot99] e o ET++, construído com o intuito de manipular objetos gráficos em aplicações Java. A Figura 4 apresenta o diagrama de classes do JHotDraw, mostrando suas interfaces principais, representadas por retângulos sombreados, e seus respectivos relacionamentos. Figura 4: Diagrama de Classes do JHotDraw [Jhd02]. 22

21 O toolkit Java 2D da plataforma Java 2 deixa a desejar no que diz respeito à manipulação dos objetos criados. Este toolkit simplesmente dispõe de operações para criar e acessar os objetos gráficos, porém não dão o suporte desejável aos tipos de objetos que o ExPSEE exige. Sendo assim, optou-se por utilizar o JHotDraw para auxiliar na manipulação dos objetos Java durante a construção e utilização do ambiente ExPSEE, devido às suas funcionalidades disponíveis PADRÃO DE COMUNICAÇÃO INTERPROCESSOS A arquitetura do ExPSEE foi redefinida, como visto na Seção 3.3, baseando-se na arquitetura da WfMC [Wmc01] e, dessa forma, caracterizando-se por ser uma arquitetura distribuída. Para implementar o ExPSEE de forma que este possa estar de acordo com esta nova arquitetura é necessário utilizar um mecanismo que faça a comunicação dos vários processos distribuídos na rede. Sendo assim, optou-se por seguir o padrão de arquitetura CORBA [Omg01] para a comunicação interprocessos utilizando-se, para isso, o produto CORBA JacORB [Jac01], que é um ORB (Object Request Broker) implementado em Java. Uma das maiores vantagens de seguir o padrão CORBA é a possibilidade de no futuro, caso seja necessário, integrar ao ExPSEE outros módulos escritos em linguagens diferentes. Uma outra vantagem é a possível substituição do ORB (no caso o JacORB) futuramente caso este não satisfaça alguns requisitos do ExPSEE em projetos futuros. Algumas funcionalidades do JacORB, encontradas em [Jac01], tais como: alto desempenho; ORB totalmente multithread; o compilador IDL suporta mapeamento para a linguagem Java; DII (Dynamic Invocation Interface) e DSI (Dynamic Skeleton Interface); OMG Interoperable Naming Service; serviço de transação, coleções e concorrência; suporte a CORBA 2.3; repositório de interfaces; 100% Java, compatível com JDK 1.2 ou superior. 23

22 4.1.4 SISTEMA GERENCIADOR DE BANCO DE DADOS Um dos principais mecanismos definidos na primeira fase deste projeto é a forma de armazenamento persistente dos objetos disponibilizados pelo ExPSEE. Tratando-se do paradigma de orientação a objetos, temos três alternativas consideráveis neste projeto para executar tal tarefa: 1. utilizar um SGBDOO 4 ; 2. utilizar o mecanismo de serialização de objetos, disponível na tecnologia Java; 3. utilizar um framework ou um mecanismo que faça o mapeamento dos objetos para uma base de dados relacional ou objeto-relacional. Existe uma série de vantagens e desvantagens dentre as alternativas apresentadas acima, o que nos levou a examinar, de forma minuciosa, cada uma delas a fim de estabelecer a que mais se aproxima às condições e metas deste projeto. A tarefa de encontrar um SGBDOO disponível mostrou-se difícil, visto que este projeto pretende utilizar somente mecanismos open source que possam ser executados na plataforma Linux. Esta tarefa se torna ainda mais difícil quando são exigidos mecanismos de controle de transações e de acesso de usuários por parte do SGBD. Dessa forma, foram encontrados somente recursos proprietários com tais características. A serialização [Sun02] de objetos Java armazena os objetos na sua forma nativa, sem que haja a necessidade de algum tipo de mapeamento. É necessário, porém, que o objeto implemente a interface java.io.serializable [Sun02], disponível na Plataforma Java 2 [Sun02]. O que dificulta a utilização deste tipo de recurso é a falta de mecanismos de gerenciamento de transações e de usuários, visto que a base de dados é criada na forma de sistema de arquivos. Os objetos são agrupados em um Stream 5 dentro de determinado arquivo. A última alternativa foi a utilização de um mecanismo capaz de mapear os objetos para bases relacionais ou objeto-relacionais. Existem vários frameworks disponíveis para realizar tal tarefa. A grande maioria deles está disponibilizada na forma de projetos open source o que vai ao encontro das expectativas deste projeto. Alguns 4 SGBDOO - Sistema Gerenciador de Banco de Dados Orientado a Objetos. 5 Stream - meio no qual dados ou bytes são armazenados de forma seqüencial. 24

23 frameworks podem ser facilmente encontrados na Web [Sou01]. Alguns destes mecanismos, tal como o ObJectBridge [Ojb01], foram desenvolvidos possibilitando sua utilização em aplicações distribuídas, possuindo controle de transações e acesso de usuários. A maior vantagem de se utilizar uma base relacional como, por exemplo, o MySQL, é o ganho de desempenho em consultas, armazenamento e recuperação de dados. Além disso, alguns sistemas de gerenciamento de bancos de dados relacionais acompanham algumas distribuições da plataforma Linux, como é o caso da distribuição Conectiva Linux 7.0 [Con01], que inclui, entre seus diversos pacotes, o MySQL, o InstantDB e o PostgreSQL (objeto-relacional), sem contar com a possibilidade de se trabalhar com uma linguagem de consulta estruturada como a SQL (Structured Query Language). Inicialmente estudou-se a utilização de um SGBDOO. Fez-se necessária, então, uma pesquisa em busca de um sistema não proprietário, que pudesse ser executado na plataforma Linux e que permitisse o armazenamento de objetos Java. Foram encontrados alguns sistemas de gerenciamento de banco de dados orientados a objetos open source que estavam de acordo com tais características, porém, todos estes sistemas estavam em fase inicial de implementação, alguns até possuindo características como controle de acesso por usuários, e execução remota. Sendo assim, percebeu-se que a maior dificuldade residiria na adoção de um destes sistemas e a possibilidade deste ser descontinuado, comprometendo, assim, a futura execução e manutenção do mecanismo de persistência do ExPSEE. Passou-se a analisar a utilização do mecanismo de serialização de objetos disponível na Plataforma Java 2. A serialização de objetos é uma forma bastante prática de armazenar e recuperar, de forma persistente, os objetos instanciados em aplicações Java. A chave para serializar um objeto é a capacidade de representar, de forma suficiente, o estado do objeto. Quando um objeto é serializado, este é colocado em um Stream, e este Stream (pode ser de saída ou de entrada) é então salvo em um arquivo, ou seja, os objetos são armazenados na forma de sistemas de arquivos. Sendo assim, pode-se ter alguns problemas ao se utilizar a serialização de objetos Java em um sistema onde existe a necessidade de controlar o acesso por usuários e implementar transações. Alguns destes problemas podem ser citados: 25

24 o ExPSEE possui diversos tipos de objetos que se relacionam entre si de formas diferentes (1:1, 1:n, m:n) o que tornará o controle destes objetos um tanto quanto complexo ou talvez nem haja a possibilidade de fazer tal controle; falta de mecanismos para travar (lock) os arquivos onde os objetos estão armazenados; não se sabe até onde o mecanismo de serialização possui um desempenho melhor do que o de um SGBDR quando em um número suficientemente grande de objetos (informações) armazenados. Dessa forma, torna-se difícil utilizar a serialização para armazenar objetos, visto que se ganha em praticidade, mas perde-se em performance e eficácia. A utilização de mapeamento objeto-relacional mostrou ser a forma mais adequada de armazenamento persistente de objetos, devido às vantagens encontradas na utilização de um SGBDR como, por exemplo, o ganho de desempenho em consultas, armazenamento e recuperação de dados. Além disso, existem vários frameworks de mapeamento e SGBDR open source. Passou-se a pesquisar tais mecanismos e foram encontrados alguns frameworks que executam tal tarefa para objetos Java. Dentre os framewroks analisados o que mais se destacou, devido às suas características, foi o ObJectBridge. Este framework caracteriza-se por [Ojb01]: dispor de API s de acordo com: ODMG 3.0, JDO e API PersistenceBroker que serve como o kernel persistence do OJB; poder ser usado de duas maneiras: o StandAlone: mesma JVM (Java Virtual Machine) da aplicação cliente; ou o Cliente/servidor: diferentes JVM s fazer mapeamento Objeto-Relacional baseado em XML (Extended Markup Language); suportar BMP (Bean Managed EntityBean), usado para melhorar o desempenho de aplicações de Enterprise Java Beans; a API PersistenceBroker permitir armazenar e recuperar objetos Java de e para JDBCs (Java Database Connectivity) para SGBDR s; permitir que todos os objetos associados ao objeto persistente sejam também persistidos; 26

25 suportar mapeamento para 1:1, 1:n e m:n; possuir associação automática de foreign key; suportar polimorfismo e extensões ODMG; dar suporte para atributos Java Array e Collection em classes persistentes; ser 100 % Java, Open Source. Como o ObJectBridge permite, teoricamente, mapear objetos Java para qualquer SGBDR (dependendo somente da geração de índice de cada SGBDR) tem-se as seguintes vantagens: utilizar SQL (Structured Query Language) ou OQL (Object query Language); maior desempenho em consultas; possibilidade de acesso remoto à base de dados; controle de transações, o que alguns SGBDR s não possuem. Sendo assim, optou-se, inicialmente, pela terceira alternativa, utilizando-se o ObJectBridge para mapear os objetos Java para o SGBDR MySQL [Mys01]. A Seção 4.2 apresenta um exemplo de uso do ObJectBridge, mostrando as configurações para que seja possível mapear objetos Java para o SGBDR MySQL. Além disso, este exemplo mostra como são configuradas as entidades permitindo todos os tipos de associações, Java Collection e Array, além de herança e polimorfismo. 4.2 EXEMPLO DE MAPEAMENTO OBJETO-RELACIONAL USANDO O OBJECTBRIDGE Para exemplificar a utilização do ObJectBridge no mapeamento de objetos Java para o SGBDR MySQL foi implementado um exemplo onde é possível perceber algumas características importantes, como: associações do tipo 1:1, 1:n e m:n, sendo que a terceira associação é a mais difícil de ser implementada em SGBDR s; herança; polimorfismo; entre outras. Esta aplicação exemplo foi implementada de forma standalone, ou seja, o ObJectBridge é executado na mesma máquina virtual da aplicação Java. É possível, porém, implementar aplicações Java distribuídas em máquinas virtuais diferentes. A Figura 5 apresenta o diagrama de classes da aplicação exemplo implementado. A documentação das classes implementadas para esta aplicação exemplo encontra-se em anexo. 27

26 ID_Phone : int Client addaddress(address : Address) : void setphone(phone : Phone) : void getaddresses() : Vector getphone() : Phone Client() Client(id : int, name : String, age : int, idphone : int) String ID_Phone : int ID_Person : int name : String age : int Person setname(name : String) : void setage(age : int) : void getname() : String getage() : int Person() Person(id : int, name : String, age : int) Vendor setphone(phone : Phone) : void set ( String) : void get () : String getphone() : Phone Vendor() Vendor(id : int, name : String, age : int, String, idphone : int) -phone String ID_Phone : int Project ID_Project : int title : String description : String setprojecttitle(title : String) : void setdescription(desc : String) : void adddeveloper(developer : Developer) : void getprojecttitle() : String getdescription() : String getdevelopers() : Vector Project() Project(id : int, title : String, desc : String) 0..n -developers 0..n -projects Developer set ( String) : void setphone(phone : Phone) : void addproject(project : Project) : void getphone() : Phone get () : String getprojects() : Vector Developer() Developer(id : int, name : String, age : int, String, idphone : int) -addresses 0..n -phone phone 0..1 ID_Address : int street : String number : String zipcode : String city : String state : String country : String Address setstreet(street : String) : void setnumber(number : String) : void setzipcode(zipcode : String) : void setcity(city : String) : void setstate(state : String) : void setcountry(country : String) : void getstreet() : String getnumber() : String getzipcode() : String getcity() : String getstate() : String getcountry() : String Address() Address(id : int, street : String, number : String, zipcode : String, city : String, state : String, country : String) ID_Phone : int ddi : String ddd : String number : String ramal : String Phone setddi(ddi : String) : void setddd(ddd : String) : void setnumber(number : String) : void setramal(ramal : String) : void getphonenumber() : String Phone() Phone(id : int, ddi : String, ddd : String, number : String, ramal : String) Figura 5: Diagrama de Classes da Aplicação Exemplo. 28

27 A Tabela 1 apresenta o código DDL (Data-Defintion Language) SQL das entidades necessárias para o armazenamento dos objetos Java através do ObJectBridge. Tabela 1: SQL das Entidades da Aplicação Exemplo. CREATE TABLE PERSON ( ID integer NOT NULL, NAME varchar(50), AGE integer, PRIMARY KEY (ID) ); CREATE TABLE ADDRESS ( ID integer NOT NULL, ID_CLIENT integer, STREET varchar(50), NUMBER varchar(50), ZIPCODE varchar(50), CITY varchar(50), STATE varchar(50), COUNTRY varchar(50), PRIMARY KEY (ID) ); CREATE TABLE PHONE ( ID integer NOT NULL, DDI varchar(50), DDD varchar(50), NUMBER varchar(50), RAMAL varchar(50), PRIMARY KEY (ID) ); CREATE TABLE PROJECT ( ID integer NOT NULL, TITLE varchar(50), DESCRIPTION varchar(50), PRIMARY KEY (ID) ); CREATE TABLE CLIENT ( ID integer NOT NULL, NAME varchar(50), AGE integer, ID_PHONE integer, PRIMARY KEY (ID) ); CREATE TABLE VENDOR ( ID integer NOT NULL, NAME varchar(50), AGE integer, varchar(50), ID_PHONE integer, PRIMARY KEY (ID) ); 29

28 CREATE TABLE DEVELOPER ( ID integer NOT NULL, NAME varchar(50), AGE integer, varchar(50), ID_PHONE integer, PRIMARY KEY (ID) ); CREATE TABLE DEVELOPER_PROJECT ( DEVELOPER_ID integer NOT NULL, PROJECT_ID integer NOT NULL, PRIMARY KEY (DEVELOPER_ID, PROJECT_ID) ); O ObJectBridge exige que se faça a configuração do SGBDR e dos campos das entidades para que este possa fazer o mapeamento dos objetos para as entidades do SGBDR. Esta configuração se dá através de um repositório, que é um arquivo em XML. Este arquivo contém a descrição das classes, seus respectivos campos, coleções que cada classe pode ter, herança, polimorfismo, entre outros. O arquivo repositório com a configuração em XML para este sistema exemplo encontra-se em anexo. Criadas as entidades através de uma DDL própria, e feitas as configurações necessárias, é preciso deixar explícito à classe principal da aplicação Java qual é o repositório que contém as descrições das entidades e do SGBDR. A partir daí o ObJectBridge, através de sua API, se encarrega de armazenar, recuperar e alterar os objetos Java. A Figura 6 apresenta algumas entidades resultantes de uma consulta realizada através de uma linguagem DML (Data-Manipulation Language), SQL, no SGBDR MySQL. 30

29 Figura 6: Atributos de Objetos Java Mapeados para o SGBDR MySQL. 4.3 EXEMPLO DE MANIPULAÇÃO DE OBJETOS GRÁFICOS JAVA COM O JHOTDRAW O framework JHotDraw possui uma ampla API que possibilita, de forma facilitada, o acesso aos objetos gráficos criados através da linguagem de programação Java. A arquitetura do JHotDraw é baseada em outras duas: HotDraw e ET++, que por sua vez se baseiam no toolkit Java 2D. O JHotDraw é formado por 7 pacotes que compõem a sua arquitetura, sendo eles [Jhd02]: CH.ifa.draw.util - dispõe funções úteis que podem ser usadas independentemente do JHotDraw; CH.ifa.draw.framework - inclui classes e interfaces que definem o JHotDraw. Este pacote não dispõe qualquer implementação das classes; CH.ifa.draw.standard - dispõe a implementação padrão das classes definidas no pacote framework; CH.ifa.draw.figures - dispõe algumas figuras e suas classes de suporte associadas; CH.ifa.draw.contrib - classes que contribuem com outras; 31