i

Universidade Estadual de Maring Centro de Tecnologia Departamento de Informtica

Projeto da Arquitetura de um Ambiente de Engenharia de Software baseada em Java

Eduardo Lus Severo Soares

Maring - Paran Brasil

ii

Universidade Estadual de Maring Centro de Tecnologia Departamento de Informtica

Projeto da Arquitetura de um Ambiente de Engenharia de Software baseada em Java

Eduardo Lus Severo Soares

TG-01-98

Trabalho de Graduao apresentado ao Curso de Cincia da Computao, do Centro de Tecnologia, da Univesidade Estadual de Maring. Orientador: Profa. Dra. Itana Maria de Souza Gimenes

Maring - Paran 1998

iii

Eduardo Lus Severo Soares

Projeto da Arquitetura de um Ambiente de Engenharia de Software baseada em Java

Este exemplar corresponde redao final da monografia aprovada como requisito parcial para obteno do grau de Bacharel em Cincia da Computao da Universidade Estadual de Maring, pela comisso for mada pelos professores:

________________________________________ Orientador: Profa. Itana Maria de Souza Gimenes Departamento de Informtica, CTC, DIN ________________________________________ Prof. Carlos Jos Maria Olguin Departamento de Informtica, CTC, DIN

________________________________________ Prof. Osvaldo Alves dos Santos Departamento de Informtica, CTC, DIN

Maring, Dezembro de 1998

iv

Agradecimentos

Agradeo a Deus, que me ofereceu proteo, perseverana e muita fora para que eu pudesse lutar pela realizao dos meus ideais.

Aos meus pais, meu irmo, Elisa e Cristiane, que significam tanto para mim, agradeo pelo apoio que me deram quando o cansao me abateu, apoiando-me nos momentos mais difceis.

minha orientadora, Professora Dra. Itana Maria de Souza Gimenes, agradeo pela compreenso e pela pacincia que teve comigo durante a realizao deste trabalho.

A todos os meus colegas que estiveram do meu lado enfrentando juntos as dificuldades do curso, com muito companheirismo e amizade.

Aos meus grandes amigos, Grson, Luciano, Alexandre, Fabiano, Andr, Hlerson e Adriano agradeo por estarem ao meu lado nas horas difceis e pelo incentivo que deram tornando muito mais fcil enfrentar as dificuldades.

Resumo

Os ambientes de Engenharia de Software integram vrias ferramentas CASE para apoiar todo o ciclo de desenvolvimento de software, incluindo o controle, validao e manuteno do processo de software. Esses ambientes operam em arquiteturas distribudas atravs das quais usurios localizados em pontos geograficamente distantes podem cooperar na produo de um software.

A ampliao e difuso das redes de computadores trouxe a necessidade de manter uma independncia entre o cdigo a ser executado e a mquina hospedeira. A linguagem Java foi proposta para atender a essas necessidades. A linguagem baseada no paradigma de orientao a objetos, o que de grande importncia no que diz respeito a integrao de dados. Alm disso, Java foi desenvolvida para tratar os problemas de construo de software para utilizao em redes de trabalho, bem como apoiar diversas arquiteturas hospedeiras e para permitir o transporte seguro de componentes de software em redes.

A arquitetura de ambientes de engenharia de software orientados a processos te m sido desenvolvida em linguagens tradicionais como C++, utilizando interfaces tradicionais especficas para cada ambiente. Este trabalho tem como objetivo o projeto da arquitetura de um PSEE com base nas novas tecnologias de ambientes distribudos, utilizando-se a linguagem Java e conceitos de RMI, fazendo assim uma unio destas tecnologias com a Web. O gerenciador de processos em Java ser responsvel pelo controle e gerenciamento de todas as aplicaes realizadas no ambiente, incluindo suas tarefas, ferramentas, cargos e artefatos. A interface do ambiente utilizar pginas HTML e applets, seguindo os padres de web-browsers, os quais sero utilizados para execuo dos processos a partir das estaes de trabalho.

vi

Abstract

Software Engineering environments integrate several CASE tools to support the whole software development life cycle, including control, validation and maintenance of the software process. Those environments operate in distributed architectures where users located in geographically distant sites can cooperate to produce software. The wide diffusion of the computer networks brought about the need to maintain an independence between the code to be executed and the host machine. The Java language was proposed to support these require ments. The language is based on the object oriented paradigm. This paradigm is of great importance in respect to data integration. In addition, Java was developed to deal with web-based information systems. It supports several host architectures as well as improving the safety of the transport of software components through the network. The architecture of process-centred software engineering environments have been designed based on traditional languages like C++, using traditional interfaces. The objective of this work is to design the architecture of a PSEE based on new the technologies of distributed environments, in particular using the Java language and the concepts of RMI. This works joins these technologies with the Web support.

The processes manager in Java is responsible for the control and management of all the applications accomplished in the environment, including its tasks, tools, roles and artifacts. The interface of the environment will use HTML pages and applets , following the patterns of web -browsers. These browsers will be used for execution of the processes starting from the workstations.

vii

ndice

INTRODUO 1.1 MOTIVAO 1.2 OBJETIVO DO TRABALHO 1.3 ES TRUTURA DA MONOGRAFIA AMBIENTES DE ENGENHARIA DE SOFTWARE ORIENTADO A PROCESSOS 2.1 PROCESSOS DE SOFTWARE 2.2 SEE S E PSEE S 2.3 MODELO DE PROCESSOS DE SOFTWARE 2.4 ARQUITETURA DO EXPSEE 2.5 LINGUAGENS DE PROGRAMAO DE PROCESSOS 2.6 A BASE DE DADOS 2.7 CONSIDERAES FINAIS A LINGUAGEM JAVA 3.1 INTERFACE ATRAVS DE EVENTOS 3.1.1 REFERNCIAS DE EVENTOS 3.2 INVOCAO DE MTODOS R EMOTOS 3.3 OUTROS PARADIGMAS DE OBJETOS DISTRIBUDOS 3.4 CONSIDERAES FINAIS SOLUES JAVA PARA O EXPSEE 4.1 O MODELO MVC 4.2 PROJETO DA ARQUITETURA DO AMBIENTE 4.3 A INTERFACE DO AMBIENTE 4.4 APLICAO DE BANCO DE DADOS 4.4.1 JDBC 4.4.2 OS MODELOS DUAS-C AMADAS E T RS-CAMADAS 4.4.3 MY SQL 4.5 O GERENCIADOR DE PROCESSOS DO A MBIENTE 4.5.1 MDULOS G ERENCIADORES 4.5.2 MANIPULAO DE OBJETOS 4.6 TESTES 4.7 CONSIDERAES FINAIS CONCLUSES

1 1 2 2 4 4 5 5 7 8 9 10 11 13 16 17 19 20 21 21 23 24 25 26 26 29 30 31 31 36 37 38

REFERNCIA BIBLIOGR FICAS

41

viii

BIBLIOGRAFIA

43

ix

Listas de Ilustraes

Figura 1 Figura 2 Figura 3 Figura 4 Figura 5 Figura 6 Figura 7 Figura 8 Figura 9 Figura 10 Figura 11 Figura 12 Figura 13 Figura 14 Figura 15 Figura 16 Figura 17

- Meta-modelo do processo de software - Arquitetura do Ambiente ExPSEE - Aplicao de eventos em Java - Listeners - Mtodo Receptor - Arquitetura de um RMI - Modelo MVC - Arquitetura do Ambiente - Tela de apresentao do PSEE - Tela do tipo tarefa - O modelo de duas camadas - O modelo trs-camadas - Interface remota do ambiente - O Gerenciador de Processos - Mdulos Gerenciadores - Applet cliente - Pgina HTML onde carregado o applet

6 7 14 15 16 19 22 23 24 25 27 27 32 33 34 35 36

Tabela 1 - Relao de eventos/listeners /mtodos receptores

25

Captulo 1

Introduo

