UNIVERSIDADE FEDERAL FLUMINENSEIVY MARTINS SALLES

SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DERASTREAMENTO VEICULAR

NITERÓI2010

IVY MARTINS SALLES

SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DERASTREAMENTO VEICULAR

Trabalho de Conclusão de Curso subme-

tido ao Curso de Tecnologia em Siste-

mas de Computação da Universidade

Federal Fluminense como requisito par-

cial para obtenção do Tecnólogo em Sis-

temas de Computação.

Orientador:Leandro Soares de Sousa

NITERÓI2010

IVY MARTINS SALLES

SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DERASTREAMENTO VEICULAR

Trabalho de Conclusão de Curso subme-

tido ao Curso de Tecnologia em Siste-

mas de Computação da Universidade

Federal Fluminense como requisito par-

cial para obtenção do Tecnólogo em Sis-

temas de Computação.

Niterói, ___ de _______________ de 2010.

Banca Examinadora:

_________________________________________

Prof. Leandro Soares de Sousa, Msc. – Orientador

UFF - Universidade Federal Fluminense

_________________________________________

Prof. Cristiano Grijó Pitangui, Msc. – Avaliador

UFRJ – Universidade Federal do Rio de Janeiro

AGRADECIMENTOS

Á Deus, por me proporcionar tamanho apren-

dizado, e por me dar forças para concluir este

curso. Também aos meus familiares e ami-

gos, pelo apoio e estimulo que me deram ao

longo do curso.

.

RESUMO

O sistema de rastreamento via satélite tem se aprimorado rapidamente, principalmente em virtude das novas necessidades do mercado e pelo avanço tec-nológico. Este trabalho descreve a construção de um Sistema de Gerência de uma Empresa de Rastreamento Veicular (Satcar). Este sistema tem por objetivo controlar todo o processo de cadastramento de clientes, vendedores, fornecedores, vendas e instalação de um rastreador veicular.

No desenvolvimento do Satcar foi feito uso da Linguagem de Modelagem Unificada e da metodologia orientada a objetos do Processo Unificado, ministrada nos cursos oferecidos pelo CEDERJ de Arquitetura e Projetos de Sistemas I e II, como também o uso de ferramentas ministradas nos curso de Banco de Dados e Engenharia de Software.

LISTA DE ILUSTRAÇÕES

Figura 3. 1: Arquitetura do sistema (Uma visão geral) ..........................................14

LISTA DE TABELAS

Tabela 4.1: Requisitos não funcionais....................................................................16

Tabela 4. 2: Requisitos funcionais..........................................................................17

Tabela 4. 3: Modelo para a especificação dos requisitos......................................20

LISTA DE ABREVIATURAS E SIGLAS

SGBD - Sistema de Gerência de Banco de Dados.

UML – Unified Modeling Language.

UC – Casos de Uso.

.

.

.

.

.

.

SUMÁRIO

AGRADECIMENTOS ............................................................................................... 4

. 4

RESUMO .................................................................................................................. 5

LISTA DE ILUSTRAÇÕES ....................................................................................... 6

LISTA DE TABELAS ................................................................................................ 6

LISTA DE ABREVIATURAS E SIGLAS ................................................................... 7

1 INTRODUÇÃO ....................................................................................................... 9

2 DEFINIÇÃO DO PROBLEMA .............................................................................. 11

3 PROPOSTA DE SOLUÇÃO ................................................................................ 13

4 MODELAGEM ...................................................................................................... 15

5 IMPLENTAÇÃO E ANÁLISE CRÍTICA DO PROCESSO .................................... 34

CONCLUSÕES ...................................................................................................... 56

REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................... 57

REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................... 57

1 INTRODUÇÃO

Os sistemas de rastreamento estão cada vez mais populares no Bra-

sil, sendo um tema muito abordado por meio da mídia ou companhias de seguro.

Ao contrário de outros equipamentos veiculares, onde há interação com o usuá-

rio, como é o caso de alarmes, auto-rádios, sistemas de navegação etc., com os

rastreadores a interatividade é quase nula dentro do veículo. Devido à questão

da segurança do patrimônio, estes equipamentos tiveram grande aceitação pe-

los consumidores ao longo de seus dez anos de existência (vide sítio [1]).

O mercado para tais sistemas vai desde empresas de transporte, com

o intuito de evitar o roubo de suas cargas, até mesmo para proprietários de car-

ros de passeio. O principal objetivo dos consumidores é proteger seu patrimônio,

uma vez que as instituições oficiais não têm obtido êxito e nem se mostrado ca-

pazes de garantir segurança.

O Satcar – Sistema de Gerência de uma Empresa de Rastreamento

Veicular foi desenvolvido com o propósito de apoiar o processo de venda e

instalação dos rastreadores veiculares. Isto é feito através do cadastramento e

controle dos clientes, bem como fornecedores e produtos em estoque.

O objetivo desse trabalho foi de aplicar os conhecimentos adquiridos

pelo autor nas disciplinas de Banco de Dados, Engenharia de Software,

Arquitetura e Projetos de Sistemas I e II, e produzir a documentação relacionada

ao projeto com base nos requisitos de um modelo de negócios.

