Sie sind auf Seite 1von 26

SISTEMA DE ENSINO PRESENCIAL CONECTADO

ANALISE E DESENVOLVIMENTO DE SISTEMAS

PRODUO TEXTUAL INTERDISCIPLINAR GRUPO


4 Semestre 2013/2

Pelotas
2013

PRODUO TEXTUAL INTERDISCIPLINAR EM GRUPO


4 Semestre 2013/2

Trabalho apresentado Universidade Norte do Paran UNOPAR, como requisito parcial para a obteno de
mdia bimestral nas disciplinas de Desenvolvimento
Orientado a Objetos, Redes de computadores,
Modelagem Orientada a Objetos e Tpicos em
Desenvolvimento de Sistemas.
Orientadores: Prof. Marcio Roberto Chiaveli
Paulo K. Nishitani
Polyanna P.G.Fabris
Adriane A. Loper

Pelotas
2013

SUMRIO

CAPA, FOLHA DE ROSTO E SUMRIO........................................................1 e 2

INTRODUO......................................................................................................3

OBJETIVO.............................................................................................................4

DESENVOLVIMENTO..........................................................................................5
4.1 CRIAO DE UM DIAGRAMA DE CLASSE, TENDO UMA CLASSE
CLIENTE, BUGGY, TIPO_BUGGY E RESERVA.........................................................5
4.1.2 INFORMAES PARA CRIAO DE DIAGRAMA DE CLASSE.........5 e 6
4.1.3 DIAGRAMA DE ACORDO COM O SOLICITADO.......................................6
4.2. CRIAO DE UM PROJETO DE BANCO DE DADOS USANDO
FERRAMENTA CASE BR MODELO............................................................................6
4.2.1
MODELO
EM
BrModelo
CONCEITUAL........................................................7
4.2.2
MODELO
EM
BrModelo
LGICO.................................................................7
4.2.3 SCRIPT SQL GERADO PELA FERRAMENTA BRMODELO.................8 e 9
4.3
CLASSES.......................10

FERRAMENTA C#

NA

IMPLEMENTAO

DAS

4.4 IMPLEMENTAO DE UMA REDE DISTRIBUDA VISANDO CUSTO E


SOLUES................................................................................................................11
4.4.1 DESENVOLVIMENTO E ORGANIZAO.................................................11
4.4.2.ENGENHARIA DE SOFTWARE.................................................................11
4.4.3.TECNOLOGIAS UTILIZADAS....................................................................11
4.4.4.IMPLEMENTAO E FUNCIONAMENTO.................................................11
4.4.5.DIFICULDADES ENCONTRADAS.............................................................11
4.4.6.TESTES REALIZADOS..............................................................................11
5

CONCLUSO.....................................................................................................33

REFERNCIAS..................................................................................................34

2 INTRODUO
O analista de sistemas deve garantir o alinhamento entre tecnologia e estratgias
organizacionais, os projetos de software devem conhecer o cenrio organizacional
em um nvel suficiente, a ponto de avaliar e sugerir melhorias, ou mesmo
reengenharia nos processos de negcio. Este trabalho mostrar na prtica a
importncia das tcnicas e o desenvolvimento do sistema que iremos utilizar a
linguagem C#, atravs do diagrama de atividades, bem como a modelagem de
dados na utilizao dos consagrados bancos de dados relacionais juntamente com a
programao orientada a objetos, viabilizando o sucesso dos sistemas no que tange
o alinhamento dos objetivos aos processos das organizaes

3 OBJETIVO
Apresentar os requisitos coletados na forma de diagramas de casos
de uso e a suas entidades de relacionamento, implementar esses dados em um
software de desenvolvimento mostrando as telas que conteria o sistema. Ao
concluirmos este trabalho teremos em mos todas as informaes para o
desenvolvimento do software at o teste e validao..

4 DESENVOLVIMENTO

4.1 CRIAO DE UM DIAGRAMA DE CLASSE


De acordo com o cenrio proposto iremos levantar para este
Diagrama de Classe tais princpios:
Classe Cliente:

Atributos: Cdigo do cliente, Nome do cliente, Telefone do


cliente,

CNH do cliente, RG do cliente, CPF do cliente, Endereo do


cliente.

Mtodos: Cadastrar, Alterar, Excluir e Pesquisar cliente.

Classe Buggy:

