sistemas de informação - repositorio.ucb.br · sistemas de informação . ucb - universidade...

SISTEMA DE COTAÇÕES - SISCOT

Autores: Maxwell Mendonça Albuquerque

Sebastião Figueiredo de Morais Filho

Tiago Petrucci Ribeiro

Orientador: Candido Guerrero Salgado

Sistemas de Informação

UCB - Universidade Católica de Brasília

Curso de Bacharelado em Sistemas de Informação

Sistema de Cotações - SISCOT

Alunos:

Maxwell Mendonça Albuquerque – UC04053232

Sebastião Figueiredo de Morais Filho – 2002058105

Tiago Petrucci Ribeiro – UC03000445

Brasília - DF, 29 de Novembro de 2008

TERMO DE APROVAÇÃO

Monografia a ser defendida para a obtenção do Título de Bacharel em Sistemas de

Informação em 29 de Novembro de 2008, pela banca examinadora constituída por:

_________________________________________________________

Prof. Msc. Candido Guerrero Salgado

_________________________________________________________

Prof. Msc. Vilson Carlos Hartmann

A Deus, por permitir que nossa graduação tenha se completado de maneira

digna e vitoriosa. As nossas famílias que sempre

nos incentivaram a seguir buscando um futuro melhor. Aqueles que contribuíram

diretamente e indiretamente para a conclusão deste importante capítulo em nossas vidas.

RESUMO

No ambiente do negócio de seguro de automóveis, as seguradoras basicamente conseguem lucrar quando o número de sinistros for bastante baixo ou, caso não seja possível, que estes não ultrapassem certa margem de valor. Evitar o sinistro, ou seja, a concretização do risco ambientado, não depende da seguradora, esta deve investir na redução dos preços das peças a serem substituídas.

A redução dos preços passa por uma prática bem conhecida: a pesquisa de preços, onde basicamente ganha quem oferecer o melhor preço no menor prazo possível de entrega do produto. Com este intuito, as seguradoras necessitavam de um sistema computacional que pudesse realizar tal pesquisa de preços junto às distribuidoras.

O Sistema de Cotações – SISCOT - é um sistema computacional que tem como objetivo informatizar o processo de cotação de peças para os reparos de automóveis segurados e promover um maior dinamismo entre os entes envolvidos: Seguradoras, Distribuidoras e Oficinas. Este possibilitará ao usuário realizar o seu trabalho, com facilidade, agilidade, segurança e comodidade, para que seja tomada uma decisão de forma tempestiva, quanto à escolha da melhor opção possível para a compra de peças para o conserto veicular.

Foi desenvolvido para o ambiente web, mais especificamente para ser acessado a partir de qualquer computador conectado a Internet, utilizando o poder da linguagem Java e o uso de alguns frameworks de comprovada eficiência, bem como várias ferramentas livres que juntos aliam às vantagens do desenvolvimento orientado a objetos e a facilidade em se usar estruturas de desenvolvimento de grande utilização no mercado.

PALAVRAS – CHAVE: Cotação de peças, Seguradoras, Distribuidoras, Internet.

ABSTRACT

In the business environment of car insurance, insurers can basically profit when the number of accidents is quite low, or if not possible, they do not exceed certain degree of value. Avoid the accident, namely the implementation of the environmental risks, does not depend on the insurer, it must invest in reducing the cost of parts to be replaced.

The price cut goes through a practice well known: the search for prices, which basically wins who offer the best price in the shortest possible timeframe for delivery of the product. To this end, insurers needed a computer system that could make such a search of prices with the distributors.

The quote system - SISCOT - is a computer system which aims to computerize the process of listing of parts for the repair of cars insured and promote a more dynamic between the entities involved: Insurers, distributors and workshops. This will enable the user to carry out their work with ease, agility, security and convenience, so that a decision on a timely, free to choose the best possible option for the purchase of parts to repair the vehicle.

It was developed for the Web environment, more specifically to be accessed from any computer connected to the Internet using the power of the Java language and the use of some frameworks of proven effectiveness, as well as several free tools that together combine the benefits of development oriented to objects and ease in using structures for use in the development of large market.

KEYWORDS: Prices of garments, insurers, distributors, Internet.

SUMÁRIO

1. INTRODUÇÃO .................................................................................................... 12

CAPÍTULO II ........................................................................................................................... 14

2. OBJETIVOS ......................................................................................................... 14

2.1. Objetivo Geral ...................................................................................................... 14

2.2. Objetivos Específicos ........................................................................................... 14

CAPÍTULO III ......................................................................................................................... 15

3. PROPOSTA DO SISTEMA ................................................................................. 15

3.1. Descrição do Sistema Proposto ............................................................................ 15

3.2. Resultados Esperados ........................................................................................... 15

3.3. Restrições do Sistema Proposto ............................................................................ 15

3.4. Recursos Necessários para Execução ................................................................... 16

3.5. Relação Custo x Benefício ................................................................................... 18

3.6. Áreas Afetadas pelo Novo Sistema ...................................................................... 19

CAPÍTULO IV ......................................................................................................................... 20

4. JUSTIFICATIVA DA PROPOSTA ..................................................................... 20

CAPÍTULO V .......................................................................................................................... 22

5. PLANEJAMENTO DO PROJETO ...................................................................... 22

5.1. Plano do Processo de Desenvolvimento ............................................................... 22

5.2. Plano de Organização ........................................................................................... 24

5.3. Plano de Acompanhamento .................................................................................. 25

5.4. Plano de Documentação ....................................................................................... 28

5.5. Plano de Recursos e Produtos ............................................................................... 29

5.6. Cronograma .......................................................................................................... 31

5.7. Glossário ............................................................................................................... 31

CAPÍTULO VI ......................................................................................................................... 32

6. ESPECIFICAÇÃO DOS REQUISITOS DO SISTEMA ..................................... 32

6.1. Descrição resumida do Problema ......................................................................... 32

6.2. Identificação dos interessados no sistema ............................................................ 32

6.3. Descrição das necessidades dos interessados ....................................................... 32

6.4. Descrição das características do sistema .............................................................. 33

6.5. Requisitos do software ......................................................................................... 33

6.6. Requisitos suplementares ..................................................................................... 35

6.7. Restrições ............................................................................................................. 36

CAPÍTULO VII ........................................................................................................................ 37

7. MODELOS DO NEGÓCIO ................................................................................. 37

7.1. Diagrama de Caso de Uso de Negócio ................................................................. 37

7.2. Diagrama de classe do negócio ............................................................................ 38

7.3. Diagrama de atividades ........................................................................................ 39

CAPÍTULO VIII ...................................................................................................................... 40

8. MODELOS DE CASOS DE USO ....................................................................... 40

8.1. Visão geral dos Casos de Uso e atores ................................................................. 40

8.2. Descrição dos Casos de Uso ................................................................................. 42

CAPÍTULO IX ......................................................................................................................... 90

9. MODELOS DE ANÁLISE .................................................................................. 90

9.1. Caso de uso Efetuar Login.................................................................................... 90

9.2. Caso de uso Cotar Peça ........................................................................................ 91

9.3. Caso de uso Orçar Cotação ................................................................................... 92

9.4. Caso de uso Autorizar Orçamento ........................................................................ 93

9.5. Caso de uso Visualizar Cotação Autorizada......................................................... 94

9.6. Caso de uso Pesquisar Cotação ............................................................................ 95

9.7. Caso de uso Visualizar Peça ................................................................................. 96

9.8. Caso de uso Configurar Dados Pessoais............................................................... 97

9.9. Caso de uso Configurar Manter Empresa ............................................................. 98

9.10. Caso de uso Configurar Manter Oficina ............................................................. 101

9.11. Caso de uso Configurar Manter Peça ................................................................. 103

9.12. Caso de uso Configurar Manter Usuário ............................................................ 105

CAPÍTULO X ........................................................................................................................ 108

10. DOCUMENTAÇÃO DE PROJETO .................................................................. 108

10.1. Memorial Descritivo das Decisões de Projeto .................................................... 108

10.2. Diagrama de Arquitetura do SISCOT ................................................................ 112

10.3. Diagrama de Classes do Projeto ......................................................................... 113

10.4. Descrição de Arquivos e Banco de Dados.......................................................... 118

CONCLUSÃO ........................................................................................................................ 119

REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................... 121

LISTA DE ILUSTRAÇÕES

QUADRO1. PROCESSO UNIFICADO ................................................................................. 22

QUADRO2. PONTOS DE CONTROLE DO PROJETO ....................................................... 25

QUADRO3. RISCO DE RH ................................................................................................... 26



QUADRO6. RISCOS RELACIONADOS COM O NEGÓCIO ............................................. 27

QUADRO7. RISCOS DE CARÁTER TÉCNICO .................................................................. 27

QUADRO8. RISCOS DE CARÁTER TÉCNICO .................................................................. 28

QUADRO9. DOCUMENTOS GERADOS ............................................................................ 29

QUADRO10. RECURSOS FINANCEIROS ESTIMADOS PARA O SISCOT .................. 30

QUADRO11. CRONOGRAMA DE DESENVOLVIMENTO ............................................. 31

FIGURA1. MODELO DE NEGÓCIOS ............................................................................... 37

FIGURA2. MODELO DE DOMÍNIO .................................................................................. 38

FIGURA3. DIAGRAMA DE ATIVIDADES ....................................................................... 39

FIGURA4. ATORES DO SISTEMA .................................................................................... 40

FIGURA5. CASOS DE USO PRINCIPAIS ......................................................................... 40

FIGURA6. CASOS DE USO SECUNDÁRIOS ................................................................... 41

FIGURA7. CASOS DE USO SECUNDÁRIOS ................................................................... 41

QUADRO12. DADOS DO LOGIN ...................................................................................... 43

FIGURA8. LAYOUT LOGIN ................................................................................................ 43

QUADRO13. DADOS DA COTAÇÃO ................................................................................ 45

FIGURA9. LAYOUT COTAR PEÇA ................................................................................... 46

QUADRO14. SEGURADORA ............................................................................................. 48

QUADRO15. COTAÇÃO ..................................................................................................... 48

QUADRO16. CLIENTE ........................................................................................................ 49

QUADRO17. TERCEIRO ..................................................................................................... 49

QUADRO18. OFICINA ........................................................................................................ 49

QUADRO19. VEÍCULO ....................................................................................................... 49

QUADRO20. PEÇA .............................................................................................................. 50

FIGURA10. LAYOUT ORÇAR COTAÇÃO .......................................................................... 50


QUADRO22. CLIENTE ........................................................................................................ 53

QUADRO23. TERCEIRO ..................................................................................................... 54

QUADRO24. OFICINA ........................................................................................................ 54

QUADRO25. VEÍCULO ....................................................................................................... 54

QUADRO26. ORÇAMENTO ............................................................................................... 55

FIGURA11. LAYOUT AUTORIZAR ORÇAMENTO ........................................................... 55


QUADRO28. CLIENTE ........................................................................................................ 58

