ANDRÉ DO LAGO ZIMMERMANN SREF SISTEMA RODOVIÁRIO PARA EMISSÃO DE FRETES

ANDRÉ DO LAGO ZIMMERMANN SREF SISTEMA RODOVIÁRIO PARA EMISSÃO DE FRETES Assis 2010 Av. Getúlio Vargas, 1200 Vila Nova Santana Assis SP 19807-634 Fone/Fax: (0XX18) 3302 1055 homepage: www.fema.edu.br

ANDRÉ DO LAGO ZIMMERMANN SREF- SISTEMA RODOVIÁRIO PARA EMISSÃO DE FRETES Projeto de sistema apresentado ao Curso de processamento de dados do Instituto Municipal de Ensino Superior de Assis IMESA e a Fundação Educacional do Município de Assis FEMA, como requisito parcial à obtenção do Certificado de Conclusão. Orientado (a): André do Lago Zimmermann Orientador: Domingos de Carvalho Villela Junior Área de Concentração Assis 2010

FICHA CATALOGRÁFICA ZIMMERMANN, André do Lago SREF Sistema Rodoviário para Emissão de Fretes / André do Lago Zimmermann. Fundação Educacional do Município de Assis Fema Assis, 2010. 85p. Orientador: Domingos de Carvalho Villela Junior. Trabalho de Conclusão de Curso Instituto Municipal de Ensino Superior de Assis IMESA 1.Tecnologia. 2.SREF Sistema Rodoviário para Emissão de Fretes. CDD:001.61 Biblioteca da FEMA

SREF SISTEMA RODOVIÁRIO PARA EMISSÃO DE FRETES ANDRÉ DO LAGO ZIMMERMANN Trabalho de Conclusão de Curso apresentado ao Instituto Municipal de Ensino de Assis, como requisito do Curso de Graduação, analisado pela seguinte comissão examinadora. Orientador: Domingos de Carvalho Villela Junior Analisador: Fábio Eder Cardoso Assis 2010

DEDICATÓRIA Dedico este trabalho aos meus pais, e a todos que me apoiaram.

AGRADECIMENTOS A Deus, pela minha vida e por todas as oportunidades que tive até o presente momento. Ao Orientador Prof. Dr. Domingos de Carvalho Villela Junior, pela paciência e dedicação durante todo o decorrer do trabalho. Aos meus amigos, principalmente os da faculdade, por terem participado desse crescimento acadêmico que tive durante esses três anos de faculdade. E a todos os professores que fizeram parte do meu crescimento como ser humano e profissional, me ensinando parte do que aprenderam durante suas vidas.

EPÍGRAFE A tecnologia Java está em todos os lugares se você for desenvolvedor de softwares e não tiver aprendido Java, definitivamente chegou a hora de mergulhar de cabeça. Scott McNealy, Presidente, conselheiro e CEO da Sun Microsystems

RESUMO O sistema SREF, tem por finalidade modernizar todo o processo da empresa, que atua na área de transportes, oferecendo mais controle e rapidez nos processos. O software é uma aplicação desenvolvida para Desktop utilizando a linguagem Java juntamente com os Frameworks Hibernate e JasperReports, para gerar os relatórios será utilizado o ireport e o banco de dados será o PostgreSQL. Utilizando-se dessas tecnologias modernas para o desenvolvimento, com recursos de análise Orientado a Objetos UML (Linguagem de Modelagem Unificada) o software proporcionará um total controle de todos os serviços de forma prática e dinâmica, trazendo ganhos significativos para a empresa. Palavras-chave: Java. Hibernate. ireport. PostgreSQL. UML.

ABSTRACT The SREF system, aims at upgrading the whole process of the company, which operates in the transportation field, providing more control and speed the process. The software is a desktop application developed for using the Java language together with JasperReports and Hibernate frameworks, to generate the reports will be used ireport and the database is PostgreSQL. Using these modern technologies for the development, analysis capabilities with Object- Oriented UML (Unified Modeling Language) software will provide a total control of all services in a practical and dynamic, bringing gains for the company. Keywords: Java. Hibernate. ireport. PostgreSQL. UML.

LISTA DE ILUSTRAÇÕES Figura 01. Mapa Mental...28 Figura 02. Use Case Login do Sistema...32 Figura 03. Use Case Emissão de CTRC...33 Figura 04. Use Case Cancelar CTRC...34 Figura 05. Use Case Baixa de CTRC...35 Figura 06. Use Case Orçamento...36 Figura 07. Use Case Cadastrar Agência...37 Figura 08. Use Case Cadastrar Cliente...48 Figura 09. Use Case Cadastrar Cidade...39 Figura 10. Use Case Cadastrar Distância...40 Figura 11. Use Case Cadastrar Espécie...41 Figura 12. Use Case Cadastrar Pagamento...42 Figura 13. Use Case Cadastrar Peso...43 Figura 14. Use Case cadastrar Funcionário...44 Figura 15. Use Case Relatório de Agências...45 Figura 16. Use Case Relatório de Clientes...46 Figura 17. Use Case Relatório de Cidades...47 Figura 18. Use Case Relatório de Distâncias...58 Figura 19. Use Case Relatório de Espécies...49 Figura 20. Use Case Relatório de Pagamentos...50 Figura 21. Use Case Relatório de Pesos...51 Figura 22. Use Case Relatório de Funcionários...52 Figura 23. Use Case Relatório Diário de Caixa...53 Figura 24. Use Case Relatório por Tipo de CTRC...54 Figura 25. Use Case Trocar Usuário...55 Figura 26. Use Case Teclas de Atalho...56 Figura 27. Use Case Sobre o Sistema...57 Figura 28. Diagrama de Entidade Relacionamento...58 Figura 29. Diagrama de classe...59

Figura 30. Diagrama de seqüência Login do Sistema...60 Figura 31. Diagrama de seqüência Emissão de CTRC...61 Figura 32. Diagrama de seqüência Cadastrar Cidade...62 Figura 33. Diagrama de seqüência Cancelar CTRC...63 Figura 34. Diagrama de atividades Emissão de CTRC...64 Figura 35. Diagrama de atividades Cadastrar Cliente...65 Figura 36. Work Breakdown Structure...66 Figura 37. Seqüenciamento das atividades...67 Figura 38. Tela login do sistema...74 Figura 39. Tela menu do sistema...75 Figura 40. Tela informações do CTRC...76 Figura 41. Tela remetente...77 Figura 42. Tela destinatário......78 Figura 43. Tela nota fiscal...79 Figura 44. Tela relação de CTRC emitidos...80 Figura 45. Tela cadastrar clientes...81 Figura 46. Tela de orçamento...82 Figura 47. Relatório de agências...83 Figura 48. Relatório por agência...84 Figura 49. Comprovante pagamento...85

