Você está na página 1de 148

UNIVERSIDADE DO PLANALTO CATARINENSE

DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS


CURSO DE INFORMÁTICA
(BACHARELADO)

UMA APLICAÇÃO WEB PARA SERVIÇOS PRÉ-SOLICITADOS

Relatório do Trabalho de Conclusão de


Curso submetido à Universidade do
Planalto Catarinense para obtenção dos
Créditos de disciplina com nome
equivalente no curso de Informática -
Bacharelado.

CLAUDIONEI MADEIRA GUIMARÃES

LAGES, NOVEMBRO DE 2002.


UNIVERSIDADE DO PLANALTO CATARINENSE
DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
CURSO DE INFORMÁTICA
(BACHARELADO)

UMA APLICAÇÃO WEB PARA SERVIÇOS PRÉ-SOLICITADOS

Relatório do Trabalho de Conclusão de


Curso submetido à Universidade do
Planalto Catarinense para obtenção dos
créditos de disciplina com nome equivalente
no curso de Informática - Bacharelado.

CLAUDIONEI MADEIRA GUIMARÃES

Orientador: Prof. Douglas Nazareno


Debiazi Vargas, M.Sc

LAGES, NOVEMBRO DE 2002


UMA APLICAÇÃO WEB PARA SERVIÇOS PRÉ-SOLICITADOS

CLAUDIONEI MADEIRA GUIMARÃES

ESTE RELATÓRIO, DO TRABALHO DE CONCLUSÃO DE CURSO, FOI


JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS DA
DISCIPLINA DE TRABALHO DE CONCLUSÃO DE CURSO DO VIII
SEMESTRE, OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE:

BACHAREL EM INFORMÁTICA

Prof. Douglas Nazareno Debiazi Vargas, M.Sc.


Orientador

BANCA EXAMINADORA:

Marcos André Pisching, M. Sc. Edson Roberto S. Paes , Bel.


Uniplac Uniplac

Prof. Angelo Augusto Frozza, Esp.


Supervisor de TCC

Lages, 11 Novembro de 2002


SUMÁRIO

LISTA DE SIGLAS ............................................................................................... VII


LISTA DE FIGURAS ..............................................................................................IX
LISTA DE QUADROS .......................................................................................... XII
RESUMO ............................................................................................................... XII
ABSTRACT ..........................................................................................................XIII
1. INTRODUÇÃO .................................................................................................... 14
1.1. Apresentação ...................................................................................................... 14
1.2. Definição do Problema .......................................................................................... 2
1.3. Justificativa ........................................................................................................... 3
1.4. Objetivos .............................................................................................................. 4
1.4.1. Objetivo Geral.............................................................................................................. 4
1.4.2. Objetivos Específicos ................................................................................................... 4
1.5. Metodologias ........................................................................................................ 4
2. TCP/IP E INTERNET............................................................................................ 6
2.1. Evolução Histórica do TCP/IP e da Internet .......................................................... 6
2.2. Conceitos de Internet e TCP/IP ............................................................................. 9
2.3. Serviços WWW e E-mail .................................................................................... 10
2.3.1. O Ambiente WWW (World Wide Web) ........................................................................ 10
2.3.2. Serviço de E-mail ? .................................................................................................... 12
2.4. Conclusão ........................................................................................................... 15
3. APLICAÇÕES WEB ........................................................................................... 16
3.1. A Importância do TCP/IP na Comunicação ......................................................... 16
3.2. Arquitetura Cliente/Servidor Web ....................................................................... 17
3.2.1. Sistema Cliente Web ................................................................................................... 18
3.2.2. Sistema Servidor Web ................................................................................................. 18
3.3. Linguagens Web ................................................................................................. 19
3.3.1. Linguagem HTML ...................................................................................................... 19
3.3.2. Linguagem JavaScript ................................................................................................ 20
3.3.3. Linguagem JAVA ........................................................................................................ 21
3.3.4. Script CGI ........................................................................................................ 23
3.3.5. Active Server Pages - ASP .......................................................................................... 24
3.4. Conclusão ........................................................................................................... 26
v

4. BANCO DE DADOS ............................................................................................ 27


4.1. Vantagens da Utilização de Banco de Dados: ...................................................... 28
4.2. Arquitetura de Banco de Dados ........................................................................... 29
4.3. Sistema Gerenciador de Banco de Dados (SGBD) .............................................. 30
4.3.1. Funções do SGBD ...................................................................................................... 30
4.4. Banco de Dados Interbase ................................................................................... 32
4.4.1. A Ferramenta IBConsole ............................................................................................ 35
4.5. Manutenção de Banco de Dados ......................................................................... 39
4.5.1. Backup e Restore no Interbase ................................................................................... 39
4.6. Conclusão ........................................................................................................... 43
5. CONCEITOS DE MODELAGEM ............................................................................... 45
5.1. A Importância da Modelagem ............................................................................. 45
5.2. Histórico da UML ............................................................................................... 47
5.3. A UML ? ............................................................................................................ 49
5.4. Diagramas da UML............................................................................................. 50
5.4.1. Diagrama de Caso de Uso ...................................................................................... 5063
5.4.2. Diagrama de Seqüência.............................................................................................. 51
5.4.3. Diagrama de Classe ................................................................................................... 52
5.5. Ferramentas de Modelagem ................................................................................ 53
5.5.1. Rational Rose ............................................................................................................. 54
5.6. Conclusão ........................................................................................................... 56
6. SISTEMA DE ATENDIMENTO CONVENCIONAL ...................................................... 57
6.1. Funcionamento da Floricultura............................................................................ 57
6.2. Funcionamento da Telemensagem ...................................................................... 58
7. MODELAGEM DO PROJETO ................................................................................... 59
7.1. Uma Aplicação Web para Serviços pré-solicitados ............................................. 59
7.2. Capturando Elementos do Modelo de Negócios .................................................. 60
7.3. Apresentando as Interações ................................................................................. 62
7.3.1. Cenário para Consultar Flores e Vasos ...................................................................... 62
7.3.2. Cenário para Consultar Mensagens ........................................................................... 63
7.3.3. Cenário Ocasião ........................................................................................................ 64
7.3.4. Cenário para Fazer Cadastro ..................................................................................... 65
7.3.5. Cenário para Fazer Pedido ........................................................................................ 66
7.3.6. Cenário para Gerenciar Produtos_serviços................................................................ 68
7.3.7. Cenário para Gerenciar Administrador. ..................................................................... 68
7.3.8. Cenário para Gerenciar Categorias ........................................................................... 69
7.3.9. Cenário para Gerenciar Clientes................................................................................ 70
7.3.10. Cenário para Gerenciar Forma de Pagamento. ........................................................ 71
7.3.11. Cenário para Gerenciar Itens do Pedido. ................................................................. 72
7.3.12. Cenário para Gerenciar Pedido. .............................................................................. 73
7.3.13. Cenário para Gerenciar Ocasião . ........................................................................... 74
7.3.14. Cenário para Validar Administrador ........................................................................ 75
7.4. Definição do Banco de Dados ............................................................................. 76
7.4.1. Clientes ...................................................................................................................... 77
7.4.2. Administrador ............................................................................................................ 77
vi

7.4.3. Forma de Pagamento ................................................................................................. 77


7.4.4. Ocasião ...................................................................................................................... 77
7.4.5. Categoria ................................................................................................................... 78
7.4.6. Produto_Serviço ......................................................................................................... 78
7.4.7. Pedido ........................................................................................................................ 78
7.4.8. ItensPedido ................................................................................................................ 78
7.5. Diagrama de Classes ........................................................................................... 80
7.6. Conclusão ........................................................................................................... 81
8. IMPLEMENTAÇÃO ................................................................................................. 82
8.1. Concepção do Site .............................................................................................. 82
8.2. Geração do Banco de Dados ............................................................................... 83
8.2.1. Criação de Domínios.................................................................................................. 83
8.2.2. Criação das Tabelas................................................................................................... 85
8.3.3. Criação dos Generator’s ............................................................................................ 87
8.2.4. Criação dos Trigger’s ................................................................................................ 88
8.3. Definição da Estrutura ........................................................................................ 90
8.3.1. Página de Consultas e Comercialização ..................................................................... 90
8.3.2. Página de administração ............................................................................................ 98
8.4. O Desenvolvimento das Páginas ....................................................................... 101
8.4.1. Desenvolvimento das Páginas de Gerência .............................................................. 102
8.4.2. Desenvolvimento das Páginas de Cadastro .............................................................. 102
8.4.3. Páginas para exibir consultas dos Clientes............................................................... 103
8.5. Conclusão ......................................................................................................... 103
9. AMBIENTE DE TESTE .......................................................................................... 104
9.1. Recursos Utilizados .......................................................................................... 104
9.2. Configurando as aplicações ASP ....................................................................... 105
9.3. Configurando o Drive ODBC ............................................................................ 105
10. CONCLUSÃO ...................................................................................................... 108
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................. 134
LISTA DE SIGLAS

ASCII - American Standard Code for Information Interchange


ANSP - An Academic Network At São Paulo
ATM - Asynchronous Transfer Mode
ARPA - Advanced Research Project Agency
ASP - Active Server Pages
CGI - Common Gateway Interface
DBA - database Administrator
DDL - Data Definition Language
DEC - Digital Equipment Corporation
DML - Data Manipulation Language
DNS - Domain Name System
Fapesp - Fundação de Amparo a Pesquisa do Estado de São Paulo
FTP - File Transfer Protocol
HP - Hewlett-Packard
HTML - HyperText Markup Language
HTTP - HyperText Transfer Protocol
IIS - Internet Information Server
IMP - Interface Message Processor
LAN - Local Area Network
MAN - Metropolitan Area Network
MIME - Multipurpose Internet Mail Extension
MPEG - Motion Picture Experts Group
MP3 - MPEG-I Audio Layer 3
NCP - Network Control Protocol
OMG - Object Management Group
OMT - Object Modeling Technique
OOA - Object Oriented Analise
OOSE - Object – Oriented Software Engineering
PERL - Pratical Extraction and Report Language
POP - Post Office Protocol
PUC-RIO - Pontifícia Universidade Católica do Rio de Janeiro
PWS - Personal Web Server
RNP - Rede Nacional de Pesquisa
RTF - Revision Task Force
viii

SGBD - Sistema Gerenciador de Banco de Dados


SGBDR - Sistema Gerenciador de Banco de Dados Relacional
SMTP - Simple Mail Transfer Protocol
SQL - Structured Query Language
TCP/IP - Transmission Control Protocol/Internet Protocol
Telnet - Emulação de terminal remoto
UFRJ - Universidade Federal do Rio de Janeiro
UML - Unified Modeling Language
UNICAMP - Universidade de Campinas
UNIPLAC - Universidade do Planalto Catarinense
USP - Universidade de São Paulo
WAN - Wide Area Network
WWW - World Wide Web
LISTA DE FIGURAS

Figura 1: Ferramenta IBConsole ............................................................................ 36


Figura 2: Elementos da Ferramenta IBConsole ...................................................... 36
Figura 3: Menu IBConsole ..................................................................................... 37
Figura 4: Ferramenta Interactive SQL .................................................................... 38
Figura 5: Menu da Ferramenta Interactive SQL ..................................................... 38
Figura 6: Acessando Operações de Backup no Interbase 6.0 .................................. 40
Figura 7: Tela de Backup do Banco de Dados Interbase 6.0................................... 40
Figura 8: Acessando operações de Restore no Interbase 6.0 .................................. 42
Figura 9: Tela de Restore do Banco de Dados Interbase 6.0 .................................. 42
Figura 10: Diagrama de Caso de Uso ..................................................................... 51
Figura 11: Diagrama de Seqüência......................................................................... 52
Figura 12: Diagrama de Classe .............................................................................. 53
Figura 13: A Ferramenta Rational Rose ................................................................. 55
Figura 14: Diagrama de Caso de Uso do Sistema Proposto .................................... 61
Figura 15: Diagrama de Seqüência Consultar Flores e Vasos ................................. 63
Figura 16: Diagrama de Seqüência Consultar Mensagem....................................... 64
Figura 17: Diagrama de Seqüência Ocasião ........................................................... 65
Figura 18: Diagrama de Seqüência Fazer Cadastro ................................................ 66
Figura 19: Diagrama de Seqüência Fazer Pedido ................................................... 67
Figura 20: Diagrama de Seqüência Gerência de Produtos e/ou Serviço .................. 68
Figura 21: Diagrama de Seqüência Gerenciar Administrador ................................. 69
Figura 22: Diagrama de Seqüência Gerenciar Categorias ....................................... 70
Figura 23: Diagrama de Seqüência Gerencia Clientes ............................................ 71
Figura 24: Diagrama de Seqüência Gerenciar Forma de Pagamento ...................... 72
Figura 25: Diagrama de Seqüência Gerenciar Itens do Pedido ............................... 73
Figura 26: Diagrama de Seqüência Gerenciar Pedido ............................................. 74
Figura 27: Diagrama de Seqüência Gerenciar Ocasião ........................................... 75
Figura 28: Diagrama de Seqüência Validar Administrador .................................... 76
Figura 29: Diagrama de Banco de Dados ............................................................... 79
Figura 30: Diagrama de Classes do Site ................................................................. 80
Figura 31: Página de Consultas e Comercialização ................................................ 91
Figura 32: Página Ocasião ..................................................................................... 92
Figura 33: Página Consulta Flores e Vasos ............................................................ 93
Figura 34: Página Consulta de Mensagens ............................................................. 93
x

Figura 35: Página Verificação de Clientes ............................................................. 94


Figura 36: Página Cadastro de Clientes .................................................................. 95
Figura 37: Página de Pedidos ................................................................................. 96
Figura 38: Continuação da Página de Pedidos ........................................................ 96
Figura 39: Página Dados de Entrega ...................................................................... 97
Figura 40: Página de Relatório do Pedido .............................................................. 98
Figura 41: Página Administração ........................................................................... 99
Figura 42: Página Validar Administrador ............................................................... 100
Figura 43: Página de Erro... ................................................................................... 100
Figura 44: Página Gerencia de Ocasiões ................................................................ 101
Figura 45: Configurando o PWS ............................................................................ 105
Figura 46: Tela de Configuração do Driver ODBC ................................................ 107
LISTA DE QUADROS

Quadro 1: Servidores Web para Cada Versão de Sistema Operacional ................... 19


Quadro 2: Opções de Backup ................................................................................. 41
Quadro 3: Opções de Restore ................................................................................. 43
Quadro 4: Autores e Características dos Métodos de Modelagem O. O. ................. 48
Quadro 5: Análise de Requisitos ............................................................................ 61
RESUMO

Tendo em vista as mudanças nas tendências e/ou exigências do mercado e das


tecnologias disponíveis, surgiu a idéia em criar uma aplicação que venha modernizar
os sistemas de teleatendimento, com o objetivo de facilitar a vida de seus clientes,
melhorando também os serviços oferecidos. Atualmente as empresas que trabalham
com a negociação de produtos e/ou serviços utilizando os sistemas de teleatendimento
enfrentam uma série de problemas que vão desde a disponibilidade de poucas linhas e
atendentes; até a escassez de recursos financeiros e as dificuldades na ampliação do
horário de atendimento. Esse trabalho propõe-se a minimizar esses problemas
disponibilizando alguns desses serviços através da Internet, fazendo com que essas
empresas possam apresentar melhor os seus produtos e/ou serviços por um período
maior, sem a necessidade de contratarem mais funcionários, fazendo assim um
marketing mais efetivo junto aos seus clientes a um custo menor. O trabalho também
ajudará no controle e organização das bases de dados dessas empresas tornando-as
unificada. A ênfase deste se dará no uso de tecnologias de programação para a Web.
Assim sendo, foram utilizados as notações e diagramas da UML para a modelagem.
As tags HTML e a linguagem de script JavaScript foram empregadas na formatação e
implementação das páginas Web. A linguagem de scripts ASP em parceria com o PWS
e o driver ODBC, foram os responsáveis pelo acesso ao banco de dados. A definição e
manipulação dos dados são gerenciadas pelo Interbase versão 6.0.

Palavras-chave: Internet; Banco de Dados; ASP;


ABSTRACT

In view of the changes in the trends and/or requirements of the market and the
available technologies, the idea in creating an application appeared that comes to
modernize the teleatendimento systems, with the objective to facilitate to the life of its
customers, also improving the offered services. Currently the companies who work
with the negotiation of products and/or services using the teleatendimento systems
face a series of problems that go since the availability of few lines and attendants; until
the scarcity of financial resources and the difficulties in the magnifying of the
attendance schedule. This work considers to minimize it these problems
disponibilizando some of these services through the Internet, making with that these
companies can better present its products and/or services for a bigger period, without
the necessity to contract employee more, thus making a together more effective
marketing to its customers to a lesser cost. The work also will help in the control and
organization of the databases of these companies becoming unified them. The
emphasis of this will be given in the use of technologies of programming for the Web.
Thus being, the notations and diagrams of the UML for the modeling had been used.
Tags HTML and the language of script Javascript had been used in the formatting and
implementation of the Web pages. The language of scripts ASP in partnership with the
PWS and driver ODBC, had been the responsible ones for the access to the data base.
The definition and manipulation of the data are managed by the Interbase version 6.0.

Key-words: Internet; Data Base; ASP;


1. INTRODUÇÃO

1.1. Apresentação

A Internet vem enfrentando diversas mudanças desde a sua invenção. Ela surgiu
com o objetivo de interligar redes militares, com o intuito de evitar que estas parassem
de funcionar durante um período de guerra, quando porventura poderia haver danos
em alguma parte da rede.
Na área científica, a Internet surgiu interligando campus de universidades,
permitindo a troca de mensagens entre acadêmicos. Atualmente, nessa área, ela é
utilizada como um canal aberto entre universidades do mundo todo, permitindo não
somente a troca de mensagens, como também a troca de outros tipos de informações.
A percepção de que a Internet vem crescendo como um canal aberto onde as
pessoas trocam informações, vem sendo o ponto emergente para que muitos
investidores direcionem seus negócios para ela. Tal fato marca o surgimento da Web
como mercado, na qual vem alcançando altas taxas de crescimento. Na opinião de
TORRES e COZER (2000, p. 1) "Nenhum outro mercado é tão promissor como a
Internet, que têm crescido a taxas maiores que 300% ao ano. Só na União Européia, o
volume de negócios do último trimestre de 1998 foi superior a US$ 5,5 bilhões. Esse
número revela mais ainda o potencial desta rede, pois somente 10% da população
européia tem acesso a ela". Cientes desse crescimento e ávidos em conquistarem esses
clientes, muitas empresas estão migrando para a Internet.
2

Por outro lado, o mercado convencional brasileiro também vem passando por
mudanças. Nesse mercado, um setor que vem se destacando em comparação aos
demais setores existentes, são os serviços pré-solicitados. Nesses setor os clientes
ligam para a empresa solicitando o serviço e/ou produto, agendam o dia, local e hora
em que o mesmo será prestado ou entregue. Esse setor abrange serviços como:
floriculturas, telemensagens, teleatendimentos (como é o caso da Telesc), entre outros.
Esses serviços são muito vantajosos tanto para os clientes que utilizam os
mesmos, quanto para as empresas que os prestam. As vantagens para os clientes estão
justamente no fato de que os mesmos podem agendar os horários e as datas em que os
serviços serão prestados, na comodidade de suas casas ou local de trabalho. Com
relação às empresas, as vantagens estão no fato delas poderem programar as suas
entregas ou visitas ao seus clientes.
O trabalho que está sendo desenvolvido é referente a um site de atendimento
através da internet para serviços pré-solicitados. No site os clientes poderão consultar
flores e vasos, ouvir mensagens e fazerem os seus pedidos, agendando o dia, local e
hora de entrega dos mesmos. A idéia de desenvolver uma aplicação Web para serviços
pré-solicitados surgiu na realização de um trabalho na graduação, onde foi
desenvolvida uma aplicação semelhante para uma pizzaria. Foi quando se observou a
necessidade de uma nova maneira de prestação de serviços. Serviços esses que
atualmente estão disponíveis por telefone ou diretamente no local.

1.2. Definição do Problema

Atualmente as pessoas não querem perder tempo. Segundo um ditado popular:


"Tempo é dinheiro", pensando nisso, muitas empresas estão buscando desenvolver
soluções que venham ao encontro dessa necessidade (os sistemas de telentregas são
bons exemplos de soluções para esse tipo de problema, nesses serviços as pessoas
telefonam para as empresas solicitando produtos e/ou serviços, agendando a data, local
e horário de entrega e/ou prestação dos mesmos).
3

O maior problema dos sistemas de teleatendimento ocorre no fato do


atendimento ser realizado pelo telefone, isso acaba gerando alguns problemas, tais
como: Negociação do produto é somente falada, o cliente não tem uma visão do
serviço que está comprando e limitação do número de usuários que podem ser
atendidos num mesmo período de tempo.

1.3. Justificativa

Atualmente os clientes estão ficando cada vez mais exigentes em relação aos
produtos e/ou serviços que estão comprando, nos sistemas de teleatendimento não
poderia ser diferente.
A prestação de serviços através de aplicações Web vem surgindo como forma
de atendimento, solucionando essa necessidade dos clientes e dessa forma está
substituindo os sistemas de teleatendimento. Pois, no atendimento através das
aplicações Web, os clientes podem de forma visual e mais interativa escolherem seus
pedidos e tirarem todas as suas dúvidas sobre estes. Nesse tipo de atendimento, os
clientes também dispõem da facilidade de agendar a data e o horário de entrega do
serviço ou produtos.
Além dos clientes, as empresas também obtém muitas vantagens, como o uso
das aplicações Web no atendimento aos clientes, substituindo os sistemas de tele
atendimento. Pois deste modo, as empresas estão reduzindo os custos e ampliando a
capacidade de atendimento. A redução dos custos ocorre pelo fato da empresa poder
atender 24 horas por dia sem necessitar de um funcionário disponível. Com relação à
ampliação da capacidade de atendimento, nos teleatendimentos com uma linha
telefônica, essas empresas só conseguiam atender um cliente de cada vez, e através das
aplicações Web com um site, essas empresas terão capacidade de atender vários
clientes ao mesmo tempo. Num site, os clientes terão a vantagem de visualizarem ou
ouvirem os produtos e/ou serviços de seus interesses e fazerem seus pedidos mais à
vontade.
4

1.4. Objetivos

1.4.1. Objetivo Geral

Este trabalho tem como objetivo o desenvolvimento de um Site de prestação de


serviços pré-solicitados. Com o propósito de demonstrar para as empresas que
oferecem essa modalidade de serviço, que o seu atendimento através de uma aplicação
Web poderá ser feito de forma mais dinâmica e lucrativa, pois os clientes poderão ter
acesso mais rápido e fácil aos seus produtos e/ou serviços.

1.4.2. Objetivos Específicos

Os objetivos específicos do trabalho são:


Fazer um estudo sobre prestação de serviços pré-solicitados.
Realizar a modelagem do projeto, através de ferramentas cases Rational
Rose;
Criar o banco de dados do projeto, utilizando o Interbase 6;
Criar as ligações do banco de dado com o projeto;
Criar as interfaces do projeto em questão, com o auxílio das tecnologias
da Internet: HTML (HyperText Markup Language), JAVASCRIPT,
JAVA, CGI (Common Gateway Interface) e ASP (Active Server Pages);
Descrever conclusões, análises e testes;

1.5. Metodologias

O trabalho se desenvolveu observando as seguintes etapas:


Foi realizado um estudo sobre os serviços pré-solicitados para o
desenvolvimento de uma análise desse ramo de negócio;
5

Foram realizadas pesquisas sobre Internet; Comércio eletrônico; Banco