QUADRO29. TERCEIRO ..................................................................................................... 58

QUADRO30. OFICINA ........................................................................................................ 58

QUADRO31. VEÍCULO ....................................................................................................... 59

QUADRO32. ITENS AUTORIZADOS ................................................................................ 59

FIGURA12. LAYOUT VISUALIZAR COTAÇÃO AUTORIZADA ..................................... 60

QUADRO33. PESQUISA ..................................................................................................... 62

QUADRO34. RESULTADO ................................................................................................. 62

QUADRO35. CLIENTE ........................................................................................................ 63

QUADRO36. TERCEIRO ..................................................................................................... 63

QUADRO37. OFICINA ........................................................................................................ 63

QUADRO38. PEÇAS ............................................................................................................ 64

QUADRO39. VEÍCULO ....................................................................................................... 64

QUADRO40. ORÇAMENTO ............................................................................................... 65

FIGURA13. LAYOUT PESQUISAR COTAÇÃO .................................................................. 65

QUADRO41. PESQUISA ..................................................................................................... 68

QUADRO42. RESULTADO ................................................................................................. 68

FIGURA14. LAYOUT VISUALIZAR PEÇA ......................................................................... 69

QUADRO43. DADOS PESSOAIS ....................................................................................... 70

FIGURA15. LAYOUT CONFIGURAR DADOS PESSOAIS ................................................ 71

QUADRO44. PESQUISA ..................................................................................................... 73

QUADRO45. RESULTADO PESQUISA ............................................................................. 73

QUADRO46. INCLUIR ........................................................................................................ 74

QUADRO47. ALTERAR ...................................................................................................... 74

FIGURA16. LAYOUT PESQUISAR USUÁRIO .................................................................... 75

FIGURA17. LAYOUT RESULTADO DA PESQUISA .......................................................... 75

FIGURA19. LAYOUT INCLUIR USUÁRIO ......................................................................... 76

QUADRO48. PESQUISA ..................................................................................................... 78

QUADRO49. INCLUIR ........................................................................................................ 78

QUADRO50. ALTERAR ...................................................................................................... 78

FIGURA20. LAYOUT PESQUISAR EMPRESA ................................................................... 80


FIGURA22. LAYOUT ALTERAR EMPRESA ...................................................................... 80

FIGURA23. LAYOUT INCLUIR EMPRESA ......................................................................... 81

QUADRO51. PESQUISAR ................................................................................................... 83

QUADRO52. INCLUIR ........................................................................................................ 83

QUADRO53. ALTERAR ...................................................................................................... 83

FIGURA24. LAYOUT PESQUISAR PEÇA ........................................................................... 84


FIGURA26. ALTERAR PEÇA .............................................................................................. 84

FIGURA27. INCLUIR PEÇA ................................................................................................. 84

QUADRO54. PESQUISA ..................................................................................................... 86

QUADRO55. INCLUIR ........................................................................................................ 87

QUADRO56. ALTERAR ...................................................................................................... 87

FIGURA28. LAYOUT PESQUISAR OFICINA ..................................................................... 88


FIGURA30. LAYOUT ALTERAR OFICINA ......................................................................... 89

FIGURA31. LAYOUT INCLUIR OFICINA ........................................................................... 89

12

CAPÍTULO I

1. INTRODUÇÃO

O mercado de seguro de automóveis é normatizado pela Circular SUSEP1 Nº

269/2004 (CIRCULAR SUSEP nº 269, de 30 de setembro de 2004, publicada em 4/10/2004

no Diário Oficial da União). Esta estabelece, altera e consolida as regras e critérios

complementares de funcionamento e de operação dos contratos de seguros de automóveis. A

esta modalidade de seguro, também se aplicam todas as disposições da Circular SUSEP Nº

256, (CIRCULAR SUSEP nº 256, de 16 de junho de 2004, publicada em 1°/06/2005 no

Diário Oficial da União), a qual verifica e normatiza as condições mínimas para a

contratação de seguros, seja ele qual for.

Seguro de automóveis existe, resumidamente, para proteger o veículo do segurado

contra eventuais acontecimentos que venham de alguma forma, causar danos a este. Portanto,

quando um segurado faz um contrato com uma companhia de seguros, concordando é claro

em pagar as despesas contratuais, a seguradora fica obrigada a pagar por suas perdas

financeiras em um eventual acidente, perdas estas condicionadas às cláusulas contratuais.

Assim, o mercado de seguro de automóveis rege-se pelo relacionamento dos seguintes

entes:

1. A seguradora;

2. A distribuidora ou fornecedora de peças, as quais competem suprir com as

eventuais peças necessárias para a manutenção do veículo;

3. A oficina, que realiza o conserto do veículo;

4. O segurado, que é o cliente;

5. O veículo, que é a razão do negócio de seguro automotivo.

A relação entre a seguradora e a distribuidora de peças é um ponto bastante crítico.

Dentro do processo de negócio, a distribuidora informa o valor da peça automotiva a ser

substituída e a seguradora arca com esta despesa. Contudo, freqüentemente as distribuidoras

extrapolam nos valores cobrados, gerando assim um prejuízo para as seguradoras.

Para melhorar a agilidade e aumentar a confiabilidade no processo fim das seguradoras

de automóveis, era necessário permitir a seguradora uma maneira de coibir atos ilícitos,

praticados por parte dos segurados e das distribuidoras. Caminhando com a evolução ocorrida

1 SUSEP, Superintendência de Seguros Privados. Disponível em <http://www.susep.gov.br>. Acesso em: 28

maio 2008.

13

em basicamente todos os campos de negócios, as seguradoras também adotaram a

informatização do seu processo de negócio, para com isso tentar controlar efetivamente o seu

produto, que é o seguro veicular.

Na maioria dos sistemas atualmente utilizados pelas seguradoras, ficaram evidentes os

seguintes problemas:

• Não existe a possibilidade de obter a cotação simultânea das peças em todas

fornecedoras cadastradas;

• Difícil navegação, pouco dinâmico e mal organizado;

• Pouco focado ao negócio;

• Falta de informações das fornecedoras cadastradas.

Com o SISCOT – Sistema de Cotações – pretende-se promover o processo de

autorização para compra de peças dos automóveis segurados de forma dinâmica e ágil,

embasados por cotações simultâneas de peças, de forma que todo o processo possa ser

acompanhado pela seguradora, facilitando a escolha da melhor opção possível para o conserto

do veículo do segurado.

14

CAPÍTULO II

2. OBJETIVOS

2.1. Objetivo Geral

O objetivo do Projeto SISCOT – Sistema de Cotações é desenvolver um sistema

computacional que auxilie as seguradoras no controle das cotações de peças automotivas. O

SISCOT promoverá uma integração entre as Seguradoras e as Distribuidoras de peças para o

reparo automotivo.

2.2. Objetivos Específicos

• Permitir cotações simultâneas de peças nas fornecedoras cadastradas;

• Centralizar as informações referentes à solicitação de peças;

• Facilitar a escolha da fornecedora cedente das peças para o reparo;

• Permitir melhor controle e transparência no processo de autorização na compra

junto às Distribuidoras;

• Agilizar o processo de solicitação de peças;

• Permitir que as Distribuidoras possam interagir com as seguradoras no que tange o

processo de cotação de peças automotivas.

15

CAPÍTULO III

3. PROPOSTA DO SISTEMA

3.1. Descrição do Sistema Proposto

Com a utilização do sistema proposto, a seguradora poderá automatizar e controlar o

processo de cotação de peças para o conserto de veículos. A integração entre as seguradoras e

as distribuidoras garantirá uma economia de tempo, agilizando assim a liberação do conserto

do automóvel.

Desta forma, a integração com as distribuidoras irá agilizar o processo de orçamento

de peças automotivas, pois não será necessária uma solicitação formal da seguradora para a

distribuidora, alcançando com este novo processo de trabalho um considerável ganho de

tempo e de recursos.

3.2. Resultados Esperados

Espera-se obter um sistema de fácil utilização e que possibilite uma decisão rápida

quanto à escolha do produto requerido, no caso de uma peça automotiva a ser trocada. O uso

da internet será um diferencial, pois tanto a seguradora quanto a distribuidora terão fácil

acesso ao sistema, bastando apenas um computador ligado à internet.

Para usar o sistema, o usuário terá apenas que digitar a URL do sistema em qualquer

browser de sua preferência, logar no sistema e fazer o seu trabalho. Com relação à segurança,

apenas os usuários cadastrados poderão acessar o sistema. O Sistema terá um perfil para cada

usuário. Caso o usuário seja a Seguradora, quando este logar no sistema, um perfil será

carregado para o mesmo. E caso o usuário seja uma Distribuidora, outro perfil será criado.

Portanto, é esperado que o sistema facilite a relação entre as Distribuidoras de peças

automotivas e as Seguradoras, haja vista que com poucos cliques o usuário possa realizar o

seu trabalho, com segurança e comodidade.

3.3. Restrições do Sistema Proposto

O SISCOT não contemplará o envio de e-mails informando a Distribuidora quanto à

existência de uma nova cotação. O caminho inverso também não será contemplado, ou seja, o

envio de e-mails informando a Seguradora quanto à existência de um novo orçamento.

16

3.4. Recursos Necessários para Execução

3.4.1. Descrição do Hardware Ideal

Cliente:

• 1 monitor 15 polegadas;

• CPU (800 MHz, 2Gb de espaço em disco, 128Mb de memória, placa de rede

10/100, internet banda larga)

Servidor:


• CPU (2.8GHz, 8Gb de memória, configuração de 1 a 2 discos rígidos sem raid,

Disco rígido de 300Gb, Disco rígido adicional de 300Gb, placa de rede 10/100

com 4 portas).

3.4.2. Descrição do Hardware Mínimo

Cliente:



10/100, internet banda larga).

Servidor:



Disco rígido de 73Gb, Disco rígido adicional de 73Gb, placa de rede 10/100 com 4

portas).

3.4.3. Descrição do Software

Cliente:

• Windows 2000 ou superior;

• Browser (Firefox ou Internet Explorer).

Servidor:

• Windows Server® 2003 R2, Standard Edition with SP2;;

17

• Banco de Dados MySQL2.

• Servidor de Aplicação Apache Tomcat3·;

3.4.4. Configuração da Rede

O servidor estará ligado constantemente na internet, e esta conexão será de 2Mb com

uma taxa de 400Kbps para upload e até 2Mbps para download.

Como o sistema será baseado em uma intranet, a rede dos usuários dependerá da

conexão que estes escolherem para trabalhar.

3.4.5. Configuração de Bancos de Dados

O servidor de banco de dados ficará fisicamente instalado junto com o servidor de

aplicação, ou seja, será usado apenas um servidor para todo o sistema. O Sistema Gerenciador

de Banco de Dados será o MySQL.

3.4.6. Descrição das Instalações

A sala onde o Servidor ficará alojado terá as seguintes características:

• O Servidor ficará em uma sala preparada para somente para a função de abrigar o

mesmo, ou seja, separada de outra finalidade;