LISTA DE TABELAS Tabela 01. Lista de eventos...31 Tabela 02. Use Case: Login do Sistema...32 Tabela 03. Use Case: Emissão de CTRC...33 Tabela 04. Use Case: Cancelar CTRC...34 Tabela 05. Use Case: Baixa de CTRC...35 Tabela 06. Use Case: Orçamento...36 Tabela 07. Use Case: Cadastrar Agência...37 Tabela 08. Use Case: Cadastrar Cliente...38 Tabela 09. Use Case: Cadastrar Cidade...39 Tabela 10. Use Case: Cadastrar Distância...40 Tabela 11. Use Case: Cadastrar Espécie...41 Tabela 12. Use Case: Cadastrar Pagamento...42 Tabela 13. Use Case: Cadastrar Peso...43 Tabela 14. Use Case: Cadastrar Funcionário...44 Tabela 15. Use Case: Relatório de Agências...45 Tabela 16. Use Case: Relatório de Clientes...46 Tabela 17. Use Case: Relatório de Cidades...47 Tabela 18. Use Case: Relatório de Distâncias...48 Tabela 19. Use Case: Relatório de Espécies...49 Tabela 20. Use Case: Relatório de Pagamentos...50 Tabela 21. Relatório de Pesos...51 Tabela 22. Use Case: Relatório de Funcionários...52 Tabela 23. Use Case: Relatório Diário de Caixa...53 Tabela 24. Relatório por Tipo de CTRC...54 Tabela 25. Use Case: Trocar Usuário...55 Tabela 26. Use Case: Teclas de Atalho...56 Tabela 27. Use Case: Sobre o Sistema...57 Tabela 28. Use Case: Cronograma de Desenvolvimento...70 Tabela 29. Orçamento do projeto...72

LISTA DE ABREVIATURAS E SIGLAS UML HTML ORM IDE SGBD WBS CTRC API JPA Unifield Modeling Language Hyper Text Markup Language Object Relational Mapping Integrated Development Environment Sistema de Gerenciamento de Banco de dados Work Breakdown Structure Conhecimento de Transporte rodoviário de Cargas Application Programming Interface Java Persistence API

SUMÁRIO 1- INTRODUÇÃO...17 1.1- NECESSIDADE DE DESENVOLVIMENTO DO SISTEMA...17 1.2- IMPORTÂNCIA DO SISTEMA...17 1.3- PROBLEMA DE FAZER TUDO MANUALMENTE...17 1.4- SOBRE A EMPRESA...18 2- OBJETIVO...19 2.1- EM QUE SENTIDO O SISTEMA IRÁ AJUDAR A EMPRESA...19 2.2- OBJETIVOS GERAIS...19 2.3- OBJETIVO DE INFORMATIZAR O SETOR ENVOLVIDO...19 3- PÚBLICO-ALVO...20 4- JUSTIFICATIVA...21 4.1- NECESSIDADE DO SISTEMA...21 4.2- NECESSIDADE QUE LEVARAM AO SURGIMENTO DO SISTEMA...21 5- METODOLOGIA DE DESENVOLVIMENTO...22 5.1- UNIFIELD MODELING LANGUAGE (UML)...22 5.1.1- Diagramas na UML...22 5.1.2- Diagrama de classe...23 5.1.3- Diagrama de caso de uso...23 5.1.4- Diagrama de atividade...23 5.1.5- Diagrama de seqüência...24 5.2- FERRAMENTAS PARA O DESENVOLVIMENTO DO SISTEMA...24 5.3- VISÃO GERAL DA LINGUAGEM QUE SERÁ UTILIZADA...24 5.4- JPA...25 5.5- HIBERNATE...25 5.6- JASPER REPORTS...25 5.7- DB DESIGNER 4...26 5.8- NetBeans IDE...26 5.9- FERRAMENTAS PARA ANÁLISE...26

5.9.1- Astah Professional...26 5.10- BANCO DE DADOS QUE SERÁ UTILIZADO...27 6- ESTRUTURA DE DESENVOLVIMENTO DO SISTEMA...28 6.1- LEVANTAMENTO DOS REQUISITOS...28 6.1.2- Mapa mental do sistema...28 6.2- ANÁLISE DOS REQUISITOS...29 6.2.1- Problemas potenciais do sistema...29 6.2.2- Restrições do Sistema...29 6.3- VALIDAÇÃO DOS REQUISITOS...29 6.4- ESPECIFICAÇÃO DOS REQUISITOS...30 6.4.1- Escopo...30 6.4.2- Lista de Eventos...31 6.5- ANÁLISE ORIENTADA A OBJETOS...32 6.5.1- Especificação dos Casos de Uso...32 6.5.1.1- Efetuar Login...32 6.5.1.2- Emissão de CTRC...33 6.5.1.3- Cancelar CTRC...34 6.5.1.4- Baixa de CTRC...35 6.5.1.5- Orçamento...36 6.5.1.6- Cadastrar Agência...37 6.5.1.7- Cadastrar Cliente...38 6.5.1.8- Cadastrar Cidade...39 6.5.1.9- Cadastrar Distância...40 6.5.1.10- Cadastrar Espécie...41 6.5.1.11- Cadastrar Pagamento...42 6.5.1.12- Cadastrar Peso...43 6.5.1.13- Cadastrar Funcionário...44 6.5.1.14- Relatório de Agências...45 6.5.1.15- Relatório de Clientes...46 6.5.1.16- Relatório de Cidades...47 6.5.1.17- Relatório de Distâncias...48 6.5.1.18- Relatório de Espécies...49

6.5.1.19- Relatório de Pagamentos...50 6.5.1.20- Relatório de Pesos...51 6.5.1.21- Relatório de Funcionários...52 6.5.1.22- Relatório Diário de Caixa...53 6.5.1.23- Relatório por Tipo de CTRC...54 6.5.1.24- Trocar de Usuário...55 6.5.1.25- Teclas de Atalho...56 6.5.1.26- Sobre o Sistema...57 6.5.2- Diagrama Entidade Relacionamento...58 6.5.3- Diagrama de classe...59 6.5.4- Diagrama de seqüência...60 6.5.4.1- Diagrama de seqüência Login de Acesso...60 6.5.4.2- Diagrama de seqüência Emissão de CTRC...61 6.5.4.3- Diagrama de seqüência Cadastrar Cidade...62 6.5.4.4- Diagrama de seqüência Cancelar CTRC...63 6.5.5 Diagrama de Atividades...64 6.5.5.1- Diagrama de atividades Emissão de CTRC...64 6.5.5.2- Diagrama de Atividades Cadastrar Cliente...65 6.6- PLANEJAMENTO DO PROJETO...66 6.6.1- Estrutura Analítica do Projeto (WBS)...66 6.6.2- Seqüenciamento das Atividades...67 7- CRONOGRAMA DA ESTRUTURA DE DESENVOLVIMENTO...68 7.1- ESPECIFICAÇÃO DE CUSTOS...68 7.1.2- Recursos Utilizados para o Desenvolvimento...68 7.1.3- Estimativa de Custos...69 7.1.4- Orçamento do Projeto...70 8- CONCLUSÃO...71 REFERÊNCIAS...72 REFERÊNCIAS BIBLIOGRÁFICAS...72 REFERÊNCIAS ELETRÔNICAS...73 ANEXOS...74

