i

Universidade Estadual de Maringá

Centro de Tecnologia
Departamento de Informática

Projeto da Arquitetura de um Ambiente de Engenharia de

Software baseada em Java

Eduardo Luís Severo Soares

Maringá - Paraná
Brasil
 ii

Universidade Estadual de Maringá

Centro de Tecnologia
Departamento de Informática

Projeto da Arquitetura de um Ambiente de Engenharia de

Software baseada em Java

Eduardo Luís Severo Soares

TG-01-98

Trabalho de Graduação apresentado ao Curso de

Ciência da Computação, do Centro de Tecnologia, da
Univesidade Estadual de Maringá.
Orientador: Profa. Dra. Itana Maria de Souza Gimenes

Maringá - Paraná
1998
 iii

Eduardo Luís Severo Soares

Projeto da Arquitetura de um Ambiente de Engenharia de

Software baseada em Java

Este exemplar corresponde à redação final da monografia aprovada como requisito parcial
para obtenção do grau de Bacharel em Ciência da Computação da Universidade Estadual
de Maringá, pela comissão for mada pelos professores:

________________________________________
Orientador: Profa. Itana Maria de Souza Gimenes
Departamento de Informática, CTC, DIN

________________________________________
Prof. Carlos José Maria Olguin
Departamento de Informática, CTC, DIN

________________________________________
Prof. Osvaldo Alves dos Santos
Departamento de Informática, CTC, DIN

Maringá, Dezembro de 1998

 iv

Agradecimentos

Agradeço a Deus, que me ofereceu proteção, perseverança e muita força para que eu
pudesse lutar pela realização dos meus ideais.

Aos meus pais, meu irmão, Elisa e Cristiane, que significam tanto para mim, agradeço pelo
apoio que me deram quando o cansaço me abateu, apoiando-me nos momentos mais
difíceis.

À minha orientadora, Professora Dra. Itana Maria de Souza Gimenes, agradeço pela
compreensão e pela paciência que teve comigo durante a realização 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, Gérson, Luciano, Alexandre, Fabiano, André, Hélerson e
Adriano agradeço por estarem ao meu lado nas horas difíceis e pelo incentivo que deram
tornando muito mais fácil enfrentar as dificuldades.
 v

Resumo

Os ambientes de Engenharia de Software integram várias ferramentas CASE para apoiar

todo o ciclo de desenvolvimento de software, incluindo o controle, validação e manutenção
do processo de software. Esses ambientes operam em arquiteturas distribuídas através das
quais usuários localizados em pontos geograficamente distantes podem cooperar na
produção de um software.

A ampliação e difusão das redes de computadores trouxe a necessidade de manter uma

independência entre o código a ser executado e a máquina hospedeira. A linguagem Java
foi proposta para atender a essas necessidades. A linguagem é baseada no paradigma de
orientação a objetos, o que é de grande importância no que diz respeito a integração de
dados. Além disso, Java foi desenvolvida para tratar os problemas de construção de
software para utilização 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
específicas para cada ambiente. Este trabalho tem como objetivo o projeto da arquitetura
de um PSEE com base nas novas tecnologias de ambientes distribuídos, utilizando-se a
linguagem Java e conceitos de RMI, fazendo assim uma união destas tecnologias com a
Web.

O gerenciador de processos em Java será responsável pelo controle e gerenciamento de

todas as aplicações realizadas no ambiente, incluindo suas tarefas, ferramentas, cargos e
artefatos. A interface do ambiente utilizará páginas HTML e applets, seguindo os padrões
de web-browsers, os quais serão utilizados para execução dos processos a partir das
estações 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

INTRODUÇÃO 1

1.1 MOTIVAÇÃO 1
1.2 OBJETIVO DO TRABALHO 2
1.3 ES TRUTURA DA MONOGRAFIA 2

AMBIENTES DE ENGENHARIA DE SOFTWARE ORIENTADO A PROCESSOS 4

2.1 PROCESSOS DE SOFTWARE 4

2.2 SEE’ S E PSEE’ S 5
2.3 MODELO DE PROCESSOS DE SOFTWARE 5
2.4 ARQUITETURA DO EXPSEE 7
2.5 LINGUAGENS DE PROGRAMAÇÃO DE PROCESSOS 8
2.6 A BASE DE DADOS 9
2.7 CONSIDERAÇÕES FINAIS 10

A LINGUAGEM JAVA 11

3.1 INTERFACE ATRAVÉS DE EVENTOS 13

3.1.1 REFERÊNCIAS DE EVENTOS 16
3.2 INVOCAÇÃO DE MÉTODOS R EMOTOS 17
3.3 OUTROS PARADIGMAS DE OBJETOS DISTRIBUÍDOS 19
3.4 CONSIDERAÇÕES FINAIS 20

SOLUÇÕES JAVA PARA O EXPSEE 21

4.1 O MODELO MVC 21

4.2 PROJETO DA ARQUITETURA DO AMBIENTE 23
4.3 A INTERFACE DO AMBIENTE 24
4.4 APLICAÇÃO DE BANCO DE DADOS 25
4.4.1 JDBC 26
4.4.2 OS MODELOS DUAS-C AMADAS E T RÊS-CAMADAS 26
4.4.3 MY SQL 29
4.5 O GERENCIADOR DE PROCESSOS DO A MBIENTE 30
4.5.1 MÓDULOS G ERENCIADORES 31
4.5.2 MANIPULAÇÃO DE OBJETOS 31
4.6 TESTES 36
4.7 CONSIDERAÇÕES FINAIS 37

CONCLUSÕES 38

REFERÊNCIA BIBLIOGRÁ FICAS 41

 viii

BIBLIOGRAFIA 43
 ix

Listas de Ilustrações

Figura 1 - Meta-modelo do processo de software 6

Figura 2 - Arquitetura do Ambiente ExPSEE 7
Figura 3 - Aplicação de eventos em Java 14
Figura 4 - Listeners 15
Figura 5 - Método Receptor 16
Figura 6 - Arquitetura de um RMI 19
Figura 7 - Modelo MVC 22
Figura 8 - Arquitetura do Ambiente 23
Figura 9 - Tela de apresentação do PSEE 24
Figura 10 - Tela do tipo tarefa 25
Figura 11 - O modelo de duas camadas 27
Figura 12 - O modelo três-camadas 27
Figura 13 - Interface remota do ambiente 32
Figura 14 - O Gerenciador de Processos 33
Figura 15 - Módulos Gerenciadores 34
Figura 16 - Applet cliente 35
Figura 17 - Página HTML onde é carregado o applet 36

Tabela 1 - Relação de eventos/listeners/métodos receptores 25

 1

Capítulo 1

Introdução

1.1 Motivação