de dados; onde foram escritas conclusões dos estudos realizados;
A realização de um estudo para a definição das tecnologias adequadas a
implementação do sistema;
O sistema Web foi implementado utilizando as tecnologias da Internet
que foram definidas em estudos anteriores;
Os testes foram realizados durante o desenvolvimento do projeto;
A validação do projeto foi realizada na parte final, onde foram realizados
os testes necessários;
A redação final do projeto foi sendo realizada durante todas as etapas do
projeto;
Foram utilizados para a realização do projeto alguns recursos próprios e
outros fornecidos por professores;
2. TCP/IP E INTERNET

Esse capítulo visa abordar os aspectos mais significativos da evolução histórica


do TCP/IP e da Internet, bem como seus principais conceitos. Além disso, serão
abordados também o funcionamento de alguns serviços da Internet, que são de grande
importância para esse trabalho.

2.1. Evolução Histórica do TCP/IP e da Internet

A Internet vem sofrendo diversas mudanças ao longo dos anos, os primeiros


passos para a sua invenção ocorreram no final dos anos 50, quando o governo
americano criou a ARPA (Advanced Research Project Agency), com a missão de
desenvolver tecnologias de comunicação com fins militares. Posteriormente, no início
dos anos 60, a ARPA repassou a Rand Corporation a missão de criar uma tecnologia
que fosse capaz de assegurar as comunicações governamentais na eventualidade de um
ataque militar (MAZZOLA, 1999, p. 1.1).
Dois anos depois a Rand Corporation lançou um artigo abordando as
características de uma rede de comunicação que tinha como base a comutação de
pacotes, segundo este artigo:

"... o objetivo dessa rede era formar uma arquitetura de rede sólida e robusta que pudesse
sobreviver a uma perda substancial de equipamentos e ainda operar com os computadores e
enlaces de comunicação restantes. Para alcançar este objetivo de comunicação deveria
suportar diversos tipos de equipamentos distintos, ser dividido em diversos níveis de
protocolos distintos para permitir a evolução independente de cada um deles e ser baseado
em transferência de pacotes de informação” (PUC-RIO/CCE).
7
Para colocar em prática a implementação da proposta da ARPA foram
convidadas quatro universidades, as quais foram interconectadas através de um
equipamento denominado IMP (Interface Message Processor), utilizando um
protocolo de comunicação denominado NCP (Network Control Protocol), criando-se
assim a rede ARPANET, sendo este o primeiro nome da Internet (MAZZOLA, 1999,
p. 1.2).
A ARPANET evoluiu rapidamente, e no decorrer dos tempos, vem obtendo
mudanças e aprimorando cada vez mais os equipamentos e serviços. Com relação a
estes, podemos citar a criação do correio eletrônico (protocolos SMTP, POP), a
especificação do protocolo Telnet (emulação de terminal remoto) e a especificação e
publicação do FTP (File Transfer Protocol). A partir da criação destes serviços,
tornou-se possível acessar qualquer servidor através de um terminal, trocar mensagens
e transferir arquivos, ampliando-se assim os serviços oferecidos pela rede.
A ARPANET obteve tanto sucesso, que em 1973 ultrapassou as barreiras do
território americano, passando a interligar outros países. Para se comprovar o sucesso e
o funcionamento desta rede foi realizado uma demonstração conforme cita
MAZZOLA (1999, p. 1.3): "...uma mensagem de rádio móvel foi enviada de São
Francisco para um satélite da ARPANET foi retransmitida para Londres e, após ter
percorrido 150.000 quilômetros, foi recebida na UCLA que ficava a 800 quilômetros
de onde foi enviada".
Com o passar dos anos, a ARPANET foi dividida na própria ARPANET e na
MILNET, separando a porção acadêmica e militar. Sendo que se utilizou a MILNET
como rede militar e a ARPANET, a partir de então, seria utilizada para fins
acadêmicos, adotando o Unix como sistema operacional prioritário, para o suporte de
seus projetos de pesquisa, escolhendo a Universidade da Califórnia - Berkeley como
centro de desenvolvimento.
Em suma, durante toda a década de 70 e início da década de 80, a ARPANET
era baseada em IMPs (Interface Message Processors), rodando diversos protocolos,
sendo o principal o NCP (Network Control Protocol). O protocolo TCP/IP
(Transmission Control Protocol/Internet Protocol) ainda estava sendo projetado e a
8
Internet era formada por máquinas de grande porte e microcomputadores ligados em
IMPs. O roteamento fora dos IMPs não existia, impedindo a conexão de máquinas em
redes locais que surgiam, ou seja, para se ligar a ARPANET era necessária a ligação
direta a um IMP. Até que em 1974, surge a rede Ethernet, definida pela Xerox, DEC e
Intel para interconectar computadores separados por pequenas distâncias suportando
altas taxas de transmissão. A Ethernet foi rapidamente dando provas de sua eficiência
e tornou-se sinônimo de rede local.
Com a necessidade do mercado de uma comunicação mais rápida entre redes de
longas distâncias e de um número maior de máquinas interconectadas, a ARPANET
foi se aperfeiçoando, implantando novos subsídios, para tentar melhorar a qualidade de
interligação das redes e com isso aumentar a sua velocidade de transmissão. Porém,
isso só começou a ocorrer com a implantação do protocolo TCP/IP na ARPANET. A
implantação deste protocolo vem permitindo um crescimento da rede ao longo dos
anos, pois esse esquema de endereçamento é capaz de suportar até quatro bilhões de
máquinas.
Mediante novas evoluções que ocorreram, a ARPANET dividiu-se novamente
em duas redes: a MILNET para aplicações militares e a NSFNET para fins de
pesquisas. A partir de então a ARPANET foi considerada extinta, nascendo então a
Internet com 1500 subredes e 250.000 hosts.
O acesso a Internet no Brasil, surgiu em 1989 com a interligação de instituições
acadêmicas como a Fapesp (Fundação de Amparo a Pesquisa do Estado de São Paulo),
USP (Universidade de São Paulo), Unicamp (Universidade de Campinas), a PUC-RIO
(Pontifícia Universidade Católica do Rio de Janeiro), a UFRJ (Universidade Federal
do Rio de Janeiro) e outras. Com essa interligação formaram-se dois backbones
regionais, a RedeRio e a ANSP (An Academic Network At São Paulo), as quais
interligaram somente as instituições desses dois Estados. Logo em seguida foi criada a
RNP (Rede Nacional de Pesquisa) com o objetivo de formar um backbone nacional de
acesso à Internet e que estimulou a formação de redes regionais como a Rede Minas,
Rede Tchê e outras.
9
Buscando o aperfeiçoamento da comunicação, visando facilitar o entendimento
das informações transmitidas para os usuários de Internet, criou-se o protocolo HTTP
(HyperText Transfer Protocol) e o Browser Mosaic, dando início ao WWW (World
Wide Web). O WWW foi o grande responsável pelo crescimento exponencial da
Internet, pois permitiu o acesso a informações com conteúdo rico em gráficos e
imagens e de forma estruturada. O WWW foi também o grande motivador do uso
comercial da Internet, permitindo às empresas disponibilizar informações e vender
produtos pela rede.
Com a privatização da NSFNET em 1995, o backbone passou a ser distribuído,
formado por múltiplas redes de prestadoras de serviços de telecomunicações como a
AT&T, MCI, Sprint e outros. Nesse mesmo ano foi permitido o tráfego de
informações comerciais na Internet. No Brasil esse tipo de tráfego ocorreu através da
Embratel, a qual montava e operava o backbone comercial.
Atualmente a Internet não é mais composta por um único backbone central, mas
por um conjunto de grandes provedores de acesso; e no Brasil, hoje o Backbone da
Internet é composto de diversos backbones nacionais interligados entre si, como a
RNP, a Embratel e de outras empresas como a IBM, Unisys, GlobalOne e outros
provedores.

2.2. Conceitos de Internet e TCP/IP

Atualmente, nota-se que a cada dia, mais e mais pessoas estão se familiarizando
com os serviços da Internet. Seja para comprar CDs, mandar e-mail, ou para realizar
uma simples pesquisa escolar. Para grande parte dessas pessoas o ato de navegar na
Internet ocorre naturalmente, de maneira intuitiva. Apesar disso, muitos desses
usuários ainda não sabem como a Internet funciona através do navegador.
Conforme abordado na seção anterior, a partir da década de 80 até os dias atuais
a Internet passou a utilizar o protocolo TCP/IP, como base para a estrutura de
comunicação e seus serviços de rede. Esse protocolo determina como a comunicação
deve ser estabelecida entre os computadores. O uso desse protocolo vem dando certo
10
durante todos esses anos, porque o mesmo possui como característica principal o
suporte direto a interconexão entre redes heterogêneas. A arquitetura TCP/IP é
independente da infra-estrutura de rede física ou lógica empregada, ou seja, qualquer
tecnologia de rede (tais como: Ethernet, Token Ring, ATM e várias outras) pode ser
empregada como meio de comunicação dos protocolos TCP/IP.

2.3. Serviços WWW e E-mail

O protocolo TCP/IP suporta diversos serviços, entre os mais conhecidos estão o


correio eletrônico (protocolos SMTP, POP), a transferência de arquivos (FTP), o
compartilhamento de terminais (Telnet), o acesso a informações hipermídia (HTTP) e
o ambiente WWW (World Wide Web). Nesse trabalho será utilizado alguns desses
serviços, tais como: O ambiente WWW e o correio eletrônico (SMTP e POP).

2.3.1. O Ambiente WWW (World Wide Web)

O ambiente WWW (World Wide Web) é a designação do conjunto de


informações públicas baseada em hipermídia com imagens, sons, textos, etc,
disponibilizadas na Internet por meio de protocolo HTTP. O protocolo HTTP
(HyperText Transfer Protocol) é um protocolo utilizado para transferência de
hipertextos na Internet.
No ambiente WWW o acesso as informações é feito de tal modo que o usuário
não precisa saber de onde a informação está sendo buscada, podendo esta, ser acessada
de qualquer ponto do mundo onde exista um computador que possa estar conectado a
Internet.
O WWW é um ambiente onde o usuário obtém acesso as informações
disponíveis na Internet, geralmente essas informações são apresentadas de forma
textual, mas como citado anteriormente, pode apresentar também imagens, sons,
coleção de arquivos e vídeos.
11
O internauta, como é chamado o usuário da Internet, geralmente utiliza a rede
para pesquisar os diversos tipos de informações existentes, buscando algo de seu
interesse. Criando suas páginas esse usuário passará a ser um fornecedor de
informações. Especialistas de diversas áreas ou profissionais liberais fazem uso da
Internet como marketing pessoal, como um meio de facilitar o seu trabalho ou a
comunicação com seus clientes, um exemplo disso, pode ser acompanhado abaixo:

"Um professor, por exemplo, pode utilizar o ambiente WWW para publicar resumos ou
revisões de suas aulas, distribuir materiais didáticos ou mesmo fazer as avaliações, sendo
que o acesso a estes recursos poderão ser feitos pelo estudante seja a partir de um
microcomputador da própria universidade ou de sua casa, independente da cidade onde
mora. Em suas páginas, é possível incluir, além de textos, arquivos gráficos, animações,
sons, voz, vídeo, o que possibilita a criação de verdadeiros documentos multimídias,
tornando mais agradável e eficiente o ensino de um dado assunto". (MAZZOLA, 1999, p.
4.21).
Desta forma, o profissional pode utilizar a rede Internet como uma ferramenta
para auxiliá-lo no desempenho de seu trabalho.
Apesar da Internet ser composta de documentos hipertextos, a leitura destes não
ocorre necessariamente do mesmo modo que a leitura de um texto em um jornal ou
revista, ou seja, de forma linear, pois o hipertexto organiza a informação como uma
interconexão de textos. Isso ocorre porque os documentos hipertextos são constituídos
de palavras-chaves, geralmente destacadas (sublinhadas e/ou escritas numa cor
diferenciada) do restante do texto, que representam um ponto de acesso a informações
mais detalhadas relacionadas àquelas palavras. Deste modo, a leitura do hipertexto
ocorre de forma aleatória, dependendo apenas do interesse do usuário da Internet e da
forma como foi estruturado o documento.
As palavras de ligação que facilitam a navegação pelo site, possibilitando o
acesso a recursos da página ou o acesso a outras páginas são chamadas de links. O link
constitui-se num ponteiro para um documento, um gráfico ou outro recurso da
Internet. Geralmente são utilizadas palavras-chaves como links, mas apesar disso
também podem serem utilizados figuras, gifs animados (desenhos animados), gráficos
mapeados, entre outros.
12

2.3.2. Serviço de E-mail ?

O e-mail é um dos meios de comunicação mais utilizados atualmente. Muitas


pessoas estão deixando de usar os meios convencionais de comunicação, tais como
cartas, telefone, fax e passando a utilizar o e-mail em suas comunicações tanto
pessoais quanto profissionais (WHITE, 1997, p. 237).
O e-mail comparado com os meios convencionais de comunicação apresenta
várias vantagens, dentre elas, pode-se citar:
Agilidade na transmissão da mensagem: enquanto uma carta leva de dois
a três dias para chegar até o destinatário o e-mail pode levar apenas
algumas horas;
Custo reduzido da mensagem: se uma pessoa que mora no Brasil e tem
parentes morando no exterior, por exemplo, se fizerem uso do telefone
para estabelecerem contato, certamente suas contas de telefone terão um
custo altíssimo. Na comunicação via e-mail, no entanto, esse custo é
reduzido. Se o meio de interligação for via rádio, por exemplo, não
existirá custo algum com telefone, podendo trocar mensagens a qualquer
hora;
Envio de informações multimídia: na hipótese de uma gravadora da
cidade de São Paulo precisar urgente de uma amostra de som de um
músico Gaúcho de Porto Alegre para fechar o contrato de gravação de um
CD, não será necessário que o músico se desloque de Porto Alegre até
São Paulo. Basta que envie o som solicitado no formato MP3 (MPEG-I
Audio Layer 3) anexado a uma mensagem de e-mail que certamente será
mais rápido do que o envio pelo correio, aliado a um custo menor. Esse
processo pode ser utilizado também para o envio de fotos, documentos de
diversos tipos, assim como para vídeos;
Apesar de muitos usuários de Internet acharem que o e-mail tornou-se
popular com o advento dessa rede, na realidade sua popularidade foi
13
atingida em redes locais (WHITE, 1997, p. 237). Essa popularidade
ocorreu devido à praticidade da utilização de e-mail em campus, empresas
ou repartições públicas. Em LAN (Local Area Network) o e-mail permite a
comunicação formal, bem como a troca de documentos entre indivíduos de
setores, salas ou prédios diferentes, evitando o deslocamento dos mesmos,
além de ajudar a agilizar a realização de algumas tarefas.
Para o envio e recebimento de e-mail da Internet geralmente utiliza-se dois
protocolos padrões, conforme menciona WHITE (1997, p. 237):

“O Simple mail transfer protocol, ou SMTP, para enviar mensagens e o post office
protocol, ou POP, para receber mensagens. Como estes padrões são universais, o software
de envio e recebimento de e-mail, bem como os servidores que tratam as mensagens,
podem ser executados em uma diversidade de computadores e sistemas operacionais
normalmente incompatíveis”.
Espera-se que futuramente, tenha-se e-mail onde agentes inteligentes, sejam
capazes de examinar a caixa de e-mail antes do usuário da Internet, selecionando
somente as mensagens que serão de interesse deste, baseado em seu perfil e jogando
na lixeira os correios inúteis (WHITE, 1997, p. 237).

2.3.2.1. O Funcionamento do E-Mail

Através de um software cliente de e-mail como a página do Hotmail


(www.hotmail.com) ou do Bol (www.bol.com.br), o usuário da Internet cria suas
mensagens inclusive anexando recursos multimídia ou documentos do Office se for o
caso. Os documentos ou recursos multimídia se forem anexados ao e-mail serão
codificados usando um algoritmo padrão, como o MINE (Multipurpose Internet Mail
Extension) (WHITE, 1997, p. 238), sendo transformados assim em textos ASCII
(American Standard Code for Information Interchange) que é um formato padrão
interpretado por todos os computadores como texto não formatado.
Logo em seguida, o software cliente busca o computador servidor de acesso a
Internet por meio de um modem ou de uma ligação a rede. O programa cliente
conecta-se a um programa servidor, denominado SMTP (Simples mail transfer
protocol), sendo o mesmo um servidor de aplicação (STARLIN e CARVALHO, 1998,
14
p. 48), após entrarem em contato com o software cliente e servidor a comunicação
entre ele ocorre geralmente conforme menciona WHITE (1997, p. 237), “O servidor
reconhece que foi contactado, e o cliente indica ao servidor que possui uma mensagem
para ser enviada a um certo endereço. O SMTP responde com uma mensagem dizendo
“Envie agora” ou “Ocupado; envie mais tarde”. Essa comunicação inicial entre
programas clientes e servidor ocorre para estabelecer a conexão entre ambos, isso
ocorre porque o SMTP é um serviço confirmado orientado à conexão.
Após o estabelecimento da conexão, o programa cliente envia a mensagem para
o SMTP e solicita uma confirmação. O SMTP confirma o recebimento da mensagem.
O servidor SMTP, por sua vez, busca no programa chamado DNS (Domain
Name System – Sistema de Nome de Domínio) qual a rota que a mensagem deve
seguir para chegar ao destino. Para estabelecer a rota da mensagem o DNS analisa o
nome de domínio – a parte do endereço após o caracter @, localizando assim, o e-mail
do destinatário. Identificado o e-mail destino o DNS informa ao SMTP a melhor rota
a ser seguida pela mensagem. Nessa etapa a mensagem é enviada pelo SMTP para a
Internet, de onde passa a ser roteada através de roteadores.
Depois de muito trafegar na Internet, enfim, a mensagem é enviada para outro
servidor chamado de servidor POP (Post Office Protocol). O servidor POP é o local
onde as mensagens ficam armazenadas até serem requisitadas (WHITE, 1997, p. 238).
Quando o usuário de Internet deseja visualizar suas mensagens estabelece
conexão com uma página de e-mail como as citadas inicialmente, através de um
programa cliente, entra no servidor POP utilizando-se de um nome de usuário e de
uma senha, os quais solicitam as mensagens ao servidor.
O servidor POP recupera as mensagens armazenadas e transmite ao programa
cliente, permitindo a leitura destas pelo usuário da Internet.
15

2.4. Conclusão

Neste capítulo foi apresentado sobre a evolução histórica e os principais


conceitos referentes a Internet e ao TCP/IP. Além disso, foi abordado também sobre o
Ambiente WWW e o serviço de e-mail. Certamente as informações que constam nesse
capítulo não encerram esses assuntos, pois alguns serviços da Internet, tais com o FTP
e o Telnet não foram mencionados.
Independente disto, o que foi apresentado já permite demonstrar o porque do
sucesso da Internet como meio alternativo de comunicação e ambiente para a
realização de negócios.
3. APLICAÇÕES WEB

As aplicações Web são o conjunto de informações textos e/ou multimídia


disponíveis na Internet. Todas as vezes que um usuário da Web consulta seu saldo
bancário ou envia um e-mail através da Internet, está fazendo uso de aplicações Web.
Para que o usuário da Internet possa acessar qualquer documento Web, alguns
requisitos são necessários, tais como:
Uma máquina que possa ser conectada a Internet;
O protocolo TCP/IP, como protocolo de comunicação;
A utilização da arquitetura Cliente/Servidor;
Documentos desenvolvidos utilizando ferramentas da Web.
Para uma melhor compreensão desses itens, será comentado nesse capítulo
sobre cada um deles.

3.1. A Importância do TCP/IP na Comunicação

Independente da forma de interligação com a Internet é indispensável que as


máquinas interligadas a rede possuam o protocolo TCP/IP instalado, pois esse
protocolo é o responsável em estabelecer a comunicação, conforme cita STARLIN
(1998, p. 1):

“TCP/IP (Transmission Control Protocol/Internet Protocol – Protocolo de Controle de


Transmissão/Protocolo da Internet) se refere ao conjunto de protocolos utilizados na
Internet. Ele inclui uma série de padrões que especificam como os computadores vão se
comunicar e criar convenções para interconectar redes e para o roteamento através dessas
17
conexões”.

O protocolo TCP/IP é o responsável por garantir que uma mensagem enviada


chegará ao seu destino.
Segundo MAZZOLA (1998, p. 3.1-3.2), o protocolo TCP atua na camada de
transporte de dados fim-a-fim, ou seja, considerando apenas a origem e o destino da
comunicação sem se preocupar com os elementos intermediários. São
responsabilidades do protocolo TCP o controle de fluxo, o controle de erros, a
sequenciação e a multiplexação de mensagens.
O protocolo IP tem como função mapear a rede, criando endereços lógicos
compostos de 4 octetos chamados de Endereços IP (exemplo: 200.168.1.0),
relacionando-os com endereços físicos, chamados de Mac Address (exemplo:
03:02:ff:34:12:01). Outra função importante do protocolo IP é o controle de quadro de
roteamento.

3.2. Arquitetura Cliente/Servidor Web

A Internet é baseada no conceito da arquitetura Cliente/Servidor, com diversos


servidores espalhados pelo mundo. Deste modo, a Internet se constitui num banco de
dados distribuído, composto de documentos Web. Além disso, a Internet é um
ambiente multiplataforma. A arquitetura Cliente/Servidor surgiu como um meio de
facilitar o acesso às informações existentes na Internet.
O funcionamento da arquitetura Cliente/Servidor na Internet ocorre da seguinte
forma: o usuário da Internet faz o pedido de uma determinada página ou informação,
através de programas clientes, esse pedido vai para um servidor onde é processado,
devolvendo uma resposta para o cliente, que será a existência ou não dessa página ou
informação solicitada.
Para MAZZOLA (1999, p. 4.21), o funcionamento da arquitetura
Cliente/Servidor dá-se do seguinte modo:
18
“... um programa “Cliente” WWW (browser) roda em seu computador. Ele apresenta
documentos transferidos de outro computador, caracterizado aqui como “servidor”. O
usuário pode requisitar uma busca, seguir uma ligação por um link de hipertexto ou
preencher formulários. A resposta do servidor (que com freqüência é uma máquina
completamente diferente em alguma outra parte do mundo) é um documento que pode ser
um texto plano, um hipertexto, ou que incorpore diversas mídias”.

3.2.1. Sistema Cliente Web

Os sistemas Clientes Web são aplicativos que auxiliam os usuários da Internet


em suas navegações, sendo também utilizados para apresentarem as respostas dos
programas servidores.
Os programas Clientes são chamados de browser ou navegadores, eles
apresentam as informações para o cliente em páginas no formato hipermídia (texto e
multimídia), porém, para que isso ocorra, essas páginas deverão ser desenvolvidas
anteriormente utilizando-se de linguagens, tais como: HTML, JavaScript, Java.
Existem vários tipos de navegadores no mercado, mas atualmente os mais
populares são o Mosaic, o Navigator, criado pela Netscape e o Internet Explore
desenvolvido pela Microsoft.

3.2.2. Sistema Servidor Web

Os sistemas servidores Web são os responsáveis por realizarem o


processamento das solicitações dos clientes e enviarem uma resposta aos mesmos,
contendo dado ou um código de erro, caso o serviço não possa ser executado.
MAZZOLA (1999, p. 4.23) aborda um pouco mais sobre o assunto, bem como
comenta mais algumas funções do servidor Web:

“Um servidor WWW é um programa que fica à espera de requisições de clientes (browser)
por documentos HTML ou informações de outros tipos (arquivos de imagens, sons, etc).
Também trata as requisições de realização de serviços executados pelo servidor, na
máquina do servidor) através de scripts, bem como mantém estatísticas sobre acessos. O
protocolo utilizado é o HTTP e o servidor WWW tem domínio sobre a base de
informações mantidas naquele site, permitindo o controle de acesso para documentos, com
autorização de senhas e outras restrições. Outros servidores implementam transações
seguras, com emprego de recursos de criptografia”.
19
Os principais Servidores Web disponíveis para os sistemas operacionais são
apresentados no Quadro 1 a seguir:

QUADRO 1: Servidores Web Para Cada Versão de Sistema Operacional


Sistema Operacional Aplicativo Servidor Disponível
Linux Apache
Novell NetWare Novell Web Server/Fastrack
Windows NT Microsoft Internet Information Server
Windows 95 Aladim
Windows 98 PWS – Personal Web Server

3.3. Linguagens Web

As linguagens da Web são empregadas para viabilizar a utilização da arquitetura


Cliente/Servidor. Portanto para que os clientes possam visualizar as páginas Web que
ficam armazenadas nos servidores Web, essas deverão ser criadas utilizando
linguagens como: HTML, Java e/ou JavaScript.
As linguagens como CGI e ASP atuam mais como uma ponte entre a aplicação
cliente e a aplicação servidora.
Neste tópico, serão citados alguns pontos importantes referentes a essas
linguagens, dentre esses: conceitos, principais aplicações e ferramentas existentes para
trabalhar com essas linguagens.

3.3.1. Linguagem HTML

A linguagem HTML (HyperText Markup Language), foi desenvolvida segundo


MAZZOLA (1999, p. 6.8) “... no final dos anos 80 na Suíça, por Tim-Berners Lee,
com o objetivo de permitir a exibição de informações”.
A linguagem HTML é utilizada para o desenvolvimento de documentos Web,
chamados mais popularmente de páginas Web. Essa linguagem é composta de
comandos marcadores, também chamados de tags. As tags tem como função formatar
os documentos Web em hipertextos. A linguagem HTML é constituída de três
conjuntos de tags com funções distintas. O primeiro é utilizado na formatação do texto
20
e de imagens, já o segundo, é utilizado na criação de links e o terceiro na formatação
de formulários.
Para MAZZOLA (1999, p. 6.8) os recursos mais importantes na linguagem
HTML são os links, pois estes, “ ... estabelecem um vínculo com uma nova página ou
com uma seção da mesma ou de outra página, dando ao documento construído, a
característica de hipertexto”.
As páginas Web podem ser criadas através de editores de textos comuns, como
o “Bloco de Notas”, ou usando editores específicos para essa tarefa, tais como: O
Dreamweaver da Macromedia, ou o FrontPage da Microsoft, além de outros. Os
editores específicos funcionam como ferramentas de design do site onde o
desenvolvedor modela-o e o editor gera todo o código na linguagem HTML.

3.3.2. Linguagem JavaScript

Sabe-se que é predominante o uso da linguagem HTML em páginas Web,


todavia, documentos que só fazem uso desta linguagem são razoavelmente estáticos,
não permitindo muita interação com os usuários de Internet.
Um dos fatores que levou a Netscape a desenvolver a linguagem JavaScript
com o nome inicialmente de LiveScript e implantá-la no navegador Navigator 2.0 em
1995, foi a necessidade de tornar as páginas mais interativas para os usuários de
Internet. A interatividade é certamente a principal característica que leva os
webdesigner a utilizarem JavaScript em suas páginas, mas para ALBUQUERQUE
(2001, p. 91), outro fator importante que levou ao desenvolvimento da linguagem
JavaScript foi:

“Os scripts escritos com a linguagem JavaScript podem ser executados por navegadores
(client-side script) ou por servidores (server-side scripts). Os scripts executados por
navegadores são inseridos em documentos HTML e podem ser executados no momento em
que o navegador carrega o documento HTML ou toda a vez que um determinado evento
ocorre; por exemplo, na seleção de um botão ou na movimentação do mouse”.
Através da citação nota-se que a linguagem JavaScript é orientada a objeto e a
eventos, desta forma, para utilizá-la o webdesigner já deve ter conhecimento do
paradigma orientado a objetos.
21
Com a linguagem JavaScript é possível implementar funções que permitem
desde a apresentação de caixas de mensagens, detecção do tipo de browser, inserção
da hora, além de outras funções.
A utilização da linguagem JavaScript ocorre de forma bem simples, ou seja,
basta colocar o código JavaScript entre o código HTML em tags específicos conforme
o exemplo a seguir:
<HTML>
<HEAD>
<TITLE>EXEMPLO JAVASCRIPT</TITLE>
<SCRIPT LANGUAGE= “JAVASCRIPT”> {
COMANDOS SCRIPTS;
}
</SCRIPT>
</HEAD>
<BODY>
COMANDOS HTML
</BODY>
</HTML>

Como foi citado o código JavaScript vai incluso entre o código HTML,
dispensando a criação de arquivo separado para a implementação de seu código.

3.3.3. Linguagem JAVA

A linguagem Java surgiu no início da década de 90, ela foi desenvolvida pela
SUN Microsystems, segundo STARLIN e CARVALHO (1998, p. 131) para ser: “...
uma linguagem leve, com códigos pequenos para controlar produtos eletrônicos de
consumo”. O intuito de utilizar a linguagem Java para programas controladores de
produtos eletrônicos, era com o objetivo de desenvolver um projeto da casa inteligente.
Já a utilização da linguagem Java para a Internet, só veio a ser pensada em
1994. Segundo STARLIN e CARVALHO (1998, p. 131), os fatores que levaram a
essa cogitação foram: “... pela independência de plataforma e sistemas operacionais e
concebida para redes”.
Como foi abordado no tópico 3.3.1., com a criação da linguagem HTML na
década de 80, tornou-se possível a partir de então, a formatação de textos, formulários,
22
multimídias (como sons e vídeos) e links de documentos Web. Porém até a década de
90 as páginas Web eram muito estáticas. No ano de 1995, como foi citado no tópico
3.3.2., surgiu a linguagem JavaScript, proporcionando mais interatividade as páginas,
através da sua programação baseada em eventos. Além disso, a linguagem JavaScript
serviu também para diminuir o tempo de carregamento das páginas, uma vez que parte
do código que antes rodava no servidor, passou a ser executado nos programas
clientes, sendo implementado dentro do código HTML.
A utilização da linguagem Java na Internet, vem surgindo como uma solução
para o processamento dos programas pesados, que as outras linguagens não
conseguem processar, conforme menciona ALBUQUERQUE (1998, p. 149): “Quando
os documentos transferidos para as máquinas dos usuários contêm apenas instruções
HTML e scripts, a maior parte do processamento continua centralizada nos servidores
responsáveis pelo tratamento dos dados. A capacidade de processamento das máquinas
com os navegadores não são totalmente exploradas”. Uma forma de explorar a
capacidade de processamento dos navegadores, dá-se através de programas
complexos, no entanto, desde que foram criadas as linguagens de scripts, não eram
capazes de desempenharem essa função, devido a algumas limitações, as quais ainda
existentes.
Segundo ALBUQUERQUE (1998, p. 149), foi para solucionar essas limitações
que a linguagem Java foi aplicada para Web, onde segundo ele o processamento dos
programas em Java ocorre da seguinte forma: “Os programas complexos podem ser
escritos em Java, armazenados em servidores, transferidos dos servidores para as
máquinas com os navegadores e nelas executados”.
STARLIN e CARVALHO (1998, p. 131), evidenciam as características da
linguagem Java, bem como de que forma ocorre a sua utilização na Web:

“O Java é, portanto, uma linguagem orientada por objeto, com alto grau de portabilidade,
com recursos de multitarefa e bem rápida. Programar em Java é basicamente seguir uma
linha de criação de objetos para usá-los dentro de uma estrutura maior e invocá-los dentro
de uma página HTML. Estes objetos são feitos em forma de applets, programas escritos
que podem ser rodados por um browser a fim de executar alguma operação”.
23
Já MAZZOLA (1999, p. 6.8) aborda de forma mais detalhada como são
desenvolvidos os programas em Java, bem como ocorrem suas visualizações pelo
navegador:

“Sua execução é baseada na geração de código intermediário, denominado “bytecode”, que


é incorporado a páginas Web, transferindo via rede no momento do carregamento da
página. Uma vez transferido para a máquina do usuário, este código é instalado no
computador do usuário. Para usuários da Web, a máquina virtual está embutida nos
navegadores, como Netscape Communicator e Internet Explorer. Desta forma, as
aplicações Java escritas pelo autor de uma página Web serão executadas, sem a necessidade
de adaptações, na maior parte das plataformas de hardware existentes na Web”.
Por mais que muitos usuários presumam que Java seja semelhante a JavaScript,
isso é um grande equívoco. A referência de SAUCIER (2000, p. 113), destaca muito
bem as diferenças entre as duas linguagens, revelando que o equívoco ocorre apenas
na analogia dos nomes destas.

“Muitos usuários pensam que Java está relacionado com JavaScript. Entretanto, as duas
linguagens de programação não estão relacionadas, salvo pela similaridade dos nomes e da
sintaxe do JavaScript ser vagamente baseada no Java. JavaScript é uma simples linguagem
de scripting que você pode utilizar para controlar navegadores de páginas da Web e seu
conteúdo. Java é uma linguagem de programação mais complexa utilizada para
desenvolver aplicações avançadas para navegadores de fora ou applets para visualizar
apenas com navegadores. O Java permite que você realize tarefas mais complexas, tais
como uso de rede, mas não controla navegadores como o JavaScript. Entretanto, você pode
utilizar o JavaScript para controlar os applets Java nas páginas da Web para aplicações
mais avançadas”.

3.3.4. Script CGI

O CGI (Common Gateway Interface), segundo SAUCIE (2000, p. 214), “…não


é uma liguangem de programação, mas um conjunto de convenções padronizadas que
definem como o servidor se comunica com a aplicação da Web, como um formulário.
Um gateway é simplesmente um programa que gerencia pedidos de informação e
mostra o documento solicitado”. Desta forma os scripts CGI formam o elo de ligação
entre as aplicações cliente e as aplicações servidoras da arquitetura cliente/servidor.
Os programas CGI, podem ser desenvolvidos através de diversas linguagens,
tais como: C, C++, Visual Basic, Java, entre outras. No entanto, atualmente a
linguagem que vem sendo mais utilizada no desenvolvimento de scripts
24
CGI é a linguagem PERL. Conforme menciona SAUCIER (2000, p. 214) “PERL
(Pratical Extraction and Report Language) é a linguagem mais popular devido à
abundância de códigos preexistentes disponíveis”.
Os programas CGI são armazenados no servidor num diretório especial
designado pelo administrador da rede.
SAUCIE (2000, p. 232) menciona os principais benefícios de CGI, bem como
as desvantagens existentes nesses scripts:

“O CGI oferece diversos benefícios, incluindo a não necessidade de um plug-in especial


para visualizar, rapidez de download, visualização compatível com várias plataformas e
navegador, além da versatilidade. Algumas desvantagens incluem a necessidade de
definições extra para os Servidores Unix, a provável necessidade de conhecimento de
programação, dificuldades em resolver erros com scripts CGI, possíveis riscos de
segurança, alguns provedores não permitem upload dos scripts CGI em seus servidores e a
sobrecarga que podem causar em servidores”.
Os scripts CGI são utilizados muitas vezes para tornar as páginas Web
interativas e dinâmicas em aplicações como: páginas de respostas de formulários,
busca de informações no banco de dados, criação de contadores de acessos, entre
outras aplicações.

3.3.5. Active Server Pages - ASP

ASP (Active Server Pages - Páginas de Servidor Ativas) são linguagens scripts
no servidor utilizados para desenvolver páginas que possuem conteúdo dinâmico,
interativo e de alto desempenho. Tais páginas consistem de arquivos com a extensão
“.asp” que contêm combinações de códigos de programas que são processados no
servidor (Server-Side Script) e tags HTML.
ASP deve ser considerado mais como um ambiente de processamento no
servidor do que uma linguagem de programação (LIRA, p. 14). Como linguagem de
programação no desenvolvimento de scripts ASP, podem ser usadas as seguintes
linguagens: JScript (o JavaScript da Microsoft), PerlScript, Phynton e VBScript, sendo
que este último geralmente é mais usual. Como os scripts ASP podem ser combinados
com tags de HTML, e já que esses tags podem ser desenvolvidos utilizando-se do
25
"Bloco de Notas", os WebDesigners também podem fazer uso desse editor de textos
para implementarem suas páginas ASP, bastando apenas que os scripts implementados
sejam salvos com a extensão “.asp”, conforme citado anteriormente.
A relação de ASP com os programas servidores, segundo LIRA (p. 14) ocorre
deste modo: "ASP é um ambiente gratuito quando se usa servidor Web Microsoft IIS
(Internet Information Server) para Windows NT e PWS (Personal Web Server) para
Windows 95 ou 98". ASP exige que a aplicação servidora rode em um sistema
operacional da Microsoft. Na aplicação cliente, por outro lado, ASP permite total
independência com relação ao browser que será utilizado. A maior exigência por parte
do servidor ocorre por ser este o responsável pelo trabalho na Arquitetura
Cliente/Servidor de uma aplicação utilizando ASP, ou seja, todo o processamento
ocorre no servidor, restando para as aplicações clientes (browsers) simplesmente a
apresentação das respostas geradas pelo servidor em códigos HTML.
Da mesma forma que nos scripts CGI, os scripts ASP, foram desenvolvidos
para auxiliar as aplicações clientes em consultas a banco de dados. No entanto ASP se
torna mais vantajoso que CGI, pelo fato de permitir uma implementação facilitada de
suas páginas em comparação com as aplicações CGIs.
As páginas ASP podem ser desenvolvidas por qualquer banco de dados
suportado pelo driver ODBC, tais como: Paradox, InterBase, MySQL, ORACLE entre
outros.
Um dos fatores importantes relacionados a ASP diz respeito a segurança. Como
as páginas ASP ficam armazenadas nos servidores e estes são gerenciados por um
sistema operacional seguro como o Windows 98 ou NT, torna-se difícil violar os
scripts armazenados (LIRA, p. 14). Como estes na aplicação servidora estão seguros
contra violação pelo sistema operacional, a aplicação cliente não precisa de segurança
alguma, pois só receberá como retorno código HTML que pode ser violado e copiado.
Como foi abordado durante todo este tópico, ASP é um poderoso ambiente de
interligação entre as aplicações clientes e servidoras da Arquitetura Cliente/Servidor,
muito utilizada para realizar o envio de dados dos usuários no preenchimento de
formulários, bem como enviar páginas de confirmação dos dados. Certamente ASP
26
será uma linguagem muito útil na implementação do trabalho proposto.

3.4. Conclusão

Nesse capítulo foram apresentados os principais conceitos referentes ao


protocolo TCP/IP, a arquitetura Cliente/Servidor Web e as ferramentas da Internet.
Os assuntos abordados nesse capítulo demonstraram que o conjunto de recursos
que envolvem esses conceitos é fundamental para o desenvolvimento e acesso as
aplicações Web.
Tendo consciência de que muitos dos conceitos mencionados hoje poderão estar
obsoletos no futuro, principalmente com relação as linguagens citadas, pois sabe-se
que novas tecnologias poderão substituir as atuais. No entanto, apesar disso os
conhecimentos adquiridos foram muito úteis para dar seqüência no desenvolvimento
do trabalho proposto.
4. BANCO DE DADOS

Banco de dados é a forma computadorizada ou eletrônica de armazenamento de


dados de diversos sistemas, para consultas e atualizações pelos usuários, é o
equivalente eletrônico dos armários de arquivamento das repartições públicas e/ou
privadas, segundo DATE (2000, p. 2). Banco de dados, para HEUSER (2001, p. 4), é o
“conjunto de dados interligados que tem por objetivo atender a uma comunidade de
usuários”.
Para falar de banco de dados, dois conceitos são relevantes, os conceitos de
“dado” e de “informação”. Por “dado”, subentende-se o valor do campo quando é
armazenado no banco de dados (PAES). Já “informação” é um conjunto de dados
transmitidos a alguém ou a um sistema, sobre o qual, ele não tem nenhum
conhecimento prévio (FEDERLE, 2001, p. 10).
Um banco de dados pode armazenar qualquer tipo de informação que interesse
a alguém e/ou a uma empresa. Hoje em dia, são inúmeras as aplicações de banco de
dados. As empresas, através do uso de banco de dados, podem controlar o estoque de
produtos vendidos e/ou de matérias-primas, tendo com isso um maior controle de seus
recursos. Na Internet, a utilização de banco de dados se faz presente desde o
armazenamento dos dados de um cliente que preenche um formulário, até a consulta
de um determinado assunto em um site de busca.
Esse capítulo visa abordar as principais vantagens do uso de banco de dados,
além de como é constituída a sua arquitetura. Será abordado também o conceito de
SGBD (Sistema Gerenciador de Banco de Dados) e suas funções, que são de
28
extrema importância para o entendimento do tópico seguinte, o qual seja, banco de
dados Interbase. Tendo em vista, o Interbase ser o banco de dados que será usado
nesse trabalho, haverá ênfase nos principais conceitos desse assunto. O capítulo se
encerra falando sobre a importância de se fazer manutenção em banco de dados e quais
são as etapas que devem ser seguidas para se realizar a mesma.

4.1. Vantagens da Utilização de Banco de Dados:

A utilização de um banco de dados tras inúmeras vantagens, dentre elas pode-se


citar:
Redução e Eliminação de Redundâncias: Com a utilização de um banco
de dados em substituição aos sistemas de arquivos, tornou-se possível
reduzir o número de dados repetidos. Uma vez que o banco de dados
caracteriza-se como sendo um repositório de informações, permitindo que
o acesso a uma única informação seja buscada por diversos sistemas
distintos (PAES).
Eliminação de Inconsistências: A inconsistência de dados é mais
freqüente em sistemas de arquivo do que em banco de dados, onde um
mesmo campo tinha valores distintos em sistemas diferentes. Como em
um banco de dados, os dados estão armazenados em um único local e
sendo consultados de forma descentralizada e compartilhada a diversos
sistemas, geralmente não haverá inconsistência de dados (PAES), pois
não existirão dados isolados.
Compartilhamento de Dados: Segundo PAES, “Um banco de dados
permite a utilização simultânea e segura de um dado, por mais de uma
aplicação ou usuário, independente da operação que esteja sendo
realizada”.
Suporte a Transações: Transação é um conjunto de operações (uma ou
mais operações) realizadas dentro do banco de dados (FEDERLE, 2001,
p. 11). Sabe-se que os banco de dados são sistemas computacionais e que
29
como qualquer sistema mecânico ou elétrico, estão sujeitos a falhas
(SILBERSCHATZ; KORTH e SUDARSHAN, 1999, p. 3). O banco de
dados deve por sua vez garantir segurança para que em casos de falhas
(queda de energia, por exemplo) as transações sejam efetuadas por
completo ou canceladas, preservando com isso a integridade dos dados.
Problemas de Integridade dos Dados: O problema de integridade dos
dados diz respeito a garantia que os dados armazenados no banco de
dados estejam corretos (FEDERLE, 2001, p. 11). Esse problema
geralmente ocorre quando existe redundância dos dados. Apesar disso,
segundo DATE (2000, p. 16), “... mesmo que não exista nenhuma
redundância, o banco de dados ainda poderá conter informações
incorretas”. Essas informações podem ser evitadas através de um controle
centralizado do banco de dados.

4.2. Arquitetura de Banco de Dados

A arquitetura de banco de dados é o modo abstrato como os dados são


organizados, armazenados e consultados no banco de dados. Essa arquitetura divide-se
em três níveis de abstração, são eles:
Nível Físico ou Interno: Descreve efetivamente como os dados estão
armazenados fisicamente. Implementa o nível mais baixo de abstração,
utilizando desta forma, estruturas e dados de baixo nível para o
armazenamento dos dados (SILBERSCHATZ; KORTH e
SUDARSHAN, 1999, p.4).
Nível Lógico ou Conceitual: Descreve quais os dados que serão
armazenados no banco de dados, bem como o inter-relacionamento entre
eles. Essa fase implementa nível médio de abstração (SILBERSCHATZ;
KORTH e SUDARSHAN, 1999, p.4).
Nível Externo ou de Visão: É o nível mais alto de abstração e implementa
a visão do banco de dados que ficará acessível a cada usuário. Nesse
30
nível é possível definir várias visões do banco de dados, de acordo com
as necessidades dos usuários.

4.3. Sistema Gerenciador de Banco de Dados (SGBD)

A forma de armazenamento de dados vem passando por mudanças ao longo dos


anos. Antes da informatização dos escritórios a maior parte das formas de
armazenamento de dados eram baseadas em papéis organizados em armários
chamados de arquivos. Com o advento da informatização, iniciou-se uma redução do
número de papéis circulando pelos escritórios, pois os dados passaram a ser
armazenados e recuperados através do processamento de arquivos, o que resultou em
uma série de problemas, tais como: segurança, redundância e inconsistência de dados
entre outros (DATE, 2000, p. 37).
Com o surgimento das tecnologias atuais de banco de dados, foram
solucionados muitos dos problemas dos sistemas de arquivos. A partir de então, para
gerenciar todos os acessos aos bancos de dados surgiram softwares específicos
chamados de SGBD, que facilitaram este trabalho (DATE, 2000, p. 37).

4.3.1. Funções do SGBD

O SGBD implementa diversas funções, as mais importantes serão abordadas a


seguir:
Linguagem de Definição de Dados (DDL – Data Definition Language).
O SGBD deve dar suporte as várias linguagens de definição de dados
existentes, realizando a conversão das mesmas para a forma objeto
adequada (DATE, 2000, p. 37). Para que isso seja possível, o SGBD deve
ser composto de componente processador DDL ou compilador DDL,
conforme DATE (2000, p. 37), “para cada uma das diversas linguagens
de definição de dados (DDLs)”.
Manipulação de Dados (DML – Data Manipulation Language): O SGBD
31
deve dar suporte para possíveis solicitações de acessos e/ou alterações
dos dados pelos usuários, em outras palavras, deve permitir a busca,
atualização, exclusão e até mesmo, inclusão de dados no banco de dados
pelo usuário. Para que isso seja viável, o SGBD deve ser composto de um
componente processador de DML ou compilador de DML que farão
interação com a linguagem de manipulação de dados (DATE, 2000, p.
37).
As solicitações de DML são divididas em dois tipos, que são as “planejadas” e
as “não-planejadas”.
Solicitações Planejadas: São solicitações previstas pelo DBA
(DataBase Administrator – Administrador de Banco de Dados), na
etapa de projeto de banco de dados, sendo deste modo, prevista antes
de serem executadas. Como exemplo deste tipo de solicitação pode-se
citar as aplicações “operacionais” ou “de produção” (DATE, 2000, p.
38).
Solicitações não-planejadas: Como o próprio nome sugere, são
solicitações que não tiveram sua previsão na fase de projeto ou
antecipadamente, mas em contra partida, surgem no último instante.
Esse tipo de solicitação surge surpreendendo o banco de dados que
geralmente não está adaptado a suportá-la. Como exemplo desse tipo
de solicitação pode-se citar as aplicações para “apoio à decisão”.
Otimização e Execução: O SGBD deve possuir o componente otimizador,
o qual é o responsável pelo processamento das solicitações de DML,
planejadas ou não-planejadas (DATE, 2000, p. 38). Em outras palavras, a
função do otimizador é implementar de forma eficiente as solicitações do
usuário.
Segurança e Integridade: Segurança pode ser interpretado como o
controle estabelecido pelo SGBD para garantia da integridade dos dados
armazenados, com relação aos acessos pelos usuários. Conforme se
mencionado acima, as restrições de segurança e integridade devem ser
32
estabelecidas anteriormente pelo DBA. Já segurança e integridade,
segundo DATE (2000, p. 38):