• Controle de temperatura, utilizando ar-condicionado a uma temperatura entre 15 a

20 graus Celsius;

• Proteção contra incêndio.

3.4.7. Pessoal Exigido

• 1 Gerente de Projetos

• 3 Analistas de Sistemas

• 1 DBA

• 1 Implementador

2 MySQL, Sun Micro Systems. Disponível em <http://www.mysql.com>. Acesso em 10 agosto 2008. 3 TOMCAT, Apache Software Fundation. Disponível em <http://tomcat.apache.org>. Acesso em 15 junho 2008.

18

3.5. Relação Custo x Benefício

Segundo dados estatísticos da Associação Nacional dos Fabricantes de Veículos

Automotores, o mercado de seguro de automóveis cresceu 6% em no período de 2004 a 2006.

Em pesquisa feita pela Correcta Seguros, empresa do ramo de seguros de automóveis, em

2007 aproximadamente 58,64% da frota brasileira é segurada. A Tabela1 demonstra a

evolução do mercado de seguro de automóveis.

Tabela1. O mercado de seguro automotivo

2006 2005 2004 2003

Frota estimada: 24.069.000 23.023.000 22.172.000 21.357.000

Veículos segurados: 14.543.819 14.467.211 12.668.033 12.955.425

%* 60% 63% 57% 61%

*Cálculo utilizando o número de expostos, prêmio total e prêmio médio.

Fontes: Anfavea, Susep, Pesquisa própria.

Nesta mesma pesquisa o número de veículos que se envolve em acidentes é de 12%. O

custo com oficinas e peças para reposição de veículos segurados elevou-se em

aproximadamente 6% em 2007 e nos últimos 4 anos foi de 11,66%. Conforme ilustra a tabela

2.

19

Tabela2. Evolução do seguro de automóveis e dos sinistros

2004 2005 2006 2007*

Crescimento da carteira de seguros

de automóveis 16.44% 16.23% 15.50% 6%

Sinistralidade 73.22% 69.15% 66% 66%

Reajuste de preços 19% 2% 15% -

Custos com sinistros -2.18% 10.38% -2.54% 6%

* Para o ano de 2007 foram usados os dados até outubro, comparando

com mesmo período de 2006.

Fonte: SUSEP e desenvolvimento próprio

As Seguradoras, então, têm um lucro relativamente pequeno se for comparado em

termos de despesas. Se por exemplo uma seguradora tiver um prêmio liquido X, terá de pagar:

• De 10% a 25% de comissão ao corretor;

• Despesas Administrativas: 12% ao mês;

• Sinistros: cerca de 70% ao mês.

O gasto com sinistros é a principal fonte de despesa das seguradoras. Com o SISCOT

será possível reduzir estes gastos, pois será fácil a escolha da peça de reposição que mais se

adapte às necessidades das seguradoras.

3.6. Áreas Afetadas pelo Novo Sistema

A principal alteração trazida pelo SISCOT para o processo de negócio das

Seguradoras de Automóveis está na forma como será feito os orçamentos para consertos de

veículos dos seus segurados.

As Seguradoras poderão disponibilizar para as distribuidoras quais peças ela precisa e

então as distribuidoras informarão quais os seus preços e prazos. Assim, as seguradoras

poderão escolher qual peça se encaixa melhor no orçamento.

20

CAPÍTULO IV

4. JUSTIFICATIVA DA PROPOSTA

A cada solicitação de conserto de peças automotivas, o seguinte fluxo de eventos é

seguido:

• O segurado aciona a seguradora informando que o seu veículo necessita de algum

reparo;

• Recebida solicitação do segurado, a seguradora espera o orçamento por parte de

uma oficina que o próprio segurado escolheu;

• De posse deste orçamento a Seguradora faz as cotações junto às distribuidoras com

o intuito de obter a peça que melhor se adapte na relação custo X tempo;

• Ao final desta pesquisa a seguradora autoriza a remessa da peça para a oficina e o

carro é consertado e devolvido ao cliente.

O principal empecilho neste ciclo é justamente a obtenção da peça que melhor se

adapte à estratégia planejada pela seguradora. O processo de entrar em contato com as

distribuidoras leva bastante tempo, o que gera um atraso na autorização do conserto do

veículo e este, por sua vez, leva a insatisfação do segurado com seguradora e, por

conseqüência prejuízos para a mesma.

A melhor solução para esse caso é usar a tecnologia para agilizar esse processo. Com

esse intuito foram criados alguns sistemas de cotações de peças automotivas que dentre os

quais os mais conhecidos são: o sistema Prismatec4 e o sistema Inpart5·.

O sistema Prismatec é um site que permite aos usuários, neste caso as seguradoras e as

distribuidoras, informatizarem o processo de cotações de peças automotivas. Este site tem as

seguintes características:

• Permite às seguradoras visualizarem orçamentos finalizados, cancelados e

orçamentos a verificar;

• Login separado para cada perfil de usuário, ou seja, um login para as seguradoras e

um login para as distribuidoras;

• Permite um login separado para cada usuário do sistema, ou seja, para cada

operador do sistema;

• Permite a criação de relatórios de acordo com o orçamento efetuado;

4 PRISMATEC, Prismatec LTDA. Disponível em <http://sistema.prismatec.srv.br>. Acesso em 05 março 2008. 5 INPART, Inpart Serviços LTDA. Disponível em <http://www.inpart.com.br>. Acesso em 05 março 2008.

21

• Permite uma pesquisa utilizando os seguintes filtros: placa do veículo, número do

sinistro, código da seguradora e código da oficina;

• Permite que as distribuidoras entrem com os seguintes dados: grupo da peça, preço

líquido e prazo de entrega;

• Possui um layout amigável, que possibilita ao usuário uma rápida utilização do

mesmo, ou seja, este sistema é de fácil utilização.

O principal problema identificado pelas seguradoras no uso do sistema Prismatec é

não permitir o cadastro de um motivo caso o preço da distribuidora esteja acima do preço de

tabela. Outro problema encontrado é a não possibilidade de visualizar o preço de tabela

existente no mercado de autopeças.

O sistema Inpart contempla as seguintes funcionalidades:

• Permite às seguradoras visualizarem orçamentos finalizados, cancelados e

orçamentos a verificar;

• Login separado para cada perfil de usuário, ou seja, um login para as seguradoras e

um login para as distribuidoras;

• Permite um login separado para cada usuário do sistema, ou seja, para cada

operador do sistema;

• Permite uma pesquisa utilizando os seguintes filtros: tipo da empresa, empresa,

mensagem, período da cotação;

• Permite que as distribuidoras entrem com os seguintes dados: grupo da peça, preço

líquido, prazo de entrega e motivo caso o produto esteja acima do preço de tabela;

• Possue uma tabela com os preços praticados pelo mercado de peças automotivas.

O sistema Inpart possui os seguintes problemas verificados pelas seguradoras:

• O sistema é de difícil utilização;

• O sistema possui um layout de má qualidade;

• O sistema possui problemas quando utilizado em browsers diferentes do internet

Explorer.

Assim, o SISCOT irá unir as boas práticas contempladas nos dois sistemas e corrigir

as eventuais falhas verificadas nos mesmos.

22

CAPÍTULO V

5. PLANEJAMENTO DO PROJETO

5.1. Plano do Processo de Desenvolvimento

5.1.1. Ciclo de vida do projeto

A solução a ser desenvolvida utilizara o ciclo de vida ITERATIVO6, onde irá gerar um

executável a cada iteração, podendo assim ser validado junto ao cliente os requisitos não

compreendidos. O sistema também usará a técnica da prototipagem, onde o cliente dará o

feedback em relação à estrutura do futuro sistema. O Quadro1 ilustra bem o funcionamento

deste modelo de processo.

Quadro1. Processo Unificado

O ciclo de vida a ser utilizado será o Processo Unificado, que tem por característica o

uso de ITERAÇÕES. O Processo Unificado é composto por 4 fases:

• Iniciação, cujo objetivo é definir o escopo do sistema;

• Elaboração, cujo objetivo é detalhar os requisitos identificados no escopo, tratar

mudanças e modelar os requisitos que para implementação na próxima fase;

6 PRESSMAN, Roger S. Engenharia de Software. 5 ed. Rio de Janeiro: McGraw-Hill, 2002.

23

• Construção caracteriza-se pela implementação e teste do código que foi modelado

na fase anterior;

• Transição que tem por objetivo implantar o sistema e realizar o treinamento

necessário.

Para o desenvolvimento do sistema foi planejado 4 interações, descritas abaixo:

Iteração 1: Nesta iteração o desenvolvimento se fixará no entendimento inicial no

sistema, onde será determinado o escopo da aplicação.

Iteração 2: Nesta interação, o desenvolvimento irá basear-se nos casos de uso mais

complexos: Cotar Peça, Orçar Peça, Visualizar Orçamento e Visualizar Peça.

Iteração 3: Esta interação visa o desenvolvimento dos demais casos de uso.

Iteração 4: Esta interação visa à implementação dos sistemas de relatórios.

Atividades desenvolvidas em cada iteração:

• Levantamento de requisitos: Fase que define claramente o que se deseja do

sistema.

• Análise e Projeto: Fase que define a estrutura do módulo a ser desenvolvido.

Nesta fase também serão analisados os requisitos para eliminação ou alteração dos

mesmos para então poder ser definidos as estruturas do subsistema.

• Implementação: Implementação real do que foi definido na fase de Analise e

Projeto, traduzindo o módulo para a linguagem de programação também definida

na fase anterior.

• Testes: Teste das funcionalidades implementadas.

• Implantação: É a fase onde o sistema é posto em operação para uso do cliente, no

caso as Seguradoras.

5.1.2. Métodos de Desenvolvimento e ferramentas CASE

O método a ser utilizado será o orientado a objeto. Este método foi escolhido tomando

previamente os seguintes cuidados:

• A adequação à tecnologia de desenvolvimento;

24

• Os conhecimentos prévios e as preferências da equipe de desenvolvimento;

• A facilidade de aprendizado;

• A facilidade de integração com outros métodos;

• A existência de ferramentas que automatizem o método.

Ferramentas CASE utilizadas:

• Eclipse;

• Jude Professional Versão 5.1;

• Apache Tomcat Version 6.0;

• Toad Data Modeler.

5.1.3. Linguagens de programação

As linguagens a serem utilizadas para o desenvolvimento e implementação do projeto

de banco de dados serão as seguintes:

• No projeto será utilizada a linguagem de programação JAVA pela sua

portabilidade, podendo ser utilizada em qualquer sistema operacional, pela fácil

documentação e pela facilidade em encontrar profissionais qualificados;

• Uso do SGBD MySQL, que disponibiliza o padrão SQL e uma interface de

administração para banco de dados.

5.1.4. Ambiente de hardware para o desenvolvimento

01 computador Pentium IV 2.6 Ghz com 512MB de RAM.

5.2. Plano de Organização

A equipe de desenvolvimento do SISCOT será composta pelos alunos descritos neste

