Pelotas2013

SISTEMA DE ENSINO PRESENCIAL CONECTADOANALISE E DESENVOLVIMENTO DE SISTEMAS

PRODUÇÃO TEXTUAL INTERDISCIPLINAR – GRUPO4º Semestre 2013/2

Pelotas2013

PRODUÇÃO TEXTUAL INTERDISCIPLINAR – EM GRUPO4º Semestre – 2013/2

Trabalho apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média bimestral nas disciplinas de Desenvolvimento Orientado a Objetos, Redes de computadores, Modelagem Orientada a Objetos e Tópicos em Desenvolvimento de Sistemas.Orientadores: Profª. Marcio Roberto Chiaveli Paulo K. Nishitani Polyanna P.G.Fabris Adriane A. Loper

SUMÁRIO

1 CAPA, FOLHA DE ROSTO E SUMÁRIO........................................................1 e 2

2 INTRODUÇÃO......................................................................................................3

3 OBJETIVO.............................................................................................................4

4 DESENVOLVIMENTO..........................................................................................5 4.1 CRIAÇÃO DE UM DIAGRAMA DE CLASSE, TENDO UMA CLASSE CLIENTE, BUGGY, TIPO_BUGGY E RESERVA.........................................................5 4.1.2 INFORMAÇÕES PARA CRIAÇÃO DE DIAGRAMA DE CLASSE.........5 e 6 4.1.3 DIAGRAMA DE ACORDO COM O SOLICITADO.......................................6

4.2. CRIAÇÃO 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 LÓGICO.................................................................7 4.2.3 SCRIPT SQL GERADO PELA FERRAMENTA BRMODELO.................8 e 9 4.3 FERRAMENTA C# NA IMPLEMENTAÇÃO DAS CLASSES.......................10 4.4 IMPLEMENTAÇÃO DE UMA REDE DISTRIBUÍDA VISANDO CUSTO E SOLUÇÕES................................................................................................................11 4.4.1 DESENVOLVIMENTO E ORGANIZAÇÃO.................................................11 4.4.2.ENGENHARIA DE SOFTWARE.................................................................11 4.4.3.TECNOLOGIAS UTILIZADAS....................................................................11 4.4.4.IMPLEMENTAÇÃO E FUNCIONAMENTO.................................................11 4.4.5.DIFICULDADES ENCONTRADAS.............................................................11 4.4.6.TESTES REALIZADOS..............................................................................11

5 CONCLUSÃO.....................................................................................................33

6 REFERÊNCIAS..................................................................................................34

2 INTRODUÇÃO

O analista de sistemas deve garantir o alinhamento entre tecnologia e estratégias organizacionais, os projetos de software devem conhecer o cenário organizacional em um nível suficiente, a ponto de avaliar e sugerir melhorias, ou mesmo reengenharia nos processos de negócio. Este trabalho mostrará na prática a importância das técnicas e o desenvolvimento do sistema que iremos utilizar a linguagem C#, através do diagrama de atividades, bem como a modelagem de dados na utilização dos consagrados bancos de dados relacionais juntamente com a programação orientada a objetos, viabilizando o sucesso dos sistemas no que tange o alinhamento dos objetivos aos processos das organizações

3

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 mãos todas as informações para o

desenvolvimento do software até o teste e validação..

4

4 DESENVOLVIMENTO

4.1 CRIAÇÃO DE UM DIAGRAMA DE CLASSE

De acordo com o cenário proposto iremos levantar para este

Diagrama de Classe tais princípios:

Classe Cliente:

Atributos: Código do cliente, Nome do cliente, Telefone do

cliente,

CNH do cliente, RG do cliente, CPF do cliente, Endereço do

cliente.

Métodos: Cadastrar, Alterar, Excluir e Pesquisar cliente.

Classe Buggy:

Atributos: Número do buggy, Modelo do buggy, Ano do buggy,

Tipo do buggy.