Este documento foi organizado da seguinte forma:

9

• No segundo capítulo é abordado o negócio alvo do trabalho bem

como o escopo do projeto.

• O terceiro capítulo trata das especificações que devem ser atendi-

das pelo Satcar e oferece uma proposta para elaborar uma solu-

ção.

• No quarto capítulo é apresentada a modelagem, formada por um

conjunto de artefatos, que permite visualizar o Satcar de forma

abstrata.

• No quinto capítulo apresentamos a implementação do sistema atra-

vés de um mapa de navegação e das telas do Satcar. Ainda neste

capítulo colocamos uma análise crítica do processo de desenvolvi-

mento do produto.

• Finalmente, no Capítulo 6, colocamos as conclusões obtidas du-

rante o desenvolvimento deste trabalho.

10

2 DEFINIÇÃO DO PROBLEMA

Uma empresa de rastreamento veicular deseja automatizar a presta-

ção de serviço de rastreamento veicular, controlando não só os serviços presta-

dos, mas também o cadastro de clientes e veículos.

O rastreamento veicular utiliza a tecnologia GPS/GPRS, que se trata

de um sistema de navegação via satélite. GPS é a sigla de Global Positioning

System. São satélites que estão em órbita da terra, através de uma rede, em for-

mação precisa. Como sabemos, todo ponto na Terra é identificado por dois nú-

meros chamados coordenadas. Estas coordenadas representam o ponto exato

onde uma linha horizontal conhecida como latitude, cruza uma linha vertical co-

nhecida como longitude. O receptor de GPS localiza pelo menos três satélites e

usa as informações recebidas para determinar as coordenadas geográficas no

receptor de GPS. Comparando o tempo em que os sinais foram transmitidos dos

satélites e o tempo que eles foram registrados, o receptor de GPS calcula a dis-

tância de cada satélite, sendo no mínimo computada a distância de três ou mais

satélites, que resultará na sua posição na superfície da terra. Com estas distan-

cias medidas, o receptor também poderá calcular velocidade e poderá calcular o

tempo de viagem, distância, altitude, dentre outros feitos (vide sítio[2]).

Com a crescente violência urbana, os sistemas de rastreamento veicu-

lar cresceram em importância, pois com eles pode-se recuperar o veículo e ga-

rantir a segurança do motorista, mesmo em situações onde há sequestro, uma

vez que a empresa responsável pelo rastreamento fará o acompanhamento da

situação de sinistro juntamente com o órgão de segurança responsável. A gran-

de questão da utilização do rastreador veicular é a capacidade de inibir furtos e

roubos devido à dificuldade e risco imposto aos ladrões (vide sítio[1]).

11

O Satcar foi desenvolvido para empresas que pretendem comerciali-

zar equipamentos de rastreamento veicular e controlar todos os seus clientes de

maneira rápida e fácil.

12

3 PROPOSTA DE SOLUÇÃO

Visando a solução das questões levantadas no capítulo anterior,

surgiu a idéia de desenvolver um produto (sistema). Nesta linha, inicialmente

colocamos as premissas básicas para o Satcar, ou seja, o sistema deve permitir

que:

• As informações relacionadas à aquisição e instalação do

rastreador possam ser registradas.

• O histórico de pagamentos do cliente possa ser registrado e

atualizado se necessário.

• O cadastramento dos técnicos responsáveis por efetuar a

instalação do rastreador.

• O controle dos estoques de equipamentos.

• O cadastramento dos fornecedores, como também sua

alteração e exclusão, quando necessário.

• A emissão de relatórios.

Para atender aos requisitos supramencionados, o Satcar foi

desenvolvido com uma arquitetura de duas camadas (vide a Figura 3.1). Uma

camada para resolver a questão da persistência dos dados, que utiliza um

Servidor de Dados e outra camada de aplicação, responsável pelo

processamento dos dados, que permite ao usuário acessar o Satcar através de

um desktop, laptop ou outro equipamento similar.

13

Figura 3. 1: Arquitetura do sistema (Uma visão geral)

O Satcar foi programado em Access que é um sistema de banco de

dados capaz de armazenar os dados solicitados (vide sítio [3]).

Durante toda a fase de planejamento e implementação do sistema

Satcar, foram feitos vários testes com o intuito de garantir que a integridade dos

dados incluídos no sistema fosse preservada. Também foram testadas todas as

operações internas a fim de verificar se estavam de acordo com as solicitações e

necessidades da Empresa.

A escolha do banco de dados em Access foi realizada por este ser um

Sistema de Gerenciamento de Banco de Dados Relacional (SGBDR), que provê

facilidades na prototipação e desenvolvimento do produto final, o sistema

proposto (vide sítio [3]).

14

4 MODELAGEM

Neste capítulo apresentamos inicialmente os requisitos do Satcar. Em

seguida são descritos os casos de uso que atendem aos requisitos. Para isso

vinculamos os casos de uso aos requisitos pertinentes, facilitando a leitura do

texto. Um diagrama de casos de uso complementa o entendimento geral das es-

pecificações.

Por último, foram construídos os diagramas de modelo de dados im-

plementado no SGBD e o diagrama de classes, que trata da codificação do Sat-

car.