documento, onde atuaram tanto na gerência quanto no desenvolvimento do sistema.

5.2.1. Equipe de Gerência

O gerenciamento do projeto será feito pelos alunos mencionados neste documento e o

controle desta equipe de gerência será feito pelo Orientador e pelo Co-Orientador deste

projeto final. Assim, os alunos atuarão como Gerentes de Projetos, ente definido no item

3.4.7.

25

5.2.2. Equipe de Desenvolvimento

A responsabilidade em desenvolver o sistema caberá aos alunos mencionados neste

documento. Os papéis da equipe de desenvolvimento foram definidos no item 3.4.7 deste

documento.

5.3. Plano de Acompanhamento

5.3.1. Marcos e Pontos de Controle

Quadro2. Pontos de controle do projeto Marco Resultado Data

1 Levantamento dos Requisitos 12/04/2008

2 Protótipos de Tela 19/04/2008

3 Modelo de Caso de Uso 26/04/2008

4 Modelo de Análise 10/05/2008

5 Definição da Arquitetura do sistema 21/05/2008

6 Implementação dos casos de uso

principais

31/05/2008

7 Implementação dos casos de uso

secundários

04/10/2008

8 Entrega da documentação do Projeto 01/11/2008

9 Entrega do produto final 22/11/2008

5.3.2. Métodos de acompanhamento e controle

Reuniões aos sábados para discussões de problemas e consulta ao andamento do

sistema com base nos marcos de controle. Possibilidade de outras reuniões em local e data

previamente definidas.

26

5.3.3. Análise e Gerência de Riscos

5.3.3.1. Risco de pessoal

Quadro3. Risco de RH


Risco Descrição do Impacto

Durante o ciclo de vida do projeto, a perda de

membros da equipe pode ser inevitável, por

diversos motivos.

A perda de membros da equipe pode

ocasionar um atraso quanto à entrega do

projeto.

Mitigação

Deve ser previsto o remanejamento das atividades do projeto, bem como todos os artefatos

devem estar bem documentados e atualizados para que o possível substituto saiba aonde o

processo parou.


Durante o ciclo de vida do projeto, a equipe

técnica de desenvolvimento erra com bastante

freqüência.

Erros no desenvolvimento causam o

desenvolvimento de um produto sem

qualidade, ou podem dificultar a execução do

mesmo.

Mitigação

Verificar onde estar à maior incidência de erros, caso seja na linguagem ou ferramentas, uso de

treinamentos para a equipe.

27


5.3.3.2. Risco de negócio

Quadro6. Riscos relacionados com o negócio

5.3.4. Riscos técnicos

Quadro7. Riscos de caráter técnico


Falta de interesse da equipe de

desenvolvimento.

O desinteresse por parte dos desenvolvedores

pode gerar um produto que não irá cumprir o

objetivo original, ou até mesmo a

inviabilizará o seu desenvolvimento.

Mitigação

Relatar, em reuniões, as possíveis conseqüências do desinteresse por parte da equipe de

desenvolvimento e discutir o desligamento do possível desinteressado.


Exceder prazo de entrega dos artefatos

anteriormente planejados.

O atraso na entrega dos artefatos pode gerar

uma sobre carga de trabalho na equipe de

desenvolvimento e, por fim, o atraso na

entrega do produto.

Mitigação

Ter controle do gerenciamento do projeto, prevendo e identificando os possíveis atrasos e

readaptação das atividades e prazos para cumprimento da meta.


Risco de hardware.

Problemas com o hardware podem ocasionar

erros durante a execução do produto. Falhas

que podem ser creditadas para o sistema

desenvolvido.

Mitigação

Fazer testes de cargas e avaliação de performance dos equipamentos, caso constatado falha na

aplicação do sistema, fazer uma manutenção preventiva.

28

Quadro8. Riscos de caráter técnico

5.4. Plano de Documentação

5.4.1. Documentos do projeto

O Quadro 9 exibe a relação dos documentos gerados em cada fase do desenvolvimento

do SISCOT, bem como sua situação durante o desenvolvimento. Situação essa que aqui será

classificada como:

• Inicia, quando o documento inicia-se nesta fase;

• Refina, quando o documento é refinado.


Durante o ciclo de vida do projeto, observa-se

que ferramentas CASE adotadas não atendem

as necessidades para a concepção do projeto.

O uso inadequado de ferramentas de

desenvolvimento pode gerar um software sem

qualidade ou atrasos na entrega do mesmo.

Mitigação

Elaborar projetos pilotos a fim de avaliar a qualidade das ferramentas a serem adquiridas.

29

Quadro9. Documentos gerados Disciplina Artefato Concepção Elaboração Construção Transição

Modelagem de

Negócio

Modelo de

Domínio

Inicia

Análise de

Requisitos

1-Modelo Caso

de Uso;

2-Documento

Visão;

3-Glossário

Inicia Refina

Análise e design Modelo de

Design

Inicia Refina

Implementação Código Fonte Inicia Refina

Gerenciamento de

projeto

Plano de

Desenvolvimen

to de Software

Inicia Refina Refina Refina

5.5. Plano de Recursos e Produtos

5.5.1. Recursos Humanos

Quantidade Profissional

3 Alunos responsáveis pelo projeto

5.5.2. Recursos de Hardware

Cliente:



10/100, internet banda larga)

Servidor:


30


Disco rígido de 73Gb, Disco rígido adicional de 73Gb, placa de rede 10/100 com 4

portas)

5.5.3. Recursos de Software

Cliente:

• Windows 2000 ou superior;

• Browser (Firefox ou Internet Explorer).

Servidor:

• Servidor Web Apache;

• Windows Server® 2003 R2, Standard Edition with SP2;

• Banco de Dados MySQL.

5.5.4. Recursos Financeiros

Quadro10. Recursos financeiros estimados para o SISCOT

Atividades

Ano 2008

fev mar abr mai jun jul ago set out nov Total

Servidor R$ 6.048 R$ 6.048

Hardware para a Implementação

R$ 4.800 R$ 4.800

Total R$

- R$

5.550 R$

- R$ 6.048 R$

- R$

- R$

- R$

- R$

- R$

- R$ 11.598

Impressão da Documentação R$ 550 R$ 550

Total R$

- R$

- R$

- R$

- R$

- R$

- R$

- R$

- R$

- R$ 550 R$ 550

Gastos não esperados R$ 50 R$ 50

Deslocamento R$ 48 R$ 48 R$ 48 R$ 48 R$ 48 R$ 48 R$ 48

R$ 48 R$ 48 R$ 48 R$ 480

Total R$ 48 R$ 48 R$ 48 R$ 48 R$ 48 R$ 48 R$ 48

R$ 48 R$ 48 R$ 98 R$ 600

Total R$ 48

R$ 5.598 R$ 48 R$ 6.096 R$ 48 R$ 48 R$ 48

R$ 48 R$ 48 R$ 648 R$ 12.748

31

5.6. Cronograma

Quadro11. Cronograma de desenvolvimento

2008 Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro

Iteração 1

Iteração 2

Iteração 3

Iteração 4

5.7. Glossário

I

Iteração: Percorrer várias vezes as diversas disciplinas de desenvolvimento

S

Sinistro: Risco concretizado

T

TI: Tecnologia da Informação

U

UCB: Universidade Católica de Brasília

UML: Unified Modeling Language, linguagem utilizada para modelagem de softwares

32

CAPÍTULO VI

6. ESPECIFICAÇÃO DOS REQUISITOS DO SISTEMA

6.1. Descrição resumida do Problema

O bom atendimento e a satisfação do segurado são as metas principais de qualquer

Seguradora. Ao realizar cotações necessárias para o conserto do automóvel do segurado, a

seguradora busca o orçamento que melhor se adapte a relação custo X tempo.

Nem sempre a peça de menor preço é a mais viável. Por exemplo, em uma cotação X a

distribuidora A possui o menor preço, contudo o prazo de entrega pode tornar inviável a

contratação da distribuidora X.

6.2. Identificação dos interessados no sistema

Os administradores são os usuários do sistema que gerenciarão toda configuração do

sistema.

As distribuidoras são todos os usuários do sistema que usarão este para informar o seu

interesse em vender determinada peça ou peças para uma cotação da Seguradora.

A seguradora será o usuário do sistema que necessitará deste para efetuar a cotação

das peças propriamente dita.

6.3. Descrição das necessidades dos interessados

Os administradores têm as seguintes necessidades:

• Gerenciar o processo de cotação de peças;

• Garantir uma comunicação entre as distribuidoras e as seguradoras. Comunicação

com qualidade e rapidez;

• Gerenciar o cadastro de interessados nos processo de cotação de peças

automotivas.

As distribuidoras têm as seguintes necessidades:

• Orçar Cotação de acordo com as necessidades vindas de uma seguradora;

• Saber quantidade de peças que deve efetuar o orçamento;

• Saber quais peças deve efetuar o orçamento;

• Receber pedidos de cotação de peças;

• Enviar de maneira rápida uma cotação de peças automotivas.

33

As seguradoras têm as seguintes necessidades:

• Escolher qual orçamento está dentro de suas necessidades;

• Incluir novas distribuidoras que poderão negociar cotações com as seguradoras;

• Escolher cotações por alguns critérios estabelecidos, como data de entrega, preço;

• Executar o processo de cotação de maneira rápida.

6.4. Descrição das características do sistema

O sistema será desenvolvido para suportar o processo de cotação de peças vindo de

uma seguradora. A seguradora disponibilizará no sistema a sua necessidade de obter uma

cotação de peças automotivas para suprir uma necessidade oriunda de um sinistro.

O sistema terá como característica primordial a portabilidade, já que a linguagem em

que o mesmo será produzido permite tal característica. O usuário do sistema poderá acessar o

mesmo de qualquer microcomputador ligado à internet.

As principais características do sistema são:

• Possibilitar uma seguradora efetuar uma cotação de peças;

• Possibilitar uma seguradora autorizar um orçamento oriundo de uma distribuidora;

• Possibilitar uma seguradora visualizar orçamentos vindos de uma ou mais

distribuidoras e, assim, escolher o que mais for apropriado;

• Possibilitar uma seguradora pesquisar orçamentos efetuados pelas distribuidoras;

• Possibilitar acessos simultâneos do mesmo perfil, ou perfis diferentes.

• Permitir a inclusão de novos usuários: Seguradoras, Distribuidoras e

Administradores, por um administrador autorizado;

• Definir perfis de acesso: Seguradora, Distribuidora e Administradores.

6.5. Requisitos do software

6.5.1. Funcionalidades Disponíveis às Seguradoras

• Cotar peça: onde o objetivo é realizar o pedido de cotação de peças necessárias em

determinado sinistro junto às distribuidoras;

• Autorizar orçamento: onde o objetivo é autorizar um orçamento realizado pela

distribuidora;

• Visualizar peça: onde o objetivo é visualizar os dados da peça;

34

• Pesquisar cotação: onde o objetivo é pesquisar as cotações realizadas

anteriormente;