Corporações de grande porte demandam um maior suporte ao desenvolvimento de

software. Obviamente, sistemas direcionados a estas grandes corporações são muito mais
complexos e custosos, devido a grande volume de informações no repositório de dados, a
uma maior quantidade de usuários e principalmente a uma maior quantidade de serviços
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 validação,
manutenção e controle.

Um ambiente de engenharia de software orientado a processos(PSEE 3) fornece várias

facilidades de integração para ferramentas CASE. Estas facilidades estão diretamente
relacionadas a forma como uma ferramenta se comporta dentro do ambiente. Assim,
quanto maior o nível de comunicação entre as ferramentas, e mais transparente a sua
função dentro de um ambiente, mais facilidades serão encontradas para se obter uma
melhor integração[NAN95].

Os recentes desenvolvimentos tecnológicos das redes de computadores, o surgimento de

web -browsers, e de linguagens como Java, permitem uma maior flexibilidade de acesso
aos sistemas de informação. Diferentes das linguagem tradicionais como C ou C++, Java

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

possibilita uma maior cooperação entre pessoas situadas em pontos geograficamente

distantes.

Os PSEE’s, apesar de distribuídos ainda não fazem muito uso desta tecnologia. Logo, a
utilização dos recursos oferecidos por Java através da web em um PSEE serão 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
através da rede Internet, utilizando protocolos HTTP 4. Neste ambiente, o usuário poderá
ter acesso as tarefas do processo através de interfaces com padrão web e poderá executa-las
em pontos geograficamente distantes.

Para a avaliação de tais aplicações foi construído um protótipo que tem como meta permitir
a integração de interface, gerenciador de processos, módulos gerenciadores e base de
dados, atuando de forma distribuída.

1.3 Estrutura da Monografia

No capítulo dois deste trabalho, são apresentadas informações detalhadas e importantes da

arquitetura ExPSEE. Um bom entendimento do ExPSEE é fundamental, pois o
desenvolvimento deste trabalho é baseado nesta arquitetura. No terceiro capítulo, são
mostradas as características e os métodos pertencentes a linguagem Java, que fazem dela
uma das mais difundidas no âmbito de software para redes. Também são citados padrões
que podem ser utilizados na integração de serviços orientados a objetos, como o RMI 5 ,
CORBA6 e DCOM7. Já no capít ulo quatro são demonstrados os testes realizados baseados

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

nas soluções Java para ExPSEE. Neste capítulo também são apresentados a interface do
ambiente, detalhes da implementação do gerenciador de processos e um estudo do uso de
banco de dados em ambientes distribuídos. Finalmente no quinto capítulo são apresentadas
conclusões deste trabalho.
 4

Capítulo 2

Ambientes de Engenharia de Software Orientados a

Processos

Este capítulo procura mostrar as bases do processos de software. Para isto, é realizado uma
descrição dos processos de software e dos ambientes que se destinam a utilizar tais
processos. SEE8 e PSEE são os ambientes voltados ao desenvolvimento e manutenção de
processos. O projeto ExPSEE é uma continuação dos estudo de processos, principalmente
do ambiente PSEE. O ExPSEE possui um modelo de processos e uma arquitetura do
ambiente que serão usados no desenvolvimento deste trabalho. Na sequencia é realizada
uma descrição de linguagens de programação de processos e por último, os serviços
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

realização dos passos necessários para o desenvolvimento e manutenção de um software.

Um processo de software pode também ser definido como o conjunto de todas atividades
relacionadas ao ciclo de vida de um software. Estas atividades incluem determinação e
especificação dos requisitos de software; a implementação, a verificação e validação do
software, o controle de qualidade, a integração dos componentes, a documentação, a
gestação de configurações e versões e a avaliação do software entre outras[GIM97]. Com
estes exemplos, é possível notar a quantidade e complexidade dos serviços que podem
pertencer a um PSEE.

8
Software Engineering Environment
 5

Desta forma, o uso de processos de software esta diretamente relacionado a integração de

serviços pertencentes ao ambiente. O gerenciador de processos é o responsável pela
integração de tais serviços.

2.2 SEE’s e PSEE’s

Um ambiente de engenharia de software (SEE) é responsável por dar suporte ao

funcionamento integrado de ferramentas CASE para a produção de software. Inicialmente
essas ferramentas foram desenvolvidas para a automação de tarefas isoladas, entretanto
existe atualmente a necessidade de que essas ferramentas possam trabalhar de forma
cooperativa, dando suporte a todo o processo de desenvolvimento de software. Desta
forma, SEE’s podem ser vistos como um conjunto de mecanismos para apoiar a definição e
execução de processos de software.

Um ambiente de engenharia de software orientado a processos(PSEE) pode ser

representado como uma nova visão do SEE. Um PSEE complementa o suporte a descrição
e execução dos processos de um SEE, auxiliando e controlando atividades envolvidas no
ciclo de vida do software, mais precisamente na produção e manutenção do software.

Os estudos de PSEE, levaram a construção do ambiente ExPSEE. No ExPSEE, existem os

objetos de software e os operadores de software. Este último é o responsável pela criação e
transformação dos objetos de software. Para um melhor entendimento, os objetos de
software são tratados como variáveis 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 representação, ou abstração dos
objetos e atividades envolvidas no processo de software. Além disso, oferece uma forma
mais abrangente e fácil de representar o gerenciamento de processo de software e
consequentemente o progresso do projeto. Uma versão de um modelo de processo de
software pode ser vista através do Meta-Modelo do ExPSEE
 6

O Meta-modelo do ExPSEE, apresentado na figura 1, é divido em duas partes. A primeira

está relacionada com a definição da arquitetura geral de processos e dos tipos desta
arquitetura. Os tipos pertencentes à uma arquitetura de processos são: 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, são definidos os objetos que podem ser criados em um
processo de software. A segunda parte esta relacionada com a primeira. Ela representa a
instanciação e execução dos objetos criados anteriormente. Os objetos a serem
instanciados: task, tool, artifact, role, actor e agenda.

Type

is preceded by dependes on has

0+
produces 1+
Process Arterfact 0+ leader
has 1+ Task Type needs 1+ Tool Type 0+ Role Type
Architecture Type
0+
1+ 1+ handles 1+ 1+ 1+
manipulates
List of Actions
Types
List of Rights
uses
accesses
requires

refines

requires
accesses
uses

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

has 1
Agenda Actor

1+ 1+
is allocated to

has

Figura1 – Meta-modelo do processo de software

No Meta-modelo os tipos se relacionam entre si de vários 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 produção de um ou mais tipos de artefatos. Esta
produção 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 também 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].
 7