Métodos: Cadastrar, Alterar, Excluir e Pesquisar buggy.

Classe Reserva:

Atributos: Código da reserva, Data da reserva, Data de

retirada do buggy, Data de devolução do buggy, Código do

cliente, Número do buggy, Valor estimado da reserva.

Métodos: Cadastrar, Alterar, Excluir e Pesquisar reserva.

Classe Tipo_buggy:

Atributos: Descrição do tipo, Código do tipo, Valor do tipo.

Métodos: Cadastrar, Alterar, Excluir e Pesquisar tipo.

Para estes relacionamentos, seguirão estas seguintes informações

aos quais serão atribuídas ao nosso Diagrama de Classe:

4.1.2 Informações para a criação do Diagrama de Classe.

Uma Cliente pode fazer nenhuma ou várias Reservas,

Uma Reserva tem no mínimo um e no máximo um Cliente.

Um Buggy pode estar em nenhuma ou várias Reservas (lembrando

que não pode ser ao mesmo tempo).

Uma Reserva tem no mínimo um e no máximo um Buggy.

Um Tipo_buggy pode ter nenhum ou vários Buggys.

5

Um Buggy tem obrigatoriamente um Tipo_buggy.

4.1.3 Diagrama de Classe de acordo com o solicitado.

4.2. CRIAÇÃO PROJETO DE BANCO DE DADOS

De acordo com o nosso cenário, será apresentado um projeto de

Banco de Dados, usando o modelo conceitual nas aplicações das formas normais,

usando a ferramenta CASE, também fora acrescentado sem pedido do projeto, mas

para aprofundamento do modelo, o modelo Lógico parametrizando todos os modelos

de um Bando de Dados e suas funcionalidades de acordo com o projeto

apresentado, que é Locadora de Buggy´s.

6

4.2.1 Modelo em BrModelo Conceitual.

4.2.2 Modelo em BrModelo Lógico.

7

4.2.3 SCRIPT SQL GERADO PELA FERRAMENTA BRMODELO

- Geração de Modelo físico-- 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 Funcionários (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),número Texto(1))

CREATE TABLE Fabricante (cod_fabricante Texto(1) PRIMARY KEY,

8

nome Texto(1),telefone Texto(1),rua Texto(1),número Texto(1),cod_desc Texto(1),cod_fornecedor Texto(1),FOREIGN KEY(cod_fornecedor) REFERENCES Fornecedor (cod_fornecedor))

CREATE TABLE Descrição 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 Descrição 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 Descrição 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 Descrição Buggy (cod_desc)ALTER TABLE Funcionários ADD FOREIGN KEY(cod_cliente) REFERENCES Cliente (cod_cliente)ALTER TABLE Fabricante ADD FOREIGN KEY(cod_desc) REFERENCES Descrição Buggy (cod_desc)

4.3 FERRAMENTA C# IMPLEMENTAÇÃO DAS CLASSES.

9

4.4 IMPLEMENTAÇÃO DE UMA REDE DISTRIBUÍDA VISANDO CUSTO E SOLUÇÕES.

Em uma primeira fase, foi determinado qual seria o processo de software do software da locadora, suas características e propriedades e formas de funcionamento. Foram também 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 distribuído. Eles possuem interação entre si. A interface para o usuário da locadora distribuída foi feita totalmente pelas páginas web, similarmente a um sítio web da internet.

Nesta fase foram definidos os casos de uso do sistema e a arquitetura do sistema dividida em módulos e componentes que interagem. Também foi definido o modelo conceitual do sistema considerando seu trabalho conjunto com os bancos de dados, e as interações temporais entre as partes do sistema, caracterizando os diagramas de sequência.

Também foi definido o diagrama de implementação. Este diagrama mostra a disposição física dos componentes do software entre as máquinas da arquitetura distribuída.

Durante o desenvolvimento do sistema, algumas modificações precisaram ser feitas nos diagramas feitos inicialmente. Assim, os diagramas foram sendo aprimorados durante as fases de projeto e implementação.