• Manter oficina: onde o objetivo é manter os dados da oficina aonde será entregue

as peças;

• Configurar dados pessoais: onde o objetivo é configurar os dados pessoais do

usuário, como senha e e-mail;

• Efetuar login: o objetivo é ter acesso às funcionalidades do sistema, de acordo com

o perfil de seguradora.

6.5.2. Funcionalidades disponíveis aos administradores

• Manter o usuário: onde o objetivo é manter os dados do usuário;

• Manter Empresa: onde o objetivo é manter os dados da empresa;

• Manter Peça: onde o objetivo é manter os dados da peça. Os dados da peça

(número de fábrica, marca, nome, descrição, preço) serão alimentados com dados

providos das próprias fábricas;

• Manter Oficina: onde o objetivo é manter os dados da oficina aonde será entregue

as peças;




o perfil de administrador.

6.5.3. Funcionalidades disponíveis às Distribuidoras

• Orçar Cotação: onde o objetivo é orçar a cotação feita pela Seguradora;

• Visualizar cotação autorizada: onde o objetivo é visualizar as peças autorizadas

pela seguradora para aquela distribuidora;

• Pesquisar orçamento: onde o objetivo deste é pesquisar os orçamentos realizados

pela Distribuidora;

• Visualizar peça: onde o objetivo é visualizar os dados da peça;

• Pesquisar cotação: onde o objetivo é pesquisar as cotações realizadas

anteriormente;

35




o perfil de administrador.

6.6. Requisitos suplementares

6.6.1. Requisitos de Processo

6.6.1.1. Desenvolvimento em Java

O sistema será desenvolvido utilizando a linguagem java, pois se trata de uma

linguagem que permite a portabilidade.

6.6.1.2. Modelagem do Sistema

Para reduzir a incidência de erros ao longo do projeto, será utilizada a

ferramenta Case Jude para modelagem do sistema.

6.6.1.3. Base de dados MySQL

O sistema utilizará o Banco MySQL, pois o mesmo é estável e gratuito.

6.6.2. Requisitos de Produto

6.6.2.1. Compatibilidade

O sistema será compatível com qualquer browser que o usuário escolha para o

seu trabalho.

6.6.2.2. Interface Amigável

A interface visual do sistema terá como característica ser bastante intuitiva e a

linguagem adaptada ao processo de negócio.

6.6.2.3. Segurança

O controle de acesso do sistema será feito com o uso de login de usuário.

36

6.7. Restrições

A linguagem adotada para desenvolvimento do sistema será a linguagem Java.

37

CAPÍTULO VII

7. MODELOS DO NEGÓCIO

7.1. Diagrama de Caso de Uso de Negócio

Figura1. Modelo de negócios

38

7.2. Diagrama de classe do negócio

Figura2. Modelo de domínio

39

7.3. Diagrama de atividades

Figura3. Diagrama de atividades

40

CAPÍTULO VIII

8. MODELOS DE CASOS DE USO

8.1. Visão geral dos Casos de Uso e atores

8.1.1. Atores

Figura4. Atores do sistema

8.1.1.1. Casos de uso principais

Figura5. Casos de uso principais

41

8.1.1.2. Casos de uso secundários

Figura6. Casos de uso secundários

Figura7. Casos de uso secundários

42

8.2. Descrição dos Casos de Uso

8.2.1. Efetuar Login

Objetivo:

Este caso de uso visa a identificar e autenticar os usuários que possuem permissão para

o uso do sistema, conforme o seu perfil de usuário.

Atores:

Seguradora, Distribuidora e Administrador.

Fluxo principal:

O caso de uso inicia-se quando o ator acessa a URL do sistema.

1. O sistema exibe a tela de login do sistema; Quadro 12

2. O ator informa o seu login;

3. O ator informa a sua senha;

4. O ator pressiona o botão “Login”;

5. O sistema valida as informações do ator e carrega todas as funcionalidades

possíveis para o perfil do ator; 6.[A1]

6. O caso de uso se encerra.

Fluxos alternativos:

[A1]. Caso o login ou a senha não sejam válidos, o sistema exibe a mensagem:

“Dados Inválidos”. O sistema retorna para o passo 1.

Fluxos de exceção: Não se aplica

Pré-condições: Não se aplica.

Pós-condição: Não se aplica

43

Atributos:

Quadro12. Dados do Login Nome Tipo Descrição Obrigatório

Usuário String Login do ator para obter

acesso ao sistema.

Sim

Senha String Senhas do ator para obter

acesso ao sistema.

Sim

Protótipo:

Figura8. Layout Login

8.2.2. Cotar Peça

Objetivo:

Realizar o pedido de cotação de peças necessárias a um determinado sinistro junto às

distribuidoras.

Ator:

Seguradora

Fluxo principal:

O Caso de Uso inicia-se quando o ator seleciona a opção “Cotação” e pressiona o

botão “adicionar”.

1. O sistema exibe um formulário de cadastro da cotação. Quadro 13

2. O ator informa os dados da cotação. [A1] [A2] [A5]

3. O sistema valida os dados enviados da cotação. [A3] [A4]

4. O sistema cadastra os dados da cotação.

44

5. O sistema exibe mensagem de sucesso.



[A1]. Caso o ator necessite de adicionar mais uma foto à cotação, o ator deverá

pressionar o botão “Adicionar”, presente no formulário de cadastro do veículo. O

sistema criará mais uma linha para a inclusão da nova peça. O sistema retorna para

o passo 1.

[A2]. Caso o ator necessite de adicionar mais uma peça à cotação, o ator deverá

pressionar o botão “Adicionar”, presente no formulário de cadastro da peça. O

sistema criará mais uma linha para a inclusão da nova peça. O sistema retorna para

o passo 1.

[A3]. Caso o ator não tenha informado algum dos dados obrigatórios, o sistema exibe

uma mensagem de erro e indica quais dados obrigatórios não foram preenchidos.

O sistema retorna para o passo 1, mantendo os dados inicialmente digitados.

[A4]. Caso o informe um valor inválido para qualquer um dos dados obrigatórios, o

sistema exibe uma mensagem de erro e indica onde ocorreu o erro. O sistema

retorna para o passo 1, mantendo os dados inicialmente digitados.

[A5]. Caso exista um terceiro envolvido no sinistro e o ator deseje cadastrá-lo no

sistema, poderá fazê-lo pressionando o botão “Mais Campos”. O sistema retorna

para o passo 1.

[A6]. Caso o ator necessite adicionar mais dados para o veículo, poderá fazê-lo

pressionando o botão “Mais Campos”. O sistema retorna para o passo 1.

Fluxos de exceção: Não se aplica.

Pré-condições:

Realizar comportamento do UC01 - Efetuar Login.

Pós-condição: Não se aplica.

45

Atributos:

Quadro13. Dados da Cotação Nome Tipo Descrição Obrigatório

Número do sinistro String Número do sinistro. Não

Número da apólice String Número da apólice de

seguro.

Não

Placa String Placa do veículo. Não

Chassi String Chassi do veículo. Não

Marca String Marca do veículo. Sim

Modelo String Modelo do veículo. Sim

Motor String Motor do veículo. Não

Ano Fabricação Integer Ano de Fabricação do

veículo.

Sim

Ano Modelo Integer Ano Modelo do veículo. Sim

Combustível String Combustível do veículo. Não

Portas Integer Quantidade de portas do

veículo.

Não

Cor String Cor do Veículo. Não

Tipo da Cor String Tipo da cor do veículo.

Ex: Metálica, sólida.

Não

Observações String Observações pertinentes

sobre o veículo.

Não

Fotos String Caminho da foto a ser

adicionada na cotação.

Não

Nome (Cliente) String Nome do cliente. Não

CPF/CNPJ (Cliente) Integer CPF ou CNPJ do cliente. Não

Telefones (Cliente) Integer Telefones do cliente. Não

Nome (Terceiro) String Nome do terceiro. Não

CPF/CNPJ

(Terceiro)

Integer CPF ou CNPJ do terceiro. Não

Telefones (Terceiro) Integer Telefones do terceiro. Não

Número da peça String Número cadastrado no

sistema da peça.

Sim

46

Nome Tipo Descrição Obrigatório

Marca String Marca da peça. Sim

Descrição String Descrição da peça a ser

cotada.

Sim

Quantidade Integer Quantidade da peça a ser

cotada

Sim

Protótipo:

Figura9. Layout Cotar Peça

47

8.2.3. Orçar Cotação

Objetivo:

O objetivo deste caso de uso é orçar a cotação feita pela Seguradora.

Ator:

Distribuidora

Fluxo principal:

O Caso de Uso inicia-se quando o ator seleciona a opção de “Cotação” e pressiona o

botão “abertas”.

1. O sistema exibe uma lista com dados de todas as cotações realizadas por todas as

seguradoras e não orçadas ainda.

2. O ator seleciona uma cotação.

3. O sistema exibe os dados da seguradora, do cliente, do terceiro, da oficina, do

veículo e das peças danificadas. Do quadro 14 ao 20

4. O sistema, dentro do campo peças, exibe a opção de inclusão do valor da peça a

ser disponibilizada e a data de entrega da mesma.

5. O ator insere o valor e a data de entrega da peça. [A1]

6. O usuário pressiona o botão “Orçar”. [A2] [A3]



[A1]. Caso a Distribuidora não forneça determina peça, o ator deverá selecionar a

opção “Não fornece”.

[A2]. Caso a Distribuidora informe o valor da peça superior ao valor de tabela, o

sistema exibe uma mensagem de alerta solicitando ao usuário uma justificativa.

Esta mensagem deverá ser adicionada no campo “Observações”. Volta para o

passo 5.

[A3]. Caso a Distribuidora informe uma data de entrega maior do que a data de

entrega pedida pela Seguradora, o sistema exibe uma mensagem de alerta

solicitando ao usuário uma justificativa. Esta mensagem deverá ser adicionada no

campo “Observações”. Volta para o passo 5.

48


Pré-condições:



Atributos:

Quadro14. Seguradora Nome Tipo Descrição Obrigatório

CNPJ Integer CNPJ da Seguradora. Não

Insc. Estadual Integer Inscrição Estadual da Seguradora. Não

Insc. Municipal Integer Inscrição Municipal da

Seguradora.

Não

Razão Social String Razão Social da Seguradora. Não

Nome Fantasia String Nome Fantasia da Seguradora. Sim

CEP Integer CEP da Seguradora. Não

Estado String Estado da Seguradora. Não

Cidade String Cidade da Seguradora. Não

Bairro String Bairro da Seguradora. Não

Endereço String Endereço comercial da

Seguradora.

Não

Contato String Contato na Seguradora. Não

Email String E-mail da Seguradora. Não

Telefones Integer Telefones da Seguradora. Não

Fax Integer Fax da Seguradora. Não

Quadro15. Cotação Nome Tipo Descrição Obrigatório

Número do

Sinistro

Integer Sinistro registrado pela

seguradora.

Não

Número da

Apólice

Integer Número Apólice de seguros. Não

49