1- INTRODUÇÃO 17 1.1- NECESSIDADE DE DESENVOLVIMENTO DO SISTEMA O objetivo para o desenvolvimento do sistema é modernizar a infra-estrutura da empresa, que usa um modelo de software que está obsoleto no mercado, não atendendo mais as necessidades da empresa no ramo de atividade que atua. Diante deste problema foi solicitado o desenvolvimento de um software que atendesse todas as especificações necessárias para garantir a competitividade no mercado que hoje é tão disputado. 1.2- IMPORTÂNCIA DO SISTEMA O sistema é de extrema importância para a empresa em questão e qualquer outra empresa que trabalhe com grandes volumes de informação e necessite dessas informações para atingir suas metas, como seria difícil manipular todas as informações manualmente ou mesmo com um software que não garantisse a integridade desses dados, daí surge a necessidade de um sistema de confiabilidade que mantenha a integridade dos dados e processe com rapidez as informações requisitadas. 1.3- PROBLEMA DE FAZER TUDO MANUALMENTE O sistema atual é muito antigo, não utiliza uma interface amigável para se comunicar com os usuários e seus administradores, o software permite que o usuário cometa erros que não poderiam ocorrer, gerando transtornos para seus utilizadores.

1.4- SOBRE A EMPRESA 18 A empresa para quem o software será desenvolvido é a Guerino Seiscento Transportes Ltda, empresa sediada na cidade de tupã, que atua na área de transportes de passageiros, encomendas e turismo, sendo que as suas principais receitas vem do transporte de passageiros e encomendas, por isso a necessidade de um sistema que manipule todas essas informações.

2- OBJETIVO 19 2.1- EM QUE SENTIDO O SISTEMA IRÁ AJUDAR A EMPRESA Com a necessidade de um sistema que gerencie todo o fluxo de informação com confiabilidade e rapidez, seja de fácil manipulação e atualização para seus usuários e para seus administradores, viu-se necessário a construção de um novo sistema que pudesse atender todas as exigências da empresa, para trazer uma maior comodidade para seus clientes, que utilizam do serviço diariamente. 2.2- OBJETIVOS GERAIS Visando uma maior competitividade no mercado e conseqüentemente uma maior lucratividade com o aumento de seus clientes, a empresa necessita de um sistema que lhe garanta uma economia no tempo de processamento e precisão das informações. Portanto nesse caso se faz necessário um sistema com uma interface intuitiva para com o usuário e algoritmos que agilizem o processo, dando confiabilidade nas informações processadas, garantindo o bom funcionamento do sistema. 2.3- OBJETIVO DE INFORMATIZAR O SETOR ENVOLVIDO A empresa é toda informatizada, más o sistema em operação tem muitas falhas, é de difícil utilização e a tecnologias utilizadas estão ultrapassadas. Portanto o objetivo principal do desenvolvimento do sistema, é torná-lo mais confiável com novas tecnologias para assim garantir mais agilidade nos processos.

3- PÚBLICO ALVO 20 O público-alvo da empresa são as distribuidoras, revendedoras e industrias das cidades e regiões onde a empresa atua, além de alguns clientes que necessitam de mercadorias mas não com tanta freqüência, nem por isso deixam de ser importantes para a empresa, todos são clientes iguais por que todos a procuram com a mesma finalidade, o transporte de mercadorias entre as cidades atendidas.

4- JUSTIFICATIVA 21 O desenvolvimento de um novo sistema se faz necessário pela grande dificuldade encontrada pela empresa, em diversos sentidos, desde a falhas no gerenciamento das informações até sua utilização. Portanto é extremamente necessário um sistema que de suporte a empresa, para que ela possa atender seus clientes com um serviço de qualidade. 4.1- NECESSIDADE DO SISTEMA Garantir a boa produtividade da empresa e assim garantir um atendimento mais satisfatório para seus clientes usuários e todos que de alguma forma se utilizam do sistema. 4.2- NECESSIDADES QUE LEVARAM AO SURGIMENTO DO SISTEMA Devido aos grandes problemas encontrados na utilização do sistema desde o gerenciamento das informações até sua utilização no dia a dia, surgiu a necessidade de um sistema mais robusto, de fácil utilização por parte dos usuários quando dos administradores do sistema, propiciando ganhos significativos de produtividade, conseqüentemente diminuindo custos de manutenção e interrupções que certamente geram prejuízos para a empresa.

5- METODOLOGIA DE DESENVOLVIMENTO 22 5.1- UNIFIELD MODELING LANGUAGE (UML) A UML (Unified Modeling Language) é uma linguagem-padrão para elaboração da estrutura de projetos de software. A UML poderá ser empregada para a visualização, a especificação, a construção e a documentação de artefatos que façam uso de sistemas complexos de software. A UML é adequada para a modelagem de sistemas, cuja abrangência poderá incluir sistemas de informação corporativos a serem distribuídos a aplicações baseadas em Web e até sistemas complexos embutidos de tempo real. É uma linguagem muito expressiva, abrangendo todas as visões necessárias ao desenvolvimento e implantação desses sistemas. Apesar de sua expressividade, não é difícil compreender e usar a UML. A UML é apenas uma linguagem e, portanto, é somente uma parte de um método para desenvolvimento de software. A UML é independente do processo, apesar de ser perfeitamente utilizada em processo orientado a casos de usos, centrado na arquitetura, iterativo e incremental. (BOOCH et al., 2000, p.13). Objetivos da UML: Visualizar Especificar Construir Documentar 5.1.1- Diagramas na UML Um diagrama é uma apresentação gráfica de um conjunto de elementos, geralmente representados como gráficos de vértices (itens) e arcos (relacionamentos). São desenhados para permitir a visualização de um sistema sob diferentes perspectivas; nesse sentido, um diagrama constitui uma projeção de um determinado sistema. Em todos os sistemas, com

23 exceção dos mais triviais, um diagrama representa uma visão parcial dos elementos que compõem o sistema. (RUMBAUGH et al., 2000, p. 25). Abaixo estão listados alguns diagramas da UML. Diagrama de classes Diagrama de atividades Diagrama de casos de uso Diagrama de seqüência Diagrama de colaborações 5.1.2- Diagrama de classe Exibe um conjunto de classes, interfaces e colaborações, bem como seus relacionamentos. Esses diagramas são encontrados com maior freqüência em sistemas de modelagem orientados a objetos e abrangem uma visão estática da estrutura do sistema. Os diagramas de classes que incluem classes ativas direcionam a perspectiva do processo estático do sistema. (JACOBSON et al., 2000, p. 25). 5.1.3- Diagrama de caso de uso Um diagrama de caso de uso exibe um conjunto de caso de uso e atores (um tipo especial de classe) e seus relacionamentos. Diagramas de caso de uso abrangem a visão estática de casos de uso do sistema. Esses diagramas são importantes principalmente para a organização e a modelagem de comportamentos do sistema. (JACOBSON et al., 2000, p. 26) 5.1.4- Diagrama de atividade Um diagrama de atividade é um tipo especial de diagrama de gráficos de estado, exibindo o fluxo de uma atividade para outra no sistema. Diagramas de atividades abrangem a visão