Atributos: Nmero do buggy, Modelo do buggy, Ano do buggy,


Tipo do buggy.

Mtodos: Cadastrar, Alterar, Excluir e Pesquisar buggy.

Classe Reserva:

Atributos: Cdigo da reserva, Data da reserva, Data de


retirada do buggy, Data de devoluo do buggy, Cdigo do
cliente, Nmero do buggy, Valor estimado da reserva.

Mtodos: Cadastrar, Alterar, Excluir e Pesquisar reserva.

Classe Tipo_buggy:

Atributos: Descrio do tipo, Cdigo do tipo, Valor do tipo.

Mtodos: Cadastrar, Alterar, Excluir e Pesquisar tipo.

Para estes relacionamentos, seguiro estas seguintes informaes


aos quais sero atribudas ao nosso Diagrama de Classe:
4.1.2 Informaes para a criao do Diagrama de Classe.
Uma Cliente pode fazer nenhuma ou vrias Reservas,
Uma Reserva tem no mnimo um e no mximo um Cliente.
Um Buggy pode estar em nenhuma ou vrias Reservas (lembrando
que no pode ser ao mesmo tempo).
Uma Reserva tem no mnimo um e no mximo um Buggy.

Um Tipo_buggy pode ter nenhum ou vrios Buggys.


Um Buggy tem obrigatoriamente um Tipo_buggy.
4.1.3 Diagrama de Classe de acordo com o solicitado.

4.2. CRIAO PROJETO DE BANCO DE DADOS


De acordo com o nosso cenrio, ser apresentado um projeto de
Banco de Dados, usando o modelo conceitual nas aplicaes das formas normais,
usando a ferramenta CASE, tambm fora acrescentado sem pedido do projeto, mas
para aprofundamento do modelo, o modelo Lgico parametrizando todos os modelos
de um Bando de Dados e suas funcionalidades de acordo com o projeto
apresentado, que Locadora de Buggys.

4.2.1 Modelo em BrModelo Conceitual.

4.2.2 Modelo em BrModelo Lgico.

4.2.3 SCRIPT SQL GERADO PELA FERRAMENTA BRMODELO


- Gerao de Modelo fsico
-- Sql ANSI 2003 - brModelo.

CREATE TABLE Buggy (


cod_buggy Texto(1) PRIMARY KEY,
numero Texto(1),
modelo Texto(1),
ano Texto(1),
cod_cliente Texto(1)
)
CREATE TABLE Fornecedor (
cod_fornecedor Texto(1) PRIMARY KEY,
nome Texto(1),
telefone Texto(1)
)
CREATE TABLE Valor por Modelo e Ano (
2013/2014 Texto(1),
2010/2012 Texto(1),
2008/2012 Texto(1),
2012/2013 Texto(1),
cod_desc Texto(1)
)
CREATE TABLE Funcionrios (
cod_func Texto(1) PRIMARY KEY,
cargo Texto(1),
nome Texto(1),
setor Texto(1),
cod_cliente Texto(1)
)
CREATE TABLE Cliente (
nome_cliente Texto(1),
cod_cliente Texto(1) PRIMARY KEY,
cnh Texto(1),
rg Texto(1),
cpf Texto(1),
telefone Texto(1),
rua Texto(1),
nmero Texto(1)
)
CREATE TABLE Fabricante (
cod_fabricante Texto(1) PRIMARY KEY,

nome Texto(1),
telefone Texto(1),
rua Texto(1),
nmero Texto(1),
cod_desc Texto(1),
cod_fornecedor Texto(1),
FOREIGN KEY(cod_fornecedor) REFERENCES Fornecedor
(cod_fornecedor)
)
CREATE TABLE Descrio Buggy (
cod_desc Texto(1) PRIMARY KEY,
valor Texto(1),
modelo Texto(1),
ano Texto(1)
)
CREATE TABLE Conter (
cod_desc Texto(1),
cod_buggy Texto(1),
FOREIGN KEY(cod_desc) REFERENCES Descrio Buggy (cod_desc),
FOREIGN KEY(cod_buggy) REFERENCES Buggy (cod_buggy)
)
CREATE TABLE Vinculado (
cod_fornecedor Texto(1),
cod_desc Texto(1),
FOREIGN KEY(cod_fornecedor) REFERENCES Fornecedor
(cod_fornecedor),
FOREIGN KEY(cod_desc) REFERENCES Descrio Buggy (cod_desc)
)
ALTER TABLE Buggy ADD FOREIGN KEY(cod_cliente) REFERENCES
Cliente (cod_cliente)
ALTER TABLE Valor por Modelo e Ano ADD FOREIGN KEY(cod_desc)
REFERENCES Descrio Buggy (cod_desc)
ALTER TABLE Funcionrios ADD FOREIGN KEY(cod_cliente)
REFERENCES Cliente (cod_cliente)
ALTER TABLE Fabricante ADD FOREIGN KEY(cod_desc)
REFERENCES Descrio Buggy (cod_desc)