Quadro16. Cliente Nome Tipo Descrição Obrigatório

Nome String Nome do Cliente. Não

CPF/CNPJ Integer CPF/CNPJ do Cliente. Não

Telefones Integer Telefones do Cliente. Não

Quadro17. Terceiro Nome Tipo Descrição Obrigatório

Nome String Nome do Terceiro. Não

CPF/CNPJ Integer CPF/CNPJ do Terceiro. Não

Telefones Integer Telefones do Terceiro. Não

Quadro18. Oficina Nome Tipo Descrição Obrigatório

CNPJ Integer CNPJ da Oficina. Não

Insc. Estadual Integer Inscrição Estadual da Oficina. Não

Insc. Municipal Integer Inscrição Municipal da Oficina. Não


Nome Fantasia String Nome Fantasia da Oficina. Não

CEP Integer CEP da Oficina. Não

Estado String Estado da Oficina. Não

Cidade String Cidade da Oficina. Não

Bairro String Bairro da Oficina. Não

Endereço String Endereço comercial da Oficina. Não

Contato String Contato na Oficina. Não

Email String E-mail da Oficina. Não

Telefones Integer Telefones da Oficina. Sim

Fax Integer Fax da Oficina. Não

Quadro19. Veículo Nome Tipo Descrição Obrigatório

Placa String Placa do Veículo. Não

Chassi String Chassi do Veículo. Não

Marca String Marca do Veículo. Sim

50


Modelo String Modelo do Veículo. Sim

Motor String Motor do Veículo. Não


Veículo.

Sim

Ano Modelo Integer Modelo do Veículo. Sim

Combustível String Combustível do Veículo. Não

Portas String Número de Portas do Veículo Não


Tipo da Cor String Tipo da cor do Veículo. Não

Observações String Observações relacionadas com

o Veículo.

Não

Quadro20. Peça Nome Tipo Descrição Obrigatório

Número da Peça String Número da Peça. Sim

Marca String Marca da Peça. Sim

Descrição String Descrição da Peça. Sim

Qnt String Quantidade da peça orçada. Sim

Valor Tabela String Valor tabelar da peça. Não

Valor (R$) Integer Valor da peça orçada pela

distribuidora.

Sim

Data de Entrega Integer Data de entrega da peça por

parte da distribuidora.

Sim

Obs String Observações relacionadas com

a peça.

Não

Protótipos:

Figura10. Layout Orçar Cotação

52

8.2.4. Autorizar Orçamento

Objetivo:

O objetivo deste caso de uso é autorizar um orçamento realizado pela distribuidora.

Ator:

Seguradora

Fluxo principal:


botão “autorizar”.

1. O sistema exibe uma lista com dados de todas as cotações abertas, orçadas e

aguardando autorização.

2. O ator seleciona uma cotação.

3. O sistema exibe os dados da seguradora, da cotação, do cliente, do terceiro, da

oficina, do veículo e das peças. Do quadro 21 ao 26

4. O usuário pressiona o botão “Autorizar”.


Fluxos alternativos: Não se aplica.


Pré-condições:



53

Atributos:





Seguradora.

Não








Seguradora.

Não



Telefones Integer Telefones da Seguradora. Sim






54










Nome Fantasia String Nome Fantasia da Oficina. Sim

















Veículo.

Sim


55






Descrição String Descrição relacionada com o

Veículo.

Não

Fotos Imagem Fotos cadastradas relacionadas

com o veículo segurado.

Não

Quadro26. Orçamento Nome Tipo Descrição Obrigatório





Valor Unitário

Tabela

String Valor tabelar da peça. Não


distribuidora.

Sim



Sim


a peça.

Não

Protótipos:

Figura11. Layout Autorizar Orçamento

57

8.2.5. Visualizar Cotação Autorizada

Objetivo:

O objetivo deste caso de uso é a visualização das cotações autorizadas pela

Seguradora.

Obs.: No momento em que a Distribuidora orça a cotação, ela está assumindo um

compromisso de que entregará a peça na data em que ela define ser capaz de realizar a

entrega.

Ator:

Distribuidora

Fluxo principal:


botão “autorizadas”.

1. O sistema exibe uma lista com todos os orçamentos autorizados e que a data de

entrega não esteja expirada ainda.

2. O ator seleciona uma cotação autorizada.

3. O sistema exibe os dados da seguradora, da cotação, do cliente, do terceiro, da

oficina, do veículo e dos itens autorizados. Do quadro 27 ao 32


Fluxos alternativos: Não se aplica.


Pré-condições:



Atributos:


58





Seguradora.

Não








Seguradora.

Não



Telefones Integer Telefones da Seguradora. Não













59



Razão Social String Razão Social da Seguradora. Sim

Nome Fantasia String Nome Fantasia da Oficina. Não
















Ano Fabricação Integer Ano de Fabricação do Veículo. Sim






Fotos Imagem Fotos relacionadas com o sinistro. Não

Descrição String Descrição relacionadas com o

Veículo.

Não

Quadro32. Itens Autorizados Nome Tipo Descrição Obrigatório

60






Valor Unitário Float Valor tabelar da peça. Não

Sub Total Float Valor subtotal dos itens

cotados.

Sim

Valor Total Float Valor total dos itens cotados. Sim

Protótipos:

Figura12. Layout Visualizar Cotação autorizada

61

8.2.6. Pesquisar Cotação

Objetivo:

O objetivo deste caso de uso é possibilita aos atores pesquisar uma cotação já

realizada.

Atores:

Seguradora e Distribuidora.

Fluxo principal:

O caso de uso se inicia quando os atores seleciona a opção “Cotação” e em seguida a

opção “Pesquisar”

1. O sistema exibe uma tela com os dados de entrada para a pesquisa; Quadro 32

2. Os ator seleciona um ou mais dados de entrada. Os campos: “Número do Sinistro,

Número da Apólice e Placa do Veículo” podem ser passados parcialmente;

3. O ator pressiona o botão “Pesquisar”; [A1] [A2]

4. O sistema retorna com os dados da cotação; Do quadro 33 ao 39

5. O caso de uso Pesquisar Cotação se encerra.


62

[A1]. Caso o sistema não exista cotação que satisfaça os dados de pesquisa, o sistema

exibe a mensagem: “Nenhum registro foi encontrado”. Retorna para o passo 1.

[A2]. Caso o usuário não passe nenhuma condição de pesquisa, o sistema retornará

com todas as cotações existentes no sistema.


Pré-condições:



Atributos:

Quadro33. Pesquisa Nome Tipo Descrição Obrigatório

Intervalo da

Data de Registro

Date Período correspondente da data de

registro da cotação.

Não

Número do

Sinistro

String Número do Sinistro. Não

Número da

Apólice

String Número da apólice do seguro. Não

Placa do

Veículo

String Placa do Veículo assegurado. Não

Quadro34. Resultado Nome Tipo Descrição Obrigatório


Número da

Apólice

String Número da Apólice. Não

Placa String Placa do Veículo Não

Data de Registro String Data de Registro da

Cotação

63

Quadro35. Cliente



Número da apólice String Número da Apólice. Não









ID da oficina Integer Identificador da Oficina Não

Tipo String Tipo da empresa Não

CNPJ Integer CNPJ da Oficina Não

Razão Social String Razão Social da Oficina Não

Nome fantasia String Nome Fantasia da Oficina Sim

Inscrição Estadual String Inscrição Estadual Não

Inscrição

Municipal

String Inscrição Municipal Não

CEP Integer CEP da Oficina Não

Estado String UF da Oficina Não

Cidade String Cidade onde a oficina está

domiciliada

Não

Bairro String Bairro onde a oficina está

domiciliada

Não

Contato String Contato na oficina Não

Email String E-mail da oficina Não

Telefone Integer Telefone da oficina Sim

64


Fax String Fax da oficina Não

Data de Registro String Data de registro da oficina Não

Ativa Integer Indica se a oficina está ativa ou

não.

Não

Quadro38. Peças Nome Tipo Descrição Obrigatório





Valor Tabela String Valor tabelar da peça. Não


distribuidora.

Sim



Sim


a peça.

Não








Veículo.

Sim





65



Descrição String Descrição relacionada com o

Veículo.

Não

Fotos Imagem Fotos cadastradas relacionadas

com o veículo segurado.

Não

Quadro40. Orçamento Nome Tipo Descrição Obrigatório

Num peça Integer Número da peça a ser trocada Não

Marca String Marca da peça Não

Descrição Integer Descrição Não

Quantidade String Quantidade de peças Não

Valor unitário String Valor unitário das peças Não

Distribuidora String Nome da distribuidora das peças Não

Data de Entrega String Data de entrega Não

Obs Integer Observações Não

Fornece String Indica se a peça é fornecida pela

distribuidora.

Não

Protótipos:

Figura13. Layout Pesquisar Cotação

67

8.2.7. Visualizar Peça

Objetivo:

O objetivo deste caso de uso é possibilitar aos atores visualizarem determinada peça

existente no sistema.

Atores:

Seguradora e Distribuidora.

Fluxo principal:

O caso de uso se inicia quando o ator seleciona a opção “Cadastro” e a opção

“Pesquisar Peça” logo em seguida.

1. O sistema exibe uma tela com os dados de entrada para a pesquisa de uma ou mais

peças; Quadro 42

2. O ator seleciona um ou mais dados de entrada para a pesquisa;

3. O usuário pressiona o botão “Pesquisar”; [A1] [A2]

4. O sistema retorna com os dados da peça; Quadro 41

5. O caso de uso Visualizar Peça se encerra.


[A1]. Caso o sistema não exista uma peça que satisfaça os dados de pesquisa, o

sistema exibe a mensagem: “Nenhum registro foi encontrado”. Retorna ao passo 1.

[A2]. Caso o ator não passe nenhuma condição de pesquisa, o sistema retornará com

todas as peças existentes no sistema.

68


Pré-condições:



Atributos:


Número da Peça Integer Número da peça a ser

pesquisada.

Não

Marca String Marca da peça. Não

Descrição String Descrição da peça. Não

Ativa ComboBox Verifica se a peça está ativa ou

não dentro do sistema

Não

Quadro42. Resultado Nome Tipo Descrição Obrigatório

Número da Peça Integer Número da peça a ser

pesquisada.

Não

Marca String Marca da peça. Não


Valor Float Preço de tabela da peça. Não

Ativa ComboBox Verifica se a peça está ativa ou

não dentro do sistema

Não

69

Protótipos:

Figura14. Layout Visualizar Peça

8.2.8. Configurar Dados Pessoais

Objetivo:

O objetivo deste caso de uso é permitir ao ator configurar os dados pessoais

cadastrados no sistema.

Atores:

Distribuidora, Seguradora e Administrador.

Fluxo principal:

O Caso de uso inicia-se quando o ator seleciona a opção “Configurações”.

1. O sistema exibe uma tela com os dados pessoais do usuário; Quadro 43

2. O ator altera os dados desejados. O ator só poderá alterar a senha e o e-mail;