4.1 REQUISITOS

Os requisitos, descritos na sequência, definem as especificações que

o Satcar deve conter para que sejam atendidas as necessidades do usuário.

4.1.1 REQUISITOS NÃO FUNCIONAIS

Os requisitos não funcionais são aqueles descrevem as qualidades do

sistema [6], listados na Tabela 4.1. Neste caso estão relacionados à segurança,

desempenho e hardware/software.

15

Tabela 4.1: Requisitos não funcionais.

Segurança RNF1: O software deve ser acessado apenas pelo usuá-

rio. Desempenho RNF2: Nas funcionalidades que demandarem algum tipo

de interação entre o usuário e o cliente, como por

exemplo, o cadastro do cliente, foi desenvolvida a

interface bem simples e objetiva, de forma que não

tome muito tempo, podendo ocasionar alguma in-

satisfação no cliente. Hardware/softwa-re

RNF3: O sistema precisará de uma máquina, com no míni-

mo 512 Mb de RAM e processador de 2.8 GHz ou

superior. O sistema pode ser executado nas

versões do Microsoft Windows superiores ao Win-

dows 98.

4.1.2 REQUISITOS FUNCIONAIS

Os requisitos funcionais são aqueles que especificam as ações que o

sistema deve ser capaz de executar [6], suas ações para cada entrada, ou seja,

é aquilo que descreve o que tem que ser feito pelo Satcar. Tais requisitos

compõem a Tabela 4.2.

16

Tabela 4. 2: Requisitos funcionais.

RF1: O software deve permitir o gerenciamento dos clientes (inclusão, exclusão

e alteração). RF2: O software deve permitir o gerenciamento dos fornecedores (inclusão, ex-

clusão e alteração).RF3: O software deve permitir o gerenciamento dos técnicos (inclusão, exclu-

são e alteração).RF4: O software deve permitir o gerenciamento do estoque dos equipamentos

(inclusão, exclusão e alteração). RF5: O software deve permitir o gerenciamento dos vendedores (inclusão, ex-

clusão e alteração).RF6: O software deve permitir o gerenciamento do(s) veículo(s) de cada cliente

(inclusão, exclusão e alteração).RF7: O software deve permitir o controle de execução dos serviços de instala-

ção (inclusão, exclusão e alteração). RF8: O software deve permitir a consulta e cadastramento dos pagamentos

efetuados pelos clientes.RF9: O software deve permitir registrar as vendas efetuadas pelos vendedores.

RF10: O software deve permitir a emissão de relatório dos clientes cadastrados.

RF11: O software deve permitir a emissão de relatório dos fornecedores.

RF12: O software deve permitir a emissão de relatório dos produtos em estoque.

RF13: O software deve permitir a emissão de relatório financeiro dos clientes ca-

dastrados.RF14: O software deve permitir a emissão de relatório dos técnicos cadastrados.

RF15: O software deve permitir a emissão de relatório dos vendedores cadastra-

dos.RF16: O software deve permitir a emissão de relatório das vendas efetuadas.RF17: O software deve permitir a emissão de relatório dos serviços prestados.

RF18: O software deve permitir a emissão de relatório dos pagamentos feitos

pelos clientes.RF19: O software deve permitir registrar o pagamento efetuado pelo cliente.

17

4.1 CASOS DE USO

Os casos de uso especificam o comportamento do sistema e descre-

vem a funcionalidade desempenhada pelos atores. (vide sítio [5]).

4.1.1 DESCRIÇÃO DOS ATORES

O ator é um ser humano ou entidade que interage com o sistema para

executar um trabalho significante [6]. (vide Figura 4.1)

4.1.2 DIAGRAMA DE CASOS DE USO

O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunica-

ção entre os analistas e o cliente [6]. Ele descreve um cenário que mostra as

funcionalidades do sistema do ponto de vista do usuário (vide Figura 4.1).

18

Figura 4. 1: Diagrama de Caso de Uso.

19

4.1.3 DESCRIÇÃO DOS CASOS DE USO

Os casos de uso foram descritos através de uma série de tópicos, pa-

dronizados segundo um modelo para a Especificação de Requisitos. No modelo

temos as informações necessárias para a compreensão dos diversos cenários

dos casos de uso, obedecendo a uma mesma organização de tópicos. Seguem

abaixo os tópicos e suas descrições foram incluídos no modelo descrito na Ta-

bela 4.3:

Tabela 4. 3: Modelo para a especificação dos requisitos.

Nome <define a sigla e o nome do caso de uso. Introduzidos na Figura 4.1>.Objetivo: <descreve o objetivo do caso de uso>.

Requisitos:<referência à Tabela 4.2 de requisitos que descreve os requisitos

atendidos por esse caso de uso>.Atores: <relaciona os atores que interagem como caso de uso>.Pré-condi-ções:

<descreve as pré-condições a serem atendidas para que o caso de

uso possa ser executado>.Trigger: <define o evento que dispara a execução desse caso de uso>.

Fluxo Prin-cipal:

<descreve as pré-condições a serem atendidas para que o caso de

uso possa ser executado>.

Fluxo Al-ternativo:

<descreve os fluxos alternativos do caso de uso, indicando que even-

