Graduacao Informatica Sistemas Downloads Tcc2k7-2 MarcioBarretoSantana

1
ESTUDO E CONSTRUO DE UM
SOFTWARE PARA CONTROLE DE
USURIOS DE ESTACIONAMENTOS
PARA A EMPRESA E1 - SIS-E1

MRCIO BARRETO SANTANA

Porto Alegre
2007

2

MRCIO BARRETO SANTANA

ESTUDO E CONSTRUO DE UM
SOFTWARE PARA CONTROLE DE
USURIOS DE ESTACIONAMENTOS
PARA A EMPRESA E1 - SIS-E1

Trabalho de Concluso de Curso II
apresentado Faculdade de
Informtica, como requisito parcial
obteno do ttulo de Bacharel em
Sistemas de Informao.

Orientador: Prof. Dr. Sidnei Renato
Silveira.

Porto Alegre
2007

3

Dedico este trabalho a meu filho
Cristian que desde o dia de seu
nascimento tem sido a razo do meu
viver e a motivao para a busca do
conhecimento contnuo para que eu
possa lhe transmitir.

4

Aos meus pais, irmos, professores,
colegas da graduao, ao coordenador
e orientador do Curso de Informtica
Dr. Sidnei Renato Silveira e
principalmente ao Dr. Roberto Carlos
Ritter Vieira que sem ele no seria
possvel o meu ingresso e concluso
da graduao.

5

RESUMO

Uma das vrias exigncias do mercado de trabalho que seus
candidatos possuam formao superior para ocupar os cargos ofertados,
aumentando a procura por Instituies que oferecem ensino superior, a fim de
se qualificarem ainda mais. Esta procura tem demandado s instituies de
ensino um aumento significativo de vagas em seus estacionamentos, como foi
o caso do UniRitter no campus de Porto Alegre. Devido necessidade destas
novas vagas de estacionamento, foi construdo um novo edifcio garagem, que
aumentou em mais de quinhentas o nmero de vagas destinadas aos alunos,
professores, funcionrios e visitantes do UniRitter, criando a necessidade de
um controle e gerenciamento eficiente. A partir da necessidade deste controle
que surgiu a oportunidade de realizar um Sistema de Informao que
atendesse aos requisitos da empresa terceirizada responsvel pelo
gerenciamento do estacionamento do UniRitter Campus Porto Alegre, a E1
Estacionamentos. Para a implementao do Sistema de Informao para
controle do estacionamento, foram realizados alguns encontros com os
responsveis da Empresa E1 Estacionamentos, para realizar a especificao
de requisitos e a partir destas, iniciou-se a fase de planejamento para a
implementao do sistema, alm de ser traado um comparativo com outros
sistemas com a mesma finalidade de controle e ou gerenciamento para
estacionamentos. A fase de projeto do sistema consistiu em construir o modelo
E-R (Entidade-Relacionamento) do banco de dados a partir dos diagramas
gerados atravs das especificaes da UML (Unified Modeling Language). A
segunda etapa envolveu a implementao e a validao do sistema,
juntamente com os usurios do atual Sistema da Empresa E1
Estacionamentos.
Palavras-Chave: Sistemas de Informao, Gerenciamento de
Estacionamentos

6

ABSTRACT

One of the many requirements of the working world is that candidates
have higher education to occupy the job positions offered, increasing the
demand for universities in order to be even more qualified. This has caused a
significant increase in need of vacancies in parking lots of the universities, as
was the case of UniRitter in the Porto Alegre Campus. Due to the need of these
new parking spaces, a new garage building was constructed, which increased
by more than five hundred the number of places for students, teachers, staff
and visitors to UniRitter, creating the need for control and efficient management.
From this need of control, the opportunity to come up with an Information
System that would serve the requirements rose from the outsourcing company
responsible for the management of the parking lot of the UniRitter Porto Alegre
Campus and the E1 Parking lot. There has been some meetings with those
responsible for the E1 Parking Enterprise to implement the Information System
for control of the parking lot, for the specification of requirements, and from
these on, for the process of planning the implementation of the system, as well
as drawing a comparison to other systems with the same purpose of control
and/or management of parking lots. The design phase of the system was to
build the model ER (Entity - Relationship) from the database starting from
diagrams generated by the specification of UML (Unified Modeling Language).
The second stage involved the implementation and validation of the system,
along with users of the current system of the E1 Parking Company.

Keywords: Information Systems, Parking Management

7

LISTA DE ABREVIATURAS E SIGLAS

ER Entidade-Relacionamento
GUI Graphical User Interface
IP Internet Protocol
OMT Object Modeling Technique
OOP Object Oriented Programming
OOSE Object Oriented Software Engineering
TCC Trabalho de Concluso de Curso
RUP Rational Unified Process
SGBD Sistema Gerenciador de Banco de Dados
UML Unified Modeling Language

8

LISTA DE FIGURAS

FIGURA 01 - Arquitetura geral do RUP (RATIONAL UNIFIED PROCESS,
2007).................................................................................................................19
FIGURA 02 - Ferramentas e melhores prticas (RATIONAL UNIFIED
PROCESS, 2007). ............................................................................................20
FIGURA 03 - Fases do RUP (RATIONAL UNIFIED PROCESS, 2007). ...........21
FIGURA 04 - Grfico das fases de construo no RUP (RATIONAL UNIFIED
PROCESS, 2007). ............................................................................................22
FIGURA 05 - Redefinio do produto ou da arquitetura (RATIONAL UNIFIED
PROCESS, 2007). ............................................................................................23
FIGURA 06 - Tela inicial do Sistema Park Service ...........................................34
FIGURA 07 - Cadastro de valores Sistema Park Service.................................34
FIGURA 08 - Cadastro de mensalistas.............................................................35
FIGURA 09 - Exemplo de relatrio do Park Service .........................................36
FIGURA 10 - Tela inicial do Sistema Gerenciador de Estacionamentos da
Pazello..............................................................................................................38
FIGURA 11 - Cadastro de valores no Sistema Pazello.....................................39
FIGURA 12 - Cadastro de mensalistas no Sistema Pazello .............................40
FIGURA 13 - Relatrio de caixa no Sistema Pazello........................................41
FIGURA 14 - Hardware para automao de estacionamentos da Aucon.........43
FIGURA 15 - Modelo ER ..................................................................................49
FIGURA 16 - Diagrama de Classes..................................................................51
FIGURA 17 - Diagrama de Casos de Uso ........................................................52
FIGURA 18 - Diagrama de Seqncia Cadastrar Cliente.................................53
FIGURA 19 - Diagrama de Seqncia Cadastrar Tipo Cliente .........................54
FIGURA 20 - Diagrama de Seqncia Cadastrar Valor Crdito .......................55

9

FIGURA 21 - Diagrama de Seqncia Cadastrar Acesso Entrada...................56
FIGURA 22 - Diagrama de Seqncia Cadastrar Acesso Sada ......................57
FIGURA 23 - Diagrama de Seqncia Cadastrar Usurio................................58
FIGURA 24 - Diagrama de Seqncia Cadastrar Tipo Usurio........................59
FIGURA 25 - Diagrama de Seqncia Cadastrar Permisso Usurio..............60
FIGURA 26 - Diagrama de Seqncia Cadastrar Compra Crdito...................61
FIGURA 27 - Tela principal do SIS-E1..............................................................63
FIGURA 28 - Formulrio de login......................................................................64
FIGURA 29 - Formulrio de entrada.................................................................65
FIGURA 30 - Formulrio de sada ....................................................................66
FIGURA 31 - Formulrio consulta de crditos disponveis ...............................67
FIGURA 32 - Formulrio cadastro de valores para crditos .............................69
FIGURA 33 - Formulrio cadastro de tipos de clientes.....................................70
FIGURA 34 - Formulrio cadastro de clientes ..................................................71
FIGURA 35 - Formulrio cadastro de permisses para grupos de usurios.....72
FIGURA 36 - Formulrio relatrio de acessos ..................................................73
FIGURA 37 - Formulrio relatrio de condutor .................................................74
FIGURA 38 - Formulrio relatrio de movimento de caixa ...............................76
FIGURA 39 - Formulrio relatrio de movimento de caixa com dados.............77
FIGURA 40 - Relatrio de movimento de caixa com dados gerados para a
impressora........................................................................................................77
FIGURA 41 - Formulrio relatrio de movimento estornado.............................78

10

LISTA DE GRFICOS

GRFICO 01 - Usurios do sistema participantes da validao.......................80
GRFICO 02 - Layout do sistema ....................................................................81
GRFICO 03 - Facilidade de acesso s opes (funcionalidades) do sistema 82
GRFICO 04 - Disposio das funcionalidades do sistema.............................83
GRFICO 05 - Relatrios gerados pelo sistema ..............................................84
GRFICO 06 - Controle de acesso ao sistema por usurio (Login) .................85
GRFICO 07 - Crditos nos cartes de identificao dos alunos.....................86
GRFICO 08 - Localizar condutores de veculos .............................................87
GRFICO 09 - No existe limitao quanto ao nmero de crditos.................88
GRFICO 10 - Possibilidade de estornar os movimentos do caixa..................89
GRFICO 11 - Visualizar movimentos estornados...........................................90
GRFICO 12 - Comparao entre SIS-E1 e o atual Sistema...........................91

11

SUMRIO

INTRODUO................................................................................................. 13
1 REFERENCIAL TERICO........................................................................... 15
1.1 Interface Grfica ........................................................................................ 15
1.2 Programao Orientada a Objetos (OOP) ................................................. 16
1.2.1 Unified Modelling Language (UML)......................................................... 17
1.3 Rational Unified Process (RUP)................................................................. 18
1.3.1 Fases do RUP......................................................................................... 20
1.3.1.1 Fase de Planejamento......................................................................... 21
1.3.1.1.1 Fase de Iniciao.............................................................................. 23
1.3.1.1.2 Fase de Elaborao.......................................................................... 24
1.3.1.1.3 Fase de Construo.......................................................................... 25
1.3.1.1.4 Fase de Transio ............................................................................ 26
1.4 Redes de Computadores ........................................................................... 27
1.5 Banco de Dados ........................................................................................ 29
1.5.1 Projeto do Banco de Dados .................................................................... 30
1.6 Tecnologias para automao de Estacionamentos ................................... 31
2 TRABALHOS RELACIONADOS ................................................................. 33
2.1 Park Service............................................................................................... 33
2.2 Gerenciador de Estacionamento Pazello Solues em Software ........... 36
2.3 Aucon Automao...................................................................................... 41
3 SOLUO PROPOSTA............................................................................... 44
3.1 Modelagem de Soluo Proposta.............................................................. 46
3.1.1 Diagrama de Classes.............................................................................. 50
3.1.2 Diagrama de Casos de Uso.................................................................... 52
3.1.3 Diagramas de Seqncia........................................................................ 53

12

4 IMPLEMENTAO DO SIS-E1.................................................................... 62
4.1 Validao do sistema SIS-E1..................................................................... 79
CONSIDERAES FINAIS............................................................................. 93
ANEXO 1......................................................................................................... 95
ANEXO 2......................................................................................................... 97
REFERNCIAS............................................................................................... 98

13

INTRODUO

Devido grande exigncia do mercado de trabalho atual, as pessoas,
para conquistarem uma vaga, devem estar cada vez mais qualificadas. Uma
entre tantas destas qualificaes a realizao de um curso de graduao,
que tem levado a cada semestre uma quantidade razovel de alunos para as
salas das Instituies de Ensino Superior. Neste sentido, outro e no menos
importante problema a ser resolvido a disponibilidade de vagas nos
estacionamentos das instituies e o controle de entrada e sada juntamente
com a movimentao financeira dos mesmos.
Pensando-se nesta necessidade de administrar os estacionamentos e a
qualificao especfica de cada tipo de estacionamento no que tange aos
Sistemas de Informao, tem-se aqui uma valiosa fatia do mercado para ser
explorado pela Tecnologia da Informao.
No caso especfico do estacionamento do UniRitter, a empresa E1
necessita de algumas funcionalidades que no so contempladas por
ferramentas de software existentes no mercado. Algumas ferramentas
existentes possuem muitos recursos, mas seu custo extremamente caro.
Sendo assim, desenvolveu-se um Sistema de Informao para o Controle do
Estacionamento do UniRitter, voltado s necessidades da comunidade
acadmica e com baixo custo.
Alm do exposto acima, o desenvolvimento do sistema proposto permitiu
a aplicabilidade dos conhecimentos adquiridos durante o curso de graduao,
possibilitando a implementao de um sistema seguindo as fases de anlise de
requisitos, modelagem, implementao, testes e validao, integrando
conceitos de programao, modelagem, bancos de dados e redes de
computadores.