1.1 Motivao
Corporaes de grande porte demandam um maior suporte ao desenvolvimento de software. Obviamente, sistemas direcionados a estas grandes corporaes so muito mais complexos e custosos, devido a grande volume de informaes no repositrio de dados, a uma maior quantidade de usurios e principalmente a uma maior q uantidade de servios oferecidos pelos sistemas. Os ambientes de engenharia de software baseados na arquitetura ExPSEE1(Ambiente Experimental de Engenharia de Software Orientado a Processo) procuram atender a essas necessidades oferecendo um conjunto inte grado de ferramentas CASE2 que podem suportar todo o processo de desenvolvimento de software, desde sua validao, manuteno e controle. Um ambiente de engenharia de software orientado a processos(PSEE 3) fornece vrias facilidades de integrao para ferramentas CASE. Estas facilidades esto diretamente relacionadas a forma como uma ferramenta se comporta dentro do ambiente. Assim, quanto maior o nvel de comunicao entre as ferramentas, e mais transparente a sua funo dentro de um ambiente, mais facilidades sero encontradas para se obter uma melhor integrao[NAN95].

Os recentes desenvolvimentos tecnolgicos das redes de computadores, o surgimento de web -browsers, e de linguagens como Java, permitem uma maior flexibilidade de acesso aos sistemas de informao. Diferentes das linguagem tradicionais como C ou C++, Java

1 2

Experimental Process-centered Software Engineering Environment Computer Aided Software Engineering 3 Process-centered Software Engineering Environment

possibilita uma maior cooperao entre pessoas situadas em pontos geograficamente distantes. Os PSEEs, apesar de distribudos ainda no fazem muito uso desta tecnologia. Logo, a utilizao dos recursos oferecidos por Java atravs da web em um PSEE sero a base deste trabalho.

1.2 Objetivo do Trabalho

O objetivo deste trabalho projetar uma arquitetura de ambientes de engenharia de software orientado a processos com base em web -browsers e Java para ser utilizado atravs da rede Internet, utilizando protocolos HTTP 4. Neste ambiente, o usurio poder ter acesso as tarefas do processo atravs de interfaces com padro web e poder executa-las em pontos geograficamente distantes.

Para a avaliao de tais aplicaes foi construdo um prottipo que tem como meta permitir a integrao de interface, gerenciador de processos, mdulos gerenciadores e base de dados, atuando de forma distribuda.

1.3 Estrutura da Monografia

No captulo dois deste trabalho, so apresentadas informaes detalhadas e importantes da arquitetura ExPSEE. Um bom entendimento do ExPSEE fundamental, pois o desenvolvimento deste trabalho baseado nesta arquitetura. No terceiro captulo, so mostradas as caractersticas e os mtodos pertencentes a linguagem Java, que fazem dela uma das mais difundidas no mbito de software para redes. Tambm so citados padres que podem ser utilizados na integrao de servios orientados a objetos, como o RMI 5 , CORBA6 e DCOM7. J no capt ulo quatro so demonstrados os testes realizados baseados

4 5

Common Object Request Broker Archit ecture Remote Method Invocation 6 Distribuited Component Object Model 7 Hiper Text Transfer Protocol

nas solues Java para ExPSEE. Neste captulo tambm so apresentados a interface do ambiente, detalhes da implementao do gerenciador de processos e um estudo do uso de banco de dados em ambientes distribudos. Finalmente no quinto captulo so apresentadas concluses deste trabalho.

Captulo 2

Ambientes de Engenharia de Software Orientados a Processos

Este captulo procura mostrar as bases do processos de software. Para isto, realizado uma descrio dos processos de software e dos ambientes que se destinam a utilizar tais processos. SEE8 e PSEE so os ambientes voltados ao desenvolvimento e manuteno de processos. O projeto ExPSEE uma continuao dos estudo de processos, principalmente do ambiente PSEE. O ExPSEE possui um modelo de processos e uma arquitetura do ambiente que sero usados no desenvolvimento deste trabalho. Na sequencia realizada uma descrio de linguagens de programao de processos e por ltimo, os servios oferecidos pela base de dados em um ambiente de engenharia de software.

2.1

Processos de Software

Processo de software, ou processo de engenharia de software nada mais do que a realizao dos passos necessrios para o desenvolvimento e manuteno de um software. Um processo de software pode tambm ser definido como o conjunto de todas atividades relacionadas ao ciclo de vida de um software. Estas atividades incluem determinao e especificao dos requisitos de software; a implementao, a verificao e validao do software, o controle de qualidade, a integrao dos componentes, a documentao, a gestao de configuraes e verses e a avaliao do software entre outras[GIM97]. Com estes exemplos, possvel notar a quantidade e complexidade dos servios que podem pertencer a um PSEE.

Software Engineering Environment

Desta forma, o uso de processos de software esta diretamente relacionado a integrao de servios pertencentes ao ambiente. O gerenciador de processos o responsvel pela integrao de tais servios.

2.2

SEEs e PSEEs

Um ambiente de engenharia de software (SEE) responsvel por dar suporte ao funcionamento integrado de ferramentas CASE para a produo de software. Inicialmente essas ferramentas foram desenvolvidas para a automao de tarefas isoladas, entretanto existe atualmente a n ecessidade de que essas ferramentas possam trabalhar de forma cooperativa, dando suporte a todo o processo de desenvolvimento de software. Desta forma, SEEs podem ser vistos como um conjunto de mecanismos para apoiar a definio e execuo de processos de software. Um ambiente de engenharia de software orientado a processos(PSEE) pode ser representado como uma nova viso do SEE. Um PSEE complementa o suporte a descrio e execuo dos processos de um SEE, auxiliando e controlando atividades envolvidas no ciclo de vida do software, mais precisamente na produo e manuteno do software.

Os estudos de PSEE, levaram a construo do ambiente ExPSEE. No ExPSEE, existem os objetos de software e os operadores de software. Este ltimo o responsvel pela criao e transformao dos objetos de software. Para um melhor entendimento, os objetos de software so tratados como variveis do processo, enquanto os operadores representam as ferramentas e procedimentos pertencentes ao ambiente[GIM97].

2.3

Modelos de Processo de Software

Um modelo de processo de software pode visto como uma representao, ou abstrao dos objetos e atividades envolvidas no processo de software. Alm disso, oferece uma forma mais abrangente e fcil de representar o gerenciamento de processo de software e consequentemente o progresso do projeto. Uma verso de um modelo de processo de software pode ser vista atravs do Meta-Modelo do ExPSEE

O Meta-modelo do ExPSEE, apresentado na figura 1, divido em duas partes. A primeira est relacionada com a definio da arquitetura geral de processos e dos tipos desta arquitetura. Os tipos pertencentes uma arquitetura de processos so: task type(tipo da tarefa), artifact type(tipo do artefato/documento), tool type(tipo da tarefa) e role type(tipo do cargo). A partir destes tipos, so definidos os objetos que podem ser criados em um processo de software. A segunda parte esta relacionada com a primeira. Ela representa a instanciao e execuo dos objetos criados anteriormente. Os objetos a serem instanciados: task, tool, artifact, role, actor e agenda.

Type

is preceded by 0+ Process Architecture has 1+ 0+ Task Type produces needs 1+ 1+

dependes on

has

Arterfact Type 1+ 1+

0+ handles List of Actions Types

Tool Type 1+ 1+ manipulates List of Rights accesses

leader

0+

Role Type 1+

uses requires

refines

requires accesses uses List of Rights List of Actions is preceded by 0+ Software Process has 1+ 0+ 1+ dependes on has leader Agenda 1 Task produces needs 1+ 1+ plays 1+ 1+ Artefact 0+ Tool 0+ Role 1+ handles 1+ 1+ manipulates 1+

has

Actor 1+ 1+

is allocated to has

Figura1 Meta-modelo do processo de software

No Meta-modelo os tipos se relacionam entre si de vrios maneiras: um tipo de tarefa pode ser precedido e/ou composto por zero ou mais tipos de tarefas. Este tipo de tarefa pode utilizar um ou mais tipos de artefatos na produo de um ou mais tipos de artefatos. Esta produo pode requerer o emprego de um ou mais tipos de ferramentas, sendo realizada por um ou mais tipos de cargos. Um tipo de cargo pode ser liderado por outro tipo de cargo e tambm fazer uso de um ou mais tipos de ferramentas, e/ou manipular um ou mais tipos de artefatos. Tipos de ferramentas podem operar sobre tipos de artefatos[GIM98].