to dispara cada um deles. Cada fluxo recebe a nomeação A1, A2,

etc>.Pós-condi-ções:

<define que produto ou resultado concreto o ator principal obterá ao

final da execução do fluxo básico>

Regras de negócio:

<lista as regras de negócios que devem ser respeitadas na execução

do caso de uso. Cada regra recebe a nomeação RN1, RN2 etc., e é

referenciada em algum fluxo do caso de uso (básico ou alternativo) >.Extensões: Cenários alternativos de sucesso ou fracasso.

20

4.1.3.1 UC01 – Cadastrar cliente

Objetivo: Permitir ao usuário cadastrar, alterar ou excluir um determi-

nado cliente.Requisitos: RF1Atores: Funcionário (Usuário), cliente.Pré-condições: Nenhuma.

Trigger:O ator aciona o cadastramento, alteração ou exclusão do cli-

ente.Fluxo Principal: 1. O Usuário verifica se o cliente já está cadastrado.

2. O cliente fornece seus dados pessoais. 3. O Usuário efetua o cadastramento.

Fluxo Alternativo: [A1] Cliente já cadastrado1. O Satcar apresenta uma mensagem informando

que não é possível efetuar o cadastramento, e

passa para o fluxo principal 2, fazendo dessa for-

ma alterações no cadastro.

[A2] Excluir cliente

1. O Usuário remove o cliente do sistema.

Extensões: Não há. Pós-condições: O Cliente é cadastrado e deverá informar os dados do seu

veiculo para cadastramento. Cadastrar veículo. Regras de negócio: Não há.

4.1.3.2 UC02 – Cadastrar veículo

Objetivo: Permitir ao ator cadastrar, alterar ou excluir o veiculo do cli-

21

ente.Requisitos: RF6Atores: Funcionário (usuário), cliente.Pré-condições: O cliente deve estar cadastrado no SatcarTrigger: O Usuário aciona o botão no formulário do cliente para abrir

o formulário de cadastramento de veículos.Fluxo Principal 1. O Usuário verifica se o cliente já possui veículo

cadastrado. 2. O cliente fornece os dados do veiculo. 3. O Usuário aciona o botão incluir.

Fluxo Alternativo: [A1] Veículo já cadastrado1. O Satcar apresenta uma mensagem informando

que não é possível efetuar o cadastramento, e

passa para o fluxo principal 2, fazendo dessa for-

ma alterações no cadastro.

[A2] Excluir veículo.

2. O Usuário remove os dados do veículo do siste-

ma.

Pós-condições: O veículo é cadastrado. Regras de negócio: RN1 – O chassi do veículo é de preenchimento obrigatório.

RN2 – Não podem existir dois veículos com o mesmo chas-

si.

4.1.3.3 UC03 – Cadastrar vendedor

Objetivo: Permitir ao ator cadastrar, alterar ou excluir vendedores.Requisitos: RF5Atores: Funcionário (usuário)Pré-condições: Nenhuma. Trigger: Não há.Fluxo Principal 1. O Usuário verifica se o vendedor está cadastrado.

22

2. O Usuário preenche os dados do vendedor.

3. O Usuário aciona o botão incluir.

Fluxo Alternativo: [A1] Vendedor já cadastrado

1. O Satcar apresenta uma mensagem informando

que não é possível efetuar o cadastramento, e

passa para o fluxo principal 2, fazendo dessa for-

ma alterações no cadastro.

[A2] Excluir vendedor.

2. O Usuário remove os dados do vendedor do sis-

tema.

Pós-condições: Não há.

Regras de negócio: Não há.Extensões: Não há.

4.1.3.4 UC04 – Cadastrar técnico

Objetivo: Permitir ao ator cadastrar, alterar ou excluir os técnicos.Requisitos: RF3Atores: Funcionário (usuário)Pré-condições: Nenhuma. Trigger: Não há.Fluxo Principal 1. O Usuário verifica se o técnico está cadastrado.

2. O Usuário preenche os dados do técnico.

3. O Usuário aciona o botão incluir.

23

Fluxo Alternativo: [A1] Técnico já cadastrado

1. O Satcar apresenta uma mensagem informando

que não é possível efetuar o cadastramento, e

passa para o fluxo principal 2, fazendo dessa for-

ma alterações no cadastro.

[A2] Excluir técnico.

2. O Usuário remove os dados do técnico do

sistema.

Pós-condições: Não há.

Regras de negócio: Não há.Extensões: Não há

4.1.3.5 UC05 – Cadastrar fornecedor

Objetivo: Permitir ao ator cadastrar, alterar ou excluir fornecedor. Requisitos: RF2Atores: Funcionário (usuário)Pré-condições: NenhumaTrigger: Não há. Fluxo Principal

Fluxo Alternativo:

1. O Usuário verifica se o fornecedor está cadastra-

do. 2. O Usuário preenche os dados do fornecedor. 3. O Usuário aciona o botão incluir.

[A1] Fornecedor já cadastrado1. O Satcar apresenta uma mensagem informando

que não é possível efetuar o cadastramento, e

24

passa para o fluxo principal 2, fazendo dessa for-

ma alterações no cadastro.[A2] Excluir fornecedor.