14

O objetivo principal a ser alcanado com a realizao deste projeto Final
de Curso foi o estudo, modelagem e construo de um Sistema de Informao
para controle do estacionamento da empresa E1, nos domnios do UniRitter, no
campus de Porto Alegre.
Como objetivos especficos para este trabalho, propem-se:
1. Estudar aspectos que envolvam o desenvolvimento de Sistemas
de Informao, envolvendo a modelagem e interface;
2. Estudar Sistemas de Informao existentes para o controle de
estacionamentos;
3. Estudar a linguagem de programao Visual Basic.NET;
4. Estudar o Banco de Dados Firebird;
5. Estudar a ferramenta JUDE Community;
6. Definir os requisitos para a construo do sistema junto
empresa E1;
7. Definir as funcionalidades da aplicao;
8. Implementar o sistema proposto;
9. Validar o sistema junto aos usurios.
O presente trabalho est organizado da seguinte forma: o captulo 1
apresenta o referencial terico o qual fundamenta as tcnicas que sero
utilizadas para a construo do sistema proposto. O captulo 2 apresenta
trabalhos relacionados com a mesma rea do sistema, apresentando as
principais vantagens e desvantagens de cada sistema estudado. O captulo 3
apresenta a modelagem do sistema proposto, incluindo o modelo E-R,
diagramas de classe, caso de uso e seqncia. O captulo 4 apresenta as
informaes referentes implementao do sistema. Encerrando o trabalho,
so apresentadas as concluses e as referncias bibliogrficas utilizadas.

15

1 REFERENCIAL TERICO

Este captulo apresenta algumas informaes sobre as reas
envolvidas no desenvolvimento do sistema proposto, envolvendo Interfaces
Grficas, Programao Orientada a Objetos, Redes de Computadores, Banco
de Dados e Tecnologias para automao e gerenciamento de
Estacionamentos.

1.1 Interface Grfica

Uma grande parte dos Sistemas de Informao voltados para o
gerenciamento de estacionamentos no utiliza interfaces grficas. Acredita-se
que as ferramentas sejam implementadas utilizando-se interfaces baseadas em
texto, com sistema operacional MS-DOS, para agilizar a operao atravs das
teclas de atalhos. No entanto, as ferramentas que utilizam Interfaces Grficas,
tambm tm a possibilidade de se valer do recurso de teclas de atalhos assim
como de outros recursos mais avanados, proporcionando a mesma agilidade
no momento de se manusear o sistema e proporcionando uma interface mais
agradvel ao usurio.
Interface grfica do usurio - GUI (Graphical User Interface) um
mecanismo de interao homem-computador onde o usurio capaz de
selecionar esses smbolos e manipul-los de forma a obter algum resultado
prtico. Esses smbolos so designados de widgets e so agrupados em kits
(ROCHA, 2001).
Os smbolos so formas grficas de representar o que, em interfaces
baseadas em texto, s podia ser feito por linhas de comandos, ou seja, para

16

abrir determinado arquivo era necessrio realizar a escrita open + o nome do
arquivo. Considerando-se uma interface grfica, basta clicar sobre o smbolo
correspondente para abrir o arquivo desejado. Este processo possvel graas
aos comandos associados aos smbolos e no visveis aos usurios, j que
para o mesmo importa apenas a funcionalidade do aplicativo e no como o
mesmo faz para realizar as tarefas solicitadas (ROCHA, 2001).
Neste sentido, o sistema desenvolvido utiliza uma interface grfica, j
que as interfaces baseadas em caracter, de certa forma, esto ultrapassadas.
Como foi mencionado anteriormente, as interfaces grficas incorporam
as mesmas funcionalidades das baseadas em texto e outras tantas no
suportadas pelas mesmas, alm claro das questes estticas, que neste
caso convidaro sutilmente o usurio a utilizar o sistema proposto neste
trabalho.

1.2 Programao Orientada a Objetos (OOP)

Um recurso muito utilizado na programao de computadores o
paradigma da programao orientada a objetos (OOP Object Oriented
Programming). Este recurso est disponvel em vrias linguagens de
programao tais como Java, Delphi e Visual Basic.NET, que ser a linguagem
utilizada para a realizao do aplicativo proposto (SILVEIRA, 2006).
Dentro do paradigma de OOP um programa visto como uma coleo
de Objetos (como no mundo real), que se caracterizam por possurem aes
prprias e que se comunicam entre si. Os atributos so as estruturas dos
objetos e os mtodos so a forma de manipular estes atributos (SILVEIRA,
2006).
Uma das vrias vantagens da programao OOP a reutilizao do
cdigo, atravs da definio de classes. Uma classe pode ser ampliada ou
reduzida quando necessrio (SILVEIRA, 2006).
A classe nada mais do que um abstrato. Abstrato aquilo que opera
fora do mbito concreto; em outras palavras, aquilo que possui um alto grau
de generalizao. Por exemplo, se trs pessoas imaginarem uma outra pessoa,

17

cada uma destas pessoas imaginar uma outra com caractersticas que podem
ser iguais e/ou diferentes entre as trs e nem por isto elas no vo ser
pessoas. Este o conceito de abstrao, que uma das formas de se
trabalhar com programao OOP (MARTIM, 2007).
Eventos so todas as coisas que acontecem dentro de uma
determinada classe. Por exemplo: considerando-se uma classe chamada
Pessoa (sendo que esta pessoa tem nome, idade, sexo e altura) e supondo-se
que esta pessoa tinha a altura de 1,7m. Decorrido um perodo de tempo de
dois anos ela aumentou quatro centmetros. Este crescimento de quatro
centmetros um evento que ocorreu dentro da classe, no atributo altura
(MARTIM, 2007).
Em especial, neste trabalho, a OOP utilizada na declarao de
classes e na implementao dos mtodos, atravs do desenvolvimento do
sistema proposto utilizando-se a linguagem de programao Visual Basic.NET.

1.2.1 Unified Modelling Language (UML)

UML um sistema de notao (incluindo a semntica para suas
notaes) dirigida modelagem de sistemas, usando conceitos orientados a
objetos (LARMAN, 2000).
A UML um padro emergente, que est sendo aceito pela indstria,
para a modelagem orientada a objetos. Ela comeou como um esforo
conjunto de Grady Booch e Jim Rumbaugh em 1994, para combinar seus dois
mtodos populares os mtodos Booch e OMT (Object Modeling Technique).
Mais tarde, Ivar Jacobson se juntou a eles (o criador do mtodo OOSE, Object
Oriented Software Engineering). Em resposta a uma solicitao do OMG
(Object Management Group), uma entidade de padronizao estabelecida pela
indstria, para definir uma linguagem e notao de modelagem padronizada, a
UML foi submetida como candidata em 1997 (LARMAN, 2000).
O OMG aceitou a UML, a qual tambm recebeu a aprovao de fato
pela indstria, uma vez que seus criadores (Grady Booch, Jim Rumbaugh e
Ivar Jacobson) representam os mtodos de anlise e/ou projeto de primeira

18

gerao, mediante que os mesmos j eram prestadores de servios na rea,
sendo eles muito populares (LARMAN, 2000).
Muitas organizaes de desenvolvimento de software, alm de
fornecedores de ferramentas CASE adotaram a UML e outros tantos esto
adotando-a. muito provvel que ela se torne um padro mundial utilizado por
desenvolvedores, autores e fornecedores de ferramentas CASE (LARMAN,
2000).
No projeto proposto, a utilizao da UML no diferente dos demais
casos mencionados anteriormente; ela tem a mesma funo de modo a se
adequar aos padres de modelagem j praticados por organizaes da rea de
desenvolvimento de Sistemas de Informao.

1.3 Rational Unified Process (RUP)

O Rational Unified Process (tambm chamado de processo RUP) um
processo de engenharia de software, que oferece uma abordagem baseada em
disciplinas para atribuir tarefas e responsabilidades dentro de uma organizao
de desenvolvimento. Sua meta garantir a produo de software de alta
qualidade, que atenda s necessidades dos usurios dentro de um cronograma
e de um oramento previsvel. (KRUCHTEN,2003)
No caso especfico deste trabalho no ser considerada a questo
custo para o desenvolvimento do projeto, assim como os membros da equipe
de desenvolvimento, mediante que o mesmo no fruto de um produto
comercial e sim acadmico.

19

A figura 01 mostra a arquitetura geral do RUP.

FIGURA 01: Arquitetura geral do RUP (RATIONAL UNIFIED PROCESS, 2007).

O RUP tem duas dimenses:
O eixo horizontal representa a linha de tempo e mostra os aspectos do
ciclo de vida do processo medida que o mesmo desenvolvido;
O eixo vertical representa as disciplinas, que agrupam as atividades de
maneira lgica , por natureza.
A primeira dimenso representa o aspecto dinmico do processo
quando ele aprovado e expressa em termos de fases, iteraes e marcos.
A segunda dimenso representa o aspecto esttico do processo, como ele
descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho,
artefatos e papis do processo.
No caso do presente trabalho a aprovao do projeto ocorre logo aps
o levantamento de requisitos para o mesmo

20

O RUP mostra como possvel aplicar as melhores prticas de
engenharia de software e usar ferramentas para automatizar o processo de
desenvolvimento de software, conforme mostra a figura 02.

FIGURA 02: Ferramentas e melhores prticas (RATIONAL UNIFIED PROCESS, 2007).

1.3.1 Fases do RUP

A partir de uma perspectiva de gerenciamento, o ciclo de vida de
software do RUP dividido em quatro fases seqenciais, que so:
- Iniciao;
- Elaborao;
- Construo e
- Transio.
Cada uma destas fases concluda por um marco principal, ou seja,
cada fase basicamente um intervalo de tempo entre dois marcos principais.
Em cada final de fase executada uma avaliao para determinar se os
objetivos da fase foram alcanados. Uma avaliao satisfatria permite que o
projeto passe para a prxima fase (KRUCHTEN,2003).

21

A figura 03 apresenta as quatro fases, assim como seus marcos
principais.

FIGURA 03: Fases do RUP (RATIONAL UNIFIED PROCESS, 2007).

1.3.1.1 Fase de Planejamento

As fases no so idnticas em termos de programao e esforo.
Embora isso varie muito de acordo com o projeto, um ciclo de desenvolvimento
inicial tpico para um projeto de mdio porte deve prever a seguinte distribuio
de esforo e programao (KRUCHTEN,2003).
O quadro 01 apresenta a relao entre as fases x esporos e
programao.

Quadro 01 - Fases x esforos e programao
Iniciao Elaborao Construo Transio
Esforo ~5% 20% 65% 10%
Programao 10% 30% 50% 10%

22

Este ciclo de desenvolvimento pode ser descrito graficamente como
mostra a Figura 04.

FIGURA 04: Grfico das fases de construo no RUP (RATIONAL UNIFIED PROCESS, 2007).

Para um ciclo de evoluo, as fases de iniciao e de elaborao
seriam bem menores. Ferramentas que automatizam parte do esforo de
construo podem amenizar isso, tornando a fase de construo muito menor
do que as fases de iniciao e de elaborao juntas (KRUCHTEN,2003).
Uma passagem pelas quatro fases um ciclo de desenvolvimento;
cada passagem pelas quatro fases produz uma gerao do software. A menos
que o produto "desaparea", ele ir se desenvolver na prxima gerao,
repetindo a mesma seqncia de fases de iniciao, elaborao, construo e
transio, mas agora com nfase diferente nas diversas fases. Esses ciclos
subseqentes so chamados de ciclos de evoluo. medida que o produto
atravessa vrios ciclos, so produzidas novas geraes (KRUCHTEN,2003).

23