Quanto a parte instancia da do meta -modelo, o comportamento das suas relaes so mantidos da mesma forma que a parte anterior. Porm, nesta etapa teremos o acrscimo dos atores(actors), que so os usurios responsveis pelo desenvolvimento do processo de software. Cada ator possui um ou mais cargos(ou funes) dentro do ambiente.

2.4

Arquitetura do ExPSEE

A arquitetura do ExPSEE mostrada na figura 2, tem como meta separar os domnios de gerenciamento do ambiente. Para isso, so utilizados mdulos gerenciadores. O mdulo interface tem a responsabilidade de gerenciar a interao com o usurio. O mdulo meta gerenciador de processos cuida da definio e manuteno das arquitetura de processos. Outros mdulos gerenciadores cuidam dos demais processos, entre eles: ?? o gerenciador de artefatos controla os produtos intermedirios e finais do processo. ?? o gerenciador de ferramentas cuida das ferramentas utilizadas pelo ambiente. ?? o gerenciador de cargos e atores mantm a responsabilidade de controlar todos os cargos relacionados aos respectivos atores/usurios do processo. ?? e por ltimo, o gerenciador de tarefas cuida do escalonamento e execuo das tarefas.
Interface

Gerenciador de Processos Meta Gerenciador de Procesos

Gerenciador de Artefatos

Gerenciador de Tarefas

Gerenciador de Atores

Interpretador Gerenciador de Ferramentas Gerenciador de Cargos

base de dados

Figura 2 Arquitetura do Ambiente ExPSEE

Alm dos gerenciadores, existe um interpretador responsvel pela definio das tarefas em uma linguagem de programao de processos. Para um processo ser especificado e executado pelo gerenciador de processos, necessrio a especificao destes em uma linguagem de programao de processos[GIM98].

2.5

Linguagens de Programao de Processos

O objetivo de uma linguagem de programao de processos produzir programas que permitam a implementao do processo de software. Com a descrio de processos se torna possvel implementar processos de software. Essa descrio tem como meta, guiar e especificar o desenvolvimento de um produto de software[GIM97].

Os programas de processos de software apresentam poucas semelhanas e muitas diferenas se comparados com programas de aplicaes tpicas. Quando a questo esta relacionada com a manipulao de informaes(criao e modificao), tanto os programas de processos, quanto os programas comuns apresentam as mesmas caractersticas. Porm, se diferem pelo fato dos processos de software possurem caractersticas distintas das outras aplicaes, como: objetos maiores e mais complexos, como o cdigo fonte, testes, resultados de testes e especificaes. Logo as linguagens de programao de processos devem ser mais abrangentes e poderosas que as linguagens de aplicaes tpicas ou convencionais.

Em uma linguagem de programao de processos, caractersticas como mecanismo de definio de tipos, de agregao de dados, de controle de fluxo e de controle de concorrncia so fundamentais. Logo, percebe-se a dificuldade e complexidade em definir uma linguagem de processos de software.

Alm disso, uma linguagem de processos requer o uso da abordagem multiparadigma, que combina diferentes formas de representao. A aplicao de uma linguagem convencional que s usa um paradigma, improvvel para uso em processos. Alguns conceitos do

processos de software so mais adequados via determinadas linguagens de programao multiparadigma. Linguagens como as procedimentais, as baseadas em regras, em planejamento e em Redes de Petri e finalmente a mais conhecida, a orientada a objetos . Esta ltima apresenta importantes definies para a programao de processos, como: abstrao de dados, compartilhamento de comportamento, evoluo e corretude. Por isso a linguagem orientada a objetos, a mais utilizada e mais estudada das linguagens de processos[GIM97].

2.6

A Base de Dados

Em PSEEs, assim como nos SEEs, os banco de dados devem permitir o acesso a uma srie de servios bsicos que manipulam com eficincia grande volumes de informaes. O conjunto de informaes de um PSEE uma de sua s principais virtudes, pois nele esto includos servios largamente utilizados pelo gerenciador de processos, tais como[NAN95]: ?? Integridade de transaes: responsvel pelo controle das transformaes executadas em uma transao ?? Servios de correo: dest inados a retornar a base de dados a um estado consistente, quando houver algum erro. ?? Controle de concorrncia: possibilitam o compartilhamento de certas partes da base de dados por vrios processos ?? Mecanismos de segurana: destinados a impedir que agentes no autorizados, tenham acessos a determinados informaes ?? Interface de comunicao de dados: atravs de uma interface possvel que usurios acessem informaes em uma base de dados ?? Servios de integridade: controlam a incluso e manipulao de dados, com o objetivo de no deixa-los inconsistentes.

10

2.7

Consideraes Finais