“O SGBD deve monitorar requisições de usuários e rejeitar toda tentativa de violar as


restrições de segurança e integridade definidas pelo DBA. Essas podem ser executadas em
tempo de compilação, ou ainda em alguma mistura dos dois”.
Recuperação e Concorrência: Sabe-se que transações são operações de
manipulação de dados que são executadas em uma falha no banco de
dados, como por exemplo, na falta de energia. O controle de
concorrência, segundo FATEC-SP, é utilizado com o objetivo de “evitar
conflitos de acessos simultâneos a um dado por mais de uma transação”.
FEDERLE (2001, p. 13) menciona porque é importante evitar o acesso
simultâneo a um dado por diversas transações, conforme a citação, “A
concorrência dos dados deve ser controlada, pois esse controle garante
que somente uma transação manipule um dado. Acessos simultâneos
podem tornar-se inválidos caso sejam atualizados por outras transações”.
Por recuperação, segundo FATEC-SP, entende-se também:

“Possibilitar o retorno do banco de dados a um estado consistente de seus dados após a


ocorrência de uma falha involuntária. Para tanto, o SGBD deve manter, por exemplo,
arquivos históricos (chamados logs) que cadastram todas as atualizações realizadas no
banco de dados por transações”.
Dicionário de Dados: É um componente do SGBD, onde estão contidas
todas as informações referentes aos dados armazenados no banco de
dados. FEDERLE (2001, p. 13), além de mencionar de forma mais clara
esse conceito, cita mais algumas informações:

“O dicionário de dados mantém armazenado o mapeamento de todas as informações


pertencentes ao sistema de dados. Guardando consigo, as entidades e relacionamentos, as
autorizações de acesso, localização de onde se encontram os dados, etc”.

4.4. Banco de Dados Interbase

O Interbase é um SGBDR (Sistema Gerenciador de Banco de Dados


Relacional) compatível com SQL-ANSI 92, e foi desenvolvido para ser um banco de
33
dados independente de sistema operacional e plataforma.
O Interbase foi desenvolvido no ano de 1985 por engenheiros da DEC (Digital
Equipament Corporation), onde era chamado de Groton (RODRIGUES).
A partir de 1986 passou a ser chamado de Interbase inicialmente na versão 2.0.,
com o desafio de tornar–se um SGBDR que incorporasse os benefícios inexistentes
nos concorrentes da época (RODRIGUES).
O Interbase inicialmente era comercializado pela empresa Ashton Tate e a partir
de 1992 passou a ser comercializado pela empresa Borland (FEDERLE, 2001, p. 14).
A Borland na versão 6 do Interbase resolveu adotar uma estratégia para aumentar a
popularidade do seu produto. Ela tornou o seu produto de “Código Aberto” (Open
Source), ou seja, na versão 6 o Interbase passou a fornecer licenças de utilização e
distribuição de graça, FREE (RODRIGUES), pela Internet. Com o Interbase sendo um
produto gratuito os desenvolvedores de sistemas passam a contar com um banco de
dados, segundo RODRIGUES, “poderoso, eficiente e seguro e seu cliente não vai
precisar pagar nada a mais por isso”.
Certamente, o fator custo é uma das grandes vantagens do Interbase em relação
aos seus concorrentes, além disso, o Interbase possuí as seguintes características:
Plataformas: O Interbase é compatível com a maioria das plataformas e
sistemas operacionais existentes, dentre eles os principais são: Windows
9x, Windows NT, Linux, Solaris (RODRIGUES). Esse fato é importante
em aplicações voltadas para a Internet (FEDERLE, 2001, p. 14);
Gerenciamento de Transações: Uma transação ou um conjunto de
transações é um grupo de operações que geralmente numa situação de
falhas deve se realizar por completo (sucesso) ou não se realizar
(insucesso), no banco de dados (SILVA, 2000, p. 4). O Interbase
gerencia essas transações permitindo que aplicações-clientes iniciem
diversas transações simultâneas (SILVA, 2000, p. 4);
Acesso Multiusuário: O Interbase dá suporte à execução de diversas
aplicações clientes em acessos de forma simultânea em um mesmo banco
de dados (SILVA, 2000, p. 3). Essas mesmas aplicações podem ter acesso
34
a vários bancos de dados ao mesmo tempo;
Nível de Bloqueio: Quando dois ou mais usuários tentam atualizar ou
acessar a mesma faixa de dados podem surgir problemas ameaçando a
integridade do banco de dados. Em sistemas multiusuários esse tipo de
problema é freqüente e chamado de concorrência (SILVA, 2000, p. 4).
Existem duas estratégias atualmente para solucionar o problema da
concorrência, são as estratégias de “bloqueio pessimista” e de “bloqueio
otimista”. A estratégia de “bloqueio pessimista” é utilizada geralmente
em bancos de dados locais como o Paradox (SILVA, 2000, p. 4). Já a
estratégia de “bloqueio otimista” é utilizada pela maioria dos servidores
SQL (Structured Query Language), inclusive o Interbase.
A estratégia pessimista funciona da seguinte forma: assim que um usuário tenta
mudar um registro, o mesmo é travado. Nenhum outro usuário pode fazer alterações
neste registro até que o primeiro usuário termine as alterações ou cancele a operação.
A estratégia otimista não fica segurando o registro como a pessimista, na
verdade, quando um usuário processa uma alteração o registro não impedirá que outros
usuários tentem também alterar este registro. Quando um usuário começa a alterar um
registro, uma copia do registro original é salva. O usuário executa seu serviço, mas os
outros usuários não estão de nenhuma forma impedidos de acessar o mesmo registro.
Como citado anteriormente e, segundo SILVA (2000, p. 4), “O Interbase se
utiliza de um mecanismo de bloqueio otimista em nível de linha. Desta forma, vários
usuários podem atualizar dados em uma mesma tabela sem que estejam sujeitos a
conflitos”.
Arquitetura Multigeracional: É a capacidade que o Interbase tem de criar
versões dos registros (FEDERLE, 2001, p. 15). A importância da criação
dessas novas versões de registros é mencionada por SILVA (2000, p. 4),
“o Interbase permite que todos os clientes (usuários) possam ler aquele
35
registro, mesmo que um outro usuário o esteja atualizando naquele exato
momento”.
Arquivos-sombra: Um arquivo-sombra, segundo SILVA (2000, p. 4)
“traduz-se numa cópia física idêntica de um banco de dados”. O
Interbase suporta a criação de arquivos-sombra. Segundo FEDERLE
(2001, p. 15), “... qualquer alteração realizada no banco de dados é
automaticamente modificada no arquivo-sombra”.

4.4.1. A Ferramenta IBConsole

A ferramenta IBConsole é uma interface que foi desenvolvida em Delphi e que


agrupa duas interfaces que se destacaram em versões anteriores do Interbase, são ela:
Interbase Server Manager e Interbase Interactive SQL (SILVA, 2000, p. 14).
Para RODIGUES, “O IBConsole é o gerenciador de dados que acompanha o
Interbase. A grande vantagem dele é o fato, de não ser uma somente uma ferramenta
de criação de tabelas”. Isso ocorre porque toda a criação, relacionamento manutenção
é realizado via linha de comando SQL (Structured Query Language).
A IBConsole segundo SILVA (2000, p. 14), apresenta as seguintes
características:
a) Administrar a segurança do servidor;
b) Fazer backup de bancos de dados e restaurar backups;
c) Analisar estatísticas sobre servidores e bancos de dados;
d) Verificar a integridade dos bancos de dados.
A interface gráfica da ferramenta IBConsole é demonstrada a seguir, na figura
1:
36

FIGURA 1: Ferramenta IBConsole

4.4.1.1. Componentes que constituem a ferramenta IBConsole

A ferramenta IBConsole é constituída de cinco elementos conforme


demonstrados na figura 2, abaixo:

Barra de Menus

Barra de Ferramentas

Janela de Visualização Janela de Trabalho


(em árvore) do servidor,
banco de dados e meta
dados
Barra de Status

FIGURA 2: Elementos da Ferramenta IBConsole


37
4.4.1.1.1. Componentes do Menu da Ferramenta IBConsole

Os componentes que constituem o menu da ferramenta IBConsole podem ser


observados na Figura 3 e são descritos logo em seguida:

FIGURA 3: Menu IBConsole

Console: É utilizado para sair da ferramenta;


View: Utilizado para configurar a forma de visualização dos dados;
Server: Segundo SILVA (2000, p. 15), é utilizado para “registrar
(desabilitar) servidores, estabelecer conexões com servidores,
diagnosticar conexões, gerenciar usuários, adicionar e remover
certificados e visualizar arquivos de log e as propriedades dos
servidores”;
Database: Segundo SILVA (2000, p. 15), dispõem de funções para
permitir: “registrar (desabilitar) banco de dados, estabelecer conexões
com bancos de dados, criar e destruir bancos de dados, realizar tarefas de
manutenção (cópia de segurança, restauração, etc), visualizar e recuperar
metadados, visualizar vários usuários conectados e as propriedades dos
bancos de dados;
Windows: Essa opção é utilizada para facilitar a visualização das janelas
abertas na IBConsole e permitir alternâncias entre elas.
Tools: É utilizado para configurar as ferramentas de trabalho e executar a
ferramenta Interactive SQL.
Help: É utilizado para obter acesso a arquivos de ajuda da ferramenta
IBConsole, bem como do servidor Interbase.

4.4.1.1.2. Ferramenta Interactive SQL

A ferramenta Interactive SQL é utilizada para estabelecer a comunicação e


interação com o banco de dados (SILVA, 2000, p. 218). Ela pode ser acessada a
38
partir do IBConsole e apresenta a interface mostrada na Figura 4, abaixo.

Barra de
Menu

Barra de Área de
Ferramentas Comandos

Área de
Resultados
Barra de Estados

FIGURA 4: Ferramenta Interactive SQL

Como pode ser visto na Figura 4, a ferramenta é constituída do menu de


funções, mostrado de forma mais detalhada na Figura 5 e descrito logo em seguida:

FIGURA 5: Menu da Ferramenta Interactive SQL

File: Permite sair da ferramenta Interactive SQL, bem como imprimir os


código existentes na área de comandos;
Edit: Como o próprio nome sugere, é utilizado para editar comandos na
Área de comandos. Desta forma é composto dos comandos de Recortar,
Copiar, Colar e Selecionar Tudo, bem como das funções Localizar,
Opções de fonte, essa última sendo utilizada para configurar a letra
utilizada na Área de Comandos;
Query: Segundo SILVA (2000, p. 21), “Contém opções de execução e
navegação nos comandos SQL apresentados na Área de Comandos”;
Database: Contém opções de conectar e desconectar em bancos de
dados, bem como, opções de criar e apagar banco de dados;
39
Transactions: Permite realizar as transações de Commit e Rollback;
Windows: Essa opção é utilizada para permitir a alternância entre as
janelas Interactive SQL e a janela da ferramenta IBConsole;
Help: Essa opção é utilizada para acessar os arquivos de ajuda de
referência do Interbase SQL Reference.

4.5. Manutenção de Banco de Dados

Os aspectos fundamentais ligados à manutenção de banco de dados são as


operações de cópia de segurança (backup) e restauração dos dados (restore) (SILVA,
2000, p. 137).
As operações de backup são cópias de segurança de um arquivo guardada em
disco rígido ou outro meio de armazenamento, geralmente não é aconselhável que seja
feito backup no mesmo disco em que se encontram os arquivos originais (SILVA,
2000, p. 137).
A principal função das operações de Restore é restaurar cópias de seguranças
(backup) de banco de dados que sofreram algum tipo de problemas. Apesar disso, as
operações de Restore estão sendo geralmente utilizadas, segundo SILVA (2000, p.
137), “... para „enxugar‟ o banco de dados ou balancear índices”.

4.5.1. Backup e Restore no Interbase

A realização de backup e restore no Interbase oferece algumas vantagens,


mencionadas por SILVA (2000, p. 138), as quais são descritas abaixo:
a) Melhorar o desempenho do banco de dados;
b) Reduzir o tamanho do banco de dados, ao recuperar espaços perdidos por
registros excluídos e compactar os dados remanescentes;
c) Realizar mudanças na estrutura do banco de dados, como aumentar ou diminuir
o tamanho das páginas de dados;
d) Criação de cópias independentes de plataformas;
40
Para realizar um Backup utilizando o Interbase 6.0, basta acessar o menu
Database do IBConsole, conforme mostra a Figura 6:

FIGURA 6: Acessando Operações de Backup no Interbase 6.0

Depois de escolhida a opção Backup, mostrada na Figura 6, abrirá a tela de


manutenção mostrada na Figura 7 a seguir:

FIGURA 7: Tela de Backup do Banco de dados Interbase 6.0


41
O Quadro 2 explica as opções disponíveis na tela de Backup do banco de
dados Interbase 6.0 mostrada na Figura 7:

QUADRO 2: Opções de Backup


Propriedades
Opções
Nome Descrição
Permite recuperar Backup feitos em uma plataforma
Transportable
Windows para uma plataforma Unix (SILVA, 2000, p. 140).
Format
Não permite recuperar Backup feito em uma plataforma
Non-Transportable
Windows para uma plataforma Unix, por exemplo.
Escolhendo essa propriedade, será feito Backup apenas dos
metadados do banco de dados. Essa opção é utilizada
True
quando se deseja recriar um banco de dados idêntico ao que
Metadata Only
esta sendo copiado.
Escolhendo essa propriedade, todo o conteúdo do banco de
False
dados será salvo.
Escolhendo esta propriedade, todas as versões obsoletas de
registros serão rejeitadas e desta forma, ocorrerá um
True
aumento no tamanho do banco de dados (SILVA, 2000, p.
Garbage Collection
140).
Essa propriedade é utilizada quando se deseja obter uma
False
cópia idêntica do banco de dados.
Essa propriedade mantém as transações pendentes na cópia
Process
de segurança.
Transactions in Limbo
Nessa propriedade, todas as transações pendentes serão
Ignore
descartadas (SILVA, 2000, p. 140).
Essa propriedade, força o processo de Backup checar, página
Process
a página, a integridade dos dados (SILVA, 2000, p. 140).
Checksums
Escolhendo essa propriedade não será checado a integridade
Ignore
dos dados página a página, durante o Backup.
Realiza a conversão de arquivos externos em tabelas internas
True
Convert to Tables (SILVA, 2000, p. 140).
False Não fará a conversão descrita na propriedade anterior.
None Bloqueia o monitoramento da operação de Backup.
To Screen Permite a visualização do andamento do processo na tela.
Verbose Output
Essa opção direciona o resultado do processo de Backup
To File
para um arquivo.

Vimos as opções que geralmente são utilizadas em caso de Backup, entretanto,


caso tenhamos que recuperar uma cópia de segurança, por problemas existentes nos
dados originais ou apenas para “enxugar” o banco de dados, balancear os índices ou
mesmos atualizar a estrutura do banco de dados (SILVA, 2000, p. 142), deve-se
proceder conforme mostra a Figura 8:
42

FIGURA 8: Acessando Operações de Restore no Interbase 6.0

Escolhida a opção Restore conforme mostrado na Figura 8, aparecerá a tela de


operação de Restore exibida na Figura 9:

FIGURA 9: Tela de Restore do Banco de dados Interbase 6.0


43
O Quadro 3 explica as opções disponíveis na tela de Restore do banco de
dados Interbase 6.0, mostradas na Figura 9:

QUADRO 3: Opções de Restore


Opções Propriedades
Nome Descrição
1024
2048
Page Size Tamanho da Página
4096
8192
Escolhendo essa propriedade, a operação sobrescreve o arquivo de
True
banco de dados existente (SILVA, 2000, p. 143).
Overwrite
Esta propriedade, não deve ser escolhida quando usuários estiverem
False
usando o banco de dados.
Esta propriedade, segundo SILVA (2000, p. 143), “obrigará o
True Interbase a recuperar o metadados e os dados de cada tela, além de
Commit After Each Table confirmar a operação (commit) tabela por tabela”.
Com esta propriedade, segundo SILVA (2000, p. 143), “o metadados
False
é inteiramente recuperado e em seguida, os dados são recuperados”.
Essa propriedade, recupera arquivos shadow (de sombreamento).
True Para SILVA (2000, p. 143), “Arquivos shadow são cópias físicas
Create Shadow Files idênticas de arquivos de bancos de dados”.
Com a escolha dessa propriedade, não serão recriados os arquivos de
False
sombreamento.
Essa propriedade, segundo SILVA (2000, p. 143), “normalmente é
True
utilizada quando há suspeita de que os dados estão inconsistentes”.
Deactivate Indexes Essa propriedade permite que os arquivos de índice sejam recriados
False ao final do processo de recuperação dos dados (SILVA, 2000, p.
143).
Com essa propriedade, a proporção é de 100% no preenchimento das
True
páginas de dados.
Use All Space
Com essa propriedade, será mantida a proporção padrão de 80% no
False
preenchimento das páginas de dados (SILVA, 2000, p. 143).
Essa propriedade é utilizada para validar as condições de restrições
Restore dos dados, ou seja, se os dados estiverem inconsistentes, a
Validity Conditions restauração dos mesmos será abortada (SILVA, 2000, p. 144).
É utilizada quando já se tem suspeita ou certeza de que alguns dados
Ignore
estão incoerentes.
None Inibe o monitoramento da operação de Restore.
To Screen Permite a visualização do andamento do processo na tela.
Verbose Output
Essa opção direciona o resultado do processo de Restore para um
To File
arquivo.

4.6. Conclusão

Esse capítulo apresentou alguns conceitos e definições de banco de dados.


Dentre esses conceitos, foi abordado as vantagens da utilização de banco de dados e
como é formada a sua arquitetura. Entretanto, o enfoque maior desse capítulo
44
foi relacionado ao SGBDR Interbase 6, esse destaque ocorreu por ser o banco de
dados escolhido para utilização no trabalho proposto.
5. CONCEITOS DE MODELAGEM

Esse capítulo visa apresentar os assuntos mais significativos referentes a


importância de se fazer a modelagem de um projeto. Além disso, esse capítulo abrange
toda a parte teórica que envolve a UML, iniciando com um breve histórico, explicando
a seguir o que é a UML e encerrando com uma descrição sobre os diagramas da UML
e as ferramentas existentes para desenvolver esses diagramas.

5.1. A Importância da Modelagem

Para que uma empresa de software seja bem sucedida, ela deve fornecer um
software de qualidade e que venha atender às necessidades de seus clientes. Segundo
BOOCH, RUMBAUGH e JACOBSON (2000, p. 3), “Uma empresa que consiga
desenvolver esse software de maneira previsível e em determinado período, com
utilização eficiente e eficaz de recursos, será uma empresa com um negócio viável”.
Muitas empresas trabalham buscando alcançar esse patamar, ou seja,
desenvolver um bom software que consiga satisfazer às necessidades de seus clientes e
dos seus respectivos negócios. Os principais requisitos para que isso seja possível, são
mencionados por BOOCH, RUMBAUGH e JACOBSON (2000, p. 3) na citação
seguinte:
46
“Para entregar um software que satisfaça ao propósito pretendido, será preciso reunir-se e
interagir com os usuários de uma maneira disciplinada, com a finalidade de expor os
requisitos reais do sistema. Para desenvolver software de qualidade duradoura, será
necessário criar uma arquitetura de fundação sólida que aceite modificações. Para
desenvolver software de forma rápida, eficiente e efetiva, com o mínimo de desperdício e
de retrabalho de software, será preciso dispor das pessoas certas, das ferramentas
adequadas e do enfoque correto. Para fazer tudo isso de maneira previsível e consistente,
com uma avaliação dos custos reais do sistema, você precisará de um processo seguro de
desenvolvimento que possa ser adaptado às novas necessidades de seu negócio e de sua
tecnologia”.
A modelagem do projeto é constituída de diversas etapas essenciais na criação
de um software de qualidade. Desenvolvendo protótipos na modelagem, ficará mais
fácil para os usuários visualizarem como será o produto final e aprovarem ou não o
software que está sendo criado. Uma das vantagens de se criar protótipos, é que caso
ele venha a ser reprovado pelos usuários, a empresa não terá muitos prejuízos, tanto
financeiramente, quanto nos prazos que terá que cumprir para a conclusão do projeto.
Isso ocorre porque para desenvolver-se um protótipo, leva-se menos tempo e usa-se
menos recursos em comparação com o projeto total.
No entanto, caso o protótipo seja aprovado pelos usuários, a empresa saberá que
está no rumo certo para desenvolver um software que atenda as necessidades dos
clientes, bastando apenas continuar os trabalhos na mesma direção.
Nota-se que a modelagem é de grande importância para que os usuários possam
acompanhar o trabalho que está sendo desenvolvido. No entanto, a importância do uso
de modelos geralmente é mais significativo para a empresa que está desenvolvendo o
software, pois além de permitir testar o sistema, segundo MATOS (2002, p. 15 ), o
modelo apresenta as seguintes vantagens:
Diminuição da complexidade do sistema, já que é difícil entender a
complexidade do todo;
Simplificação da realidade por meio de uma abstração, que pode ser
facilmente entendida;
Possibilidade de enxergar os problemas do sistema antes mesmo que eles
aconteçam.
47
Possibilidade de simular situações que seriam perigosas ou até danosas
caso fossem executadas no sistema em ação.
A modelagem deste trabalho utilizará os métodos de modelagem orientado à
objetos baseados na UML (Unified Modeling Language) através da ferramenta
Rational Rose Enterprise Edition.

5.2. Histórico da UML

Nas últimas décadas notou-se uma constante mudança dos métodos e técnicas
para a engenharia de software com o intuito de acompanhar os avanços evolutivos do
conhecimento, incluindo a análise e o projeto estruturado, a análise essencial e a
Engenharia da Informação (FURLAN, 1998, p. 23).
Essas mudanças começaram a ocorrer com o surgimento dos métodos de
modelagem orientados a objeto durante o período decorrente entre a metade da década
de 70 e final da década de 80. Nessa época o número de métodos existentes, deu um
salto de menos de 10 para mais de 50 (FURLAN, 1998, p. 24). Apesar do aumento no
número de métodos, muitos usuários ainda encontravam dificuldades na busca de
linguagens de modelagem capazes de suprir a todas as suas necessidades,
contribuindo, desta forma para aumentar com a chamada “Guerra de métodos”
(BOOCH, RUMBAUGH e JACOBSON, 2000, p. XVI).
Todavia, passada a chamada, “Guerra de método”, novas gerações de métodos
foram surgindo, e alguns obtiveram grande destaque. Dentre esses destaques
encontram-se, segundo BOOCH, RUMBAUGH e JACOBSON (2000, p. XIV), os
métodos de: Booch, OOSE (Object Oriented Software Enginnering) de Jacobson, o
OMT (Object Modeling Technique) de Rumbauah, Shlaer/Mellor e Coad/Yordon.
O Quadro 4 a seguir, ressalta as características dos principais métodos, bem
como quais foram os seus autores:
48

QUADRO 4: Autores e Características dos Método de Modelagem O. O.