4.3 FERRAMENTA C# IMPLEMENTAO DAS CLASSES.

10

4.4 IMPLEMENTAO DE UMA REDE DISTRIBUDA VISANDO


CUSTO E SOLUES.
Em uma primeira fase, foi determinado qual seria o processo de software do
software da locadora, suas caractersticas e propriedades e formas de
funcionamento. Foram tambm definidas suas propriedades de engenharia de
software, onde foram aplicados os conhecimentos disciplinares de engenharia de
software.
O software teve arquitetura separada em dois grandes componentes: o
software web e o software distribudo. Eles possuem interao entre si. A interface
para o usurio da locadora distribuda foi feita totalmente pelas pginas web,
similarmente a um stio web da internet.
Nesta fase foram definidos os casos de uso do sistema e a arquitetura do
sistema dividida em mdulos e componentes que interagem. Tambm foi definido o
modelo conceitual do sistema considerando seu trabalho conjunto com os bancos de
dados, e as interaes temporais entre as partes do sistema, caracterizando os
diagramas de sequncia.
Tambm foi definido o diagrama de implementao. Este diagrama mostra a
disposio fsica dos componentes do software entre as mquinas da arquitetura
distribuda.
Durante o desenvolvimento do sistema, algumas modificaes precisaram ser
feitas nos diagramas feitos inicialmente. Assim, os diagramas foram sendo
aprimorados durante as fases de projeto e implementao.
Aps isso, foram feitas as primeiras implementaes do sistema distribudo
em Java, onde deveriam ser realizados os casos de uso de forma distribuda. O
software foi sendo desenvolvido de maneira incremental e evolutiva, sendo que cada
caso de uso foi desenvolvido em uma ordem determinada, de maneira sistematizada
e com realizao de testes de funcionamento. O programa web tambm foi
desenvolvido de forma organizada, e a integrao entre o sistema web e o sistema
distribudo foi sendo realizada de maneira gradativa.

Trabalho

4.4.1 Desenvolvimento e Organizao


Inicialmente foram levantadas as caractersticas importantes dos servios de
uma locadora de vdeos. Estas caractersticas so as de disponibilizar filmes de
vdeo para aluguel, mostrar os filmes disponveis para aluguel, fornecer ao cliente as
aes de alugar filme, devolver filme, efetuar seu pagamento de filmes alugados e
checar a sua situao de crdito ou dbito com a locadora.
A partir disso, foi desenvolvida a idia da arquitetura da locadora distribuda,
composta por alguns mdulos que iriam construir um software que seria concebido
para a filial, e outro software que seria concebido para a matriz. Assim decidiu-se

11