Os ciclos de evoluo podem ser disparados por melhorias sugeridas
pelos usurios, mudanas no contexto do usurio, mudanas na tecnologia
subjacente, reao concorrncia e assim por diante. Normalmente, os ciclos
de evoluo tm fases de Iniciao e Elaborao bem menores, pois a
definio e a arquitetura bsicas do produto foram determinadas por ciclos de
desenvolvimento anteriores. So excees a essa regra os ciclos de evoluo
em que ocorre uma redefinio significativa do produto ou da arquitetura,
conforme mostra a figura 05 (KRUCHTEN,2003).

FIGURA 05: Redefinio do produto ou da arquitetura (RATIONAL UNIFIED PROCESS, 2007).

1.3.1.1.1 Fase de Iniciao

A meta dominante da fase de iniciao atingir o consenso entre
todos os envolvidos sobre os objetivos do ciclo de vida do projeto. A fase de
iniciao tem muita importncia principalmente para os esforos dos
desenvolvimentos novos, nos quais h muitos riscos de negcios e de
requisitos que precisam ser tratados para que o projeto possa prosseguir. Para
projetos que visam melhorias em um sistema existente, a fase de iniciao
mais rpida, mas ainda se concentra em assegurar que o projeto seja
compensatrio e que seja possvel faz-lo (KRUCHTEN,2003).

Os objetivos principais da fase de iniciao incluem
(KRUCHTEN,2003).

24

- Estabelecer o escopo do software do projeto e as condies limite,
incluindo uma viso operacional, critrios de aceitao e o que
deve ou no estar no produto;
- Discriminar os casos de uso crticos do sistema, os principais
cenrios de operao e o que direcionar as principais trocas de
design;
- Exibir, e talvez demonstrar, pelo menos uma opo de arquitetura
para alguns cenrios bsicos;
- Estimar o custo geral e a programao para o projeto inteiro (e
estimativas detalhadas para a fase de elaborao imediatamente a
seguir);
- Estimar riscos em potencial (as origens de imprevistos);
- Preparar o ambiente de suporte para o projeto.

1.3.1.1.2 Fase de Elaborao

A meta da fase de elaborao criar a baseline para a arquitetura do
sistema, a fim de fornecer uma base estvel para o esforo da fase de
construo. A arquitetura se desenvolve a partir de um exame dos requisitos
mais significativos (aqueles que tm grande impacto na arquitetura do sistema)
e de uma avaliao de risco. A estabilidade da arquitetura avaliada atravs
de um ou mais prottipos de arquitetura (KRUCHTEN,2003).
Os objetivos primrios da fase de elaborao incluem
(KRUCHTEN,2003):
- Assegurar que a arquitetura, os requisitos e os planos sejam estveis
o suficiente e que os riscos sejam suficientemente diminudos a fim
de determinar com segurana o custo e a programao para a
concluso do desenvolvimento. Para a maioria dos projetos,
ultrapassar essa marca tambm corresponde transio de uma
operao rpida e de baixo risco para uma operao de alto custo e
alto risco com uma inrcia organizacional freqente.

25

- Tratar todos os riscos significativos do ponto de vista da arquitetura
do projeto;
- Estabelecer uma arquitetura da baseline derivada do tratamento dos
cenrios significativos do ponto de vista da arquitetura, que
normalmente expem os maiores riscos tcnicos do projeto;
- Produzir um prottipo evolutivo dos componentes de qualidade de
produo, assim como um ou mais prottipos descartados para
diminuir riscos especficos como:
trocas de design/requisitos;
reutilizao de componentes;
possibilidade de produo do produto ou demonstraes para
investidores, clientes e usurios finais;
demonstrar que a arquitetura de baseline suportar os
requisitos do sistema a um custo justo e em tempo justo;
estabelecer um ambiente de suporte.

Para atingir esses objetivos bsicos, tambm importante configurar o
ambiente de suporte para o projeto. Isso inclui criar um caso de
desenvolvimento, criar templates e diretrizes, e configurar ferramentas
(KRUCHTEN,2003).

1.3.1.1.3 Fase de Construo

A meta da fase de construo esclarecer os requisitos restantes e
concluir o desenvolvimento do sistema com base na arquitetura da baseline. A
fase de construo de certa forma um processo de manufatura, em que a
nfase est no gerenciamento de recursos e controle de operaes para
otimizar custos(No aplicvel para o presente projeto), programaes e
qualidade. Nesse sentido, a mentalidade do gerenciamento passa por uma
transio do desenvolvimento da propriedade intelectual durante a iniciao e

26

elaborao, para o desenvolvimento dos produtos que podem ser implantados
durante a construo e transio (KRUCHTEN,2003).
Os objetivos principais da fase de construo incluem
(KRUCHTEN,2003).
- Minimizar os custos de desenvolvimento;
- Atingir a qualidade adequada;
- Atingir as verses teis (alfa, beta e outros releases de teste);
- Concluir a anlise, o desenvolvimento e o teste de todas as
funcionalidades necessrias;
- Desenvolver de modo iterativo e incremental um produto completo
que esteja pronto para a transio para a sua comunidade de
usurios. Isso implica descrever os casos de uso restantes e outros
requisitos, incrementar o design, concluir a implementao e testar
o software;
- Decidir se o software, os locais e os usurios esto prontos para
que o aplicativo seja implantado;
- Atingir um certo paralelismo entre o trabalho das equipes de
desenvolvimento.

1.3.1.1.4 Fase de Transio

O foco da Fase de Transio assegurar que o software esteja
disponvel para seus usurios finais. A Fase de Transio pode atravessar
vrias iteraes e inclui testar o produto em preparao para release e ajustes
pequenos com base no feedback do usurio. Nesse momento do ciclo de vida,
o feedback do usurio deve priorizar o ajuste fino do produto, a configurao, a
instalao e os problemas de usabilidade; todos os problemas estruturais mais
graves devem ter sido trabalhado muito antes no ciclo de vida do projeto
(KRUCHTEN,2003).
No fim do ciclo de vida da Fase de Transio, os objetivos devem ter
sido atendidos e o projeto deve estar em uma posio para fechamento. Em
alguns casos, o fim do ciclo de vida atual pode coincidir com o incio de outro

27

ciclo de vida no mesmo produto, conduzindo nova gerao ou verso do
produto. Para outros projetos, o fim da transio pode coincidir com uma
liberao total dos artefatos a terceiros que podero ser responsveis pela
operao, manuteno e melhorias no sistema liberado (KRUCHTEN,2003).
Essa fase de transio pode ser muito fcil ou muito complexa,
dependendo do tipo de produto. Um novo release de um produto de mesa
existente pode ser muito simples, ao passo que a substituio do sistema de
controle do trfego areo de um pas pode ser excessivamente complexo
(KRUCHTEN,2003).
As atividades realizadas durante uma iterao na Fase de Transio
dependem da meta. Por exemplo, ao corrigir erros, normalmente bastam a
implementao e o teste. Se, no entanto, novas caractersticas tiverem de ser
adicionadas, a iterao ser semelhante a uma da fase de construo, exigindo
anlise, design, etc.
A Fase de Transio entra quando uma baseline estiver desenvolvida
o suficiente para ser implantada no domnio do usurio final. Isso normalmente
requer que algum subconjunto usvel do sistema tenha sido concludo com
nvel de qualidade aceitvel e documentao do usurio, de modo que a
transio para o usurio fornea resultados positivos para todas as partes.
A partir de algumas das vrias regras sugeridas pelo RUP para o
gerenciamento e implementao de Software foram usadas todos os recursos
mencionados no item 3 (Soluo Proposta) do presente trabalho.

1.4 Redes de Computadores

Nas duas ltimas dcadas o conceito de rede transformou-se em uma
alternativa prtica de organizao, possibilitando processos capazes de
responder s demandas de flexibilidade, conectividade e descentralizao das
esferas contemporneas de atuao e articulao social (FOROUZAN, 2006).
A palavra rede bem antiga e vem do latim retis, significando
entrelaamento de fios com aberturas regulares que formam uma espcie de
tecido. A partir da noo de entrelaamento, malha e estrutura reticulada, a

28

palavra rede foi ganhando novos significados ao longo dos tempos, passando a
ser empregada em diferentes situaes. Uma delas so as redes de
computadores, que tornaram a comunicao entre diferentes mquinas muito
mais geis e eficientes e tm tido um enorme avano em termos de tecnologia
a cada ano que passa (RITS, 2007).
As redes de computadores ou redes de comunicao, existem para
que dados possam ser enviados de um lado para o outro; esta a idia bsica
da comunicao de dados. No caso especfico deste trabalho, o conceito de
rede servir para o envio e recebimento de dados referentes ao Sistema de
Informao destinado para o controle de acessos do estacionamento do
UniRitter do Campus de Porto Alegre. A rede deste sistema servir para
integrar os computadores responsveis pelo cadastro de entradas e sadas,
assim como a manipulao dos dados e armazenamento dos mesmos em um
banco de dados, centralizando-as de forma que todas as mquinas tenham
acesso atravs de uma arquitetura Cliente-servidor (FOROUZAN, 2006).
Existem vrias formas de um computador solicitar servios a outro
computador. Quando esta solicitao feita de um computador para outro do
qual ambos esto longe, a forma mais comum de comunicao entre eles
implantar uma arquitetura cliente-servidor (FOROUZAN, 2006).
O propsito desta rede ou internetwork oferecer servios para os
usurios. Pode-se usar como exemplo o presente trabalho para explicar o
funcionamento de uma rede do qual utiliza os servios cliente-servidor
(FOROUZAN, 2006). O aplicativo que cadastra os vrios tipos de registros
referentes ao estacionamento (cliente), precisa de algumas informaes que
no estaro disponveis localmente. Estas informaes so armazenadas em
um banco de dados remoto (servidor). No entanto, para que os computadores
possam se comunicar faz-se necessrio que ambos tenham um aplicativo que
possibilite esta troca de informaes.
O cliente um programa executado localmente, que solicita servios
de um servidor. Um programa cliente inicializado por um usurio ou outra
aplicao, e finalizado quando o servio completado. O cliente estabelece um
canal de comunicao com o servidor usando um endereo IP (Internet
Protocol) do host da mquina servidora, assim como o nmero da porta
conhecida pelo programa servidor. Este processo denominado de active

29

open. To logo este canal de comunicao estabelecido, o cliente envia uma
solicitao de servio e recebe uma resposta. Mesmo que a solicitao
resposta seja repetida inmeras vezes, todo o processo finito. Chegando-se
ao trmino deste processo, o mesmo encerrar. Neste momento o cliente
fechar o canal de comunicao, usando um active close (FOROUZAN, 2006).
Programa Servidor um software executado na mquina remota
(tambm conhecida como servidor), oferecendo servios aos clientes. Quando
este programa inicializado ele abre portas para que os clientes possam fazer
suas solicitaes ao servidor. No entanto ele nunca inicia um servio sem que
o mesmo seja solicitado, ou seja, ele funciona de forma passiva. Esta forma de
trabalho chamada de passive open (FOROUZAN, 2006).

1.5 Banco de Dados

Quando se observa um conjunto de arquivos em computador, sejam
eles gerenciados por um SGBD (Sistema Gerenciador de Banco de Dados), ou
arquivos convencionais, observa-se que, usualmente, um arquivo contm
informaes sobre um conjunto de objetos ou entidades referentes
organizao que atendida pelo sistema (HEUSER, 1999).
As tabelas de um BD (Banco de dados) interagem entre si atravs de
relacionamentos. Estes relacionamentos tm a finalidade de manter a
integralidade e consistncia das informaes ali armazenadas. Estes
relacionamentos podem ser dos seguintes tipos (SOUZA,2000):
- um para um: uma tabela somente poder ter um nico vnculo com
algum atributo da outra tabela e vice versa;
- um para n: um atributo da tabela pode ter vrios outros vnculos
com outros atributos de outra tabela;
- n para n: vrios atributos de uma determinada tabela podem se
relacionar com vrios outros atributos de outra tabela.
Neste contexto surgiu uma das idias fundamentais do projeto de
banco de dados: a de que atravs da identificao das entidades que tero

30

