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

RESUMOUma 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: Estacionamentos Sistemas de Informao, Gerenciamento de

6

ABSTRACTOne 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 GUI IP OMT OOP OOSE TCC RUP SGBD UML

Entidade-Relacionamento Graphical User Interface Internet Protocol Object Modeling Technique Object Oriented Programming Object Oriented Software Engineering Trabalho de Concluso de Curso Rational Unified Process Sistema Gerenciador de Banco de Dados 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 Esforo ~5% Elaborao 20% 30% Construo 65% 50% Transio 10% 10%

Programao 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 estveis e e administrao preparados central remota, de

equipamentos

contra

fraudes

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 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. do UniRitter usurios de automveis e/ou

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 relacionase 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. IBExpert.

O diagrama E-R foi construdo atravs da ferramenta

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

O diagrama mostrado na figura 19 apresenta a seqncia de 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

O diagrama mostrado na figura 20 apresenta a seqncia de 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

O diagrama mostrado na figura 21 apresenta a seqncia de 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

O diagrama mostrado na figura 22 apresenta a seqncia de 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

O diagrama mostrado na figura 23 apresenta a seqncia de 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

O diagrama mostrado na figura 24 apresenta a seqncia de 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

O diagrama mostrado na figura 25 apresenta a seqncia de 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

O diagrama mostrado na figura 26 apresenta a seqncia de 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 usurio do sistema deve ativar o boto salvar para inserir as informaes no 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 usurio do sistema deve ativar o boto salvar para inserir as informaes no 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 apresentado na figura 32 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 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 apresentado na figura 33 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 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 boto sair para fechar o formulrio. 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 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 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). Exemplo: compra de crditos, que podem se sadas pagas ou compra de 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 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 de crditos antecipados; 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). Exemplo: compra de crditos, que podem se sadas pagas ou compra de 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 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 cancelar e sair, sendo o boto cancelar para limpar todos os campos do 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

22%

Respondentes No respondentes

78%

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

0% 0% 29% 42% timo Muito bom Bom Regular Insatisfatrio

29%

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 sistema0% 0% 14%

timo Muito bom Bom Regular 57% 29% Insatisfatrio

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

0% 0% 29% 29% timo Muito bom Bom Regular Insatisfatrio

42%

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

14%

0% 28% timo Muito bom Bom Regular

29%

Insatisfatrio

29%

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)

0% 14% 0%

43%

timo Muito bom Bom Regular Insatisfatrio

43%

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 alunos0% 0% 14% 0%

timo Muito bom Bom Regular Insatisfatrio

86%

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

O grfico 08 apresenta os resultados da avaliao referentes 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 estacionamento0% 0% 14% 0%

timo Muito bom Bom Regular Insatisfatrio

86%

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%)