que haveria um software distribudo para a execuo das aes dos servios da
locadora, e este se dividiria em dois programas: um deles para a matriz, e outro
idntico para cada uma das filiais. O motivo de o programa ser igual para todas as
filiais o de que cada filial tem o mesmo comportamento, diferenciando-se apenas
nos filmes que possui, funcionrios disponveis para busca e entrega, localizao na
cidade e nmero de cpias de cada filme.
Considerando cada uma destas diferenas seria desenvolvido o programa
das filiais. O programa na matriz levaria em considerao as mesmas caractersticas
das filiais, porm com o adicional de que na matriz tem-se conhecimento de todos os
filmes que a rede de locadoras possui em seu portflio. Estes conhecimentos e
informaes esto nos bancos de dados. A matriz possui seu banco de dados
especfico, e as filiais possuem seus bancos de dados. Os bancos de dados das
filiais possuem apenas um nmero muito pequeno de informaes em tabelas, para
tratar do processamento e execuo dos casos de uso. A maior parte das
informaes da rede de locadoras fica no banco de dados da matriz.
Em um nvel mais alto, a arquitetura da dinmica de funcionamento da
locadora foi definida como possuindo o software web e o software distribudo.
No programa web, o usurio pode visualizar toda a interface da locadora, com
seus filmes disponveis para aluguel e com as aes que ele pode fazer. Esta
interface possui telas de navegao entre os filmes, links, frames, e formulrios que
devem ser preenchidos e submetidos pelo usurio quando ele estiver realizando um
caso de uso.
No software distribudo, formado por dois programas (um para filiais e outro
para matriz), so realizados as comunicaes, clculos e processamentos referentes
a cada caso de uso. Os resultados gerados pelo processamento e comunicaes
distribudas dos softwares distribudos so salvos e atualizados em banco de dados.
Assim, durante o processamento de um caso de uso, e dependendo do tipo de caso
de uso, ocorrem mudanas ou resultados e eles so salvos nos bancos de dados de
matriz e filial, com coerncia nas tabelas corretas e com consistncia de dados.
O software web, durante seu trabalho, tambm realiza leitura e escrita nos
dados do banco de dados da matriz. Desta forma, foi definido como parte da
arquitetura o comportamento de que na locadora matriz fica localizado o servidor
web, alm do banco de dados da matriz. O servidor web trabalha para gerar as
pginas web da interface com o usurio, para o browser. Alm disso, o programa
web tambm trabalha com o gerenciador de banco de dados para realizar consultas
ou transaes no banco de dados da matriz, de acordo com requisies do usurio
ou casos de uso que so disparados para ocorrer.

12

Figura: Arquitetura de funcionamento do sistema

13

4.4.2. ENGENHARIA DE SOFTWARE

Aps as etapas iniciais de especificao do projeto, foram desenvolvidos e


formalizados os aspectos de engenharia de software do sistema. Estes aspectos
foram os casos de uso do sistema e seus detalhes, o modelo conceitual do sistema
como um todo, o modelo do banco de dados da filial, o modelo do banco de dados
da matriz, os diagramas de sequncia dos casos de uso do sistema, e os diagramas
de implementao.
O modelo conceitual do sistema desenvolvido foi:

Os diagramas de seqncias para os casos de uso so:


1-> Alugar Buggy

2-> Devolver Buggy

14

3-> Cadastrar

4-> Efetuar login

5-> Efetuar pagamento

6-> Checa Situao

15

O diagrama de implementao :

Um refinamento do diagrama de implementao, que mostra todos os


processos do sistema, :

16

O diagrama mostra os processos e suas interaes, durante a operao do


sistema. H uma filial, mas ele pode ser interpretado com qualquer nmero de
filiais, pois o modelo das filiais o mesmo.
Uma modelagem importante para o sistema foi a do banco de dados da matriz
e o banco de dados da filial. Abaixo segue o modelo relacional dos bancos de
dados:
Modelo da base de dados da matriz:

Modelo da base de dados da filial:

4.4.3 Tecnologias utilizadas


Para a realizao efetiva do projeto da locadora distribuda, foram estudadas
algumas possibilidades de mtodos ou tecnologias de implementao do sistema.
Foi uma deciso de projeto a utilizao de Java para a implementao do
software distribudo. Na tecnologia Java encontram-se vrias ferramentas e

17

bibliotecas adequadas disponveis para um bom desenvolvimento do software, tais


como orientao a objetos, threads, tratamento de excees, conexo com banco de
dados, interao com banco de dados, sockets, mtodos de rede, mtodos para
manipulao de strings, entre outros.
Para o Java tambm existem ferramentas de ambiente de desenvolvimento
integrado, com compilador, editor de cdigo, auto-completao de cdigo,
verificao de erros, organizao de projeto, organizao de pacotes, busca,
numerao de linhas, depurao e teste, refatoramento, e outros. As principais
ferramentas so o Eclipse e o Netbeans. Foi decidido usar o Eclipse.

Figura: Desenvolvimento Java do software com o Eclipse


Primeiramente considerou-se usar CORBA para a implementao das
comunicaes distribudas, porm esta ideia no foi usada. Foi tomada a deciso de
se utilizar sockets, com a biblioteca de redes do Java, para a implementao das
comunicaes.
Para o banco de dados, usou-se o sistema gerenciador de banco de dados
MySQL, com bancos de dados relacionais. Para o servidor web, usou-se o Apache.
O sistema web deve prover uma interface para que o usurio interaja com o
sistema distribudo da locadora, efetuando os processos descritos nos casos de uso,
portanto o sistema web deve apresentar informaes e tambm processar
requisies como se fosse um software alm de acessar o banco de dados, portanto
precisamos de uma linguagem que gere contedo dinmico alm de pgina web