Caso o usuário deseje alterar o campo senha, deverá seguir os seguintes passos:

Inserir senha atual;

Inserir a nova senha;

Confirmar a nova senha.

3. O ator altera os dados desejados. O ator só poderá alterar a senha e o e-mail;

4. O usuário pressiona o botão “Salvar”; [A1] [A2]

5. O sistema exibe uma mensagem de sucesso.

70



[A1]. Caso o usuário altere o campo nova senha e não insira o campo senha atual, o

sistema exibe a mensagem “Insira a sua senha atual”. Retorna ao passo 1.

[A2]. Caso o usuário altere o campo nova senha e não confirme esta nova senha no

campo “Confirmar Nova Senha”, o sistema exibe a mensagem “Confirme a alteração da

senha”. Retorna ao passo 1.


Pré-condições:



Atributos:

Quadro43. Dados Pessoais Nome Tipo Descrição Obrigatório

Nome String Nome do usuário. Este campo

não é editável.

Sim

Login String Login do usuário. Este campo

não é editável.

Sim

Senha Atual String Senha atual do usuário. Sim

Nova Senha String Nova senha do usuário. Não

Confirmação String Confirmar a nova senha. Não

Email String E-mail do usuário. Não

71

Protótipo:

Figura15. Layout Configurar Dados Pessoais

8.2.9. Manter Usuário

Objetivo:

O objetivo deste caso de uso é possibilitar ao ator pesquisar, alterar, excluir e inclui

um usuário no sistema.

Ator:

Administrador, Seguradora e Distribuidora.

Fluxo principal:

O Caso de Uso inicia-se quando o ator seleciona a opção “Cadastros” e a opção

“Usuário”.

1. O sistema exibe uma tela com as ações possíveis no que tange o gerenciamento de

usuários;

2. O ator seleciona a ação desejada;

Caso selecione a opção “Incluir”, o sistema executa o cenário descrito pelo

subfluxo Incluir;

Caso selecione a opção “Pesquisar”, o sistema executa o cenário descrito pelo

subfluxo Pesquisar;

Caso o ator tenha perfil de Administrador, poderá gerenciar todos os usuários

do sistema.

Caso o ator tenha perfil de Seguradora e de usuário Master, poderá gerenciar

apenas os usuários que tenham o perfil Seguradora e pertencentes à seguradora a qual

trabalha.

72

Exemplo: O usuário master da Seguradora A só poderá alterar os dados dos

usuários da própria Seguradora A.

Caso o ator tenha perfil de Distribuidora e de usuário Master, poderá gerenciar

apenas os usuários que tenham o perfil Distribuidora e pertencentes a distribuidora a

qual trabalha.

Exemplo: O usuário master da Distribuidora B só poderá alterar os dados dos

usuários da própria Distribuidora B.

3. O caso de uso Manter Usuário se encerra.

Subfluxos:

Incluir

1. O sistema exibe uma tela com os dados de entrada para a inclusão de um novo

usuário; Quadro 46

2. O ator insere os dados desejados; [A1]

3. O ator pressiona o botão “Salvar”; [A2]

4. O Subfluxo Incluir se encerra.

Pesquisar

1. O sistema exibe uma tela com os usuários cadastrados, de acordo com o

argumento da pesquisa; [A3] Quadro 45

2. O ator seleciona um usuário;

3. O sistema exibe as ações possíveis para o ator;

Caso o ator selecione a opção “Alterar”, o sistema executa o subfluxo Alterar;

Caso o ator opte por excluir um usuário no sistema, o mesmo terá que alterar o

campo “Ativo” para o valor “Não.

4. O Subfluxo Pesquisar se encerra.

Alterar

1. O sistema exibe uma tela com os dados do usuário selecionado; Quadro 47

2. O ator altera os dados desejados; [A1]


4. O Subfluxo Alterar se encerra.


73

[A1]. O campo “Empresa” só estará ativo para o usuário de perfil Administrador,

para os outros perfis este campo será preenchido pelo nome da empresa ao qual pertence o

ator.

[A2]. Caso o ator não insira algum dos campos obrigatórios, o sistema exibirá a

seguinte mensagem: “Existem dados obrigatórios não preenchidos”. Retorna ao passo 1.

[A3]. Caso o ator não insira um argumento de pesquisa, o sistema retornará com

todos os usuários presentes na sua empresa, conforme o seu perfil de usuário.


Pré-condições:



Atributos:


Nome do usuário String Nome do usuário. Não

Login String Login do usuário. Não

Empresa String Pesquisa o usuário por empresas Não

Perfil String Pesquisa o usuário por perfil Não

Quadro45. Resultado Pesquisa Nome Tipo Descrição Obrigatório

Nome String Nome do usuário. Sim

Login String Login do usuário. Sim


Perfil ComboBox Exibe o perfil do usuário Sim

Empresa ComboBox Exibe a empresa do usuário. Sim

Ativo ComboBox Indica se o usuário está ativo

ou não.

Sim

74

Quadro46. Incluir Nome Tipo Descrição Obrigatório



Senha String Senha do usuário. Sim


Confirmação String Confirmação da senha Sim

Tipo ComboBox Indica se o usuário será

cadastrado como usuário

máster.

Sim

Perfil ComboBox

Empresa ComboBox Insere a empresa ao qual

pertence o usuário.

Sim

Quadro47. Alterar Nome Tipo Descrição Obrigatório




Tipo ComboBox Indica se o usuário será

cadastrado como usuário

máster.

Sim

Perfil ComboBox

Empresa ComboBox Insere a empresa ao qual

pertence o usuário.

Sim

Ativo ComboBox Indica se o usuário está ativo

ou não no sistema

Não

Protótipos:

75

Figura16. Layout Pesquisar Usuário

Figura17. Layout Resultado da Pesquisa

Figura18. Layout Alterar Usuário

76

Figura19. Layout Incluir usuário

8.2.10. Manter Empresa

Objetivo:


uma empresa dentro do sistema.

Ator:

Administrador.

Fluxo principal:

O Caso de Uso inicia-se quando o ator seleciona a opção “Cadastros” e logo em

seguida “Empresa”.


empresas;



subfluxo Incluir;


subfluxo Pesquisar;

3. O caso de uso Manter Empresa se encerra.

Subfluxos:

Incluir

1. O sistema exibe uma tela com os dados de entrada para a inclusão de uma nova

empresa; Quadro 49

77


3. O ator pressiona o botão “Salvar”;


Pesquisar

1. O sistema exibe uma tela com as empresas cadastradas, de acordo com o

argumento da pesquisa; Quadro 48 [A2]

2. O ator seleciona uma empresa;



Caso o ator opte por excluir uma empresa no sistema, o mesmo terá que alterar

o campo “Ativo” para o valor “Não.


Alterar

1. O sistema exibe uma tela com os dados da empresa selecionada; Quadro 50








todas as empresas cadastradas no sistema.


Pré-condições:



Atributos:

78


Razão Social String Razão Social da Empresa. Não

Nome fantasia String Nome Fantasia da Empresa. Não

Inscrição Estadual Integer Inscrição Estadual da Empresa. Não

Inscrição

Municipal

Integer Inscrição Municipal da Empresa. Não

Tipo String Tipo da empres Não

Estado String Estado da Empresa. Não

CNPJ Integer CNPJ da Empresa Não


Tipo String Tipo da Empresa. Não

CNPJ Integer CNPJ da Empresa. Não


Nome Fantasia String Nome Fantasia da Empresa. Não


Inscrição

Municipal


CEP Integer CEP da Empresa. Não


Cidade String Cidade da Empresa. Não

Bairro String Bairro da Empresa. Não

Endereço String Endereço da Empresa. Não

Contato String Contato na Empresa. Não

Email String E-mail da Empresa. Não

Telefones Integer Telefones da Empresa. Não

Fax Integer Fax da Empresa. Não




79






Inscrição

Municipal











String Tipo da empresa Não

80

Protótipos:

Figura20. Layout Pesquisar Empresa


Figura22. Layout Alterar Empresa

81

Figura23. Layout Incluir Empresa

8.2.11. Manter Peça

Objetivo:


uma peça dentro do sistema.

Atores:

Administrador.

Fluxo principal:

O Caso de Uso inicia-se quando o ator seleciona a opção “Pesquisar Peça”.


peças;



subfluxo Incluir;


subfluxo Pesquisar;

3. O caso de uso Manter Peça se encerra.

Subfluxos:

82

Incluir


peça; Quadro 52




Pesquisar:

1. O sistema exibe uma tela com as peças cadastradas, de acordo com o argumento da

pesquisa; Quadro 51 [A2]

2. O ator seleciona uma peça;



Caso o ator opte por excluir uma peça no sistema, o mesmo terá que alterar o



Alterar

1. O sistema exibe uma tela com os dados da peça selecionada; Quadro 5








todas as peças cadastradas no sistema.


Pré-condições:

83



Atributos:

Quadro51. Pesquisar Nome Tipo Descrição Obrigatório

Número da Peça String Número tabelar da peça. Não



Ativa ComboBox Ativa ou não o bem Sim


Número da Peça String Número tabelar da peça. Sim


Descrição String Descrição da peça. Sim

Valor Float Valor da peça. Sim



Número da Peça String Número tabelar da peça. Sim


Descrição String Descrição da peça. Sim

Valor Float Valor da peça. Sim


Protótipos:

84

Figura24. Layout Pesquisar Peça


Figura26. Alterar Peça

Figura27. Incluir Peça

8.2.12. Manter Oficina

Objetivo:

85


uma oficina dentro do sistema.

Atores:

Administrador e Seguradora

Fluxo principal:

O Caso de Uso inicia-se quando o ator seleciona a opção “Pesquisar Oficina”.


uma oficina


3. Caso selecione a opção “Incluir”, o sistema executa o cenário descrito pelo

subfluxo Incluir;

4. Caso selecione a opção “Pesquisar”, o sistema executa o cenário descrito pelo

subfluxo Pesquisar;

5. O caso de uso Manter Oficina se encerra.

Subfluxos:

Incluir


oficina; Quadro 55

2. O ator insere os dados desejados;



Pesquisar

1. O sistema exibe uma tela com as oficinas cadastradas, de acordo com o argumento

da pesquisa; Quadro 54 [A2]

2. O ator seleciona uma oficina;



Caso o ator opte por excluir uma oficina no sistema, o mesmo terá que alterar o


86


Alterar

1. O sistema exibe uma tela com os dados da oficina selecionada; Quadro 56

2. O ator altera os dados desejados;







todas as oficinas cadastradas no sistema.


Pré-condições:



Atributos:



Nome fantasia String Nome Fantasia da Empresa. Não


Inscrição

Municipal


Tipo String Tipo da empres Não


CNPJ Integer CNPJ da Empresa Não

87







Inscrição

Municipal


















Inscrição

Municipal






88







String Tipo da empresa Não

Protótipos:

Figura28. Layout Pesquisar Oficina


89

Figura30. Layout Alterar Oficina

Figura31. Layout Incluir Oficina

90