Este captulo apresenta os principais aspectos do ExPSEE(seu modelo e sua arquitetura), ambiente que ser a base do prottipo a ser realizado para avaliao das novas tecnologias de rede ao PSEE`s.

Tambm so descritos a importncia das linguagens de programao de processos, principalmente a linguagem orientada a objetos, que o caso de Java , alm de uma demonstrao da importncia da base de dados em um ambiente orientado a processos.

11

Captulo 3

A linguagem Java
Neste captulo so apresentados os recursos Java a serem utilizados em um ambiente distribudo e suas principais caractersticas como orientao a objetos, multiplatafoma, entre outras. Posteriormente so ilustradas as tcnicas de construo de interfaces a partir de eventos. Por ltimo so descritos os padres de servios orientados a objetos que suportam um encontro com Java. Padres estes como o RMI, CORBA e DCOM.

3.1 Os Recursos da Linguagem

Java uma das linguagens de programao mais utilizadas e estudadas atualmente, possuindo um conjunto de recursos tecnolgicos no tradicionais, mas ideal para ser aplicado em grandes redes de computadores. Outra caracterstica de Java o fato de que ela no deixa de possuir uma sintaxe simples, at mesmo tradicional, sendo muito parecida com C e C++. As principais caractersticas da linguagem so destacadas a seguir:

Orientao a objetos
Em uma linguagem orientada a objetos, uma classe uma coleo de dados e mtodos que operam sobre estes dados. Desta maneira, os dados representam as caractersticas do objeto e os mtodos descrevem seu comportamento. Java possui um grande conjunto de classes(APIs9), arranjadas em pacotes[FLA97]. Exemplos de pacotes so o: Java.net, responsvel por suportar facilidades networking , o

Application Programming Interfaces

12

Java .lang, que possui a classe Object. Esta classe responsvel pelo comportamento geral das outras classes. As classes esto organizadas em uma hierarquia, onde uma subclasse pode herdar todo comportamento de uma superclasse. As classes so unidades nicas e bsicas de compilao e execuo em Java . Todos os programas em Java so formados por classes[FLA97].

Multiplataforma
Java oferece a vantagem de ser uma linguagem interpretada. O compilador Java gera byte codes , para a Mquina Virtual Java , ao invs de cdigo de mquina nativo[FLA97]. Assim, para rodar um programa cliente/servidor em Java , usa-se o interpretador Java (na mquina cliente) para executar os byte-codes gerados na mquina servidora. A Mquina Virtual Java e os interpretadores vem atualmente acoplados em web-browsers, atravs de um ambiente run-time. Quando um programa em Java carregado para a mquina cliente, em forma de applets, na verdade so carregados os byte-codes j compilados na mquina servidora. Dessa forma, o applet um cdigo interpretado atravs da Mquina Virtual Java embutida nos browsers, tornando-o possvel de ser executado em qualquer plataforma cliente. Os programas em Java podem rodar em qualquer plataforma que o JVM10

e o

interpretador estiverem portados. Esta pode ser considerada talvez como a principal caracterstica de Java , sendo a principal motivao para o uso de um PSEE em ambientes multiplataformas.

Uma linguagem dinmica e distribuda

Java uma linguage m que permite execuo dinmica. Qualquer classe pertencente a Java pode ser carregada no interpretador Java em qualquer momento, sendo ento instanciadas
10

Java Virtual Machine

13

dinmicamente.

Bibliotecas

de

cdigo

nativo

podem

tambm

ser

carregadas

dinmicamente[FLA97]. Java tambm conhecida como distribuda, pelo fato de fornecer vrios suportes de alto nvel para uso em redes[FLA97]. Por exemplo, a classe URL11 e outras classes pertencentes a pacotes Java como Java .net tem a capacidade de tornar mais fcil o acesso a um arquivo ou recurso remoto - como se fosse um arquivo ou recurso local. Juntando estas duas caractersticas, torna -se possvel acessar e executar cdigos pela Internet[FLA97]. Por exemplo, quando um web-browser acessa e executa um applet Java .

Threads
Um outro fator que precisa ser lembrado, o uso de Multithreads. Numa aplicao de rede GUI(Graphical User Interface) - baseando-se num web -browser - fcil de imaginar mltiplas atividades acontecendo em um mesmo tempo. Dessa maneira, podemos rotular Java como sendo uma linguagem multithread [FLA97]. Java suporta mltiplos threads de execuo que podem aplicar-se a diferentes tarefas. Um importante benefcio dos mltiplos threads, a melhoria ou aperfeioamento de desempenhos interativos de aplicaes grfic as para o usurio.

Java faz da programao com threads algo simples, fornecendo um suporte embutido na linguagem justamente para threads. O pacote Java .lang oferece uma classe thread que suporta mtodos para inicializar e finalizar threads e suas prioridades, entre outras coisas[FLA97].

3.1 Interface atravs de Eventos

A interface em Java, mesmo na forma de applets, oferece recursos voltados a aplicao de eventos. O uso de eventos uma forma alternativa e muito vantajosa, pois diminui de maneira significativa os custos da construo de uma interface.

14

Um evento pode ser disparado/acionado quando um boto ou um checkbox executado, por exemplo. Desta forma, os eventos so enviados aos seus receptores(mtodos) atravs do uso de listeners 12. Estes mtodos tem a funo de ajudar a execuo de tais eventos[FLA97].

Eventos so sempre enviados para os mtodos chamados receptores. Para cada tipo de evento existe um determinado listener que descreve o mtodo que ele deve utilizar para receber o evento correspondente[FLA97], conforme ilustra a figura 3.
"escuta" quando um evento acionado Evento listener

Mtodos Receptores

Figura 3 Aplicao de eventos em Java

Com a utilizao de mtodos receptores, no se torna necessrio criar funes que entendam que componentes da interface foram acionados. Nos mtodos receptores definido o que acontece quando um componente disparado. Mtodos receptores fazem parte do cdigo fonte da interface.

O fato da interface ser carregada e executada na mquina cliente, significa que quanto menor o nmero de linhas em um cdigo muito mais interessante se torna a aplicao, pois a quantidade de transferncia de dados do servidor para o cliente menor. As classes usadas na construo da interface j esto localizadas no cliente, atravs dos browsers .

11

Uniform Resource Locators

15

Os trechos do cdigo fonte usado no prottipo, como mostrado nas figuras 5 e 6, representam os conceitos de eventos em Java.

Evento
Com a criao do componente Button, o evento ActionEvent ser guardado num ContainerListener (Recipiente de Listener), mais precisamente no componentAdded . Este ltimo um mtodo receptor de AddContainerListener, como ilustrado na tabela 1.

Button exemplo = new Button(1. Inserir);

Listener
O ActionListener apresentado na figura 4 refere-se ao listener do ActionEvent, como mostrado na tabela 1. Ele fica localizado dentro do componentAdded. public class GerenciaApplet_tarefa ActionListener, ContainerListener { addContainerListener(this); ........ public void componentAdded(ContainerEvent e){ { ........ ActionListener(this); ........ } }
Figura 4 - Listeners

extends Applet implements

12

listeners: a escuta da int erface inserida no cdigo fonte que serve para informar quando um evento pertencente a um componente foi disparado.

16

Mtodo Receptor do ActionEvent

Quando um evento acionado feito uma verificao no componentAdded . Se o Button foi disparado, ento o ActionListener utilizado. Como ActionListener o mtodo receptor de ActionEvent, nele que ser definido a sequncia das aplicaes, conforme mostrado na figura 5. Por exemplo, quando o button 1.Inserir apertado/acionado, alguma aplicao relacionada com o prottipo iniciada. public void ActionPerformed(Action Event e) { if (e.getActionCo mmand( ). Equals( 1. Inserir ) { ........ ........ } }
Figura 5 Mtodo Receptor

3.1.1 Referncias de Eventos

Eventos em Java, so referenciados a partir de um conjunto de componentes ou classes AWT13. Estes componentes permitem disparos de vrios eventos. Cada componentes est relacionado a um evento, enquanto um evento pode estar relacionado a vrios componentes. A tabela 1 resume quais eventos(somente os usados na interface do prottipo) so disparados por seus respectivos componentes, e quais os mtodos receptores e os seus listeners .

13

Abstract Window Toolkit

17

Eventos ActionEvent

Disparados por TextField Button List Choice

Listener ActionListener

Mtodos Receptores ActionPerformed()

ItemEvent

ItemListener

ItemStateChanged() ComponentAdded()

ContainerEvent

All Containers

ContainerListener

ComponentRemoved()

Tabela 1 Relao de eventos/listeners/mt odos receptores

3.2 Invocao de Mtodos Remotos

Alm dos recursos j descritos acima, Java oferece servios orientados a objetos distribudos. Isto pode ser melhor detalhado atravs do mtodo RMI.

RMI permite o uso de objetos distribudos em redes heterogneas como uma extenso da programao orientada a objetos. A atuao destes objetos a garantia de interoperabilidade num sistema. Um objeto RMI um objeto remoto, cujos mtodos podem ser chamados de outra mquina virtual Java normalmente usando redes. RMI permite aos clientes interagir com o objetos remotos via interfaces pblicas. Os clientes no interagem diretamente com as classes que implementam as interfaces[RAJ98]. Como sabemos, objetos distribudos podem falhar pelos mais variados motivos, motivos estes ainda mais variados do que em objetos locais. Ento devemos ser capazes de tratar excees que possam ocorrer durante a chamada de um mtodo remoto. Para isso, RMI estendeu as caractersticas de tratamento de excees em Java , facilitando o tratamento e captura de falhas com objetos remotos[RAJ98].

Atravs do protocolo RMI, Java permite a serializao de seus objetos, que por sua vez permite a transmisso de objetos via rede. Desta forma, possvel a criao de objetos servidores e objetos clientes Java /RMI. O servidor o responsvel por definir uma

18

instncia da classe que implementa a interface remota. A interface remota dever declarar todos os mtodos que sero chamados remotamente no servidor. Para um cliente localizar um objeto remoto, pela primeira vez o RMI depende da execuo de um mecanismo chamado RMIRegistry. Este mecanismo quem roda o servidor, manipulando informaes sobre os objetos servidores disponveis, bem como mantm um mapeamento entre os objetos do host e o nome com os quais foram registrados. Para a aplicao cliente ser capaz de invocar um mtodo de um objeto remoto servidor, o cliente precisa primeiro adquirir uma referncia para o objeto remoto. Na maioria das vezes, a referncia ser obtida como valor de retorno de um mtodo remoto ou como uma passagem de parmetro para tal mtodo. Quando o objeto referenciado encontrado no servidor, ocorre a invocao de mtodos do objeto servidor. Um objeto RMI pode ser referenciado como se estivssemos chamando um objeto local no remoto. Se o RMIRegistry no estiver sendo executado, a conexo entre cliente e servidor ir falhar[RAJ98]. Quanto a arquitetura RMI, conforme mostrada na figura 6, existem tipos de camadas: os stubs e skeletons, Remote Reference e Transport . Como j descrito acima, uma referncia a um objeto remoto pode ser obtida atravs da passagem de parmetros para mtodos. Assim, quando um cliente invoca um mtodo, os parmetros so transformados em blocos de dados(marshalling na linguagem RPC14) pelo stub e so enviados a uma mquina servidora remota, atravs de um protocolo TCP/IP15 e uma porta annima de comunicao( Transport). Quando estes blocos de dados(ou mensagens) chegam na mquina remota, Em eles sero transformados a chamada em da

argumentos(unmarshalling) pelo

skeleton.

seguida,

ocorre

implementao do mtodo convertendo o resultado do objeto referenciado em uma outra mensagem, mas que ser redirecionada mquina cliente. O stub ser novamente utilizado. Agora ele o responsvel pela extrao deste valor de retorno[RAJ98].

14 15

Remote Procedure Call Transmission Control Protocol/Internet Protocol

19

A camada Remote Reference tem a responsabilidade de providenciar uma interface constante para os stubs e skeletons. Ela faz isso mascarando as diferenas entre as vrias formas de protocolo usadas no servidor.

Figura 6 Arquitetura de um RMI

3.3 Outros paradigmas de Objetos Distribudos

Apesar do RMI ser um mtodo original de Java e por isso s usado nesta linguagem, existem outros tipos de mtodos que oferecem servios orientados a objetos, que permitem uma integrao com Java e valem ser citados. Os mais conhecidos so DCOM e CORBA, principalmente este ltimo[RAJ98].

CORBA
Em uma arquitetura CORBA tudo depende do ORB16. Este funciona como um barramento de objetos, capaz de realizar a comunicao entre o cliente e o servidor. O ORB est localizado no servidor e tem a funo de localizar um objeto invocado(atravs de mtodos) e encaminh-lo de volta ao cliente que fez o pedido. Cada objeto servidor CORBA tem uma interface que expe um conjunto de mtodos. Para realizar um servio, o cliente adquiri uma referncia do objeto remoto, exatamente como no RMI, a no ser pelo fato de

16

Object Request Broker

20

que CORBA utiliza o ORB e no o RMIRegistry. A invocao de mtodos tambm funciona de maneira muito parecida[RAJ98]

DCOM
DCOM um Modelo de Componentes de Objetos Distribudos pertencente Microsoft? . O DCOM dentre os mtodos remotos, o que menos apresenta coincidncias com o RMI e CORBA. Apesar das diferenas, ele suporta a invocao de objetos remotos rodando em um protocolo chamado ORPC(Object Remote Procedure Call). O ORPC construdo sobre as bases de funcionamento do RPC e interage com os servios run -time COM. Cada objeto servidor DCOM pode suportar mltiplas interfaces, onde cada uma representa um comportamento diferente de objeto. Um cliente DCOM chama os mtodos expostos em um servidor atravs de um ponteiro adquirido em uma das interfaces servidoras. Este ponteiro que localizar o objeto invocado pelo cliente. o maior competidor de CORBA e RMI, pois a Microsoft o est incluindo em todos os seus sistemas operacionais. Tambm o fundamento tecnolgico para ActiveX e para o Microsoft Internet Explorer[RAJ98].

3.4 Consideraes Finais

Neste captulo mostramos os aspectos principais da linguagem Java, bem como abordamos alguns padre s de comunicao de objetos distribudos, em particular o Java RMI. Como o interesse principal deste trabalho testar o uso de Java em PSEEs, adotamos o RMI, como padro de comunicao no nosso prottipo.

21

Captulo 4

Solues Java para o ExPSEE

Este captulo da monografia destina -se ao estudo dos recursos oferecidos pela linguagem Java voltados para um ambiente ExPSEE. Para a realizao do estudos foram aplicadas tcnicas de programao e tambm conhecimentos tericos de Java amplamente aceitos no mbito computacional. Com isso, foi possvel a construo de um prottipo com vistas a realizao de testes operando em modo cliente/servidor.

Primeiramente, discutido a construo e aplicao das interfaces do prottipo. Na sequncia apresentado um estudo do banco de dados para PSEEs. E por ltimo, os detalhes do desenvolvimento e construo do prottipo do gerenciador de processos, bem como os seus mdulos gerenciadores.

4.1 O modelo MVC

O modelo MVC 17, mostrado na figura 7, tem como objetivo a representao de uma estrutura bsica formada por classes concretas e abstratas e seus relacionamentos, sendo esta estrutura chamada de framework . Um framework MVC um mtodo de construo que separa logicamente interface, estrutura e comportamentos em v rios mdulos. Dessa forma, possvel a implementao de um prottipo sujeito a substituies, sem comprometer certas partes do ambiente[ITO97]. A principal base do MVC separar um modelo de dados de um item de sua interface[FLA97]. Por exemplo, um modelo de dados pode ser representado e at mesmo substitudo por vrios tipos de interfaces. Desta forma, um simples banco de dados pode ter vrias vises, mostrando diferentes representaes dos dados pertencentes ao ambiente. O modelo MVC pode ser melhor caracterizado e separado atravs da :

17

Model/View/Controller

22

?? Viso: responsvel pela interface e seus componentes. ?? Controlador : responsvel pela integrao entre objetos do modelo(base de dados) e objetos da viso. ?? Modelo : responsvel pelas especificaes do sistema. Compreende as ferramentas utilizados pelo ambiente e principalmente o banco de dados.

Desta maneira a viso responsvel por capturar eventos disparados, o Controlador pela interpretao das aes passadas ele pela Interface e pela realizao de determinado servio, utilizando o modelo de dados. O resultados processados na base de dados(Modelo) retornam ao Controlador, sendo padronizadas por ele, para ento serem processadas, agora pela interface. E neste momento que o feedback com o usurio ocorre[ITO97].

Usurio Manipulao realimentao

Viso ao interpretada Controlador aes solicitadas Modelo

Figura 7 Modelo MVC

aes solicitadas

resultados

A linguagem Java apresenta alm da orientao objetos, a ocorrncia de eventos. Isto ocorre atravs dos componentes AWT que passam eventos do cdigo fonte para os listeners. Esta passagem de eventos possui uma parte do conceito de MVC, ou seja, possibilita a separao de implementao de um objeto de seu comportamento, fazendo com que os componentes de interface construdos possam ser reutilizveis[FLA97]. O termo reutilizvel significa que em caso de alteraes no desenvolvimento de um projeto,

23

a sua interface por exemplo, pode permanecer intacta, enquanto o comportamento do resto do ambiente modificado ou vice -versa. Logo ocorre todo o ciclo de separao de estrutura (modelo), representao (viso) e comportamento (controle). Desta forma, no nosso prottipo adotamos o modelo MVC para realizar a comunicao cliente com o servidor do ambiente.

4.2

Projeto da Arquitetura do Ambiente

Com o estudo de aplicaes Java , banco de dados e principalmente RMI foi possvel realizar uma nova arquitetura de ambiente, que apresentado na figura 8. Ela caracterizase pelo fato de que baseada na arquitetura proposta pela do ExPSEE.
Cliente
HTML/Applets (GerenciaApplet) Web Browser Ambiente Run-time Carregador de classes Verificador de byte-code Interpretador de Byte-code JVM Bibliotecas de classe Java

Interface

RMI

Mquina Servidora
Mtodo Remoto (mtodo_remoto) Gerencador de Processos (Gerencia) classes (mdulos)
tarefas cargos ferramentas artefatos

Gerenciador de Processos e seus mdulos

SGBD

MySQL

Repositrio de Dados

Servidor de Banco de Dados

Figura 8 Arquitetura do Ambiente

24

A seguir, vamos descrever a interface, o repositrio de dados, o gerenciador de processos, os mdulos gerenciadores e explicar como eles se relacionam. O gerenciador e seus mdulos so os ltimos a serem ilustrados, pois neles que se concretizam as relaes com a interface e o banco de dados.

4.3 A Interface do Ambiente

O objetivo da interface do ExPSEE permitir a manipulao dos tipos existentes em uma arquitetura de processos e posteriormente a execuo dos objetos definidos e instanciados a partir dos relacionamentos existentes entre os tipos do processo.

A interface do ambiente, atravs de applets Java, foi construda atravs de recursos voltados a aplicao de eventos, como descrito no captulo 3, operando em modo cliente/servidor. As figuras 9 e 10 mostram os prottipos da interface do Gerenciador de Processos funcionando atravs do browser Netscape. As telas se baseiam no relacionamento dos tipos pertencentes a arquitetura do ambiente ExPSEE(ver captulo 2). Os arquivos utilizados so pginas HTML18 contendo applets Java . Na figura 10 temos o exemplo de uma interface que efetua os relacionamentos pertencentes a uma tarefa. As demais telas: cargos, ferramentas e documentos apresentam uma interface semelhante, a no ser pelo nmero de relacionamentos que cada tipo comporta.

Figura 9 -Tela de apresentao do PS EE

18

Hiper Text Markup Language

25

Figura 10 -Tela do tipo tarefa

4.4 Aplicao de Banco de Dados

A consulta a banco de dados atravs da web (especificamente atravs de applets Java ) capaz de gerar o resultado de uma pesquisa em tempo de execuo, como se fosse em um computador pessoal. Porm, as consultas do usurio so repassadas ao servidor e posteriormente repassados do seu repositrio de dados ao cliente localizado em qualquer ponto da rede, no importando a plataforma de hardware ou software usado pelo usurio eles so totalmente independentes. Logo, o impacto da atualizao de verses de software para quem acessa banco de dados na rede menor[BAR98]. Quanto ao tempo de resposta de acesso ao banco de dados, os applets ficam restritos exclusivamente ao desempenho da rede utilizada para a conexo cliente/servidor.

26

Applets no precisam instalar, desinstalar ou configurar o repositrio de dados, como alguns outros assistentes de banco de dados utilizados na web[BAR98]. O cliente somente encarregado da apresentao dos dados. Logo, os applets permitem a construo de um cliente leve, de forma nenhuma sobrecarregado. A sobrecarga fica no servidor e na rede, que so os responsveis pelas configuraes necessrias[BAR98].

Para a utilizao de applets Java e banco de dados, necessrio a utilizao do driver JDBC19 . Com relao a base de dados usada neste projeto, a escolhida foi a MySQL descrita na seo 4.3.3.

4.4.1 JDBC
O JDBC um conjunto de classes e interfaces em Java feitos para executar declaraes SQL20. Atravs de um programa que usa o driver JDBC se torna fcil enviar declaraes SQL para qualquer base de dados, principalmente as relacionais[SUN97]. Com o uso do JDBC e Java , possvel publicar uma pgina na web contendo um applet com as informaes obtidas de um banco de dados remoto sem nenhum problema.

4.4.2 Os Modelos Duas-Camadas e Trs-Camadas

Para a aplicao de um banco de dados em applets, existem dois modelos que podem ser seguidos. O modelo duas-camadas e o modelo trs-camadas.

No modelo de dua s-camadas, conforme ilustra a figura 11, um applet Java fala diretamente com a base de dados instalado na prpria mquina servidora. O driver JDBC se comunica com o sistema gerenciador da base de dados inicialmente acessado[SUN97]. Este modelo baseado na configurao cliente/servidor, onde a mquina do usurio serve como cliente, e a mquina onde est alojada o banco de dados como servidor. O JDBC carregado para um cliente, quando o applet Java referenciado na mquina servidora.

19

Java DataBase Connectivity

27

Aplicao Java JDBC

Mquina Cliente

SGBD-protocolo proprietrio Banco de Dados Servidor da Base de Dados

Figura 11- O mode lo de duas camadas O modelo de trs-camadas difere do modelo de duas-camadas por apresentar uma camada do meio, como pode ser observado na figura 12, que faz o papel de servidor sem possuir o repositrio de dados, mas com o JDBC inserido. O SGBD21 fica numa outra mquina, chamada de servidor de base de dados.

Com a camada do meio, possvel a utilizao do Mtodo de Invocao Remoto(RMI). Isto significa que driver JDBC est localizado na mquina servidora e no mais na mquina cliente. Isto permite que applets sejam carregados no cliente de forma mais leve, pois quando uma declarao SQL executada, no cabe mais ao cliente passar a consulta(enviar a declarao) ao servidor. O prprio servidor que ir realizar a consulta ao banco de dados. Isto poss vel, pois o RMI envia parmetros para o servidor indicando qual objeto deve ser consultado. Logo, o cliente no mais o responsvel por realizar a consulta.
Applet Java ou browser HTML Mquina Cliente (GUI)

HTTP,RMI, CORBA Aplicao Servidora(Java) JDBC SGBD - protocolo proprietrio Banco de dados Servidor da Base de Dados Mquina Servidora
(Camada do Meio)

Figura 12 - O modelo trs -camadas

Um link entre a mquina servidora(camada do meio) e o servidor de banco de dados o responsvel pela transferncia de dados do SGBD para a mquina servidora e vice-versa.

20 21

Structured Query Language Sistema Gerenciador de Banco de Dados

28

Para que isso funcione, preciso ser declarado o nome da mquina servidora de banco de dados no arquivo que contm o JDBC. Este modelo traz certas vantagens em relao ao de duas-camadas, como manter um melhor controle sobre acessos e atualizaes que podem ser realizadas no banco de dados[SUN97]. Isto ocorrer no prprio servidor e no mais num cliente remoto. Alm do que, servidores possuem mais recursos que mquinas clientes.

Atravs das vantagens mostradas neste projeto, optou-se pelo modelo de trs camadas para a ser utilizado no projeto. Ainda em relao ao desenvolvimento do projeto, so utilizadas trs mquinas. Uma contendo a interface(cliente), e outras duas atuando como servidores.

Outra vantagem que o usurio pode empregar uma API de alto-nvel traduzida pela camada do meio em uma chamada de baixo-nvel[SUN97]. Logo, esta camada do meio pode providenciar uma melhora de desempenho, compensando a desvantagem transferncia de dados entre trs camadas ao invs de duas. Abaixo est um pequeno exemplo de como o JDBC pode ser usado em um applet. A declarao dbUrl contm o endereo do servidor de dados. da

Definio das variveis String informaes; String dbUrl="jdbc:mysql://caqui.din.uem.br :3333"; String user="anonymous"; String password="*****";

Carregando o driver Class.forName("gwe.sql.gweMysqlDriver");

Setando a conexo Connection con = DriverManager.getConnection(dbUrl,user,password);

29

Inicializando o contexto de banco de dados

Statement j = con.createStatement();

Selecionando os campos a serem lidos no banco de dados MySQL ResultSet rs= j.executeQuery("select * from tabela"); informaes = rs.getString(0)

4.4.3 MySQL
MySQL um banco de dados relacional, com certo reconhecimento no mercado. Permite o uso de multi-usurios atravs de threads, constituindo-se assim, de uma implementao cliente/servidor com o MySQL trabalhando em modo servidor e programas conectados a ele funcionando como clientes[MYS98].

O fato dela ser relacional, implica em uma maior facilidade de integrao com o JDBC, porm apresenta um problema. A incompatibilidade de tipos entre uma linguagem orientada a objeto e uma base de dados relacional. Isto ocorre, j que em Java existir um objeto no equivalente ao armazenado no banco de dados. O uso de um banco de dados orientado objetos facilitaria a resoluo deste problema[MAU98], porm para efeito de prototipao, o MySQL mostrou-se mais adequado devido a disponibilidade e facilidade de uso.

Neste projeto, o MySQL apresenta uma boa integrao com o driver JDBC Java , facilitando muito a integrao Java/MySQL. A bases de sua construo suportam um conjunto de rotinas, o que garante a sua usabilida de por um bom tempo[MYS98]. Entre as suas principais caractersticas, podem ser citadas[MYS98]: ?? trabalha com vrios tipos de dados em suas colunas: FLOAT, DOUBLE, CHAR,VARCHAR, TEXT , BLOB, DATE, DATETIME, TIMESTAMP, YEAR, SET e ENUM

30

?? possui operadores c ompletos da linguagem SQL ?? permite misturar tabelas em uma mesma consulta ?? manipula grandes bases de dados, com at 50.000.000 de registros ?? uso de tabelas hash (tabelas temporrias) ?? rpido sistema de alocao de memria baseada em threads

O uso de declaraes SQL um de seus pontos mais fortes. Pois SQL atingi atualmente o status de ser uma das linguagem de base de dados mais conhecidas e estudas no mundo.

4.5 O gerenciador de processos do ambiente

Um gerenciador de processos de software, como no ExPSEE, procura automatizar a

gerncia das atividades envolvidas no desenvolvimento de software, tendo em vista um ciclo de vida que envolve ferramentas de apoio s suas diversas fases.

O gerenciador de processos do ExPSEE, foi construdo prevendo a existnc ia de uma base de dados ligada diretamente aos tipos e relacionamentos da arquitetura propostos pelo prprio ExPSEE(ver capitulo 2). A partir desta base de dados permitido um controle gerenciado do compartilhamento de informaes entre as ferramentas do ambiente.

Para a realizao de uma melhor integrao entre a base de dados do ambiente e o gerenciador de processos, outros produtos podem ser adicionados ao ambiente. Servios orientados a objetos, como CORBA, DCOM ou RMI, tem muito a ver com este traba lho e podem oferecer funcionalidades a intercomunicao de servios.

Java possui as caractersticas e as bibliotecas necessrias para um encontro com CORBA[BRA98], mesmo em nvel de redes, ou mais precisamente atravs da web. DCOM tambm oferece recursos para Java, porm fica restrito ao uso do produtos pertencentes a Microsoft. Para o RMI basta citar que ele uma extenso da programao orientada a objetos de Java, onde estes objetos podem ser distribudos atravs de redes. A atuao destes objetos a garantia da interoperabilidade num sistema.

31

RMI foi o mtodo priorizado no projeto, no pelo fato de ser o padro mais adequado, mas simplesmente por ser um mtodo oriundo e exclusivo de Java. Desta forma, a idia principal do projeto seguida - o desenvolvimento de PSEE para testes baseado somente em tcnicas de programao Java .

4.5.1 Mdulos Gerenciadores

A arquitetura do ExPSEE caracteriza -se por separar os domnios de gerenciamento do ambiente em vrios mdulos gerenciadores(cargos, tarefas, artefatos e ferramentas) conforme discutido no captulo 2. Para realizar esta separao de domnios de gerenciamento, RMI permite a criao e instanciao de classes(ou objetos) ligados diretamente ao gerenciador de processos, funcionando como verdadeiros mdulo gerenciadores. So eles: ?? a classe tarefa ?? a classe cargo ?? a classe ferramenta ?? a classe artefato O uso de Java/RMI em um PSEE fornece o suporte necessrio para que elementos de um mdulo gerenciador sejam manipulados e executados atravs da web .

4.5.2 Manipulao de Objetos

Para um objeto ser manipulado, Java /RMI fornece um conjunto de facilidades que permitem a integrao entre interface e gerenciador de processos e repositrio de dados, em modo cliente/servidor. Como facilidades, podem ser citadas a implementao de uma interface remota localizada no servidor onde so declarados todos os mtodos que sero chamados remotamente. Neste projeto bastou a definio de um mtodo. Este mtodo que faz o papel do gerenciador de processos.

32

Definindo a interface remota

Definir uma instncia de classe que implementa a interface remota e manipula excees que podem ocorrer durante a chamada de um mtodo remoto um dos recursos disponveis desta interface (declarada atravs de uma classe java.rmi.RemoteException pertencente a Java ). A interface remota deve ser declarada no servidor e deve tambm declarar o tipo de dado do objeto referenciado que passado como um valor de retorno para o cliente( String valor(int evento)).

Logo, quando o mtodo metodo_gerencia for referenciado(chamado), conforme mostra a figura 13, pelo cliente retornado uma String valor como resposta. Os valores de retorno dos mtodos remotos podem ser de qualquer tipo Java, incluindo at mesmo objetos. O metodo_gerencia funciona desta forma, como um integrador de interface e gerenciador de processos.

import java.rmi.Remote; import java.rmi.RemoteException; public interface metodo_gerencia extends Remote{ String valor(int evento) throws RemoteException; }
Figura 13 Interface remota do ambiente

A implementao do objeto remoto Um objeto deve declarar que implementao de pelo menos uma interface remota(atravs do UnicastRemoteObject) e desta forma criar um objeto remoto simples. Assim, possvel fornecer implementaes para os mtodos que podem ser invocados remotamente, como ilustradas na figura 14. Tambm devero ser criadas uma ou mais instncias do objeto remoto para ficarem disponveis aplicao cliente(atravs do Gerenciador obj ). Uma vez criado este objeto, ele estar pronto para escutar alguma "chamada" remota do cliente.

33

A funo Naming.rebind(), localizada imediatamente depois do objeto Gerenciador mostra o endereo deste objeto instanciado(qual a mquina que ele se encontra). Gerenciador funciona como o gerenciador de processos do ambiente, pois nele que sero especificados a sequncia de processos. Os parmetros int evento pertencentes a valor() (invocados atravs do cliente) so uma forma do gerenciador distinguir quais eventos foram acionados na interface cliente e consequentemente indicar qual processo deve ser aplicado. import java.rmi.*; import java.rmi.server.*; import java.net.*; public class Gerenciador extends UnicastRemoteObject implements metodo_gerencia { public String valor(int evento) throws RemoteException { if (evento=1) { cargo.obj = new cargo.obj; return obj.cargo; } ...... } ...... public static void main(strings args[]) { Gerenciador obj = new Gerenciador(); Naming.rebind("//sequoia.din.uem.br:1999/metodo_gerencia",obj); ...... } }
Figura 14- O Gerenciador de Processos

34

Por exemplo, se o cliente invoca o objeto valor(1), ou seja, o valor com parmetro igual a 1 ser indicado qual aplicao e qual mdulo gerenciador vai realiz-la. Se o parmetro for diferente de 1, ento outros mdulos sero comunicados. Uso de classes As classes usadas no ambiente, apresentadas na figura 15, esto diretamente relacionadas com o uso de mdulos gerenciadores. Mdulos realizam os passos do ciclo de desenvolvimento do software, atravs do gerenciador de processos que indica qual o mdulo(de cargos, ferramentas, artefatos e tarefas) que dever ser usado.

O driver JDBC(responsvel pela comunicao com a base de dados MySQL) est instalado nos mdulos. Com isso possvel um mdulo gerenciador pode obter as informaes necessrias para o desenvolvimento deste processo inseridas no banco de dados. Logo, ele est separando os domnios de gerenciamento. O return , localizado no fim do arquivo contm os dados a serem retornados pelo mdulo ao gerenciador de processos. Ao chegar no gerenciador, ele ser novamente retornado, s que agora a interface do ambiente. import java.net.URL; import java.sql.*; import java.rmi.*; import gwe.sql.*; public class cargo { public String cargo() { String informaes; ........ (realiza as consultas ao banco de dados) return informaes; } }
Figura 15 Mdulos Gerenciadores

35

Escrevendo o programa cliente Atravs d e cada um dos applets (ou simplesmente interfaces do ambiente) possvel a invocao do mtodo remoto metodo_gerencia . Posteriormente haver um retorno deste mtodo referenciado inicialmente pelo cliente, atravs da String valor(). RMI providencia um registro baseado em URL, permitindo a localizao de uma URL atravs da declarao Naming.lookup() pertencente ao mtodo metodo_gerencia . Nesta declarao definido o host da mquina servidora. Ou seja, onde est o gerenciador de processos e consequentemente seus mdulos.

O applet, apresentado na figura 16, tambm invoca valor(1) como um objeto e at os seus parmetros. O seu valor de retorno ser armazenado em uma var ivel do tipo String chamada message(usada para imprimir o valor de retorno na interface do ambiente). import java.awt.*; import java.rmi.*; public class GerenciaApplet_tarefa extends java.applet.Applet { String message; public void init() { ....... (interface) ....... obj =(metodo_gerencia())Naming. Lookup ("//sequoia.din.uem.br:1999/... "); message = obj.valor(1); }
Figura 16 Applet cliente

Por fim, ser construda uma pgina HTML, ilustrada na figura 17, onde ser carregado o applet Java. Depois de compilado na mquina servidora, o applet recebe a extenso class e

36

transformado em byte-codes. Assim, est pronto para ser usado pelos padres da web e pela mquina cliente(onde o applet fica instalado) .Os applets diferem entre si, somente no momento que invocam o objeto valor() atravs de parmetros diferentes, ou seja, quando indicam qual processo deve ser aplicado pelo gerenciador.

<HTML> <applet code="GerenciaApplet_tarefa.class" > </applet> </HTML>

Figura 17 Pgina HTML onde carregado o applet

4.6

Testes

As operaes realizadas para testes do prottipo so baseadas na manipula o de declaraes SQL realizadas pelos mdulos gerenciadores localizados no servidor. Ao recuperar informaes, o valor repassado ao mtodo manipulador e posteriormente carregado na interface do ambiente. Quanto as outras caractersticas, o PSEE baseado em Java projetado para rodar atravs da Internet com o auxlio de arquivos HTML, prprios para o protocolo HTTP, enquanto que o ExPSEE usa uma pequena rede centralizada. Abaixo esto os testes escolhidos para o desenvolvimento do projeto em Java. O uso de mtodos, classes, objetos e repositrio de dados so fundamentais para todas operaes.

Criao de arquitetura de processos Incluso dos tipos cargos, tarefas, artefatos e ferramentas. A criao de uma arquitetura de processos ser parecida com a do projeto ExPSEE e a sua principal caracterstica est no relacionamento entre os tipos existentes. Assim que criados, os dados sero armazenados na base de dados.

37

Abrir arquitetura

Localizar e carregar os dados pertencentes a uma arquitetura referencia da. Para isso um pedido do cliente para o servidor realizado. Remover arquitetura Quando no se deseja mais utilizar determinados tipos(ou dados) de uma arquitetura eles so removidos da base de dados.

Todos estes testes precisam explorar bem a integrao repositrio de dados e classes remotamente instanciadas, pois atravs desta comunicao que sero realizadas as declaraes SQL , como INSERT, REMOVE e SELECT .

4.7 Consideraes Finais

A aplicao de um modelo de trs camadas coube perfeitamente para o desenvolvimento do projeto. O encontro de RMI e banco de dados, muito positivo pois deixa o cliente mais leve, totalmente livre de consultas e de manipulao de informaes. Cabe ao gerenciador de processos e seus mdulos gerenciadores localizados no servidor e ao sistema gerenciador de banco de dados tambm localizado no servidor mas em outra mquina, realizar estas aplicaes.

38

Captulo 5

Concluses
Mesmo no tendo oportunidade de desenvolver um maior nmero de testes(foram realizados alguns a partir da construo de um prottipo) os estudos realizados neste trabalho revelaram que Java possui os recursos necessrios para criar uma arquitetura de ambientes de engenharia de software de processos baseado em redes Internet. O fato do ambiente ser proposto para o uso em sistemas distribudos, fez de Java a linguagem ideal para o desenvolvimento deste trabalho. Java possui fortes laos com o paradigma cliente/servidor, alm de poder ser aplicado em qualquer plataforma, permitir a criao e manipulao de threads e muitos outros fatores j citados neste trabalho. Tudo isso mostra que atualmente Java aponta como uma das melhores linguagens de programao para uso em redes, seja aplicado em programas convencionais, seja em programas mais complexos e de grande porte(como um PSEE), normalmente orientados a objeto.

A realizao de poucos testes deveu -se muitas vezes as dificuldades encontradas na construo das camadas de comunicao entre cliente e servidor, e entre servidor e servidor de dados, onde cada um representado por uma mquina. Apesar destas

dificuldades, pode se realizar a arquitetura do prottipo em trs-camadas, oferecendo ao cliente uma interface totalmente desprovida de execues. Todas elas so referenciadas pelo cliente e executadas nas mquinas servidoras.

Com isso, objetivou-se a aplicao de testes mais nas formas de integrao de banco de dados, mdulos gerenciadores, gerenciadores e interface.

O uso do driver JDBC oferece um bom suporte de integrao entre o ambiente e banco d e dados MySQL. Um banco de dados constitui a base de todas as informaes de um PSEE.

39

O RMI tambm providencia suportes para construo de PSEE, pois oferece recursos de orientao a objetos estendido para uso em redes atravs de protocolos HTTP. Com RMI possvel usar mtodos de invocao remota(neste trabalho foi usado apenas um) funcionando como um gerenciador de processos. Assim, este mtodo usado como um gerenciador de PSEE, podendo dizer quais aplicaes sero realizadas e por qual mdulo. Mesmo o RMI sendo testado, analisado e observado como um mtodo muito til na construo de PSEEs, podemos referenciar CORBA como o padro que melhor oferece servios de integrao de objetos remotos. Desta forma, CORBA pode ser destacado para futuros trabalhos envolvendo Java e PSEE, pois apresenta: ?? melhores nveis de desempenho que o RMI ?? referncia a objetos persistentes ?? protocolo independente de linguagem ?? escalonamento universal via IORs, DSI, GUIDs, IIOP e inter-ORBs ?? Java oferece todas as bibliotecas necessrias para um encontro com CORBA e a web Com mostra a comparao, CORBA est a frente de RMI tanto em desempenho quanto no nmero de recursos oferecidos[UNI98]. Mas, RMI apresenta facilidades que no seriam encontradas em CORBA, tais como: ?? faz passagem de objetos por valor ?? usa Java tanto como linguagem de definio de interfaces como linguagem de implementao ?? usa nomes baseados em URL

40

Alm de CORBA, outras aplicaes Java podem ser destacadas para futuros trabalhos, tais como: ?? uso de threads. Voltados a resoluo de problemas de concorrncia, pois como o ambiente construdo em redes, diferentes usurios podem tentar acessar uma mesma operao num mesmo instante de tempo. ?? aplicao de uma base de dados orientada a objetos. Possibilitam uma melhor compatibilidade de tipos entre a linguagem Java (orientada a objetos) e sua base de dados.

41

Referncia Bibliogrficas
[BAR98] Baruzzi, Flvio. Por que Integrar Bancos de Dados World Wide Web , Developers Magazine ,Janeiro de 1998, Ano 2, N. 17. [BRA98] Brasileiro, Francisco Vilar e Stanchi, Tatiana Simas. Quando CORBA encontra Java e World Wide Web: novos paradigmas para a programao cliente servidor, XII Simpsio Brasileiro de Engenharia de Software : Tutorial, 1998. [FLA97] Flanagan, D., Java in a Nutshell 2 a Edio, O'Reilly & Associates, Inc.,1997.

[GIM97] Gimenes, Itana M.S., Fantinato, Marcelo e Carniello, Andria. Relatrio 1 Projeto ExPSEE , Universidade Estadual de Maring, 1997.

[GIM98] Gimenes, Itana M. S., Silva, Srgio R.P., Ito, Srgio Akira, e Haeberer, Armando. FORMLAB: Um Ambiente Integrado de Apoio aos Mtodos Formais para o Desenvolvimento de Software, Universidade Estadual de Maring, 1997.

[ITO97] Ito, Srgio Akira. Prototipao da Interface com o Usurio de um Gerenciador de Processos de Software , Universidade Estadual de Maring,1997.

[MAU98] Mauro, Renato Campos e Mattoso, Marta Lima de Queirs. Integrao de LPOO e BDOO : Uma experincia com Java e GOA++, XIII Simpsio Brasileiro de Banco de Dados: Anais, 1998.

[MYS98] What is MySQL? . Rede Internet http://www.mysql.com, 1998

[NAN95] Nanni, Edicezar Leandro. Construo de uma Base para Ambientes de Engenharia de Software, Universidade Estadual de Maring, 1995.

42

[RAJ98] Raj, Gopalan Suresh. A Detailed Comparision of CORBA, DCOM and Java/RMI. Rede Internet, 1998. [SUN97]JDBCTM Database Access from Java TM: A Tutorial and Annotated Reference. Sun Microsystem, Rede Intrenet,1997

[UNI98] Comparando uma Aplicao Cliente/Servidor usando RMI com uma usando CORBA, Rede Inter net, UNICAMP -Universidade de Campinas, www.dcc.unicamp.br~973245-rmi, 1998

43

Bibliografia

Cap Web Flow, General Information Manual. Rede Internet, http://www.cs.man.ac.uk/ipj, 1997. Halfhill, T.R., Hoje a Web, Amanh o Mundo,Revista Byte Janeiro de 1997, Vol. 06 No. 1.

Lindholm, T. & Yellin, F. The Java Virtual Machine Specification. 1 a Edio, Addison Wesley Longman, Inc. 1996. Recife Java Team, The, composto por Alcantara, A.A., Fernandes, J.H.C., Martins, J.F.T., Pepeu, J.F.S., Meira, S.L., Introduo a Java, Universidade Federal de Pernambuco,1997.