18

estticas feitas em html. Inicialmente foi considerada a utilizao da tecnologia JSP


(Java Server Pages) que torna possvel o sistema web processar entradas do
usurio ao invs de ser um mero mecanismo de apresentao de dados.
A utilizao de JSP envolve interao entre pginas html (que sozinhas
provm contedo esttico) e pginas.Jsp (que unidas com os arquivos .html tornam
possvel mostrar pginas diferentes acessando o mesmo arquivo baseado nas
requisies do usurio). Para acessar o banco de dados pela Web, JSP tambm
capaz de fazer isso. Mas a principal razo que privilegiou JSP em detrimento de
outras tecnologias Web (asp, php, cgi, xml, etc) era a comunicao com o sistema
distribudo em Java provendo uma linguagem nica de trabalho e facilitando o envio
das requisies feitas pela Web para o sistema distribudo em Java.
No entanto encontramos muitas dificuldades em implementar o sistema Web
em JSP, visto que era uma tecnologia com a qual no tnhamos familiaridade.
Portanto decidimos fazer o sistema Web em uma linguagem mais efetiva para
utilizarmos que no prejudicasse o andamento do projeto. A linguagem que acabou
sendo a final foi escolhida PHP (PHP hypertext preprocessor). PHP pode lidar com
formulrios e banco de dados to eficientemente quanto JSP, mas neste caso temos
uma discrepncia nas linguagens utilizadas (Java e PHP). Para realizar a interface
entre o sistema Web e o sistema distribudo utilizamos o banco de dados como meio
destes sistemas trocarem mensagens.
O sistema distribudo funciona processando requisies que os usurios
pedem pelo sistema Web e o canal de comunicao o banco de dados. Por
exemplo, quando o usurio X quer alugar o buggy Y, o sistema Web grava no banco
de dados esta requisio com as informaes locao, usurio X, buggy Y. O
sistema distribudo l periodicamente o banco de dados em busca de requisies e
quando encontra alguma, processa-a. Ento o sistema distribudo grava neste
mesmo banco de dados os resultados da requisio (neste exemplo o nome do
buggy alugado e de qual locadora ele vai sair) para que o sistema Web apresente
para o usurio o resultado da requisio.

4.4.4 Implementao e Funcionamento


A implementao do sistema distribudo se realizou com uma orientao aos
casos de uso que deveriam ser feitos, os processos de comunicao entre filiais e
matriz, e as leituras e escritas no banco de dados da matriz e filial.
A organizao e estrutura do programa distribudo foram feitas com quatro
classes Java, ou seja, quatro arquivos.Java. No programa matriz, estas classes so
Matriz, Conexo, ComunicadorMatriz e ConversaMatriz. No programa filial as
classes so Cliente, ConexoCliente, Comunicador e Conversa.
Na matriz, a classe Matriz possui como atributos o nmero de filiais que
estaro presentes no sistema distribudo e um objeto da classe ComunicadorMatriz.
A classe Matriz possui o programa principal (main) de onde deve ser chamado o
processo. Ao se executar o programa em linha de comando, deve ser passados
como parmetro o nmero de filiais da rede. Se o nmero de filiais da rede mudar,
basta que o programa seja chamado novamente com o novo nmero como
parmetro. Este valor atribudo para a varivel local de classe de nmero de filiais.
O programa principal da classe matriz responsvel por instanciar um novo objeto
ComunicadorMatriz, que uma thread. Este objeto criado e seu mtodo start()

19

chamado, assim inicia-se uma nova thread ComunicadorMatriz.