dinâmica do sistema e é importante principalmente para modelagem da função de um sistema e dá ênfase ao fluxo de controle entre objetos. (JACOBSON et al., 2000, p. 26). 24 5.1.5- Diagrama de seqüência Um diagrama de seqüência é um diagrama de interação que dá ênfase à ordenação temporal de mensagens. Um diagrama de seqüência mostra conjunto de objetos e as mensagens enviadas e recebidas por esses objetos. Tipicamente os objetos são instâncias nomeadas ou anônimas de classes, mas também podem representar instâncias de outros itens, como colaborações, componentes e nós. Use os diagramas de seqüência para ilustrar a visão dinâmica de um sistema. (BOOCH et al., 2000, p. 96). 5.2.- FERRAMENTAS PARA O DESENVOLVIMENTO DO SISTEMA NetBeans IDE software para o desenvolvimento do sistema PostgresSQL banco de dados Astah Professional para a construção dos diagramas DB Designer 4.0 para modelagem ER (Entidade Relacionamento). ireport para gerar relatórios Hibernate (Framework que se relaciona com o banco de dados ) JasperReports (Framework que ajuda o desenvolvedor com a tarefa de criar relatórios) 5.3- VISÃO GERAL DA LINGUAGEM QUE SERÁ UTILIZADA Até hoje, a plataforma Java já atraiu mais de 6,5 milhões de desenvolvedores de software. É utilizada em todos os principais segmentos da indústria, estando presente em uma ampla gama de dispositivos, computadores e redes. Sua versatilidade, eficiência, portabilidade de plataforma e segurança fazem dela a tecnologia ideal para a computação em rede. A tecnologia Java está em todo lugar. Ela pode ser