Método Autor (es) Características
Booch Grady Booch Emprego de técnicas de desenho orientado à objeto
OOSE Ivar Jacobson Criou a base para métodos OOSE e Objectory, direcionando seu
foco em caso e a categorização de pessoas e equipamentos
dependendo de seu papel no sistema global.
OMT James Rumbaugh É um método poderoso para a criação de modelos de objetos de
domínio. Seu enfoque é dirigido a objeto principalmente aqueles
que estão dentro do sistema e suas associações.
Shlaer/Mellor Sally Shaer e Stephen Utilizam diagramas de entidade/relacionamento e de transição de
Mellor estado, na sua maioria derivados dos métodos de análise e
desenho de sistemas de tempo real.
Coad/Yourdon Peter Coad e Ed Yordon Propõem a identificação e a definição de classes e objetos,
estruturas, sujeitos, atributos e serviços, como passos básicos para
a realização da análise orientada a objetos.

Segundo BOOCH, RUMBAUGH e JACOBSON (2000, p. XVI), “Todos eram


métodos completos, apesar de cada um conter pontos fortes e fracos”.
Na metade da década de 1990, os principais autores dos métodos Booch, OOSE
e OMT observaram que esses métodos estavam caminhando de forma paralela, sendo
reconhecidos mundialmente como os principais métodos orientados a objeto. A partir
dessa época, esses autores vislumbraram a possibilidade de criar uma linguagem
unificada de modelagem.
No entanto, a criação da UML (Unified Modeling Language) veio a se
concretizar somente em 1994, com a união de esforços de Rumbaugh e Booch na
Rational Corporation. O foco principal desta união foi a criação do projeto que previa
a unificação dos métodos Booch e OMT. O resultado dessa união foi o lançamento em
outubro de 1995, do rascunho do método unificado (como foi chamado a princípio) na
versão 0.8.
Em outubro de 1995, Jacobson também se associou a Rational e o projeto foi
expandido com o intuito de incorporar o método OOSE. A associação de Jacobson
somou forças ao projeto, que culminaram com o lançamento em junho de 1996 dos
documentos da versão 0.9 da UML. Ainda durante o ano de 1996, os autores da UML,
fizeram um apelo a comunidade de engenharia de software em geral, buscando
parceiros que investissem no projeto. O retorno não demorou a chegar, pois nesta
época a UML estabeleceu um consórcio com várias empresas que tinham
49
interesse em investir no seu projeto com o propósito de obter uma definição mais
consistente e completa da UML (BOOCH, RUMBAUGH e JACOBSON, 2000, p.
XVII).
A maioria das empresas associada considerava a UML, como um recurso
estratégico para seus negócios. Algumas das principais parceiras foram Microsoft, HP
(Hewlett-Packard), Oracle, IBM, Texas Instruments Software, MCISystemhouse, entre
outras. Essa associação veio dar frutos, em janeiro de 1997, com o lançamento da
UML 1.0 e em setembro do mesmo ano com a exibição da UML 1.1.
Em novembro de 1997 a guerra de métodos orientados a objeto chegou ao seu
final, com a aprovação da UML pela OMG (Object Management Group) (FURLAN,
1998, p. 32).
A partir de 14 de novembro a manutenção da UML foi assumida pela RTF
(Revision Task Force) a qual faz parte do OMG. E segundo BOOCH, RUMBAUGH e
JACOBSON (2000, p. XVIII) “A RTF lançou uma revisão editorial, a UML 1.2, em
junho de 1998. No final de mesmo ano, a RTF lançou a UML 1.3, (...) fornecendo
alguns aprimoramentos técnicos”. Atualmente a UML encontra-se na versão 1.4 e suas
modificações vêm sendo debatidas em várias listas de discussão internacionais
(MATOS, 2002, p. 30).

5.3. A UML ?

A UML (Unified Modeling Language), é uma ferramenta completa para criar,


entender, testar, validar, arquitetar, bem como, identificar todos os possíveis
comportamentos do sistema, principalmente nos sistemas orientados a objeto
(MATOS, 2002, p. 16).
Para BOOCH, RUMBAUGH e JACOBSON (2000, p. 13), a UML “... é uma
linguagem–padrão para a elaboração da estrutura de projetos de software, (...) poderá
ser empregada para a visualização, a especificação, a construção e a documentação de
artefatos que façam uso de sistemas complexos de software”.
50

5.4. Diagramas da UML

Os Diagramas são a apresentação de forma gráfica de um conjunto de modelos,


no caso da UML, geralmente mostrados com gráficos de vértices (itens) e arcos
(relacionamentos) (FURLAN, 1998, p. 73). O uso de diagramas proporciona a
visualização de um sistema sob diferentes perspectivas. Tendo em vista, que nenhum
sistema é totalmente compreendido em uma única perspectiva, através da UML, foi
definido um número de diagramas capaz de abordar aspectos diferentes do sistema de
forma independente (BOOCH, RUMBAUGH e JACOBSON, 2000, p. 89).
Os diagramas de modelagem de sistemas propostos pela UML são os seguintes:
Diagrama de Caso de Uso (do inglês Use Case);
Diagrama de Seqüência;
Diagrama de Classe;
Diagrama de Estado e de Atividade;
Diagrama de Componentes e de Implementação.
Esse trabalho abordará somente os três primeiros diagramas, pois apenas estes
serão utilizados na modelagem do sistema proposto. Já a descrição das características
dos demais diagramas, além de outros assuntos referentes a eles, podem ser
encontrados nas bibliografias citadas neste trabalho.

5.4.1. Diagrama de Caso de Uso

Os diagramas de caso de uso são utilizados para identificar as funções do


sistema, bem como os atores responsáveis por usá-las (MATOS, 2002, p. 31). Em
suma ao ator cabe o papel de interação com o sistema, e segundo FURLAN (1998, p.
77) o mesmo pode ser, “... um usuário, dispositivo ou outro sistema”.
A notação adotada pela UML para mostrar o relacionamento entre atores e
casos de uso em um sistema é apresentada na Figura 10:
51

FIGURA 10: Diagrama de Caso de Uso.


Fonte (FURLAN, 1998, p. 77).

Os diagramas de caso de uso, segundo BOOCH, RUMBAUGH e JACOBSON


(2000, p. 95), “são importantes principalmente para a organização e modelagem dos
comportamentos de um sistema”.

5.4.2. Diagrama de Seqüência

O diagrama de seqüência faz parte dos diagramas de interação. Então antes de


abordarmos sobre diagrama de seqüência, é necessário citar o conceito de diagrama de
interação. Diagramas de interação, segundo MATOS (2002, p. 57), são “... a
representação do comportamento dinâmico que uma sociedade de objetos necessita ter
para que a execução de alguma tarefa possa ser acompanhada”. O diagrama de
interação é composto também do diagrama de colaboração, o qual não será falado
nesse trabalho, pois não será utilizado.
O diagrama de seqüência como o próprio nome sugere, baseia-se numa
seqüência ordenada de interações exercidas pelos objetos ao longo do tempo
(FURLAN, 1998, p.77). A forma como são organizados os elementos no diagrama de
seqüência segundo FURLAN (1998, p. 182), procede do seguinte modo: “Os objetos
são desenhados como linhas verticais, as mensagens com linhas horizontais e a
seqüência de mensagens é lida de cima para baixo na página”. A Figura 11 ajuda a
visualizar melhor a descrição citada.
52

FIGURA 11: Diagrama de Seqüência


Fonte (FURLAN, 1998, p. 185)

A utilização dos diagramas de seqüência dar-se-á para visualizar a dinâmica e o


funcionamento de um sistema (BOOCH, RUMBAUGH e JACOBSON, 2000, p. 96).

5.4.3. Diagrama de Classe

É um diagrama bidimensional que apresenta um conjunto de classes, interfaces


e colaborações, bem como os seus relacionamentos (BOOCH, RUMBAUGH e
JACOBSON, 2000, p. 94). O diagrama de classe é estático, segundo FURLAN (1998,
p. 76) “... pois a estrutura descrita é sempre válida em qualquer ponto no ciclo de vida
do sistema”.
Os diagramas de classe geralmente são utilizados em modelagem orientada à
objeto. E para MATOS (2002, p. 31) esses diagramas servem para, “... identificar as
estruturas mínimas de informações”.
Um exemplo de diagrama de classe pode ser visto na Figura 11, a seguir:
53

FIGURA 12: Diagrama de Classe


Fonte (MATOS, 2002, p. 31)

5.5. Ferramentas de Modelagem

A UML, conforme abordado no tópico 5.2. deste relatório, foi criada pela
Rational Corporation, no entanto, sabe-se que atualmente ela pertence a OMG (Object
Management Group). A OMG vem ao longo dos anos promovendo melhoria e
atualizações na UML e com isso desenvolvendo muitas especificações. É com base
nessas especificações, que as empresas desenvolvedoras de ferramentas de desenho de
UML confeccionam os seus softwares (MATOS, 2002, p. 103).
Em suma, para se criar uma ferramenta de desenho de UML, deve ser seguido
os padrões das especificações da OMG, entretanto cada ferramenta pode implementar
de forma diferente essas especificações.
Existem várias ferramentas de modelagem baseadas na UML no mercado, as
que apresentam um maior destaque são: O Rational Rose, o Enterprise Architect e o
ArgoUML (essa de código aberto). Esse trabalho irá abordar apenas sobre a ferramenta
Rational Rose, pois foi a ferramenta escolhida para desenvolver a modelagem desse
projeto. A preferência pelo Rational Rose, ocorreu por ser a ferramenta que foi
utilizada nas disciplinas de modelagem de sistema do curso e desta
54
forma, já se tinha um conhecimento prévio da mesma.

5.5.1. Rational Rose

O Rational Rose é uma ferramenta de desenho com base no conceito de modelo


de negócios. Para MATOS (2002, p. 105), isso significa dizer que o Rational Rose, “...
trata-se de uma ferramenta robusta, com o propósito de desenvolver soluções que
atendam às necessidades do negócio do cliente que vão desde uma simples solução
localizada até soluções complexas baseadas em ambientes distribuídos”.
Para desenvolver um modelo de negócios que atenda as necessidades do cliente,
não basta apenas criar um modelo de casos de uso, tendo em vista isso, o Rational
Rose dá suporte a criação de outros modelos, permitindo com isso, a visualização do
modelo de negócio por outras perspectivas.
O Rational Rose, segundo MATOS (2002, p. 105), encontra-se disponível no
mercado em três versões, são elas:
Rose Modeler: Não possui suporte de linguagens de programação;
Rose Professional: Possui suporte para apenas uma linguagem de
programação;
Rose Enterprise: Possui suporte para Visual C++, Visual Basic, Java e
Corba.
O Rational Rose v2002 (Professional) na versão trial de 15 dias, pode ser
adquirido através de download no site da própria empresa (www.rational.com) ou
utilizando-se de endereços de ftp‟s alternativos, tais como:
Na UFRGS: ftp://heuser.inf.ufrgs.br/pub/windows/CASEtools/Rose/
Na Unicamp: ftp://ftp.dca.fee.unicamp.br/pub/docs/ea977/RoseDemo.zip
A ferramenta Rational Rose pode ser visualizada na Figura 13:
55

FIGURA 13: A Ferramenta Rational Rose


Fonte (MATOS, 2002, p. 107)

Conforme demonstrado na Figura 13, o Rational Rose é composto dos seguintes


itens:
1) Barra de Ferramentas Padrão: Dispõem das ferramentas necessárias para a
modelagem de qualquer nível de visão, ou seja, um browser para todos sos
diagramas e um help sensitivo (esse sendo novidade em comparação a outras
ferramentas) (MATOS, 2002, p. 106).
2) Caixa de Ferramentas para cada diagrama: Na criação de novos diagramas,
surge um conjunto de ferramentas específicas daquele diagrama que podem ser
manipuladas pelo desenvolvedor para auxilia-lo na tarefa de criação do modelo.
3) Browser: É o responsável por gerenciar as cinco visões do Rational Rose. As
cinco visões que compõem essa ferramenta, segundo MATOS (2002, p. 106),
são:
Visão de caso de uso: Representa o diagrama de caso de uso ou modelo
de negócio;
Visão lógica: Refere-se aos diagramas de classe e objeto;
56
Visão de componentes: Representa os diagramas de componentes;
Visão de desenvolvimento: Referente ao diagrama de implantação;
Propriedades do Modelo: É referente as características gerais que vão
desde a estética do ambiente de desenvolvimento (cores, posicionamento
de janelas,...) até o código final desenvolvido;
4) Janela do diagrama: É a interface na qual o diagrama está sendo desenvolvido.

5.6. Conclusão

Nesse capítulo foi apresentada a descrição dos estudos realizados sobre os


conceitos e tecnologias que serão utilizadas na etapa de modelagem do trabalho
proposto. Esses estudos auxiliaram numa melhor compreensão dos diagramas da
UML, bem como no funcionamento da ferramenta Rational Rose facilitando a etapa
seguinte.
Através da disciplina de “análise de projetos e sistemas” ministrada na
graduação, pode-se obter alguns conhecimentos da análise orientada a objeto, os quais
foram muito úteis na descrição deste capítulo.
6. SISTEMA DE ATENDIMENTO CONVENCIONAL

O trabalho proposto tem como base modelar uma floricultura aliada a uma
telemensagem. Por ser dois assuntos distintos suas formas de funcionamento serão
explicadas separadamente. Primeiro será explicado o funcionamento da floricultura e
logo em seguida da telemensagem.

6.1. Funcionamento da Floricultura

Quando um cliente deseja comprar flores no sistema de atendimento


convencional, ele tem duas opções, quais sejam, comprar pelo telefone ou diretamente
na floricultura.
Nas compras de flores pelo telefone, o cliente geralmente já deverá saber o tipo
de flor que deseja. O cliente liga para a floricultura e informa o tipo de flor que deseja
para o atendente, este lhe dirá se a floricultura dispõe ou não de tais flores. Caso a
floricultura não possua as flores que o cliente está solicitando o atendente pergunta
para qual ocasião o cliente deseja comprar as flores e sugere outras opções para que
este possa fazer sua escolha. Durante a escolha das flores o cliente pergunta sobre o
preço e características destas. Após decidir-se por quais flores deseja comprar, o
cliente informa a quantidade. O atendente lhe passará o valor total à pagar e solicitará
alguns dados pessoais e outros referentes a entrega, finalizando a compra.
58
Na compra diretamente na floricultura, o cliente geralmente procura as flores
de sua preferência ou pede informações para o atendente. Encontrando as flores que
deseja, o cliente pergunta para o atendente o preço unitário e escolhe a quantidade que
irá comprar. Após ter escolhido a quantidade de flores desejada, o cliente dirigi-se ao
caixa. O funcionário pergunta sobre a forma de pagamento para o cliente, que
normalmente é realizada através de cheque, cartão de crédito ou à vista. Definida a
forma de pagamento, o funcionário pergunta ao cliente se ele já possui cadastro na
floricultura, informando-o das vantagens em envio de promoções para clientes
cadastrados. Caso não possua cadastro o cliente é convidado a cadastrar-se. Após o
cadastro, o atendente pergunta ao cliente se deseja que a floricultura faça a entrega do
seu pedido. Em caso positivo, o funcionário solicita os dados referentes a entrega
encerrando a compra.

6.2. Funcionamento da Telemensagem

Quando um cliente deseja enviar uma mensagem no sistema convencional, ele


liga para o serviço de telemensagens informando a ocasião ou a data comemorativa
para qual deseja o envio da mensagem. Nesse momento, um atendente irá dispor
algumas opções para que o cliente ouça e faça a escolha da mensagem mais adequada
para a ocasião. Feita a escolha da mensagem, o cliente solicita o preço e a forma de
cobrança da empresa. Caso o cliente aceite o preço, o atendente perguntará o telefone,
nome, data e horário para o qual será enviada a mensagem escolhida. Em seguida o
atendente solicita o nome e endereço para cobrança, finalizando a solicitação da
mensagem.
7. MODELAGEM DO PROJETO

Esse capítulo pretende vivenciar na prática os conceitos citados no capítulo 5.


Deste modo tem inicio fazendo uma breve descrição do sistema que esta sendo
modelado, a partir de então será abordado como foi feita a captura dos elementos do
modelo de negócio, os quais resultaram num diagrama de caso de uso.
Para visualizar as interações dos atores com o protótipo foi desenvolvido
diagramas de seqüência para cada caso de uso. Sendo que estes auxiliaram na
definição das informações referente ao banco de dados facilitando a criação do
diagrama de Entidade/Relacionamento. Encerrando o capítulo pode ser observado o
diagrama de classes, demonstrando as funções que serão implementadas no protótipo.

7.1. Uma Aplicação Web para Serviços pré-solicitados

Os serviços pré-solicitados são aqueles onde os clientes fazem a requisição de


produtos ou serviços e agendam a data, horário e local em que os mesmos serão
prestados e/ou entregues.
Sabe-se que grande parte do atendimento desse tipo de serviço é prestado via
telefone e isso acarreta uma série de problemas, conforme foi mencionado na
“definição do problema” deste trabalho.
Além das dificuldades mencionadas na “definição do problema”, sabe-se que o
atendimento dos serviços pré-solicitados quando realizados pelo telefone passam por
outras dificuldades, tais como, atendimento 24 horas, gastos com atendentes,
60
número insuficiente de linhas telefônicas, entre outros.
A dificuldade de atendimento 24 horas está associada aos horários dos
atendentes, que geralmente nesse tipo de serviço trabalham em média 6 horas por dia.
Para que se tenha um sistema de teleatendimento funcionando 24 horas por dia será
necessário que se faça pelo menos quatro turnos. Sabe-se que grande parte das
despesas da maioria das empresas encontra-se em recursos humanos, o ramo de
teleatendimento não é diferente dessa realidade, pois é composto geralmente de
empresas pequenas e com poucos recursos materiais, onde os funcionários são
responsáveis por executar a maioria das funções.
Se essas empresas resolvem ampliar sua capacidade de atendimento,
contratando mais atendentes, conseqüentemente estarão aumentando suas despesas,
não somente em folhas de pagamentos e encargos trabalhistas, mas também em
treinamentos.
O modelo que está sendo proposto visa tentar minimizar todos os problemas
apresentados. Esse modelo segue as tendências do mercado, mercado este que está se
voltando para a Internet, buscando deste modo descobrir novas formas de atender um
número maior de clientes, bem como, também fazer um marketing mais efetivo dos
produtos e/ou serviços de uma determinada empresa.

7.2. Capturando Elementos do Modelo de Negócios

Somente a descrição textual do funcionamento do sistema convencional não é


suficiente para modelar o protótipo que está sendo proposto, no entanto ela servirá de
base para as etapas de análise de requisitos e modelagem de caso de uso.
A etapa de análise de requisitos é utilizada para identificar os atores e suas
responsabilidades. Segundo MATOS (2002, p. 120), essa tarefa torna-se mais fácil
através de um quadro, conforme o Quadro 5, a seguir:
61

QUADRO 5: Análise de Requisitos


Atores Responsabilidades
Consultar flores e vasos;
Consultar mensagens;
Cliente Escolher ocasião;
Fazer cadastro;
Fazer pedido.
Gerenciar administrador;
Gerenciar categorias;
Gerenciar clientes;
Gerenciar forma de pagamento;
Administrador Gerenciar itens do pedido;
Gerenciar pedido;
Gerenciar produtos_serviços;
Gerenciar ocasião.
Validar Administrador

Depois de coletados os requisitos do sistema, cada requisito se transforma num


caso de uso conforme demonstrado na Figura 14, a seguir:

FIGURA 14: Diagrama de Caso de Uso do Sistema Proposto


62

7.3. Apresentando as Interações

O diagrama de caso de uso nos permitiu identificar os usuários do site, bem


como quais funções eles tem acesso. Entretanto, por ser fundamentado numa
modelagem estática, o diagrama de caso de uso não permite uma visualização das
interações dos atores com cada caso de uso. Para que essa interação possa ser
observada, surgiu a necessidade de desenvolver um diagrama de seqüência para cada
caso de uso. Os diagramas de seqüência são desenvolvidos a partir da descrição dos
cenários dos casos de uso. Baseado nisso, será abordado neste tópico a série de
cenários e respectivos diagramas de seqüência mostrados abaixo:
Cenário para consultar flores e vasos;
Cenário para consultar mensagens;
Cenário ocasião;
Cenário para fazer cadastro;
Cenário para fazer pedido;
Cenário para gerenciar produtos_serviços;
Cenário para gerenciar administrador;
Cenário para gerenciar clientes;
Cenário para gerenciar forma de pagamento;
Cenário para gerenciar itens do pedido;
Cenário para gerenciar pedido;
Cenário para gerenciar ocasião;
Cenário para Validar administrador.

7.3.1. Cenário para Consultar Flores e Vasos

O objetivo deste cenário é permitir que os clientes visualizem as flores e vasos


existentes no banco de dados produtos/serviço.
63

7.3.1.1. Fluxo Principal:

a) O cliente entra na página principal do site.


b) Clicar na página principal, no botão Flores e Vasos, o site abre uma página
chamada ocasião.
c) <<include>> ocasião
d) Após verificar a existência de produtos no banco de dados Produtos/serviço
para a ocasião escolhida, o site abre uma página mostrando as opções de flores
e vasos existentes, permitindo que o cliente faça sua escolha.
O diagrama de seqüência para o cenário “Consultar Flores e Vasos”, pode ser
visualizado na Figura 15, abaixo:

FIGURA 15: Diagrama de Seqüência Consultar Flores e Vasos

7.3.2. Cenário para Consultar Mensagens

O objetivo deste cenário é permitir que os clientes escutem as mensagens


existentes no banco de dados produto/serviço.
64

7.3.2.1. Fluxo Principal:

a) O cliente entra na página principal do site.


b) Clicar na página principal, no botão Ouvir Mensagens, o site abre uma página
chamada ocasião.
c) <<include>> ocasião.
d) Após verificar a existência de produtos no banco de dados Produtos/serviço
para a ocasião escolhida, o site exibe uma página mostrando as opções de
mensagens existentes para a ocasião escolhida, permitindo que o cliente escute-
as e escolha suas opções.
O diagrama de seqüência para o cenário “Consultar Mensagens”, pode ser
visualizado na Figura 16, abaixo:

FIGURA 16: Diagrama de Seqüência Consultar Mensagem

7.3.3. Cenário Ocasião

O objetivo deste cenário é permitir a escolha para qual ocasião, ou seja, data
comemorativa deverá ser dado o produto e/ou prestado o serviço.
65
Exemplos de ocasiões: Aniversário, dia dos pais, dia das mães, etc.

7.3.3.1. Fluxo Principal

a) Na Página Ocasião, o cliente escolhe a ocasião que deseja e clica no botão OK,
encerrando o use case.
O diagrama de seqüência para o cenário “Ocasião”, pode ser visualizado na
Figura 17, a seguir:

FIGURA 17: Diagrama de Seqüência Ocasião

7.3.4. Cenário para Fazer Cadastro

O objetivo deste cenário é permitir o cadastro de clientes do site, para agilizar


os próximos pedidos dos mesmos, bem como facilitar o envio de promoções.

7.3.4.1. Fluxo principal

a) Para se cadastrar o cliente clica no botão fazer cadastro na página validar


cliente.
b) O site abre uma página de cadastro de cliente.
c) O cliente preenche o formulário com seus dados e clica no botão Cadastrar.
d) Após o cliente clicar no botão Cadastrar, o site envia seus dados para o banco
de dados Cliente.
66

7.3.4.2. Fluxo Alternativo:

a) Após o cliente clicar no botão Cadastrar o site verifica se os campos do


formulário estão preenchidos corretamente, caso não estejam, o site envia uma
mensagem de erro para o cliente solicitando o preenchimento dos campos.
O diagrama de seqüência para o cenário “Fazer Cadastro”, pode ser visualizado
na Figura 18, a seguir:

FIGURA 18: Diagrama de Seqüência Fazer Cadastro

7.3.5. Cenário para Fazer Pedido