Após isso, foram feitas as primeiras implementações do sistema distribuído em Java, onde deveriam ser realizados os casos de uso de forma distribuída. 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 realização de testes de funcionamento. O programa web também foi desenvolvido de forma organizada, e a integração entre o sistema web e o sistema distribuído foi sendo realizada de maneira gradativa.

Trabalho

4.4.1 Desenvolvimento e Organização

Inicialmente foram levantadas as características importantes dos serviços de uma locadora de vídeos. Estas características são as de disponibilizar filmes de vídeo para aluguel, mostrar os filmes disponíveis para aluguel, fornecer ao cliente as ações de alugar filme, devolver filme, efetuar seu pagamento de filmes alugados e checar a sua situação de crédito ou débito com a locadora.

A partir disso, foi desenvolvida a idéia da arquitetura da locadora distribuída, composta por alguns módulos que iriam construir um software que seria concebido para a filial, e outro software que seria concebido para a matriz. Assim decidiu-se

10

que haveria um software distribuído para a execução das ações dos serviços da locadora, e este se dividiria em dois programas: um deles para a matriz, e outro idêntico 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, funcionários disponíveis para busca e entrega, localização na cidade e número de cópias de cada filme.

Considerando cada uma destas diferenças seria desenvolvido o programa das filiais. O programa na matriz levaria em consideração as mesmas características das filiais, porém com o adicional de que na matriz tem-se conhecimento de todos os filmes que a rede de locadoras possui em seu portfólio. Estes conhecimentos e informações estão nos bancos de dados. A matriz possui seu banco de dados específico, e as filiais possuem seus bancos de dados. Os bancos de dados das filiais possuem apenas um número muito pequeno de informações em tabelas, para tratar do processamento e execução dos casos de uso. A maior parte das informações da rede de locadoras fica no banco de dados da matriz.

Em um nível mais alto, a arquitetura da dinâmica de funcionamento da locadora foi definida como possuindo o software web e o software distribuído.

No programa web, o usuário pode visualizar toda a interface da locadora, com seus filmes disponíveis para aluguel e com as ações que ele pode fazer. Esta interface possui telas de navegação entre os filmes, links, frames, e formulários que devem ser preenchidos e submetidos pelo usuário quando ele estiver realizando um caso de uso.

No software distribuído, formado por dois programas (um para filiais e outro para matriz), são realizados as comunicações, cálculos e processamentos referentes a cada caso de uso. Os resultados gerados pelo processamento e comunicações distribuídas dos softwares distribuídos são 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 mudanças ou resultados e eles são salvos nos bancos de dados de matriz e filial, com coerência nas tabelas corretas e com consistência de dados.

O software web, durante seu trabalho, também 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, além do banco de dados da matriz. O servidor web trabalha para gerar as páginas web da interface com o usuário, para o browser. Além disso, o programa web também trabalha com o gerenciador de banco de dados para realizar consultas ou transações no banco de dados da matriz, de acordo com requisições do usuário ou casos de uso que são disparados para ocorrer.

11

Figura: Arquitetura de funcionamento do sistema

12

4.4.2. ENGENHARIA DE SOFTWARE

Após as etapas iniciais de especificação 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 sequência dos casos de uso do sistema, e os diagramas de implementação.

O modelo conceitual do sistema desenvolvido foi:

Os diagramas de seqüências para os casos de uso são:

1-> Alugar Buggy 2-> Devolver Buggy

13

3-> Cadastrar 4-> Efetuar login

5-> Efetuar pagamento 6-> Checa Situação

14

O diagrama de implementação é:

Um refinamento do diagrama de implementação, que mostra todos os processos do sistema, é:

15

O diagrama mostra os processos e suas interações, durante a operação do sistema. Há uma filial, mas ele pode ser interpretado com qualquer número 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 realização efetiva do projeto da locadora distribuída, foram estudadas algumas possibilidades de métodos ou tecnologias de implementação do sistema.