suas informaes armazenadas no banco de dados, possvel identificar os
arquivos que comporo tal banco de dados. Devido existncia desta relao
um-para-um entre arquivos de computador e entidades da organizao
modelada, observa-se que um mesmo modelo conceitual pode ser interpretado
de duas formas (HEUSER, 1999):
Como modelo abstrato da organizao, que define as entidades da
organizao que tem suas informaes armazenadas no banco de
dados;
Como modelo abstrato do banco de dados, que define que arquivos
(tabelas) faro parte do banco de dados.
Na prtica, convencionou-se iniciar o processo de construo de um
novo banco de dados com a construo de um modelo dos objetos da
organizao que ser atendida pelo banco de dados, ao invs de partir
diretamente para o projeto do banco de dados, visando evitar futuras
adaptaes que possam prejudicar o projeto, tais como a simples criao de
uma tabela, que pode comprometer todo o trabalho, j que no se sabe de
forma concreta quais outras tabelas se relacionaro com a mesma e se os
registros que comporo esta tabela iro servir para compor alguma outra
(HEUSER, 1999).

1.5.1 Projeto do Banco de Dados

O projeto de um novo BD d-se atravs de duas fases (HEUSER,
1999):

1 - Modelagem conceitua
Nesta primeira fase, construdo um modelo conceitual, na forma de
um diagrama entidade-relacionamento. Este modelo captura as necessidades

31

da organizao em termos de armazenamento de dados de forma
independente de implementao.

2 - Projeto lgico
A etapa de projeto lgico objetiva transformar o modelo conceitual
obtido na primeira fase em um modelo lgico. O modelo lgico define como o
banco de dados ser implementado utilizando-se um SGBD especfico.
O processo acima adequado para a construo de um novo banco
de dados e no para a reutilizao de registros j existentes.
No caso do trabalho proposto, foi criado um novo banco de dados para
atender as necessidades da aplicao, de forma a no comprometer a
integridade dos registros, atendendo todas as regras de normalizao para
bancos de dados (consistncia e integralidade das informaes). Alm disso, a
construo deste banco de dados ser realizada a partir do levantamento de
requisitos e reunies com os responsveis pelo gerenciamento do
estacionamento do UniRitter.

1.6 Tecnologias para automao de Estacionamentos

Visando estudar a aplicabilidade do sistema proposto neste trabalho,
foram estudadas algumas ferramentas que realizam o controle informatizado
de estacionamentos, apresentadas neste tpico.
Em geral, as empresas que gerenciam estacionamentos tm as
mesmas necessidades, fugindo regra uma pequena parcela. Existem
Sistemas de Informao disponveis no mercado, que suprem as necessidades
destas empresas. Alm disso, existem equipamentos que possibilitam a
automao total dos estacionamentos, necessitando apenas de operadores
para efetuarem o recebimento dos valores e validarem os tickets para a sada
do estacionamento.

32

O prprio hardware emite um ticket, onde constam a data e hora de
entrada e, to logo o usurio o retire do equipamento, o mesmo abre o
dispositivo de acesso aos domnios do estacionamento (cancela). Para sair do
estacionamento, basta o usurio inserir o ticket no equipamento, que o mesmo
faz a verificao do pagamento. Se o pagamento estiver OK a cancela aberta
ou uma mensagem pedindo ao usurio que efetue o pagamento do ticket
(AUCON, 2007).
Um outro tipo de sistema, mais comumente usado, faz com que seja
necessrio um operador para realizar o cadastro de entrada e de sada do
estacionamento, e o sistema realiza as operaes necessrias para calcular o
tempo de estadia nos domnios do estacionamento, assim como o valor a ser
cobrado do cliente, entre outras inmeras operaes (PAZELLO, 2007).
O presente projeto bem semelhante com o mencionado no pargrafo
anterior, com o diferencial de que ele engloba a possibilidade de compra de
acessos antecipadamente pelo usurio, sendo disponibilizados pela aplicao
quando o mesmo tiver a necessidade de us-los futuramente, conforme
mencionado na proposta do projeto.

33

2 TRABALHOS RELACIONADOS

Este captulo apresenta algumas ferramentas e tecnologias voltadas
para a rea de Sistemas de Informao com a finalidade de gerenciar
estacionamentos.

2.1 Park Service

O sistema disponibilizado pela Park Service, verso 03/2007, foi
desenvolvido para a plataforma MS-DOS. As principais funcionalidades deste
sistema so (PARK SERVICE, 2007):
- Controle de entrada e sada de veculos;
- Cobrana de outros servios (lavagem de automveis);
- Impresso de relatrios;
- Cadastro de veculos;
- Cadastro de mensalistas.
- Durante a utilizao do sistema foram detectados alguns
problemas, tais como:
- Permite a entrada duas ou mais vezes do mesmo veculo sem que
tenha sido registrada a sada referente primeira entrada;
- Permite a entrada de apenas oito caracteres no campo RG.
No site da empresa no mencionado o valor do software, no sendo
possvel fazer um comparativo com os demais sistemas que possuem a
mesma finalidade.

34

A Figura 06 apresenta a tela inicial do sistema Park Service.

FIGURA 06: Tela inicial do Sistema Park Service

A Figura 07 apresenta a tela de cadastro de valores referente ao
tempo de permanncia nos domnios do estacionamento, sendo possvel
cadastrar valores para a primeira meia hora, uma hora, duas horas e as demais
horas.

FIGURA 07: Cadastro de valores Sistema Park Service

35

A figura 08 mostra a tela destinada ao cadastro de cliente mensalista,
que por sua vez efetuam o pagamento mensalmente, podendo ter ou no uma
vaga fixa destinada ao cliente.

FIGURA 08: Cadastro de mensalistas

36

A figura 09 mostra a tela destinada visualizao de relatrios, sendo
que os mesmos podem ser de diversos tipos como, por exemplo, de
mensalistas, avulsos, servios, etc. No caso da figura 4, o relatrio referente
a avulsos (acessos de clientes que no so mensalistas e/ou no esto
cadastrados no sistema).

FIGURA 09: Exemplo de relatrio do Park Service

2.2 Gerenciador de Estacionamento Pazello Solues em Software

A segunda ferramenta pesquisada foi o Gerenciador de
Estacionamento, desenvolvido pela empresa Pazello Solues em Softwares,
para a plataforma Microsoft Windows (PAZELLO, 2007). Como principais
funcionalidades desta ferramenta, destacam-se:
- Controle de entrada e sada de veculos;
- Cobrana de servios de lavagem de automveis;
- Impresso de relatrios;
- Cadastro de veculos;
- Cadastro de mensalistas.
Com relao a esta ferramenta, destacam-se como vantagens:
- Possui teclas de atalho F1 para entradas e F5 para sadas;

37

- Permite a cobrana de servios agregados ao estacionamento, tais
como a lavagem de veculos.
- Imprime recibo para mensalistas.
Durante a utilizao do sistema foram detectados alguns problemas, tais
como:
- Permite a entrada duas ou mais vezes do mesmo veculo sem que
tenha sido registrada a sada referente primeira entrada;
- Carrega o valor a ser pago pelo mensalista, mas no carrega
automaticamente o valor para o campo total, deixando em branco o
campo e no contabilizando o mesmo no caixa.
Segundo informaes disponibilizadas no site da empresa, o valor do
software de R$ 400,00 (Quatrocentos reais).

38

A Figura 10 apresenta a tela principal do Sistema Gerenciador de
Estacionamentos da empresa Pazello.

FIGURA 10: Tela inicial do Sistema Gerenciador de Estacionamentos da Pazello

39

A Figura 11 mostra a tela de cadastro de valores referentes ao tempo
de permanncia nos domnios do estacionamento, sendo possvel cadastrar
nove diferentes valores, sendo um para cada perodo de tempo.

FIGURA 11: Cadastro de valores no Sistema Pazello

40

A Figura 12 mostra a tela de cadastro de mensalistas, a qual inclui os
principais dados referentes ao cliente, dentre eles nome, endereo, CPF e dois
campos para telefone, entre outros.

FIGURA 12: Cadastro de mensalistas no Sistema Pazello

41

A Figura 13 mostra a tela de relatrios de caixa.

FIGURA 13: Relatrio de caixa no Sistema Pazello

2.3 Aucon Automao

O Sistema de automao da Aucon no oferece nenhum tipo de
interface, tanto para o operador que recebe os valores referentes ao tempo de
estadia no estacionamento nos caixas quanto para o cliente.
Para o cliente o contato via hardware, onde o sistema detecta a
presena de um veculo atravs de sensores instalados no cho. Quando o
veculo os transpe acionada uma gravao, que solicita ao cliente que insira
o seu carto de acesso ou aperte o boto para que seja emitido um carto
avulso.
Para o Operador (caixa), o motorista do veculo pra e entrega o
carto de acesso para o mesmo, que faz a leitura do cdigo do carto e o
sistema calcula automaticamente o valor referente ao tempo de permanncia

42

nos domnios do estacionamento, sendo que, logo aps o pagamento da tarifa,
o operador (caixa) emite um comando para que seja aberta a cancela, e o
veculo possa sair do estacionamento.
O sistema tambm permite que o valor referente ao tempo de
permanncia seja cobrado em caixas distantes das cancelas como, por
exemplo, no saguo da recepo e o cliente, ao transpor o sensor instalado no
cho, ouve uma mensagem gravada, que solicita ao cliente que insira o carto.
To logo o sistema identifique o pagamento, a cancela aberta, permitindo a
sada do cliente.
Entre outras vantagens, o equipamento possibilita:
a) Que o registro de ingresso de veculos, seja atravs da emisso de
ticket ou do uso de uma credencial, ocorrendo apenas quando
efetivamente um veculo ingresse no estacionamento;
b) Que o registro de sada de veculos, seja atravs da leitura e
recolhimento de ticket ou da leitura de uma credencial, ocorrendo
apenas quando efetivamente um veculo sai do estacionamento.
c) Que o sistema registre em relatrio especfico de auditoria (acessos
irregulares), quando a cancela seja levantada pelo sistema ou de
forma manual, a passagem de veculo, com contagem carro a
carro;
d) Que, ocorrendo a entrada de um carro pela sada ou sada de um
carro pela entrada, o sistema registre em relatrio especfico de
auditoria (acessos irregulares);
e) Que ocorra a cobrana correta caso o usurio informe o extravio de
ticket;
f) Que os tickets emitidos na mquina de entrada sejam efetivamente
recolhidos na mquina de sada. Isto, alm de representar
segurana, viabiliza o controle de uso de selos nos ticktes e outros
convnios que devem ser checados no ticket emitido pela mquina
de entrada;
g) Controle eletrnico completo e transferncia de dados pela Internet
entre estacionamento e administrao central remota,
equipamentos estveis e preparados contra fraudes de

43

empregados e/ou clientes e com sistemas dotados de tecnologia de
transmisso de dados, cadastros e auditoria remota.
A Figura 14 apresenta, destacada com uma elipse vermelha, a
mquina de entrada e sada, juntamente com a cancela que est destacada
com uma elipse azul.

FIGURA 14: Hardware para automao de estacionamentos da Aucon

O prximo captulo apresenta a modelagem da soluo proposta e
implementada para este trabalho.

44

3 SOLUO PROPOSTA

Este trabalho foi desenvolvido com base em um caso real de mercado,
envolvendo o desenvolvimento de um Sistema de Informao, do tipo desktop,
com a base de dados disponvel em uma rede de computadores interna, para a
empresa E1, que atua na rea de administrao de estacionamentos.
O Sistema de Informao utilizado pela E1 Estacionamentos, antes da
implantao do sistema em uso atualmente, oferecia a possibilidade de compra
e registro em banco de dados dos crditos antecipados adquiridos pelos
clientes, mas no o tipo de cliente que comprou, assim como o valor de receita
adquirido por cada um. Tambm gerava inconsistncia nos relatrios, o que
motivou os administradores da E1 Estacionamentos a migrarem para um novo
sistema.
Atualmente a E1 Estacionamentos encontra-se utilizando um Sistema
de Informao que no atende as necessidades de compra e registro em
banco de dados dos crditos antecipados adquiridos pelos clientes, bem como
o registro dos tipos de clientes e relao dos valores financeiros arrecadados
por cada tipo.
O presente projeto teve, como objetivo principal, a modelagem e
implementao de um sistema para controle de entradas e sadas de alunos,
funcionrios, estagirios e professores do Centro Universitrio Ritter dos Reis -
campus Porto Alegre, assim como controlar o fluxo de caixa. Nos vrios
encontros realizados com a gerncia da empresa E1 Estacionamentos, ficou
definida como necessidades da mesma, referentes ao Sistema de Informao
para gerenciamento do estacionamento os seguintes requisitos:
- registrar a entrada e sada dos clientes, atravs de um nmero de
cdigo de barras que ser armazenado juntamente com a placa e
hora de entrada do veculo aos domnios do estacionamento;