Quanto a parte instancia da do meta -modelo, o comportamento das suas relações são
mantidos da mesma forma que a parte anterior. Porém, nesta etapa teremos o acréscimo
dos atores(actors), que são os usuários responsáveis pelo desenvolvimento do processo de
software. Cada ator possui um ou mais cargos(ou funções) dentro do ambiente.

2.4 Arquitetura do ExPSEE

A arquitetura do ExPSEE mostrada na figura 2, tem como meta separar os domínios de

gerenciamento do ambiente. Para isso, são utilizados módulos gerenciadores. O módulo
interface tem a responsabilidade de gerenciar a interação com o usuário. O módulo meta -
gerenciador de processos cuida da definição e manutenção das arquitetura de processos.
Outros módulos gerenciadores cuidam dos demais processos, entre eles:

?? o gerenciador de artefatos controla os produtos intermediários e finais do processo.

?? o gerenciador de ferramentas cuida das ferramentas utilizadas pelo ambiente.
?? o gerenciador de cargos e atores mantém a responsabilidade de controlar todos os
cargos relacionados aos respectivos atores/usuários do processo.
?? e por último, o gerenciador de tarefas cuida do escalonamento e execução das tarefas.

Interface

Gerenciador de Processos

Meta Gerenciador
de Procesos

Gerenciador de Gerenciador de Gerenciador de

Artefatos Tarefas Atores

Interpretador

Gerenciador de Gerenciador de
Ferramentas Cargos

base
de dados

Figura 2 – Arquitetura do Ambiente ExPSEE

 8

Além dos gerenciadores, existe um interpretador responsável pela definição das tarefas em
uma linguagem de programação de processos. Para um processo ser especificado e
executado pelo gerenciador de processos, é necessário a especificação destes em uma
linguagem de programação de processos[GIM98].

2.5 Linguagens de Programação de Processos

O objetivo de uma linguagem de programação de processos é produzir programas que

permitam a implementação do processo de software.

Com a descrição de processos se torna possível implementar processos de software. Essa

descrição tem como meta, guiar e especificar o desenvolvimento de um produto de
software[GIM97].

Os programas de processos de software apresentam poucas semelhanças e muitas

diferenças se comparados com programas de aplicações típicas. Quando a questão esta
relacionada com a manipulação de informações(criação e modificação), tanto os programas
de processos, quanto os programas comuns apresentam as mesmas características. Porém,
se diferem pelo fato dos processos de software possuírem características distintas das
outras aplicações, como: objetos maiores e mais complexos, como o código fonte, testes,
resultados de testes e especificações. Logo as linguagens de programação de processos
devem ser mais abrangentes e poderosas que as linguagens de aplicações típicas ou
convencionais.

Em uma linguagem de programação de processos, características como mecanismo de

definição de tipos, de agregação de dados, de controle de fluxo e de controle de
concorrência são fundamentais. Logo, percebe-se a dificuldade e complexidade em definir
uma linguagem de processos de software.

Além disso, uma linguagem de processos requer o uso da abordagem multiparadigma, que
combina diferentes formas de representação. A aplicação de uma linguagem convencional
que só usa um paradigma, é improvável para uso em processos. Alguns conceitos do
 9

processos de software são mais adequados via determinadas linguagens de programação

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 definições para a programação de processos, como:
abstração de dados, compartilhamento de comportamento, evolução 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 PSEE’s, assim como nos SEE’s, os banco de dados devem permitir o acesso a uma
série de serviços básicos que manipulam com eficiência grande volumes de informações. O
conjunto de informações de um PSEE é uma de sua s principais virtudes, pois nele estão
incluídos serviços largamente utilizados pelo gerenciador de processos, tais
como[NAN95]:

?? Integridade de transações: responsável pelo controle das transformações executadas em

uma transação
?? Serviços de correção: dest inados a retornar a base de dados a um estado consistente,
quando houver algum erro.
?? Controle de concorrência: possibilitam o compartilhamento de certas partes da base de
dados por vários processos
?? Mecanismos de segurança: destinados a impedir que agentes não autorizados, tenham
acessos a determinados informações
?? Interface de comunicação de dados: através de uma interface é possível que usuários
acessem informações em uma base de dados
?? Serviços de integridade: controlam a inclusão e manipulação de dados, com o objetivo
de não deixa-los inconsistentes.
 10

2.7 Considerações Finais

Este capítulo apresenta os principais aspectos do ExPSEE(seu modelo e sua arquitetura),