25 encontrada em laptops, datacenters, consoles de jogo, supercomputadores científicos, telefones celulares e até na Internet. Algumas características que tornaram Java a escolha perfeita para os desenvolvedores: Criar um software em uma plataforma e executá-lo em praticamente qualquer outra Criar programas para execução em navegadores e serviços da Web Desenvolver aplicativos no lado do servidor usados tanto em fóruns, lojas e pesquisas on-line, como no processamento de formulários HTML. (http://www.java.com/pt_br/about/) 5.4- JPA JPA ou Java Persistence API, é uma padronização da linguagem Java, para o mapeamento objeto/relacional. Em outras palavras, é uma padronização de um mecanismo capaz de armazenar no banco de dados as classes do modelo da aplicação que necessitem de persistência. Este mecanismo visa promover todos os recursos de banco de dados, sem a necessidade de manipulação direta de instruções SQL. 5.5- HIBERNATE Hibernate é um projeto audacioso que procura ter uma completa solução para o problema de gerenciamento de dados persistentes em Java. O Hibernate é um framework que se relaciona com o banco de dados, onde este relacionamento é conhecido como mapeamento objeto/relacional (ORM) para Java, deixando o desenvolvedor livre para se concentrar em problemas da lógica do negócio. (GONÇALVES, 2008, p.402). 5.6- JASPER REPORTS JasperReports é uma biblioteca escrita em Java, de código fonte open source, projetada para ajudar o desenvolvedor com a tarefa de criar relatórios para aplicações, tanto para Desktop como Web, fornecendo uma API que facilita sua geração. Embora seja simples,

ainda exige que o desenvolvedor conheça seu formato XML utilizado para criar os relatórios, o que torna dispendioso o tempo de um iniciante. (GONÇALVES, 2008, p.68) 26 5.7- DB DESIGNER 4 Editor visual para criação de banco de dados capaz de integrar criação, modelagem, desenvolvimento e manutenção dos bancos em um ambiente gráfico simples e agradável. (CORREA, 2009, p.16). 5.8- NetBeans IDE O NetBeans IDE Integred Development Enverioment é um ambiente integrado para desenvolvimento de software, escrito em Java, é usado por muitos desenvolvedores que utilizam esta linguagem. O NetBeans é uma ferramenta gratuita e pode ser baixado no site do próprio fabricante, esta ferramenta auxilia os programadores a escrever, debugar, compilar e executar programas. (http://netbeans.org/downloads/) 5.9 FERRAMENTAS PARA ANÁLISE 5.9.1- Astah Professional Astah Professional é uma ferramenta de análise, design e desenvolvimento de aplicações em UML (Unified Modeling Language), e baseada em Windows. Diagramas Utilizados para análise. Diagrama de Classe

Diagrama de Seqüência Diagrama de Atividade Mapa Mental 27 5.10- BANCO DE DADOS QUE SERÁ UTILIZADO PostgesSQL é um SGBD objeto/relational (SGBDOR) desenvolvido via Internet por um grupo de desenvolvedores espalhados pelo globo. É uma alternativa de código fonteaberta para SGBDs comerciais como Oracle e Informix. O PostgreSQL foi desenvolvido originalmente na Universidade de Califórnia em Berkeley. Em 1996, um grupo começou o desenvolvimento do SGBD na Internet. Eles usavam email para compartilhar idéias e servidores de arquivos para compartilhar código. PostgreSQL é agora comparável à SGBDs comerciais em termos de características, desempenho e confiança. Hoje tem transações, views, procedimentos armazenados, e constranints de integridade referencial. (http://www.postgresql.org.br/sobre). Alguns recursos importantes: Comandos complexos Chaves estrangeiras (Foreign Key) Gatilhos (Triggers) Visões (views) Integridade de Transações Controle de Simultaneidade Multiversão (MVCC) Suporta múltiplas transações online concorrentes entre usuários. Traz também opções de extensão pelo usuário para: Tipos de dados Funções Operadores Funções de Agregação (Agrupamento) Métodos de Índice

6- ESTRUTURA DE DESENVOVIMENTO DO SISTEMA 28 6.1- LEVANTAMENTO DOS REQUISITOS Fazer o levantamento dos requisitos junto ao cliente é uma das partes mais importantes no desenvolvimento do sistema, para saber quais serão as funcionalidades do sistema, quem irá manipular e de que forma, a partir daí definir quais serão os níveis de restrição e a iteração com o usuário. 6.1.2- Mapa mental do sistema Figura 01 Mapa mental

6.2- ANÁLISE DOS REQUISITOS 29 6.2.1- Problemas potenciais do sistema Cadastrar clientes, Cidades, Funcionários e etc. Digitação de CTRC, Orçamento e etc. Consultar Cidades, Pagamentos, Clientes e etc. Emitir relatório Diário de Caixa, Cidades, Clientes e etc. 6.2.2 Restrições do Sistema O sistema desenvolvido é uma aplicação Desktop, por ser uma aplicação simples que necessita de pouco processamento e utiliza tecnologias novas, não será necessário muitos recursos do sistema, apenas um sistema operacional confiável, bastando para que a aplicação rode com segurança. 6.3- VALIDAÇÃO DOS REQUISITOS Os requisitos estão completos? Sim(X) Não( ) Os objetivos estão concretos? Sim(X) Não( ) Os dados levantados atende as necessidades?

Sim(X) Não( ) 30 O desenvolvimento foi atingido dentro das restrições? Sim(X) Não( ) Descrição de inconsistências, redundâncias, omissões e falta de clareza: Informações adicionais: André do Lago Zimmermann Responsável pela Validação 6.4- ESPECIFICAÇÃO DOS REQUISITOS 6.4.1- Escopo Os Cadastros só podem ser realizados pelo administrador. Os clientes poderão solicitar cotações de fretes. Ao final de uma cotação o cliente tem a possibilidade de aceitar o serviço. Diversos relatórios serão disponibilizados para o administrador. Por questão de segurança o sistema contará com um recurso de autenticação de usuários. Para evitar dados inconsistentes, o sistema terá um recurso de validação e conversão de dados, maximizando possíveis problemas

6.4.2- Lista de Eventos 31 N Descrição Mensagem Use Cases 01 Administrador Solicita Login MSG-01 Efetuar Login do sistema 02 Administrador Emite CTRC MSG-02 Emissão de CTRC 03 Administrador da Baixa de CTRC MSG-03 Baixa de CTRC 04 Administrador Cancela CTRC MSG-04 Cancelar CTRC 05 Administrador faz Orçamento MSG-05 Orçamento 06 Administrador Cadastra Agência MSG-06 Cadastrar Agência 07 Administrador Cadastra Cliente MSG-07 Cadastrar Cliente 08 Administrador Cadastra Cidade MSG-08 Cadastrar Cidade 09 Administrador Cadastra Distância MSG-09 Cadastrar Distância 10 Administrador Cadastra Espécie MSG-10 Cadastrar Espécie 11 Administrador Cadastra Pagamento MSG-11 Cadastrar Pagamento 12 Administrador Cadastra Peso MSG-12 Cadastrar Peso 13 Administrador Cadastra Funcionário MSG-13 Cadastrar Funcionário 14 Administrador Emite Relatório Agências MSG-14 Relatório de Agências 15 Administrador Emite Relatório Clientes MSG-15 Relatório de Clientes 16 Administrador Emite Relatório Cidades MSG-16 Relatório de Cidades 17 Administrador Emite Relatório Distâncias MSG-17 Relatório de Distâncias 18 Administrador Emite Relatório Espécies MSG-18 Relatório de Espécies 19 Administrador Emite Relatório Pagamentos MSG-19 Relatório de Pagamentos 20 Administrador Emite Relatório Pesos MSG-20 Relatório de Pesos 21 Administrador Emite Relatório Funcionários MSG-21 Relatório de Funcionários 22 Administrador Troca de Usuário MSG-22 Trocar de Usuário 23 Administrador busca ajuda Teclas de Atalho MSG-23 Teclas de Atalho 24 Administrador busca informação do sistema MSG-24 Sobre o Sistema Tabela 01 Lista de Eventos

6.5- ANÁLISE ORIENTADA A OBJETOS 32 6.5.1- Especificação dos Casos de Uso 6.5.1.1- Efetuar Login Figura 02 Use Case Login do Sistema Nome da Use Case Descrição Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Login do Sistema Caso de uso responsável pelo login do sistema Administrador 1- O Administrador é direcionado para uma tela onde deverá preencher os campos usuário e senha. 2- Se todos os dados estiverem corretos o acesso é permitido ao sistema. 3- O Administrador poderá cancelar o processo durante o login 4- O sistema encontra um campo errado e não gera o cadastro. Tabela 02 Use Case Login do Sistema

6.5.1.2- Emissão de CTRC 33 Figura 03- Use Case Emissão de CTRC Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Caos de Testes Emissão de CTRC O Administrador Solicitará ao sistema informações de emissão para um novo CTRC. Administrador estar logado no sistema Administrador/Cliente 1- O Administrador solicita um novo formulário de Emissão de CTRC. 2- O sistema gera o formulário de Emissão. 3- O Administrador preenche todos os campos requeridos. 4- As informações são enviadas para o sistema. 5- O sistema verifica se as informações estão corretas. 6- É concluída a Emissão de CTRC. 7- O sistema informa que o processo foi realizado com sucesso. 8- O Administrador poderá cancelar o processo durante a digitação 9- O sistema encontra um campo errado e não gera o CTRC. Tabela 03- Use Case Emissão de CTRC

6.5.1.3- Cancelar CTRC 34 Figura 04- Use Case Cancelar CTRC Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Cancelar CTRC O Administrador solicitará ao sistema informações do formulário para Cancelar CTRC. Administrador estar logado no sistema Administrador 1- O Administrador solicita um formulário para Cancelar CTRC 2- O sistema gera o formulário para Cancelar CTRC 3- O Administrador preenche todos os campos requeridos. 4- As informações são enviadas para o sistema. 5- O sistema verifica todos os campos requeridos. 6- É concluído o cancelamento de CTRC. 7- O sistema informa que o processo foi realizado com sucesso. 8- O Administrador poderá cancelar o processo a qualquer momento. 9- O sistema encontra um campo errado e não gera o cancelamento.. Tabela 04- Use Case Cancelar CTRC

6.5.1.4- Baixa de CTRC 35 Figura 05 Use Case Baixa de CTRC Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Baixa de CTRC O Administrador solicitará ao sistema informações para Baixa de CTRC. Administrador estar logado no sistema Administrador 1- O Administrador solicita um formulário para dar Baixa de CTRC. 2- O sistema gera o formulário de Baixa de CTRC. 3- O Administrador preenche todos os campos requeridos. 4- As informações são enviadas para o sistema. 5- O sistema verifica os campos requeridos. 6- É concluída a Baixa de CTRC. 7- O sistema informa que o processo foi realizado com sucesso. 8- O Administrador poderá cancelar o processo durante a Baixa de CTRC. 9- O sistema encontra um campo errado e não da Baixa de CTRC. Tabela 05 - Use Case Baixa de CTRC

6.5.1.5- Orçamento 36 Figura 06 Use Case Orçamento Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Orçamento O Administrador solicitará ao sistema informações Orçamento. Administrador estar logado no sistema Administrador 1- O Administrador solicita um formulário para Orçamento. 2- O sistema gera o formulário para Orçamento. 3- O Administrador preenche os campos requeridos. 4- As informações são enviadas para o sistema. 5- O sistema verifica os campos requeridos. 6- É concluído o Orçamento. 7- O sistema informa que o Orçamento foi realizado com sucesso. 8- O Administrador poderá cancelar o processo durante o Orçamento. 9- O sistema encontra um campo errado e não gera Orçamento. Tabela 06 - Use Case Orçamento

6.5.1.6- Cadastrar Agência 37 Figura 07 Use Case Cadastrar Agência Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Teste Cadastrar Agência O Administrador solicitará ao sistema informações de cadastro de uma nova Agência. Administrador estar logado ao sistema. Administrador. 1- O Administrador solicita um formulário de cadastro de Agência. 2- O sistema gera o formulário de cadastro. 3- O Administrador preenche os campos requeridos. 4- As informações são enviadas para o sistema. 5- O sistema verifica os campos requeridos. 6- É concluído o cadastro. 7- O sistema informa que o cadastro foi realizado com sucesso. 8- O Administrador poderá cancelar o processo durante o cadastro. 9- O sistema encontra um campo errado e não gera o cadastro. Tabela 07 - Use Case Cadastrar Agência

6.5.1.7- Cadastrar Cliente 38 Figura 08 Use Case Cadastrar Cliente Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Cadastrar Cliente O Administrador solicitará ao sistema informações de cadastro para um novo cliente Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de cadastro de Cliente. 2- O sistema gera o formulário de cadastro. 3- O Administrador preenche os campos requeridos. 4- O Administrador envia as informações para o sistema. 5- O sistema verifica os campos requeridos. 6- É concluído o cadastro. 7- O sistema informa que o cadastro foi concluído com sucesso. 8- O Administrador poderá cancelar o cadastro durante o processo. 9- O sistema encontra um campo errado e não gera o cadastro. Tabela 08 Use Case Cadastrar Cliente

6.5.1.8- Cadastrar Cidade 39 Figura 09 Use Case Cadastrar Cidade Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Teste Cadastrar Cidade O Administrador solicitará ao sistema informações de cadastro para Cidade. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de cadastro de Cidade. 2- O sistema gera o formulário de cadastro. 3- O Administrador preenche todos os campos requeridos. 4- As informações são enviadas para o sistema. 5- O sistema verifica os campos requeridos. 6- É concluído o cadastro. 7- O sistema informa que o cadastro foi realizado com sucesso. 8- O Administrador poderá cancelar o cadastro durante o processo. 9- O sistema encontra um campo errado e não gera o cadastro. Tabela 09 Use Case Cadastrar Cidade

6.5.1.9- Cadastrar Distância 40 Figura 10 Use Case Cadastrar Distância Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Cadastrar Distância O Administrador solicitará ao sistema informações de cadastro para Distância. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de cadastro de Distância. 2- O sistema gera o formulário de cadastro. 3- O Administrador preenche os campos requeridos. 4- As informações são enviadas para o sistema. 5- O sistema verifica os campos requeridos. 6- É concluído o cadastro. 7- O sistema informa que o cadastro foi realizado com sucesso. 8- O Administrador poderá cancelar o processo durante o cadastro. 9- O sistema encontra um campo errado e não gera o cadastro. Tabela 10 Use Case Cadastrar Distância

6.5.1.10- Cadastrar Espécie 41 Figura 11 Use Case Cadastrar Espécie Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Cadastrar Espécie O Administrador solicitará ao sistema informações de cadastro para Espécie. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de cadastro de Espécie. 2- O sistema gera o formulário de cadastro. 3- O Administrador preenche os campos requeridos. 4- As informações são enviadas para o sistema. 5- O sistema verifica os campos requeridos. 6- É concluído o cadastro. 7- O sistema informa que o cadastro foi realizado com sucesso. 8- O Administrador poderá cancelar o processo durante o cadastro. 9- O sistema encontra um campo errado e não gera o cadastro. Tabela 11 Use Case Cadastrar Espécie

6.5.1.11- Cadastrar Pagamento 42 Figura 12 Use Case Cadastrar Pagamento Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Cadastrar Pagamento O Administrador solicitará ao sistema informações de cadastro para Pagamento. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de cadastro de Pagamento. 2- O sistema gera o formulário de cadastro. 3- O Administrador preenche os campos requeridos. 4- As informações são enviadas para o sistema. 5- O sistema verifica os campos requeridos. 6- É concluído o cadastro. 7- O sistema informa que o cadastro foi realizado com sucesso. 8- O Administrador poderá cancelar o processo durante o cadastro. 9- O sistema encontra um campo errado e não gera o cadastro. Tabela 12 Use Case Cadastrar Pagamento

6.5.1.12- Cadastrar Peso 43 Figura 13 Use Case Cadastrar Peso Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Cadastrar Peso O Administrador solicitará ao sistema informações de cadastro para Peso. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de cadastro de Peso. 2- O sistema gera o formulário de cadastro. 3- O Administrador preenche os campos requeridos. 4- As informações são enviadas para o sistema. 5- O sistema verifica os campos requeridos. 6- É concluído o cadastro. 7- O sistema informa que o cadastro foi realizado com sucesso. 8- O Administrador poderá cancelar o processo durante o cadastro. 9- O sistema encontra um campo errado e não gera o cadastro. Tabela 13 Use Case Cadastrar Peso

6.5.1.13- Cadastrar Funcionário 44 Figura 14 Use Case Cadastrar Funcionário Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Cadastrar Funcionário. O Administrador solicitará ao sistema informações de cadastro para Funcionário. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de cadastro de Funcionário. 2- O sistema gera o formulário de cadastro. 3- O Administrador preenche os campos requeridos. 4- As informações são enviadas para o sistema. 5- O sistema verifica os campos requeridos. 6- É concluído o cadastro. 7- O sistema informa que o cadastro foi realizado com sucesso. 8- O Administrador poderá cancelar o processo durante o cadastro. 9- O sistema encontra um campo errado e não gera o cadastro. Tabela 14 Use Case Cadastrar Funcionário

6.5.1.14- Relatório de Agências 45 Figura 15 Use Case Relatório de Agências Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Relatório de Agências O Administrador solicitará ao sistema informações de Relatório de Agências Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de Relatório de Agências. 2- O sistema gera todas as informações e mostra na tela a solicitação do Administrador. 3- É concluído o relatório. 4- O sistema informa que o relatório foi gerado com sucesso. 5- O Administrador poderá cancelar o processo durante o relatório. 6- O sistema não encontra nenhuma informação. Tabela 15 Use Case Relatório de Agências

6.5.1.15- Relatório de Clientes 46 Figura 16 Use Case Relatório de Clientes Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Relatório de Clientes O Administrador solicitará ao sistema informações de Relatório de Clientes. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de Relatório de Clientes. 2- O sistema gera todas as informações e mostra na tela a solicitação do Administrador. 3- É concluído o relatório. 4- O sistema informa que o relatório foi gerado com sucesso. 5- O Administrador poderá cancelar o processo durante o relatório. 6- O sistema não encontra nenhuma informação. Tabela 16 Use Case Relatório de Clientes

6.5.1.16- Relatório de Cidades 47 Figura 17 Use Case Relatório de Cidades Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Relatório de Cidades. O Administrador solicitará ao sistema informações de Relatório de Cidades. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de Relatório de Cidades. 2- O sistema gera todas as informações e mostra na tela a solicitação do Administrador. 3- É concluído o relatório. 4- O sistema informa que o relatório foi gerado com sucesso. 5- O Administrador poderá cancelar o processo durante o relatório. 6- O sistema não encontra nenhuma informação. Tabela 17 Use Case Relatório de Cidades

6.5.1.17- Relatório de Distâncias 48 Figura 18 Use Case Relatório de Distâncias Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Relatório de Distâncias. O Administrador solicitará ao sistema informações de Relatório de Distâncias. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de Relatório de Distâncias. 2- O sistema gera todas as informações e mostra na tela a solicitação do Administrador. 3- É concluído o relatório. 4- O sistema informa que o relatório foi gerado com sucesso. 5- O Administrador poderá cancelar o processo durante o relatório. 6- O sistema não encontra nenhuma informação. Tabela 18 Use Case Relatório de Distâncias

6.5.1.18- Relatório de Espécies 49 Figura 19 Use Case Relatório de Espécies Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Relatório de Espécies. O Administrador solicitará ao sistema informações de Relatório de Espécies. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de Relatório de Espécies. 2- O sistema gera todas as informações e mostra na tela a solicitação do Administrador. 3- É concluído o relatório. 4- O sistema informa que o relatório foi gerado com sucesso. 5- O Administrador poderá cancelar o processo durante o relatório. 6- O sistema não encontra nenhuma informação. Tabela 19 Use Case Relatório de Espécies.

6.5.1.19- Relatório de Pagamento 50 Figura 20 Use Case Relatório de Pagamentos Nome da Use Case Descrição Pré-Condições Ator(es) Cenário Principal Cenário Alternativo Casos de Testes Relatório de Pagamentos. O Administrador solicitará ao sistema informações de Relatório de Pagamentos. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de Relatório de Pagamentos. 2- O sistema gera todas as informações e mostra na tela a solicitação do Administrador. 3- É concluído o relatório. 4- O sistema informa que o relatório foi gerado com sucesso. 5- O Administrador poderá cancelar o processo durante o relatório. 6- O sistema não encontra nenhuma informação. Tabela 20 Use Case Relatório de Pagamentos

6.5.1.20- Relatório de Pesos 51 Figura 21 Use Case Relatório de Pesos Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Relatório de Pesos. O Administrador solicitará ao sistema informações de Relatório de Pesos. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de Relatório de Pesos. 2- O sistema gera todas as informações e mostra na tela a solicitação do Administrador. 3- É concluído o relatório. 4- O sistema informa que o relatório foi gerado com sucesso. 5- O Administrador poderá cancelar o processo durante o relatório. 6- O sistema não encontra nenhuma informação. Tabela 21 Use Case Relatório de Pesos

6.5.1.21- Relatório de Funcionários 52 Figura 22 Use Case Relatório de Funcionários Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Relatório de Funcionários. O Administrador solicitará ao sistema informações de Relatório de Funcionários. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de Relatório de Funcionários. 2- O sistema gera todas as informações e mostra na tela a solicitação do Administrador. 3- É concluído o relatório. 4- O sistema informa que o relatório foi gerado com sucesso. 5- O Administrador poderá cancelar o processo durante o relatório. 6- O sistema não encontra nenhuma informação. Tabela 22 Use Case Relatório de Funcionários

6.5.1.22- Relatório Diário de Caixa 53 Figura 23 Use Case Relatório Diário de Caixa Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Relatório Diário de Caixa. O Administrador solicitará ao sistema informações de Relatório Diário de Caixa. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de Relatório Diário de Caixa. 2- O sistema gera todas as informações e mostra na tela a solicitação do Administrador. 3- É concluído o relatório. 4- O sistema informa que o relatório foi gerado com sucesso. 5- O Administrador poderá cancelar o processo durante o relatório. 6- O sistema não encontra nenhuma informação. Tabela 23 Use Case Relatório Diário de Caixa

6.5.1.23- Relatório por Tipo de CTRC 54 Figura 24 Use Case Relatório por Tipo de CTRC Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Relatório por Tipo de CTRC. O Administrador solicitará ao sistema informações de Relatório por Tipo de CTRC. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de Relatório por Tipo de CTRC. 2- O sistema gera todas as informações e mostra na tela a solicitação do Administrador. 3- É concluído o relatório. 4- O sistema informa que o relatório foi gerado com sucesso. 5- O Administrador poderá cancelar o processo durante o relatório. 6- O sistema não encontra nenhuma informação. Tabela 24 Use Case Relatório por Tipo de CTRC

6.5.1.24- Trocar Usuário 55 Figura 25 Use Case Trocar Usuário Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Trocar Usuário. O Administrador solicitará ao sistema informações de Utilitários para Trocar Usuário. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de Utilitários para Trocar de Usuário. 2- A tela de login e chamada e o sistema é encerrado. 3- O Administrador deverá entrar com usuário e senha para entrar no sistema novamente. 4- O Sistema verifica se as informações requisitadas estão corretas. 5- Se estiverem corretas o acesso é permitido ao sistema. 6- O Administrador poderá cancelar o processo durante a Troca de Usuário. 7- O sistema não encontra nenhuma informação de usuário informado, e não permite acesso ao sistema. Tabela 25 Use Case Trocar Usuário

6.5.1.25- Teclas de Atalho 56 Figura 26 Use Case Teclas de Atalho Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Teclas de Atalho O Administrador solicitará ao sistema informações de Teclas de Atalho. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário de Teclas de Atalho. 2- O sistema gera todas as informações e mostra na tela a solicitação do Administrador. 3- O Administrador poderá consultar as informações mostradas na tela 4- O Administrador poderá cancelar o processo durante a Execução. 5- O sistema encontra erro ao carregar informações. Tabela 26 Use Case Teclas de Atalho

6.5.1.26- Sobre o Sistema 57 Figura 27 Use Case Sobre o Sistema Nome da Use Case Descrição Pré-Condições Ator (es) Cenário Principal Cenário Alternativo Casos de Testes Sobre o Sistema O Administrador solicitará ao sistema informações Sobre o Sistema. Administrador estar logado ao sistema Administrador 1- O Administrador solicita um formulário com informações Sobre o Sistema. 2- O sistema gera todas as informações e mostra na tela a solicitação do Administrador. 3- O Administrador poderá visualizar as informações mostradas na tela 4- O Administrador poderá cancelar o processo durante a Execução. 5- O sistema encontra erro ao carregar informações. Tabela 27 Use Case Sobre o Sistema

6.5.2- Diagrama Entidade Relacionamento 58 Figura 28 Diagrama de Entidade Relacionamento

6.5.3- Diagrama de classe 59 Figura 29- Diagrama de classe

6.5.4- Diagrama de seqüência 60 6.5.4.1 Diagrama de Seqüência Login de Acesso Figura 30 Diagrama de seqüência: Login do Sistema

6.5.4.2- Diagrama de Seqüência Emissão de CTRC 61 Figura 31 Diagrama de seqüência: Emissão de CTRC

6.5.4.3 Diagrama de Seqüência Cadastrar Cidade 62 Figura 32 Diagrama de Seqüência: Cadastrar Cidade

6.5.4.4- Diagrama Seqüência Cancelar CTRC 63 Figura 33- Diagrama de Seqüência: Cancelar CTRC

6.5.5- Diagrama de Atividades 64 6.5.5.1- Diagrama de atividades Emissão de CTRC Figura 34 Diagrama de atividades: Emissão de CTRC

6.5.5.2- Diagrama de atividades Cadastrar Cliente 65 Figura 35 Diagrama de atividades: Cadastrar Cliente

6.6- PLANEJAMENTO DO PROJETO 66 6.6.1- Estrutura Analítica do Projeto (WBS) Figura 36 Work Breakdown Structure

6.6.2- Seqüenciamento da Atividades 67 Figura 37 - Seqüenciamento das atividades

7- CRONOGRAMA DA ESTRUTURA DE DESENVOVIMENTO 68 Tabela 28- Cronograma de Desenvolvimento 7.1- ESPECIFICAÇÃO DE CUSTOS 7.1.2- Recursos Utilizados para o Desenvolvimento 01 (um) Programador Java; 01 (um) Notebook HP Core 2 Duo, 3 gb de memória, HD 160 gb; 01 (um) Multifuncional Hp Photosmart C4440; Sistema Operacional Microsoft Windows 7 Ultimate; IDE para o desenvolvimento: Netbeans IDE; Aplicativo para digitação do sistema: BrOffice.org 3.2; Banco de dados: PostgresSQL; IDE para modelagem de dados: Astah Professional;

7.1.3- Estimativa de Custos 69 Custo Programador Programador Java custo diário: R$ 30,00 (trinta reais) Total de dias: 112 Custo total: (112 * 30,00) = R$ 3.360,00 (três mil trezentos e sessenta reais). Custos Materiais Notebook: R$ 2.850,00 (dois mil oitocentos e cinqüenta) Depreciação 2 anos: 2.850,00 / 24 (meses) = R$ 118,75 (cento e dezoito reais e setenta e cinco centavos). Custo de um dia: R$ 118,75 / 30 (dias) = R$ 3.95 (três reais e noventa e cinco centavos). Custo de 112 dias: R$ 3.95 * 112 = R$ 442,40 (quatrocentos e quarenta e dois reais e quarenta centavos). Multifuncional: R$ 399,00 (trezentos e noventa e nove reais). Depreciação 18 meses: R$ 399,00 / 18 (meses) = R$ 22,16 (vinte e dois reais e dezesseis centavos). Custo de um dia: R$ 22,16 / 30 (dias) = R$ 0,73 (setenta e três centavos). Custo de 112 dias: R$ 0,73 * 112 (dias) = R$ 81,76 (oitenta e um reais e setenta e seis centavos). Sistema Operacional Microsoft Windows 7 Ultimate: R$ 700,00 (setecentos reais). Depreciação 2 anos: R$ 700,00 / 24 (meses) = R$ 29,16 (vinte e nove reais e dezesseis centavos). Custo de um dia: R$ 29,16 / 30 (dias) = R$ 0,97 (noventa e sete centavos). Custo de 112 dias: R$ 0,97 * 112 (dias) = R$ 108,64 (cento e oito reais e sessenta e quatro centavos).

70 Astah Professional: R$ 492,80 (setecentos reais). Depreciação 2 anos: R$ 492,80 / 24 (meses) = R$ 41,06 (quarenta e um reais e seis centavos). Custo de um dia: R$ 41,06 / 30 (dias) = R$ 1,36 (um real e trinta e seis centavos). Custo de 112 dias: R$ 1,36 * 112 (dias) = R$ 152,32 (cento e cinqüenta e dois reais e trinta e dois centavos). NetBeans IDE : Custo: R$ 0,00 (Freeware) BrOffice.org 3.2: Custo: R$ 0,00 (Freeware) PostgresSQL: Custo: R$ 0,00 (Freeware) 7.1.4- Orçamento do projeto Recursos Valor R$ Programador Java R$ 3.360,00 Notebook R$ 442,40 Multifuncional R$ 81,76 Sistema Operacional Windows 7 R$ 108,64 NetBeans IDE R$ 0,00 BrOffice.org 3.2 R$ 0,00 PostgresSQL R$ 0,00 Astah Professional R$ 152,32 Custo total do projeto R$ 4.145,12 Tabela 29 Orçamento do projeto

8- Conclusão 71 Com o término do trabalho e instalação do sistema, o administrador e os funcionários da empresa, terão acesso a uma ferramenta moderna e rápida para realização das tarefas. Após a instalação e utilização do sistema no dia a dia, espera-se a redução dos erros que ocorriam antes dessa nova ferramenta, como a perda de informações, interrupções inesperadas e um sistema difícil de manipular. SREF - Sistema Rodoviário para Emissão de Fretes proporcionará para to dos os seus usuários, mais rapidez e precisão das informações na realização de tarefas, fazendo assim com que o cliente se sinta mais seguro e satisfeito com o atendimento que tem na empresa, com isso aumentando ainda mais a competitividade da empresa no mercado de trabalho. A etapa de análise facilitou o entendimento do sistema. Por meio da lista de eventos e pelo mapa mental foi possível identificar as principais funcionalidades do sistema. O diagrama de seqüência facilitou a compreensão do funcionamento do software enquanto que o diagrama de classes orientou o desenvolvimento da implementação. Grande parte do tempo de desenvolvimento deste projeto foi gasto no estudo das tecnologias utilizadas, houve muita dificuldade no decorrer do projeto, mas com muita dedicação foram superadas, apesar do sistema ser bem simples está totalmente funcional. O desenvolvimento deste trabalho está sendo de suma importância para o meu crescimento profissional, visto que as tecnologias utilizadas são as mesmas empregadas no mercado de trabalho.

REFERÊNCIAS 72 REFERÊNCIAS BIBLIOGRÁFICAS DEITEL, H.M; DEITEL, P.J. Java como Programar. 6, ed. Tradução de Edson Furmankiewicz. São Paulo: Editora Pearson, 2005. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML GUIA DO USUÁRIO. 1, ed. Tradução de Fábio Freitas. Rio de Janeiro: Editora Campus, 2000. LEE, Richard.C; TEPFENHART, William.M. UML e C++ Guia Prático de Desenvolvimento Orientado a Objeto. 1, ed. Tradução Celso Roberto Paschoa. São Paulo: Editora MAKRON Books, 2001. GONÇALVES, Edson. Desenvolvendo Aplicações Web com NetBeans IDE 6.0. Rio de Janeiro: Editora Ciência Moderna Ltda, 2008. CORREA, Reinaldo Ferreira. SISTEMA CDA - ORÇAMENTO. 2009. 68p. Trabalho de Conclusão de Curso. Fundação Educacional do Município de Assis - FEMA/Instituto Municipal de Ensino Superior de Assis - IMESA.

REFERÊNCIAS ELETRÔNICAS 73 Saiba mais sobre a tecnologia Java. Disponível em: <http://www.java.com/pt_br/about/>. Acesso em 01 de abr. de 2010 NetBeans. Disponível em: <http://netbeans.org/downloads/>. Acesso em 01 de abr. de 2010 Sobre o PostgreSQL. Disponível em: <http://www.postgresql.org.br/sobre/>. Acesso em 25 de Nov. de 2010. NOGUEIRA, Admilson. UML - Unified Modeling Language - Atores, Atividades e Componentes. Disponível em: <http://www.linhadecodigo.com.br/artigo/>. Acesso em 13 de jun. de 2010.

ANEXOS 74 INTERFACE DO SISTEMA Tela login do sistema Figura 38 - Tela login do sistema

Tela menu do sistema 75 Figura 39 - Tela menu do sistema

Tela informações do CTRC 76 Figura 40 - Tela informações do CTRC

Tela remetente 77 Figura 41 - Tela remetente

Tela destinatário 78 Figura 42 - Tela destinatário

Tela nota fiscal 79 Figura 43 - Tela nota fiscal

Tela relação de CTRC emitidos 80 Figura 44 - Tela relação de CTRC emitidos

Tela cadastrar clientes 81 Figura 45 - Tela cadastrar clientes

Tela de orçamento 82 Figura 46 - Tela de orçamento

Relatório de agências 83 Figura 47 - Relatório de agências

Relatório por agência 84 Figura 48 - Relatório por agência

Comprovante pagamento 85 Figura 49 - Comprovante pagamento