45

- controlar o fluxo de caixa do estacionamento;
- permitir a visualizao da quantidade de acessos feitos por cada
tipo de cliente, bem como o valor pago pelos mesmos (valor
integral da tarifa e ou valor antecipado) por determinado perodo;
- permitir a compra antecipada de acessos ao estacionamento;
- permitir o controle de vendas de cada operador e por grupo;
- permitir o controle dos operadores que tiverem permisses para
alterar e ou estornar entradas no caixa, bem como sua justificativa,
atravs de relatrios.
Os clientes do estacionamento so divididos da seguinte forma:
[1] Alunos do UniRitter usurios de automveis;
[2] Alunos do UniRitter usurios de motocicletas;
[3] Professores do UniRitter usurios de automveis e/ou motocicletas;
[4] Funcionrios do UniRitter usurios de automveis e/ou
motocicletas;
[5] Estagirios do UniRitter usurios de automveis e/ou motocicletas;
[6] Visitantes do UniRitter usurios de automveis;
[7] Visitantes do UniRitter usurios de motocicletas.
A tarifa cobrada de cada tipo de usurio se d atravs de uma tabela.
O usurio que comprar acima de uma quantidade mnima (a ser definida) de
acessos pagar um valor inferior ao valor unitrio. Estes acessos antecipados
ficam creditados na base de dados do sistema desenvolvido, sendo
descontados a cada sada do usurio dos domnios do estacionamento. Estes
acessos antecipados podem ser adquiridos nos quiosques da empresa E1
dentro das dependncias do UniRitter. Para que o controle dos crditos
antecipados funcione adequadamente, o sistema ser executado em rede
local, permitindo o compartilhamento de acesso base de dados.
O sistema ainda permite a incluso e excluso de operadores, bem
como de supervisores e gerentes do estacionamento, com suas devidas
permisses de uso.
O sistema, assim que for implantado definitivamente, ser utilizado em
uma rede local de computadores pela Empresa E1 Estacionamentos, sendo
previstos no mnimo trs computadores nas entradas e ou sadas que
efetuaro os registros de entradas e sadas, bem como a venda de crditos.

46

3.1 Modelagem de Soluo Proposta

A proposta deste trabalho foi unir todas as tecnologias estudadas at
agora para a construo de uma ferramenta que seja de fcil integrao, no
intuito de disponibilizar servios para o gerenciamento do estacionamento do
Uniritter campus Porto Alegre, de forma a oferecer tanto para o cliente do
estacionamento quanto para os administradores, a possibilidade de satisfazer
suas reais necessidades, j mencionadas nos captulos anteriores deste
trabalho.
Para um melhor andamento do presente projeto algumas diretrizes
foram seguidas, tais como a modelagem do sistema implementado. Esta
modelagem seguiu o padro UML, a fim de evitar futuras alteraes no projeto
que demandaria um excesso de tempo para a sua concluso. A modelagem
UML foi abordada na seo 1.2.1 deste trabalho.
Um dos modelos utilizados foi o modelo Entidade-Relacionamento
(ER), visando definir quais as tabelas e de que forma as mesmas se
relacionam no banco de dados.
No caso deste projeto, como apresentado na Figura 15, foram
definidas as seguintes tabelas:
Cliente
TipoCliente
ValorCredito
AcessoAntecipado
Caixa
AlteraCaixa
Usuario
SenhaUsuario
TipoUsuario
PermissaoUsuario
Acesso
TipoUsuario_has_PermissaoUsuario

47

A tabela TipoUsuario_has_PermissaoUsuario uma tabela gerada
pelo tipo de relacionamento entre TipoUsuario e PermissaoUsuario que do
tipo n para n.
Cada cliente do estacionamento composto por cdigo de cliente e
um nome. Alm disso, cada cliente tem um tipo (Aluno, professor, estagirio,
funcionrio, etc), que se relacionam na forma de 1 para n. Existe um valor
associado a este tipo, este valor pode ser ou no o mesmo para mais de um
tipo de cliente, por isto o relacionamento de 1 para n.
O cliente pode ainda realizar a compra de crditos antecipados, os
quais sero armazenados na tabela AcessoAntecipado, que armazena o
cdigo do cliente e a quantidade de crditos disponveis. Esta tabela relaciona-
se com a tabela Cliente atravs de um relacionamento 1 para n.
A tabela Usurio composta pelo cdigo e nome do usurio, sendo
que cada usurio pertence a um grupo de tipo de usurio. As tabelas Usurio e
TipoUsuario relacionam-se na forma de 1 para n.
A tabela tipo de usurio composta pelo cdigo e nome do tipo do
usurio, tais como Gerente, Supervisor e Operador. Cada tipo de Usurio
possui permisses que podem ou no ser comuns a mais de um tipo de
usurio. Desta forma a tabela tipoUsuario se relaciona com a tabela
PermissaoUsuario que composta por cdigo e nome da permisso. Este
relacionamento entre TipoUsuario e PermissaoUsuario de n para n, a partir
do qual foi criada a tabela TipoUsuario_has_PermissaoUsuario entre ambas,
como uma tabela intermediria que quebra o relacionamento n para n direto e
cria um relacionamento 1 para n entre TipoUsuario e PermissaoUsuario.
Cada usurio tem uma senha para realizar as operaes pertencentes
ao seu tipo de usurio. Para isto a tabela Usuario relaciona-se com a tabela
SenhaUsuario que composta pelo cdigo do usurio, login e senha, atravs
de um relacionamento 1 para 1.
Cada cliente do estacionamento pode realizar a compra antecipada de
crditos. Esta compra de crditos ficar registrada na tabela Caixa que
composta por cdigo da operao, cdigo do cliente que est realizando a
compra de crditos, o cdigo do usurio do sistema (operador, supervisor ou
gerente) que est realizando a venda de crditos, o valor unitrio de cada

48

crdito, a quantidade de crditos que esto sendo comprados, o total que ser
pago e a data da compra dos crditos.
A operao de compra dos crditos antecipados envolve o
relacionamento de vrias tabelas, como por exemplo a tabela Caixa, que
precisa armazenar qual cliente est comprando os crditos atravs do cdigo
do cliente, que se relaciona com a tabela Cliente atravs de um relacionamento
1 para n. A tabela Caixa tambm se relaciona com a tabela Usuario, j que
necessrio armazenar o cdigo do usurio que est realizando a venda para o
cliente. Este relacionamento de 1 para n.
A fim de evitar fraudes financeiras no sistema, a E1 Estacionamentos
solicitou que, para qualquer alterao que fosse realizada no caixa, fosse
registrado o nome do usurio, juntamente com uma justificativa. Para atender
esta necessidade foi inserida no projeto uma tabela para registrar estas
modificaes chamada de AlteraCaixa. Esta tabela composta pelo cdigo da
alterao, o cdigo da operao que est sendo modificada, o cdigo do
usurio que est realizando a alterao, a data da alterao e o motivo da
alterao. O relacionamento entre as tabelas Caixa do tipo 1 para 1.
A entrada e/ou sada do estacionamento ser registrada em uma
tabela chamada Acesso. Esta tabela composta por cdigo do acesso, cdigo
do usurio que est realizando o registro de entrada, o cdigo do cliente que
est entrando, a data de entrada, hora de entrada, sada pendente para
controle quando for realizar o cadastro de sada, data da sada, hora da sada,
placa do veculo e valor pago. Esta tabela relaciona-se duas vezes com a
tabela Usuario, j que o usurio que vai cadastrar a entrada pode ser ou no o
mesmo que vai cadastrar a sada. Ambos os relacionamentos das tabelas
Acesso e Usuario so do tipo 1 para n. A tabela Acesso ainda relaciona-se com
a tabela Cliente atravs de um relacionamento 1 para n.
Para um melhor entendimento do modelo E-R foi inserido no presente
projeto um diagrama que demonstra as explicaes anteriores, apresentado na

49

Figura 15. O diagrama E-R foi construdo atravs da ferramenta
IBExpert.

FIGURA 15: Modelo ER

50

3.1.1 Diagrama de Classes

A figura 16 apresenta o diagrama de classes que compem o Sistema
implementado neste projeto.
Este diagrama composto pelas classes Pessoa, Usuario , Cliente,
sendo que Cliente e Usuario herdam os atributos de Pessoa, j que as mesmas
so um tipo de pessoa. Acesso, Entrada e Sada, sendo que Entrada e Sada
herdam os atributos de Acesso, j que Entrada e Saida so tipos de Acesso.
Estas trs ultimas classes tm como objetivo gerar as informaes referentes
aos acessos feitos pelos clientes do estacionamento e ainda pelas classes
TipoUsuario, TipoCliente, Permissao, AcessoAntecipado , ValorAcesso, Caixa
e SenhaUsuario.

51

FIGURA 16: Diagrama de Classes

52

3.1.2 Diagrama de Casos de Uso

A figura 17 apresenta o diagrama de casos de uso gerado a partir das
especificaes de requisitos do Sistema implementado, especificaes estas
descritas no captulo 3.

FIGURA 17: Diagrama de Casos de Uso

A figura 17 mostrada anteriormente foi gerada com o auxlio da
ferramenta JUDE Community.
O diagrama de casos de uso apresenta todas as funes que podem
ser realizadas pelo usurio do sistema. Vale lembrar que o usurio do sistema
refere-se pessoa responsvel por fazer algum tipo de operao, sendo neste
caso o operador, supervisor, gerente e/ou algum outro tipo de usurio a ser
criado que possa realizar algum tipo de: incluso, excluso e/ou alterao no
mesmo e no o cliente do estacionamento.

53

3.1.3 Diagramas de Seqncia

Os diagramas de seqncia tm a finalidade de apresentar qual ser a
seqncia de insero de informaes, juntamente com as reaes do sistema,
sejam elas pr-inseres ou ps-inseres.
A figura 18 apresenta o diagrama de seqncia com todas as classes
que se relacionam diretamente com a classe Cliente.

FIGURA 18: Diagrama de Seqncia Cadastrar Cliente

O diagrama mostrado na figura 18 apresenta a seqncia de
operaes que so necessrias para realizar a incluso de um cliente no
sistema. Para tal incluso o sistema carrega, logo aps a escolha de cadastrar
cliente, todos os tipos de clientes disponveis previamente.
O usurio informa o nome do cliente e seleciona o tipo do cliente (
validado o preenchimento dos dois campos). A seguir ativada a incluso no
banco de dados, alm de ser ativada uma mensagem que exibida ao usurio.

54

A figura 19 apresenta o diagrama de seqncia Cadastrar Tipo Cliente,
que uma das aes do usurio.

FIGURA 19: Diagrama de Seqncia Cadastrar Tipo Cliente

operaes que so necessrias para realizar a incluso de um tipo de cliente
no sistema. No caso desta operao no carregada nenhuma informao que
o usurio necessite para realizar a incluso.
O usurio informa o tipo do cliente, sendo validado o preenchimento do
campo e, em seguida, ativada a incluso no banco de dados, recebendo uma
mensagem do sistema.

55

A figura 20 apresenta o diagrama de seqncia Cadastrar Valor
Crdito.

FIGURA 20: Diagrama de Seqncia Cadastrar Valor Crdito

operaes que so realizadas para a incluso de um valor de crdito no
sistema. No caso desta operao no carregada nenhuma informao que o
usurio necessite para realizar a incluso.
O usurio informa o valor do crdito na hora e o valor de crdito
antecipado, sendo validado o preenchimento dos campos e, em seguida,
ativada a incluso no banco de dados, sendo exibida uma mensagem ao
usurio.

56

A figura 21 apresenta o diagrama de seqncia Cadastrar Acesso
Entrada, sendo que Entrada uma classe que herda os mesmos atributos de
Acesso. Sendo assim, no ser representada separadamente no diagrama de
seqncia e sim em conjunto, conforme mostrado na figura 16, sendo uma das
aes do usurio.

FIGURA 21: Diagrama de Seqncia Cadastrar Acesso Entrada