O objetivo deste cenário é permitir fazer com que o cliente encomende o


produto e/ou serviço que deseja.

7.3.5.1. Fluxo Principal:

a) Na página de consulta o cliente digita o código do produto que deseja e clica no


botão comprar.
67
b) O site abre a página validar cliente.
c) O cliente entra com seu login e senha cadastrados anteriormente e clica no
botão confirma dados.
d) O site abre a página de pedidos exibindo os dados do produto escolhido,
solicitando que o cliente preencha o campo quantidade pedida, bem como os
dados referentes à forma de pagamento.
e) O cliente preenche os dados mencionados no item anterior e clica no botão
continuar comprando.
f) O site abre a página dados de entrega pedido exibindo os dados da forma de
pagamento escolhida pelo cliente e solicitando o preenchimento do formulário
dados de entrega do pedido.
g) O cliente preenche os dados do formulário citado no item anterior e clica no
botão gerar relatório
h) O site abre uma página de relatório do pedido, para que possa ser impressa pelo
cliente.
O diagrama de seqüência para o cenário “Fazer Pedido”, pode ser visualizado
na Figura 19, a seguir:

FIGURA 19: Diagrama de Seqüência Fazer Pedido


68

7.3.6. Cenário para Gerenciar Produtos_serviços.

O objetivo deste cenário é permitir que o administrador possa realizar as


funções de consulta, inclusão, alteração e exclusão de produtos e/ou serviços
gerenciando assim essa base de dados.

7.3.6.1. Fluxo Principal:

a) A página principal do site mostra o Botão Administrador.


b) O administrador clica no Botão Administrador.
c) <<include>> O site abre a página validar administrador.
d) O site abre a página administração exibindo um menu de gerencias.
e) O administrador clica no botão gerenciar produtos.
f) O site abre a página de gerencia de produtos e/ou serviços.
O diagrama de seqüência para o cenário “Gerência de Produto e/ou Serviço”,
pode ser visualizado na Figura 20, logo em seguida:

FIGURA 20: Diagrama de Seqüência Gerência de Produtos e/ou Serviço

7.3.7. Cenário para Gerenciar Administrador.

O objetivo deste cenário é permitir que o administrador possa realizar as


funções de consulta, inclusão, alteração e exclusão na base de dados administrador,
gerenciando essa.
69

7.3.7.1. Fluxo Principal:

a) A página principal do site mostra o Botão Administrador.


b) O administrador clica no Botão Administrador.
c) <<include>> O site abre a página validar administrador.
d) O site abre a página administração exibindo um menu de gerências.
e) O administrador clica no botão gerenciar administrador.
f) O site abre a página “gerência administrador”.
O diagrama de seqüência para o cenário “Gerenciar Administrador”, pode ser
visualizado na Figura 21, logo em seguida:

FIGURA 21: Diagrama de Seqüência Gerenciar Administrador

7.3.8. Cenário para Gerenciar Categorias

O objetivo deste cenário é permitir que o administrador possa realizar as


funções de consulta, inclusão, alteração e exclusão na base de dados categoria,
gerenciando essa.

7.3.8.1. Fluxo Principal:

a) A página principal do site mostra o Botão Administrador.


b) O administrador clica no Botão Administrador.
c) <<include>> O site abre a página validar administrador.
70
d) O site abre a página administração exibindo um menu de gerências.
e) O administrador clica no botão gerenciar categorias.
f) O site abre a página gerenciar categorias.
O diagrama de seqüência para o cenário “Gerenciar de Categorias”, pode ser
visualizado na Figura 22, logo em seguida:

7.3.9. Cenário para Gerenciar Clientes.

O objetivo deste cenário é permitir que o administrador possa realizar as


funções de consulta, e exclusão na base de dados clientes, gerenciando essa.

7.3.9.1. Fluxo Principal:

a) A página principal do site mostra o Botão Administrador.


b) O administrador clica no Botão Administrador.
c) <<include>> O site abre a página validar administrador.
d) O site abre a página administração exibindo um menu de gerências.
e) O administrador clica no botão gerenciar clientes.
f) O site abre a página de gerência de clientes.
O diagrama de seqüência para o cenário “Gerenciar Clientes”, pode ser
visualizado na Figura 23, logo em seguida:

FIGURA 22: Diagrama de Seqüência Gerenciar Categorias


71

FIGURA 23: Diagrama de Seqüência Gerência Clientes

7.3.10. Cenário para Gerenciar Forma de Pagamento.

O objetivo deste cenário é permitir que o administrador possa realizar as


funções de consulta, incluão, alteração e exclusão na base de dados forma de
pagamento, gerenciando essa.

7.3.10.1. Fluxo Principal:

a) A página principal do site mostra o Botão Administrador.


b) O administrador clica no Botão Administrador.
c) <<include>> O site abre a página validar administrador.
d) O site abre a página administração exibindo um menu de gerências.
e) O administrador clica no botão gerenciar pagamento.
f) O site abre a página de gerenciar pagamento.
O diagrama de seqüência para o cenário “Gerenciar Forma de Pagamento”,
pode ser visualizado na Figura 24, logo em seguida:
72

FIGURA 24: Diagrama de Seqüência Gerenciar Forma de Pagamento

7.3.11. Cenário para Gerenciar Itens do Pedido.

O objetivo deste cenário é permitir que o administrador possa realizar as


funções de consulta, inclusão e exclusão na base de dados itens do pedido,
gerenciando essa.

7.3.11.1. Fluxo Principal:

a) A página principal do site mostra o Botão Administrador.


b) O administrador clica no Botão Administrador.
c) <<include>> O site abre a página validar administrador.
d) O site abre a página administração exibindo um menu de gerências.
e) O administrador clica no botão gerenciar itens do pedido.
f) O site abre a página de gerenciar itens do pedido.
O diagrama de seqüência para o cenário “Gerenciar Itens do Pedido”, pode ser
visualizado na Figura 25, logo em seguida:
73

FIGURA 25: Diagrama de Seqüência Gerenciar Itens do Pedido

7.3.12. Cenário para Gerenciar Pedido.

O objetivo deste cenário é permitir que o administrador possa realizar as


funções de consulta e exclusão na base de dados pedido, gerenciando essa.

7.3.12.1. Fluxo Principal:

a) A página principal do site mostra o Botão Administrador.


b) O administrador clica no Botão Administrador.
c) <<include>> O site abre a página validar administrador.
d) O site abre a página administração exibindo um menu de gerências.
e) O administrador clica no botão gerenciar pedido.
f) O site abre a página de gerenciar pedido.
O diagrama de seqüência para o cenário “Gerenciar Pedido”, pode ser
visualizado na Figura 26, logo em seguida:
74

FIGURA 26: Diagrama de Seqüência Gerenciar Pedido

7.3.13. Cenário para Gerenciar Ocasião .

O objetivo deste cenário é permitir que o administrador possa realizar as


funções de consulta, inclusão, alteração e exclusão na base de dados ocasião,
gerenciando essa.

7.3.13.1. Fluxo Principal:

a) A página principal do site mostra o Botão Administrador.


b) O administrador clica no Botão Administrador.
c) <<include>> O site abre a página validar administrador.
d) O site abre a página administração exibindo um menu de gerências.
e) O administrador clica no botão gerenciar pedido.
f) O site abre a página de gerenciar pedido.
O diagrama de seqüência para o cenário “Gerenciar Ocasião”, pode ser
visualizado na Figura 27, logo em seguida:
75

FIGURA 27: Diagrama de Seqüência Gerenciar Ocasião

7.3.14. Cenário para Validar Administrador

O objetivo deste cenário é permitir verificar se os dados do administrador são


válidos para que ele possa ter acesso ao site proposto.

7.3.14.1. Fluxo Principal:

a) Na página validar Administrador o site solicita ao administrador um login e


uma senha.
b) O administrador digita os seus dados e confirma os mesmos, pressionando o
botão Enviar Dados.
c) O site verifica os dados do administrador no banco de dados Administrador
para saber se são válidos. Se ambos forem válidos, o site reconhece o
administrador e finaliza o caso de uso.

7.3.14.2. Fluxo Alternativo:

a) O administrador pode sair da página "validar administrador", clicando no botão


cancelar, voltando para a página de principal do site.
b) Caso o administrador digite uma senha ou um login invalido e pressione no
botão OK o site mostrará uma página de Erro informando que a sua senha ou o
seu login é invalido.
76
O diagrama de seqüência para o cenário “Validar Administrador”, pode ser
visualizado na Figura 28, mostrada a seguir:

FIGURA 28: Diagrama de Seqüência Validar Administrador

7.4. Definição do Banco de Dados

Levando em consideração todas as informações levantadas nesse capítulo de


modelagem, procurou-se identificar os indivíduos e as interações para definir as
informações que permitem a definição de uma base de dados.
Os clientes podem ser definidos como qualquer pessoa que deseje realizar
uma consulta e/ou esteja interessada em fazer uma compra de flores e
vasos ou queira enviar uma mensagem.
Os administradores são os funcionários da empresa, os quais ficaram
responsáveis pela gerência do site.
Com base na definição dos indivíduos e suas interações identificou-se as
seguintes tabelas:
77

7.4.1. Clientes

Tabela responsável pelo armazenamento de informações referentes aos clientes


cadastrados na empresa. Essa tabela tem como intuito facilitar novas comprar do
cliente, bem como o envio de promoções para estes, por parte da empresa. Essa tabela
é composta dos seguintes campos:
Chave primária: CodigoCliente;
Atributos: NomeCliente, RGCliente, CPFCliente, LoginCliente, SenhaCliente,
EnderecoCliente, TelefoneCliente, EmailCliente, CidadeCliente, EstadoCliente,
CEPCliente.

7.4.2. Administrador

Essa tabela é responsável pelo armazenamento dos dados dos administradores


que terão acesso ao site. Ela é composta dos seguintes campos:
Chave primária: CodigoAdministrador;
Atributos: NomeAdministrador, LoginAdministrador, SenhaAdministrador.

7.4.3. Forma de Pagamento

Tabela responsável pelo armazenamento das formas de pagamento existentes no


site.
Chave primária: CodigoPagamento;
Atributos: FormaPagamento, TipoCartao, NumeroCartao.

7.4.4. Ocasião

Tabela responsável pelo armazenamento das ocasiões existentes no site.


Chave primária: CodigoOcasiao;
Atributos: TipoOcasiao.
78

7.4.5. Categoria

Tabela responsável pelo armazenamento das categorias existentes no site.


Chave primária: CodigoCategoria;
Atributos: NomeCategoria.

7.4.6. Produto_Serviço

Tabela responsável pelo armazenamento dos dados referentes aos


produtos_servicos, bem como da categoria e ocasião para a qual eles pertences. Possui
os seguintes campos.
Chave primária: CodigoProduto_servico;
Atributos: NomeProduto_servico, DescricaoProduto_servico, FotoProduto_servico,
SomProduto_servico, Disponibilidade, PrecoProduto_servico;
Chave estrangeira: CodigoOcasiao, CodigoCategoria.

7.4.7. Pedido

Tabela responsável pelo armazenamento dos pedidos dos clientes do site.


Chave primária: CodigoPedido;
Atributos: ValorPedido, NomeDestinatario, HorarioPedido, DataPedido ,
HorarioEntrega, DataEntrega , EnderecoEntrega, TelefoneEntrega, EmailEntrega,
CidadeEntrega, EstadoEntrega, CepEntrega, Proximidade.
Chave estrangeira: CodigoCliente, CodigoPagamento.

7.4.8. ItensPedido

Tabela responsável pelo armazenamento dos itens do pedido.


Chave primária: CodigoIntensPedido;
Atributos: Quantidade, ValorUnitario, ValorTotal.
Chave estrangeira: CodigoPedido, CodigoProduto_servico.
79
Com base nas tabelas referentes ao projeto, pode-se definir através da
ferramenta de modelagem de banco de dados Logic Works Erwin/ERX, o diagrama de
banco de dados mostra na Figura 29, a seguir:

FIGURA 29: Diagrama de Banco de Dados


80

7.5. Diagrama de Classes

Após identificar os indivíduos e suas interações, além das estruturas mínimas de


informações, restava apenas identificar as funções que farão parte do protótipo. Para
essa tarefa utilizou-se mais um diagrama da UML, que é o diagrama de classe, o qual é
mostrado na Figura 30, a seguir:

FIGURA 30: Diagrama de Classes do site


81

7.6. Conclusão

Apesar muitos profissionais da área de informática que trabalham no


desenvolvimento de sistemas não se importarem com a etapa de modelagem de
sistemas, chegando a ponto de suprimir de seus projetos essa etapa, nesse trabalho ela
foi de extrema importância.
Com a modelagem do trabalho proposto, pode-se identificar num primeiro
momento os indivíduos responsáveis por interagir com o protótipo, logo em seguida
foi modelada cada interação desses indivíduos as quais ajudaram na definição e
modelagem da base de dados a ser usada pelo protótipo.
Tendo em vista que todos os diagramas aqui apresentados foram
constantemente revisados e atualizados até se chegar num modelo que venha atender
as principais necessidades do protótipo, essa etapa ajudou a diminuir as dúvidas e o
tempo de desenvolvimento da etapa seguinte.
8. IMPLEMENTAÇÃO

O capítulo tem início fazendo um estudo de como deverá ser o Site a ser
implementado, a seguir é feita a criação do banco de dados, a próxima etapa é a
definição da estrutura das páginas. O capítulo se encerra com a implementação destas
páginas.
Cabe observar que nesse capítulo foi posto em prática todos os conhecimentos
estudados nos capítulos anteriores.

8.1. Concepção do Site

Encerrada a etapa de modelagem buscou-se através da análise dos estudos


realizados nessa etapa, determinar como deveria ser criado o site. Nessa análise surge
a necessidade de que o site tenha uma página inicial exibindo um menu com as
categorias de flores e vasos e envio de mensagens, além de uma opção que será usada
pelos administradores.
Cada categoria precisará de uma página para a exibição dos produtos e/ou
serviços. Como o site será composto de duas categorias, será necessário desenvolver
uma página para a categoria de flores e vasos e outra para a de mensagens.
Conforme abordado no capítulo de modelagem para que um cliente acesse uma
categoria ele deverá escolher uma determinada ocasião para a qual esta solicitando o
produto e/ou o serviço surgindo daí a necessidade de uma pagina de ocasiões.
O capítulo de modelagem demonstra também que cada administrador precisará
ser verificado antes de lhe permitir o acesso no site, desta forma, deverão ser criadas
duas páginas, sendo a primeira para o administrador entrar com os seus dados e a
83

segunda será uma página de erro, mostrada para ele no caso de dados incorretos.
Depois de validar o administrador, segundo os diagramas de seqüência, esse
será direcionado para a página de administração, deste modo à mesma deverá ser
desenvolvida para que isso ocorra. Analisando os diagramas de seqüência é possível
prever que na pagina deverá haver um menu para cada gerência permitindo assim o
acesso a estas.
Cada gerência que poderá ser acessada pelo administrador deverá ter uma
página exibindo os dados existentes no banco de dados juntamente com as opções de
alterar e excluir ao lado de cada dado. Como foi visto na etapa de modelagem existem
8 gerências, sendo assim, deverá ser desenvolvida 8 páginas referentes a estas.
Com base no estudo dos diagramas de seqüência “Fazer Cadastro” e “Fazer
Pedido”,observou-se que deverão ser criadas duas páginas para a realização dessas
tarefas.

8.2. Geração do Banco de Dados

Para a geração do Banco de Dados foi utilizado o Interbase, versão 6.0. A


criação das tabelas foram realizadas atráves de comandos SQL (Structured Query
Language), linguagem essa suportada pelo Interbase.
A seguir é apresentado como foi realizada a criação de domínios, tabelas,
generator’s e trigger’s no Interbase.

8.2.1. Criação de Domínios

A criação de domínios se deu pela necessidade de definição de tipos de dados


personalizados, baseado em tipos de dados já existentes. Segundo SILVA (2000, pg.
43) “Definir um domínio significa criar uma abstração de dados, uma vez que as
colunas definidas refletem quaisquer alterações realizadas sobre ele, sem que precisem
ser redefinidas”. Antes da criação propriamente dita das tabelas foram definidos os
seguintes domínios:
84

/* Domain D_CEP*/
Create Domain D_CEP as INTEGER;

/* Domain D_Cidade*/
Create Domain D_Cidade as Varchar (20);

/* Domain D_Codigo*/
Create Domain D_Codigo as Integer not null;

/* Domain D_Data*/
Create Domain D_Data as Date;

/* Domain D_Documentos*/
Create Domain D_Documentos as INTEGER;

/* Domain D_Email*/
Create Domain D_Email as Varchar (30);

/* Domain D_Endereco*/
Create Domain D_Endereco as Varchar (50);

/* Domain D_Estado*/
Create Domain D_Estado as Varchar (5);

/* Domain D_Hora*/
Create Domain D_Hora as Varchar (8);

/* Domain D_Login*/
Create Domain D_Login as Varchar (15) not null;

/* Domain D_Nome*/
Create Domain D_Nome as Varchar (30) not null;

/* Domain D_Senha*/
Create Domain D_Senha as Varchar (8) not null;

/* Domain D_Telefone*/
Create Domain D_Telefone as Integer;

/* Domain D_Valor*/
Create Domain D_Valor as Decimal(10,2);

/* Domain D_TextoLongo*/
Create Domain D_TextoLongo as Varchar (80);

O uso dos domínios evita erros na definição da base de dados, permitindo


unificar tipos de dados de maneira bem específica
85

8.2.2. Criação das Tabelas

Uma vez definida a base de dados na fase de modelagem, passou-se para a fase
da criação da base de dados. Os comandos SQL utilizados para a criação das tabelas
no Interbase foram os seguintes:
/* Table: Administrador */
Create Table Administrador
(
CodigoAdministrador D_Codigo,
NomeAdministrador D_Nome,
LoginAdministrador D_Login Not Null,
SenhaAdministrador D_Senha Not Null,
Primary Key (CodigoAdministrador)
);
/* Table: Categoria */
Create Table Categoria
(
CodigoCategoria D_Codigo,
NomeCategoria D_Nome,
Primary Key (CodigoCategoria)
);

/* Table: Cliente */
Create Table Cliente
(
CodigoCliente D_Codigo,
RGCliente D_Documentos Not Null,
NomeCliente D_Nome,
CPFCliente D_Documentos Not Null,
EnderecoCliente D_Endereco Not Null,
SenhaCliente D_Senha,
LoginCliente D_Login,
TelefoneCliente D_Telefone,
EmailCliente D_Email,
CidadeCliente D_Cidade,
EstadoCliente D_Estado,
CepCliente D_Cep,
Primary Key (CodigoCliente)
);

/* Table: Formapagamento */
Create Table Formapagamento(
CodigoPagamento D_Codigo,
FormaPagamento D_Nome,
Primary Key (CodigoPagamento)
);
86

/* Table: Itenspedido */
Create Table Itenspedido
(
CodigoItensPedido D_Codigo,
CodigoPedido D_Codigo,
CodigoProduto_Servico D_Codigo,
Quantidade Integer Not Null,
ValorUnitario D_Valor,
ValorTotal D_Valor,
Primary Key (CodigoItensPedido),
Foreign Key (CodigoPedido) References Pedido (Codigopedido)
on Update Cascade,
Foreign Key (CodigoProduto_Servico) References
Produto_Servico
(Codigoproduto_Servico) on Update Cascade
);

/* Table: Ocasiao*/
Create Table Ocasiao
(
CodigoOcasiao D_Codigo,
TipoOcasiao D_Nome,
Primary Key (CodigoOcasiao)
);

/* Table: Pedido */
Create Table Pedido
(
CodigoPedido D_Codigo,
CodigoCliente D_Codigo,
CodigoPagamento D_Codigo,
ValorPedido D_Valor,
DataEntrega D_Data Not Null,
DataPedido D_Data ,
Horapedido D_Hora,
HorarioEntrega D_Hora Not Null,
EnderecoEntrega D_Endereco Not Null,
TelefoneEntrega D_Telefone Not Null,
EmailEntrega D_Email Not Null,
Nomedestinatario D_Nome,
CidadeEntrega D_Cidade Not Null,
EstadoEntrega D_Estado,
CepEntrega D_Cep,
Proximidade Varchar (20),
Primary Key (CodigoPedido),
Foreign Key (CodigoPagamento) References FormaPagamento
(CodigoPagamento) on Update Cascade,
Foreign Key (CodigoCliente) References Cliente
(CodigoCliente) on Update Cascade
);
87

/* Table: Produto_Servico */
Create Table Produto_Servico
(
CodigoProduto_Servico D_Codigo,
CodigoOcasiao D_Codigo,
CodigoCategoria D_Codigo,
NomeProduto_Servico D_Nome,
DescricaoProduto_Servico D_Textolongo,
FotoProduto_Servico D_Textolongo,
SomProduto_Servico D_Textolongo,
Disponibilidade Char (10),
Precoproduto_Servico D_Valor,
Primary Key (CodigoProduto_Servico),
Foreign Key (CodigoCategoria) References Categoria
(CodigoCategoria),
Foreign Key (CodigoOcasiao) References Ocasiao
(CodigoOcasiao)
);

/* Table: Ocasiao*/
Create Table Ocasiao
(
CodigoOcasiao D_Codigo,
TipoOcasiao D_Nome,
Primary Key (CodigoOcasiao)
);

8.3.3. Criação dos Generator’s

Um generator em um banco de dados possui a função de criar um número


sequencial para ser usado em uma coluna de uma tabela, esse número sequencial é
normalmente utilizado para definição de chaves primárias. Segundo SILVA (2000, p.
255) “a criação dos generator’s é essencial para evitar chaves duplicadas em campos
que constituem chave primária”. Abaixo segue o código SQL utilizado para a criação
dos generator’s:
/*Generator Codigoadministrador_Gen*/
Create Generator CodigoAdministrador_Gen;

/*Generator Codigocategoria_Gen*/
Create Generator CodigoCategoria_Gen;
88

/*Generator Codigocliente_Gen*/
Create Generator CodigoCliente_Gen;

/*Generator CodigoItensPedido_Gen*/
Create Generator CodigoItensPedido_Gen;

/*Generator CodigoPagamento_Gen*/
Create Generator CodigoPagamento_Gen;

/*Generator CodigoPedido_Gen*/
Create Generator Codigopedido_Gen;

/*Generator CodigoProdutoservico_Gen*/
Create Generator CodigoProdutoservico_Gen;

/*Generator CodigoOcasiao_Gen*/
Create Generator CodigoOcasiao_Gen;

8.2.4. Criação dos Trigger’s

Os trigger’s ou gatilhos, segundo SILVA (2000, p. 131) “são automaticamente


acionados pelo banco de dados quando um usuário ou uma aplicação tenta realizar
uma operação de dados, isto é, quando executa uma instrução insert, update ou delete
em uma tabela”. No caso do Interbase, a definição do gatilho determina se ele será
executado antes ou depois das instruções de insert, update ou delete.
/* Triggers: ADMINISTRADOR*/
Set Term ^ ;
Create Trigger Codigoadministrador_Gen For Administrador
Active Before Insert Position 0
as
Begin
New.Codigoadministrador = Gen_Id(Codigoadministrador_Gen,1);
End
^Commit Work ^
Set Term ;^

/* Triggers: CATEGORIA*/
Set Term ^ ;
Create Trigger Codigocategoria_Gen For Categoria
Active Before Insert Position 0
as
Begin
New.Codigocategoria = Gen_Id(Codigocategoria_Gen,1);
End
^
89

Commit Work ^
Set Term ;^