A classe e thread ComunicadorMatriz responsvel por criar um socket de
comunicao para cada uma das filiais, criar a conexo de banco de dados da
matriz, fazer a conexo de banco de dados da matriz, checar por requisies de
casos de uso no banco de dados e encaminhar a realizao do caso de uso. Desta
forma, quando uma nova requisio de caso de uso, como alugar buggy ou devolver
buggy, ocorre atravs do programa web, esta requisio salva no banco de dados
da matriz. O programa distribudo da matriz checa pela existncia de requisies
uma vez a cada intervalo de tempo determinado (5 segundos), e se houver algum
requisio (retirada de uma dupla da tabela do banco de dados), esta requisio
encaminhada para ter sua realizao. Para cada tipo de requisio, h um
encaminhamento diferente. Por exemplo, se o caso de uso for alugar buggy, ento
o encaminhamento feito o de se iniciar um novo objeto Conversa (classe
Conversa) para cada uma das filiais, e iniciar sua execuo (Conversa tambm
uma thread). Assim, no caso de uso de alugar, a o ComunicadorMatriz inicia um
socket de comunicao com cada filial, e instncia uma thread de conversa para
cada filial atravs de seu respectivo socket.
O conceito adotado de conversa, implementado na classe Conversa, foi o de
um conjunto inteiro de comunicaes entre matriz e filial para se realizar um caso de
uso. Assim uma conversa uma comunicao entre matriz e filial, nas suas vrias
possveis mensagens que so enviadas e recebidas, de forma a se realizar o
processo completo de algum caso de uso. No caso de uso alugar buggy, essa
conversa especfica. E assim para cada caso de uso h uma conversa especfica.
Ainda no caso de uso alugar filme, o ComunicadorMatriz lana a execuo
de uma thread de conversa para cada filial. Essa thread est na implementao da
classe ConversaMatriz. A classe ConversaMatriz, portanto, possui responsabilidade
de realizar as passagens de mensagens entre a matriz e uma filial para realizar o
caso de uso alugar. A primeira mensagem a de confirmao do caso de uso (filial
para matriz). Aps isso a matriz obtm de seu banco de dados o endereo do cliente
que requisita um aluguel. A matriz monta uma mensagem com o cdigo do cliente, o
cdigo do filme e a localizao do cliente (endereo relativo). Essa mensagem a
segunda, e enviada ao cliente (matriz para filial). A filial, por sua vez, verifica o
nmero de funcionrios de entrega livres, o nmero de cpias do buggy requisitado
livres, e a sua distncia at o endereo do cliente. A filial encapsula estes dados em
uma mensagem e a envia para a matriz (terceira mensagem, filial -> matriz). A matriz
recebe esta mensagem, decodifica-a, e armazena os valores em suas variveis
locais. Esta conversao ocorre no somente uma vez. Esta conversao ocorre
para cada uma das filiais, e uma thread de conversa a realiza para cada filial.
Ao final, realizam-se todas as comunicaes, a matriz coleta todos os dados
necessrios de cada filial, e as threads de conversa terminam. Para a continuidade
do processamento do caso de uso alugar, o matriz processa os dados coletados e
determina a melhor filial para entregar o buggy para o cliente, de acordo com o
nmero de funcionrios de entrega livres, o nmero de cpias livres e principalmente
a distncia fsica entre filial e matriz. A filial que melhor satisfazer estes requisitos
escolhida para entregar o buggy. Os dados da filial escolhida so atualizados no seu
banco de dado apropriadamente, e o banco de dados da matriz tambm recebe
atualizao adequada. Ocorrem atualizaes tambm no sistema distribudo. Estas
atualizaes so: o buggy alugado, decremento no nmero de cpias disponveis do
filme, informaes sobre o buggy e cpia alugados, valor a pagar de conta do
cliente, entre outros.

20

As comunicaes que ocorrem entre matriz e filiais segue um protocolo criado