operaes que so realizadas para a incluso de um acesso de entrada do
cliente no sistema. Para tal incluso o sistema carrega, logo aps a escolha de
cadastrar acesso entrada, a data e hora em que tal acesso est ocorrendo.
O usurio informa a placa do veculo do cliente, cujo preenchimento
validado e, em seguida, ativada a incluso no banco de dados, sendo exibida
uma mensagem ao usurio.

57

A figura 22 apresenta o diagrama de seqncia Cadastrar Acesso
Sada, sendo que Sada uma classe que herda os mesmos atributos da
classe Acesso.

FIGURA 22: Diagrama de Seqncia Cadastrar Acesso Sada

operaes que so realizadas para a incluso de um acesso de sada do
cliente no sistema. Para tal incluso o sistema carrega, logo aps a escolha de
cadastrar acesso sada, a data e hora em que tal acesso est ocorrendo.
O usurio informa o cdigo do carto de entrada, que no foi
mencionado nos diagramas, pois as regas da UML dizem que atributos com
propriedades de cdigos no devem ser visveis nos diagramas ( validado o
preenchimento do campo). Em seguida, ativada a incluso no banco de
dados, alm de ativar uma mensagem que exibida ao usurio.

58

A figura 23, apresenta o diagrama de seqncia Cadastrar Usurio.

FIGURA 23: Diagrama de Seqncia Cadastrar Usurio

operaes que so realizadas para realizar a incluso de um usurio do
sistema. Para tal incluso o sistema carrega o tipo de usurio, logo aps a
escolha da opo cadastrar usurio.
O usurio informa o nome do novo usurio, login para acessar o
sistema e senha, sendo validado o preenchimento dos campos e, em seguida,
ativada a incluso no banco de dados, alm de exibir uma mensagem ao
usurio.

59

A figura 24 apresenta o diagrama de seqncia Cadastrar Tipo
Usurio.

FIGURA 24: Diagrama de Seqncia Cadastrar Tipo Usurio

operaes que so realizadas para a incluso de um tipo de usurio do
sistema.
O usurio informa o nome do tipo de usurio, sendo validado o
preenchimento do campo e, em seguida, ativada a incluso no banco de
dados, alm de exibir uma mensagem ao usurio.

60

A figura 25 apresenta o diagrama de seqncia Cadastrar Permisso
Usurio.

FIGURA 25: Diagrama de Seqncia Cadastrar Permisso Usurio

operaes que so realizadas para incluir as permisses a um tipo de usurio
do sistema.
O usurio informa o nome da permisso, sendo validado o
preenchimento do campo e, em seguida, ativada a incluso no banco de
dados, alm de ser exibida uma mensagem ao usurio.

61

A figura 26 apresenta o diagrama de seqncia Cadastrar Compra
Crdito.

FIGURA 26: Diagrama de Seqncia Cadastrar Compra Crdito

operaes que so realizadas para permitir a incluso de compra de crditos
no sistema. Para tal incluso, o sistema carrega o tipo de cliente e a data da
operao, logo aps a escolha da opo cadastrar compra de crditos.
O usurio informa o nome do cliente e quantidade de crditos a serem
comprados, sendo validado o preenchimento dos campos e, em seguida,
ativada a incluso no banco de dados, exibindo uma mensagem ao usurio.
No prximo captulo apresentam-se as informaes referentes
implementao do sistema para gerenciamento do estacionamento do
UniRitter, Campus de Porto Alegre.
Todos os diagramas de seqncia apresentados nesta seso foram
gerados com o auxlio da ferramenta JUDE Community.

62

4 IMPLEMENTAO DO SIS-E1

Para a implementao do SIS-E1 utilizou-se a plataforma de
desenvolvimento Microsoft Visual Studio 2005, com a linguagem de
programao Visual Basic.NET para a construo das interfaces do sistema,
assim como para a implementao das classes que compem o aplicativo.
O banco de dados que serve como base para armazenamento das
informaes do sistema foi implementado no FireBird 1.5, utilizando-se, a
manipulao neste banco, a ferramenta IbExpert.
O presente trabalho encontra-se finalizado, sendo que as interfaces
que sero apresentadas nos prximos pargrafos so as finais, e tanto as
interfaces quanto as funcionalidades foram testadas e validadas pelos usurios
do atual Sistema da Empresa E1 Estacionamento.

63

A figura 27 apresenta a tela principal do Sistema implementado,
atravs da qual para o usurio poder acessar alguma das funcionalidades do
sistema, sendo necessrio realizar o login no mesmo. O login pode ser
acessado atravs do menu Estacionamento, sub-menu login.
A tela principal do Sistema no interage por meio de chamado de
nenhuma classe, ela apenas carrega para dentro de si os formulrios que por
sua vez tm interaes diretas com as classes implementadas.

FIGURA 27:Tela principal do SIS-E1

64

A figura 28 apresenta o formulrio para login no sistema do qual para
validar o acesso necessrio informar o login e senha em seus respectivos
campos.

FIGURA 28:Formulrio de login

O formulrio apresentado na figura 28 interage diretamente com as
classes SenhaUsuario, Usurio, TipoUsuario e Permissao. A classe
SenhaUsuario verificar se existe o registro da senha e login informados, caso
exista identificado o nome do usurio na classe Usuario, sendo verificado o
seu tipo de usurio atravs da classe TipoUsuario. Finalmente, so habilitados
os menus que o tipo de usurio tem permisso para acessar atravs da classe
Permissao.

65

A figura 29 apresenta o formulrio de entrada, tendo por finalidade
registrar no banco as informaes do cliente e do veculo que o mesmo est
conduzindo. logo aps a leitura do carto do cliente verifica-se se o mesmo no
possui um registro de entrada do qual no realizou a sada. Caso o cliente no
tenha sada pendente, o usurio do sistema deve informar a placa do veculo,
sendo verificado, tambm, se este veculo no tem sada pendente.
Aps terem sido preenchidos corretamente os campos do formulrio, o
usurio do sistema deve ativar o boto salvar para inserir as informaes no
banco de dados.

FIGURA 29: Formulrio de entrada

O formulrio apresentado na figura 29 interage unicamente com a
classe Saida, que herda todos os atributos e mtodos da classe Acesso.
O formulrio entrada ainda possui os botes cancelar e sair, sendo o
boto cancelar para limpar todos os campos do formulrio e o boto sair para
fechar o formulrio.
A figura 30 apresenta o formulrio de sada que tem por finalidade,
registrar no banco de dados as informaes referentes sada de um veculo
do estacionamento. Faz-se necessrio, apenas ler o carto de identificao do
cliente, sendo verificado se o tempo de permanncia no estacionamento no

66

ultrapassou a tolerncia de vinte minutos. Caso o tempo de permanncia seja
inferior a vinte minutos exibe-se no campo Tipo de cliente um texto informando
que o cliente isento de pagamento e, no campo Motivo da iseno de
pagamento, mostra-se um texto informando que o tempo de permanncia
inferior a vinte minutos.
Caso o tempo de permanncia seja superior a vinte minutos o sistema
realiza uma pesquisa para verificar se o cliente possui crditos antecipados
disponveis. Em caso afirmativo, apresenta-se no formulrio no campo
Crditos disp.: a quantidade de crditos disponveis atualmente; no campo
Tipo de cliente mostra-se um texto informando que o cliente isento de
pagamento e no campo Motivo da iseno de pagamento aparece um texto
informando que o cliente possui crditos antecipados disponveis.
Caso o cliente no tenha crditos disponveis, o sistema realiza uma
pesquisa pelo tipo de cliente, para buscar os valores associados ao mesmo.
Apresenta-se, ento, no campo Tipo de cliente o tipo de cliente e no campo
Valor a pagar o referido valor da tarifa a ser paga pelo cliente.
Aps terem sido preenchidos corretamente os campos do formulrio o
banco de dados.

FIGURA 30: Formulrio de sada

67

O formulrio apresentado na figura 30 interage diretamente com as
classes Sada (que herda todos os atributos e mtodos da classe Acesso),
Cliente, TipoCliente , AcesoAntecipado e Caixa.
O formulrio de sada ainda possui os botes cancelar e sair, sendo o
boto cancelar para limpar todos os campos do formulrio e o boto sair para
fechar o formulrio.
A figura 31 apresenta o formulrio de consulta de crditos disponveis,
tendo por finalidade pesquisar a quantidade de crditos disponveis para o
cdigo do carto de identificao do cliente informado.
Aps ter sido preenchido corretamente o campo do formulrio o
usurio do sistema deve ativar o boto consultar para pesquisar as
informaes no banco de dados, pesquisando-se se o cliente possui crditos
antecipados disponveis. Ento, ser apresentado no formulrio no campo
Nome do cliente, o nome do cliente e, no campo Qtde. crd. disponvel, a
quantidade de crditos disponveis at o momento da consulta.

FIGURA 31: Formulrio consulta de crditos disponveis

68

O formulrio apresentado na figura 31 ainda possui os botes cancelar
e sair, sendo o boto cancelar para limpar todos os campos do formulrio e o
boto sair para fechar o formulrio.
O formulrio consulta de crditos disponveis interage diretamente com
as classes Cliente e AcessoAntecipado.

69

A figura 32 apresenta o formulrio Cadastro de valores para crditos,
que tem, por finalidade, registrar no banco de dados as informaes referentes
s tarifas de crditos, sendo necessrio apenas informar no campo Valor hora
o valor para compras de uma a cinco unidades de crditos e no campo Valor
antecipado para compras acima de cinco unidades.
Aps terem sido preenchidos corretamente os campos do formulrio, o
banco de dados.
O usurio do sistema tambm tem a possibilidade de alterar os valores
j cadastrados no banco de dados. Para realizar tal operao, basta o usurio
clicar sobre a linha onde se encontram os valores a serem alterados, que os
mesmos sero carregados para seus respectivos campos, permitindo-se, ao
usurio modific-los.
Aps terem sido modificado(s) o(s) corretamente(s) o(s) valor(es) no(s)
campo(s) do formulrio, o usurio do sistema deve ativar o boto alterar para
inserir as informaes alteradas no banco de dados.

FIGURA 32: Formulrio cadastro de valores para crditos

70

O formulrio Cadastro de valores para crditos interage unicamente
com a classe ValorAcesso.
A figura 33 apresenta o formulrio Cadastro de Tipos de Clientes que
tem, por finalidade, registrar no banco de dados as informaes referentes ao
nome do tipo de cliente e a vinculao das tarifas de crditos ao tipo de cliente.
Para realizar esta operao necessrio apenas informar no campo Descrio
do tipo de cliente o nome para o tipo de cliente e o usurio deve clicar sobre a
linha onde se encontram os valores a serem vinculados. Aps a seleo da
linha, aparecer o cdigo do crdito selecionado logo abaixo da grade para
seleo.
Aps ter informado o nome do tipo de cliente e selecionado a linha que
contm os valores a serem vinculados ao tipo de cliente, o usurio do sistema
deve ativar o boto salvar para inserir as informaes no banco de dados.

FIGURA 33: Formulrio cadastro de tipos de clientes

71

O formulrio Cadastro de tipos de clientes interage com as classes
TipoCliente e ValorAcesso.
A figura 34 apresenta o formulrio Cadastro de clientes que tem for
finalidade registrar no banco de dados as informaes referentes ao cliente.
Para tal operao, o usurio do sistema deve informar o cdigo informado no
carto do cliente, que pode ser digitado ou lido por uma leitora de cdigo de
barras no campo Cdigo do cliente, selecionar o tipo de cliente e informar o
nome do cliente no campo Nome do cliente.
Aps ter sido informado o cdigo do cliente, o tipo de cliente e o nome
do cliente, o usurio do sistema deve ativar o boto salvar para inserir as
informaes no banco de dados.

FIGURA 34: Formulrio cadastro de clientes

O formulrio apresentado na figura 34 tambm possibilita que o
usurio consulte os dados do cliente. Para realizar a consulta deve ser
informado o cdigo do cliente e ativado o boto consultar.
Caso seja necessrio alterar o nome e/ou o tipo de cliente, o usurio
pode realizar uma consulta, modificar os dados desejados e ativar o boto
alterar para confirmar as modificaes.

72