Foi uma decisão de projeto a utilização de Java para a implementação do software distribuído. Na tecnologia Java encontram-se várias ferramentas e bibliotecas adequadas disponíveis para um bom desenvolvimento do software, tais como orientação a objetos, threads, tratamento de exceções, conexão com banco de

16

dados, interação com banco de dados, sockets, métodos de rede, métodos para manipulação de strings, entre outros.

Para o Java também existem ferramentas de ambiente de desenvolvimento integrado, com compilador, editor de código, auto-completação de código, verificação de erros, organização de projeto, organização de pacotes, busca, numeração de linhas, depuração e teste, refatoramento, e outros. As principais ferramentas são 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 implementação das comunicações distribuídas, porém esta ideia não foi usada. Foi tomada a decisão de se utilizar sockets, com a biblioteca de redes do Java, para a implementação das comunicações.

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 usuário interaja com o sistema distribuído da locadora, efetuando os processos descritos nos casos de uso, portanto o sistema web deve apresentar informações e também processar requisições como se fosse um software além de acessar o banco de dados, portanto precisamos de uma linguagem que gere conteúdo dinâmico além de página web estáticas feitas em html. Inicialmente foi considerada a utilização da tecnologia JSP (Java Server Pages) que torna possível o sistema web processar entradas do usuário ao invés de ser um mero mecanismo de apresentação de dados.

17

A utilização de JSP envolve interação entre páginas html (que sozinhas provém conteúdo estático) e páginas.Jsp (que unidas com os arquivos .html tornam possível mostrar páginas diferentes acessando o mesmo arquivo baseado nas requisições do usuário). Para acessar o banco de dados pela Web, JSP também é capaz de fazer isso. Mas a principal razão que privilegiou JSP em detrimento de outras tecnologias Web (asp, php, cgi, xml, etc) era a comunicação com o sistema distribuído em Java provendo uma linguagem única de trabalho e facilitando o envio das requisições feitas pela Web para o sistema distribuído em Java.

No entanto encontramos muitas dificuldades em implementar o sistema Web em JSP, visto que era uma tecnologia com a qual não tínhamos familiaridade. Portanto decidimos fazer o sistema Web em uma linguagem mais efetiva para utilizarmos que não prejudicasse o andamento do projeto. A linguagem que acabou sendo a final foi escolhida PHP (PHP hypertext preprocessor). PHP pode lidar com formulários e banco de dados tão eficientemente quanto JSP, mas neste caso temos uma discrepância nas linguagens utilizadas (Java e PHP). Para realizar a interface entre o sistema Web e o sistema distribuído utilizamos o banco de dados como meio destes sistemas trocarem mensagens.

O sistema distribuído funciona processando requisições que os usuários pedem pelo sistema Web e o canal de comunicação é o banco de dados. Por exemplo, quando o usuário X quer alugar o buggy Y, o sistema Web grava no banco de dados esta requisição com as informações “locação”, “usuário X”, “buggy Y”. O sistema distribuído lê periodicamente o banco de dados em busca de requisições e quando encontra alguma, processa-a. Então o sistema distribuído grava neste mesmo banco de dados os resultados da requisição (neste exemplo o nome do buggy alugado e de qual locadora ele vai sair) para que o sistema Web apresente para o usuário o resultado da requisição.

4.4.4 Implementação e Funcionamento

A implementação do sistema distribuído se realizou com uma orientação aos casos de uso que deveriam ser feitos, os processos de comunicação entre filiais e matriz, e as leituras e escritas no banco de dados da matriz e filial.

A organização e estrutura do programa distribuído foram feitas com quatro classes Java, ou seja, quatro arquivos.Java. No programa matriz, estas classes são Matriz, Conexão, ComunicadorMatriz e ConversaMatriz. No programa filial as classes são Cliente, ConexãoCliente, Comunicador e Conversa.