ambiente que será a base do protótipo a ser realizado para avaliação das novas tecnologias
de rede ao PSEE`s.

Também são descritos a importância das linguagens de programação de processos,

principalmente a linguagem orientada a objetos, que é o caso de Java , além de uma
demonstração da importância da base de dados em um ambiente orientado a processos.
 11

Capítulo 3

A linguagem Java

Neste capítulo são apresentados os recursos Java a serem utilizados em um ambiente

distribuído e suas principais características como orientação a objetos, multiplatafoma,
entre outras. Posteriormente são ilustradas as técnicas de construção de interfaces a partir
de eventos. Por último são descritos os padrões de serviços orientados a objetos que
suportam um encontro com Java. Padrões estes como o RMI, CORBA e DCOM.

3.1 Os Recursos da Linguagem

Java é uma das linguagens de programação mais utilizadas e estudadas atualmente,

possuindo um conjunto de recursos tecnológicos não tradicionais, mas ideal para ser
aplicado em grandes redes de computadores.

Outra característica de Java é o fato de que ela não deixa de possuir uma sintaxe simples,
até mesmo tradicional, sendo muito parecida com C e C++.

As principais características da linguagem são destacadas a seguir:

Orientação a objetos

Em uma linguagem orientada a objetos, uma classe é uma coleção de dados e métodos que
operam sobre estes dados. Desta maneira, os dados representam as características do objeto
e os métodos descrevem seu comportamento.

Java possui um grande conjunto de classes(APIs9), arranjadas em pacotes[FLA97].

Exemplos de pacotes são o: Java.net, responsável por suportar facilidades networking , o

9
Application Programming Interfaces
 12

Java.lang, que possui a classe Object. Esta classe é responsável pelo comportamento geral
das outras classes.

As classes estão organizadas em uma hierarquia, onde uma subclasse pode herdar todo
comportamento de uma superclasse. As classes são unidades únicas e básicas de
compilação e execução em Java . Todos os programas em Java são formados por
classes[FLA97].

Multiplataforma

Java oferece a vantagem de ser uma linguagem interpretada. O compilador Java gera byte -
codes, para a Máquina Virtual Java , ao invés de código de máquina nativo[FLA97].
Assim, para rodar um programa cliente/servidor em Java , usa-se o interpretador Java (na
máquina cliente) para executar os byte-codes gerados na máquina servidora. A Máquina
Virtual Java e os interpretadores vem atualmente acoplados em web-browsers, através de
um ambiente run-time. Quando um programa em Java é carregado para a máquina cliente,
em forma de applets, na verdade são carregados os byte-codes já compilados na máquina
servidora. Dessa forma, o applet é um código interpretado através da Máquina Virtual Java
embutida nos browsers, tornando-o possível 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
característica de Java , sendo a principal motivação para o uso de um PSEE em ambientes
multiplataformas.

Uma linguagem dinâmica e distribuída

Java é uma linguage m que permite execução dinâmica. Qualquer classe pertencente a Java
pode ser carregada no interpretador Java em qualquer momento, sendo então instanciadas

10
Java Virtual Machine
 13

dinâmicamente. Bibliotecas de código nativo podem também ser carregadas

dinâmicamente[FLA97].

Java também é conhecida como distribuída, pelo fato de fornecer vários suportes de alto
nível 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 fácil o acesso a
um arquivo ou recurso remoto - como se fosse um arquivo ou recurso local.

Juntando estas duas características, torna -se possível acessar e executar códigos 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 aplicação de rede
GUI(Graphical User Interface) - baseando-se num web -browser - é fácil de imaginar
múltiplas atividades acontecendo em um mesmo tempo. Dessa maneira, podemos rotular
Java como sendo uma linguagem multithread[FLA97]. Java suporta múltiplos threads de
execução que podem aplicar-se a diferentes tarefas. Um importante benefício dos múltiplos
threads, é a melhoria ou aperfeiçoamento de desempenhos interativos de aplicações
gráfic as para o usuário.

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

3.1 Interface através de Eventos

A interface em Java, mesmo na forma de applets, oferece recursos voltados a aplicação de

eventos. O uso de eventos é uma forma alternativa e muito vantajosa, pois diminui de
maneira significativa os custos da construção de uma interface.
 14

Um evento pode ser disparado/acionado quando um botão ou um checkbox é executado,

por exemplo. Desta forma, os eventos são enviados aos seus receptores(métodos) através
do uso de listeners 12. Estes métodos tem a função de ajudar a execução de tais
eventos[FLA97].

Eventos são sempre enviados para os métodos chamados “receptores”. Para cada tipo de
evento existe um determinado listener que descreve o método que ele deve utilizar para
receber o evento correspondente[FLA97], conforme ilustra a figura 3.

"escuta" quando um
evento é acionado

Evento listener

Métodos
Receptores

Figura 3 – Aplicação de eventos em Java

Com a utilização de métodos receptores, não se torna necessário criar funções que
entendam que componentes da interface foram acionados. Nos métodos receptores é
definido o que acontece quando um componente é disparado. Métodos receptores fazem
parte do código fonte da interface.

O fato da interface ser carregada e executada na máquina cliente, significa que quanto
menor o número de linhas em um código muito mais interessante se torna a aplicação, pois
a quantidade de transferência de dados do servidor para o cliente é menor. As classes
usadas na construção da interface já estão localizadas no cliente, através dos browsers.

11
Uniform Resource Locators
 15

Os trechos do código fonte usado no protótipo, como mostrado nas figuras 5 e 6,

representam os conceitos de eventos em Java.

Evento

Com a criação do componente Button, o evento ActionEvent será guardado num

ContainerListener(Recipiente de Listener), mais precisamente no componentAdded. Este
último é um método 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 extends Applet implements

ActionListener, ContainerListener
{
addContainerListener(this);
........
public void componentAdded(ContainerEvent e){
{
........
ActionListener(this);
........
}
}
Figura 4 - Listeners

12
listeners: É a escuta da int erface inserida no código fonte que serve para informar quando um evento
pertencente a um componente foi disparado.
 16

Método Receptor do ActionEvent

Quando um evento é acionado é feito uma verificação no componentAdded. Se o Button

foi disparado, então o ActionListener é utilizado. Como ActionListener é o método receptor
de ActionEvent, é nele que será definido a sequência das aplicações, conforme mostrado
na figura 5. Por exemplo, quando o button “1.Inserir” é apertado/acionado, alguma
aplicação relacionada com o protótipo é iniciada.

public void ActionPerformed(Action Event e)

{
if (e.getActionCo mmand( ).
Equals( “1. Inserir” )
{
........
........
}
}
Figura 5 – Método Receptor

3.1.1 Referências de Eventos

Eventos em Java, são referenciados a partir de um conjunto de componentes ou classes

AWT13. Estes componentes permitem “disparos” de vários eventos. Cada componentes
está relacionado a um evento, enquanto um evento pode estar relacionado a vários
componentes.

A tabela 1 resume quais eventos(somente os usados na interface do protótipo) são

disparados por seus respectivos componentes, e quais os métodos receptores e os seus
listeners.

13
Abstract Window Toolkit
 17

Eventos Disparados por Listener Métodos Receptores

TextField
ActionEvent ActionListener ActionPerformed()
Button

List
ItemEvent ItemListener ItemStateChanged()
Choice

ComponentAdded()
ContainerEvent All Containers ContainerListener
ComponentRemoved()

Tabela 1 – Relação de eventos/listeners/mét odos receptores

3.2 Invocação de Métodos Remotos

Além dos recursos já descritos acima, Java oferece serviços orientados a objetos
distribuídos. Isto pode ser melhor detalhado através do método RMI.

RMI permite o uso de objetos distribuídos em redes heterogêneas como uma extensão da
programação orientada a objetos. A atuação destes objetos é a garantia de
interoperabilidade num sistema.

Um objeto RMI é um objeto remoto, cujos métodos podem ser chamados de outra máquina
virtual Java normalmente usando redes. RMI permite aos clientes interagir com o objetos
remotos via interfaces públicas. Os clientes não interagem diretamente com as classes que
implementam as interfaces[RAJ98].

Como sabemos, objetos distribuídos podem falhar pelos mais variados motivos, motivos
estes ainda mais variados do que em objetos locais. Então devemos ser capazes de tratar
exceções que possam ocorrer durante a chamada de um método remoto. Para isso, RMI
estendeu as características de tratamento de exceções em Java , facilitando o tratamento e
captura de falhas com objetos remotos[RAJ98].

Através do protocolo RMI, Java permite a serialização de seus objetos, que por sua vez
permite a transmissão de objetos via rede. Desta forma, é possível a criação de objetos
servidores e objetos clientes Java /RMI. O servidor é o responsável por definir uma
 18

instância da classe que implementa a interface remota. A interface remota deverá declarar
todos os métodos que serão chamados remotamente no servidor.

Para um cliente localizar um objeto remoto, pela primeira vez o RMI depende da execução
de um mecanismo chamado RMIRegistry. Este mecanismo é quem roda o servidor,
manipulando informações sobre os objetos servidores disponíveis, bem como mantém um
mapeamento entre os objetos do host e o nome com os quais foram registrados. Para a
aplicação cliente ser capaz de invocar um método de um objeto remoto servidor, o cliente
precisa primeiro adquirir uma referência para o objeto remoto. Na maioria das vezes, a
referência será obtida como valor de retorno de um método remoto ou como uma passagem
de parâmetro para tal método. Quando o objeto referenciado é encontrado no servidor,
ocorre a invocação de métodos do objeto servidor. Um objeto RMI pode ser referenciado
como se estivéssemos chamando um objeto local não remoto. Se o RMIRegistry não
estiver sendo executado, a conexão 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 referência a um objeto remoto pode ser obtida através da
passagem de parâmetros para métodos. Assim, quando um cliente invoca um método, os
parâmetros são transformados em blocos de dados(marshalling na linguagem RPC14) pelo
stub e são enviados a uma máquina servidora remota, através de um protocolo TCP/IP15 e
uma porta anônima de comunicação(Transport). Quando estes blocos de dados(ou
mensagens) chegam na máquina remota, eles serão transformados em
argumentos(unmarshalling) pelo skeleton. Em seguida, ocorre a chamada da
implementação do método convertendo o resultado do objeto referenciado em uma outra
mensagem, mas que será redirecionada à máquina cliente. O stub será novamente utilizado.
Agora ele é o responsável pela extração deste valor de retorno[RAJ98].

14
Remote Procedure Call
15
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 diferenças entre as várias
formas de protocolo usadas no servidor.

Figura 6 – Arquitetura de um RMI

3.3 Outros paradigmas de Objetos Distribuídos

Apesar do RMI ser um método original de Java e por isso só usado nesta linguagem,
existem outros tipos de métodos que oferecem serviços orientados a objetos, que permitem
uma integração com Java e valem ser citados. Os mais conhecidos são 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 comunicação entre o cliente e o servidor. O ORB está
localizado no servidor e tem a função de localizar um objeto invocado(através de métodos)
e encaminhá-lo de volta ao cliente que fez o pedido. Cada objeto servidor CORBA tem
uma interface que expõe um conjunto de métodos. Para realizar um serviço, o cliente
adquiri uma referência do objeto remoto, exatamente como no RMI, a não ser pelo fato de

16
Object Request Broker
 20

que CORBA utiliza o ORB e não o RMIRegistry. A invocação de métodos também

funciona de maneira muito parecida[RAJ98]

DCOM

DCOM é um Modelo de Componentes de Objetos Distribuídos pertencente à Microsoft? .

O DCOM dentre os métodos remotos, é o que menos apresenta coincidências com o RMI e
CORBA. Apesar das diferenças, ele suporta a invocação de objetos remotos rodando em
um protocolo chamado ORPC(Object Remote Procedure Call). O ORPC é construído
sobre as bases de funcionamento do RPC e interage com os serviços run-time COM. Cada
objeto servidor DCOM pode suportar múltiplas interfaces, onde cada uma representa um
comportamento diferente de objeto. Um cliente DCOM chama os métodos expostos em um
servidor através 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. Também é o
fundamento tecnológico para ActiveX e para o Microsoft Internet Explorer[RAJ98].

3.4 Considerações Finais

Neste capítulo mostramos os aspectos principais da linguagem Java, bem como abordamos
alguns padrõe s de comunicação de objetos distribuídos, em particular o Java RMI. Como o
interesse principal deste trabalho é testar o uso de Java em PSEE’s, adotamos o RMI,
como padrão de comunicação no nosso protótipo.
 21

Capítulo 4

Soluções Java para o ExPSEE

Este capítulo da monografia destina -se ao estudo dos recursos oferecidos pela linguagem
Java voltados para um ambiente ExPSEE. Para a realização do estudos foram aplicadas
técnicas de programação e também conhecimentos teóricos de Java amplamente aceitos no
âmbito computacional. Com isso, foi possível a construção de um protótipo com vistas a
realização de testes operando em modo cliente/servidor.

Primeiramente, é discutido a construção e aplicação das interfaces do protótipo. Na

sequência é apresentado um estudo do banco de dados para PSEE’s. E por último, os
detalhes do desenvolvimento e construção do protótipo do gerenciador de processos, bem
como os seus módulos gerenciadores.

4.1 O modelo MVC

O modelo MVC 17, mostrado na figura 7, tem como objetivo a representação de uma
estrutura básica formada por classes concretas e abstratas e seus relacionamentos, sendo
esta estrutura chamada de framework . Um framework MVC é um método de construção
que separa logicamente interface, estrutura e comportamentos em vários módulos. Dessa
forma, é possível a implementação de um protótipo sujeito a substituições, 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
substituído por vários tipos de interfaces. Desta forma, um simples banco de dados pode ter
várias visões, mostrando diferentes representações dos dados pertencentes ao ambiente.

O modelo MVC pode ser melhor caracterizado e separado através da :

17
Model/View/Controller
 22

?? Visão: responsável pela interface e seus componentes.

?? Controlador : responsável pela integração entre objetos do modelo(base de dados) e
objetos da visão.
?? Modelo : responsável pelas especificações do sistema. Compreende as ferramentas
utilizados pelo ambiente e principalmente o banco de dados.

Desta maneira a visão é responsável por capturar eventos disparados, o Controlador pela
interpretação das ações passadas à ele pela Interface e pela realização de determinado
serviço, utilizando o modelo de dados. O resultados processados na base de dados(Modelo)
retornam ao Controlador, sendo padronizadas por ele, para então serem processadas, agora
pela interface. E neste momento que o feedback com o usuário ocorre[ITO97].

Usuário

Manipulação realimentação

Visão

ação ações
interpretada solicitadas

Controlador

ações resultados
solicitadas

Modelo

Figura 7 – Modelo MVC

A linguagem Java apresenta além da orientação à objetos, a ocorrência de eventos. Isto

ocorre através dos componentes AWT que passam eventos do código fonte para os
“listeners”. Esta passagem de eventos possui uma parte do conceito de MVC, ou seja,
possibilita a separação de implementação de um objeto de seu comportamento, fazendo
com que os componentes de interface construídos possam ser reutilizáveis[FLA97]. O
termo reutilizável significa que em caso de alterações 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 separação de estrutura (modelo), representação (visão) e

comportamento (controle). Desta forma, no nosso protótipo adotamos o modelo MVC para
realizar a comunicação cliente com o servidor do ambiente.

4.2 Projeto da Arquitetura do Ambiente

Com o estudo de aplicações Java , banco de dados e principalmente RMI foi possível
realizar uma nova arquitetura de ambiente, que é apresentado na figura 8. Ela caracteriza-
se pelo fato de que é baseada na arquitetura proposta pela do ExPSEE.

Cliente
HTML/Applets
(GerenciaApplet)
Web Browser
Ambiente Run-time
Interface
Carregador de classes
Verificador de byte-code
Interpretador de Byte-code
JVM
Bibliotecas de
classe Java

RMI

Máquina
Servidora

Método Remoto
(método_remoto) Gerenciador de Processos e
Gerencador de Processos seus módulos
(Gerencia)
classes
(módulos)
tarefas cargos ferramentas artefatos

SGBD

MySQL
Repositório de Dados
Servidor
de Banco de Dados

Figura 8 – Arquitetura do Ambiente

 24

A seguir, vamos descrever a interface, o repositório de dados, o gerenciador de processos,

os módulos gerenciadores e explicar como eles se relacionam. O gerenciador e seus
módulos são os últimos a serem ilustrados, pois neles é que se concretizam as relações com
a interface e o banco de dados.

4.3 A Interface do Ambiente

O objetivo da interface do ExPSEE é permitir a manipulação dos tipos existentes em uma

arquitetura de processos e posteriormente a execução dos objetos definidos e instanciados
a partir dos relacionamentos existentes entre os tipos do processo.

A interface do ambiente, através de applets Java, foi construída através de recursos

voltados a aplicação de eventos, como descrito no capítulo 3, operando em modo
cliente/servidor.

As figuras 9 e 10 mostram os protótipos da interface do Gerenciador de Processos

funcionando através do browser Netscape. As telas se baseiam no relacionamento dos tipos
pertencentes a arquitetura do ambiente ExPSEE(ver capítulo 2). Os arquivos utilizados são
páginas 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 não ser pelo número de relacionamentos que cada tipo comporta.

Figura 9 -Tela de apresentação do PS EE

18
Hiper Text Markup Language
 25

Figura 10 -Tela do tipo tarefa

4.4 Aplicação de Banco de Dados

A consulta a banco de dados através da web (especificamente através de applets Java ) é

capaz de gerar o resultado de uma pesquisa em tempo de execução, como se fosse em um
computador pessoal. Porém, as consultas do usuário são repassadas ao servidor e
posteriormente repassados do seu repositório de dados ao cliente localizado em qualquer
ponto da rede, não importando a plataforma de hardware ou software usado pelo usuário –
eles são totalmente independentes. Logo, o impacto da atualização de versões 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 conexão cliente/servidor.
 26

Applets não precisam instalar, desinstalar ou configurar o repositório de dados, como

alguns outros assistentes de banco de dados utilizados na web[BAR98]. O cliente é
somente encarregado da apresentação dos dados. Logo, os applets permitem a construção
de um cliente leve, de forma nenhuma sobrecarregado. A sobrecarga fica no servidor e na
rede, que são os responsáveis pelas configurações necessárias[BAR98].

Para a utilização de applets Java e banco de dados, é necessário a utilização do driver

JDBC19 . Com relação a base de dados usada neste projeto, a escolhida foi a MySQL
descrita na seção 4.3.3.

4.4.1 JDBC

O JDBC é um conjunto de classes e interfaces em Java feitos para executar declarações

SQL20. Através de um programa que usa o driver JDBC se torna fácil enviar declarações
SQL para qualquer base de dados, principalmente as relacionais[SUN97]. Com o uso do
JDBC e Java, é possível publicar uma página na web contendo um applet com as
informações obtidas de um banco de dados remoto sem nenhum problema.

4.4.2 Os Modelos Duas-Camadas e Três-Camadas

Para a aplicação de um banco de dados em applets, existem dois modelos que podem ser
seguidos. O modelo duas-camadas e o modelo três-camadas.

No modelo de dua s-camadas, conforme ilustra a figura 11, um applet Java fala diretamente
com a base de dados instalado na própria máquina servidora. O driver JDBC se comunica
com o sistema gerenciador da base de dados inicialmente acessado[SUN97]. Este modelo é
baseado na configuração cliente/servidor, onde a máquina do usuário serve como cliente, e
a máquina onde está alojada o banco de dados como servidor. O JDBC é carregado para
um cliente, quando o applet Java é referenciado na máquina servidora.

19
Java DataBase Connectivity
 27

Aplicação Java Máquina

Cliente
JDBC

SGBD-protocolo
proprietário

Banco de Servidor da Base de

Dados Dados

Figura 11- O mode lo de duas camadas

O modelo de três-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
repositório de dados, mas com o JDBC inserido. O SGBD21 fica numa outra máquina,
chamada de servidor de base de dados.

Com a camada do meio, é possível a utilização do Método de Invocação Remoto(RMI).

Isto significa que driver JDBC está localizado na máquina servidora e não mais na
máquina cliente. Isto permite que applets sejam carregados no cliente de forma mais leve,
pois quando uma declaração SQL é executada, não cabe mais ao cliente passar a
consulta(enviar a declaração) ao servidor. O próprio servidor é que irá realizar a consulta
ao banco de dados. Isto é poss ível, pois o RMI envia parâmetros para o servidor indicando
qual objeto deve ser consultado. Logo, o cliente não é mais o responsável por realizar a
consulta.

Applet Java ou Máquina Cliente

browser HTML (GUI)

HTTP,RMI, CORBA
Aplicação Máquina
Servidora(Java) Servidora
(Camada do Meio)
JDBC
SGBD - protocolo
proprietário
Banco de Servidor da Base de
dados Dados

Figura 12 - O modelo três -camadas

Um link entre a máquina servidora(camada do meio) e o servidor de banco de dados é o

responsável pela transferência de dados do SGBD para a máquina servidora e vice-versa.

20
Structured Query Language
21
Sistema Gerenciador de Banco de Dados
 28

Para que isso funcione, é preciso ser declarado o nome da máquina servidora de banco de
dados no arquivo que contém o JDBC.

Este modelo traz certas vantagens em relação ao de duas-camadas, como manter um

melhor controle sobre acessos e atualizações que podem ser realizadas no banco de
dados[SUN97]. Isto ocorrerá no próprio servidor e não mais num cliente remoto. Além do
que, servidores possuem mais recursos que máquinas clientes.

Através das vantagens mostradas neste projeto, optou-se pelo modelo de três camadas para
a ser utilizado no projeto. Ainda em relação ao desenvolvimento do projeto, são utilizadas
três máquinas. Uma contendo a interface(cliente), e outras duas atuando como servidores.

Outra vantagem é que o usuário pode empregar uma API de alto-nível traduzida pela
camada do meio em uma chamada de baixo-nível[SUN97]. Logo, esta camada do meio
pode providenciar uma melhora de desempenho, compensando a desvantagem da
transferência de dados entre três camadas ao invés de duas.

Abaixo está um pequeno exemplo de como o JDBC pode ser usado em um applet. A
declaração dbUrl contém o endereço do servidor de dados.

Definição das variáveis

String informações;
String dbUrl="jdbc:mysql://caqui.din.uem.br :3333";
String user="anonymous";
String password="*****";

Carregando o driver

Class.forName("gwe.sql.gweMysqlDriver");

Setando a conexão
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");

informações = rs.getString(0)

4.4.3 MySQL

MySQL é um banco de dados relacional, com certo reconhecimento no mercado. Permite o

uso de multi-usuários através de threads, constituindo-se assim, de uma implementação
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 integração com o JDBC,
porém 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 não equivalente ao armazenado no banco de dados. O uso de um banco de dados
orientado à objetos facilitaria a resolução deste problema[MAU98], porém para efeito de
prototipação, o MySQL mostrou-se mais adequado devido a disponibilidade e facilidade de
uso.

Neste projeto, o MySQL apresenta uma boa integração com o driver JDBC Java ,
facilitando muito a integração Java/MySQL. A bases de sua construção suportam um
conjunto de rotinas, o que garante a sua usabilida de por um bom tempo[MYS98].

Entre as suas principais características, podem ser citadas[MYS98]:

?? trabalha com vários 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 temporárias)
?? rápido sistema de alocação de memória baseada em threads

O uso de declarações 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

gerência 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 construído prevendo a existênc ia de uma base

de dados ligada diretamente aos tipos e relacionamentos da arquitetura propostos pelo
próprio ExPSEE(ver capitulo 2). A partir desta base de dados é permitido um controle
gerenciado do compartilhamento de informações entre as ferramentas do ambiente.

Para a realização de uma melhor integração entre a base de dados do ambiente e o

gerenciador de processos, outros produtos podem ser adicionados ao ambiente. Serviços
orientados a objetos, como CORBA, DCOM ou RMI, tem muito a ver com este traba lho e
podem oferecer funcionalidades a intercomunicação de serviços.

Java possui as características e as bibliotecas necessárias para um encontro com

CORBA[BRA98], mesmo em nível de redes, ou mais precisamente através da web.
DCOM também oferece recursos para Java, porém fica restrito ao uso do produtos
pertencentes a Microsoft. Para o RMI basta citar que ele é uma extensão da programação
orientada a objetos de Java, onde estes objetos podem ser distribuídos através de redes. A
atuação destes objetos é a garantia da interoperabilidade num sistema.
 31

RMI foi o método priorizado no projeto, não pelo fato de ser o padrão mais adequado, mas
simplesmente por ser um método oriundo e exclusivo de Java. Desta forma, a idéia
principal do projeto é seguida - o desenvolvimento de PSEE para testes baseado somente
em técnicas de programação Java .

4.5.1 Módulos Gerenciadores

A arquitetura do ExPSEE caracteriza -se por separar os domínios de gerenciamento do

ambiente em vários módulos gerenciadores(cargos, tarefas, artefatos e ferramentas)
conforme discutido no capítulo 2. Para realizar esta separação de domínios de
gerenciamento, RMI permite a criação e instanciação de classes(ou objetos) ligados
diretamente ao gerenciador de processos, funcionando como verdadeiros módulo
gerenciadores. São eles:

?? a classe tarefa
?? a classe cargo
?? a classe ferramenta
?? a classe artefato

O uso de Java/RMI em um PSEE fornece o suporte necessário para que elementos de um

módulo gerenciador sejam manipulados e executados através da web .

4.5.2 Manipulação de Objetos

Para um objeto ser manipulado, Java /RMI fornece um conjunto de facilidades que
permitem a integração entre interface e gerenciador de processos e repositório de dados,
em modo cliente/servidor. Como facilidades, podem ser citadas a implementação de uma
interface remota localizada no servidor onde são declarados todos os métodos que serão
chamados remotamente. Neste projeto bastou a definição de um método. Este método é
que faz o papel do gerenciador de processos.
 32

Definindo a interface remota

Definir uma instância de classe que implementa a interface remota e manipula exceções
que podem ocorrer durante a chamada de um método remoto é um dos recursos disponíveis
desta interface (declarada através de uma classe java.rmi.RemoteException pertencente a
Java). A interface remota deve ser declarada no servidor e deve também 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 método metodo_gerencia for referenciado(chamado), conforme mostra a

figura 13, pelo cliente é retornado uma String valor como resposta. Os valores de retorno
dos métodos 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 implementação do objeto remoto

Um objeto deve declarar que é implementação de pelo menos uma interface remota(através
do UnicastRemoteObject) e desta forma criar um objeto remoto simples. Assim, é possível
fornecer implementações para os métodos que podem ser invocados remotamente, como
ilustradas na figura 14.
Também deverão ser criadas uma ou mais instâncias do objeto remoto para ficarem
disponíveis à aplicação cliente(através do Gerenciador obj). Uma vez criado este objeto,
ele estará pronto para escutar alguma "chamada" remota do cliente.
 33

A função Naming.rebind(), localizada imediatamente depois do objeto Gerenciador mostra

o endereço deste objeto instanciado(qual a máquina que ele se encontra).

Gerenciador funciona como o gerenciador de processos do ambiente, pois é nele que serão
especificados a sequência de processos. Os parâmetros int evento pertencentes a valor()
(invocados através do cliente) são 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 parâmetro igual a
1 será indicado qual aplicação e qual módulo gerenciador vai realizá-la. Se o parâmetro for
diferente de 1, então outros módulos serão comunicados.

Uso de classes

As classes usadas no ambiente, apresentadas na figura 15, estão diretamente relacionadas

com o uso de módulos gerenciadores. Módulos realizam os passos do ciclo de
desenvolvimento do software, através do gerenciador de processos que indica qual o
módulo(de cargos, ferramentas, artefatos e tarefas) que deverá ser usado.

O driver JDBC(responsável pela comunicação com a base de dados MySQL) está instalado
nos módulos. Com isso é possível um módulo gerenciador pode obter as informações
necessárias para o desenvolvimento deste processo inseridas no banco de dados. Logo, ele
está separando os domínios de gerenciamento.

O return , localizado no fim do arquivo contém os dados a serem retornados pelo módulo
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 informações;
........
(realiza as consultas ao banco de dados)
return informações;
}
}
Figura 15 – Módulos Gerenciadores
 35

Escrevendo o programa cliente

Através de cada um dos applets (ou simplesmente interfaces do ambiente) é possível a

invocação do método remoto metodo_gerencia . Posteriormente haverá um retorno deste
método referenciado inicialmente pelo cliente, através da String valor().

RMI providencia um registro baseado em URL, permitindo a localização de uma URL

através da declaração Naming.lookup() pertencente ao método metodo_gerencia . Nesta
declaração é definido o host da máquina servidora. Ou seja, onde está o gerenciador de
processos e consequentemente seus módulos.

O applet, apresentado na figura 16, também invoca valor(1) como um objeto e até os seus
parâmetros. O seu valor de retorno será armazenado em uma var iável 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á construída uma página HTML, ilustrada na figura 17, onde será carregado o
applet Java. Depois de compilado na máquina servidora, o applet recebe a extensão class e
 36

é transformado em byte-codes. Assim, está pronto para ser usado pelos padrões da web e
pela máquina cliente(onde o applet fica instalado) .Os applets diferem entre si, somente no
momento que invocam o objeto valor() através de parâmetros diferentes, ou seja, quando
indicam qual processo deve ser aplicado pelo gerenciador.

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

Figura 17 – Página HTML onde é carregado o applet

4.6 Testes

As operações realizadas para testes do protótipo são baseadas na manipulaçã o de

declarações SQL realizadas pelos módulos gerenciadores localizados no servidor. Ao
recuperar informações, o valor é repassado ao método manipulador e posteriormente
carregado na interface do ambiente.

Quanto as outras características, o PSEE baseado em Java é projetado para rodar através
da Internet com o auxílio de arquivos HTML, próprios para o protocolo HTTP, enquanto
que o ExPSEE usa uma pequena rede centralizada.

Abaixo estão os testes escolhidos para o desenvolvimento do projeto em Java. O uso de

métodos, classes, objetos e repositório de dados são fundamentais para todas operações.

Criação de arquitetura de processos

Inclusão dos tipos cargos, tarefas, artefatos e ferramentas. A criação de uma arquitetura de
processos será parecida com a do projeto ExPSEE e a sua principal característica está no
relacionamento entre os tipos existentes. Assim que criados, os dados serão 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 não se deseja mais utilizar determinados tipos(ou dados) de uma arquitetura eles
são removidos da base de dados.

Todos estes testes precisam explorar bem a integração repositório de dados e classes
remotamente instanciadas, pois é através desta comunicação que serão realizadas as
declarações SQL, como INSERT, REMOVE e SELECT .

4.7 Considerações Finais

A aplicação de um modelo de três 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 manipulação de informações. Cabe ao
gerenciador de processos e seus módulos gerenciadores localizados no servidor e ao
sistema gerenciador de banco de dados também localizado no servidor mas em outra
máquina, realizar estas aplicações.
 38

Capítulo 5

Conclusões

Mesmo não tendo oportunidade de desenvolver um maior número de testes(foram

realizados alguns a partir da construção de um protótipo) os estudos realizados neste
trabalho revelaram que Java possui os recursos necessários 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 distribuídos, fez de Java a
linguagem ideal para o desenvolvimento deste trabalho. Java possui fortes “laços” com o
paradigma cliente/servidor, além de poder ser aplicado em qualquer plataforma, permitir a
criação e manipulação de threads e muitos outros fatores já citados neste trabalho. Tudo
isso mostra que atualmente Java aponta como uma das melhores linguagens de
programação 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 realização de poucos testes deveu-se muitas vezes as dificuldades encontradas na

construção das camadas de comunicação entre cliente e servidor, e entre servidor e
servidor de dados, onde cada um é representado por uma máquina. Apesar destas
dificuldades, pode –se realizar a arquitetura do protótipo em três-camadas, oferecendo ao
cliente uma interface totalmente desprovida de execuções. Todas elas são referenciadas
pelo cliente e executadas nas máquinas servidoras.

Com isso, objetivou-se a aplicação de testes mais nas formas de integração de banco de
dados, módulos gerenciadores, gerenciadores e interface.

O uso do driver JDBC oferece um bom suporte de integração entre o ambiente e banco de
dados MySQL. Um banco de dados constitui a base de todas as informações de um PSEE.
 39

O RMI também providencia suportes para construção de PSEE, pois oferece recursos de
orientação a objetos estendido para uso em redes através de protocolos HTTP.

Com RMI é possível usar métodos de invocação remota(neste trabalho foi usado apenas
um) funcionando como um gerenciador de processos. Assim, este método é usado como
um gerenciador de PSEE, podendo dizer quais aplicações serão realizadas e por qual
módulo.

Mesmo o RMI sendo testado, analisado e observado como um método muito útil na
construção de PSEE’s, podemos referenciar CORBA como o padrão que melhor oferece
serviços de integração de objetos remotos. Desta forma, CORBA pode ser destacado para
futuros trabalhos envolvendo Java e PSEE, pois apresenta:

?? melhores níveis de desempenho que o RMI

?? referência a objetos persistentes
?? protocolo independente de linguagem
?? escalonamento universal via IORs, DSI, GUIDs, IIOP e inter-ORBs
?? Java oferece todas as bibliotecas necessárias para um encontro com CORBA e a web

Com mostra a comparação, CORBA está a frente de RMI tanto em desempenho quanto no
número de recursos oferecidos[UNI98]. Mas, RMI apresenta facilidades que não seriam
encontradas em CORBA, tais como:

?? faz passagem de objetos por valor

?? usa Java tanto como linguagem de definição de interfaces como linguagem de
implementação
?? usa nomes baseados em URL
 40

Além de CORBA, outras aplicações Java podem ser destacadas para futuros trabalhos, tais
como:

?? uso de threads. Voltados a resolução de problemas de concorrência, pois como o

ambiente é construído em redes, diferentes usuários podem tentar acessar uma mesma
operação num mesmo instante de tempo.
?? aplicação 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

Referência Bibliográficas

[BAR98] Baruzzi, Flávio. Por que Integrar Bancos de Dados à World Wide Web ,
Developer’s 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 programação cliente servidor, XII
Simpósio Brasileiro de Engenharia de Software : Tutorial, 1998.

[FLA97] Flanagan, D., Java in a Nutshell

2 a Edição, O'Reilly & Associates, Inc.,1997.

[GIM97] Gimenes, Itana M.S., Fantinato, Marcelo e Carniello, Andréia. Relatório 1 –

Projeto ExPSEE, Universidade Estadual de Maringá, 1997.

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

[ITO97] Ito, Sérgio Akira. Prototipação da Interface com o Usuário de um Gerenciador

de Processos de Software, Universidade Estadual de Maringá,1997.

[MAU98] Mauro, Renato Campos e Mattoso, Marta Lima de Queirós. Integração de

LPOO e BDOO : Uma experiência com Java e GOA++, XIII Simpósio Brasileiro de
Banco de Dados: Anais, 1998.

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

[NAN95] Nanni, Edicezar Leandro. Construção 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 Aplicação 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 Edição, 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., Introdução a Java, Universidade Federal de Pernambuco,1997.