desenvolvimento de um sistema de leilÃo utilizando
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
(Bacharelado)
DESENVOLVIMENTO DE UM SISTEMA DE LEILÃO UTILIZANDO JAVASERVER PAGES
TRABALHO DE CONCLUSÃO DE CURSO SUBMETIDO À UNIVERSIDADE REGIONAL DE BLUMENAU PARA A OBTENÇÃO DOS CRÉDITOS NA
DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE CIÊNCIAS DA COMPUTAÇÃO — BACHARELADO
CHARLES BURKHARDT
BLUMENAU, JUNHO/2001
2001/1-15
ii
DESENVOLVIMENTO DE UM SISTEMA DE LEILÃO UTILIZANDO JAVASERVER PAGES
CHARLES BURKHARDT
ESTE TRABALHO DE CONCLUSÃO DE CURSO, FOI JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS NA DISCIPLINA DE TRABALHO DE
CONCLUSÃO DE CURSO OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE:
BACHAREL EM CIÊNCIAS DA COMPUTAÇÃO
Prof. Dr. Paulo Rodacki Gomes — Orientador na FURB
Prof. José Roque Voltolini da Silva — Coordenador do TCC
BANCA EXAMINADORA
Prof. Dr. Paulo Rodacki Gomes Prof. Marcel Hugo Prof. Ricardo Guilherme Radünz
iii
AGRADECIMENTOS
Agradeço a todos aqueles que me acompanharam durante toda esta caminhada. Aos
funcionários e professores do departamento e aos amigos de estudo. Agradeço, também ao
meu orientador, pelas sugestões e constribuições que ajudaram no enriquecimento deste
trabalho e a QuickSoft, por fornecer os equipamentos e tecnologias indispensáveis na
realização deste trabalho. E por fim, agradeço a meus familiares pelo apoio nesta importante
fase de minha vida.
iv
SUMÁRIO
LISTA DE FIGURAS ...............................................................................................................vi
LISTA DE QUADROS ............................................................................................................vii
RESUMO ................................................................................................................................viii
ABSTRACT ..............................................................................................................................ix
1 INTRODUÇÃO...................................................................................................................1
1.1 OBJETIVOS DO TRABALHO........................................................................................2
1.2 ESTRUTURA DO TRABALHO .....................................................................................2
2 FUNDAMENTAÇÃO TEÓRICA ......................................................................................4
2.1 HISTÓRICO DA ARQUITETURA DE SOFTWARE ....................................................4
2.1.1 ARQUITETURA DE UMA CAMADA ........................................................................4
2.1.2 ARQUITETURA DE DUAS CAMADAS ....................................................................5
2.1.3 ARQUITETURA MULTI-CAMADAS.........................................................................6
2.2 A ARQUITETURA MULTI-CAMADAS E A INTERNET ...........................................8
2.2.1 COMMON GATEWAY INTERFACE (CGI) ...............................................................9
2.2.2 COLDFUSION.............................................................................................................10
2.2.3 ACTIVE SERVER PAGES (ASP) ..............................................................................10
2.2.4 SERVER-SIDE JAVASCRIPT (SSJS)........................................................................10
2.2.5 PHP...............................................................................................................................11
2.2.6 APPLETS E SERVLETS.............................................................................................11
2.2.7 JAVASERVER PAGES (JSP) .....................................................................................12
2.2.8 COMO JSP FUNCIONA .............................................................................................14
2.2.9 JAVASERVER PAGES E MULTICAMADAS..........................................................17
v
2.2.10 JAVABEANS & ENTERPRISE JAVABEANS..........................................................19
2.2.11 A SINTAXE JSP ..........................................................................................................21
2.2.11.1 DIRETIVA PAGE .....................................................................................................21
2.2.11.2 TAG JSP:USEBEAN.................................................................................................22
2.2.11.3 TAG JSP:SETPROPERTY........................................................................................23
2.2.11.4 TAG JSP:GETPROPERTY .......................................................................................23
2.2.11.5 TAG JSP:FORWARD ...............................................................................................24
2.2.11.6 SCRIPTLET...............................................................................................................24
3 DESENVOLVIMENTO DO TRABALHO......................................................................26
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ....................26
3.2 ESPECIFICAÇÃO..........................................................................................................27
3.2.1 DIAGRAMA DE CASOS DE USO.............................................................................27
3.2.2 DIAGRAMA DE CLASSES........................................................................................28
3.2.3 DIAGRAMAS DE SEQUÊNCIA................................................................................31
3.3 IMPLEMENTAÇÃO......................................................................................................34
3.3.1 TÉCNICAS E FERRAMENTAS UTILIZADAS ........................................................34
3.3.1.1 CAMADA DA LÓGICA DE ACESSO AOS DADOS.............................................35
3.3.1.2 CAMADA DAS REGRAS DE NEGÓCIO...............................................................38
3.3.1.3 CAMADA DA LÓGICA DE APRESENTAÇÃO ....................................................41
3.3.2 OPERACIONALIDADE DA IMPLEMENTAÇÃO...................................................42
4 CONCLUSÕES.................................................................................................................47
4.1 EXTENSÕES..................................................................................................................48
REFERÊNCIAS BIBLIOGRÁFICAS .....................................................................................49
ANEXOS..................................................................................................................................51
vi
LISTA DE FIGURAS
Figura 1 – Arquitetura de uma camada ......................................................................................4
Figura 2 - Arquitetura cliente-servidor.......................................................................................5
Figura 3 - Arquitetura cliente-servidor com “fat client” ............................................................6
Figura 4 - Arquitetura cliente-servidor com “fat server” ...........................................................6
Figura 5 - Arquitetura multi-camadas ........................................................................................7
Figura 6 - Processo do servidor para criação e execução de servlet JSP..................................16
Figura 7 - JavaServer Pages implementando multi-camadas ...................................................17
Figura 8 – Diagrama de casos de uso .......................................................................................28
Figura 9 – Diagrama de classes ................................................................................................30
Figura 10 – Diagrama de sequência (Efetuar cadastro)............................................................31
Figura 11 – Diagrama de sequência (Autenticar empresa).......................................................32
Figura 12 – Diagrama de sequência (Anunciar produto) .........................................................32
Figura 13 – Diagrama de sequência (Realizar proposta)..........................................................33
Figura 14 – Diagrama de sequência (Fechar negociação)........................................................33
Figura 15 – Tela de cadastramento de empresa........................................................................42
Figura 16 – Tela de autenticação..............................................................................................43
Figura 17 – Tela principal do sistema ......................................................................................44
Figura 18 – Tela de cadastramento de novo anúncio ...............................................................45
Figura 19 – Tela de detalhamento do anúncio..........................................................................46
vii
LISTA DE QUADROS
Quadro 1 - Exemplo de JavaBean ............................................................................................20
Quadro 2 – Exemplo da diretiva page ......................................................................................22
Quadro 3 - Exemplo de <jsp:useBean>....................................................................................22
Quadro 4 - Exemplo de <jsp:setProperty> ...............................................................................23
Quadro 5 - Exemplo de <jsp:getProperty>...............................................................................24
Quadro 6 - Exemplo de <jsp:forward>.....................................................................................24
Quadro 7 - Exemplo de scriptlet...............................................................................................25
Quadro 8 – Tabela AREAS_ATUACAO.................................................................................35
Quadro 9 – Tabela EMPRESAS...............................................................................................36
Quadro 10 – Tabela ANUNCIOS.............................................................................................36
Quadro 11 – Tabela PROPOSTAS...........................................................................................36
Quadro 12 – Exemplo de acesso ao banco de dados utilizando JDBC ....................................37
Quadro 13 – Trecho do código da página be1080.jsp (novo anúncio).....................................39
Quadro 14 – Trecho do código da página be1080process.jsp (novo anúncio).........................40
viii
RESUMO
O presente trabalho trata de sistemas distribuídos multi-camadas. Tais
sistemas apresentam uma arquitetura distribuída separada em camadas lógicas,
e permite uma melhor estruturação da distribuição do sistema em redes. Para
validar o estudo realizado, foi implementado um protótipo de sistema de
leilão compatível com a web utilizando JavaServer Pages e Oracle. O sistema
implementa o conceito multi-camadas utilizando uma tecnologia de geração de
conteúdo dinâmico para internet denominada JSP (Java Server Pages), bem como
alguns recursos de JavaBeans, HTML e Javascript.
ix
ABSTRACT
The present work deals with multi-tier distributed systems. Such distributed
systems present an architecture based on separate logical layers, which
provides a better distributed structure for systems running over computer
networks. As a demonstration of the theory, a software prototype for
internet auctions is implemented using JavaServer Pages and Oracle. The
prototype implements multi-tier concepts using a dynamic web pages
generation technology called Java Server Pages (JSP), as well Javabeans,
HTML and Javascript technologies.
1
1 INTRODUÇÃO
Atualmente, a tecnologia da informação é algo que traz um diferencial competitivo
para as organizações, fundamental para que estas alcancem seus objetivos, buscando a
qualidade de seus produtos e satisfação de seus clientes.
Como a maioria dos campos de empenho humano, as tecnologias projetadas para o
desenvolvimento de aplicações vem evoluindo constantemente. Dando maior ênfase à
arquitetura de software, que desde o princípio vem passando por importantes mudanças no
que diz respeito à divisão das aplicações em camadas independentes. Com o surgimento das
redes locais, as aplicações deixaram de ser executadas em somente uma máquina, como por
exemplo os mainframes, e passaram a ser divididas em duas partes: cliente e servidor. Depois
surgiu o conceito de aplicações distribuídas, e logo a seguir, com a popularização da internet,
surgiu a arquitetura denominada multi-camadas, que divide as aplicações em tres ou mais
partes, normalmente: lógica da aplicação, acesso aos dados e interface com o usuário (Ntier,
1999).
O presente trabalho propõe apresentar um estudo sobre o desenvolvimento de sistemas
em multi-camadas, implementando um sistema de leilão para internet, utilizando JavaServer
Pages e Oracle.
O sistema de leilão é direcionado para empresas que buscam uma vantagem
competitiva através de um sistema que seja independente de plataforma, robusto, seguro e
acessível através da internet.
A idéia do sistema surgiu de uma necessidade real, levantada por empresas da região
de Blumenau e repassadas para uma empresa de informática, a QuickSoft. Tais necessidades
dizem respeito à redução de custos operacionais e de estoque, muitas vezes oriundos de
produtos que possuem pouca saída ou por serem de segunda qualidade.
No sistema é possível que empresas anunciem seus produtos, ao mesmo tempo que
podem realizar propostas para produtos anunciados por outras empresas. Tais operações
podem ser realizadas depois do cliente fazer o cadastro no sistema. Tendo o CGC e a senha
em mãos, o mesmo pode consultar anúncios classificados em áreas de atuação, como por
exemplo, anúncios de indústrias têxteis. Quando realizado o anúncio de um produto, é
2
informado o valor mínimo e a data limite do mesmo. Encerrada a data limite, a negociação é
realizada com a empresa anunciante e a empresa cujo valor da proposta superou as demais.
Para satisfazer as necessidades do sistema, como a independência de plataforma, a
segurança e robustez, buscou-se uma tecnologia que implementasse o conceito de
desenvolvimento em multi-camadas, e que pudesse ser disponibilizada na internet.
A tecnologia que permite este tipo de recurso é chamada de geração de páginas
dinâmicas. Consiste em porções de código (scripts) que são inseridos nas páginas HTML e
processados pelo servidor web antes de serem enviadas para os usuários, separando desta
forma a geração da interface da geração do conteúdo. Entre os representantes mais populares
desta tecnologia tem-se as páginas ASP (Active Server Pages) da Microsoft; PHP, que surgiu
para fortalecer a geração de páginas em servidores Unix mas já disponível para Linux e
Windows NT; O Jscript Server Side da NetScape e o ColdFusion. Além de todas estas
soluções citadas, mais uma surge como uma tecnologia competiviva, o JavaServer Pages
(JSP), que está na versão 1.1 de sua especificação (Gomes, 1999).
1.1 OBJETIVOS DO TRABALHO Caracterizam-se como objetivos do presente trabalho, o desenvolvimento de um
sistema de leilão voltado para internet, que implemente os conceitos de multi-camadas,
utilizando a tecnologia JavaServer Pages.
Os objetivos específicos do trabalho são:
a) desenvolver o sistema de leilão voltado para empresas industriais;
b) definir as vantagens e a viabilidade de utilizar JavaServer Pages no
desenvolvimento de sistemas para internet;
c) implementar o conceito de multi-camadas delimitando a camada de apresentação,
regras de negócio e acesso aos dados.
1.2 ESTRUTURA DO TRABALHO
No primeiro capítulo é apresentado o assunto do trabalho como um todo, assim como
seus objetivos.
3
No segundo capítulo é apresentado um breve histórico sobre as arquiteturas de
software, as tecnologias de geração de conteúdo dinâmico para a internet e a tecnologia
utilizada para implementar o sistema de leilão descrevendo suas funcionalidades e recursos.
No terceiro capítulo são apresentados os detalhes do desenvolvimento do sistema, sua
especificação, técnicas e ferramentas utilizadas.
No quarto capítulo são apresentadas as conclusões obtidas no decorrer do
desenvolvimento do mesmo e sugestões para futuros trabalhos.
4
2 FUNDAMENTAÇÃO TEÓRICA
2.1 HISTÓRICO DA ARQUITETURA DE SOFTWARE
Desde a concepção das primeiras aplicações, a arquitetura de software passou por
evoluções deste o surgimento da arquitetura cliente-servidor até a arquitetura multi-camadas.
Visando esclarecer estes conceitos, descreve-se a seguir as principais características e a
evolução das arquiteturas de software.
2.1.1 ARQUITETURA DE UMA CAMADA
As primeiras aplicações computacionais que surgiram eram monolíticas, ou seja, nela
todos os seus componentes (interfaces, regras de negócio e dados) estavam em um mesmo
lugar. Segundo Hampshire (1999), a arquitetura de uma camada é baseada em um ambiente
onde todos os componentes são combinados num simples programa integrado, rodando
somente em uma máquina.
Conforme figura 1, os mainframes são exemplos clássicos da arquitetura de uma
camada, onde estações de trabalho (terminais burros) são conectados a computadores centrais
onde todo o processamento é executado (Ntier, 1999).
Figura 1 – Arquitetura de uma camada
5
2.1.2 ARQUITETURA DE DUAS CAMADAS
Com o surgimento das LAN (Local Area Network) os computadores saíram do
isolamento e logo começaram a se conectar não só mutuamente, mas também com servidores,
surgindo assim a arquitetura cliente/servidor. Segundo Bochenski (1995), em uma arquitetura
cliente/servidor (two-tier), processos independentes residem em diferentes plataformas e
interagem através de redes para atender aos objetivos da computação. Em um sistema
cliente/servidor, um processo do cliente faz solicitações ao processo do servidor e este atende
a essas solicitações.
O modelo cliente/servidor surgiu com as aplicações desenvolvidas para redes locais no
final dos anos 80 e início de 90. Numa arquitetura cliente/servidor de duas camadas, o cliente
se comunica diretamente com o servidor de banco de dados (figura 2). A lógica de negócios
ou lógica da aplicação está inserida ou no cliente ou no servidor de banco de dados (Ntier,
1999).
Figura 2 – Arquitetura cliente-servidor
O modelo cliente/servidor de duas camadas inicialmente envolvia um servidor de
arquivos e um cliente “fat client” (figura 3), onde ocorria a maior parte do processamento.
Posteriormente a interface gráfica com o usuário (GUI - Graphical User Interface) surgiu
como ambiente de desktop (estação de trabalho) e o servidor de arquivos fora substituído por
servidor de banco de dados. A maior parte do processamento ainda era executado no cliente,
6
porém conjuntos de dados eram enviados para o banco de dados utilizando Structured Query
Language (SQL) e estes retornavam o resultado da consulta (Ntier, 1999).
Figura 3 – Arquitetura cliente-servidor com “fat client”
Como alternativa aos “fat clients” surgiram os “fat servers” (figura 4), onde o cliente
invoca chamadas de procedimentos armazenadas no servidor de banco de dados aumentando
a eficiência no ganho de performance devido à redução no tráfego da rede (Ntier, 1999).
Figura 4 – Arquitetura cliente-servidor com “fat server”
2.1.3 ARQUITETURA MULTI-CAMADAS
Multi-camadas segundo Hampshire (1999), é composta basicamente por três camadas
que se referem às três partes lógicas que compõem uma aplicação, e não ao número de
máquinas usadas pela aplicação (figura 5). O modelo multi-camadas considera a aplicação,
normalmente, dividida nas seguintes camadas:
7
a) camada da lógica de apresentação: apresenta a informação a uma fonte externa e
obtém entradas daquela fonte. Na maioria dos casos, a fonte externa é um usuário
final trabalhando em um terminal ou estação de trabalho, embora a fonte externa
possa ser um sistema robótico, um telefone ou algum outro dispositivo de entrada;
b) camada da lógica do negócio: contém a lógica da aplicação que governa as funções
do negócio e os processos executados pela aplicação;
c) camada da lógica de acesso a dados: contém a lógica que fornece à interface um
sistema de armazenamento de dados ou algum outro tipo de fonte de dados
externos, como uma aplicação externa.
Figura 5 – Arquitetura multi-camadas
Uma aplicação multi-camadas é uma aplicação que foi dividida em componentes de
aplicação múltiplos. Esta arquitetura possui várias vantagens significativas sobre as
arquiteturas cliente/servidor tradicionais, inclusive melhorias em escalabilidade, desempenho,
confiabilidade, gerenciabilidade, reusabilidade e flexibilidade (Schlickmann, 1999).
Vantagens do ambiente multicamadas segundo Ntier (1999):
a) alterações na interface do usuário ou na lógica da aplicação são independentes,
permitindo que a aplicação facilmente se adapte a novas necessidades;
b) gargalos de rede são minizados porque a camada da lógica da aplicação apenas
transmite os dados necessários para o cliente;
c) quando a lógica de negócios sofre alterações, somente o servidor de aplicação
necessita ser alterado;
d) o cliente fica isolado das operações de rede e acesso a banco de dados pois o
mesmo não precisa saber onde estão os dados e quantos servidores estão
envolvidos;
e) conexões a banco de dados podem ser compartilhadas entre os clientes reduzindo o
custo de licenças por usuário;
8
f) o banco de dados é independente pois os acessos a dados são escritos utilizando o
padrão SQL (Structured Query Language).
2.2 A ARQUITETURA MULTI-CAMADAS E A INTERNET
Com a disseminação do uso da internet nos últimos anos, cresce o número de
aplicações que são construídas visando ser compatíveis com esta tecnologia, sendo assim a
implementação do conceito de multi-camadas tem sido cada vez mais freqüente.
A implementação do conceito de multi-camadas em sistemas voltados para internet ou
baseados na tecnologia web, envolve a quebra do modelo cliente-servidor em várias camadas.
Uma aplicação pode ser dividida em várias camadas para os seguintes serviços: apresentação,
geração dinâmica do conteúdo de apresentação, lógica de negócios e acesso aos dados (Gould,
2000).
Através de estações utilizando navegadores, empresas podem implementar uma
arquitetura multi-camadas onde servidores de internet atuam como uma camada intermediária,
gerenciando as transações com os clientes web (Sun MicroSystems, 1999).
Segundo Sun Microsystems (1999), uma arquitetura baseada em clientes web, possue
pelo menos três camadas. Esta arquitetura multi-camadas oferece vários benefícios em relação
a uma arquitetura cliente-servidor:
a) instalar e implementar a interface do usuário é instantânea, somente a interface web
na camada intermediária (servidor web) necessita ser atualizada;
b) como a aplicação é baseada em servidor, o usuário sempre acessa a versão mais
atualizada;
c) sem a necessidade de instalar um software cliente na estação, fica mais fácil de
implementar e manter aplicações web, não importando a localização geográfica do
cliente.
Estes benefícios justificam a crescente popularidade da arquitetura multi-camadas, e
porque várias aplicações cliente-servidor estão sendo migradas para suportar clientes web.
Empresas que estão desenvolvendo aplicações baseadas na web estão envolvidas com
uma arquitetura que ainda está amadurecendo. Atualmente, um grande número de tecnologias,
desde os tradicionais scripts CGI até o JavaServer Pages, estão disponíveis para construir os
9
componentes destas aplicações. O desafio é escolher uma tecnologia e arquitetura que
acompanhe as necessidades dos usuários, desde clientes, fornecedores ou funcionários da
própria empresa.
De acordo com Sun Microsystems (2000), as organizações que necessitam manter e
desenvolvolver este tipo de aplicação, aplicam requisitos rígidos na escolha da arquitetura,
produtos e ferramentas para criar aplicações baseadas na web:
a) a plataforma de desenvolvimento deve ter suporte à rápida construção e
manutenção das aplicações;
b) as aplicações devem ser de fácil manutenção usando o mínimo de recursos de
desenvolvimento;
c) como muitas organizações requerem a habilidade de adaptar novas tecnologias e
ferramentas de acordo com suas necessidades, a tecnologia de desenvolvimento
não deve impedir ou dificultar este processo. Como todo dia aparecem novidades
no mercado, existe um risco de se escolher uma solução que deixe e organização
inteiramente a mercê de uma tecnologia, mesmo que esta seja líder de mercado.
Antes de detalhar a tecnologia que será utilizada no desenvolvimento deste trabalho,
demonstra-se a seguir, os principais representantes das tecnologias de geração de conteúdo
dinâmico para web e suas principais características.
2.2.1 COMMON GATEWAY INTERFACE (CGI)
Os servidores de HTTP (HyperText Transport Protocol) mais antigos não incluíam
qualquer mecanismo embutido para gerar respostas dinamicamente. Ao invés disso, foram
fornecidas interfaces para chamar outros programas para traduzir solicitações no conteúdo em
tempo de execução. O primeiro padrão para conteúdo de web dinâmico se baseava na
Common Gateway Interface, ou CGI, que especificava um mecanismo para que servidores de
internet passassem as informações das solicitações para programas externos, que eram então,
rodados pelo servidor da web para gerar respostas em tempo de execução (Fields, 2000).
O CGI não é uma linguagem de programação, mas um protocolo de comunicação que
o servidor HTTP utiliza para conversação com outro programa. Um CGI script é qualquer
programa que se comunica com o servidor web através do protocolo CGI. Em verdade, um
script CGI (como ficou conhecido este mecanismo) é um programa atendente de requisições,
10
enviadas por um cliente e a ele repassadas pelo servidor de internet. De forma simplificada,
CGI é apenas a definição de formatação de passagem de parâmetros do navegador para o
servidor web, como estes parâmetros são passados do servidor para o programa CGI e, por
fim, a forma que o programa devolve HTML (Hyper Text Markup Language) para o servidor
(Batista, 2000).
2.2.2 COLDFUSION
O ColdFusion fornece um conjunto de tag(s) do tipo HTML (Hyper Text Markup
Language) que inicialmente visavam embutir consultas de banco de dados em páginas da
web, mas desde então, foram estendidas para suportar uma ampla variedade de fontes de
dados para geração de conteúdo dinâmico (Fields, 2000).
2.2.3 ACTIVE SERVER PAGES (ASP)
A tecnologia Active Server Pages da Microsoft, frequentemente abreviada como ASP,
suporta múltiplas linguagens de criação de scripts, incluindo PerlScript, Jscript e VBScript.
PerlScript é baseada em Perl, e Jscript é baseada em JavaScript, mas a linguagem de criação
de scripts padrão para ASP é VBScript, um subconjunto da linguagem de programação
popular Visual Basic da Microsoft. A VBScript inclui suporte para acessar componentes
ActiveX, que são objetos de código compilados que podem encapsular virtualmente qualquer
funcionalidade, incluindo acesso a banco de dados e manipulação de arquivos. A principal
limitação da ASP é que ela está disponível apenas com o Internet Information Server (IIS) da
Microsoft, rodando no sistema operacional Windows NT (Fields, 2000).
Outro ponto fraco é que a tecnologia ASP tem seu padrão fechado, ou seja, somente a
Microsoft tem total conhecimento de sua estrutura interna e de seu funcionamento em baixo
nível (Gomes, 1999).
2.2.4 SERVER-SIDE JAVASCRIPT (SSJS)
Server-Side JavaScript (SSJS) usa JavaScript como sua linguagem de criação de
scripts. O JavaScript é uma linguagem orientada a objetos com uma sintaxe do tipo C, mas
embora tenha um nome similar, não é Java. SSJS é uma extensão da linguagem JavaScript
básica, que também é a base para a linguagem JavaScript do cliente popular, usada para criar
11
scripts para navegadores da web. SSJS é específico para servidores de HTTP (HyperText
Transport Protocol) da Netscape (Fields, 2000).
2.2.5 PHP
PHP era originalmente um acrônimo para as ferramentas Personal Home Page. Como
seu escopo e funcionalidade cresceram no decorrer dos anos, este nome não é mais adequado,
e o software é chamado apenas de PHP. Assim como JavaScript, PHP emprega uma sintaxe
do tipo C e fornece suporte para acesso de banco de dados e correspondência padrão. O PHP é
compatível com Windows NT e diversos sistemas operacionais UNIX e com diversos
servidores de HTTP (HyperText Transfer Protocol), como Apache, IIS da Microsoft e
Netscape Enterprise Server (Fields, 2000).
2.2.6 APPLETS E SERVLETS Quando a Sun MicroSystems introduziu pela primeira vez a tecnologia Java à
comunidade de computação, foi no contexto de pequenos programas , chamados de applets,
que podiam ser transmitidos pela internet e rodados dentro de navegadores da web.
Devido a importância da geração de conteúdo dinâmico para o desenvolvimento da
web, em 1996 a Sun introduziu servlets como pequenas aplicações baseadas em Java para
adicionar funcionalidade interativa aos navegadores da web (Fields, 2000).
Java Servlets são a alternativa Java para CGI Scripts. Um Servidor de HTTP
(HyperText Transfer Protocol) com suporte a servlets, ao invés de executar um programa
para cada requisição CGI, repassa-o para um ServletEngine, que só ativa o programa se ele
não foi ativado num passado recente, significando, na maioria dos casos, um aumento
substancial de desempenho e redução dos requisitos de memória. Por serem escritos em Java,
servlets têm à sua disposição todas as APIs (Application Program Interface) e softwares
disponíveis na plataforma, o que lhes conferem alta flexibilidade, representada por uma
linguagem orientada a objetos, multiplataforma, com suporte a multithreading e com forma de
acesso a bases de dados padronizada (Batista 2000).
Uma desvantagem potencial desta abordagem é que todo o conteúdo de documentos,
tanto estático quanto dinâmico, reside no código fonte do programa. Como resultado,
qualquer modificação em tal documento necessita de intervenção de um programador. Um
12
desenvolvedor de páginas HTML não pode modificar o formato da página, a menos que o
código fonte associado seja modificado (Fields, 2000).
2.2.7 JAVASERVER PAGES (JSP)
A tecnologia JavaServer Pages usa tags parecidas com XML (eXtended Markup
Language) e scriptlets escritos em Java para encapsular a lógica que gera o conteúdo da
página. A lógica da aplicação também pode residir em recursos baseados em servidores, como
Javabeans, que a página acessa com essas tags e scriptlets. Separando a lógica da editoração
da página e suportando a utilização de componentes reutilizáveis, a tecnologia JSP permite a
desenvolvimento fácil e rápido de aplicações web (Sun Microsystems, 2001a).
Fields (2000) detalha JSP como arquivos de texto , normalmente com a extensão .jsp,
que substituem as páginas HTML tradicionais. Os arquivos JSP contém HTML tradicional
junto com código embutido que permitem que o desenvolvedor de páginas tenha acesso aos
dados através do código de Java rodando no servidor. Quando a página é solicitada por um
usuário e processada pelo servidor de HyperText Transport Protocol (HTTP), a parte HTML
da página é transmitida. No entanto, as partes do código da página são executadas no
momento em que a solicitação é recebida e o conteúdo dinâmico gerado por este código é
unido na página antes de ser enviado para o usuário. Isto propicia uma separação dos aspectos
de apresentação HTML da página e da lógica de programação contida no código.
JSP é a combinação de HTML com Java dentro de uma mesma página. Usando tags
especiais pode-se introduzir Java em qualquer parte da página, todo o código fora dos tags é,
em princípio, HTML puro. Talvez o mais interessante seja ter em mente que uma página JSP
sempre é convertida em programa Java (um servlet) antes de entrar em ação.
A idéia por trás do JSP é a combinação das estratégias anteriores de separação de parte
estática de conteúdo dinâmico. Ou seja, gerar automaticamente um servlet Java que represente
a página JSP. Este programa gerado contém comandos para emitir a parte HTML fixa. A parte
dinâmica, por ser escrita em Java, pode ser incorporada diretamente ao fonte sendo gerado. O
código gerado é um servlet, que tem comportamento bem conhecido. Todo o processo de
conversão da página JSP em um servlet, a compilação do Servlet e sua incorporação ao
ambiente do servidor de aplicação é automático, mas efetuada uma única vez, a menos que a
página mude, quando o processo é repetido (Batista, 2000).
13
Uma grande vantagem do JSP é que suas páginas podem ser processadas por diversos
servidores web, como o Apache, NetscapeTM e Internet Information Server, e sob várias
plataformas, como o Solaris, Linux, Mac OS, Windows NT, Windows 95 e outras. Uma outra
vantagem é o padrão aberto para a indústria, contando com o apoio de empresas como Oracle,
Netscape, IBM e WebLogic. Isto significa que mais empresas poderão fornecer servidores
web compatíveis com JSP e outros adendos para facilitar o trabalho dos desenvolvedores
(Gomes, 1999).
Antes de detalhar a tecnologia JSP, é importante descrever sua relação com o ambiente
de desenvolvimento Java, que segundo Sun MicroSystems (1999), consiste da linguagem de
programação Java, do compilador da linguagem Java e a JVM (Java Virtual Machine), para
executar os programas. O poder da tecnologia Java de ser portável para diversas plataformas
está neste modelo: o compilador cria executaveis independentes de plataforma (java byte-
code) que é executado pela JVM, na qual gera as instruções de máquina a serem executadas.
A linguagem de programação Java consiste de classes e interfaces, acessíveis através
de APIs (Application Programming Interfaces), distribuídas numa estrutura de bibliotecas de
classes. A tecnologia JSP é implementada como uma API do Java, que faz parte da J2EE
(Java 2 Enterprise Edition). Ela não oferece novos recursos, tudo o que pode ser feito através
de JSP, também pode ser feito através de servlets, pois páginas JSP são compiladas para
servlets. O que JavaServer Pages faz é fornecer uma metodologia de desenvolvimento e
manutenção de aplicações muito mais eficiente. Isto ocorre porque a tecnologia JSP separa o
design da página e conteúdo estático com a lógica utilizada para gerar a parte dinâmica (Sun
MicroSystems, 1999).
Servlets e JavaServer Pages apareceram pela primeira vez como parte do produto
Java Web Server da Sun, um servidor HTTP escrito em Java. A Sun, lançou a tecnologia de
servlet como uma extensão Java padrão. A JSP apareceu logo depois, com as primeiras
especificações API aparecendo em 1998. A especificação JavaServer Pages 1.0 foi lançada
em junho de 1999, garantindo assim uma plataforma estável e bem definida, a partir da qual
os fornecedores puderam desenvolver seus produtos (Fields, 2000).
JSP oferece diversos benefícios como um sistema para geração de conteúdo dinâmico.
Primeiramente, sendo uma tecnologia baseada em Java, ela se aproveita de todas as vantagens
14
que a linguagem Java fornece em relação a desenvolvimento e acionamento. Como uma
linguagem orientada a objetos com forte digitação, encapsulamento, tratamento de exceções e
gerenciamento de memória automática, o uso de Java conduz a uma produtividade aumentada
do programador e a código mais robusto. Pelo fato de haver uma API padrão publicada para
JSP, e pelo fato do bytecode de Java compilado ser portável através de todas as plataformas
que aceitam uma JVM, o uso de JSP não o restringe ao uso de uma plataforma de hardware,
sistema operacional ou software de servidor específico (Fields, 2000).
2.2.8 COMO JSP FUNCIONA
Embora a especificação JSP não determine qualquer abordagem específica para
implementação de JavaServer Pages, atualmente a maioria das implementações de JSP se
baseia em servlets. Como um primeiro passo na compreensão de como JSP funcionam, então
é útil compreender como os servlets funcionam.
Servlets são um análogo baseado em java aos programas de CGI, implementados
através de um container servlet (processo ou ambiente de execução) associado com um
servidor HTTP. Um conjunto de URLs e/ou padrões de URL está especificado como sendo
tratado pelo container servlet, de modo que sempre que uma solicitação por um URL
correspondendo a este conjunto for recebida pelo servidor HTTP, esta solicitação é
encaminhada para o container servlet para processamento (Fields, 2000).
O encaminhamento de solicitações é acompanhado pelo empacotamento de todos os
dados da solicitação (URL, origem da solicitação, parâmetros e valores de parâmetros, etc).
Um objeto java similar é construído representando a resposta. Este objeto de resposta tem
métodos para definir o código de estado da resposta e para acessar o fluxo de saída que
conterá os resultados do processamento da solicitação. As classes de servlet são responsáveis
pela definição dos métodos de serviço para tratar dos vários tipos de solicitações de HTTP,
incluindo um método doGet() para tratar de solicitações GET de HTTP e um método doPost()
para tratar de solicitações POST de HTTP. Os objetos construídos pelo container servlet para
representar uma única solicitação e sua resposta correspondente, são passados como
argumentos para estes métodos, que são então chamados pelo container servlet, de solicitação
em solicitação (Fields, 2000).
15
O componente principal de uma implementação baseada em servlets de JavaServer
Pages é um servlet especial frequentemente chamado de compilador de página. O container é
configurado para chamar este servlet para todas as solicitações com URL que combinem com
a extensão de arquivo JSP, e é a presença deste servlet e suas classes de java associadas, que
transforma um container servlet em um container JSP. Como seu nome sugere, a tarefa deste
servlet não é apenas encontrar páginas JSP em resposta a tais solicitações, mas na verdade
compilá-las (Fields, 2000).
Como demonstra a figura 6, as solicitações do navegador são conduzidas para o servlet
compilador de página rodando no container JSP. O container JSP então verifica se o servlet
para a página JSP especificada está ou não atualizada: existe um servlet compilado para esta
página e, se existir, ele é mais novo do que o conteúdo atual da página JSP ? Se não, o
container JSP deve sofrer o processo de analisar a página, gerar o código fonte e compilá-lo.
O servlet recentemente compilado é então carregado no container servlet. Se o servlet da
página JSP for atual, então o container JSP precisa se certificar que o servlet esteja
atualmente carregado, já que ele pode ter sido descarregado, depois de sua criação original,
devido a falta de uso. Em qualquer uma dessas situações, o controle pode então ser transferido
do servlet compilador de página para o servlet da página JSP, que então lida com a
solicitação. A reposta é gerada pelo servlet da página JSP e devolvida para o servidor HTTP,
para retornar para o navegador da web (Fields, 2000).
16
Figura 6 – Processo do servidor para criação e execução de servlet JSP
FONTE: Fields (2000) página 36
Este recurso único de compilação de página empresta benefício de performance
adicional à tecnologia JavaServer Pages em comparação a outros sistemas de conteúdo
dinâmico. Como discutido, a maioria dos sistemas de conteúdo dinâmico se apóia em tags
especiais, linguagens de criação de scripts interpretadas ou uma combinação. Para a maioria
desses sistemas o arquivo contendo estas tags e/ou scripts deve ser analisado cada vez que o
documento é solicitado. Esta análise provoca utilização de recursos de hardware pelo sistema
operacional que é evitada com JavaServer Pages, já que arquivos JSP são analisados apenas
na primeira vez em que são solicitados. JSP será mais lenta que outras abordagens para esta
17
primeira solicitação, devido ao passo de compilação, mas será mais rápida que outras
abordagens para todas as solicitações subsequentes (Fields, 2000).
2.2.9 JAVASERVER PAGES E MULTICAMADAS
A tecnologia JSP pode ser utilizada para criar aplicações simples que reportam a hora
ou número de visitantes da página. Porém, segundo Sun MicroSystems (1999) esta tecnologia
também ser utilizada em sistemas mais complexos que implementem o conceito de multi-
camadas (figura 7).
Na camada de cliente, ou lógica de apresentação, as páginas JSP podem comunicar
com clientes baseados em web, incluindo browsers baseados em HTML. A página gerencia a
interação do browser com o usuário, enviando e recebendo informações.
Na camada intermediária, ou lógica de negócios, as páginas JSP podem residir em
vários servidores web ou servidores de aplicação. As páginas tem acesso a uma grande
variedades de API Java e serviços, incluindo JDBC para acesso a banco de dados, JavaMail
para utilização dos recursos de envio de email, Java Transaction API para serviços
transacionais, dentre outros.
Ainda na camada intermediária, componentes JavaBeans ou até mesmo as páginas JSP
podem acessar informações na camada de acesso aos dados, esta interação é feita através da
API JDBC, que interage com o SGBD (Sistema Gerenciador de Banco de Dados) (Sun
MicroSystems, 1999).
Figura 7 – JavaServer Pages implementando multi-camadas
Acesso aos dados
Lógica de apresentação
Regras de negócio
BROWSER
Serv idor de banco de
dados
Serv idor web Serv idor de aplicação
JDBC
JavaBeansJSP
SERVLET
18
A tecnologia JSP é designada a criar conteúdo dinâmico para web usando
processamento baseado em servidor (middle-tier). Ela simplifica o processa de criação de
páginas dinâmicas separando a lógica da aplicação com o design da página e encapsulando a
lógica da aplicação em componentes java portáveis e reutilizáveis (Sun MicroSystems, 1999).
Embora JavaServer Pages permita que programadores implementem a geração de
conteúdo dinâmico, ao incluir código fonte de java diretamente em páginas da web, ela
também inclui um conjunto de tags do tipo HTML para interagir com objetos java que
residem no servidor. Em especial, estas tags são projetadas para criar, realizar consultas e
modificar JavaBeans no servidor (Fields, 2000).
JavaBeans são objetos escritos em java, cuja implementações estão de acordo com um
conjunto de convenções projetadas para promover modularidade e reusabilidade. JavaBeans
usa um estilo de programação que conduz a pedaços de código de programa independentes de
fatores externos, que encapsulam comportamento, funcionalidade ou dados relacionados, que
podem ser usados e reutilizados em múltiplos contextos sem que seja preciso conhecer os
detalhes de sua operação interna. Como resultado, os objetos JavaBeans podem prontamente
ser conectados uns com outros e combinados a fim de fornecer capacidades específicas de
aplicação ou capacidades mais sofisticadas (Fields, 2000).
Ao se aproveitar do suporte embutido de JSP para JavaBeans, é possível manter uma
rígida separação entre as regras de negócio e a lógica de apresentação. O benefício
proveniente desta separação é que as mudanças em um podem ser realizadas sem a
necessidade de realizar qualquer mudança no outro. Um efeito colateral importante desta
separação de apresentação e implementação através de JSP, é que ela promove uma clara
divisão de trabalho no desenvolvimento e manutenção das aplicações da web para geração de
conteúdo dinâmico. É raro um indivíduo que possua habilidades impressionantes tanto no
design artístico quanto na programação (Fields, 2000).
A grande virtude dos componentes reutilizáveis é a produtividade. Se um componente
já estiver disponível para realizar alguma tarefa, este é menos um pedaço de código que
precisa ser escrito, depurado e mantido.
19
2.2.10 JAVABEANS & ENTERPRISE JAVABEANS
Um Bean é classe de java que segue um conjunto de convenções simples de design e
nomeação delineado pela especificação de JavaBeans. De acordo com a especificação de JSP,
eles não precisam estender uma classe base específica ou implementar uma determinada
interface. As convenções de JavaBean são o que nos permitem desenvolver Beans, porque
elas permitem que o container Bean analise um arquivo de classe Java e interprete seus
métodos como propriedades, designando a classe como um bean de java. As convenções
determinam as regras para definição do construtor de um bean e os métodos que definirão
suas propriedades.
A primeira regra da criação do bean de JSP é a necessidade de criação de um
construtor que não pegue argumentos. É este construtor que o container JSP usará para
instanciar seu Bean através da tag <jsp:useBean>. Cada classe de java tem um método de
construtor que é usado para criar instâncias da classe (Fields, 2000).
As propriedades de um bean são definidas simplesmente ao criar os métodos de acesso
apropriados para eles. Os métodos de acesso são usados para recuperar o valor de uma
propriedade ou fazer modificações nela. Um método usado para recuperar o valor de uma
propriedade é chamado de método getter, enquanto que um método que modifica seu valor é
chamado de método setter. Juntos, estes métodos são geralmente chamados de métodos de
acesso, eles fornecem acesso a valores armazenados nas propriedades de um bean.
Um dos requisitos do Bean de Java que JSP não determina é que os Beans devem
implementar a interface Serializable. Isto permitirá que uma instância do Bean seja
serializada, transformando-a em um fluxo contínuo de dados binários que podem ser
armazenados no disco para posterior reutilização. Quando um bean é serializado para o disco
seu estado é preservado, de modo que seus valores de propriedades permaneçam intocados
(Fields, 2000).
O quadro 1 mostra o exemplo de um bean cujo nome da classe é pessoa, que possui a
propriedade nome e os métodos setter e getter.
20
Quadro 1 – Exemplo de JavaBean
package exemplo;
import java.io.Serializable;
public class pessoa implements Serializable {
String nome;
public pessoa {
nome = “”;
}
public String getNome() {
return nome;
}
public void setNome(String vnome) {
this.nome = vnome;
}
}
Assim como JavaBeans, Enterprise JavaBeans são componentes de software baseados
em Java. No entanto, estes Beans seguem um conjunto completamente diferente de
convenções e interfaces e não são acessíveis diretamente através dos containers Bean ou tags
JSP. Eles são projetados para uso em arquiteturas de aplicações distribuídas (Fields, 2000).
A especificação enterprise javabeans tem suporte a vários tipos de clientes. Isto ocorre
devido ao fato do servidor poder suportar múltiplos protocolos como RMI, IIOP (CORBA) e
DCOM. Desta forma, o cliente para o servidor enterprise javabean não precisa
necessariamente ser escrito na linguagem java (Roth, 1998).
Tanto javabeans como enterprise javabeans são componentes reutilizáveis e baseados
em servidores com o objetivo de encapsular a lógica da aplicação. Porém enterprise
javabeans possui suporte a vários protocolos de arquiteturas de sistemas distribuídos. Como o
objetivo do presente trabalho é implementar o sistema na arquitetura multi-camadas,
descreve-se somente o conceito de enterprise javabeans, visto que ele não será utilizado no
desenvolvimento do sistema.
21
2.2.11 A SINTAXE JSP
De acordo com Sun MicroSystems (2000), uma página JSP basicamente é um arquivo
contendo comandos HTML (Hyper Text Markup Language) e os seguintes elementos JSP:
a) diretivas JSP:
- diretiva page, passa informações específicas da página;
- diretiva language, especifica a linguagem de script;
- diretiva include, utilizada para incluir um documento externo na página;
- diretiva taglib, utilizada para indicar bibliotecas de tags customizáveis;
b) tags JSP:
- jsp:useBean, utilizada para instanciar um componente JavaBean;
- jsp:setProperty, utilizada para alterar o valor de uma propriedade de um
componente JavaBean;
- jsp:getProperty, utilizada para pegar o valor de uma propriedade de um
componente JavaBean;
- jsp:forward, utilizada para passar o controle de execução para outra página JSP;
c) scriptlets (elementos de script), são fragmentos de código java, delimitados por <%
e %> dentro da página JSP.
Alguns destes recursos, utilizados no desenvolvimento deste trabalho são detalhados a
seguir, baseando-se em Sun MicroSystems (2000) e Fields (2000).
2.2.11.1 DIRETIVA PAGE
A diretiva page suporta uma ampla gama de atributos e funcionalidade associada. Sua
principal funcionalidade é definir as características da página JSP. Dentre os atributos,
destacam-se:
a) atributo language, especifica a linguagem de criação de scripts a ser usada em
todos os elementos de criação de scripts na página. Todos os containers JSP devem
suportar Java como uma linguagem de criação de scripts e este é o padrão se o
atributo language não for explicitamente especificado;
b) atributo extends, identifica a super classe a ser usada pelo container JSP quando ele
está traduzindo a página JSP em um servlet Java. Não há valor padrão para este
22
atributo. Se este atributo não for especificado, o container JSP é livre para fazer sua
própria escolha da classe de servlet JSP a usar como a super classe para a página;
c) atributo contentType, utilizado para indicar o tipo MIME da resposta sendo gerada
pela página JSP. Embora MIME signifique Multipurpose Internet Mail Extensions,
os tipos MIME também são usados para indicar o tipo de informação contida em
uma resposta de HTTP, e este é o contexto no qual eles são usados em JSP. Os
tipos mais comuns de MIME para JSP são “text/html”, “text/xml” e “text/plain”,
indicando respostas em HTML, XML e simples formatos de texto, respectivamente.
d) atributo import, estende o conjunto de classes Java que podem ser referenciadas em
uma página JSP sem ter que explicitamente especificar os nomes de pacotes de
classes.
O exemplo de utilização da diretiva page é apresentado no quadro 2.
Quadro 2 – Exemplo da diretiva page
<%@ page import=”java.util.*, java.lang.*” %>
<%@ page language=”java” %>
<%@ page contentType=”text/html” %>
2.2.11.2 TAG JSP:USEBEAN
A tag <jsp:useBean> cria ou recupera uma instância de um componente JavaBean e a
associa com o identificador especificado pelo atributo id. Este identificador pode ser usado
para identificar o Bean a partir dos elementos de criação de scripts ou nas tags subsequentes
<jsp:setProperty> ou <jsp:getProperty>. O exemplo da tag <jsp:useBean> é apresentado no
quadro 3.
Quadro 3 – Exemplo de <jsp:useBean>
<jsp:useBean id=”BeanEmpresa” class=”sis.empresa” / >
23
2.2.11.3 TAG JSP:SETPROPERTY
A tag <jsp:setProperty> pode ser usada em qualquer lugar dentro da página para
modificar as propriedades de um Bean, desde que ela apareça depois da ação <jsp:useBean>
usada para definir aquele Bean. O Bean é identificado através do atributo name da tag, que
deve corresponder ao identificador originalmente atribuído a um Bean através do atributo id
de sua tag <jsp:useBean>. Apenas propriedades que tenham métodos públicos setter podem
ser modificadas através da ação <jsp:setProperty>. A propriedade a ser definida é
especificada através do atributo property na tag (quadro 4).
O atributo value é usado para especificar o valor a ser atribuído à propriedade indicada
e pode ser uma expressão JSP representando um valor de atributo no tempo de solicitação.
Alternativamente, o parâmetro param pode ser usado para especificar o nome de um
parâmetro de solicitação cujo valor deve ser copiado para a propriedade do Bean.
Quadro 4 – Exemplo de <jsp:setProperty>
<jsp:useBean id=”BeanEmpresa” class=”sis.empresa” / >
<jsp:setProperty name=”BeanEmpresa” property=”NomeE mpresa” value=”Tabajara SA” />
2.2.11.4 TAG JSP:GETPROPERTY
A tag <jsp:getProperty> é utilizada para acessar as propriedades de um Bean. Ela
produz o conteúdo que pode ser visto no HTML gerado pela página. O atributo name
especifica o Bean que está sendo acessado e deve corresponder ao identificador que foi
selecionado para o Bean no atributo id da tag <jsp:useBean>. Na HTML resultante que é
exibida no tempo de execução, esta tag é substituída pelo valor da propriedade do Bean sendo
solicitado (quadro 5).
24
Quadro 5 – Exemplo de <jsp:getProperty>
<jsp:useBean id=”BeanEmpresa” class=”sis.empresa” / >
<CENTER>
<h3> O nome da empresa é: </h3>
<jsp:getProperty name=”BeanEmpresa” property=”NomeE mpresa” />
</CENTER>
2.2.11.5 TAG JSP:FORWARD
A tag <jsp:forward> é usada para transferir permanentemente controle de uma página
JSP para um outro local no servidor local. Qualquer conteúdo gerado pela página atual é
descartado e o processamento da solicitação começa novamente no local alternativo. O
atributo page da tag <jsp:forward> é usado para especificar este local alternativo para o qual
o controle deve ser transferido, que pode ser um documento estático, uma CGI, um servlet ou
uma outra página JSP (quadro 6).
Quadro 6 – Exemplo de <jsp:forward>
... Comandos HTML
<jsp:forward page=”pagina.jsp” />
2.2.11.6 SCRIPTLET
Considerando que as diretivas JSP influenciam como a página é processada pelo
container JSP, os elementos de criação de scripts permitem que os programadores embutam
diretamente código em uma página JSP, incluindo código que gera output para parecer nos
resultados enviados de volta para o usuário. JSP oferece três tipos de elementos de criação de
scripts: declarações, scriptlets e expressões. As declarações permitem que o programador
defina variáveis e métodos para uma página, que podem ser acessados por outros elementos
de criação de scripts. Os scriptlets são blocos de código a serem executados cada vez que a
página JSP é processada para uma solicitação. As expressões são linhas de código individuais.
Assim como os scriptlets, elas são executadas para cada solicitação. Os resultados da
25
avaliação de uma expressão, no entanto, são automaticamente inseridos no output da página
no lugar da tag de expressão original.
Todos os elementos de criação de scripts em uma página são escritos na linguagem de
criação de scripts designada para a página através do atributo language da diretiva page. Na
falta de uma especificação explícita da linguagem de criação de scripts, assume-se pelo
container JSP que a linguagem de criação de scripts é java (Fields, 2000).
O quadro 7 mostra o exemplo de um scriplet dentro de uma página JSP.
Quadro 7 – Exemplo de scriptlet
<%
String name = null;
If (request.getParameter(“name“) == null) {
%>
... Comandos HTML
<%
} else {
%>
... Comandos HTML
<% } %>
26
3 DESENVOLVIMENTO DO TRABALHO
No capítulo anterior foi apresentada a fundamentação teórica do presente trabalho,
descrevendo a arquitetura multi-camadas, conceituando a tecnologia JavaServer Pages e
mostrando suas principais características e recursos necessários para a implementação do
sistema.
No presente capítulo descreve-se a metodologia utilizada para especificação e
implementação do sistema de leilão, bem como os resultados obtidos.
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO
Como já mencionado, o objetivo deste trabalho é desenvolver um sistema de leilão
utilizando a tecnologia JavaServer Pages implementando o conceito de multi-camadas. O
sistema deve permitir as funções básicas de um leilão virtual, que são o anúncio de produtos e
o lance, ou como será denominado neste trabalho, a proposta sobre produtos anunciados.
Não é objetivo deste trabalho construir um sistema que vise concorrer com sistemas de
leilão existentes no mercado, já que existem inúmeros sistemas no mercado com muito mais
recursos que o que será desenvolvido. A idéia é desenvolver um sistema piloto avaliando a
tecnologia JavaServer Pages e a arquitetura multi-camadas como uma solução para o
desenvolvimento de aplicações para a internet.
Do ponto de vista da arquitetura, o sistema deve ser totalmente voltado para a internet,
independente de plataforma do ponto de vista do cliente, do servidor de aplicação e do
servidor de banco de dados, delimitando claramente as diferentes camadas da aplicação.
Do ponto de vista funcional do sistema, define-se como principais recursos:
a) permitir o cadastramento de empresas que visem anunciar produtos ou realizar
propostas sobre outros produtos anunciados;
b) autenticar a empresa que deseja realizar alguma operação no sistema;
c) permitir o anúncio de produtos;
d) permitir a realização de propostas sobre produtos anunciados;
e) permitir o acompanhamento das propostas realizadas sobre seus produtos.
27
3.2 ESPECIFICAÇÃO
Para a especificação do sistema, optou-se pela análise orientada a objetos, utilizando a
linguagem UML (Unified Modeling Language), sugerida por Fowler (2000) para a
implementação de sistemas utilizando linguagens orientadas a objetos.
A UML aborda conceitos fundamentais da orientação a objeto, buscando efetuar um
casamento entre método e utilização prática, para cobrir o ciclo de vida de desenvolvimento.
O modo para descrever os vários aspectos de modelagem pela UML é através da notação
definida pelos seus vários tipos de diagramas. Um diagrama é uma apresentação gráfica de
uma coleção de elementos de modelo, frequentemente conectados por arcos (relacionamentos)
e vértices (outros elementos do modelo).
Segue abaixo, os diagramas que serão utilizados para a especificação do sistema:
a) diagrama de casos de uso;
b) diagrama de classes;
c) diagrama de sequência;
Para a construção dos diagramas foi utilizada a ferramenta Rational Rose (Rational,
2001), seguindo os padrões de modelagem desta ferramenta.
3.2.1 DIAGRAMA DE CASOS DE USO
Diagramas de caso de uso fornecem um modo de descrever a visão externa do sistema
e suas interações com o mundo exterior, representando uma visão de alto nível de
funcionalidade intencional mediante o recebimento de um tipo de requisição do usuário.
A figura 8 demonstra claramente as interações do sistema com o mundo exterior,
delimitando os personagens e funções do sistema. A empresa anunciante ou compradora
poderá efetuar o cadastro no sistema. A empresa anunciante irá anunciar seus produtos e
efetivar ou fechar a negociação sobre a maior proposta da empresa compradora. A empresa
compradora poderá consultar os anúncios e efetuar propostas sobre os mesmos.
28
Figura 8 – Diagrama de casos de uso
3.2.2 DIAGRAMA DE CLASSES
Uma vez definida as principais funções do sistema, descreve-se as classes originadas
através destas funções no diagrama de classes.
O diagrama de classe é a essência da UML, trata-se de uma estrutura lógica estática
mostrando uma coleção de elementos declarativos de modelo, como classes, tipos e seus
respectivos conteúdos e relações. A parte de dados de um objeto é definida por um conjunto
de atributos e a porção funcional é definida por um conjunto de operações.
No diagrama 9, a classe AREA_ATUACAO classifica as empresas de acordo com o
tipo de seus produtos. A classe EMPRESA mantém os dados da empresa como CGC, nome,
endereço, pessoa de contato, dados para contato, a área de atuação, bem como a senha que
efetuar cadastro
anunciar produto
fechar negociação
autenticar empresa
realizar proposta
Empresa (Anunciante/Compradora)
29
será utilizada para autenticação no sistema. Para esta classe define-se os métodos “efetuar
cadastro” e “autenticar empresa”, para que esta possa ter acesso ao sistema. A relação da
classe EMPRESA com a classe AREA_ATUACAO é de N para 1, ou seja, uma empresa deve
obrigatoriamente pertencer a uma e somente uma área de atuação. A área de atuação por sua
vez, pode agrupar várias empresas.
A classe ANUNCIO mantém os dados dos anúncios efetuados pelas empresas. Os
dados são o código do anúncio, título, descrição detalhada, data do anúncio, data final, valor
mínimo para o produto anunciado e o código da empresa anunciante. O método “anunciar
produto” fica responsável pela lógica de inclusão de um anúncio no sistema. A relação da
classe EMPRESA com a classe ANUNCIO é de 1 para N. Um anúncio pode ser realizado por
somente uma empresa, já a empresa pode realizar quantos anúncios desejar.
A classe PROPOSTA mantém os dados das propostas efetuadas pelas empresas sobre
os produtos anunciados. Esta contém o código da proposta, o valor da proposta, um campo
indicando se a negociação já foi encerrada, o código da empresa compradora e o código do
anúncio. Para esta classe define-se os métodos “efetuar proposta” que contém a lógica a ser
processada para a empresa compradora que efetuar alguma proposta sobre algum anúncio e o
método “fechar negociação” para a empresa anunciante encerrar o leilão de determinado
produto. Ela está relacionada com as classes EMPRESA e ANUNCIO. Uma proposta pode
ser efetuada por somente uma empresa, que por sua vez pode realizar várias propostas sobre
um produto anunciado. Um anúncio pode receber várias propostas, uma proposta pode ser
feita a somente um anúncio.
30
Figura 9 – Diagrama de classes
3.2.3 DIAGRAMAS DE SEQUÊNCIA
Após definição dos diagramas de casos de uso e do diagrama de classes, define-se os
diagramas de sequência identificando a comunicação entre os objetos do sistema.
O diagrama de sequência é descendente dos diagramas de interação de objetos de
Booch e Jacobson (Rational, 2001) e mostra os objetos colaborando entre si. Entram em
vários formatos ligeiramente diferentes, e para propósitos diferentes.
No caso deste trabalho, o objeto (a empresa por exemplo) é desenhado como um
retângulo ao topo de uma linha vertical tracejada projetada para baixo. Essa linha vertical é
chamada de linha de vida do objeto e representa, conforme sugerido pelo próprio nome, o
ciclo de vida de um objeto durante uma interação. Cada mensagem é representada por uma
linha com seta dirigida horizontalmente entre as linhas de vida de dois objetos.
N
PROPOSTA
CD_PROPOSTAVL_PROPOSTAFG_FECHADOCD_CGC_EMPRESACD_ANUNCIO
Realizar proposta( )Fechar negociação( )
1
N
ANUNCIO
CD_ANUNCIODS_TITULODS_ANUNCIODT_ANUNCIODT_FINALVL_MINIMOCD_CGC_EMPRESA
Anunciar produto( )
1
N
EMPRESA
CD_CGC_EMPRESADS_EMPRESADS_CONTATODS_ENDERECODS_CIDADEDS_UFDS_CEPDS_TELDS_FAXDS_EMAILDS_HTTPSENHACD_AREA_ATUACAO
Efetuar cadastro( )Autenticar empresa( )untitled( )
1
AREA_ATUACAO
CD_AREA_ATUACAODS_AREA_ATUACAO
N
1
31
A implementação de uma mensagem pode tomar várias formas, como uma chamada de
procedimento, o envio de um sinal entre linhas ativas, a elevação explícita de eventos, e assim
por diante. A seguir demonstra-se os diagramas de sequência referentes às funções do sistema
(figuras 10, 11, 12, 13 e 14).
Figura 10 – Diagrama de sequência (Efetuar cadastro)
Empre : Empresa (Anunciante/Compradora)
: EMPRESA : AREA_ATUACAO
Efetuar cadastro ( ) Consiste área de atuação()
32
Figura 11 – Diagrama de sequência (Autenticar empresa)
Figura 12 – Diagrama de sequência (Anunciar produto)
: Empresa (Anunciante/Compradora)
: EMPRESA
Autenticar empresa ( )
: Empresa (Anunciante/Compradora)
: ANUNCIO : EMPRESA
Anunciar produto ( ) Consiste empresa()
33
Figura 13 – Diagrama de sequência (Realizar proposta)
Figura 14 – Diagrama de sequência (Fechar negociação)
: Empresa (Anunciante/Compradora)
: PROPOSTA : ANUNCIO : EMPRESA
Realizar proposta ( ) Consiste anuncio()
Consiste empresa()
: Empresa (Anunciante/Compradora)
: PROPOSTA : EMPRESA : ANUNCIO
Fechar negociação ( ) Consiste empresa()
Consiste anuncio()
34
3.3 IMPLEMENTAÇÃO
Nesta etapa é desenvolvido o sistema de leilão propriamente dito, onde são descritas as
técnidas e ferramentas utilizadas para implementação segundo os objetivos propostos. Além
deste é apresentado um estudo de caso, mostrando as funcionalidades do sistema do ponto de
vista do usuário.
3.3.1 TÉCNICAS E FERRAMENTAS UTILIZADAS
De uma forma genérica, as tecnologias e ferramentas utilizadas neste trabalho são:
a) tecnologias:
- análise orientada a objeto, através da utilização da linguagem UML (Unified
Modeling Language);
- linguagem de programação java, usada em scriplets e nos componentes
JavaBeans;
- HTML (Hyper Text Markup Language) e JavaScript, utilizados na construção
das telas do sistema;
- JavaServer Pages;
b) ferramentas:
- Rational Rose, para a especificação do sistema;
- Jdeveloper, para o desenvolvimento do sistema;
- Oracle 8.1.6, como servidor de banco de dados;
- Oracle IAS (Internet Application Server), como servidor de aplicação e
servidor web;
- Internet Explorer 5.01, utilizado para executar as telas do sistema na máquina
cliente;
Buscando detalhar como cada tecnologia/ferramenta auxiliou na concepção deste
trabalho, divide-se o desenvolvimento do sistema em várias fases, levando em conta a
implementação da arquitetura multi-camadas:
a) camada da lógica de acesso aos dados:
- criação das tabelas no banco de dados, baseando-se no diagrama de classes;
35
- definição do padrão utilizado pelas páginas JSP e os componentes JavaBeans
para acessar o banco de dados Oracle;
b) camada das regras de negócios:
- criação dos componentes JavaBeans, baseando-se no diagrama de classes e
diagrama de sequência, utilizando a ferramenta JDeveloper;
- disponibilização do sistema no servidor de aplicação;
- construção dos arquivos JSP que terão acesso aos JavaBeans utilizando a
ferramenta Jdeveloper;
c) camada da lógica de apresentação:
- construção das telas do sistema, utilizando HTML, JavaScript e a ferramenta
JDeveloper;
- testes do sistema, utilizando o Internet Explorer 5.01;
3.3.1.1 CAMADA DA LÓGICA DE ACESSO AOS DADOS
Na camada da lógica de acesso aos dados utilizou-se um servidor executando o sistema
operacional linux RedHat versão 6.2 e o banco de dados Oracle Enterprise Edition versão
8.1.6.
Baseando-se no diagrama de classes descrito na especificação do sistema, criou-se as
tabelas “areas_atuacao” (quadro 8), “empresas” (quadro 9), “anuncios” (quadro 10) e
“propostas” (quadro 11).
Quadro 8 – Tabela AREAS_ATUACAO
Name Null? Type
----------------------- -------- --------------- -------------
CD_AREA_ATUACAO NOT NULL NUMBER(3)
DS_AREA_ATUACAO NOT NULL VARCHAR2(50)
Foi efetuada manualmente a carga da tabela “areas_atuacao” com valores pré-
definidos , visto que esta não possui métodos para acesso aos dados e só é utilizada para
classificar as empresas.
36
Quadro 9 – Tabela EMPRESAS
Name Null? Type
----------------------- -------- --------------- -------------
CD_CGC_EMPRESA NOT NULL NUMBER(20)
DS_EMPRESA NOT NULL VARCHAR2(50)
DS_CONTATO NOT NULL VARCHAR2(50)
DS_ENDERECO NOT NULL VARCHAR2(60)
DS_CIDADE NOT NULL VARCHAR2(30)
DS_UF NOT NULL VARCHAR2(2)
DS_CEP NOT NULL VARCHAR2(8)
DS_TEL NOT NULL VARCHAR2(15)
DS_FAX NOT NULL VARCHAR2(15)
DS_EMAIL NOT NULL VARCHAR2(50)
DS_HTTP NOT NULL VARCHAR2(50)
SENHA NOT NULL VARCHAR2(15)
CD_AREA_ATUACAO NOT NULL NUMBER(3)
Quadro 10 – Tabela ANUNCIOS
Name Null? Type
----------------------- -------- --------------- -------------
CD_ANUNCIO NOT NULL NUMBER(15)
DS_TITULO NOT NULL VARCHAR2(30)
DS_ANUNCIO NOT NULL VARCHAR2(256)
DT_ANUNCIO NOT NULL DATE
DT_FINAL NOT NULL DATE
VL_MINIMO NOT NULL NUMBER(13,2)
CD_CGC_EMPRESA NOT NULL NUMBER(20)
Quadro 11 – Tabela PROPOSTAS
Name Null? Type
----------------------- -------- --------------- -------------
CD_PROPOSTA NOT NULL NUMBER(15)
VL_PROPOSTA NOT NULL NUMBER(15,2)
FG_FECHADO NUMBER(1)
CD_ANUNCIO NOT NULL NUMBER(15)
CD_CGC_EMPRESA NOT NULL NUMBER(20)
37
Para que as páginas JSP e os componentes JavaBeans pudessem acessar as tabelas no
banco de dados, foi utilizado a API de Java JDBC (Sun Microsystems, 2001b).
A tecnologia JDBC é uma API (Application Program Interface) de Java que tem por
objetivo prover a comunicação de programas Java com o SGBD (Sistema Gerenciador de
Banco de Dados), como por exemplo: Oracle, DB2, Interbase, dentre outros.
O quadro 12 demonstra um exemplo do código que foi utilizado para acessar o banco
de dados, a partir de uma página JSP. O código mostrado no exemplo monta a lista de valores
de áreas de atuação, utilizada pelas telas de cadastramento e alteração de dados da empresa.
Inicialmente é importando o pacote “java.sql.*”, onde se encontram as classes JDBC. Depois
é carregado o driver para acesso ao banco de dados Oracle através do método
“DriverManager.registerDriver”. Logo após é estabelecida a conexão ao banco de dados
(“DriverManager.getConnection”). Uma vez efetuada a conexão ao banco de dados é
executado o comando SQL que trará o conjunto de dados desejados a partir da tabela
“areas_atuacao”.
As linhas seguintes fazem a leitura do resultado da consulta formatando os dados na
tela através de HTML. Este exemplo também demonstra a relação de comandos java através
dos scriptlets com os comandos HTML.
Quadro 12 – Exemplo de acesso ao banco de dados utilizando JDBC
<%@ page import="java.sql.*" %>
<% try { DriverManager.registerDriver (new
oracle.jdbc.driver.OracleDriver());
Connection conn = DriverManager.getConnection ("jdbc:oracle:thin:@192.168.0.100:1521:web","webdes en","xuxa.");
Statement Stmt = conn.createStatement();
ResultSet rset =
Stmt.executeQuery("select * from AREAS_ATUACAO o rder by 1");
%>
<TABLE ALIGN="center" border="1" CELLSPACING="0" CE LLPADDING="0" WIDTH="70%" >
<TR>
<TD ALIGN="CENTER" WIDTH="80%">
<FONT color="black"><B>Áreas de atuação</B></FO NT>
</TD>
38
</TR>
<% while (rset.next()) { %>
<TR>
<TD ALIGN="RIGHT" WIDTH="20%"><FONT color="black" >
<CENTER>
<A REF="JavaScript:opener.document.be1000.CD_ARE A_ATUACAO.value
= '<% out.print(rset.getString(1)); %>'; JavaScript:opener.document.be1000.DS_AREA_ATUACAO.v alue = '<% out.print(rset.getString(2)); %>'; this.close();">
<% out.print(rset.getString(2)); %></A>
</FONT>
</CENTER>
</TD>
</TR>
<% } %>
</TABLE>
<% rset.close();
Stmt.close();
conn.close();
} catch (SQLException E) {
out.print("SQLException: " + E.getMessage()) ;
}
%>
3.3.1.2 CAMADA DAS REGRAS DE NEGÓCIO
No que diz respeito às regras de negócio, utilizou-se o diagrama de classes e o
diagrama de sequência como base para criar os JavaBeans, componentes que implementam a
lógica da aplicação. Segue abaixo alguns detalhes do desenvolvimento dos JavaBeans,
maiores informações podem ser verificadas no código fonte que se encontra no anexo 1,
anexo 2 e anexo 3.
Foi criado um JavaBean “empresa” com os métodos: “inclui”, “altera”, “autentica” e
“validate”. Os métodos “inclui” e “altera” são responsáveis pela lógica de cadastramento da
empresa no sistema. O método “autentica” cuida da autenticação do CGC e da senha. O
método “validate” é responsável pela consistências das propriedades, originadas a partir das
páginas JSP.
39
Para a classe anúncio, foi criado um JavaBean com o mesmo nome, com os métodos
“inclui” e “validate”.
Da mesma forma foi criada um JavaBean para a classe proposta, com os métodos
“inclui”, “fecharnegociação” e “validate”.
Nota-se que em todos os JavaBeans criou-se um novo método denominado “validate”.
Este método é invocado pelas páginas JSP para consistência dos dados informados pelo
usuário. Uma grande vantagem de manter estas consistências dentro de JavaBeans, é que
existe a possibilidade de várias páginas JSP relacionadas a uma classe poderem utilizar o
mesmo método para consistência de seus dados. Isto caracteriza a reutilização de código
bastante comum na arquitetura multi-camadas.
Para as páginas JSP interagirem com os Beans, é necessário informar onde encontrar o
arquivo de classe Java que define o Bean e a atribuir um nome a ele. Pode-se então utilizar
este nome para acessar os valores armazenados nas propriedades do Bean.
Para os casos das páginas JSP que acessam Beans, foi definida uma página inicial que
monta a tela de entrada de dados. Um botão contido nesta página carrega uma função em
JavaScript passando como parâmetro a página que deve ser utilizada para processar os dados
digitados. A função então passa o controle para a nova página, enviando as informações
digitadas em tela (quadro 13).
Quadro 13 – Trecho do código da página be1080.jsp (novo anúncio)
<SCRIPT> <!--
function AbreJanela(url) { window.open( url,'Lista','toolbar=no,location=no,directories=no, status=no,menubar=no,scrollbars=yes,resizable=yes,titlebar=no,width=50 0,height=300,top=100,left=80'); return; }
</SCRIPT>
<INPUT TYPE="button" value=" Salva " onclick="AbreJanela('be1080process.jsp?CD_CGC_EMPRE SA=<% out.print(request.getParameter("CD_CGC_EMPRESA")); %>' + '&CD_ANUNCIO=0' + '&DS_TITULO=' + document.be1080.D S_TITULO.value + '&DS_ANUNCIO=' + document.be1080.DS_ANUNCIO.value + '&DT_ANUNCIO=' + document.be1080.DT_ANUNCIO.value + '&DT_FINAL=' + document.be1080.DT_FINAL.value + '&VL_MINIMO=' + document.be1080.VL_MINIMO.value);">
40
A página de destino então é executada, recebendo os parâmetros e repassando-os para
o componente Bean instanciado (quadro 14).
Quadro 14 – Trecho do código da página be1080process.jsp (novo anúncio)
<%@ page import="java.util.*" %>
<jsp:useBean id="be1080process" class="bolsaempresa rial.anuncio" scope="request" />
<jsp:setProperty name="be1080process" property="CD _ANUNCIO" value='0' />
<jsp:setProperty name="be1080process" property="DS _TITULO" value='<%= request.getParameter("DS_TITULO")%>' />
<jsp:setProperty name="be1080process" property="DS _ANUNCIO" value='<%= request.getParameter("DS_ANUNCIO")%>' />
<jsp:setProperty name="be1080process" property="DT _ANUNCIO" value='<%= request.getParameter("DT_ANUNCIO")%>' />
<jsp:setProperty name="be1080process" property="DT _FINAL" value='<%= request.getParameter("DT_FINAL")%>' />
<jsp:setProperty name="be1080process" property="VL _MINIMO" value='<%= request.getParameter("VL_MINIMO")%>' />
<jsp:setProperty name="be1080process" property="CD _CGC_EMPRESA" value='<%= request.getParameter("CD_CGC_EMPRESA")%> ' />
<% if (be1080process.validate()) {
if (be1080process.inclui()) { %>
<CENTER><h3>Inclusão efetuada com sucesso. </h3>
<INPUT type="button" value=" OK " onClic k= "opener.document.be1080.reset(); self.close();">
</CENTER>
<% } else { %>
<CENTER><h3><jsp:getProperty name="be1080p rocess" property="DS_ERRO" /></h3>
<INPUT type="button" value=" OK " onClick="s elf.close();">
</CENTER>
<% } %>
<% } else { %>
<CENTER>
<h3><jsp:getProperty name="be1080process" prope rty="DS_ERRO" /></h3>
<INPUT type="button" value=" OK " onClick="sel f.close();">
</CENTER>
<% } %>
</BODY>
</HTML>
41
Como servidor de aplicação, utilizou uma máquinua executando o sistema operacional
linux RedHat versão 6.2 e o Oracle Internet Application Server 9i. Não será detalhado o
conjunto de passos de configuração do servidor de aplicação, pois cada produto tem métodos
diferentes de configuração. O sistema desenvolvimento neste trabalho pode ser
disponibilizado em qualquer servidor de aplicação que tenha suporte a especificação JSP
versão 1.1.
3.3.1.3 CAMADA DA LÓGICA DE APRESENTAÇÃO
Para a construção das telas utilizou-se da linguagem de programação HTML e alguns
recursos de JavaScript para aperfeiçoar a interface com o usuário.
42
3.3.2 OPERACIONALIDADE DA IMPLEMENTAÇÃO
Com o objetivo de demonstrar o funcionamento do sistema, descreve-se a seguir um
estudo de caso, apresentando nomes de empresas, dados e situações fictícias.
A indústria têxtil Blutextil Ltda necessita vender alguns produtos que estão com a
venda em baixa causando acumulo em estoque e com isso um alto custo de armazenamento.
Através do sistema de leilão desenvolvido, a mesma pode anunciar os produtos desejados.
Para tal, é necessário que ela faça o cadastramento no sistema, conforme figura 15.
Figura 15 – Tela de cadastramento de empresa
Uma vez efetuado o cadastramento, o responsável pela empresa entra no sistema
através da autenticação do CGC e da senha cadastrada (figura 16).
43
Figura 16 – Tela de autenticação
Logo a seguir é exibida a tela principal, listando todos os anúncios cadastrados. A
partir desta, o usuário pode alterar os dados cadastrais da empresa, incluir novos anúncios,
fazer o acompanhamento de propostas e filtrar os anúncios por área de atuação (figura 17).
44
Figura 17 – Tela principal do sistema
Imaginando-se que a Indústria Têxtil Blutextil, queira realizar o anúncio de algum
produto, pode-se executá-lo utilizando o link que leva a tela de cadastramento de anúncios
(figura 18).
45
Figura 18 – Tela de cadastramento de novo anúncio
Clicando-se no botão “Salva” da tela de cadastramento de anúncio, o mesmo será
inserido imediatamente no banco de dados, ficando disponível para consulta.
No caso de outras empresas acessarem o sistema, as mesmas podem efetuar propostas
sobre o anúncio incluído, conforme demonstra a figura 19.
46
Figura 19 – Tela de detalhamento do anúncio
47
4 CONCLUSÕES
Com a disseminação do uso da internet nos últimos anos, a arquitetura multi-camadas
tem se tornado uma arquitetura bastante utilizada visando atender as necessidades de sistemas
de informações requeridos pelas empresas para buscar atender seus objetivos e a satisfação de
seus clientes. O objetivo principal deste trabalho foi alcançado através da implementação de
um sistema de leilão voltado para a internet.
Com o desenvolvimento do presente trabalho observou-se que a arquitetura multi-
camadas oferece vantagens significativas sobre as demais arquiteturas de software existentes
no mercado.
Porém, com estudo e implementação da arquitetura multi-camadas através da
tecnologia JavaServer Pages, algumas dificuldades foram encontradas devido a quantidade
de tecnologias que são envolvidas no desenvolvimento de um sistema para internet, sendo
necessário estudar cada uma delas para a correta implementação do sistema. Neste trabalho,
foi utilizado tecnologias para criação das telas (HTML, JavaScript e JSP), tecnologias para
encapsular as regras de negócios (JavaBeans), linguagens para trabalhar com banco de dados
como o SQL (Structured Query Language) além de ferramentas para desenvolvimento,
servidor de aplicação e sistema gerenciador de banco de dados.
Mesmo com um grande número de recursos e ferramentas envolvidas, a tecnologia
JavaServer Pages se mostrou uma excelente solução para desenvolvimentos de sistemas para
a internet, destacando os seguintes pontos:
a) JavaServer Pages tem suporte a rápida construção e manutenção das aplicações,
pela implementação da arquitetura multicamadas, através da construção de
componentes reutilizáveis e pela clara separação da lógica de apresentação da
lógica de negócios;
b) JSP não está vinculado a um fabricante. Qualquer camada de uma aplicação JSP
tem suporte a várias tecnologias existentes no mercado:
- camada de apresentação, pode ser construída através de HTML (Hyper Text
Markup Language), JavaScript, XML (Extended Markup Language) bem como
executar em navegadores como Internet Explorer, Netscape sob vários sistemas
operacionais como Windows, Linux, Mac, dentre outros;
48
- a camada de regras de negócio é implementada através de JavaBeans que são
suportados por vários servidores de aplicação existentes no mercado;
- na camada de acesso aos dados, JavaServer Pages tem suporte a uma série de
bancos de dados através da utilização da API de Java JDBC.
Sendo assim o autor espera que os objetivos alcançados na realização deste trabalho
possam conduzir à elaboração de outros trabalhos na área de sistemas distribuídos multi-
camadas, conforme sugestões a seguir.
4.1 EXTENSÕES
Como sugestões para trabalhos futuros sugere-se:
a) estudar o funcionamento dos servidores de aplicação;
b) utilizar JavaServer Pages na implementação de sistemas distribuídos utilizando o
suporte de Java para Enterprise JavaBeans;
Sugere-se ainda estudos no sentido de aprofundar a investigação do conceito de multi-
camadas no que diz respeito a camadas de gerência de aplicações distribuídas, utilizando
tecnologias como Enterprise JavaBeans.
Além das camadas de lógica do negócio, acesso a banco de dados e interface com o
usuário, pode-se propor arquiteturas mais complexas, que implementem camadas de serviços
típicos de sistemas distribuídos, tais como serviços de controle de transações, serviços de
comunicação entre partes do sistema, tolerância a falhas, dentre outras.
Tais estudos representam a evolução deste trabalho no que diz respeito ao
aprofundamento de questões relativas a arquiteturas de sistemas distribuídos.
49
REFERÊNCIAS BIBLIOGRÁFICAS
BATISTA, Galileu. Conteúdo Dinâmico, CGI, Servlets e JSP, Natal, [2000]. Disponível
em: < http://www.jspbrasil.com.br:8080/forum/forum.jsp?forum=1001&action=10>. Acesso
em: 21 mai. 2001.
BOCHENSKI, Barbara. Implementando sistema cliente/servidor de qualidade. São Paulo:
Makron Books, 1995.
FIELDS, Duane K.; Kolb, Mark A. Desenvolvendo na web com JavaServer Pages. 1. ed.
Tradução Rejane Freitas. Rio de Janeiro: Ciência Moderna Ltda, 2000.
FOWLER, Martin; Scott, Kendall. UML essencial. 2. ed. Tradução Vera Pezerico. Porto
Alegre: Bookman, 2000.
GOMES, Handerson Ferreira. JavaServer Pages, novo sucessor para as páginas ASP?, São
Paulo, dez. [2000]. Disponível em: <http://www.uol.com.br/webworld/tecnologia/handerson/
Hander016.htm>. Acesso em: 15 fev. 2001.
GOULD, Steven. Develop n-tier applications using J2EE, JavaServer Pages, dez. [2000].
Disponível em: <http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-eblogic_p.html>.
Acesso em: 25 mai. 2001.
HAMPSHIRE, Paulo. Usando java como ferramenta corporativa. Developers magazine. Rio
de Janeiro, v. 3, n. 34, p. 36-39, jun. 1999.
NTIER. Client/Server and the N-Tier Model of Distributed Computing, [1999?]
Disponível em: <http://www.n-tier.com/articles/csovervw.html>. Acesso em: 15 abr. 2001.
ROTH, Bill. An introduction to enterprise javabeans technology , Palo Alto, out. [1998]
Disponível em: <http: //developer.java.sun.com/developer/technicalArticles/ebeans/IntroEJB/
index.html>. Acesso em: 20 abr. 2001.
RATIONAL Software Corporation. Rational Rose, Cupertino, mai. [2001] Disponível em: <
http://www.rational.com/products/rose/index.jsp>. Acesso em: 28 mai. 2001.
50
SCHLICKMANN, Raquel. Aplicação da arquitetura multicamadas utilizando java. 1999.
85 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) - Centro de
Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
SUN Microsystems. JavaServer Pages technology white paper, Palo Alto, dez. [1999].
Disponível em: <http://java.sun.com/products/jsp/jspguide-wp.pdf>. Acesso em: 10 dez.
2000.
SUN Microsystems. JSP v1.1 syntax reference, Palo Alto, nov. [2000]. Disponível em: <
http://www.javasoft.com/products/jsp/tags/11/syntaxref11.html>. Acesso em: 15 fev. 2001.
SUN Microsystems. JavaServer Pages, Palo Alto, mai. [2001a]. Disponível em:
<http://java.sun.com/products/jsp/index.html>. Acesso em: 21 mai. 2001.
SUN Microsystems. JDBC data access api, Palo Alto, mai. [2001b]. Disponível em: <
http://java.sun.com/products/jdbc/index.html>. Acesso em: 30 mai. 2001.
51
Anexo 1 – Código fonte do JavaBean anuncio
/*
------------------------------------------------- ------------------
anuncio.java - Implementação da classe anuncio
Autor: Charles Burkhardt
Este JavaBean é composto por propriedades da clas se empresa e pelos
métodos validate(), inclui(), setProperty e getPr operty de cada
propriedade.
------------------------------------------------- ------------------
*/
package bolsaempresarial;
import java.sql.*;
import java.util.*;
import java.lang.*;
public class anuncio {
/* Atributos da classe anuncio */
private long CD_ANUNCIO; /* Código do a núncio */
private String DS_TITULO; /* Título */
private String DS_ANUNCIO; /* Descrição D etalhada */
private String DT_ANUNCIO; /* Data do anú ncio */
private String DT_FINAL; /* Data Final */
private long VL_MINIMO; /* Valor mínim o */
private long CD_CGC_EMPRESA; /* CGC da empr esa anunciante */
private String DS_ERRO;
/* Método para consistência das propriedades */
public boolean validate() {
if (DS_TITULO.equals("")) {
DS_ERRO="Informe o título do anúncio.";
DS_TITULO="";
return false;
}
if (DS_ANUNCIO.equals("")) {
DS_ERRO="Informe a descrição detalhada do an úncio.";
DS_ANUNCIO="";
return false;
52
}
if (DT_FINAL.equals("")) {
DS_ERRO="Informe a data final do anúncio.";
DT_FINAL="";
return false;
}
if (VL_MINIMO == 0) {
DS_ERRO="Informe o valor mínimo.";
VL_MINIMO=0;
return false;
}
return true;
}
/* Método para incluir registro na tabela ANUNCIOS */
public boolean inclui() {
DS_ERRO="";
String sql;
try {
DriverManager.registerDriver
(new oracle.jdbc.driver.OracleDriver());
Connection conn = DriverManager.getConnection
("jdbc:oracle:thin:@192.168.0.100:1521:web" ,"webdesen","xuxa.");
Statement Stmt = conn.createStatement();
ResultSet resultset =
Stmt.executeQuery("Select nvl(Max(CD_ANUNCI O),0) from anuncios");
if (resultset.next()) {
CD_ANUNCIO = (Long.parseLong(resultset.getSt ring(1))) + 1;
sql = "INSERT INTO ANUNCIOS VALUES (";
sql += CD_ANUNCIO + ",";
sql += "'" + DS_TITULO + "',";
sql += "'" + DS_ANUNCIO + "',";
sql += "TO_DATE('" + DT_ANUNCIO + "','DD/MM/ YYYY'),";
sql += "TO_DATE('" + DT_FINAL + "','DD/MM/YY YY'),";
sql += "'" + VL_MINIMO + "',";
sql += CD_CGC_EMPRESA + ")";
int rset = Stmt.executeUpdate(sql);
53
Stmt.close();
conn.close();
return true;
}
return false;
} catch (SQLException E) {
DS_ERRO = E.getMessage();
return false;
}
}
/* Método constructor */
public anuncio() {
CD_ANUNCIO=0;
DS_TITULO="";
DS_ANUNCIO="";
DT_ANUNCIO="";
DT_FINAL="";
VL_MINIMO=0;
CD_CGC_EMPRESA=0;
DS_ERRO="";
}
/* Métodos setProperty */
public void setCD_ANUNCIO(String P_CD_ANUNCIO) {
try {
this.CD_ANUNCIO = Long.parseLong(P_CD_ANUNCIO);
} catch (NumberFormatException E) {
this.CD_ANUNCIO = 0;
}
}
public void setDS_TITULO(String P_DS_TITULO) {
this.DS_TITULO = P_DS_TITULO;
}
public void setDS_ANUNCIO(String P_DS_ANUNCIO) {
this.DS_ANUNCIO = P_DS_ANUNCIO;
}
public void setDT_ANUNCIO(String P_DT_ANUNCIO) {
this.DT_ANUNCIO = P_DT_ANUNCIO;
54
}
public void setDT_FINAL(String P_DT_FINAL) {
this.DT_FINAL = P_DT_FINAL;
}
public void setVL_MINIMO(String P_VL_MINIMO) {
try {
this.VL_MINIMO = Long.parseLong(P_VL_MINIMO);
} catch (NumberFormatException E) {
this.VL_MINIMO = 0;
}
}
public void setCD_CGC_EMPRESA(String P_CD_CGC_EMPR ESA) {
try {
this.CD_CGC_EMPRESA = Long.parseLong(P_CD_CGC_EM PRESA);
} catch (NumberFormatException E) {
this.CD_CGC_EMPRESA = 0;
}
}
/* Métodos getProperty */
public long getCD_ANUNCIO() {
return CD_ANUNCIO;
}
public String getDS_TITULO() {
return DS_TITULO;
}
public String getDS_ANUNCIO() {
return DS_ANUNCIO;
}
public String getDT_ANUNCIO() {
return DT_ANUNCIO;
}
public String getDT_FINAL() {
return DT_FINAL;
}
public long getVL_MINIMO() {
return VL_MINIMO;
}
public long getCD_CGC_EMPRESA() {
55
return CD_CGC_EMPRESA;
}
public String getDS_ERRO() {
return DS_ERRO;
}
}
56
Anexo 2 – Código fonte do JavaBean proposta
/*
proposta.java - Implementação da classe empresa
Autor: Charles Burkhardt
Este JavaBean é composto por propriedades da clas se proposta e pelos
métodos validate(), inclui(), setProperty e getPr operty de cada
propriedade.
*/
package bolsaempresarial;
import java.sql.*;
import java.util.*;
import java.lang.*;
public class proposta {
/* Atributos da classe proposta */
private long CD_PROPOSTA;
private long VL_PROPOSTA;
private int FG_FECHADO;
private long CD_ANUNCIO;
private long CD_CGC_EMPRESA;
private String DS_ERRO;
/* Método para consistência das propriedades */
public boolean validate() {
if (VL_PROPOSTA == 0) {
DS_ERRO="Informe o valor da proposta.";
VL_PROPOSTA=0;
return false;
}
if (CD_ANUNCIO == 0) {
DS_ERRO="Erro ao passar parâmetro: CD_ANUNCI O.";
CD_ANUNCIO=0;
return false;
}
if (CD_CGC_EMPRESA == 0) {
DS_ERRO="Erro ao passar parâmetro: CD_CGC_EM PRESA.";
57
CD_CGC_EMPRESA=0;
return false;
}
return true;
}
/* Método para incluir registro na tabela ANUNCIOS */
public boolean inclui() {
DS_ERRO="";
String sql;
try {
DriverManager.registerDriver
(new oracle.jdbc.driver.OracleDriver());
Connection conn = DriverManager.getConnection
("jdbc:oracle:thin:@192.168.0.100:1521:w eb","webdesen","xuxa.");
Statement Stmt = conn.createStatement();
ResultSet resultset =
Stmt.executeQuery("Select nvl(Max(CD_ANUNCIO), 0) from propostas");
if (resultset.next()) {
CD_PROPOSTA = (Long.parseLong(resultset.getS tring(1))) + 1;
sql = "INSERT INTO PROPOSTAS VALUES (";
sql += CD_PROPOSTA + ",";
sql += VL_PROPOSTA + ",";
sql += FG_FECHADO + ",";
sql += CD_ANUNCIO + ",";
sql += CD_CGC_EMPRESA + ")";
int rset = Stmt.executeUpdate(sql);
Stmt.close();
conn.close();
return true;
}
return false;
} catch (SQLException E) {
DS_ERRO = E.getMessage();
return false;
}
}
58
/* Método constructor */
public proposta() {
CD_PROPOSTA=0;
VL_PROPOSTA=0;
FG_FECHADO=0;
CD_ANUNCIO=0;
CD_CGC_EMPRESA=0;
DS_ERRO="";
}
/* Métodos setProperty */
public void setCD_PROPOSTA(String P_CD_PROPOSTA) {
try {
this.CD_PROPOSTA = Long.parseLong(P_CD_PROPOSTA) ;
} catch (NumberFormatException E) {
this.CD_PROPOSTA = 0;
}
}
public void setVL_PROPOSTA(String P_VL_PROPOSTA) {
try {
this.VL_PROPOSTA = Long.parseLong(P_VL_PROPOSTA) ;
} catch (NumberFormatException E) {
this.VL_PROPOSTA = 0;
}
}
public void setFG_FECHADO(String P_FG_FECHADO) {
try {
this.FG_FECHADO = Integer.parseInt(P_FG_FECHADO) ;
} catch (NumberFormatException E) {
this.FG_FECHADO = 0;
}
}
public void setCD_ANUNCIO(String P_CD_ANUNCIO) {
try {
this.CD_ANUNCIO = Long.parseLong(P_CD_ANUNCIO);
} catch (NumberFormatException E) {
this.CD_ANUNCIO = 0;
}
}
59
public void setCD_CGC_EMPRESA(String P_CD_CGC_EMPR ESA) {
try {
this.CD_CGC_EMPRESA = Long.parseLong(P_CD_CGC_EM PRESA);
} catch (NumberFormatException E) {
this.CD_CGC_EMPRESA = 0;
}
}
/* Métodos getProperty */
public long getCD_PROPOSTA() {
return CD_PROPOSTA;
}
public long getVL_PROPOSTA() {
return VL_PROPOSTA;
}
public long getFG_FECHADO() {
return FG_FECHADO;
}
public long getCD_ANUNCIO() {
return CD_ANUNCIO;
}
public long getCD_CGC_EMPRESA() {
return CD_CGC_EMPRESA;
}
public String getDS_ERRO() {
return DS_ERRO;
}
}
60
Anexo 3 – Código fonte do JavaBean empresa
/*
empresa.java - Empresa
Autor: Charles Burkhardt
Este JavaBean é composto por propriedades da clas se empresa e pelos
métodos validate(), inclui(), setProperty e getPr operty de cada
propriedade.
*/
package bolsaempresarial;
import java.sql.*;
import java.util.*;
import java.lang.*;
public class empresa {
/* Atributos da classe empresa */
private long CD_CGC_EMPRESA;
private int CD_AREA_ATUACAO;
private String DS_EMPRESA;
private String DS_CONTATO;
private String DS_ENDERECO;
private String DS_CIDADE;
private String DS_UF;
private String DS_CEP;
private String DS_TEL;
private String DS_FAX;
private String DS_EMAIL;
private String DS_HTTP;
private String SENHA;
private String CONFIRMACAO;
private String DS_ERRO;
/* Método para consistência das propriedades */
public boolean validate() {
DS_ERRO="";
if (CD_CGC_EMPRESA == 0) {
DS_ERRO="Código do CGC inválido.";
CD_CGC_EMPRESA=0;
61
return false;
}
if (CD_AREA_ATUACAO == 0) {
DS_ERRO="Informe a Área de atuação.";
CD_CGC_EMPRESA=0;
return false;
}
if (DS_EMPRESA.equals("")) {
DS_ERRO="Informe o nome da empresa.";
DS_EMPRESA="";
return false;
}
if (DS_CONTATO.equals("")) {
DS_ERRO="Informe a pessoa de contato.";
DS_CONTATO="";
return false;
}
if (DS_ENDERECO.equals("")) {
DS_ERRO="Informe o endereço.";
DS_ENDERECO="";
return false;
}
if (DS_CIDADE.equals("")) {
DS_ERRO="Informe a cidade.";
DS_CIDADE="";
return false;
}
if (DS_UF.equals("")) {
DS_ERRO="Informe a UF.";
DS_UF="";
return false;
}
if (DS_CEP.equals("")) {
DS_ERRO="Informe o CEP.";
DS_CEP="";
return false;
}
if (DS_TEL.equals("")) {
DS_ERRO="Informe o Telefone.";
62
DS_TEL="";
return false;
}
if (DS_FAX.equals("")) {
DS_ERRO="Informe o FAX.";
DS_FAX="";
return false;
}
if (DS_EMAIL.equals("")) {
DS_ERRO="Informe o EMAIL.";
DS_EMAIL="";
return false;
}
if (DS_HTTP.equals("")) {
DS_ERRO="Informe a página HTTP da empresa.";
DS_HTTP="";
return false;
}
if (SENHA.equals("")) {
DS_ERRO="Informe a Senha.";
SENHA="";
return false;
}
if (CONFIRMACAO.equals(SENHA)) {
}
else {
DS_ERRO="Você deve confirmar a senha.";
CONFIRMACAO="";
return false;
}
return true;
}
/* Método para incluir registro na tabela EMPRESAS */
public boolean inclui() {
DS_ERRO="";
String sql;
sql = "INSERT INTO EMPRESAS VALUES (";
63
sql += CD_CGC_EMPRESA + ",";
sql += "'" + DS_EMPRESA + "',";
sql += "'" + DS_CONTATO + "',";
sql += "'" + DS_ENDERECO + "',";
sql += "'" + DS_CIDADE + "',";
sql += "'" + DS_UF + "',";
sql += "'" + DS_CEP + "',";
sql += "'" + DS_TEL + "',";
sql += "'" + DS_FAX + "',";
sql += "'" + DS_EMAIL + "',";
sql += "'" + DS_HTTP + "',";
sql += "'" + SENHA + "',";
sql += CD_AREA_ATUACAO + ")";
try {
DriverManager.registerDriver (new oracle.jdbc. driver.OracleDriver());
Connection conn = DriverManager.getConnection ("jdbc:oracle:thin:@192.168.0.100:1521:web","webdes en","xuxa.");
Statement Stmt = conn.createStatement();
int rset = Stmt.executeUpdate(sql);
Stmt.close();
conn.close();
return true;
} catch (SQLException E) {
DS_ERRO = E.getMessage();
return false;
}
}
/* Método para alterar registro na tabela EMPRESAS */
public boolean altera() {
DS_ERRO="";
String sql;
sql = "UPDATE EMPRESAS SET ";
sql += " CD_AREA_ATUACAO=" + CD_AREA_ATUACAO;
sql += ",DS_EMPRESA='" + DS_EMPRESA + "'";
sql += ",DS_CONTATO='" + DS_CONTATO + "'";
sql += ",DS_ENDERECO='" + DS_ENDERECO + "'";
sql += ",DS_CIDADE='" + DS_CIDADE + "'";
64
sql += ",DS_UF='" + DS_UF + "'";
sql += ",DS_CEP='" + DS_CEP + "'";
sql += ",DS_TEL='" + DS_TEL + "'";
sql += ",DS_FAX='" + DS_FAX + "'";
sql += ",DS_EMAIL='" + DS_EMAIL + "'";
sql += ",DS_HTTP='" + DS_HTTP + "'";
sql += ",SENHA='" + SENHA + "'";
sql += " WHERE CD_CGC_EMPRESA=" + CD_CGC_EMPRES A;
try {
DriverManager.registerDriver (new oracle.jdbc. driver.OracleDriver());
Connection conn = DriverManager.getConnection ("jdbc:oracle:thin:@192.168.0.100:1521:web","webdes en","xuxa.");
Statement Stmt = conn.createStatement();
int rset = Stmt.executeUpdate(sql);
Stmt.close();
conn.close();
return true;
} catch (SQLException E) {
DS_ERRO = E.getMessage();
return false;
}
}
/* Método para autenticar CGC e senha */
public boolean autentica() {
DS_ERRO="";
String sql;
sql = "SELECT * FROM EMPRESAS WHERE CD_CGC_EMP RESA=";
sql += Long.toString(CD_CGC_EMPRESA) + " AND SE NHA = '";
sql += SENHA + "'";
try {
DriverManager.registerDriver (new oracle.jdbc. driver.OracleDriver());
Connection conn = DriverManager.getConnection ("jdbc:oracle:thin:@192.168.0.100:1521:web","webdes en","xuxa.");
Statement Stmt = conn.createStatement();
ResultSet rset = Stmt.executeQuery(sql);
65
if (rset.next()) {
rset.close();
Stmt.close();
conn.close();
return true;
}
else {
rset.close();
Stmt.close();
conn.close();
DS_ERRO="CGC/Senha inválidos.";
return false;
}
} catch (SQLException E) {
DS_ERRO = E.getMessage();
return false;
}
}
/* Método constructor */
public empresa() {
CD_CGC_EMPRESA=0;
CD_AREA_ATUACAO=0;
DS_EMPRESA="";
DS_CONTATO="";
DS_ENDERECO="";
DS_CIDADE="";
DS_UF="";
DS_CEP="";
DS_TEL="";
DS_FAX="";
DS_EMAIL="";
DS_HTTP="";
SENHA="";
CONFIRMACAO="";
DS_ERRO="";
}
/* Métodos setProperty */
public void setCD_CGC_EMPRESA(String P_CD_CGC_EMPR ESA) {
66
try {
this.CD_CGC_EMPRESA = Long.parseLong(P_CD_CGC_EM PRESA);
} catch (NumberFormatException E) {
this.CD_CGC_EMPRESA = 0;
}
}
public void setCD_AREA_ATUACAO(String P_CD_AREA_AT UACAO) {
try {
this.CD_AREA_ATUACAO = Integer.parseInt(P_CD_ARE A_ATUACAO);
} catch (NumberFormatException E) {
this.CD_AREA_ATUACAO = 0;
}
}
public void setDS_EMPRESA(String P_DS_EMPRESA) {
this.DS_EMPRESA = P_DS_EMPRESA;
}
public void setDS_CONTATO(String P_DS_CONTATO) {
this.DS_CONTATO = P_DS_CONTATO;
}
public void setDS_ENDERECO(String P_DS_ENDERECO) {
this.DS_ENDERECO = P_DS_ENDERECO;
}
public void setDS_CIDADE(String P_DS_CIDADE) {
this.DS_CIDADE = P_DS_CIDADE;
}
public void setDS_UF(String P_DS_UF) {
this.DS_UF = P_DS_UF;
}
public void setDS_CEP(String P_DS_CEP) {
this.DS_CEP = P_DS_CEP;
}
public void setDS_TEL(String P_DS_TEL) {
this.DS_TEL = P_DS_TEL;
}
public void setDS_FAX(String P_DS_FAX) {
this.DS_FAX = P_DS_FAX;
}
public void setDS_EMAIL(String P_DS_EMAIL) {
this.DS_EMAIL = P_DS_EMAIL;
67
}
public void setDS_HTTP(String P_DS_HTTP) {
this.DS_HTTP = P_DS_HTTP;
}
public void setSENHA(String P_SENHA) {
this.SENHA = P_SENHA;
}
public void setCONFIRMACAO(String P_CONFIRMACAO) {
this.CONFIRMACAO = P_CONFIRMACAO;
}
public void setDS_ERRO(String P_DS_ERRO) {
this.DS_ERRO = P_DS_ERRO;
}
/* Métodos getProperty */
public long getCD_CGC_EMPRESA() {
return CD_CGC_EMPRESA;
}
public int getAREA_ATUACAO() {
return CD_AREA_ATUACAO;
}
public String getDS_EMPRESA() {
return DS_EMPRESA;
}
public String getDS_CONTATO() {
return DS_CONTATO;
}
public String getDS_ENDERECO() {
return DS_ENDERECO;
}
public String getDS_CIDADE() {
return DS_CIDADE;
}
public String getDS_UFComm() {
return DS_UF;
}
public String getDS_CEP() {
return DS_CEP;
}
68
public String getDS_TEL() {
return DS_TEL;
}
public String getDS_FAX() {
return DS_FAX;
}
public String getDS_EMAIL() {
return DS_EMAIL;
}
public String getDS_HTTP() {
return DS_HTTP;
}
public String getSENHA() {
return SENHA;
}
public String getCONFIRMACAO() {
return CONFIRMACAO;
}
public String getDS_ERRO() {
return DS_ERRO;
}
}