2. O Usuário remove os dados do fornecedor do

sistema.Não há.Não há.

4.1.3.6 UC06 – Cadastrar Equipamento

Objetivo: Permitir ao ator cadastrar, alterar ou excluir um equipamento

do estoque.Requisitos: RF4Atores: Funcionário (usuário)Pré-condições: O fornecedor deve estar cadastrado.Trigger: O ator aciona o formulário de Estoque.Fluxo Principal:

Fluxo Alternativo:

1. O Usuário verifica se o equipamento está cadas-

trado. 2. O Usuário preenche os dados do equipamento. 3. O Usuário aciona o botão incluir.

[A1] Equipamento já cadastrado1. O Satcar apresenta uma mensagem informando

que não é possível efetuar o cadastramento, e

passa para o fluxo principal 2, fazendo dessa for-

25

ma alterações no cadastro.

Pós-condições:Regras de negócio:

[A2] Excluir equipamento.2. O Usuário remove os dados do equipamento do

sistema.

Equipamento cadastrado. Poderá ser associado à venda.RN1 – O código de estoque é de preenchimento obrigatório.RN2 – O número de série é único, dessa forma não pode

dois equipamentos possuir o mesmo número de série. Extensões Não há

4.1.3.7 UC07 – Processar venda

Objetivo:Permitir ao ator registrar a venda do equipamento.

Requisitos: RF9Atores: Funcionário (Usuário)

Pré-condições: O vendedor deve estar cadastrado.

Trigger: O ator aciona o cadastramento do serviço.

Fluxo Principal

Fluxo Alternativo:

1. O ator aciona o botão adicionar registro.

2. O ator preenche o código da venda.

3. O ator preenche o código do vendedor que efetuou

a venda.

[A1] Venda já cadastrada 1. O Satcar não permite o cadastramento de ven-

das com o mesmo código.

26

Pós-condições:

A venda é cadastrada e será utilizada no processo de Ca-

dastramento dos serviços.

Não há.

4.1.3.8 UC08 – Efetuar Pagamento

Objetivo: Permitir ao ator cadastrar o pagamento efetuado pelo cliente.Requisitos: RF19Atores: Funcionário (usuário), cliente.Pré-condições: O cliente deve estar cadastrado.

Trigger: O ator aciona o formulário de cadastro de pagamento.Fluxo Principal 1. O cliente efetua o pagamento.

2. O usuário aciona o botão adicionar registro.

3. O usuário inclui os dados referentes ao pagamento.Fluxo secundário: Não há.

Pós-condições: Pagamento registrado. Poderá ser feito o controle através do

controle financeiro.

Regras de negócio: Não há.

27

4.1.3.9 UC09 – Preencher controle financeiro

Objetivo: Permitir ao ator fazer o cadastro e o controle dos pagamen-

tos efetuados pelos clientes.Requisitos: RF8Atores: Funcionário (Usuário)Pré-condições: O cadastro do pagamento já deve ter sido efetuado.Trigger: Não há.Fluxo Principal: 1. O ator informa o código do pagamento já cadastrado.

2. O ator informa a forma de pagamento e o valor do equipa-

mento.

Fluxo Alternativo: [A1] Ator solicita exclusão de um pagamento. 1. O ator aciona o botão excluir. 2. Para efetuar a exclusão total do registro de paga-

mento, o usuário deverá também excluir no cadastro do pa-

gamento.

Pós-condições: O controle de pagamento foi preenchido, e através dele po-

deremos ver todos os pagamentos efetuados pelos clientes.Regras de negócio: Não há.

28

4.1.3.10 UC10 – Cadastrar serviço

Objetivo: Permitir ao usuário cadastrar, alterar ou excluir um determi-

nado serviço.Requisitos: RF7Atores: Funcionário (Usuário)

Pré-condições:O cliente, o veiculo, a venda, o equipamento e o técnico já

devem ter sido cadastrados.

Trigger:O ator aciona o cadastramento, alteração ou exclusão do

serviço.Fluxo Principal: 1. O Usuário verifica se o serviço já está cadastrado.

2. O usuário verifica se a venda já foi cadastrada. 3. O Usuário efetua o cadastramento.

Fluxo Alternativo: [A1] Serviço já cadastrado2. O Satcar apresenta uma mensagem informando

que não é possível efetuar o cadastramento, e

passa para o fluxo principal 2, fazendo dessa for-

ma alterações no cadastro.

[A2] Excluir serviço

2. O Usuário remove o serviço do sistema.

Extensões: Não há. Pós-condições: O Serviço é cadastrado, finalizando o processo de venda e

instalação do equipamento.Regras de negócio: Não há.

29

4.1.3.11 UC11 – Emitir relatórios

Objetivo: Permitir ao ator consultar e emitir relatórios gerais.Requisitos: RF10, RF11, RF12, RF13, RF14, RF15, RF16, RF17 e

RF18. Atores: Funcionário (Usuário)Pré-condições: Todos os formulários relativos aos relatórios devem ter sido

preenchidos com pelo menos um registro.Trigger: O ator aciona a opção “relatórios principais” ou “outros rela-

tórios”.Fluxo Principal:

Fluxo secundário:Pós-condições:Regras de negócio:

1. O Satcar emite relatórios de todos os formulários relati-

vos à venda e ao cliente, assim como fornecedores e esto-

que. 2. O usuário poderá fazer a impressão do relatório que de-

sejar, ou apenas efetuar a consulta.

Não há.Não há.Não há.

30

4.2 DIAGRAMA DE CLASSES

O diagrama de classes é uma representação da estrutura e relações

das classes que servem de modelo para objetos [6]. É uma modelagem muito

útil para o sistema, define todas as classes que o sistema necessita possuir e é

a base para a construção dos diagramas de comunicação e estados (vide Figura

4.2). O código que definiu o Satcar é composto por 10 classes, a saber:

• Cliente – armazena os dados pertinentes ao cliente.

• Veiculo – armazena os dados pertinentes ao veiculo dos clientes.

• Vendedor – armazena os dados pertinentes aos vendedores.

• Técnico - armazena os dados pertinentes aos técnicos.

• Fornecedor – armazena os dados pertinentes aos fornecedores.

• Estoque – responsável pelo cadastramento e armazenamento dos

equipamentos.

• Pagamento – responsável por cadastrar os pagamentos efetuados

pelo cliente.

• Financeiro – responsável por manter um histórico dos pagamentos

efetuados pelo cliente, podendo o usuário fazer a consulta dos pa-

gamentos efetuados.

• Venda – responsável por armazenar os dados relativos à venda do

equipamento.

• Serviço – armazena os dados relativos ao serviço efetuado no vei-

culo do cliente.

31

Figura 4. 2: Diagrama de Classes

32

4.3 MODELO DE DADOS

Um Modelo de Dados é um conjunto de conceitos que podem ser usa-

dos para descrever a estrutura de uma base de dados. Por estrutura de uma

base de dados entendem-se os tipos de dados, relacionamentos e restrições

pertinentes aos dados (vide Figura 4.3).

Figura 4. 3: Modelo de Dados

33

5 IMPLENTAÇÃO E ANÁLISE CRÍTICA DO PROCESSO

Este capítulo aborda a implementação do Satcar e ao final é apresen-

tada uma análise crítica sobre o processo de implementação desse produto, que

inclui as facilidades e dificuldades encontradas durante a implementação.

5.1 IMPLEMENTAÇÃO

A implementação é apresentada através das janelas correspondentes

às funcionalidades contidas no menu principal (vide Figura 5.1).

Estas funcionalidades foram divididas da seguinte forma:

• Na seção 5.1.1 tratamos das funcionalidades relativas aos ca-

dastros efetuados no sistema.

• Em 5.1.2 tratamos das funcionalidades relativas aos serviços

tanto financeiros quanto técnicos.

• Em 5.1.3 são descritas tudo que é relativo ao equipamento,

como o estoque, por exemplo.

• Em 5.1.4 descrevemos a consulta dos principais relatórios do

sistema.

• E por último, o tópico 5.1.5 descreve a consulta dos demais re-

latórios do sistema.

34

5.1.1 CADASTROS

O usuário seleciona essa opção do menu para ter acesso cadastros

disponíveis no sistema. (vide Figura 5.1)

Figura 5. 1: Diagrama de Caso de Uso

Ao selecionar a primeira opção Cadastros, aparecerá a seguinte tela:

Figura 5. 2: Janela do Menu Cadastros

35

Neste item do Menu o usuário poderá fazer o cadastramento de clien-

tes, veículos, pagamentos, vendedores e técnicos, descritos na sequência (vide

Figura 5.2).

5.1.1.1 Tela de Cadastro de Clientes (UC01)

Para que seja feito o cadastramento dos clientes, o usuário deverá

selecionar a opção cadastro de clientes, no menu cadastros. Essa opção permi-

te que sejam lançados no sistema os dados pessoais de cada cliente, assim

como excluir ou alterar os dados de um determinado cliente já cadastrado. Te-

mos também a opção de imprimir o cadastro do cliente (vide Figura 5.3).

Figura 5. 3: Janela de Cadastro de Clientes

Após o cadastramento dos dados do cliente, deverá ser feito o cadas-

tramento do veículo do mesmo. Esta tarefa é realizada através do menu cadas-

tro de veículos, ou pressionando o botão que consta nesse próprio formulário.

Ao clicar nele, a tela para cadastramento do veiculo será aberta.

36

5.1.1.2 Tela de Cadastro de Veículos (UC02)

Esta opção do menu nos possibilita cadastrar o veículo do cliente, no

qual será instalado do equipamento. Também permite fazer exclusão ou altera-

ção dos dados. Os dados do veículo só poderão ser cadastrados após a inclu-

são do cliente, pois devemos vincular seu CPF no cadastro do veículo (vide Fi-

gura 5.4).

Figura 5. 4: Janela de Cadastro de Veículos

Após o cadastramento dos dados do cliente e veículo, deverá ser feito

o cadastramento dos serviços que vai ser efetuado no veículo do cliente. Isto po-

derá ser feito através do menu cadastro de serviços, ou através do botão que

consta nesse próprio formulário. Ao clicar nele, a tela para cadastramento do

serviço será aberta permitindo a inclusão, alteração ou exclusão de um determi-