Na matriz, a classe Matriz possui como atributos o número de filiais que estarão presentes no sistema distribuído 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 parâmetro o número de filiais da rede. Se o número de filiais da rede mudar, basta que o programa seja chamado novamente com o novo número como parâmetro. Este valor é atribuído para a variável local de classe de número de filiais. O programa principal da classe matriz é responsável por instanciar um novo objeto ComunicadorMatriz, que é uma thread. Este objeto é criado e seu método start() é chamado, assim inicia-se uma nova thread ComunicadorMatriz.

A classe e thread ComunicadorMatriz é responsável por criar um socket de comunicação para cada uma das filiais, criar a conexão de banco de dados da

18

matriz, fazer a conexão de banco de dados da matriz, checar por requisições de casos de uso no banco de dados e encaminhar a realização do caso de uso. Desta forma, quando uma nova requisição de caso de uso, como alugar buggy ou devolver buggy, ocorre através do programa web, esta requisição é salva no banco de dados da matriz. O programa distribuído da matriz checa pela existência de requisições uma vez a cada intervalo de tempo determinado (5 segundos), e se houver algum requisição (retirada de uma dupla da tabela do banco de dados), esta requisição é encaminhada para ter sua realização. Para cada tipo de requisição, há um encaminhamento diferente. Por exemplo, se o caso de uso for “alugar buggy”, então o encaminhamento feito é o de se iniciar um novo objeto ‘Conversa’ (classe Conversa) para cada uma das filiais, e iniciar sua execução (Conversa também é uma thread). Assim, no caso de uso de alugar, a o ComunicadorMatriz inicia um socket de comunicação com cada filial, e instância uma thread de conversa para cada filial através de seu respectivo socket.

O conceito adotado de ‘conversa’, implementado na classe Conversa, foi o de um conjunto inteiro de comunicações entre matriz e filial para se realizar um caso de uso. Assim uma conversa é uma comunicação entre matriz e filial, nas suas várias possíveis mensagens que são enviadas e recebidas, de forma a se realizar o processo completo de algum caso de uso. No caso de uso ´alugar buggy´, essa conversa é específica. E assim para cada caso de uso há uma conversa específica.

Ainda no caso de uso ´alugar filme´, o ComunicadorMatriz lança a execução de uma thread de conversa para cada filial. Essa thread está na implementação 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 confirmação do caso de uso (filial para matriz). Após isso a matriz obtém de seu banco de dados o endereço do cliente que requisita um aluguel. A matriz monta uma mensagem com o código do cliente, o código do filme e a localização do cliente (endereço relativo). Essa mensagem é a segunda, e é enviada ao cliente (matriz para filial). A filial, por sua vez, verifica o número de funcionários de entrega livres, o número de cópias do buggy requisitado livres, e a sua distância até o endereço 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 variáveis locais. Esta conversação ocorre não somente uma vez. Esta conversação ocorre para cada uma das filiais, e uma thread de conversa a realiza para cada filial.

Ao final, realizam-se todas as comunicações, a matriz coleta todos os dados necessários 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 número de funcionários de entrega livres, o número de cópias livres e principalmente a distância física entre filial e matriz. A filial que melhor satisfazer estes requisitos é escolhida para entregar o buggy. Os dados da filial escolhida são atualizados no seu banco de dado apropriadamente, e o banco de dados da matriz também recebe atualização adequada. Ocorrem atualizações também no sistema distribuído. Estas atualizações são: o buggy alugado, decremento no número de cópias disponíveis do filme, informações sobre o buggy e cópia alugados, valor a pagar de conta do cliente, entre outros.

As comunicações que ocorrem entre matriz e filiais segue um protocolo criado para o projeto, ou seja, um protocolo próprio de aplicação. Nas camadas mais baixas, a comunicação pela rede ocorre usando a internet pelos protocolos TCP/IP,

19

ou seja, são usados os endereços IP das máquinas usadas para filiais e para matriz, e são usadas as portas do processo do programa distribuído em execução, para filiais e matriz.