O formulrio Cadastro de Clientes tambm possui os botes cancelar e
sair, sendo o boto cancelar para limpar todos os campos do formulrio e o
O formulrio Cadastro de tipos de clientes interage com as classes
TipoCliente e ValorAcesso.
A figura 35 apresenta o formulrio Cadastro de Permisses para Tipos
de Usurios do Sistema. Para realizar o cadastro de permisses necessrio
selecionar o tipo de usurio e ativar o boto visualizar que carregar todas as
permisses cadastradas para o tipo de usurio definido. Caso seja necessrio
alterar (incluir ou excluir permisses) basta selecionar a permisso que a
mesma ser marcada ou desmarcada, de acordo com a necessidade do
usurio e ativar o boto alterar para registr-las no banco de dados.

FIGURA 35: Formulrio cadastro de permisses para grupos de usurios

O formulrio apresentado na figura 35 os botes cancelar e sair, sendo
o boto cancelar para limpar todos os campos do formulrio e o boto sair para
fechar o formulrio.
O formulrio para cadastro de permisses para tipos de usurios
interage diretamente com as classes Tipousuario e Tipopermissao.
A figura 36 apresenta o formulrio para relatrio de acessos ao
estacionamento por aluno. Este relatrio tem, como principal funo,
demonstrar todos os acessos (entrada e sada) realizados em um intervalo de

73

datas. Este relatrio pode identificar a data de entrada e sada, hora de entrada
e sada, assim como o tempo de permanncia no estacionamento e o valor
pago.
Para realizar a pesquisa no banco de dados necessrio informar o
cdigo do cliente no campo Cdigo do cliente, selecionar a data inicial, a data
final e ativar o boto consultar.

FIGURA 36: Formulrio relatrio de acessos

O formulrio apresentado na figura 36 ainda contm os botes
cancelar e sair, sendo o boto cancelar para limpar todos os campos do
formulrio e o boto sair para fechar o formulrio.
O formulrio relatrio de acessos interage exclusivamente com a
classe Acesso.

74

A figura 37 apresenta o formulrio para gerar o relatrio de condutor de
veculo. Este relatrio tem como funo demonstrar o cdigo e nome do
condutor do veculo, caso seja necessrio localiz-lo se houver alguma
anormalidade no estacionamento que envolva o veculo.
Este relatrio s retornar algum resultado se o veculo
correspondente placa informada no tiver sado do estacionamento. Para
realizar a pesquisa no banco de dados necessrio informar a placa do veculo
no campo Placa e ativar o boto consultar.

FIGURA 37: Formulrio relatrio de condutor

O formulrio apresentado na figura 37 ainda contm os botes
formulrio e o boto sair para fechar o formulrio.
O formulrio relatrio de condutor interage exclusivamente com a
classe Acesso.
A figura 38 apresenta o formulrio para gerar relatrio de movimento
de caixa. Este relatrio tem como principais funes demonstrar todas as
entradas realizadas no caixa do estacionamento, inclusive sadas do
estacionamento pagas com crditos antecipados creditados nas carteiras dos
clientes. Os relatrios podem ser:
Todos os usurios do sistema na data referente consulta (data do
dia) de todos os valores diferentes de zero (pagantes).

75

Exemplo: compra de crditos, que podem se sadas pagas ou compra
de crditos antecipados;
Todos os usurios do sistema na data referente consulta (data do
dia) de todos os valores iguais zero (acesso antecipado). Exemplo: sadas
pagas com crditos antecipados;
Todos os usurios do sistema por perodo por perodo, habilitando-se
os componentes que permitem ao usurio selecionar a data inicial e final para
referenciar a consulta e de todos os valores diferentes de zero (pagantes).
Todos os usurios do sistema por perodo, por perodo, habilitando-se
os componentes que permitem ao usurio selecionar a data inicial e final para
referenciar a consulta e de todos os valores iguais a zero (acesso antecipado).
Exemplo: sadas pagas com crditos antecipados;
Por usurio do sistema na data referente consulta (data do dia) de
todos os valores diferentes de zero (pagantes).
Exemplo: compra de crditos, que podem ser sadas pagas ou compra
Por usurio do sistema na data referente consulta (data do dia) de
todos os valores iguais a zero (acesso antecipado).
Exemplo: sadas pagas com crditos antecipados;
Por usurio do sistema por perodo por perodo, habilitando-se os
componentes que permitem ao usurio selecionar a data inicial e final para
referenciar a consulta e de todos os valores diferentes de zero (pagantes).
Por usurio do sistema por perodo por perodo, habilitando-se os
componentes que permitem ao usurio selecionar a data inicial e final para
referenciar a consulta e de todos os valores iguais a zero (acesso antecipado).
Exemplo: sadas pagas com crditos antecipados.

76

Para realizar a pesquisa no banco de dados necessrio selecionar
pelo menos uma de cada das opes contidas nos campos Usurio, Data
consulta, tipo consulta e ativar o boto consultar.

FIGURA 38: Formulrio relatrio de movimento de caixa

O formulrio apresentado na figura 38 tambm possui o boto imprimir,
que envia os resultados da consulta para a impressora, assim como os botes
formulrio e o boto sair para fechar o mesmo.

77

A figura 39 apresenta o formulrio para gerar relatrio de movimento
de caixa com os valores encontrados para a pesquisa.

FIGURA 39: Formulrio relatrio de movimento de caixa com dados

A figura 40 apresenta o relatrio de movimento de caixa com os
valores encontrados para a pesquisa em tamanho real (de acordo com a
impressora), aps ser ativado o boto imprimir.

FIGURA 40: Relatrio de movimento de caixa com dados gerados para a impressora

O formulrio para relatrio de movimento de caixa interage
exclusivamente com a classe Caixa.

78

A figura 41 apresenta o formulrio para gerar o relatrio de movimento
estornado. Este relatrio tem, por finalidade, realizar a pesquisa de todos os
movimentos do caixa que foram estornados (no excludos), assim como a
data de estorno e o motivo, sendo necessrio selecionar o nome do usurio do
sistema no campo Usurio, a data inicial no campo Data inicial e a data final
no campo Data final. Os resultados so apresentados na grade contida no
campo Resultado da consulta, devendo ser ativado o boto consultar para
realizar a pesquisa.

FIGURA 41: Formulrio relatrio de movimento estornado

O formulrio apresentado na figura 41 tambm possui o boto imprimir,
que envia todos os resultados da consulta para a impressora, assim como os
botes cancelar e sair, sendo o boto cancelar para limpar todos os campos do
formulrio e o boto sair para fechar o mesmo.
Este formulrio interage exclusivamente com a classe Caixa.

79

4.1 Validao do sistema SIS-E1

O SIS-E1 foi validado junto aos funcionrios que atuam na E1
Estacionamentos no UniRitter. No total, existem 9 (nove) funcionrios.
Para tornar o processo de validao do sistema o mais prximo
possvel do equipamento utilizado pela E1 Estacionamentos, foi instalado uma
leitora de cdigos de barras e uma impressora matricial de 80 colunas em um
computador simulando o equipamento usado pelos usurios.
A validao foi aplicada dividindo-se o total de usurios que
participaram do processo de validao, em dois grupos. O primeiro grupo foi
composto por quatro usurios e o segundo por trs, totalizando sete usurios
que participaram do processo de validao.
Inicialmente foi apresentado todo o sistema para ambos os grupos,
descrevendo-se suas funcionalidades. Logo aps, cada usurio teve a
oportunidade de criar situaes vividas diariamente. Algumas destas no foram
possveis de serem realizadas no atual sistema da E1 Estacionamento, tais
como a compra de crditos antecipados pelas carteiras de identificao dos
alunos e a identificao dos condutores de veculos.
Alguns usurios tiveram dificuldades para usar o mouse, mediante que
o atual sistema implantado executado em plataforma MS-DOS, no se
valendo do recurso oferecido pelo mouse e, sim, pelo uso de teclado.
Logo aps identificar a dificuldade de usar o mouse, exps-se aos
usurios, que o SIS-E1, alm da possibilidade de usar o mouse tambm
oferecia os recursos de navegao nos formulrios pelo teclado. Todo o
processo de validao durou aproximadamente quatro horas.

80

O grfico 01 apresenta, em percentual, a quantidade de usurios da
E1 Estacionamentos que participaram da validao do SIS-E1. A validao
atingiu 78% dos funcionrios da E1.

GRFICO 01 - Usurios do sistema participantes da validao

Usurios do sistema participantes da validao
78%
22%
Respondentes
No respondentes

Os grficos de nmero 02 a 06 so referentes validao do sistema
utilizando-se critrios mais genricos, que poderiam ser aplicados validao
de outros Sistemas. Para cada item avaliado, gerou-se um grfico. Para
avaliao de cada item foram padronizadas 5 (cinco) alternativas de resposta,
das quais o usurio deveria escolher uma. O questionrio utilizado para a
validao apresentado no Anexo 1.

81

A primeira pergunta do questionrio envolveu o layout do sistema. O
grfico 02 apresenta a avaliao deste item do SIS-E1, de acordo com as
alternativas de respostas possveis, que foram timo, Muito Bom, Bom,
Regular e Insatisfatrio.

GRFICO 02 - Layout do sistema

Layout do Sistema
42%
29%
29%
0%
0%
timo
Muito bom
Bom
Regular
Insatisf atrio

Analisando-se os dados do grfico 02, verifica-se que a maioria dos
usurios que participaram da validao (42%) considerou o layout do sistema
timo. Somando-se as alternativas timo e Muito Bom chega-se ao percentual
de 71%.

82

O grfico 03 apresenta os resultados da avaliao referentes
facilidade de acesso s opes (funcionalidades) do sistema.

GRFICO 03 - Facilidade de acesso s opes (funcionalidades) do sistema

Facilidade de acesso s opes (funcionalidades) do sistema
14%
29%
57%
0%
0%
timo
Muito bom
Bom
Regular
Insatisf atrio

Analisando-se os resultados apresentados no Grfico 03, observa-se
que a maioria dos usurios considerou o acesso s funcionalidades do sistema
como Bom. Cabe destacar que estes usurios utilizam, atualmente, um sistema
com outro tipo de interface, o que pode ter dificultado, em um primeiro
momento, a navegao no SIS-E1. Acredita-se que, com a utilizao do
sistema diariamente, esta dificuldade seria reduzida.

83

O grfico 04 apresenta os resultados referentes disposio das
funcionalidades do sistema.

GRFICO 04 - Disposio das funcionalidades do sistema

Disposio das funcionalidades do sistema
29%
42%
29%
0%
0%
timo
Muito bom
Bom
Regular
Insatisf atrio

De acordo com os resultados apresentados pelo grfico 04, a maioria
dos usurios considerou a disposio das funcionalidades com o critrio Muito
Bom. Somando-se as respostas timo e Muito Bom, chega-se ao percentual
de 71% de satisfao com relao disposio das funcionalidades.

84

O grfico 05 apresenta a avaliao referente aos relatrios gerados
pelo sistema.

GRFICO 05 - Relatrios gerados pelo sistema

Relatrios gerados pelo sistema
28%
29%
29%
14%
0%
timo
Muito bom
Bom
Regular
Insatisf atrio

Analisando-se os resultados do grfico 05, verifica-se um empate entre
as opes Muito Bom e Bom, alm do fato de que, a opo timo, atingiu 28%,
ou seja, apenas 1% de diferena. Os resultados podem representar que os
relatrios precisem de uma maior ateno na implementao, para que a
avaliao dos usurios seja mais satisfatria.

85

O grfico 06 apresenta a avaliao referente ao controle de acesso ao
SIS-E1 atravs do login do usurio.

GRFICO 06 - Controle de acesso ao sistema por usurio (Login)

Controle de acesso ao sistema por usurio (Login)
43%
43%
14%
0%
0%
timo
Muito bom
Bom
Regular
Insatisf atrio

De acordo com os resultados apresentados no grfico 06, no
existiram respostas com os critrios Regular ou Insatisfatrio. Todos os
usurios consideraram no mnimo Bom o acesso atravs de login, j que o
sistema atual opera em modo de terminal, ou seja, a mquina habilitada a
realizar suas funes em nome do usurio, no sendo possvel o uso da
mesma caso o usurio esteja, por exemplo, em horrio de intervalo. Para que a
mquina possa continuar trabalhando necessrio migrar todas as operaes
realizadas pelo usurio anterior para o usurio que ir assumir a mquina.
Caso o usurio faa um intervalo em um curto espao de tempo ele deve
deixar a mquina funcionando em seu nome para que um outro usurio possa
continuar operando-a.
Os grficos de nmeros 07 a 11 referem-se validao das
funcionalidades especficas do SIS-E1, de acordo com as regras de negcio
estabelecidas pela empresa.