nado serviço.

37

5.1.1.3 Tela de Cadastro de Pagamento (UC08)

Esta opção do menu permitirá ao usuário cadastrar o pagamento da

mensalidade do cliente (vide Figura 5.5).

Figura 5. 5: Janela de Cadastro de Pagamentos

38

5.1.1.4 Tela de Cadastro de Vendedor (UC03)

Este item do menu permite que sejam cadastrados os dados pessoais

dos vendedores, assim como alterar ou excluir vendedores já cadastrados (vide

Figura 5.6).

Figura 5. 6: Janela de Cadastro de vendedor

39

5.1.1.5 Tela de Cadastro de Técnico (UC04)

Selecionamos esta opção do menu para efetuar o cadastramento dos

técnicos da empresa, assim como possibilita que façamos alterações e ex-

clusões de algum dado que já fora cadastrado (vide Figura 5.7).

Figura 5.7 : Janela de Cadastro de técnicos

40

5.1.2 SERVIÇOS

Ao selecionar a segunda opção do Menu Principal poderemos cadas-

trar, visualizar, excluir e alterar o controle financeiro do cliente e também os ser-

viços efetuados no veículo de determinado cliente (vide Figura 5.8).

Figura 5.8 : Janela do Menu Serviços

41

5.1.2.1 Tela de Controle Financeiro (UC09)

Este item do menu de serviços permite ao usuário cadastrar e verificar

os pagamentos efetuados pelo cliente e que já foram cadastrados (vide Figura

5.9).

Figura 5. 9: Janela de Controle Financeiro

42

5.1.2.2 Tela de Cadastro de Serviços (UC10)

Esta opção permitirá que o usuário cadastre o serviço que será efetu-

ado pelo técnico em um veículo de determinado cliente. Como descrito na opção

cadastro de veiculo, este formulário também pode ser acessado através do for-

mulário de cadastramento do veiculo. Também permite que façamos alterações

ou exclusões em algum lançamento. Através desta opção podemos também vi-

sualizar o procedimento efetuado pelo técnico (vide Figura 5.10).

Figura 5. 10: Janela de Cadastro de Serviços

43

5.1.3 EQUIPAMENTOS

Este item do Menu Principal permite que o usuário faça o cadastra-

mento dos equipamentos comprados pela empresa no estoque. Assim como

permite cadastrar os fornecedores, ou fazer alteração ou exclusão de algum

dado do mesmo. Também é através deste menu de equipamentos que registra-

mos o processo de venda dos equipamentos. Em todos os itens é possível fazer

alterações e exclusões (vide Figura 5.11).

Figura 5. 11: Janela do Menu Equipamentos

44

5.1.3.1 Tela de Controle de Estoque (UC06)

Esta opção do Menu Equipamentos permite ao usuário fazer o cadas-

tramento, alterações e exclusões de equipamentos comprados pela empresa. O

Estoque é uma ferramenta muito importante para controle dos equipamentos, fa-

zendo prevenção da falta dos mesmos (vide Figura 5.12).

Figura 5. 12: Janela de Controle de Estoque

45

5.1.3.2 Tela de Cadastro de Fornecedores (UC05)

Nesta opção, o usuário poderá fazer o cadastramento dos dados dos

fornecedores de equipamentos. Nesta, também, podemos fazer alguma altera-

ção ou exclusão no cadastro de um fornecedor anteriormente cadastrado (vide

Figura 5.13).

Figura 5.13: Janela de Cadastro de Fornecedor

46

5.1.3.3 Tela de Venda de equipamentos (UC07)

Este item do meu de equipamentos permitirá que o usuário cadastre o

processo de venda do equipamento, registrando o valor que deve ser pago e o

vendedor que efetuou a venda (vide Figura 5.14).

Figura 5. 14: Janela de venda de equipamentos

47

5.1.4 RELATÓRIOS PRINCIPAIS (UC11)

Este item do Menu Principal permite que se faça a consulta dos dados

de cadastramento de diversos formulários. Isto possibilita verificar quantos regis-

tros temos se há necessidade de alteração em algum cadastro, ou até mesmo

para ser feita a impressão se for da vontade do cliente (vide Figura 5.15).

Figura 5. 15: Janela de Relatórios Principais

Através desta opção poderemos emitir os relatórios dos clientes ca-

dastrados, os relatórios financeiros dos clientes, o relatório de equipamentos em

estoque e o relatório de fornecedores cadastrados.

48

5.1.4.1 Modelo de Relatório de Cadastro de Clientes (RF10)

Neste relatório temos a lista de todos os clientes cadastrados no siste-

ma (vide Figura 5.16).

Figura 5. 16: Janela de Relatórios de Cadastro de Clientes

5.1.4.2 Modelo de Relatório de Controle Financeiro (RF13)

Neste relatório podemos verificar os dados de todos os pagamentos

efetuados pelos clientes (vide Figura 5.17).

Figura 5. 17: Janela de Relatório de Controle Financeiro

49

5.1.4.3 Modelo de Relatório de Estoque (RF12)

Neste relatório podemos obter todos os dados dos equipamentos em

estoque (vide Figura 5.18).