Para o programa distribuído que executa nas filiais, ocorre semelhante implementação e dinâmica de funcionamento, apenas com algumas diferenças.

O programa distribuído na filial possui classes Cliente, Conexão, Comunicador e Conversa. A classe Cliente possui o programa principal (main) que recebe como parâmetro a localização relativa da filial na cidade e o número de funcionários de entrega que ela possui. Este programa principal inicializa variáveis importantes, incluindo um objeto da classe Comunicador, e faz a chamada para a thread do Comunicador. Na filial, Comunicador e Conversa também são thread. A thread do Comunicador, similarmente à thread ComunicadorMatriz, irá iniciar um socket e uma stream de comunicação 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. Após a thread de conversa se iniciar na filial é realizada a conversa (um conjunto de comunicações por passagem de mensagens através 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 realização do caso de uso esteja terminado.

Durante as comunicações, há uma sincronização 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.

Implementação do sistema Web. O sistema Web inicial mostra uma tela de login em HTML, obrigando o usuário efetuar login para acessar o resto da página Web, caso ele não tenha um logjn, esta página inicial fornece um link que possibilite o usuário novo realizar cadastro. Quando o usuário envia os dados do login, um script PHP é rodado que vai validar o usuário, quando o usuário é validade, uma página HTML é carregada no browser mostrando as opções que o usuário pode escolher.

Quando o usuário decide locar um filme, ele deve clicar no link alugar buggy, preencher os dados (sua identificação e a identificação do buggy que quer alugar) e envia-los.

No envio um script PHP é executado que grava os dados da requisição no banco de dados, então neste momento o script dorme por um tempo e o sistema distribuído captura esta requisição do banco de dados, este então processa esta requisição se comunicando com as filiais e grava o resultado da requisição na tabela resultado do banco de dados.

O sistema Web acorda depois de um tempo predefinido para que o sistema distribuído tenha tempo para processar a requisição e lê o banco de dados em busca do resultado e mostra na tela do browser para o usuário. Este exemplo serve para explicar todos os processos que ocorrem no sistema Web.

O usuário acessa uma página HTML referente a algum caso de uso, põe os dados e envia para execução, então um programa PHP é ativado que se comunica com o sistema distribuído pelo banco de dados e espera que o sistema distribuído retorne algum resultado pelo banco de dados também. Alguns processos não necessitam do sistema distribuído, que são efetuar login, efetuar cadastro e buscar filme, pois casos envolvem informações disponíveis no banco de dados central localizado na matriz que é o único ao qual o sistema Web tem acesso.

20

4.4.5. Dificuldades Encontradas

Algumas dificuldades foram encontradas, e elas foram explicadas anteriormente. Condensando, foi mais complexas a decisão de utilizar JSP para implementar o sistema Web, que mostrou-se inviável depois devido ao pouco conhecimento da tecnologia que tínhamos e à necessidade de andamento do projeto (não podíamos parar para estudar JSP). Utilização de PHP também suscitou uma nova questão, que era como realizar a comunicação entre o sistema Web e o sistema distribuído. Se tivéssemos utilizado JSP a comunicação poderia ser feita usando sockets de forma simples já que as linguagens são iguais (em JSP são utilizados programas .java também, classes, etc). Como optamos por PHP não havia como conectar o PHP ao JSP diretamente então decidimos realizar a comunicação por um banco de dados comum, mas como o sistema distribuído sabia que alguma requisição estava esperando no banco de dados? Não havia como responder esta questão, para resolver isso, o sistema Web fica lendo o banco de dados ininterruptamente (com um período de alguns segundos) em busca de requisições.

Uma outra dificuldade encontrada foi a diferença no banco de dados durante a implementação, pois os sistemas Web e distribuído foram construídos separadamente, então os detalhes do banco de dados estavam um pouco diferentes, prejudicando a “linguagem” usada para comunicação entre sistema Web e sistema distribuído.

4.4.6. Testes Realizados

Durante a implementação do projeto, testes foram exaustivamente executados para descobrir erros na implementação e validar o sistema. A utilização de testes foi particularmente importante na depuração do programa, pois esta foi a forma que melhor se encaixou no sistema.

No sistema web onde quem utiliza o sistema são usuários, a melhor forma de depurar o programa é realizar testes que são parte da rotina de funcionamento do sistema web, como alugar buggy, devolver buggy, etc. Grande parte dos testes para o sistema Web envolveu a gravação de informações corretas no banco de dados de requisições, que é a parte mais importante na comunicação entre sistema Web e sistema distribuído.

Entre os teste mais simples que imediatamente revelaram os problemas na implementação podemos citar realizar cadastro, efetuar login, e buscar buggy, pois neste caso o sistema distribuído não está envolvido.

21

Teste de efetuar login

Teste efetuar cadastro

Resultado do teste

22

Para e execução correta do sistema distribuído, vários testes e depurações foram realizados. Exceções do processamento e interpretação Java ocorreram, porém estas exceções foram todas capturadas (em catches), e assim que cada uma ocorria, ela foi tratada e corrigida adequadamente no software.

O programa distribuído foi executado por um número 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 verificação incluiu checagem no banco de dados, para visualizar se dados corretos das transações SQL estavam sendo feitos, e com coerência e consistência.

Ocorreram exceções sobre sockets, sincronização de comunicações, passagem de mensagens, decodificação de mensagens e ponteiros de objetos errados. Todas essas exceções ou erros foram tratados durante as depurações, e devidamente corrigidos.

23

5 CONCLUSÃO

O desenvolvimento do projeto de uma locadora distribuída foi

realizado com sucesso. Com o uso de tecnologias que permitem uma boa

implementação de sistemas distribuídos, é possível o desenvolvimento completo de

uma aplicação distribuída que solucione problemas, aumento o desempenho e

aumente a qualidade da aplicação de locadora.

No trabalho, há a utilização das vantagens da intercomunicação

entre vários processos de diferentes máquinas, assim como o processamento e

operação distribuída, para um aprimoramento da aplicação, em relação a uma

aplicação similar não distribuída, em máquinas que não se comunicam ou passam

mensagens.

No projeto da locadora distribuída, é possível obter-se um aumento

da qualidade do dos serviços de uma rede de locadoras de uma cidade, com a

utilização operacional de uma aplicação distribuída, 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 avaliação,

pois foi justamente por termos exercidos o trabalho de análise e programação como

se profissionais fossemos, que podemos identificar e atuar na essência da profissão.

Foi bastante interessante as discussões, reuniões, ponderações, dúvidas e a forma

como foi desenvolvido o trabalho com pesquisa e ajuda de fóruns, pois na medida

que o modelo tomava forma, ficou evidente que em projetos de sistemas, vários

profissionais trabalhando em conjunto com certeza podem obter um resultado muito

satisfatório para o objetivo final que é o projeto pronto, funcionando e entregue ao

destino final. O trabalho proposto foi concluído com a certeza de que no decorrer

deste Curso, o aprendizado e os conhecimentos adquiridos reforçam a importância

de conhecermos bem os diversos benefícios trazidos pela correta aplicabilidade das

ferramentas como o domínio dos conceitos de banco de dados relacionais casados

ao paradigma de orientação a objetos. A pesquisa nos proporcionou a prática de

programação, tão importante na concretização dos sistemas modelados e pensados.

24

6 Referências

[1] Wikipedia.org - “Computação Distribuída” http://pt.wikipedia.org/wiki/Sistemas_distribu%C3%ADdos

[2] Apache Web Server Documentation – Versão 2.2 da documentação Apache – http://httpd.apache.org/docs/2.2/

[3] MySQL Documentation – MySQL Reference Manual – Manual de referência do sistema gerenciador de banco de dados MySQLhttp://dev.mysql.com/doc/

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

25