para o projeto, ou seja, um protocolo prprio de aplicao. Nas camadas mais
baixas, a comunicao pela rede ocorre usando a internet pelos protocolos TCP/IP,
ou seja, so usados os endereos IP das mquinas usadas para filiais e para matriz,
e so usadas as portas do processo do programa distribudo em execuo, para
filiais e matriz.
Para o programa distribudo que executa nas filiais, ocorre semelhante
implementao e dinmica de funcionamento, apenas com algumas diferenas.
O programa distribudo na filial possui classes Cliente, Conexo,
Comunicador e Conversa. A classe Cliente possui o programa principal (main) que
recebe como parmetro a localizao relativa da filial na cidade e o nmero de
funcionrios de entrega que ela possui. Este programa principal inicializa variveis
importantes, incluindo um objeto da classe Comunicador, e faz a chamada para a
thread do Comunicador. Na filial, Comunicador e Conversa tambm so thread. A
thread do Comunicador, similarmente thread ComunicadorMatriz, ir iniciar um
socket e uma stream de comunicao com a matriz, receber uma mensagem da
matriz sobre um caso de uso que deve ser processado e tratado, ir verificar o caso
de uso que deve ser tratado, e ir disparar uma nova thread de conversa. Aps a
thread de conversa se iniciar na filial realizada a conversa (um conjunto de
comunicaes por passagem de mensagens atravs do stream de fluxo de dados)
com a matriz. Esta conversa ocorre sobre o caso de uso que estiver sendo tratado, e
trabalha por completo at que todo o processo de realizao do caso de uso esteja
terminado.
Durante as comunicaes, h uma sincronizao entre as filiais e a matriz,
para que as mensagens sejam enviadas e recebidas no tempo e ordem correta.
Para os outros casos de uso, como devolver filme e efetuar pagamento, o
mesmo processo realizado.
Implementao do sistema Web. O sistema Web inicial mostra uma tela de
login em HTML, obrigando o usurio efetuar login para acessar o resto da pgina
Web, caso ele no tenha um logjn, esta pgina inicial fornece um link que possibilite
o usurio novo realizar cadastro. Quando o usurio envia os dados do login, um
script PHP rodado que vai validar o usurio, quando o usurio validade, uma
pgina HTML carregada no browser mostrando as opes que o usurio pode
escolher.
Quando o usurio decide locar um filme, ele deve clicar no link alugar buggy,
preencher os dados (sua identificao e a identificao do buggy que quer alugar) e
envia-los.
No envio um script PHP executado que grava os dados da requisio no
banco de dados, ento neste momento o script dorme por um tempo e o sistema
distribudo captura esta requisio do banco de dados, este ento processa esta
requisio se comunicando com as filiais e grava o resultado da requisio na tabela
resultado do banco de dados.
O sistema Web acorda depois de um tempo predefinido para que o sistema
distribudo tenha tempo para processar a requisio e l o banco de dados em
busca do resultado e mostra na tela do browser para o usurio. Este exemplo serve
para explicar todos os processos que ocorrem no sistema Web.
O usurio acessa uma pgina HTML referente a algum caso de uso, pe os
dados e envia para execuo, ento um programa PHP ativado que se comunica
com o sistema distribudo pelo banco de dados e espera que o sistema distribudo
retorne algum resultado pelo banco de dados tambm. Alguns processos no

21

necessitam do sistema distribudo, que so efetuar login, efetuar cadastro e buscar


filme, pois casos envolvem informaes disponveis no banco de dados central
localizado na matriz que o nico ao qual o sistema Web tem acesso.

4.4.5. Dificuldades Encontradas


Algumas dificuldades foram encontradas, e elas foram explicadas
anteriormente. Condensando, foi mais complexas a deciso de utilizar JSP para
implementar o sistema Web, que mostrou-se invivel depois devido ao pouco
conhecimento da tecnologia que tnhamos e necessidade de andamento do projeto
(no podamos parar para estudar JSP). Utilizao de PHP tambm suscitou uma
nova questo, que era como realizar a comunicao entre o sistema Web e o
sistema distribudo. Se tivssemos utilizado JSP a comunicao poderia ser feita
usando sockets de forma simples j que as linguagens so iguais (em JSP so
utilizados programas .java tambm, classes, etc). Como optamos por PHP no havia
como conectar o PHP ao JSP diretamente ento decidimos realizar a comunicao
por um banco de dados comum, mas como o sistema distribudo sabia que alguma
requisio estava esperando no banco de dados? No havia como responder esta
questo, para resolver isso, o sistema Web fica lendo o banco de dados
ininterruptamente (com um perodo de alguns segundos) em busca de requisies.
Uma outra dificuldade encontrada foi a diferena no banco de dados durante
a implementao, pois os sistemas Web e distribudo foram construdos
separadamente, ento os detalhes do banco de dados estavam um pouco
diferentes, prejudicando a linguagem usada para comunicao entre sistema Web
e sistema distribudo.
4.4.6. Testes Realizados
Durante a implementao do projeto, testes foram exaustivamente
executados para descobrir erros na implementao e validar o sistema. A utilizao
de testes foi particularmente importante na depurao do programa, pois esta foi a
forma que melhor se encaixou no sistema.
No sistema web onde quem utiliza o sistema so usurios, a melhor forma de
depurar o programa realizar testes que so parte da rotina de funcionamento do
sistema web, como alugar buggy, devolver buggy, etc. Grande parte dos testes para
o sistema Web envolveu a gravao de informaes corretas no banco de dados de
requisies, que a parte mais importante na comunicao entre sistema Web e
sistema distribudo.
Entre os teste mais simples que imediatamente revelaram os problemas na
implementao podemos citar realizar cadastro, efetuar login, e buscar buggy, pois
neste caso o sistema distribudo no est envolvido.

