DESENVOLVIMENTO DE UM SISTEMA DE LEILÃO UTILIZANDO JAVASERVER PAGES

Transcrição

1 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/ /1-15

2 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 ii

3 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. iii

4 SUMÁRIO LISTA DE FIGURAS...vi LISTA DE QUADROS...vii RESUMO...viii ABSTRACT...ix 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA HISTÓRICO DA ARQUITETURA DE SOFTWARE ARQUITETURA DE UMA CAMADA ARQUITETURA DE DUAS CAMADAS ARQUITETURA MULTI-CAMADAS A ARQUITETURA MULTI-CAMADAS E A INTERNET COMMON GATEWAY INTERFACE (CGI) COLDFUSION ACTIVE SERVER PAGES (ASP) SERVER-SIDE JAVASCRIPT (SSJS) PHP APPLETS E SERVLETS JAVASERVER PAGES (JSP) COMO JSP FUNCIONA JAVASERVER PAGES E MULTICAMADAS...17 iv

5 JAVABEANS & ENTERPRISE JAVABEANS A SINTAXE JSP DIRETIVA PAGE TAG JSP:USEBEAN TAG JSP:SETPROPERTY TAG JSP:GETPROPERTY TAG JSP:FORWARD SCRIPTLET DESENVOLVIMENTO DO TRABALHO REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ESPECIFICAÇÃO DIAGRAMA DE CASOS DE USO DIAGRAMA DE CLASSES DIAGRAMAS DE SEQUÊNCIA IMPLEMENTAÇÃO TÉCNICAS E FERRAMENTAS UTILIZADAS CAMADA DA LÓGICA DE ACESSO AOS DADOS CAMADA DAS REGRAS DE NEGÓCIO CAMADA DA LÓGICA DE APRESENTAÇÃO OPERACIONALIDADE DA IMPLEMENTAÇÃO CONCLUSÕES EXTENSÕES...48 REFERÊNCIAS BIBLIOGRÁFICAS...49 ANEXOS...51 v

6 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 vi

7 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 vii

8 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. viii

9 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. ix

10 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, é

11 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.

12 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.

13 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 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

14 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,

15 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 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:

16 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;

17 f) o banco de dados é independente pois os acessos a dados são escritos utilizando o padrão SQL (Structured Query Language) 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

18 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 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,

19 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) 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) 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) 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

20 scripts para navegadores da web. SSJS é específico para servidores de HTTP (HyperText Transport Protocol) da Netscape (Fields, 2000) 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) 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

21 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) 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).

22 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 bytecode) 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 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

23 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) 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).

24 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).

25 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

26 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) 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 multicamadas (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 , 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 Lógica de apresentação Regras de negócio Acesso aos dados Servidor web Servidor de aplicação JDBC BROWSER JSP SERVLET JavaBeans Servidor de banco de dados

27 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.

28 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.

29 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.

30 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) 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

31 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 %> 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 />

32 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= NomeEmpresa value= Tabajara SA /> 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).

33 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= NomeEmpresa /> </CENTER> 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 /> 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

34 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 <% %>

35 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.

36 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 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.