CAPÍTULO IX

9. MODELOS DE ANÁLISE

9.1. Caso de uso Efetuar Login

9.1.1. Diagrama de Classe

91

9.1.2. Diagrama de Seqüência

9.2. Caso de uso Cotar Peça


92


9.3. Caso de uso Orçar Cotação


93


9.4. Caso de uso Autorizar Orçamento


94


9.5. Caso de uso Visualizar Cotação Autorizada


95


9.6. Caso de uso Pesquisar Cotação


96


9.7. Caso de uso Visualizar Peça


97


9.8. Caso de uso Configurar Dados Pessoais


98


9.9. Caso de uso Configurar Manter Empresa


99


9.9.2.1. Cenário de Pesquisa

9.9.2.2. Cenário de Inclusão

100

9.9.2.3. Cenário de Exclusão

9.9.2.4. Cenário de Alteração

101

9.10. Caso de uso Configurar Manter Oficina




102




103

9.11. Caso de uso Configurar Manter Peça




104



105


9.12. Caso de uso Configurar Manter Usuário


106




107



108

CAPÍTULO X

10. DOCUMENTAÇÃO DE PROJETO

10.1. Memorial Descritivo das Decisões de Projeto

Com o intuito de facilitar a construção do SISCOT foram utilizados alguns

frameworks. Framework é uma estrutura que dá suporte ao desenvolvimento de software. O

conceito de framework é descrito no item Framework.

10.1.1. Framework

Introdução

Com a evolução da Engenharia de Software, a cada instante tem-se tentado facilitar o

desenvolvimento de sistemas, enfatizando o custo e a qualidade. Um framework é um

facilitador para a construção de sistemas informatizados.

Segundo Larman (2005) um framework7 é um conjunto de objetos extensível para

funções relacionadas e um exemplo típico de framework é o AWT ou o SWING da linguagem

Java. Um framework tem por objetivo a reutilização de códigos, o que é uma característica

importante em toda programação orientada a objeto.

Conceito

Um framework é uma estrutura pronta que oferece algumas implementações que

facilitam o desenvolvimento de softwares. É comparável a uma classe abstrata da linguagem

Java, onde o programador usa apenas as funcionalidades que deseja implementar em sua

aplicação. Ao se utilizar um framework o controle de quando serão invocados determinados

métodos da aplicação será transferido do programador para este.

Classificação

Com relação ao tipo de aplicação ao qual será utilizado, um framework classifica-se

em três tipos básicos:

7 LARMAN, C. Utilizando UML e padrões. 2 ed. Porto Alegre: Bookman, 2004

109

1. System infrastruture frameworks: utilizados no desenvolvimento de sistemas

operacionais e de sistemas de interface com o usuário;

2. Middleware integration frameworks: utilizados para o desenvolvimento de

aplicações distribuídas;

3. Enterprise application frameworks: utilizados em aplicações comerciais, são os

mais conhecidos e utilizados.

Vantagens

As principais vantagens ao se utilizar um framework são:

• O reuso;

• A facilidade de manutenção do sistema construído;

• A capacidade de centralizar o controle de chamada de funcionalidades do sistema;

• A possibilidade de criar classes que podem ser estendidas, economizando um

considerável tempo no desenvolvimento.

10.1.2. Frameworks Escolhidos para o desenvolvimento do SISCOT

Dentre os diferentes frameworks existentes no mercado, para o desenvolvimento do

SISCOT foram escolhidos os seguintes: Hibernate8, Spring9, Struts 210, DWR11,

AcegiSecurity12, SiteMesh13.

8 HIBERNATE, Red Hat Middleware. Disponível em <http://www.hibernate.org>. Acesso em 15 junho 2008. 9 SPRING, Spring Source Community. Disponível em <http://springframework.org>. Acesso em 15 junho 2008. 10 STRUTS, Apache Software Fundation. Disponível em <http://struts.apache.org>. Acesso em 15 junho 2008. 11 DWR, Ajax para uso com a linguagem java. Disponível em <http://getahead.org/dwr/>. Acesso em 15 junho

2008. 12 ACEGISECURITY, Source Forge. Disponível em <http://www.acegisecurity.org/>. Acesso em 15 junho

2008. 13 SITEMESH, Open Symphony. Disponível em <http://www.opensymphony.com/sitemesh/>. Acesso em 15

junho 2008.

110

Hibernate

O Hibernate é um framework de persistência utilizado para o mapeamento objeto-

relacional escrito na linguagem Java.

Sua principal característica é a transformação das classes em Java para tabelas de

dados (e dos tipos de dados Java para os da SQL). O Hibernate gera as chamadas SQL e libera

o desenvolvedor do trabalho manual da conversão dos dados resultante, mantendo o programa

portável para quaisquer bancos de dados SQL, porém causando um pequeno aumento no

tempo de execução.

Spring

O Spring é um framework open source criado por Rod Johnson e descrito em seu livro

“Expert One-on-One: J2EE Design e Development". Ele foi criado para endereçar a

complexidade de desenvolvimento de aplicativos enterprise. O Spring torna possível usar

POJOs para alcançar coisas que previamente só eram possíveis com EJBs. Porém, a utilidade

do Spring não é limitada ao desenvolvimento de server-side. Qualquer aplicativo em Java

pode se beneficiar do Spring em termos de simplicidade, testabilidade e agrupamento.

Struts 2

O Struts 2 é um framework MVC concebido para criar aplicações web prontas para

java enterprise.

DWR

O DWR é uma biblioteca open-source escrita em Java, que permite construir

aplicações web AJAX, ou seja, construir aplicações web mais dinâmicas e interativas.

AcegiSecurity

O framework AcegiSecurity, é um sistema de segurança desenvolvido para o Spring

Framework, no qual, você pode controlar a segurança para métodos de cada objeto ou para

todos os objetos de uma classe, pode controlar acesso para uma URL definida por uma

regexp, ou pode fazer um controle customizado baseado em uma URL + alguns parâmetros

dependendo do que você quiser, e tudo isto de maneira totalmente declarativa.

111

SiteMesh

O SiteMesh é um framework de integração e de layout de página. SiteMesh intercepta

requisições para qualquer página web, se ela for gerada de forma estática ou dinâmica, faz um

parsing no conteúdo e gera a página final. Este processo é baseado no Padrão de Projeto

Decorator.

112

10.2. Diagrama de Arquitetura do SISCOT

113

10.3. Diagrama de Classes do Projeto

10.3.1. Subsistema DAO

114

10.3.2. Principais Entidades e seus relacionamentos

10.3.2.1. Empresa

115

10.3.2.2. Cotação

116

10.3.2.3. Usuário

10.3.3. Subsistema de Autenticação

117

10.3.4. Subsistema Cotação

Como o subsistema Cotação é o um dos mais complexos, ele servirá como exemplo de

como ficará a disposição das classe nos outros subsistemas relacionados com o negócio.

118

10.4. Descrição de Arquivos e Banco de Dados

10.4.1. Modelo Físico

119

CONCLUSÃO

Com o SISCOT, buscou-se contemplar as principais funcionalidades necessárias para

automatizar o processo de cotação de peças para o reparo de automóveis segurados. Através

do SISCOT, foi possível alcançar o objetivo de controle de cotações e a centralização das

informações inerentes, provendo uma maior integração entre Seguradora e Distribuidoras. O

controle efetivo de cotações de peças foi atendido através das suas funcionalidades,

possibilitando a qualquer usuário autorizado obter de informações sobre as cotações de peças

de acordo com seu perfil.

A Seguradora que utilizar o SISCOT perceberá melhorias na parte administrativa, com

o acompanhamento efetivo e preciso das cotações. Terá uma rápida tomada de decisão quanto

à escolha dos produtos cotados, tornando o processo ágil e facilitando a relação com as

Distribuidoras de peças automotivas.

O SISCOT atende todas as necessidades que o mercado anseia, porém é um sistema

passível de evolução. Futuramente o SISCOT poderá contemplar as seguintes

funcionalidades:

• Será possível integrá-lo com as oficinas que possam vir a trabalhar com as

Seguradoras, possibilitando uma maior comunicação entre as partes envolvidas no

processo.

• Será possível o envio de e-mails informando as Distribuidoras quanto à chegada de

nova cotação.

• Será possível que as seguradoras também recebam e-mails relativos aos orçamentos

efetuados.

Nesse projeto, várias ferramentas livres foram utilizadas, evidenciando cada vez mais

a tendência de seu uso, e com isso provando ser possível a construção de sistemas

computacionais de qualidade com o uso de ferramentas não proprietárias.

Para a implementação do SISCOT buscou-se utilizar as mais recentes tecnologias

ligadas à linguagem Java e a Orientação a Objetos, que permitiram reduzir o tempo de

desenvolvimento e adequar o sistema às funcionalidades que o mundo corporativo cada vez

120

mais entende como necessárias. Um ótimo exemplo de tecnologia de grande aceitação e

demanda no mercado é o framework DWR que permite a implementação do AJAX, tornando

a aplicação mais dinâmica.

121

REFERÊNCIAS BIBLIOGRÁFICAS

SUSEP, Superintendência de Seguros Privados. Disponível em <http://www.susep.gov.br>.

Acesso em: 28 maio 2008.

MySQL, Sun Micro Systems. Disponível em <http://www.mysql.com>. Acesso em 10

agosto 2008.

TOMCAT, Apache Software Fundation. Disponível em <http://tomcat.apache.org>. Acesso

em 15 junho 2008.

PRISMATEC, Prismatec LTDA. Disponível em <http://sistema.prismatec.srv.br>. Acesso

em 05 março 2008.

INPART, Inpart Serviços LTDA. Disponível em <http://www.inpart.com.br>. Acesso em 05

março 2008.

PRESSMAN, Roger S. Engenharia de Software. 5 ed. Rio de Janeiro: McGraw-Hill, 2002.

LARMAN, C. Utilizando UML e padrões. 2 ed. Porto Alegre: Bookman, 2004

MOZDEV, br.mozdev.org. Disponível em <http://br.mozdev.org>. Acesso em 30 maio

2008.

HIBERNATE, Red Hat Middleware. Disponível em <http://www.hibernate.org>. Acesso

em 15 junho 2008.

SPRING, Spring Source Community. Disponível em <http://springframework.org>. Acesso

em 15 junho 2008.

STRUTS, Apache Software Fundation. Disponível em <http://struts.apache.org>. Acesso

em 15 junho 2008.

122

DWR, Ajax para uso com a linguagem java. Disponível em <http://getahead.org/dwr/>.

Acesso em 15 junho 2008.

ACEGISECURITY, Source Forge. Disponível em <http://www.acegisecurity.org/>. Acesso

em 15 junho 2008.

JASPERREPORTS, Jasper Forge. Disponível em <http://www.jasperforge.org/jaspersoft/>.


SITEMESH, Open Symphony. Disponível em <http://www.opensymphony.com/sitemesh/>.


sistemas de informação - repositorio.ucb.br · sistemas de informação . ucb - universidade...

Documents