22

Teste de efetuar login

Teste efetuar cadastro


Resultado do teste

Para e execuo
correta do sistema
distribudo,
vrios
testes e depuraes
foram
realizados.
Excees
do
processamento
e
interpretao
Java
ocorreram,
porm
estas excees foram
todas capturadas (em
catches), e assim que

23

cada uma ocorria, ela foi tratada e corrigida adequadamente no software.


O programa distribudo foi executado por um nmero grande de vezes at que
seu funcionamento completo fosse atingido. Cada caso de uso foi testado
separadamente, para que seu perfeito funcionamento fosse verificado at o fim. Esta
verificao incluiu checagem no banco de dados, para visualizar se dados corretos
das transaes SQL estavam sendo feitos, e com coerncia e consistncia.
Ocorreram excees sobre sockets, sincronizao de comunicaes,
passagem de mensagens, decodificao de mensagens e ponteiros de objetos
errados. Todas essas excees ou erros foram tratados durante as depuraes, e
devidamente corrigidos.

24

5 CONCLUSO
O desenvolvimento do projeto de uma locadora distribuda foi
realizado com sucesso. Com o uso de tecnologias que permitem uma boa
implementao de sistemas distribudos, possvel o desenvolvimento completo de
uma aplicao distribuda que solucione problemas, aumento o desempenho e
aumente a qualidade da aplicao de locadora.
No trabalho, h a utilizao das vantagens da intercomunicao
entre vrios processos de diferentes mquinas, assim como o processamento e
operao distribuda, para um aprimoramento da aplicao, em relao a uma
aplicao similar no distribuda, em mquinas que no se comunicam ou passam
mensagens.
No projeto da locadora distribuda, possvel obter-se um aumento
da qualidade do dos servios de uma rede de locadoras de uma cidade, com a
utilizao operacional de uma aplicao distribuda, como foi realizado neste
trabalho.
Com este trabalho, conclui-se que o processo de modelagem do
banco de dados com certeza merece um destaque especial em nossa avaliao,
pois foi justamente por termos exercidos o trabalho de anlise e programao como
se profissionais fossemos, que podemos identificar e atuar na essncia da profisso.
Foi bastante interessante as discusses, reunies, ponderaes, dvidas e a forma
como foi desenvolvido o trabalho com pesquisa e ajuda de fruns, pois na medida
que o modelo tomava forma, ficou evidente que em projetos de sistemas, vrios
profissionais trabalhando em conjunto com certeza podem obter um resultado muito
satisfatrio para o objetivo final que o projeto pronto, funcionando e entregue ao
destino final. O trabalho proposto foi concludo com a certeza de que no decorrer
deste Curso, o aprendizado e os conhecimentos adquiridos reforam a importncia
de conhecermos bem os diversos benefcios trazidos pela correta aplicabilidade das
ferramentas como o domnio dos conceitos de banco de dados relacionais casados
ao paradigma de orientao a objetos. A pesquisa nos proporcionou a prtica de
programao, to importante na concretizao dos sistemas modelados e pensados.

25

6 Referncias
[1] Wikipedia.org - Computao Distribuda
http://pt.wikipedia.org/wiki/Sistemas_distribu%C3%ADdos

[2] Apache Web Server Documentation Verso 2.2 da documentao Apache


http://httpd.apache.org/docs/2.2/

[3] MySQL Documentation MySQL Reference Manual Manual de referncia do


sistema gerenciador de banco de dados MySQL
http://dev.mysql.com/doc/

[4] Sun Java Standard Edition Documentation Java SE APIs & Documentation Core
API Docs Documentao Java da Sun, e Documentao da biblioteca Java da Sun.
http://java.sun.com/javase/6/docs/api/

Das könnte Ihnen auch gefallen