/* Triggers: CLIENTE*/
Set Term ^ ;
Create Trigger Codigocliente_Gen For Cliente
Active Before Insert Position 0
as
Begin
New.Codigocliente = Gen_Id(Codigocliente_Gen,1);
End
^
Commit Work ^
Set Term ;^

/* Triggers: FORMAPAGAMENTO*/
Set Term ^ ;
Create Trigger Codigopagamento_Gen For FormaPagamentoActive
Before Insert Position 0
as
Begin
New.Codigopagamento = Gen_Id(Codigopagamento_Gen,1);
End
^
Commit Work ^
Set Term ;^

/* Triggers: ITENSPEDIDO*/
Set Term ^ ;
Create Trigger Codigoitenspedido_Gen For ItensPedido
Active Before Insert Position 0
as
Begin
New.Codigoitenspedido = Gen_Id(Codigoitenspedido_Gen,1);
End
^
Commit Work ^
Set Term ;^

/* Triggers: OCASIAO*/
Set Term ^ ;
Create Trigger Codigoocasiao_Gen For Ocasiao
Active Before Insert Position 0
as
Begin
New.Codigoocasiao = Gen_Id(Codigoocasiao_Gen,1);
End ^
Commit Work ^
Set Term ;^
90

/* Triggers: PEDIDO*/
Set Term ^ ;
Create Trigger Codigopedido_Gen For Pedido
Active Before Insert Position 0
as
Begin
New.Codigopedido = Gen_Id(Codigopedido_Gen,1);
End
^
Commit Work ^
Set Term ;^

/* Triggers: PRODUTO_SERVICO*/
Set Term ^ ;
Create Trigger Codigoprodutoservico_Gen For Produto_servico
Active Before Insert Position 0
as
Begin
New.Codigoproduto_servico =
Gen_Id(Codigoprodutoservico_Gen,1);
End
^
Commit Work ^
Set Term ;^

8.3. Definição da Estrutura

Para o desenvolvimento do projeto optou-se pela utilização de dois grupos


páginas distintas: O primeiro que será utilizado para consultas e comercialização dos
produtos e/ou serviços e o segundo que será utilizado pelos administradores do site.
Ambas as páginas, possuem praticamente o mesmo layout, sendo divididas em
dois frames. O frame superior é onde será exibido o menu de opções. O segundo frame
(inferior) será o responsável por mostrar o conteúdo dos menus.

8.3.1. Página de Consultas e Comercialização

Essa é a página principal do site que pode ser acessada tanto por clientes,
quanto por administradores. Ela possui um menu de botões no frame superior
constituído dos seguintes botões:
91

Consultar Flores e Vasos;


Consultar Mensagens;
Administrador.
Essa página pode ser visualizada na Figura 31, a seguir:

FIGURA 31: Página de consultas e comercialização

Os botões de consulta da página mostrada na Figura 31, tem a função de


direcionar o cliente para a categoria desejada restando para que ele faça a consulta
apenas a escolha da ocasião. Deste modo após clicar nos botões de consulta o cliente é
conduzido para a página de ocasião, pois a categoria é automaticamente definida.
A página ocasião é composta de um menu de ocasiões existentes na qual o
cliente escolhe a sua opção, selecionando a mesma e pressionando no botão “OK”.
Essa página pode ser visualizada na Figura 32, abaixo:
92

FIGURA 32: Página Ocasião

Escolhida a ocasião o cliente é direcionado para as páginas de consultas. As


páginas de consultas estão subdivididas nas duas categorias existentes no site. Essas
páginas são as responsáveis por apresentarem os produtos existentes no banco de
dados referentes as consultas de categoria e ocasião escolhidas anteriormente. A forma
como as consultas serão expostas na página podem ser visualizadas nas Figuras 33 e
34, a seguir:
93

FIGURA 33: Página Consulta Flores e Vasos

FIGURA 34: Página Consulta de Mensagens


94

Além de mostra o resultado das consultas para os clientes, para que esses
possam realizar as compras de produtos e/ou solicitar os serviços, foi inserido um
campo do tipo texto e um botão com o rótulo “comprar”, para que o cliente digite o
código do produto que deseja e pressione no botão confirmando que deseja comprar.
Despertado o interesse do cliente em efetuar uma compra esse é direcionado para a
página de verificação de clientes.

8.3.1.1. Páginas de Verificação de Clientes

Essa página tem por objetivo identificar se o cliente possui ou não cadastro no
site. É composta de dois campos do tipo texto para que os clientes cadastrados digitem
o login e a senha e através do botão “Confirmar Dados”, possam enviá-los para
verificação. Caso o cliente não possua cadastro, ele poderá fazê-lo através do botão
“Fazer Cadastro”. Em últimos casos, se o cliente não deseja fazer cadastro e não está
cadastrado, ele poderá clicar no link “voltar a página principal”, a qual encerra a
compra. Essa página pode ser vista na Figura 35 a seguir:

FIGURA 35: Página Verificação de Clientes


95

Caso o cliente tenha selecionado o botão “Fazer Cadastro”, ele será direcionado
para a página de cadastro de clientes mostrada na Figura 36, onde ele deverá preencher
todos os dados do formulário e clicar no botão “Incluir Cadastro”, para passar a etapa
seguinte.

FIGURA 36: Página Cadastro de Clientes

8.3.1.2. Fazer Pedido

Após a verificação do cliente, o mesmo será direcionado para uma página de


pedidos a qual exibira seu nome completo, os dados do produto e ou serviço escolhido,
bem como a quantidade, o valor unitário e o valor total da compra referente a um item.
No caso do cliente querer comprar mais de um item do mesmo produto, basta alterar o
valor da quantidade que automaticamente o valor total é recalculado. Logo a baixo
nessa mesma página constam os dados referentes a forma de pagamento, os quais
devem ser escolhidos pelo cliente com base nas opções oferecidas pelo site. Escolhida
a forma de pagamento o cliente deverá clicar no botão “Continuar comprando”. Essa
página é mostrada nas Figura 37 e 38, a seguir:
96

FIGURA 37: Página de Pedidos

FIGURA 38: Continuação da Página de Pedidos


97

Feito o pedido resta apenas que cliente forneça os dados de entrega. Esses dados
poderão ser digitados no formulário que é apresentado na página de entrega a qual
mostra inicialmente os dados da forma de pagamento escolhida pelo cliente para
conferência e logo abaixo o formulário de entrega.
Após preencher o formulário de entrega, o cliente deverá acionar o botão “gerar
relatório de pedido”.
A página de entrega poderá ser visualizada na Figura 39.

FIGURA 39: Página Dados de Entrega

A página de relatórios mostrada na Figura 40 poderá ser impressa pelo cliente,


servindo como comprovante de compra em caso de compra no cartão de crédito ou
como boleto bancário na escolha desta forma de pagamento.
98

FIGURA 40: Página de Relatório do Pedido

8.3.2. Página de administração

Essa página tem como objetivo organizar todas as gerências do site, permitindo
que de maneira rápida e simples o administrador acesse a gerência que deseja. Ela é
composta de um menu de gerências na frame superior contendo as 8 gerências
existentes no site. A frame inferior é responsável por exibir o conteúdo das gerências.
Essa página é mostrada na Figura 41, a seguir.
99

FIGURA 41: Página Administração

Para obter acesso a página de administração, o administrador deverá acessar a


página principal do site (ver tópico 8.3.1.) e escolher o botão “administrador”. Ao
escolher esse botão, o administrador é encaminhado para a página “Validar
Administrador”, onde deverá digitar um login e uma senha nos campos do tipo texto e
pressionando o botão “Entrar”. Essa página é mostrada na Figura 42, a seguir:
100

FIGURA 42: Página Validar Administrador

Caso algum dos dados do administrador esteja incorreto, ele será encaminhado
para a página de erro mostrada na Figura 43:

FIGURA 43: Página de Erro


101

8.3.2.1. As Páginas de Gerência

As páginas de gerência são 8 páginas praticamente idênticas, as quais são


divididas em dois frames. A frame superior possui um menu contendo os botões de
incluir e consultar referentes a cada gerência. A frame inferior exibe os dados existente
no banco de dados para cada gerência, além das opções excluir e alterar do lado
esquerdo de cad campo existente. Um exemplo de página de gerência pode ser
visualizado na Figura 44.

FIGURA 44: Página Gerência de Ocasiões

8.4. O Desenvolvimento das Páginas

Todas páginas foram desenvolvidas utilizando os recursos do editor de páginas


Front Page 2000 da Microsoft aliado as linguagens da Web citadas no capítulo
“Aplicações Web”.
As páginas de consulta e comercialização, bem como as páginas de
administração foram desenvolvidas apenas utilizando comandos da linguagem HTML
102

(HyperText Markup Language) fazendo uso das tags formatação de frames, imagens e
textos. Os códigos fontes desenvolvidos para criar as páginas “menuprincipal.html” e
“consultaprincipal.html” podem ser vistos nos Anexo A e B.
Para unir essas duas páginas, foi desenvolvido uma página de frame chamada
“principal.html”, a qual o código fonte é mostrado no Anexo C.
O código fonte das páginas “menuadministração.html” e “administração.html”
são semelhantes aos códigos já mostrados, portanto não há a necessidade de exibi-los.
Para desenvolver o código fonte das páginas “ocasiao.html” e
“validaradministrador.html”, foram utilizados tags HTML de formatação de figuras,
fontes e principalmente de formulário. O código fonte das respectivas páginas pode ser
visto nos Anexo D e E:

8.4.1. Desenvolvimento das Páginas de Gerência

As páginas de gerência foram desenvolvidas utilizando tags HTML de


formatação de frame, tabelas e textos. Mesclados as tags HTML, foram acrescentados
scripts ASP (Active Page Server), cuja função é estabelecer a conexão com o banco de
dados realizando consultas SQL (Structured Query Language) neste.
Como a estrutura das páginas de gerência são semelhantes (ver tópico “As
Páginas de Gerência”), serão apresentados somente os códigos fonte referentes a
página “gerenciarocasioes.html” os quais podem ser visto nos Anexo F, G e H.

8.4.2. Desenvolvimento das Páginas de Cadastro

As páginas de cadastro referentes as gerências e a página de clientes foram


desenvolvidas utilizando principalmente tags HTML de formulário e recursos da
linguagem JavaScript, conforme demonstra o código fonte do Anexo I.
Para que os dados preenchidos nos cadastros cheguem até o banco de dados, se
faz necessário uma página desenvolvida em ASP, servindo de caminho entre os
campos do cadastro e os campos da tabela no banco de dados. No caso da página
“cadastroclientes.html”, a página ASP que faz a interaligação com o banco de dados é
103

a página “Enviadados.asp”, cujo codigo fonte é mostrado no Anexo J.

8.4.3. Páginas para exibir consultas dos Clientes

As páginas utilizadas para exibir as consultas dos clientes foram desenvolvidas


com o uso de scripts ASP, os quais são úteis no resgate dos dados dos formulários das
páginas anteriores a elas, bem como na captura dos dados no banco de dados
referentes à consulta. Para formatar os dados resultantes das consultas realizadas no
banco de dados foram utilizados tags HTML de formatação de tabelas. Através do
código fonte da página “flores.asp”, no Anexo L, pode-se ter um exemplo desse tipo
de página.

8.5. Conclusão

Esse capítulo apresentou de que forma foi concebido o Site, como foi
desenvolvido o banco de dados no Interbase, como foi definida a estrutura das páginas
e encerrou abordando com foram implementadas essas páginas.
No transcorrer desse capítulo ocorreram algumas dificuldades referentes a
codificação dos scripts ASP, dificuldades essas que foram sanadas após consultas
bibliográficas e através do auxílio do orientador.
Com a conclusão desse capítulo pôde-se obter um resultado prático no trabalho
proposto confirmando os estudo realizados.
9. AMBIENTE DE TESTE

Os testes foram realizados no computador do acadêmico no decorrer de toda a


etapa de desenvolvimento. A realização destes testes foi possível somente após a
configuração das ferramentas: PWS (servidor Web) e Driver ODBC, as quais são
descritas neste capítulo.

9.1. Recursos Utilizados

Para a realização dos testes foram necessários alguns recursos. Como primeiro
recurso, foi utilizado o PWS (Personal Web Server), sua aplicação no projeto foi para
dar funcionalidade de servidor Web ao microcomputador no qual as páginas foram
testadas, facilitando assim a realização dos testes de funcionamento.
Como segundo recurso, foi utilizado o Interbase na versão 6.0 o qual serviu
para a criação da base de dados. Uma característica bastante considerável na escolha
deste SGDBR (Sistema Gerenciador de Banco Dados Relacional), foi o fato deste ser
gratuito, diminuindo assim os custos do protótipo. O programa de instalação do
Interbase pode ser baixado através da seguinte página: http://www.interbase.com.
Foi utilizado também o Driver ODBC para Interbase, Gemini Interbase ODBC
Driver 2.0, interligando os scripts ASP com o Interbase.
105

9.2. Configurando as aplicações ASP

Para podermos testar os arquivos de extensão “.asp”, devemos ter um servidor


web compatível instalado na máquina. No projeto proposto será utilizado o PWS
(Personal Web Server) para Windows 98, seu uso ocorre por ser compatível com o
ambiente desktop e por ser gratuito.
Primeiramente deve ser instalado o PWS, o qual é realizada de forma simple
como qualquer outro programa. Completada a instalação, o ícone do programa deverá
aparecer no canto direito da tela de seu computador e deverá estar ativado.
A função do PWS é permitir a criação de um diretório virtual onde estará sendo
salvo o projeto. Para a criação desse diretório foram seguidos os passo relatados
abaixo:
Foi dado um duplo clique no ícone do PWS;
Foi escolhida a opção “Avançado” e dentro desta a opção “Adicionar”;
É exibida uma tela solicitando as opções de pasta e Alias.
Na opção pasta foi colocado o diretório “F:\tcc\Implementação” e como
alias a opção “ASPTCC”, conforme mostra a Figura 45 a seguir.
Após a configuração, foi aberto o navegador Internet Explorer e digitado
o seguinte endereço http://localhost/asptcc/principal.html para acessar a
página principal do site.

FIGURA 45: Configurando o PWS

9.3. Configurando o Driver ODBC

Para trabalhar com ASP juntamente com o banco de dados Interbase 6.0,
106

precisa-se além de configurar PWS, configurar também o driver OBDC, o qual ira
criar uma interface entre essas duas tecnologias. Essa configuração é descrita abaixo:
Clique em iniciar, configurações, painel de controle;
Abra a Fonte de dados ODBC;
Selecione a Guia NFD de Usuários;
Clique em Adicionar;
Selecione a banco de Dados, no projeto esta sendo utilizado o Gemini
InterBase ODBC Driver 2.0 e pressione o botão concluir;
Preencha os campos mostrados abaixo:
Data Source Name: No projeto foi dado o nome de “conexaotcc”,
correspondente a um alias.
Database File: Corresponde ao diretório onde se encontra o arquivo
do banco de dados. No projeto foi digitado o “F:\tcc\bancotcc”
Default User Name: É o login que será utilizado para acessar o
Interbase. No projeto foi utilizado o login padrão Interbase 6.0,
SYSDBA.
Password: É a senha que será utilizada para acessar o Interbase.
Também foi utilizada a senha padrão do Interbase 6.0, Masterkey.
InterBase Version: Essa opção é utilizada para a escolha da versão do
Interbase que será utilizada, que no projeto proposto já vimos que é a
6.0.
Após preencher os dados pressione no botão “Test”, verificando se a
conexão foi efetuada com sucesso, depois pressione no botão “OK”
A tela de configuração do driver ODBC pode ser vista na Figura 46, a seguir:
107

FIGURA 46: Tela de Configuração do Driver ODBC


10. CONCLUSÃO

Sabe-se que ultimamente a maioria das pessoas não quer perder tempo, deste
modo, o atendimento de muitas empresas atualmente é realizado por telefone. O maior
problema dos teleatendimentos, ocorre normalmente quando muitas informações
precisam ser trocadas entre o atendente e o cliente. Isso acaba gerando despesas tanto
para o cliente, que terá que ficar muito tempo ao telefone, quanto para a empresa, que
poderia estar disponibilizando desse tempo para atender outros clientes.
A flexibilidade no horário de atendimento é outro ponto a ser levado em
consideração. As consultas à produtos e/ou serviços somente podem ser realizadas em
horários em que a empresa está funcionando. Normalmente os funcionários dessas
empresas cumprem turnos de 6 horas de trabalho. Para manter a empresa atendendo 24
horas por dia, seria necessário a criação de 4 turnos, levando a empresa a ter que
contratar mais funcionários, gerando deste modo mais despesas com salários, encargos
trabalhistas e treinamento.
A disponibilização dos serviços através das aplicações Web tendem a minimizar
os problemas citados anteriormente. O fato do atendimento passar a ser
disponibilizado na Internet, proporciona um marketing mais efetivo dessas empresas
junto aos seus clientes, permitindo-lhes uma percepção melhor dos produtos e/ou
serviços oferecidos por elas. Tendo em vista que através da Internet essas empresas
poderão aumentar o tempo de atendimento mantendo o mesmo quadro de funcionários,
realizando mais negócios a um custo menor.
109

Além disso, o uso da Internet não tornaria extinto o sistema de teleatendimento,


pois sabemos que muitos dos clientes desses serviços não possuem acesso a Internet,
desta forma o site seria mais um recurso para a empresa, visando aumentar a sua
receita.
Com base no trabalho realizado considermos que o uso das tecnologias, tiveram
um bom desempenho e que os objetivos principais do protótipo foram alcançados.
Os passos para a criação do protótipo foram os seguintes: realizaram-se
pesquisas sobre Internet, aplicações Web e serviços pré-solicitados, o resultado deste
estudo foi descrito nos diversos capítulos, servindo de base para a definição do
problema e das tecnologias adequada a serem utilizadas.
Foram realizados estudos com o objetivo de definir o banco de dados a ser
utilizado. Definido o banco de dados o sistema começou a ser modelado utilizando os
diagramas de a UML através da ferramenta Rational Rose.
Logo em seguida foi modelado e criado o banco de dados, através das
ferramentas Erwin para modelagem e IBConsole (Interbase 6.0) para criação.
Definida a base de dados partiu-se para a criação das páginas utilizando as
linguagens da Web, HTML, JavaScript e ASP e para realizar os experimentos e testes
foram criados a conexão com o driver ODBC e o diretório virtual no PWS.
As características referentes a utilização do Interbase que foram consideradas
importantes, está no fato de ser um SGBD (Sistema Gerenciador de Banco de Dados)
que permite que um número considerável de usuários acessem a mesma base de dados
de forma simultânea. Outras características relevantes são, a sua política de código
aberto e a facilidade de instalação.
A escolha da utilização da modelagem através da UML, ocorreu por já se ter
obtido conhecimento dessa notação na disciplina “análise de projeto de sistemas,
facilitando assim essa etapa.
A utilização das linguagens Web foram de extrema importância no
desenvolvimento das páginas.
110

As configurações do PWS (Personal Web Server) e do drive OBDC tornaram


possível o desenvolvimento e o experimento da aplicação em um micro computador
pessoal, sem a necessidade da disponibilidade de um servidor Web conectado a
Internet.
Sendo assim, os recursos utilizados mostraram-se adequados para o
desenvolvimento do protótipo para a aplicação Web.
Os testes foram realizados durante toda a etapa de implementação e
demonstraram que o protótipo cumpre os objetivos propostos, os quais eram de
desenvolver um site que fosse capaz de permitir aso clientes de empresas de
teleatendimento a realização de consultas a produtos e/ou serviços, bem como a
aquisição de produtos e/ou serviços.
No entanto temos conciência de que os testes foram realizados com base numa
empresa fictícia, para utilização por uma empresa seria necessário um período de
implantação e testes.
ANEXOS
ANEXO A

Código fonte da página “menuprincipal.html”


<html>
<head>
<title>menu</title>
</head>
<body bgcolor="#FFFF99" text="#000000">
<map name="FPMap0">
<area href="Ocasiao.htm" target="mainFrame" shape="polygon"
coords="3, 43, 3, 12, 10, 3, 134, 3, 144, 8, 143, 47, 1, 46,
6, 42">
<area href="OcasiaoMensagens.htm" target="mainFrame"
shape="polygon" coords="153, 47, 153, 12, 163, 2, 284, 3, 293,
13, 293, 46">
<area href="Validar.html" target="_top" coords="304, 47,
304, 17, 314, 8, 436, 8, 444, 15, 443, 47"
shape="polygon"></map><img border="0"
src="Figuras/menuprincipal.jpg" usemap="#FPMap0" width="445"
height="48">
</body>
</html>
ANEXO B

Código fonte da página “consultaprincipal.html”


<html>
<head><title>consultaprincipal</title></head>
<body bgcolor="#FFFFcc" text="#000000"
background="Figuras/FundoPrincipal.jpg">
<div align="center"><img src="Figuras/Floricultura.gif"
width="641" height="119" align="middle">
<p><img src="Figuras/Bar5.gif" width="600" height="7">
<div align="center">
<center>
<table border="0" width="75%">
<tr>
<td width="100%">
<p align="center">
<font face="Monotype Corsiva" size="5" color="#FF3300">
Nesse site voc&ecirc; poder&aacute; pesquisar os
pre&ccedil;os, escolher os produtos que deseja, agendar a data
e o local de entrega destes, da comodidade de sua casa ou
escrit&oacute;rio.
</font>
</p>
</td>
</tr>
</table>
</center>
</div>
<p><img src="Figuras/Bar5.gif" width="600" height="7"></p>
<p><a href="mailto:claudimg51@homail.com">
<img src="Figuras/e-mail.gif" width="92" height="44">
</a></p>
</div>
</body>
</html>
ANEXO C

Código fonte da página “principal.html”


<html>
<head>
<title>Principal</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>
<frameset cols="80" frameborder="0" border="0"
framespacing="0">
<frameset rows="50,*" frameborder="0" border="0"
framespacing="0">
<frameset frameborder="0" border="0" framespacing="0"
cols="*">
<frame name="topFrame" noresize scrolling="NO"
src="Menuprincipal.html">
<frameset frameborder="0" border="0" framespacing="0"
cols="*">
<frame name="mainFrame" src="consultaprincipal.html">
</frameset>
</frameset>
</frameset>
</frameset>
</html>
ANEXO D

Código fonte da página “ocasiao.html”


<html>
<head>
<meta http-equiv="Content-Language" content="pt-br">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>PÁGINA OCASIÃO</title>
</head>
<body bgcolor="#FFFFCC"
background="Figuras/FundoPrincipal.jpg" text="#FF0000">
<p align="center"><img src="Figuras/Paginaocasiao.gif"
width="600" height="62"></p>
<p align="center"><img src="Figuras/Bar5.gif" width="600"
height="7"></p>
<form method="POST" name="Form" action="Flores.asp">
<input type="hidden" name="codigocategoria" value=1>
<center>
<table width="75%" border="0" align="center">
<tr>
<td>
<div align="center"><b><font size="+1">
Escolha uma data comemorativa para a qual deseja
</font></b><font size="+1"><b>comprar o produto ou solicitar o
serviço</b></font></div>
</td>
</tr>
</table>
<p><b>Ocasi&otilde;es existentes: </b>
<select name="codigoocasiao" size="1">
<option value="1">Dia dos Pais</option>
<option value="2">Dia das M&atilde;es</option>
<option value="3">Formatura</option>
<option value="4">Casamento</option>
<option value="5">Anivers&aacute;rio</option>
<option value="6">Dia dos Namorados</option>
</select>
</p>
</center>
<p align="center">
<input type="submit" value="OK" name="ocasiao"
style="background-color: #66CCFF; border-style: solid; border-
color: #000080" >
</p>
</form>
<div align="center">
<p><img src="Figuras/Bar5.gif" width="600" height="7"></p>
<p><a href="principal.html" target="_top"><img border="0"
src="Figuras/setaesquerda.GIF" width="54" height="53"></a></p>
</div>
</body>
</html>
ANEXO E