Figura 5. 18: Janela de Relatório de Estoque

5.1.4.4 Modelo de Relatório de Cadastro de Fornecedor (RF11)

Neste relatório listamos os dados de todos os fornecedores (vide Fi-

gura 5.19).

Figura 5. 19: Janela de Relatório de Cadastro de Fornecedor

50

5.1.5 Outros Relatórios (UC11)

Neste item temos, também, a possibilidade de emissão e visualização

de relatórios. No entanto, são relatórios secundários, que não serão muito aces-

sados pelo usuário (vide Figura 5.20).

Figura 5. 20: Janela de Outros Relatórios

Através desta opção poderemos emitir os relatórios do processo de

venda de equipamentos, relatório de pagamentos dos clientes, relatório dos ser-

viços efetuados nos veículos dos clientes e relatório dos técnicos e vendedores

da empresa.

51

5.1.5.1 - Modelo de Relatório de Venda de Equipamentos (RF16)

Neste relatório temos os dados de todas as vendas cadastradas no

sistema (vide Figura 5.21).

Figura 5. 21: Janela de Relatório de Venda de Equipamentos

5.1.5.2 - Modelo de Relatório de Cadastro de Pagamentos (RF18)

Neste relatório podemos acompanhar os dados de todos os paga-

mentos de mensalidades feitas pelos clientes (vide Figura 5.22).

Figura 5. 22: Janela de Relatório de Cadastro de Pagamentos

52

5.1.5.3 - Modelo de Relatório de Cadastro de Serviços (RF17)

Neste relatório podemos verificar os dados de todos os serviços efetu-

ados nos veículos (vide Figura 5.23).

Figura 5. 23: Janela de Relatório de Cadastro de Serviços

5.1.5.4 - Modelo de Relatório de Cadastro de Técnicos (RF14)

Neste relatório temos a lista com os dados de todos técnicos da Em-

presa (Vide Figura 5.24).

Figura 5. 24: Janela de Relatório de Cadastro de Técnicos

53

5.1.5.5 - Modelo de Relatório de Cadastro de Vendedor (RF15)

Neste relatório podemos verificar os dados de todos os vendedores

da Empresa (vide Figura 5.25).

Figura 5. 25: Janela de Relatório de Cadastro de Vendedor

54

5.2 ANÁLISE CRÍTICA DO PROCESSO

O processo de desenvolvimento teve como base a matéria de Banco

de Dados, oferecida pelo curso do Cederj.

O levantamento dos requisitos foi facilitado pela experiência do autor

em projetos anteriores e no próprio domínio do modelo. Entretanto, a falta de

compreensão plena do que seria um modelo de projeto “puro” permanece, já

que a padronização determinada pelo TCC de alguma forma prejudica o forma-

lismo, do que seria aquele documento.

Os desenhos dos modelos foram elaborados utilizando a ferramenta

Jude, que provê diagramas UML e diagramas adicionais, facilitando o processo

de desenvolvimento do mesmo (vide sítio [4], de uso livre).

O autor faz uso diário do Satcar de forma disciplinada. Não há objeti-

vo comercial na produção desse sistema, e sim, principalmente, permitir ao autor

um mecanismo que controle uma empresa de rastreamento.

55

CONCLUSÕES

Esta monografia teve como objetivo principal não só apresentar o for-

mato da documentação pertinente ao desenvolvimento de um sistema de infor-

mação, mas também ter como um resultado o produto deste desenvolvimento,

ou seja, o Satcar.

O ciclo de vida de desenvolvimento do Satcar prossegue, já que no

domínio do modelo ainda existe espaço para o crescimento do Satcar. Dessa

forma, o autor entende que o Satcar não está finalizado, há muito que fazer ain-

da no sentido de agregar novas funcionalidades ao mesmo, o que pode implicar

em futuras adaptações do sistema.

Assim sendo, é de interesse do autor prosseguir em seus estudos no

sentido de obter maior conhecimento, não só com vistas ao aprimoramento do

Satcar, mas também, com o propósito de desenvolver outros softwares, ainda na

área de sistemas de informação.

56

REFERÊNCIAS BIBLIOGRÁFICAS

1. Global Safe, http://www.globalsafe.com.br - acessado em 01/10/2010.

2. Satcom Rastreadores, http://www.satcomrastreadores.com.br – acessado

em 02/10/2010

3. UFPEL, http://ci.ufpel.edu.br/treinamento/apostilas/microsoft_office/m_offi-

ce97/access/o_que_e.pdf - acessado em 30-09-10

4. Jude, http://jude.change-vision.com/, acessado em 30-09-10

5. UFCG Sistema de Computação http://www.dsc.ufcg.edu.br/~sampaio/cur-

sos/2007.1/Graduacao/SI-II/Uml/diagramas/usecases/usecases.htm ,

acessado em 30-09-10

6. UFCG Sistema de Computação http://www.dsc.ufcg.edu.br/~jacques/cur-

sos/map/html/uml/diagramas/classes/classes1.htm , acessado em 30-09-

10

7. Bezerra, Eduardo. Princípios de Analise e Projeto de Sistemas UML 1ªEd.

,Editora Campus, 2006 (ISBN - 8535216960)

57