86

O grfico 07 apresenta os resultados referentes avaliao da
funcionalidade que permite a vinculao de crditos (acessos antecipados) aos
cartes de identificao dos alunos.

GRFICO 07 - Crditos nos cartes de identificao dos alunos

Vinculao de crditos (acessos antecipados) aos cartes de identificao
dos alunos
86%
14%
0%
0%
0%
timo
Muito bom
Bom
Regular
Insatisf atrio

Analisando-se os resultados apresentados no grfico 07, verifica-se
que esta opo bem aceita por todos os usurios, j que no foram
registradas opinies diferentes de timo ou Muito Bom. Alm disso, a grande
maioria dos usurios (86%), considerou esta funcionalidade tima.

87

possibilidade de localizar o condutor do veculo, no caso de ocorrer algum
problema com o veculo estacionado.

GRFICO 08 - Localizar condutores de veculos

Possibilidade de localizar o condutor do veculo, no caso de ocorrer algum
problema com o veculo no estacionamento
86%
14%
0%
0%
0%
timo
Muito bom
Bom
Regular
Insatisf atrio

Assim como na funcionalidade anterior, os resultados do grfico 08
demonstram que todos os usurios consideram importante a possibilidade de
localizar o condutor do veculo caso seja necessrio. A maioria dos usurios
(86%) definiu com o critrio timo esta possibilidade.

88

O grfico 09 apresenta os resultados referentes avaliao da
funcionalidade de aquisio de crditos antecipados de forma ilimitada.

GRFICO 09 - No existe limitao quanto ao nmero de crditos

No existe limitao quanto ao nmero de crditos (acessos antecipados)
57%
43%
0%
0%
0%
timo
Muito bom
Bom
Regular
Insatisf atrio

Os resultados do grfico 09 demonstram que todos os usurios
consideram vlida a possibilidade de que os usurios adquiram os crditos de
forma ilimitada, sendo que a maioria (57%) atribuiu o critrio timo e os
restantes 43% o critrio Muito Bom a esta funcionalidade do sistema.

89

O grfico 10 apresenta os resultados da avaliao referente
possibilidade de estornar os movimentos do caixa.

GRFICO 10 - Possibilidade de estornar os movimentos do caixa

Possibilidade de estornar os movimentos do caixa
86%
14%
0%
0%
0%
timo
Muito bom
Bom
Regular
Insatisf atrio

De acordo com os dados do grfico 10, a grande maioria dos usurios
(86%) considera com o critrio timo a possibilidade de estornar os
movimentos do caixa. Isto se deve, provavelmente, ao fato de que no existe
esta possibilidade no sistema utilizado atualmente na E1.

90

possibilidade de visualizar os movimentos estornados e o motivo dos mesmos.

GRFICO 11 - Visualizar movimentos estornados

Possibilidade de visualizar os movimentos estornados e o motivo do estorno
71%
29%
0%
0%
0%
timo
Muito bom
Bom
Regular
Insatisf atrio

Assim como na funcionalidade apresentada no grfico 10, os
resultados do grfico 11 tambm tm o critrio timo em sua maioria (71%).
Alm disso, todos os usurios consideraram esta funcionalidade com os
critrios timo ou Muito Bom.

91

O grfico 12 apresenta os resultados referentes comparao do SIS-
E1 em relao ao sistema atualmente usado pela E1 Estacionamentos.

GRFICO 12 - Comparao entre SIS-E1 e o atual Sistema

A partir de sua experincia na utilizao do sistema implantado atualmente
na E1 Estacionamentos, comparando-o com o SIS-E1, este novo sistema
pode ser considerado
14%
72%
14%
0%
0%
timo
Muito bom
Bom
Regular
Insatisfatrio

O grfico 12 demonstra que, de forma geral, o SIS-E1 foi considerado
como um sistema Muito Bom em sua maioria (72%). Os critrios Bom e timo
obtiveram o mesmo resultado (14%).
Na sua totalidade, os resultados apresentados demonstram que o SIS-
E1 foi bem aceito pelos usurios, principalmente pelas funcionalidades
implementadas que no existem no sistema utilizado atualmente no
estacionamento, dos quais destacam-se:
Usurio poder realizar login e logoff, liberando o equipamento para ser
usado por outro usurio, sem que haja a possibilidade de assumir por
operaes no feitas pelo mesmo;
Disponibilizar a venda de crditos antecipados, vinculando ao nmero
do carto de identificao do aluno;
No existir limitaes quanto ao nmero de crditos vendidos.
Atualmente os alunos s podem comprar crditos em quantidades mltiplas de
quatro. Considerando que o volume maior de uso do estacionamento noite,
e que no noturno a semana til de quatro dias, torna-se mais fcil de
contabilizar as unidades vendidas por blocos de crditos.

92

A existncia de campos nos formulrios, referentes s operaes que
envolvam dinheiro, possibilitando o clculo entre o valor a ser pago pelo cliente,
o valor que o usurio recebeu do cliente para pagar a referida operao e
quanto o usurio deve devolver para o cliente em forma de troco.
O modelo do instrumento utilizado para a validao do SIS-E1 com os
usurios da Empresa E1 Estacionamento, encontra-se no Anexo 2.

93

CONSIDERAES FINAIS

Como consideraes finais, cabe ressaltar que todos os objetivos
estabelecidos na proposta de Trabalho de Concluso de Curso foram
alcanados, tendo sido realizados os estudos das tecnologias que foram
aplicadas no desenvolvimento do sistema proposto, bem como a identificao
de ferramentas disponveis comercialmente para a gerncia de
estacionamento. Alm disso, o sistema encontra-se totalmente implementado,
testado e validado.
Durante o estudo dos trabalhos relacionados, encontrou-se uma
grande dificuldade para obteno de informaes referentes ao Sistema Aucon,
devido ao fato de que a empresa no disponibiliza uma verso demonstrativa
do sistema, j que a proposta no a venda do software e sim de hardware,
que compreende o conjunto formado pela cancela e pela mquina validadora
de tickets para a sada.
Durante a implementao houve a necessidade de estudar mais
profundamente a gerao de relatrios impressos sem o auxlio da ferramenta
Crystal Reports, tendo-se em vista que a verso inclusa no pacote
Microsoft.NET uma verso limitada da ferramenta proprietria e no atendia
aos requisitos necessrios para os relatrios solicitados pela E1.
O presente sistema pode ser aprimorado, de forma a atender outras
situaes que no se enquadram as mesmas da Empresa E1, tornando-o
comercialmente vivel para qualquer outro tipo de empresa que necessite de
um software que gerencie as entradas, sada, tempo de permanncia, controle
de caixa dentre outras necessidades.

94

O sistema tambm pode receber algumas outras melhorias, tais como:
- Gerar novo login e senha para usurios quando os mesmos no se
lembrarem dos dados previamente cadastrados;
- Capturar as placas dos veculos com o auxlio de cmeras,
dispensando o usurio do sistema de digit-las;
- Possibilitar a escolha do tipo de veculo na hora da entrada no
estacionamento;
- Controlar a quantidade de vagas que o estacionamento oferece,
disponibilizando via relatrio a quantidade de vagas ocupadas e
disponveis.
A declarao de acompanhamento e implementao do SIS-E1 pela
Empresa E1 Estacionamentos, encontra-se em Anexo 1.

95

ANEXO 1

Questionrio para Avaliao do Sistema desenvolvido para Gerenciar
o Estacionamento da Empresa E1 Estacionamentos no Campus do UniRitter
Porto Alegre

Prezado colaborador da E1 Estacionamentos:

Aps utilizar o sistema para gerenciamento do estacionamento SIS-E1,
desenvolvido como Trabalho de Concluso do Curso de Sistemas de
Informao, responda s questes abaixo.

Com relao utilizao do SIS-E1, marque na tabela abaixo a sua
opinio para cada um dos itens apresentados.

timo Muito
bom
Bom Regular Insatisfatrio
Layout do Sistema

Facilidade de acesso s
opes (funcionalidades) do
sistema

Disposio das
funcionalidades do sistema

Relatrios gerados pelo
sistema

Controle de acesso ao
sistema por usurio (Login)

Com relao s funcionalidades do SIS-E1, marque na tabela abaixo
a sua opinio para cada um dos itens apresentados.

timo Muito
bom
Bom Regular Insatisfatrio
Vinculao de crditos
(acessos antecipados) aos
cartes de identificao dos
alunos

Possibilidade de localizar o

96

condutor do veculo, no caso
de ocorrer algum problema
com o veculo no
estacionamento
No existe limitao quanto
ao nmero de crditos
(acessos antecipados)

Possibilidade de estornar os
movimentos do caixa

Possibilidade de visualizar
os movimentos estornados e
o motivo do estorno

A partir de sua experincia na utilizao do sistema implantado
atualmente na E1 Estacionamentos, comparando-o com o SIS-E1, este novo
sistema pode ser considerado:

( ) timo ( ) Muito Bom ( ) Bom ( ) Regular ( ) Insatisfatrio

Justifique sua resposta:

Utilize este espao para fazer sugestes para melhoria do SIS-E1:

Outras Consideraes:

97

ANEXO 2

DECLARAO

Declaro, para os devidos fins, que acompanhei o desenvolvimento do
SIS-E1 Sistema para Controle de Usurios de Estacionamentos para a
Empresa E1 Estacionamentos, empresa terceirizada responsvel por
administrar e gerenciar o estacionamento do UniRitter Campus Porto Alegre ,
na condio de gerente, tendo participado das definies de regras e validao
do sistema.

Porto Alegre, 01 de dezembro de 2007.
Eduardo Feij Chaves
RG: 9056683478

98

REFERNCIAS

AUCON BRASIL. Automao Disponvel em
<http://www.aucon.com.br/aucon/site/automacao/automacao.php>. Consultado
em Maio de 2007

FOROUZAN, Behrouz A. Comunicao de dados e redes de computadores.
3. ed. Porto Alegre: Bookman, 2006.

HEUSER, Carlos Alberto. Projeto de Banco de Dados. 2. ed. Porto
Alegre:Sagra Luzzatto,1999.

KRUCHTEN, Philippe. Introduo ao RUP Rational Unified Process. Rio de
Janeiro: Cincia Moderna,2003.

LARMAN, Graig. Utilizando UML e padres: Uma introduo analise e ao
projeto orientados a objetos. Porto Alegre: Bookman, 2000.

MARTIM, Roberto. O que programao Orientada a Objetos. Disponvel
em: <http://www.linhadecodigo.com.br/artigos.asp?id_ac=851>. Consultado em
maio de 2007.

PARK SERVICE BRASIL. Programa Gerenciador de Estacionamento.
Disponvel em: <http://br.geocities.com/luq40/download.htm>. Consultado em
maio de 2007.

PAZELLO BRASIL. Solues em Software. Disponvel em:
<http://www.informatizesuaempresa.com.br>. Consultado em Maro de 2007.

RATIONAL UNIFIED PROCESS: RATIONAL UNIFIED PROCESS. Disponvel
em: < http://www.wthreex.com/rup/>. Consultado em setembro de 2007.

RITS BRASIL: Redes de Informaes para o Terceiro Setor. Disponvel em:
<http://www.rits.org.br/redes_teste/rd_oqredes.cfm>. Consultado em maio de
2007.

ROCHA,Maria Heloisa Baranauskas. Design e Avaliao de Interfaces
Humano-Computador. So Paulo: IME - USP, 2001.

SILVEIRA,Sidnei Renato. Programao com Visual Basic.NET 2005. Porto
Alegre: UniRitter, 2006.

SOUZA,Vandenberg Dantas de. Introduo a Sistemas de Banco de Dados /
C.J Date. Rio de Janeiro: Campus, 2000.

Graduacao Informatica Sistemas Downloads Tcc2k7-2 MarcioBarretoSantana

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Graduacao Informatica Sistemas Downloads Tcc2k7-2 MarcioBarretoSantana

Hochgeladen von

Copyright:

Verfügbare Formate

1

Das könnte Ihnen auch gefallen