Código fonte da página “validaradministrador.html”


<html>
<head>
<title>Validar Administrador</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000"
background="Figuras/FundoPrincipal.jpg">
<div align="center">
<p><img src="Figuras/Validar.gif" width="600" height="58"></p>
<p><img src="Figuras/Bar5.gif" width="600" height="7"></p>
<form name="FormValidarAdministrador" method="post"
action="Paginavalidacao.asp">
<table width="532" border="0">
<tr>
<td width="190"><b>Dígite seu login de usu&aacute;rio:</b>
</td>
<td width="328">
<input type="text" name="loginAdministrador" size="30"
value="" maxlength="20">
</td>
</tr>
<tr>
<td width="190">&nbsp;</td>
<td width="328">&nbsp;</td>
</tr>
<tr>
<td width="190"><b>Dígite sua senha: </b>
</td>
<td width="328">
<input type="password" name="SenhaAdministrador" size="20"
maxlength="8">
</td>
</tr>
<tr>
<td width="190"> &nbsp;</td>
<td width="328"> &nbsp;</td>
</tr>
<tr>
<td width="190"> &nbsp;</td>
<td valign="bottom" width="328">
<input type="submit" name="Entrar" value="Entrar"
style="float: left; background-color: #00FFFF; border-style:
solid; border-color: #000080">
<a href="principal.html" target="_parent"><img border="0"
src="Figuras/botaocancelar.jpg" align="absbottom" width="81"
height="24"></a>
<input type="reset" name="LimpaDados" value="Limpar Dados"
style="background-color: #00FFFF; border-style: solid; border-
color: #000080; background-position: top 50%">
</td>
</tr>
</table>
</form>
<p>&nbsp;</p>
<p><img src="Figuras/Bar5.gif" width="600" height="7"></p>
</div>
</body>
</html>
ANEXO F

Código fonte da página “gerenciarocasioes.html”.


<html>
<head>
<title>gerencia ocasiões</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>
<frameset rows="65,*" frameborder="0" border="0"
framespacing="0">
<frameset frameborder="0" border="0" framespacing="0"
cols="*">
<frame name="topFrame" scrolling="NO" noresize
src="menuocasiao.htm" >
<frameset frameborder="0" border="0" framespacing="0"
cols="*">
<frame name="menucategoria" src="consultarocasiao.asp"
noresize target="menucategoria">
</frameset>
</frameset>
</html>
ANEXO G

Código fonte que representa a página “menuocasiao.htm”


<html>
<head>
<title>Menucategoria</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<base target="menucategoria">
</head>

<body bgcolor="#FFFF99" text="#000000"


background="Figuras/FundoPrincipal.jpg">
<p><map name="FPMap0">
<area href="incluirocasiao.htm" target="menucategoria"
coords="1, 49, 1, 3, 108, 1, 113, 6, 113, 7, 113, 46, 111, 51,
4, 51, 4, 46, 4, 47" shape="polygon"
target="menucategoria"></map><img border="0"
src="Figuras/Incluirocasiao.bmp" usemap="#FPMap0" width="114"
height="52">&nbsp;
<map name="FPMap1">
<area href="consultarocasiao.asp" target="menucategoria"
shape="polygon" coords="1, 50, 1, 4, 5, 0, 109, 2, 113, 8,
111, 51"></map><img border="0"
src="Figuras/consultarocasiao.bmp" usemap="#FPMap1"
width="114" height="52"></p>
</body>
</html>
ANEXO H

Código fonte que representa a página de “consultaocasiao.asp”


<HTML>
<HEAD>
<TITLE>Consulta Ocasião</TITLE>
<base target="menucategoria">
</HEAD>
<BODY background="Figuras/FundoPrincipal.jpg"
bgcolor="#FFFF99">
<H2 align="center">As ocasi&otilde;es existentes est&atilde;o
mostradas abaixo:</H2>
<center><img src="Figuras/Bar5.gif" width="600" height="7">
</center><H2 align="center">
<%
dim cnn, rs
set cnn = Server.CreateObject ("ADODB.Connection")
cnn.open ("Driver={Easysoft IB6
ODBC};Pwd=masterkey;Uid=sysdba;database=f:\tcc\Bancotcc")
set rs = CreateObject("ADODB.RecordSet")
Set rs.ActiveConnection = cnn
rs.open "Select * From ocasiao"
%>
</H2>
<TABLE BORDER="1" align="center" bgcolor="#000000" >
<TR bgcolor="#CCCCCC">
<TD><b>Excluir</b></TD>
<TD><b>Alterar</b></TD>
<TD><b><STRONG>Código Ocasi&atilde;o</STRONG></b></TD>
<TD><b><STRONG>Tipo Ocasi&atilde;o</STRONG></b></TD>
</TR>
<%
WHILE not rs.eof
%>
<div align="center">
<TR bgcolor="#009999">
<td>
<div align="center"><a
href="Confirmaocasiao.asp?codigoocasiao=<%=rs("codigoocasiao")
%>&opc=E&tipoocasiao=<%=rs("tipoocasiao")%>"
targert="menucategoria" target="_self"><b><font size="+3"
face="Arial">X</font></b></a>
</div>
<TD>
<div align="center"><a
href="Alteracaoocasiao.asp?codigoocasiao=<%=rs("codigoocasiao"
)%>" target="_self"><font size="6"><b><font
face="Arial">A</font></b></font></a></div>
</TD>
<TD>
<% Response.Write rs("codigoocasiao")%>
</TD>
<TD>
<% Response.Write rs("Tipoocasiao")%>
</TD>
</TR>
</div>
<%
rs.movenext
wend
Set rs= Nothing
%>
</TABLE>
<P>
<center><img src="Figuras/Bar5.gif" width="600"
height="7"></center><p>
<center>
<a href="principal.html" target="_top">Voltar a pagina
principal do site</a>
</center>
</BODY>
</HTML>
ANEXO I

Código fonte cadastro de clientes


<html>
<head>
<meta http-equiv="Content-Language" content="pt-br">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>cadastro de clientes</title>
<script language="JavaScript">
<!--
function Alerta()
{
if (document.FormCliente.Nomecliente.value == "")
{
alert (" Preencher o campo com o seu nome completo !");
return false;
}
else
if (document.FormCliente.RGcliente.value == "")
{
alert (" Preencher o campo com o seu RG !");
return false;
}
else
if (document.FormCliente.cpfcliente.value == "")
{
alert (" Preencher o campo com o seu CPF !");
return false;
}
else
if (document.FormCliente.logincliente.value == "")
{
alert (" Preencher o campo com um login !");
return false;
}
else
if (document.FormCliente.senhacliente.value == "")
{
alert (" Preencher o campo com uma senha !");
return false;
}
else
if (document.FormCliente.enderecocliente.value == "")
{
alert (" Preencher o campo com seu endereço !");
return false;
}
else
if (document.FormCliente.Telefonecliente.value == "")
{
alert (" Preencher o campo com seu telefone !");
return false;
}
else
if (document.FormCliente.Cidadecliente.value == "")
{
alert (" Preencher o campo com o nome de sua cidade !");
return false;
}
else
{
document.FormCliente.action = "Enviadados.asp";
return true;
}
}
//-->
</script>
</head>
<body background="Figuras/FundoPrincipal.jpg">
<p align="center"><b><font size="6">Cadastro de
Clientes</font></b></p>
<p align="center"><img border="0" src="Figuras/Bar5.gif"></p>
<form method="POST" name="FormCliente" onsubmit="return
Alerta()" action="--WEBBOT-SELF--">
<input type="hidden" name="numerocartao" >
<input type="hidden" name="codigoproduto"
value="<%=codigoproduto%>">
<input type="hidden" name="codigocliente"
value="<%=codigocliente%>">
<input type="hidden" name="nomecliente"
value="<%=nomecliente%>">
<div align="center">
<center>
<table border="0" width="80%">
<tr>
<td width="49%"><b>Digite seu nome completo:</b></td>
<td width="68%"><!--webbot bot="Validation" B-Value-
Required="TRUE"
I-Maximum-Length="20" --><input type="text" name="Nomecliente"
size="48" maxlength="20"></td>
</tr>
<tr>
<td width="49%"><b>Digite o nº do seu RG :</b></td>
<td width="68%"><!--webbot bot="Validation" B-Value-
Required="TRUE"
I-Maximum-Length="10" --><input type="text" name="RGcliente"
size="19" maxlength="10">
(Exemplo: 3825682)</td>
</tr>
<tr>
<td width="49%"><b>Digite o nº do seu CPF :</b></td>
<td width="68%"><!--webbot bot="Validation" B-Value-
Required="TRUE"
I-Maximum-Length="14" --><input type="text" name="cpfcliente"
size="19" maxlength="14">
(Exemplo: 022438439-27)</td>
</tr>
<tr>
<td width="49%"><b>Digite um nome de usuário:</b></td>
<td width="68%"><!--webbot bot="Validation" S-Data-
Type="String"
B-Allow-Letters="TRUE" B-Allow-Digits="TRUE" B-Value-
Required="TRUE"
I-Maximum-Length="20" --><input type="text"
name="logincliente" size="20" maxlength="20"> &nbsp;</td>
</tr>
<tr>
<td width="49%"><b>Digite uma senha:</b></td>
<td width="68%"><!--webbot bot="Validation" S-Data-
Type="String"
B-Allow-Letters="TRUE" B-Allow-Digits="TRUE" B-Value-
Required="TRUE"
I-Minimum-Length="6" I-Maximum-Length="8" --><input
type="password" name="senhacliente" size="20" maxlength="8">
&nbsp;</td>
</tr>
<tr>
<td width="49%"><b>Digite seu endereço:</b></td>
<td width="68%"><!--webbot bot="Validation" B-Value-
Required="TRUE"
I-Maximum-Length="20" --><input type="text"
name="enderecocliente" size="49" maxlength="20"> </td>
</tr>
<tr>
<td width="49%"><b>Digite seu Telefone :</b></td>
<td width="68%"><!--webbot bot="Validation" S-Data-
Type="Integer"
S-Number-Separators="x" B-Value-Required="TRUE" I-Minimum-
Length="7"
I-Maximum-Length="10" --><input type="text"
name="Telefonecliente" size="20" maxlength="10">(Exemplo:
2223093)</td>
</tr>
<tr>
<td width="49%"><b>Digite um endereço de&nbsp;
<br>E-mail :</b></p>
</td>
<td width="68%"><input type="text" name="emailcliente"
size="42">
<br>(Exemplo: ana@bol.com.br)</td>
</tr>
<tr>
<td width="49%"><b>Digite o nome de sua Cidade:</b></td>
<td width="68%"><input type="text" name="Cidadecliente"
size="20"></td>
</tr>
<tr>
<td width="49%"><b>Escolha o Estado onde mora:</b></td>
<td width="68%"><select size="1" name="estadocliente">
<option selected value="SC">SC</option>
<option value="PR">PR</option>
<option value="RS">RS</option>
&nbsp;
</select></td>
</tr>
<tr>
<td width="49%"><b>Digite seu CEP:</b></td>
<td width="68%"><!--webbot bot="Validation" S-Data-
Type="Integer"
S-Number-Separators="x" B-Value-Required="TRUE" I-Maximum-
Length="8" --><input type="text" name="cepcliente" size="20"
maxlength="8">(Exemplo:
88504210)</td>
</tr>
</table>
</center>
</div>
<p align="center"><img border="0" src="Figuras/Bar5.gif"></p>
<p align="center"><input type="submit" value="Incluir
cadastro" name="continuar comprar" style="background-color:
#00FFFF; border-style: solid; border-color: #000080"><input
type="reset" value="Limpar Dados" name="LimparDados"
style="background-color: #00FFFF; border-style: solid; border-
color: #000080"></p>
</form>
</body>
</html>
ANEXO J

Código fonte da página “Enviadados.asp”


<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Nova pagina 1</title>
</head>
<body background="Figuras/FundoPrincipal.jpg"
bgcolor="#FFFF99">
<center><h3>Confirma cadastro de clientes</h3><p>
<h4>seus dados foram cadastrados com sucesso !!!</h4></center>
<%
nomecliente = request.form ("nomecliente")
rgcliente = request.form ("rgcliente")
cpfcliente = request.form ("nomecliente")
logincliente = request.form ("logincliente")
senhacliente = request.form ("senhacliente")
enderecocliente = request.form ("enderecocliente")
telefonecliente = request.form ("telefonecliente")
emailcliente = request.form ("emaicliente")
cidadecliente = request.form ("cidadecliente")
Estadocliente = request.form ("estadocliente")
cepcliente = request.form ("cepcliente")
dim cnn, rs, str
set cnn = Server.CreateObject ("ADODB.Connection")
cnn.open ("Driver={Easysoft IB6
ODBC};Pwd=masterkey;Uid=sysdba;database=f:\tcc\Bancotcc")
set rs = CreateObject("ADODB.RecordSet")
Set rs.ActiveConnection = cnn
str "INSERT INTO cliente (nomecliente, rgcliente, cpfcliente,
logincliente, senhacliente, enderecocliente, telefonecliente,
emailcliente, cidadecliente, estadocliente, cepcliente) VALUES
('"&nomecliente&"', '"&rgcliente&"', '"&cpfcliente&"',
'"&logincliente&"', '"&senhacliente&"', '"&enderecocliente&"',
'"&telefonecliente&"', '"&emailcliente&"',
'"&cidadecliente&"', '"&estadocliente&"', '"&cepcliente&"')"
rs.open (str)
set rs= nothing
%>
<table width="483">
<tr>
<td width="179">Nome do cliente: </td>
<td width="290">
<!--webbot bot="Validation" S-Data-Type="String" B-Allow-
Letters="TRUE"
B-Allow-WhiteSpace="TRUE" -->
<input type="text" name="formapagamento" size="40"
value="<%=nomecliente%>" readonly>
</td>
</tr>
<tr>
<td width="179">Numero do RG: </td>
<td width="290">
<input type="text" name="rgcliente" size="40"
value="<%=rgcliente%>" readonly>
</td>
</tr>
<tr>
<td width="179">Numero do CPF: </td>
<td width="290">
<input type="text" name="cpfcliente" size="40"
value="<%=cpfcliente%>" readonly>
</td>
</tr>
<tr>
<td width="179">login: </td>
<td width="290">
<input type="text" name="logincliente" size="40"
value="<%=logincliente%>" readonly>
</td>
</tr>
<tr>
<td width="179">Seu endereço: </td>
<td width="290">
<input type="text" name="enderecocliente" size="40"
value="<%=enderecocliente%>" readonly>
</td>
</tr>
<tr>
<td width="179">Seu telefone: </td>
<td width="290">
<input type="text" name="telefonecliente" size="40"
value="<%=telefonecliente%>" readonly>
</td>
</tr>
<tr>
<td width="179">Email : </td>
<td width="290">
<input type="text" name="emailcliente" size="40"
value="<%=emailogincliente%>" readonly>
</td>
</tr>
<tr>
<td width="179">Cidade do cliente: </td>
<td width="290">
<input type="text" name="cidadecliente" size="40"
value="<%=cidadecliente%>" readonly>
</td>
</tr>
<tr>
<td width="179">Estado do cliente: </td>
<td width="290">
<input type="text" name="estadocliente" size="40"
value="<%=telefonecliente%>" readonly>
</td>
</tr>
<tr>
<td width="179">Numero do CEP: </td>
<td width="290">
<input type="text" name="cepcliente" size="40"
value="<%=cepcliente%>" readonly>
</td>
</tr>
</table>
<p align="center"><A HREF="verificaclientes.asp"
target="_self">voltar para a página de verificação</A> </p>
<center>
<p>
</center>
</body>
</html>
ANEXO L

Código da página “Flores.asp”


<html>
<head>
<title>Flores &amp; Vasos</title>
</head>
<body bgcolor="#FFFFCC"
background="Figuras/FundoPrincipal.jpg" text="#FF0000">
<SCRIPT LANGUAGE=JAVASCRIPT>
<!--
function Alerta()
{
if (document.FrmIncPedido.codigoproduto.value == "")
{
alert (" Preencha o campo com o código do produto desejado
!");
return false;
}
else
{
document.FrmIncPedido.action = "verificaclientes.asp";
return true;
}
}
/-->
</script>
<center>
<p><img src="Figuras/Flores e vasos.gif" width="536"
height="42" border="0" align="middle"></p>
<p><img src="Figuras/Bar5.gif" width="575" height="7"> </p>
</center>
<p>
<%
'***** cria variáveis *****
dim cnn, rs, str
'***** cria variáveis *****
'***** recupera dados do formulario *****
codigoocasiao = Request.form ("codigoocasiao")
codigocategoria = Request.form ("codigocategoria")
'***** recupera dados do formulario *****
set cnn = Server.CreateObject ("ADODB.Connection"
cnn.open ("Driver={Easysoft IB6
ODBC};Pwd=masterkey;Uid=sysdba;database=f:\tcc\Bancotcc")
set rs = CreateObject("ADODB.RecordSet")
Set rs.ActiveConnection = cnn
str = "Select * From Produto_Servico Where
(produto_servico.Codigoocasiao) ="
str = str & codigoocasiao
str = str & " and "
str = str & "(produto_servico.Codigocategoria) ="
str = str & codigocategoria
'str = str & " and "
'str = str & "(produto_servico.disponibilidade) ="
'srt = str & "('&emfalta&')"
rs.open str
'response.write "Select * From Produto_Servico Where
(produto_servico.Codigoocasiao) =" & Request.form
("codigoocasiao") & " and (produto_servico.Codigocategoria) ="
& Request.form ("codigocategoria")
while not rs.eof %>
<center>
<table border="0" width="349">
<tr>
<td width="157" height="21"><b>C&oacute;digo do
Produto:</b></td>
<td width="178">
<font color="#0000FF">
<b>
<%response.write rs ("codigoproduto_servico")%>
</b>
</font>
</td>
</tr>
<tr>
<td width="157" height="21"><b>Nome do Produto:</b></td>
<td width="178">
<%response.write rs ("nome_produto_servico")%>
</td>
</tr>
<tr>
<td width="157" height="21"><b>Descrição do Produto:</b></td>
<td width="178">
<%response.write rs ("descricaoproduto_servico")%>
</td>
</tr>
<tr>
<td width="157" height="21">
<p align="center"><img border="0" src="Figuras/Fotos.gif"
width="64" height="44" alt="foto do produto" align="left"></p>
<td width="178">
<img border="2" src="Flores/<%response.write rs
("fotoproduto_servico")%>" width="124" height="104">
</td>
<tr>
<td width="157" height="21"><b>Disponibilidade:</b></td>
<td width="178">
<%response.write rs ("disponibilidade")%>
</td>
</tr>
<tr>
<td width="157" height="21"><b>Preço do Produto:</b></td>
<td width="178">
R$ <%response.write rs ("precoproduto_servico")%>,00
</td>
</tr>
</table>
</center>
<p align="center"><img src="Figuras/Bar5.gif" width="575"
height="7"></p>
<p>
<%rs.movenext
wend
rs.close
cnn.close
Set rs= Nothing
Set cnn= Nothing%>
<center>
<form name="FrmIncPedido" Method="Post" onsubmit="return
Alerta()">
<b>Digite o Código do produto que deseja comprar:</b><input
type="text" name="codigoproduto"><p>
<input type="Submit" name="FazerPedido" value="comprar"
width="75%" height="75%" style="background-color: #00FFFF;
border-style: solid; border-color: #000080">
</form></center>
</body>
</html>
REFERÊNCIAS BIBLIOGRÁFICAS

ALBUQUERQUE, Fernando. TCP/IP Internet: Programação de Sistemas


Distribuídos HTML, JavaScript e Java. Rio de Janeiro: Axcel Books do Brasil
Editora, 2001.

BOOCH, Grady.; RUMBAUGH, James.; JACOBSON, Ivan. UML: Guia do Usuário.


Rio de Janeiro: Campus, 2000, 472 p.

DATE, C. J. Introdução a Sistemas de Banco de Dados. Rio de Janeiro: Campus,


2000.

FATEC-SP. Sistemas Gerenciadores de Banco de Dados SGBD. Disponível em:


<http://www.geocities.com/fatecinfo/inf06002.htm> Acessado em: 28 – Jul – 2002.

FEDERLE, Luciane. Uma Aplicação Via Web Para o Serviço de Proteção ao


Crédito – SPC. 2000. 70 p. Relatório de Trabalho de Conclusão de Curso
(Bacharelado em Informática) - Departamento de Ciências Exatas e Tecnológicas,
Universidade do Planalto Catarinense, Lages. CD-ROM.

FOWLER, Martin. UML Essencial: Um Breve Guia Para a Linguagem-padrão de


Modelagem de Objetos. 2. ed. Porto Alegre: Bookman, 2000, 169 p.

FURLAN, José Davi. Modelagem de Objetos Através da UML: The Unified


Modeling Language. São Paulo: Makron Books, 1998. 329 p.

HEUSER, Carlos Alberto. Projeto de Banco de dados. Porto Alegre: Instituto de


Informática da UFRGS: Sagra Luzzatto, 2001.

LIRA, Renato. Crie Sites Dinâmicos: Tutorial ASP. The WebMasters, Rio de Janeiro:
N.3, p.14-21.

MATOS, Alexandre Veloso de. UML: Prático e Descomplicado. São Paulo: Érica,
2002. 187 p.

MAZZOLA, Vitório Bruno. Internet e Intranets. 1999. 250 p. Dissertação de Pós-


Graduação em Redes de Computadores. Departamento de Informática e de Estatística
Universidade do Estado de Santa Catarina, Joinville.

PAES, Edson Roberto S. Introdução e Conceitos Gerais de Banco de Dados.


Disponível em: <http://www.uniplac.net/Disciplina/IBD/index.htm> Acessado em: 16-
Jul-2002.
135

PUC-RIO/CCE. Curso Redes de Computadores: Internet e Arquitetura TCP/IP [e-


mail de Gustavo Corso]. Endereço eletrônico: gustavo@iscc.com.br.

RODRIGUES, Anderson Haertel. Apostila de Interbase 6.0: Acesso Nativo com o


Interbase Express “IBX” [e-mail de Gefferson Machado Ribeiro]. Endereço eletrônico:
gmribeiro@aol.com.br.

RON, White. Como Funciona o Computador III/Ilustrado por


TIMOTHYEDWARD DOWNS E SARAH ISHIDA ALCANTARA. São Paulo:
Quark, 1997.

SAUCIER, Christine. Animação e Interatividade na Web. São Paulo: Market Books,


2000.

SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de


Banco de dados. 3. ed. São Paulo: Makron Books, 1999.

SILVA, Ivan José de Mecenas. Interbase 6: Guia do desenvolvedor. Rio de Janeiro:


Book Express, 2000.

SILVA, Marco Aurélio Nobre Da. Interbase 5.6: O Poderoso Sistema Gerenciador de
Banco de Dados Relacional. São Paulo: Érica, 2000. 230 p.

STARLIN, Gorki; CARVALHO, Alan. Guia Inteligente: Tecnologia de Redes. Rio


de Janeiro: Book Express LTDA, 1998.

STARLIN, Gorki. TCP/IP. Barra da Tijuca: Book Express LTDA, 1998

TORRES, Gabriel; COZER, Alberto. Alavancando Negócios na Internet. Rio de


Janeiro: Axcel Books do Brasil Editora, 2000.

Você também pode gostar