sistema para administração de corretores de

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
ESCOLA DE ENGENHARIA
DEPARTAMENTO DE ENGENHARIA ELETRÔNICA E
DE COMPUTAÇÃO
Projeto Final
Sistema para Administração de Corretoras de Seguros
Desenvolvido com Componentes Multi-Plataforma
Autor:
________________________________________________________
Marcelo Seabra Pinto
Orientador:
________________________________________________________
Antônio Cláudio Gómez de Sousa
Examinador 1: ________________________________________________________
Sérgio Barbosa Villas-Boas
Examinador 2: ________________________________________________________
Sérgio Palma da Justa Medeiro
Rio de Janeiro
2004
DEDICATÓRIA:
Dedico este trabalho ao meu pai, que através do seu exemplo de vida me deu
tanta disposição e vontade de trabalhar, à minha mãe, por toda ajuda prestada durante
meu curso de Engenharia e a meu mestre Antônio Cláudio pela valiosa orientação e total
apoio neste trabalho.
I
AGRADECIMENTOS:
Gostaria de agradecer este trabalho primeiramente a Deus, por nunca ter me
deixado esmorecer diante das dificuldades encontradas durante todo o curso e também
neste projeto.
Agradeço aos meus pais, Elcio Pinto e Edilce Seabra Pinto, que sempre me
apoiaram em todos os momentos do meu curso. Agradeço em particular à minha mãe
pela valiosa ajuda nas questões referentes ao negócio em foco deste trabalho, seguros.
Agradeço também a minha irmã, Daniele Seabra Pinto, que não só me deu forças
para superar as dificuldades da faculdade, como também muito contribuiu nos momentos
de dúvida e decisão em minha vida profissional.
Agradeço a todos os meus amigos de turma que, de uma maneira ou de outra, me
ajudaram a realizar os trabalhos da faculdade e a passar nas provas. Agradeço em
especial a meu amigo Guilherme Oliveira Pinto, por ter me passado importantes
conhecimentos técnicos que muito me ajudaram no desenvolvimento deste projeto e sem
os quais, possivelmente, não o concluiria no prazo estipulado ou não o faria com a
mesma qualidade.
Não poderia deixar de agradecer ao povo brasileiro, que através do pagamento
de seus impostos, financiaram o meu curso superior.
Agradeço ao meu mestre Sérgio Barbosa Villas-Boas, não só pelas tantas dicas e
ajuda com relação a parte técnica deste trabalho, como também pelas valiosas
conversas, que me ajudaram a ampliar minha visão de futuro, emprego e negócios.
Por fim, agradeço ao meu mestre e orientador, Antônio Cláudio, por ter
trabalhado comigo ao longo deste projeto de modo tão produtivo e compreensível.
II
RESUMO
A realização de seguros é um assunto cada vez mais popular no Brasil e no
mundo. A evolução de diferentes modadlidades de seguros têm ocorrido com grande
rapidez e as companhias de seguros vêm ampliando seus lucros de modo espetacular.
Neste ramo extremamente dinâmico e de grande concorrência, o pequeno e médio
corretor de seguros muitas vezes carece de um sistema que aumente a eficiência de seu
trabalho e aumente sua competitividade no mercado. Não há muitos softwares no
mercado que vão de encontro às necessidades das corretoras e ainda sejam de fácil
utilização. Ainda, dentre os existentes, todos funcionam apenas no sistema operacional
Windows.
O projeto foi todo desenvolvido utilizando a liguagem C++. Nos dias de hoje,
onde a competição por empregos é cada vez mais acirrada, devemos cultivar uma
estratégia de desenvolvimento pessoal que nos proporcione um conhecimento útil e
duradouro. Este foi o motivo principal da escolha da linguagem utilizada neste projeto.
Além disso, não podemos nos limitar a produzir tecnologia com soluções proprietárias e
limitadas, daí, a escolha pela biblioteca multiplataforma wxWidgets para o
desenvolvimento da interface gráfica e da biblioteca SQLAPI++, para interfaceamento
com o Banco de Dados.
Assim, este trabalho procura ao mesmo tempo, ser uma referência para aqueles
que desejam aprender mais sobre programação multi-plataforma, sobretudo com a
bibliotecas wxWidget, e uma alternativa para as corretoras de seguros, que poderão
contar com mais esta opção para seu sistema de administração.
PALAVRAS-CHAVE
Banco
de
Dados,
Programação
Multiplataforma,
Manutebilidade,
GUI,
wxWidgets, SQLAPI++, C++.
III
ÍNDICE
DEDICATÓRIA: .......................................................................................................... I
AGRADECIMENTOS:................................................................................................ II
RESUMO.................................................................................................................... III
PALAVRAS-CHAVE ................................................................................................ III
ÍNDICE.......................................................................................................................... 1
1. INTRODUÇÃO ......................................................................................................... 5
1.1. O MERCADO DE SEGUROS ...................................................................................... 5
1.2. UMA OPÇÃO INOVADORA AO MERCADO .................................................... 7
1.3. ESCOPO DO SISTEMA....................................................................................... 8
2. REGRAS DE NEGÓCIO.......................................................................................... 9
3. FUNDAMENTAÇÃO TEÓRICA .......................................................................... 16
3.1. ANÁLISE DO SISTEMA ................................................................................... 16
3.2. ARQUITETURA EM CAMADAS ..................................................................... 16
4. ANÁLISE ESTRUTURADA .................................................................................. 18
4.1. MODELO CONCEITUAL ......................................................................................... 18
4.1.1. Dicionário de dados das entidades do modelo conceitual............................. 19
4.2. DIAGRAMAS DE FLUXO DE DADOS ....................................................................... 27
4.2.1. DFD de contexto ou de nível 0..................................................................... 28
4.2.2. DFD de nível 1 ............................................................................................ 29
4.2.3. DFDs nível 2................................................................................................ 30
4.2.3.1. Gerenciar_Cliente_Corretor .................................................................. 30
4.2.3.2. Gerenciar_Producao.............................................................................. 31
4.2.3.3. Gerenciar_Sinistro ................................................................................ 32
4.2.3.4. Gerenciar_Seguradora........................................................................... 33
1
4.2.3.5. Gerenciar_Usuario ................................................................................ 34
4.2.4. DFDs nível 3................................................................................................ 35
4.2.4.1. Gerenciar_Proposta............................................................................... 35
4.2.4.2. Gerenciar_Comissao ............................................................................. 36
4.2.4.3. Gerenciar_Automovel ........................................................................... 37
4.2.5. Descrição dos fluxos de dados: .................................................................... 38
4.2.6. Descrição dos depósitos: ............................................................................. 40
4.2.7. Descrição dos terminadores: ....................................................................... 40
5. O PROJETO............................................................................................................ 41
5.1. CARACTERÍSTICAS-CHAVE................................................................................... 41
5.1.1. A interface gráfica ....................................................................................... 41
5.1.2. Banco de Dados genérico ............................................................................ 42
5.1.3. Código-fonte comentado e em inglês............................................................ 43
5.2. ARQUITETURA DO SISTEMA ........................................................................ 43
5.3 MODELOS LÓGICO DOS DADOS.................................................................... 44
5.3.1. Descrição das entidades e seus atributos: .................................................... 44
5.3.1.1. Entidade corretor................................................................................... 44
5.3.1.2. Entidade cliente..................................................................................... 45
5.3.1.3. Entidade pes_fisica ............................................................................... 48
5.3.1.4. Entidade pes_jurídica ............................................................................ 50
5.3.1.5. Entidade endereco ................................................................................. 51
5.3.1.6. Entidade seguradora .............................................................................. 54
5.3.1.7. Entidade proposta.................................................................................. 56
5.3.1.8. Entidade apolice.................................................................................... 61
5.3.1.9. Entidade renovacao ............................................................................... 63
5.3.1.10. Entidade endosso................................................................................. 64
5.3.1.11. Entidade custo_fixo............................................................................. 66
5.3.1.12. Entidade cobertura .............................................................................. 67
5.3.1.13. Entidade marca.................................................................................... 69
5.3.1.14. Entidade modelo ................................................................................. 69
5.3.1.15. Entidade cobertura_automovel ............................................................ 71
2
5.3.1.16. Entidade acessorio............................................................................... 75
5.3.1.17. Entidade cobertura_outro .................................................................... 77
5.3.1.18. Entidade parcela_comissao.................................................................. 78
5.3.1.19. Entidade parcela_recebida ................................................................... 79
5.3.1.20. Entidade tipo_sinistro.......................................................................... 81
5.3.1.21. Entidade sinistro.................................................................................. 81
5.3.1.22. Entidade aceitacao............................................................................... 85
5.3.1.23. Entidade recusa ................................................................................... 86
5.4. PANORAMA GERAL DO SISTEMA .......................................................................... 87
5.5. DIAGRAMA MODULAR.................................................................................. 89
5.5.1. Propostas..................................................................................................... 90
5.5.2. Corretores ................................................................................................... 92
5.5.3. Clientes: ...................................................................................................... 93
5.5.4. Seguradoras: ............................................................................................... 94
5.5.5. Automóveis: ................................................................................................. 95
5.5.6. Sinistros....................................................................................................... 96
5.5.7. Comissões.................................................................................................... 97
5.5.8. Relatórios .................................................................................................... 98
5.5.9. Usuários .................................................................................................... 100
5.6. INFORMAÇÕES ADICIONAIS ................................................................................ 101
5.6.1. Demais arquivos envolvidos....................................................................... 101
6. FERRAMENTAS UTILIZADAS NO DESENVOLVIMENTO ......................... 103
6.1. FERRAMENTAS DE HARDWARE E SOFTWARE ...................................................... 103
6.1.1. Ferramentas de Software ........................................................................... 103
6.1.2 Ferramentas de Hardware .......................................................................... 104
6.2. BIBLIOTECAS UTILIZADAS ................................................................................. 105
6.2.1. A wxWidgets .............................................................................................. 105
6.2.2. A SQLAPI++............................................................................................. 108
7. CONCLUSÕES ..................................................................................................... 111
A WXWIDGETS .................................................................................................... 112
3
METODOLOGIA ................................................................................................... 112
APRENDIZADO .................................................................................................... 112
FUTURAMENTE ................................................................................................... 113
8. BIBLIOGRAFIA:.................................................................................................. 115
REFERÊNCIAS ADICIONAIS........................................................................................ 116
APÊDICE: ................................................................................................................. 117
4
1. INTRODUÇÃO
1.1. O MERCADO DE SEGUROS
Seguro é uma atividade que vem crescendo assustadoramente nos últimos anos.
Nos Estados Unidos as pessoas e empresas vêm procurando fazer seguros não só de seus
pertences mais valiosos, como também de fatores críticos para seus negócios. Por
exemplo: um médico cirurgião já pode fazer seguro de suas mãos, meio absolutamente
indispensável para a prática de sua profissão. Outro exemplo seria o seguro para
executivos, que algumas empresas já fornecem como benefício aos seus funcionários
mais bem posicionados, com alto poder de decisão.
No Brasil, o ramo de seguros vem crescendo acentuadamente na última década.
Para se ter uma idéia do tamanho deste mercado, observe o texto divulgado pela
Seguradora J. Malucelli, em sua home-page:
“O mercado de seguros no Brasil é ainda bastante promissor, com tendência a
crescimento nos próximos anos. Atualmente o setor responde por cerca de 3% do PIB
brasileiro, o dobro do registrado no início da década de 90. No mercado da América
Latina, o Brasil é líder em prêmios gerados com mais de 40%, quase quatro vezes mais
que o segundo colocado no ranking, o México.
As principais carteiras comercializadas são Automóveis, Vida e Saúde, sendo que cerca
de 30% do mercado brasileiro de seguros é controlado por empresas estrangeiras.”
Um outro dado interessante é a evolução do número de corretores de seguros
ativos por ano, publicado pela Fundação Nacional dos Corretores de Seguros Privados, de
Capitalização, de Previdência Privada e das Empresas Corretoras de Seguros,
FENACOR. Observe no gráfico abaixo:
5
!!
647
6 7
4
6 7
4
6 7
4
6 7
4
6 7
4
6 7
4
6 7
4
6 7
4
798
798
798
798
798
798
798
798
798
7;::<
7;::=
7;::F
7;::A
7;:::
89@@@
89@@C7
89@@)8
89@@6
/'0 02
, 0
7=>?<@'=
7H:C>?@IA'D
85@>E:<'F
88>G8A'A
856>?F<5:
8DC>EA6'6
85=>?<<'@
85=>E:D'A
88>G8:)6
"$#%'&()
34& A!>B6'@C7
7<>E:'F@
8!7I>EA'@=
85F>EA'F8
647I>?6AC8
7HAC>EA5DD
85<>J757<
85<>J757F
7HAC>E:'@6
'/ 0-/1
8DC>EA@'F
6<>?@<5D
DC8>?F='6
<@>J7H='@
<<>J7LDM7
D6>?=F'F
<47I>?=='<
<8>?@='<
D7I>J7L:)=
/0 02
, 0
7@>[email protected]
77I>?<<5A
7I8>EAD)<
76>E:<'6
7<>J77F
7=>[email protected]
7F>?=I:M7
7F>EAAM7
7HDC>EAF.7
*+-,.# &(
3.& 856A
7I>?6:A
6>G85FF
DC>?=DF
<>ED<)8
<>J7I8<
F>?F@<
AC>J7@C7
F>EA=ID
/0/1
/'0-/5-1
7@>G89=:
7I8>E:'<=
7=>J788
7HAC>?=5@@
85@>?<5=:
8!7I>?685=
85<>?6:=
85<>E:5AC8
88>?F56<
6<>B@5F=
DA!>B@!7@
<A!>KA5A<
=A!>BF5=@
F<>BF!7@
=<>B@5@6
FF>B@5=47
FA!>B@DF
=6>K:'647
Tabela 1: número de corretores de seguros ativos por ano no Brasil – Fonte: FENACOR
Por esta tabela, percebemos como este mercado vem crescendo constantemente
por quase uma década no Brasil.
Outro dado interessante de ser analisado é a participação dos diferentes ramos de
seguros dentro deste mercado. Dados de um estudo da Susep, Superintendência de
Seguros Privados, órgão do Ministério da Fazenda, revelaram que, durante o ano de
2003, o ramo de seguros com maior participação no mercado foi o de pessoas, que
respondeu por 42,95% do total. O ramo de automóvel aparece em segundo lugar em
participação, com 33,90% do mercado no ano. Observa-se que o seguro de automóveis é
um dos mais procurados pela maioria das pessoas, tendo-se em vista que o seguro de vida
e/ou de saúde, é fornecido por muitas empresas a seus funcionários, seja como um
benefício, seja por obrigação. Este ramo, movimentou quase 10,5 bilhões de reais no ano
de 2003.
Como podemos perceber, este mercado está em amplo crescimento no Brasil,
com o surgimento constante de novos tipos de seguros, novas seguradoras, algumas delas
gigantes multinacionais, e novos corretores de seguros. A participação de grandes bancos
neste mercado, alguns com suas próprias companhias de seguros, outros atuando como
corretoras, também vem fomentando bastante o setor.
6
Neste cenário de extrema competitividade, com a presença de gigantes no setor,
como bancos-corretoras, o pequeno e médio corretor de seguros precisa estruturar o seu
negócio muito bem, de modo a permanecer ativo no mercado. Para isso, um sistema que
centralize toda a sua produção é fundamental para sua organização, agilidade no acesso
às informações e extração de relatórios eficientes e úteis, que permitam uma grande
economia de tempo e dinheiro. Além disso, por se tratar de um ramo bastante específico,
com muitas características próprias e extremamente dinâmicas, uma vez que as
seguradoras constantemente modificam algumas de suas regras, fica difícil adotar uma
solução genérica de sistemas de gestão. Isto faz com que seja extremamente aconselhável
aos corretores de seguros que adquiram softwares específicos para corretoras de seguros,
fornecidos atualmente por algumas poucas empresas.
1.2. UMA OPÇÃO INOVADORA AO MERCADO
O mercado de sistemas para corretoras de seguros ainda é pequeno e não há uma
solução que possa ser utilizada em Linux. Uma das idéias deste projeto é implementar um
sistema que possa ser utilizado também no Linux, o que pode trazer uma economia de
licença de software para a corretora.
O sistema, cujo nome neste momento é Seguro Fácil, pretende reunir as principais
necessidades de uma corretora de seguros. Para levantar estas necessidades, foram feitas
entrevistas com dois corretores de seguros, atuantes neste mercado há mais de 15 anos.
Com isto, o sistema representa um modelo bastante fiel à realidade das corretoras de
seguros.
Entretanto, neste ambiente extremamente dinâmico, o sistema pode tornar-se
obsoleto com o tempo. Para sua viabilização comercial, seria interessante um
compromisso de manutenção periódica, fora os casos de bugs. Analisando este fato como
um fator positivo para um software que gere receita com upgrades e tendo em vista suas
características positivas, o produto passa a ser interessante de ser comercializado também
para empresas de software, que simpatizem com a filosofia deste trabalho e acreditem em
potenciais ganhos com o sistema.
7
1.3. ESCOPO DO SISTEMA
O sistema Seguro Fácil visa implementar as seguintes funcionalidades úteis a uma
corretora de seguros:
•
Cadastro de clientes;
•
Cadastro de corretores;
•
Cadastro de seguradoras;
•
Cadastro de propostas;
•
Controle das comissões;
•
Cadastro de sinistros.
Baseado nestes cadastros compomos um banco de dados ricos em informações e
relacionamentos. A partir dele, poderosos relatórios podem ser gerados a fim de trazer
grandes benefícios às corretoras de seguros.
O sistema possui uma interface simples e amigável, uma de suas principais
vantagens para o usuário. Os cadastros foram implementados utilizando o mesmo
princípio. Para cada um deles, implementamos as seguintes funções: incluir, localizar,
editar e excluir, de modo padrão e bastante intuitivo para que o tempo de familiarização
com os sistema seja o menor possível.
8
2. REGRAS DE NEGÓCIO
Abaixo, descrevemos as principais regras de negócio e que foram implementadas
no nosso sistema. O objetivo desta descrição aqui é fazer uma breve explicação das
pricipais características do mercado segurador presentes no Seguro Fácil, a fim de que
seja mais fácil o entendimento dos itens implementados no sistema.
Cliente:
•
O cliente possui um nome completo;
•
Ele pode ser uma pessoa física ou pessoa jurídica;
•
Em caso de pessoa física, o cliente:
o Pode ser do sexo masculino ou feminino;
o Possui um estado civil;
o Possui uma data de nascimento;
o Possui um CPF;
•
Em caso de pessoa jurídica, o cliente:
o Possui um CNPJ;
o Possui o nome da pessoa que está lidando com a corretora;
•
A cada cliente é atribuído um corretor, pessoa da corretora com o qual fechou o
seguro;
•
O cliente possui uma atividade;
9
•
Cada endereço é composto dos campos: nome da rua, número, complemento,
bairro, cidade, estado, CEP;
•
As seguintes informações de contato podem ser preenchidas: e-mail, telefone, fax,
celular;
•
Informações adicionais podem ser informadas em um campo livre para
observações sobre o cliente;
Seguradoras:
•
Dados básicos de uma Seguradora: nome, telefone, fax e nome da pessoa de
contato com a corretora.
•
A seguradora permite que o segurado divida o pagamento do seu seguro em um
certo número de parcelas até o qual ela ainda paga a comissão à corretora em uma
única parcela (pagamento integral).
•
A seguradora possui um número máximo de dias para pagar a comissão à
corretora, após receber o pagamento da parcela do seguro.
•
Este número máximo de dias pode diferir entre os pagamentos de comissão
integrais ou parcelados.
•
O corretor poderá adicionar informações extras sobre a corretora. Um campo livre
de observações é destinado a esse fim.
Proposta:
•
Proposta é um pedido de realização de um seguro que a Corretora faz à
Seguradora;
10
•
A proposta pode ser de 3 tipos: seguro novo, renovação de uma apólice ou
endosso de apólice;
o Apólice:
N
Quando a proposta é aprovada pela seguradora, é emitida uma
apólice para o seguro. O segurado recebe sua apólice diretamente
em casa, pelo correio, e a corretora recebe uma cópia,
normalmente em formato eletrônico pela Internet;
N
A apólice possui uma data de emissão;
o Renovação:
N
Assemelha-se a um seguro novo.
N
Possui um número da apólice a ser renovada e a seguradora
referente à esta apólice;
o Endosso:
N
O endosso é um documento que altera uma proposta de seguro em
N
vigência;
O endosso possui um número, informado pela Seguradora após sua
aprovação. A apólice endossada continua sendo identificada pelo
N
seu número, porém sabe-se que houve alterações por um endosso.
Por estar alterando uma apólice em vigência, a vigência do
endosso vai da data em que a proposta de endosso é aprovada até a
N
data do final da apólice endossada.
Um endosso pode ser dos tipos:
11
•
Sem movimento: caso não haja mudança no valor do
prêmio líquido do seguro em vigência;
•
Cobrança: caso haja um aumento no valor do prêmio
líquido;
•
Restituição: caso haja uma diminuição no valor do prêmio
líquido;
•
A proposta é referente a apenas uma Seguradora;
•
A proposta é relativa a apenas um cliente;
•
Um cliente pode ter várias propostas;
•
A proposta possui um ramo;
•
Ramos são os diversos tipos de seguros: automóvel, residencial, etc. Nesta versão
do sistema, implementamos as coberturas detalhadas apenas para o ramo de
automóveis;
•
A proposta possui uma data de entrada, que é a data em que a proposta foi
entregue à seguradora;
•
A proposta possui uma vigência, que é constituída das datas inicial e final da
validade da apólice do cliente;
•
A proposta possui o número de parcelas que os seguro será pago;
•
Para cada proposta é definido o percentual de comissão que a corretora irá receber
pelo seguro;
•
A proposta possuiu os seguintes valores:
12
o Prêmio líquido: é o valor total do seguro;
o Adicional: custo adicional que se queira acrescentar;
o Custo da apólice: é um custo fixo que a corretora define com um gasto
médio para a realização do seguro;
o IOF: Imposto sobre Operações Financeiras. Percentual cobrado em cima
do prêmio líquido, atualmente em torno de 7,42 %;
o Prêmio Total: é a soma de todos os valores anteriores. É o valor que o
cliente pagará à corretora.
•
A proposta possui uma lista de coberturas associadas a ela, que é diferente para
cada ramo de seguro;
o Seguro de Automóveis: especifica para as coberturas:
N
Itens do automóvel como modelo, placa, chassi, ano de fabricação,
ano do modelo e combustível;
N
Bônus: valor de desconto que o segurado possui em seu seguro;
N
Franquia: valor que o segurado terá que pagar caso utilize o seguro
para perdas parciais no veículo. Pode ser de 3 tipos: normal,
N
reduzida ou majorada;
Importância segurada para responsabilidade civil de danos
materiais de terceiros (IS RCF/DM): é o máximo valor que a
seguradora pagará para os danos materiais de terceiros em caso de
N
sinistro que os envolva;
Importância segurada para responsabilidade civil de danos
corporais de terceiros (IS RCF/DC): é o máximo valor que a
13
seguradora pagará para os danos corporais de terceiros em caso de
sinistro que os envolva.
N
Acessórios: são os vários acessórios do automóvel que podem ser
cobertos opcionalmente. São descritos por um nome e possuem um
valor associado.
o Outros ramos de seguros: não serão implementados detalhadamente nesta
versão, mas poderão ser incluídos por meio de texto livre.
Comissões:
•
As comissões são inerentes a uma dada proposta;
•
As comissões são separadas em parcelas. O número de parcelas de comissão
depende do número de vezes que o cliente quis dividir o pagamento do seguro e
do número máximo de parcelas em que o seguro é dividido para que a seguradora
pague a comissão de uma única vez.
•
Cada parcela possui os seguintes campos:
o Número da parcela: é o índice da parcela na quantidade total de parcelas
existentes para uma proposta;
o Data de vencimento: baseada na data de vencimento da parcela do seguro
do cliente;
o Parcela Líquida: valor da parcela para a Seguradora que o segurado vai
pagar. Não inclui os custos adicionais que o segurado vai pagar, como IOF
e custo da apólice. A comissão da corretora é calculada em cima desta
parcela;
o Comissão Devida: é o valor da comissão previsto para a corretora receber
pela parcela que o cliente irá pagar. É calculada aplicando-se o percentual
14
de comissão especificado na proposta em cima da parcela líquida que o
cliente pagará;
o Data Comissão: data em que a Seguradora pagou a comissão para a
corretora;
o Valor da comissão recebida: É o valor da comissão que a corretora
realmente recebeu, que pode diferir ligeiramente da comissão prevista,
dependendo de fatores diversos.
Sinistros:
•
Uma proposta pode ter zero, um ou mais sinistros;
•
Um sinistro possui um tipo (colisão, roubo, danos elétricos, incêndio, etc);
•
O sinistro possui um número de sinistro, que é fornecido pela seguradora após o
aviso do sinistro;
•
O sinistro possui uma data de ocorrência e uma data de aviso à seguradora;
•
O sinistro possui um valor, que é o valor do orçamento para o reparo do dano
causado pelo sinistro;
•
O sinistro pode estar em 3 situações diferentes: aceito, recusado ou pendente;
o Aceito: a seguradora indenizará o segurado pelo seu sinistro. Neste caso
deve-se informar a data da liquidação e o valor da liquidação;
o Recusado: a seguradora não pagará o sinistro do segurado. Neste caso
deve-se informar o motivo da recusa;
o Pendente: a seguradora ainda não definiu como proceder diante do
sinistro.
15
3. FUNDAMENTAÇÃO TEÓRICA
3.1. ANÁLISE DO SISTEMA
A análise de sistemas tem por objetivo estabelecer os objetivos do projeto, de
forma que usuários e programadores entendam de modo único as características que o
sistema terá. Uma vez feita e entendida a análise, a programação do sistema tende a
atender perfeitamente os requisitos estabelecidos, de modo a se evitar um posterior retrabalho devido a divergências entre o que foi implementado e o que se esperava do
sistema.
Este projeto foi elaborado utilizando-se a análise estruturada de sistemas. Esta
escolha foi feita pela simplicidade que esta técnica oferece para a especificação dos
processos. Através de diagramas, modela-se de maneira fácil de se entender o que o
sistema irá realizar e como os dados serão transformados.
3.2. ARQUITETURA EM CAMADAS
A divisão de um projeto em camadas é uma técnica que traz diversas vantagens
para a construção do sistema. Com ela, isolamos a programação e os problemas de
diferentes partes do sistema. Podemos utilizar produtos de terceiros, como um banco de
dados comercial, de modo a não nos preocuparmos em como lidaremos com os dados,
além de aumentar a qualidade do produto em desenvolvimento. Ainda, a arquitetura em
camadas permite uma melhor divisão do trabalho, conseguindo-se se reunir as diferentes
partes do trabalho de modo fácil.
Neste projeto, foi utilizada a arquitetura em 2 camadas: banco de dados e
aplicação. Entretanto, como veremos no projeto, a camada de aplicação possui algumas
facilidades que permite uma certa divisão do trabalho entre as regras de negócios e a
interface gráfica.
Nesta arquitetura em duas camadas, pode-se hospedar o banco de dados em uma
máquina diferente daquela que roda a aplicação. Isto introduz duas grandes vantagens:
16
•
Divisão do processamento entre dois computadores: pode aumentar o
desempenho do sistema, caso o computador que irá rodar o sistema tenha recursos
limitados. Além disso, a empresa que utilizará o sistema pode já possuir um
computador hospedanado um SGBD1, de modo que apenas será necessário criar
mais uma instância para o novo sistema.
•
Facilidades para rodar o sistema em rede: instalando-se o sistema nos
computadores onde se deseja executá-lo e criando-se um mapeamento de rede
para o computador que hospeda o banco de dados, podemos ter vários programas
rodando simultaneamente, compartilhando a mesma base de dados. Para isto,
entretanto, é aconselhável que o sistema possua algumas proteções para evitar
problemas, como acesso simultâneo aos mesmos registros.
1
Sistema Gerenciador de Banco de Dados
17
4. ANÁLISE ESTRUTURADA
A análise estruturada de sistemas consiste de um conjunto de técnicas e
ferramentas que auxiliam o desenvolvimento de um projeto, capazes de levar usuários,
analistas e projetistas a formarem um quadro claro e geral do sistema e de como suas
partes se encaixam para atender às necessidades daqueles que dele precisam. A
construção de um modelo lógico do sistema, onde seus fundamentos sejam perfeitamente
descritos, é fundamental para o sucesso do projeto. É importante notar que o êxito neste
tipo de atividade não depende apenas da qualidade da implementação envolvida, mas
também do perfeito atendimento às solicitações do cliente.
A análise estruturada utiliza gráficos para a representação das funções (DFDs2),
das informações (DER3) e das dependências de estados (DTE4).
4.1. Modelo conceitual
O modelo conceitual representa as entidades e os relacionamentos do sistema de
forma a se entender melhor as especificações que o sistema pretende atender. Ele
descreve através de blocos que representam as entidades que compõe o sistema e de
como eles se relacionam. O modelo conceitual descrito desta forma é também conhecido
como DER.
2
Diagrama de Fluxo de Dados
Diagrama de Entidades e Relacionamentos
4
Diagrama de Transição de Estados
3
18
Figura 1: DER do Sistema
4.1.1. Dicionário de dados das entidades do modelo conceitual
A seguir descreveremos os atributos que compõe as entidades do modelo
conceitual do sistema.
•
Entidade Corretor:
o Código do corretor
o Nome do corretor
19
•
Entidade Cliente
o Código do cliente
o Nome do cliente
o Corretor que atende ao cliente
o Principal atividade profissional do cliente
o Telefone
o Fax
o Celular
o E-mail
o Observaões
•
Entidade pes_fisica
o Código da pessoa física
o Data de nascimento
o CPF
o Código do estado civil
o Código do sexo
•
Entidade estado_civil
o Código do Estado Civil
o Nome do Estado Civil
•
Entidade sexo
o Código do sexo
o Nome do sexo
•
Entidade pes_jurídica
o Código da pessoa jurídica
o CNPJ
o Nome da pessoa na empresa cliente que lida com com a corretora
20
•
Entidade endereco
o Código do endereço
o Código do cliente referente ao endereço
o Código do CEP
o Número da residência do cliente
o Complemento do endereço
•
Entidade estado
o Código do estado
o Nome do estado
•
Entidade cidade
o Código da cidade
o Código do estado ao qual pertence a ciadade
o Nome da cidade
•
Entidade bairro
o Código do bairro
o Código da cidade ao qual pertence o bairro
o Nome do bairro
•
Entidade rua
o Código da rua
o Código do bairro ao qual pertence a rua
o Nome da rua
•
Entidade cep
o Código do CEP
o Código da rua do CEP
o Código do bairro do CEP
o Código da cidade do CEP
21
o Valor do CEP
•
Entidade seguradora
o Código da seguradora
o Nome da seguradora
o Telefone da seguradora
o Fax da seguradora
o Nome do principal contato na seguradora
o Número máximo de dias que a seguradora leva para emitir a apólice após
a data de entrada da proposta
o Número máximo de parcelas que o cliente pode dividir o pagamento do
seu seguro para que a corretora possa receber a sua comissão de uma única
vez.
o Número máximo de dias que a seguradora demora para pagar a comissão à
corretora após receber o pagamento do cliente.
o Número máximo de dias que a seguradora demora para pagar a parcela de
comissão à corretora após receber o pagamento da parcela cliente.
o Observações
•
Entidade ramo
o Código do ramo de seguro
o Nome do ramo
•
Entidade proposta
o Código da proposta
o Código da seguradora referente à proposta
o Código do cliente referente à proposta
o Código do ramo do seguro
o Número da proposta
o Data de entrada da proposta na seguradora
o Data de início da vigência do seguro
o Data de fim da vigência do seguro
22
o Número de parcelas que o cliente dividirá o pagamento do seguro
o Valor do prêmio líquido, ou seja, o preço que a seguradora cobrará pelo
seguro
o Valor adicional que a corretora queira acrescentar ao seguro
o Valor do custo da apólice
o Valor acrescido pelo IOF, Imposto sobre Operações Financeiras,
obrigatório nese ramo de atividade
o Valor do prêmio total, a soma de todos os valores cobrados ao cliente
o Valor da primeira parcela
o Valor das demais parcelas
o Percentual da comissão da corretora para o seguro
o Observações
•
Entidade apolice
o Código da apólice
o Código da proposta referente à apólice
o Número da apólice
o Data de emissão da apólice
•
Entidade renovacao
o Código da renovação
o Código da proposta referente à renovação
o Código da apólice renovada
•
Entidade tipo_endosso
o Código do tipo de endosso
o Nome do tipo de endosso
•
Entidade endosso
o Código do endosso
o Código da proposta referente ao endosso
o Código da apólice endossada
23
o Código do tipo de endosso
o Número do endosso
•
Entidade custo_fixo
o Código do custo_fixo
o Percentual default definido para o IOF
o Valor default definido para o custo da apólice
•
Entidade cobertura
o Código da cobertura
o Código da proposta referente à cobertura
•
Entidade marca
o Código da marca de automóvel
o Nome da marca de automóvel
•
Entidade modelo
o Código do modelo do automóvel
o Código da marca referente ao modelo
o Nome do modelo
o Capacidade
•
Entidade combustível
o Código do combustível
o Nome do combustível
•
Entidade tipo_franquia
o Código do tipo da franquia
o Nome do tipo da franquia
•
Entidade cobertura_automovel
o Código da cobertura de automóvel
o Código do modelo
24
o Nome do proprietário, que pode não ser o cliente do seguro, em alguns
casos
o Placa
o Chassi
o Código do combustível
o Código do tipo da franquia da cobertura
o Valor da franquia
o Ano de fabricação
o Ano do modelo
o Valor do bônus
o Importância segurada para a carroceria
o Importância segurada para responsabilidade civil de danos materiais de
terceiros
o Importância segurada para responsabilidade civil de danos corporais de
terceiros
•
Entidade acessorio
o Código do acessório segurado à parte
o Código da cobertura do automóvel referente ao acessório segurado
o Nome do acessório
o Valor do acessório
•
Entidade cobertura_outro
o Código da cobertura para outros ramos de seguro
o Descrição das coberturas
•
Entidade parcela_comissao
o Código da parcela
o Código da proposta referente à parcela de comissão
o Número da parcela
o Data de vencimento da parcela, ou seja, a data normal que a seguradora
deve pagar a parcela à corretora
25
o Valor da comissão devida à corretora
•
Entidade parcela_recebida
o Código da parcela recebida
o Código da parcela devida
o Valor da comissão recebida pela corretora
o Data de recebimento da comissão
•
Entidade tipo_sinistro
o Código do tipo do sinistro
o Nome do tipo do sinistro
•
Entidade sinistro
o Código do sinistro
o Código da proposta referente ao sinistro
o Código do tipo do sinistro
o Código da seguradora
o Descrição do evento
o Número do sinistro
o Data da ocorrência
o Data do aviso
o Valor do sinistro
o Observações
•
Entidade aceitacao
o Código da aceitação
o Data da aceitação
o Valor da liquidação
•
Entidade recusa
o Código da recusa
o Descrição do motivo da recusa do pagamento do sinistro
26
•
Entidade tipo_usuario
o Código do tipo de usuário
o Nome do tipo de usuário
•
Entidade usuario
o Código do usuario
o Código do tipo de usuário
o Nome do usuário
o Login
o Senha
4.2. DIAGRAMAS DE FLUXO DE DADOS
Na análise estruturada, o primeiro DFD desenvolvido é o de contexto, que
descreve o sistema como um todo, sem se preocupar com detalhes. A seguir, este é
explodido por várias vezes, até que se chegue aos processos primitivos, que demonstram
uma grande riqueza de detalhes. Ou seja, a análise estruturada possui uma arquitetura
conhecida como top-down, onde partimos dos requisitos básicos para chegar aos detalhes
do sistema. Após este processo, todas as funções do sistema devem estar completamente
entendidas por todas as partes nele envolvidas.
Nos items a seguir apresentamos os DFDs na ordem como foi explicado acima.
Os processos primitivos são representados por círculos não-preendhidos, enquanto os
demais, por círculos preenchidos.
27
4.2.1. DFD de contexto ou de nível 0
Figura 2: DFD de contexto
Os fluxos de dados acima aparecerão novamente em DFDs seguintes e serão
explicados posteriormente, com a descrição dos dados que os compõe.
28
4.2.2. DFD de nível 1
Figura 3: DFD de nível 1
O Processo 6, Configurar_BD, representa um processo primitivo, ou seja, já se
encontra em seu grau máximo de detalhe, não havendo a necessidade de ser explodido
em outros DFDs.
29
4.2.3. DFDs nível 2
Os DFDs a seguir são a primeira explosão dos processos apresentados no DFD de
nível 1.
4.2.3.1. Gerenciar_Cliente_Corretor
Figura 4: DFD de nível 2 explosão do processo Gerenciar_Proposta
30
4.2.3.2. Gerenciar_Producao
Figura 5: DFD de nível 2 explosão do processo Gerenciar_Producao
31
4.2.3.3. Gerenciar_Sinistro
Figura 6: DFD de nível 2 explosão do processo Gerenciar_Sinistro
32
4.2.3.4. Gerenciar_Seguradora
Figura 7: DFD de nível 2 explosão do processo Gerenciar_Seguradora
33
4.2.3.5. Gerenciar_Usuario
Figura 8: DFD de nível 2 explosão do processo Gerenciar_Usuario
34
4.2.4. DFDs nível 3
4.2.4.1. Gerenciar_Proposta
Figura 8: DFD de nível 3 explosão do processo Gerenciar_Proposta
35
4.2.4.2. Gerenciar_Comissao
Figura 9: DFD de nível 3 explosão do processo Gerenciar_Comissao
36
4.2.4.3. Gerenciar_Automovel
Figura 9: DFD de nível 3 explosão do processo Gerenciar_Automovel
37
4.2.5. Descrição dos fluxos de dados:
A seguir descreveremos os fluxos de dados não explicitados nos DFD’s acima:
•
d_cliente: composto de todos os dados relacionados ao cliente, conforme descrito
no modelo conceitual.
•
d_corretor: composto do nome do corretor, único atributo da entidade corretor
nesta versão do Seguro Fácil. Futuramente, podem ser adicionadas outras
informações sobre os corretores.
•
d_proposta: composto de todos os dados relacionados à proposta, conforme
descrito no modelo conceitual.
•
d_comissao: composto das informações das parcelas de comissao devidas e das
parcelas de comissão já recebidas pela corretor, conforme descrito no modelo
conceitual.
•
d_automovel: composto dos dados de marcas e modelos de automóveis descritos
no modelo conceitual.
•
d_modelo: composto dos dados de modelos apenas, conforme descrito no modelo
conceitual.
•
d_sinistro: composto de todos os dados relacionados a sinistros, conforme
descrito no modelo conceitual.
•
d_seguradora: composto de todos os dados relacionados à seguradora, conforme
descrito no modelo conceitual.
•
d_usurario: composto do nome do usuário, seu login e sua senha inicial.
•
d_autenticação: composto do login e a senha do usuário.
38
•
d_nova_senha: composto da nova senha desejada pelo usuário, digitada duas
vezes, para a verificação pelo sistema.
•
lista_cliente: composto de uma lista com o nome de todos os cliente.
•
lista_corretor: composto de uma lista com o nome de todos os corretores
cadastrados.
•
lista_proposta: composto de uma lista de todas as propostas, contendo as
seguintes informações:
o código da proposta
o cliente referente à proposta
o número da proposta
o número da apólice, caso haja
o seguradora referente à proposta
o data de entrada da proposta
•
lista_marcas: composto de uma lista com o nome de todas as marcas cadastradas.
•
lista_modelo: composto de uma lista de todos os modelos, contendo o nome do
modelo e a marca a que pertence
•
lista_sinistro: composto de uma lista de todos os sinistros, contendo as seguintes
informações:
o código do sinistro
o código da proposta referente ao sinistro
o cliente referente ao sinistro
o modelo do carro, se for seguro de automóveis
•
lista_seguradora: composto de uma lista com o nome de todas as seguradoras
cadastradas.
39
4.2.6. Descrição dos depósitos:
Os depósitos de dados dos DFDs correspondem exatamente às entidades
apresentadas no modelo conceitual.
4.2.7. Descrição dos terminadores:
Os terminadores dos DFDs correspondem aos tipos de usuários que o sistema
poderá ter. A descrição dos tipos de usuários e suas potencialidades é a seguinte:
•
Administrador: primeiro usuário a ser criado no sistema, no momento em que ele
é executado pela primeira vez. Possui permissão para criar ou editar outros
usuários, bem como alterar configurações relativas a banco de dados. Também
tem acesso, como leitura, aos registros do sistema.
•
Operador: usuário que tem acesso a modificar os registros do sistema, com
excessão das funções atribuídas ao administrador mencionadas anteriormente.
•
Leitor: usuário que possui apenas o direito de leitura dos dados.
Estas categorias de usuário fazem com que o sistema possua um bom grau de
segurança dos dados, uma vez que só terão acesso a modificar os registros pessoas de
confiança do Administrador. Além disso, para evitar problemas de descuido do usuário
Administrador, ele não possui direito de escrita, o que o obriga a criar uma conta de
operador para si e a trabalhar com ela, caso queira modificar os registros.
Assim, para que o sistema possa ser utilizado plenamente é necessário que se crie,
pelo menos, duas contas de usuários, uma de administrador e outra de operador.
40
5. O PROJETO
5.1. CARACTERÍSTICAS-CHAVE
Apresentamos aqui algumas características de implementação consideradas no
projeto que tornam o sistema interessante do ponto de vista do desenvolvedor. Elas foram
escolhidas levando-se em conta, principalmente a facilidade de manutenção e a
portabilidade do software. Estas características acrescentam ao sistema uma grande
vantagem competitiva, em caso de sua comercialização para uma empresa da área de
software.
5.1.1. A interface gráfica
Para a confecção da interface gráfica, foi utilizado o utilitário wxGlade. Este
utilitário é gratuito e serve para o design das telas gráfica de sistemas desenvolvidos com
a wxWidgets. Com ele, podemos utilizar blocos gráficos para compor nossas interfaces
gráficas em um ambiente bastante amigável. De fato, o desenvolvimento das interfaces
gráficas programando-se diretamente com a wxWidgets é um trabalho difícil e árduo.
Além disso, é muito mais fácil obter um resultado elegante utilizando o ambiente gráfico
da wxGlade do que programando diretamente.
A wxGlade pode gerar o código em 4 formatos (linguagens) distintos: pynton,
perl, C++ ou XRC. Neste projeto, onde optou-se pela utilização da linguagem C++, as
duas últimas opções poderiam ter sido utilizada. Considerando-se as facilidades para
desenvolvimento e manutebilidade do sistema, a opção do XRC, sigla para XML-based
Resource System, foi considerada a mais interessante. Utilizando o XRC, a nossa
interface gráfica é descrita em arquivos-texto em um formato XML que a wxWidgets
saiba como utilizar. A interface gráfica pode estar todo descrita em um único arquivo
XRC ou em vários. Construindo-se diversos arquivos XRC, o design das interfaces se
torna mais fácil, além de introduzir diversas vantagens para a programação. Estes
arquivos são carregados pelo programa em tempo de execução, o que fornece ao sistema
a facilidade de ser aperfeiçoada a interface gráfica após o programa já ter sido compilado.
41
5.1.2. Banco de Dados genérico
A bilbioteca SQLAPI permite a utilização de qualquer banco de dados baseado na
linguagem SQL5 com a mesma facilidade de programação. Assim, a opção por esta
biblioteca garante ao sistema uma maior adaptabilidade a diferentes corretoras, que
podem ter preferência por diferentes bancos de dados.
No entanto, a SQLAPI não traduz a sintaxe SQL de comandos que possam diferir
em suas sintaxes entre os diferentes tipos de Banco de Dados. Por exemplo: a sintaxe
para se criar um atributo que se auto-incremente quando for inserido um novo item no
registro, funcionalidade muito utilizada na implementação dos atributos de identificador
único, difere do MySQL para o MS SQL Server. Neste exemplo:
•
Sintaxe do MySQL: nome_atributo INT AUTO_INCREMENT
•
Sintaxe do SQL Server: nome_atributo INT IDENTITY
Para que o sistema fosse capaz de lidar realmente com qualquer Banco de Dados
baseado em SQL, utilizamos o conceito de late bind, onde são definidos métodos virtuais
genéricos, enquanto os métodos para bancos de dados específicos são implementados
separadamente. A ligação com o método apropriado a ser executado é realizado de
acordo com o banco de dados escolhido para o sistema, no momento da execução do
programa.
Neste projeto, foram desenvolvidos os métodos para o MySQL e o SQL Server.
Porém, com a arquitetura projetada, pode-se implementar os métodos para a utilização de
outros bancos de dados no futuro, como o Oracle. Todos os métodos das classes de banco
de dados foram implementados em um arquivo separado para cada tipo de banco, o que
facilita o trabalho de se acrescentar um novo tipo de banco de dados. Entretanto a
recompilação do projeto será necessária neste caso.
5
Struct Query Language
42
5.1.3. Código-fonte comentado e em inglês
Com o atual mercado globalizado, é interessante notar que não é conveniente a
programação em um idioma de uso restrito a poucos países, como é o caso do português.
Apesar das regras na área de seguros variarem consideravelmente de país para país, não
se pode desprezar a possibilidade de pessoas ou grupos do exterior se interessarem pelo
nosso sistema. Asim, foi utilizado a programação em inglês, com comentários por todo o
código, pensando-se que não apenas o sistema pronto para ser executado é um produto,
mas também o seu código fonte pode ser.
A excessão ficou por conta do modelo do banco de dados, que foi desenvolvido
em português, visando a facilitar a compreensão deste projeto tanto por professores nele
envolvidos quanto por possíveis clientes.
5.2. ARQUITETURA DO SISTEMA
A arquitetura escolhida para o nosso sistema foi de duas camadas (two-tier):
banco de dados e aplicação. Porém, com a utilização da ferramenta XRC para descrição
da interface gráfica, em vez de desenvolver a interface em código C++ a ser compilado,
consideramos que a camada de aplicação está isolada logicamente da apresentação. A
figura abaixo descreve a arquitetura utilizada:
Banco de dados
Camada 1
SQLAPI++
Regras de negócio
XML-based resource system
Camada 2
Interface gráfica descrita
em arquivos XML
Figura 10: camadas envolvidas no projeto
43
Esta divisão lógica se dá porque com o XRC, podemos refazer a interface gráfica,
e gerar um arquivo no formato apropriado. Assim, basta substituir o arquivo .xrc antigo
pelo novo, que o sistema possuirá uma nova aparência. Entretanto, é necessário que a
nova interface possua os campos definidos do mesmo modo que a anterior, pois eles são
utilizados na camada de aplicação. O Anexo B contém a descrição das interfaces, que
deve ser utilizada para a confecção das interfaces.
5.3 MODELOS LÓGICO DOS DADOS
O modelo lógico dos dados foi desenvolvido utilizando-se o software ErWin, da
Computer Associates e encontra-se no Apêndice A, ao final do documento.
5.3.1. Descrição das entidades e seus atributos:
5.3.1.1. Entidade corretor
Finalidade: Consiste nos corretores da corretora ou funcionários quaisquer que também
possam vender seguros na corretora. Eles serão listados ao incluir um cliente para que
seja escolhido um corretor ao qual o cliente está mais ligado, com o qual normalmente
fecha o seguro, o que é uma prática comum neste mercado.
Atributo identificador único:
Código do corretor
•
Definição: código do corretor, identificando-o unicamente. Usado apenas para uso
interno do sistema.
•
Domínio: numérico
•
Abreviatura padrão: id_funcionario
•
Regras de validação: Não há, pois é atribuído automaticamente pelo sistema.
44
Atributos:
Nome do corretor
•
Definição: contém o nome do corretor.
•
Domínio: texto
•
Abreviatura padrão: no_corretor
•
Regras de validação: Qualquer seqüência de caracteres alfabéticos. Verifica-se a
duplicidade ou seja, se já foi cadastrado um corretor com o mesmo nome.
5.3.1.2. Entidade cliente
Finalidade: Consiste nos clientes que a corretora possui ou pode vir a ter no futuro.
Atributo identificador único:
Código do cliente
•
Definição: código do cliente, identificando-o unicamente.
•
Domínio: numérico
•
Abreviatura padrão: id_cliente
•
Regras de validação: Não há, pois é atribuído automaticamente.
Atributos:
Nome do cliente
•
Definição: contém o nome do cliente.
•
Domínio: texto
45
•
Abreviatura padrão: no_cliente
•
Regras de validação: Qualquer seqüência de caracteres alfabéticos. Não pode ser
nulo. Verifica-se a duplicidade.
Corretor
•
Definição: contém o corretor que costuma atender o cliente.
•
Domínio: numérico
•
Abreviatura padrão: id_corretor
•
Regras de validação: Somente um valor válido contido na tabela corretor no
campo id_corretor.
Atividade
•
Definição: contém a atividade profissional do cliente.
•
Domínio: texto
•
Abreviatura padrão: de_atividade
•
Regras de validação: Qualquer seqüência de caracteres.
Telefone
•
Definição: contém o telefone do cliente.
•
Domínio: texto
•
Abreviatura padrão: nu_telefone
•
Regras de validação: Qualquer seqüência de caracteres.
46
Fax
•
Definição: contém o número do fax do cliente
•
Domínio: texto
•
Abreviatura padrão: nu_fax
•
Regras de validação: Qualquer seqüência de caracteres.
Celular
•
Definição: contém o número do celular do cliente
•
Domínio: texto
•
Abreviatura padrão: nu_celular
•
Regras de validação: Qualquer seqüência de caracteres.
E-mail
•
Definição: contém o e-mail do cliente.
•
Domínio: texto
•
Abreviatura padrão: de_email
•
Regras de validação: O e-mail deve estar no formato dentro do padrão utilizado
na Internet.
Observacao
•
Definição: contém observações extras quaisquer sobre o cliente.
47
•
Domínio: texto
•
Abreviatura padrão: de_observação
•
Regras de validação: Qualquer seqüência de caracteres.
5.3.1.3. Entidade pes_fisica
Finalidade: consiste nos clientes que são pessoa física
Atributo identificador único:
Código da pessoa física
•
Definição: código da pessoa física, identificando-a unicamente. É um alias para o
código do cliente, presente na entidade cliente.
•
Domínio: numérico
•
Abreviatura padrão: id_pes_fisica
•
Regras de validação: não há, pois trata-se da replicação do código do cliente para
esta entidade.
Atributos:
Data de nascimento
•
Definição: contém a data de nascimento do cliente
•
Domínio: data
•
Abreviatura padrão: dt_nascimento
48
•
Regras de validação: A data deve estar no formato dd/mm/aaaa. Foi criada uma
função para realizar esta verificação.
CPF
•
Definição: contém o CPF do cliente
•
Domínio: texto
•
Abreviatura padrão: nu_cpf
•
Regras de validação: O CPF deve estar dentro do formato exigido pela legislação
brasileira.
Sexo
•
Definição: contém o sexo do cliente
•
Domínio: numérico
•
Abreviatura padrão: co_sexo
•
Regras de validação: não pode ser nulo em casos de cliente pessoa física.
Estado Civil
•
Definição: contém o estado civil do cliente
•
Domínio: numérico
•
Abreviatura padrão: co_estado_civil
•
Regras de validação: não pode ser nulo em cliente pessoa física.
49
5.3.1.4. Entidade pes_jurídica
Finalidade: consiste nos clientes que são pessoa jurídica
Atributo identificador único:
Código da pessoa jurídica
•
Definição: contém o código da pessoa jurídica. É um alias para o código do
cliente, presente na entidade cliente.
•
Domínio: numérico
•
Abreviatura padrão: id_pes_juridica
•
Regras de validação: não há, pois trata-se da replicação do código do cliente para
esta entidade.
Atributos:
CNPJ
•
Definição: contém o CNPJ da empresa cliente.
•
Domínio: texto
•
Abreviatura padrão: nu_cnpj
•
Regras de validação: qualquer seqüência de caracteres alfa-numéricos
Nome do principal contato
•
Definição: contém o nome da pessoa da empresa cliente que faz contato com a
corretora.
50
•
Domínio: texto
•
Abreviatura padrão: no_principal_contato
•
Regras de validação: qualquer seqüência de caracteres
5.3.1.5. Entidade endereco
Finalidade: consiste no endereço do cliente
Atributo identificador único:
Código do endereço
•
Definição: código do endereço, identificando-o unicamente.
•
Domínio: numérico
•
Abreviatura padrão: id_endereco
•
Regras de validação: Não há, pois é atribuído automaticamente.
Atributos:
Código do cliente
•
Definição: contém o código do cliente que possui o endereço.
•
Domínio: numérico
•
Abreviatura padrão: id_cliente
•
Regras de validação: Somente um valor válido contido na tabela cliente no campo
id_cliente.
51
Nome da rua
•
Definição: contém o nome da rua do endereço do cliente.
•
Domínio: texto
•
Abreviatura padrão: no_rua
•
Regras de validação: Qualquer seqüência de caracteres
Número
•
Definição: contém o número da rua do anunciante
•
Domínio: numérico
•
Abreviatura padrão: nu_numero
•
Regras de validação: somente caracteres numéricos.
Complemento
•
Definição: contém o complemento do endereço do cliente
•
Domínio: texto
•
Abreviatura padrão: de_complemento
•
Regras de validação: Qualquer seqüência de caracteres
Bairro
•
Definição: contém o bairro do endereço do cliente.
•
Domínio: texto
52
•
Abreviatura padrão: no_bairro
•
Regras de validação: Qualquer seqüência de caracteres.
Cidade
•
Definição: contém a cidade do endereço anunciante.
•
Domínio: texto
•
Abreviatura padrão: no_cidade
•
Regras de validação: Qualquer seqüência de caracteres.
Estado
•
Definição: contém o estado do endereço do cliente
•
Domínio: texto
•
Abreviatura padrão: co_estado
•
Regras de validação: Qualquer valor escolhido da lista contendo os estados da
federação.
CEP
•
Definição: contem o cep do endereço do anunciante
•
Domínio: texto
•
Abreviatura padrão: de_cep
•
Regras de validação: Verifica-se se o formato do CEP está dentro do formato
exigido pelos correios.
53
5.3.1.6. Entidade seguradora
Finalidade: consiste nas companhias seguradoras com as quais a corretora trabalha.
Atributo identificador único:
Código da seguradora
•
Definição: código da seguradora, identificando-a unicamente
•
Domínio: numérico
•
Abreviatura padrão: id_seguradora
•
Regras de validação: Não há, pois é atribuído automaticamente pelo sistema.
Atributos:
Nome da seguradora
•
Definição: contém o nome da seguradora.
•
Domínio: texto
•
Abreviatura padrão: no_seguradora
•
Regras de validação: Qualquer seqüência de caracteres.
Número máximo de parcelas para o pagamento integral
•
Definição: contém o número máximo de parcelas que o cliente pode dividir o
pagamento do seu seguro para que a corretora possa receber a sua comissão de
uma única vez. Caso o número de parcelas do seguro seja maior do que este, a
corretora receberá suas comissões com o mesmo número de parcelas que o cliente
dividiu seu pagamento.
54
•
Domínio: numérico
•
Abreviatura padrão: nu_parcelas_para_pgto_integral
•
Regras de validação: Somente caracteres numéricos.
Número de dias para atraso da comisão integral
•
Definição: contém o número máximo de dias que a seguradora pode levar para
liberar a comissão à corretora, a partir da data de vencimento, em caso de
comissão em uma única parcela.
•
Domínio: numérico
•
Abreviatura padrão: nu_dias_atraso_comissao_integral
•
Regras de validação: Somente caracteres numéricos.
Número de dias para atraso da comisão parcelada
•
Definição: contém o número máximo de dias que a seguradora pode levar para
liberar a comissão à corretora, a partir da data de vencimento, em caso de
comissão parcelada
•
Domínio: numérico
•
Abreviatura padrão: nu_dias_atraso_comissao_integral
•
Regras de validação: Somente caracteres numéricos
Observação
•
Definição: contém observações quaisquer sobre a seguradora.
•
Domínio: texto
55
•
Abreviatura padrão: de_observacao
•
Regras de validação: Qualquer seqüência de caracteres.
5.3.1.7. Entidade proposta
Finalidade: consiste nas propostas feitas pela corretora.
Atributo identificador único:
Código da proposta
•
Definição: código da proposta, identificando-a unicamente.
•
Domínio: numérico
•
Abreviatura padrão: id_proposta
•
Regras de validação: Não há, pois é atribuído automaticamente pelo sistema.
Atributos:
Código da seguradora
•
Definição: contém o código da seguradora a que a proposta se refere.
•
Domínio: numérico
•
Abreviatura padrão: id_seguradora
•
Regras de validação: Somente um valor válido contido na tabela seguradora no
campo id_seguradora
Código do cliente
•
Definição: contém o código do cliente da proposta.
56
•
Domínio: numérico
•
Abreviatura padrão: id_cliente
•
Regras de validação: Somente um valor válido contido na tabela cliente no campo
id_cliente
Número da proposta
•
Definição: contém o número da proposta
•
Domínio: numérico
•
Abreviatura padrão: nu_proposta
•
Regras de validação: Somente caracteres numéricos.
Ramo
•
Definição: contém o nome do ramo de seguros da proposta
•
Domínio: texto
•
Abreviatura padrão: no_ramo
•
Regras de validação: Qualquer seqüência de caracteres.
Data de entrada
•
Definição: contém a data que a proposta é cadastrada no sistema.
•
Domínio: data
•
Abreviatura padrão: dt_entrada
57
•
Regras de validação: Função que verifica se a data está no formato dd/mm/aaaa.
Data de início da vigência
•
Definição: contém a data do início da vigência do seguro ao qual a proposta se
refere.
•
Domínio: data
•
Abreviatura padrão: dt_ini_vigencia
•
Regras de validação: Função que verifica se a data está no formato dd/mm/aaaa.
Data de fim da vigência
•
Definição: contém a data do final da vigência do seguro ao qual a proposta se
refere.
•
Domínio: data
•
Abreviatura padrão: dt_fim_vigencia
•
Regras de validação: Função que verifica se a data está no formato dd/mm/aaaa.
Número de parcelas do o pagamento do seguro
•
Definição: contém o número de parcelas que o cliente irá dividir o pagamento do
seu seguro
•
Domínio: numérico
•
Abreviatura padrão: nu_parcelas_pgto_seguro
•
Regras de validação: somente caracteres numéricos
58
Valor do Prêmio Líquido
•
Definição: contém o valor que a seguradora irá cobrar pelo seguro
•
Domínio: numérico
•
Abreviatura padrão: vr_premio_liquido
•
Regras de validação: Função que verifica se o valor está no formato monetário.
Valor adicional
•
Definição: contém um valor adicional que pode ser acrescido pela corretora.
•
Domínio: numérico
•
Abreviatura padrão: vr_adicional
•
Regras de validação: Função que verifica se o valor está no formato monetário.
Valor do custo da apólice
•
Definição: contém um valor que a corretora considera para o custo da apólice.
•
Domínio: numérico
•
Abreviatura padrão: vr_custo_apolice
•
Regras de validação: Função que verifica se o valor está no formato monetário.
Valor do IOF
•
Definição: contém o valor do IOF para aquele seguro.
•
Domínio: numérico
59
•
Abreviatura padrão: vr_iof
•
Regras de validação: Função que verifica se o valor está no formato monetário.
Valor do prêmio total
•
Definição: contém o valor total a ser pago pelo cliente.
•
Domínio: numérico
•
Abreviatura padrão: vr_premio_total
•
Regras de validação: Função que verifica se o valor está no formato monetário.
Valor da primeira parcela
•
Definição: contém o valor da primeira parcela a ser paga pelo cliente.
•
Domínio: numérico
•
Abreviatura padrão: vr_primeira_parcela
•
Regras de validação: Função que verifica se o valor está no formato monetário.
Valor das demais parcelas
•
Definição: contém o valor das demais parcelas a serem pagas pelo cliente.
•
Domínio: numérico
•
Abreviatura padrão: vr_demais_parcelas
•
Regras de validação: Função que verifica se o valor está no formato monetário.
Percentual da comissão
60
•
Definição: contém o percentual que a corretora ganhará pelo seguro.
•
Domínio: numérico
•
Abreviatura padrão: pc_comissao
•
Regras de validação: somente números inteiros ou em ponto flutuante.
Observação
•
Definição: contém observações quaisquer da corretora para a proposta
•
Domínio: texto
•
Abreviatura padrão: id_observação
•
Regras de validação: Qualquer seqüência de caracteres.
5.3.1.8. Entidade apolice
Finalidade: consiste na apolice que é emitida pela seguradora caso ela aprove a proposta
Atributo identificador único:
Código da apólice
•
Definição: código da apólice, identificando-a unicamente.
•
Domínio: numérico
•
Abreviatura padrão: id_apolice
•
Regras de validação: não há, pois é atribuído automaticamente pelo sistema.
61
Atributos:
Código da proposta
•
Definição: contém o código da proposta que deu origem à apólice.
•
Domínio: numérico
•
Abreviatura padrão: id_proposta
•
Regras de validação: Somente um valor válido contido na tabela proposta no
campo id_proposta.
Código da seguradora
•
Definição: contém o código da seguradora que está realizando o seguro.
•
Domínio: numérico
•
Abreviatura padrão: id_seguradora
•
Regras de validação: Somente um valor válido contido na tabela cliente no campo
id_cliente.
Número da apólice
•
Definição: contém o número da apólice, que é fornecido pela seguradora.
•
Domínio: numérico
•
Abreviatura padrão: nu_apolice
•
Regras de validação: somente caracteres numéricos.
62
Data de emissão
•
Definição: contém a data em que a apólice foi emitida.
•
Domínio: data
•
Abreviatura padrão: dt_emissao
•
Regras de validação: Função que verifica se a data está no formato dd/mm/aaaa.
5.3.1.9. Entidade renovacao
Finalidade: consiste em um depósito que permita um controle das apólices renovadas.
Atributo identificador único:
Código da renovação
•
Definição: código da renovação, identificando-a unicamente.
•
Domínio: numérico
•
Abreviatura padrão: id_renovacao
•
Regras de validação: Não há, pois é atribuído automaticamente pelo sistema.
Atributos:
Código da nova proposta
•
Definição: contém o código da proposta que propciará a renovação de uma
apólice.
•
Domínio: numérico
•
Abreviatura padrão: id_nova_proposta
63
•
Regras de validação: Somente um valor válido contido na tabela proposta no
seguradora id_proposta.
Código da seguradora
•
Definição: contém o código da seguradora da proposta em questão.
•
Domínio: numérico
•
Abreviatura padrão: id_seguradora
•
Regras de validação: Somente um valor válido contido na tabela seguradora no
seguradora id_seguradora.
Código da apólice renovada
•
Definição: contém o código da apólice que está sendo renovada.
•
Domínio: numérico
•
Abreviatura padrão: id_apolice_renovada
•
Regras de validação: Somente um valor válido contido na tabela apolice no
campo id_apolice.
5.3.1.10. Entidade endosso
Finalidade: consiste nos endossos de apólice, que são feitos também através de uma
proposta à seguradora.
Atributo identificador único:
Código do endosso
•
Definição: código do endosso, identificando-o unicamente.
64
•
Domínio: numérico
•
Abreviatura padrão: id_endosso
•
Regras de validação: Não há, pois é atribuído automaticamente pelo sistema.
Atributos:
Código da nova proposta
•
Definição: contém o código da proposta que irá endossar uma apólice.
•
Domínio: numérico
•
Abreviatura padrão: id_nova_proposta
•
Regras de validação: Somente um valor válido contido na tabela proposta no
campo id_proposta.
Código da seguradora
•
Definição: contém o código da seguradora da proposta em questão.
•
Domínio: numérico
•
Abreviatura padrão: id_seguradora
•
Regras de validação: Somente um valor válido contido na tabela seguradora no
campo id_seguradora.
Código da apólice endossada
•
Definição: contém o código da apólice que está sendo renovada.
•
Domínio: numérico
65
•
Abreviatura padrão: id_apolice_endossada
•
Regras de validação: Somente um valor válido contido na tabela apolice no
campo id_apolice.
Código do tipo de endosso
•
Definição: contém o código do tipo de endosso, utilizado internamente pelo
sistema.
•
Domínio: numérico
•
Abreviatura padrão: co_tipo_endosso
•
Regras de validação: Não há, pois o valor será escolhido em uma lista prédeterminada pelo sistema.
Número do endosso
•
Definição: contém o número do endosso, fornecido pela seguradora.
•
Domínio: numérico
•
Abreviatura padrão: nu_endosso
•
Regras de validação: Somente valores numéricos.
5.3.1.11. Entidade custo_fixo
Finalidade:
Atributo identificador único:
Código do custo_fixo
66
•
Definição: código dos custos fixos
•
Domínio: numérico
•
Abreviatura padrão: id_custo_fixo
•
Regras de validação: Não há, pois é atribuído automaticamente pelo sistema.
Atributos:
Percentual do IOF
•
Definição: contém o percentual do IOF que a corretora utiliza como padrão para
os seus seguros.
•
Domínio: texto
•
Abreviatura padrão: pc_iof
•
Regras de validação: somente números inteiros ou de ponto flutuante.
Valor do custo da apólice
•
Definição: contém o custo da apólice que a corretora utiliza como padrão para os
seus seguros.
•
Domínio: numérico
•
Abreviatura padrão: vr_apolice
•
Regras de validação: Função que verifica se o valor está no formato monetário.
5.3.1.12. Entidade cobertura
Finalidade: consiste nas coberturas do seguro para uma determinada proposta.
67
Atributo identificador único:
Código da cobertura
•
Definição: código da cobertura, identificando-a unicamente.
•
Domínio: numérico
•
Abreviatura padrão: id_cobertura
•
Regras de validação: Não há, pois é atribuído automaticamente pelo sistema.
Atributos:
Código da proposta
•
Definição: contém o código da proposta a qual a cobertura se refere.
•
Domínio: numérico
•
Abreviatura padrão: id_proposta
•
Regras de validação: Somente um valor válido contido na tabela proposta no
campo id_proposta.
Código da seguradora
•
Definição: contém o código da seguradora à qual a proposta se refere.
•
Domínio: numérico
•
Abreviatura padrão: id_seguradora
•
Regras de validação: Somente um valor válido contido na tabela seguradora no
campo id_seguradora.
68
5.3.1.13. Entidade marca
Finalidade: consiste nas marcas de automóveis com as quais a corretora trabalha.
Atributo identificador único:
Código da marca
•
Definição: código da marca, identificando-a unicamente.
•
Domínio: numérico
•
Abreviatura padrão: id_marca
•
Regras de validação: Não há, pois é atribuído automaticamente pelo sistema.
Atributos:
Nome da marca
•
Definição: contém o nome da marca.
•
Domínio: texto
•
Abreviatura padrão: no_marca
•
Regras de validação: Qualquer seqüência de caracteres
5.3.1.14. Entidade modelo
Finalidade: consiste nos modelos de automóveis com os quais a corretora trabalha.
Atributo identificador único:
Código do modelo
69
•
Definição: código do modelo, identificando-o unicamente.
•
Domínio: numérico
•
Abreviatura padrão: id_modelo
•
Regras de validação: Não há, pois é atribuído automaticamente pelo sistema.
Atributos:
Código da marca
•
Definição: contém o código da marca do modelo.
•
Domínio: numérico
•
Abreviatura padrão: id_marca
•
Regras de validação: Somente um valor válido contido na tabela marca no campo
id_marca.
Nome do modelo
•
Definição: contém o nome do modelo do veículo.
•
Domínio: numérico
•
Abreviatura padrão: no_modelo
•
Regras de validação: Qualquer seqúência de caracteres.
Capacidade
•
Definição: contém o número máximo de passageiros que o veículo comporta.
70
•
Domínio: numérico
•
Abreviatura padrão: qt_capacidade
•
Regras de validação: somente caracteres numéricos.
5.3.1.15. Entidade cobertura_automovel
Finalidade: consiste nas coberturas para seguros do ramo de automóveis.
Atributo identificador único:
Código da cobertura de automóvel
•
Definição: código do automóvel, identificando-o unicamente. É um alias para o
código da cobertura, presente na entidade cobertura.
•
Domínio: numérico
•
Abreviatura padrão: id_cobertura_automovel
•
Regras de validação: não há, pois trata-se da replicação do código da cobertura
para esta entidade.
Atributos:
Código do modelo
•
Definição: contém o código do modelo do automóvel
•
Domínio: numérico
•
Abreviatura padrão: id_mocelo
71
•
Regras de validação: Somente um valor válido contido na tabela modelo no
campo id_modelo.
Nome do proprietário
•
Definição: contém o nome do proprietário do veículo. Em alguns casos, pode não
corresponder ao proponente.
•
Domínio: texto
•
Abreviatura padrão: no_proprietário
•
Regras de validação: Qualquer seqüência de caracteres.
Placa
•
Definição: contém a placa do veículo.
•
Domínio: texto
•
Abreviatura padrão: co_placa
•
Regras de validação: Qualquer seqüência de caracteres.
Chassi
•
Definição: contém o número do chassi do veículo
•
Domínio: numérico
•
Abreviatura padrão: nu_chassi
•
Regras de validação: Somente caracteres numéricos
Combustível
72
•
Definição: contém o código do combustível, que é definido internamente no
sistema.
•
Domínio: numérico
•
Abreviatura padrão: co_combustível
•
Regras de validação: Seleciona-se um valor de uma lista pré-determinada pelo
sistema.
Tipo da franquia
•
Definição: contém o código da franquia, que é definido internamente no sistema.
•
Domínio: numérico
•
Abreviatura padrão: co_tipo_franquia
•
Regras de validação: Seleciona-se um valor de uma lista pré-determinada pelo
sistema.
Valor da franquia
•
Definição: é o valor da franquia do seguro proposto.
•
Domínio: numérico
•
Abreviatura padrão: vr_franquia
•
Regras de validação: Função que verifica se o valor está no formato monetário.
Ano de fabricação
•
Definição: é o ano em que o automóvel foi fabricado
73
•
Domínio: numérico
•
Abreviatura padrão: aa_fabricação
•
Regras de validação: Somente caracteres numéricos
Ano do modelo
•
Definição: é o ano do modelo que o modelo do automóvel foi lançado.
•
Domínio: numérico
•
Abreviatura padrão: aa_modelo
•
Regras de validação: Somente caracteres numéricos.
Bônus
•
Definição: contém o valor do bônus do seguro
•
Domínio: numérico
•
Abreviatura padrão: vr_classe_bonus
•
Regras de validação: seleciona-se um valor de uma lista pré-determinada pelo
sistema.
Importância segurada para a carroceria
•
Definição: contém o valor para a cobertura da carroceria do veículo.
•
Domínio: numérico
•
Abreviatura padrão: vr_is_carroceria
74
•
Regras de validação: Função que verifica se o valor está no formato monetário.
Importância segurada para responsabilidade civil de danos materiais de terceiros
•
Definição: contém o valor para a cobertura de danos materiais causados a
terceiros.
•
Domínio: numérico
•
Abreviatura padrão: vr_is_rcf_dm
•
Regras de validação: Função que verifica se o valor está no formato monetário.
Importância segurada para responsabilidade civil de danos corporais de terceiros
•
Definição: contém o valor para a cobertura de danos corporais causados a
terceiros.
•
Domínio: numérico
•
Abreviatura padrão: vr_is_rcf_dc
•
Regras de validação: Função que verifica se o valor está no formato monetário.
5.3.1.16. Entidade acessorio
Finalidade: consiste nos acessórios a serem incluídas, opcionalmente, no seguro.
Atributo identificador único:
Código do acessório
•
Definição: código do acessório, identificando-o unicamente.
•
Domínio: numérico
75
•
Abreviatura padrão: id_acessório
•
Regras de validação: não há, pois é atribuído automaticamente pelo sistema.
Atributos:
Código da cobertura do automóvel
•
Definição: contém o código da cobertura do automóvel ao qual o acessório
pertence.
•
Domínio: numérico
•
Abreviatura padrão: id_acessorio
•
Regras
de
validação:
Somente
um
valor
válido
contido
na
tabela
cobertura_automóvel no campo id_cobertura_automovel.
Nome do acessório
•
Definição: contém o nome do acessório a ser segurado.
•
Domínio: texto
•
Abreviatura padrão: no_acessorio
•
Regras de validação: Qualquer seqüência de caracteres.
Valor do acessório
•
Definição: contém o valor do acessório a ser segurado.
•
Domínio: numérico
•
Abreviatura padrão: vr_acessorio
76
•
Regras de validação: Função que verifica se o valor está no formato monetário.
5.3.1.17. Entidade cobertura_outro
Finalidade: consiste em uma entidade onde possam ser definidas as coberturas de
seguros de ramos diferentes de automóvel. É um alias para o código da cobertura,
presente na entidade cobertura.
Atributo identificador único:
Código da cobertura para outros ramos
•
Definição: código da cobertura do seguro de ramo diferente de automóvel,
identificando-o unicamente.
•
Domínio: numérico
•
Abreviatura padrão: id_cobertura_outro
•
Regras de validação: não há, pois trata-se da replicação do código da cobertura
para esta entidade.
Atributos:
Descrição da cobertura
•
Definição: contém a descrição das coberturas do seguro.
•
Domínio: texto
•
Abreviatura padrão: de_coberturas
•
Regras de validação: Qualquer seqüência de caracteres.
77
5.3.1.18. Entidade parcela_comissao
Finalidade: consiste nas parcelas de comissão que a corretora irá receber por
determinado seguro.
Atributo identificador único:
Código da parcela
•
Definição: código da parcela de comissão, identificando-a unicamente.
•
Domínio: numérico
•
Abreviatura padrão: id_parcela
•
Regras de validação: não há, pois é atribuído automaticamente pelo sistema.
Atributos:
Código da seguradora
•
Definição: contém o código da seguradora que fez o seguro.
•
Domínio: numérico
•
Abreviatura padrão: id_seguradora
•
Regras de validação: Somente um valor válido contido na tabela seguradora no
campo id_seguradora.
Número da parcela
•
Definição: contém o índice da parcela de comissão, ou seja, um identificador da
parcela dentre as parcelas totais a serem recebidas por determinado seguro.
78
•
Domínio: numérico
•
Abreviatura padrão: nu_parcela
•
Regras de validação: somente caracteres numéricos.
Data de vencimento
•
Definição: contém a data em que a parcela de comissão deverá vencer.
•
Domínio: data
•
Abreviatura padrão: dt_vencimento
•
Regras de validação: Função que verifica se a data está no formato dd/mm/aaaa.
Valor da comissão devida
•
Definição: contém o valor da comissão que deverá ser paga à corretora para a
parcela.
•
Domínio: numérico
•
Abreviatura padrão: vr_comissao_devida
•
Regras de validação: Função que verifica se o valor está no formato monetário.
5.3.1.19. Entidade parcela_recebida
Finalidade: consiste nas parcelas de comissão que foram pagas à corretora.
Atributo identificador único:
Código da parcela recebida
•
Definição: código da parcela recebida, identificando-a unicamente.
79
•
Domínio: numérico
•
Abreviatura padrão: id_parcela_recebida
•
Regras de validação: Não há, pois é atribuído automaticamente pelo sistema.
Atributos:
Código da parcela devida
•
Definição: contém o código da parcela devida.
•
Domínio: numérico
•
Abreviatura padrão: id_parcela_devida
•
Regras
de
validação:
Somente
um
valor
válido
contido
na
tabela
parcelas_comissao no campo id_parcela.
Valor da comissão recebida
•
Definição: contém o valor real recebido pela corretora para determianda parcela.
•
Domínio: numérico
•
Abreviatura padrão: vr_comissao_recebida
•
Regras de validação: Função que verifica se o valor está no formato monetário.
Data de recebimento da comissão
•
Definição: contém a data em que a comissão foi recebida pela corretora.
•
Domínio: data
80
•
Abreviatura padrão: dt_comissao_recebida
•
Regras de validação: Função que verifica se a data está no formato dd/mm/aaaa.
5.3.1.20. Entidade tipo_sinistro
Finalidade: consiste nos tipos de sinistros que podem ocorrer com os seguros que a
corretora trabalha.
Atributo identificador único:
Código do tipo do sinistro
•
Definição: código do tipo do sinistro, identificando-o unicamente.
•
Domínio: numérico
•
Abreviatura padrão: id_tipo_sinistro
•
Regras de validação: Não há, pois é atribuído automaticamente pelo sistema.
Atributos:
Nome do tipo do sinistro
•
Definição: contém o nome do tipo do sinistro.
•
Domínio: texto
•
Abreviatura padrão: no_tipo_sinistro
•
Regras de validação: Qualquer seqüência de caracteres.
5.3.1.21. Entidade sinistro
Finalidade: consiste nos sinistros ocorridos com os segurados da corretora.
81
Atributo identificador único:
Código do sinistro
•
Definição: código do sinistro, identificando-o unicamente.
•
Domínio: numérico
•
Abreviatura padrão: id_sinistro
•
Regras de validação: não há, pois é atribuído automaticamente.
Atributos:
Código da proposta
•
Definição: contém o código da proposta do seguro que sofreu o sinistro.
•
Domínio: numérico
•
Abreviatura padrão: id_proposta
•
Regras de validação: Somente um valor válido contido na tabela proposta no
campo id_proposta.
Código do tipo do sinistro
•
Definição: contém o código do tipo do sinistro.
•
Domínio: numérico
•
Abreviatura padrão: id_tipo_sinistro
•
Regras de validação: Somente um valor válido contido na tabela tipo_sinistro no
campo id_tipo_sinistro.
82
Código da seguradora
•
Definição: contém o código da seguradora que fez o seguro.
•
Domínio: numérico
•
Abreviatura padrão: id_seguradora
•
Regras de validação: Somente um valor válido contido na tabela seguradora no
campo id_seguradora.
Descrição do evento
•
Definição: contém a descrição do evento que levou ao sinistro.
•
Domínio: texto
•
Abreviatura padrão: de_evento
•
Regras de validação: Qualquer seqüência de caracteres.
Número do sinistro
•
Definição: contém o número do sinistro, que é fornecido pela seguradora após
receber o aviso do sinistro.
•
Domínio: numérico
•
Abreviatura padrão: nu_sinistro
•
Regras de validação: Somente caracteres numéricos
Data da ocorrência
•
Definição: contém a data de ocorrência do sinistro
83
•
Domínio: data
•
Abreviatura padrão: dt_ocorrencia
•
Regras de validação: Função que verifica se a data está no formato dd/mm/aaaa.
Data do aviso
•
Definição: contém a data em que o segurado fez o aviso do sinistro para a
seguradora.
•
Domínio: data
•
Abreviatura padrão: dt_aviso
•
Regras de validação: Função que verifica se a data está no formato dd/mm/aaaa.
Valor do sinistro
•
Definição: contém o valor do orçamento para cobrir aquele sinistro.
•
Domínio: numérico
•
Abreviatura padrão: vr_sinistro
•
Regras de validação: Função que verifica se o valor está no formato monetário.
Observação
•
Definição: contém observações quaisquer sobre o sinistro.
•
Domínio: texto
•
Abreviatura padrão: de_observacao
84
•
Regras de validação: Qualquer seqüência de caracteres.
5.3.1.22. Entidade aceitacao
Finalidade: consiste em uma tabela onde são armazenados dados de sinistros que a
seguradora concordou em cobrir. É um alias para o código do sinistro, presente na
entidade sinistro.
Atributo identificador único:
Código da aceitação
•
Definição: código da aceitação do sinistro, identificando-o unicamente.
•
Domínio: numérico
•
Abreviatura padrão: id_aceitacao
•
Regras de validação: não há, pois trata-se da replicação do código do sinistro para
esta entidade.
Atributos:
Data da aceitação
•
Definição: contém a data em que a seguradora aceitou cobrir o sinistro.
•
Domínio: data
•
Abreviatura padrão: dt_aceitacao
•
Regras de validação: Função que verifica se a data está no formato dd/mm/aaaa.
85
Valor da liquidação
•
Definição: contém o valor que a seguradora indenizou o segurado pelo seu
sinistro.
•
Domínio: numérico
•
Abreviatura padrão: vr_liquidacao
•
Regras de validação: Função que verifica se o valor está no formato monetário.
5.3.1.23. Entidade recusa
Finalidade: consiste nos sinistros que foram recusados pela seguradora.
Atributo identificador único:
Código da recusa
•
Definição: código da recusa, identificando-o unicamente. É um alias para o
código do sinistro, presente na entidade sinistro.
•
Domínio: numérico
•
Abreviatura padrão: id_recusa
•
Regras de validação: não há, pois trata-se da replicação do código do sinistro para
esta entidade.
Atributos:
Descrição do motivo
•
Definição: contém a descrição do motivo pelo qual a seguradora se recusou a
indenizar o segurado pelo seu sinistro.
86
•
Domínio: texto
•
Abreviatura padrão: de_motivo
•
Regras de validação: Qualquer seqüência de caracteres.
5.4. PANORAMA GERAL DO SISTEMA
O sistema inicia-se com uma tela para login. Caso o login seja efetuado
corretamente, o usuário tem acesso ao frame do sistema e a realizar operações
compatíveis com a sua categoris.
Figura 11: tela de login do sistema
O frame do sistema possui um título, uma barra de menus e uma barra de status,
onde são exibidas mensagens de ajuda conforme a posição do mouse sobre um item de
menu.
Na barra de menus, encontramos um item para cada um de nossos depósitos de
dados. Para cada um deles, há uma janela, também conhecida como caixa de diálogo, que
87
é exibida ao ser selecionado seu item no menu. A fim de que possamos modificar nossos
depósitos de dados, estas janelas possuem botões com as seguintes funções:
•
Incluir: Habilitado quando a janela é aberta. Ao se acionado, os campos da janela
que podem ou devem ser preenchidos pelo usuário são habilitados. Habilita ainda
os botões Gravar e Desfazer.
•
Localizar: Habilitado quando a janela é aberta. Após a escolha de um item, a
janela é carregada com todas as informações referentes ao item escolhido e os
botões Editar e Excluir são habilitados.
•
Editar: Ao se acionado, os campos da janela que podem ou devem ser preenchidos
pelo usuário são habilitados. Habilita ainda os botões Gravar e Desfazer.
•
Excluir: permite que um registro seja excluído. Em alguns casos, a exclusão pode
não ser permitida ou pode gerar exclusões em outras tabelas, conforme a
implementação de possíveis chaves estrangeiras envolvidas.
•
Gravar: captura os dados da interface gráfica e chama funções que acessam o
banco de dados para que realizem uma inclusão ou edição de dados.
•
Desfazer: retorna a janela para seu estado inicial, ou seja, campos desabilitados e
em branco e apenas os botões Incluir e Localizar acessíveis.
Há algumas poucas janelas que possuem o aspecto diferente deste apresentado,
por serem mais simples ou possuírem características diferentes. Entretanto a
interoperabilidade destas janelas entre o usuário e o sistema sempre segue a seguinte
cadeia: o usuário solicita algo ao sistema, que faz uma operação no banco de dados e
retorna uma resposta ao usuário. A figura seguinte ilustra melhor este ciclo:
88
O usuário faz uma
solicitação ao sistema,
através da janela de diálogo
O sistema captura a solicitação do
usuário, e prepara uma operação
no Banco de Dados
A SQLAPI++ se encarrega de
acessar o banco de dados
O sistema recebe a resposta da
SQLAPI e prepara uma resposta
para o usuário
O banco de dados retorna o
resultado da operação para a
SQLAPI++
O usuário visualiza o resultado
de sua operação pela
Interface gráfica
Figura 12: seqüência de processos internos do sistema
O sistema pode ser dividido em módulos, cada um com a sua janela de diálogo
que é carregada ao ser escolhido o item de menu correspondente. Estes itens são descritos
a seguir.
5.5. DIAGRAMA MODULAR
Frame do Sistema
Propostas
Funcionários
Clientes
Seguradoras
Automóveis
Sinistros
Comissões
Relatórios
Usuários
Figura 13: diagrama modular do projeto
O diagrama da Figura 13 representa a página inicial do sistema e os módulos que
podemos acessar através dela.
Arquivos envolvidos:
•
sigicsFrame.cpp: Analisa se o Seguro Fácil está sendo executado pela primeira
vez. Carrega o frame do sistema, a barra de menu, a barra de status e a caixa de
diálogo para login ou a caixa de diálogo para configuração das informações do
89
banco de dados e criação da conta do administrador, conforme a situação. Possui
também os eventos executados para cada item da barra de menu, que chama o
módulo a ele associado.
•
sigicsFrame.h: contém os includes necessários para o sigicsFrame.cpp e a
descrição da classe de Frame, com seus atributos e métodos.
5.5.1. Propostas
Frame do Sistema
Propostas
Incluir
Funcionários
Localizar
Clientes
Editar
Seguradoras
Excluir
Automóveis
Sinistros
Comissões
Relatórios
Usuários
Definir custos
fixos
Figura 14: Descrição do módulo Propostas
Esta é a parte do sistema que permite a manipulação das propostas de seguro. Este
módulo também faz todo o controle das apólices, renovações e endossos. Quando é
incluída uma nova proposta, o sistema calcula ainda as comissões que a corretora deve
receber (valor e data de vencimento).
Arquivos envolvidos:
•
dlg_proposal.cpp: Carrega a caixa de diálogo para propostas. Possui também sua
tabela de eventos e as funções associadas a cada um deles.
•
dlg_proposal.h: contém os includes necessários para o dlg_proposal.h e a
descrição da classe de proposta, com seus atributos e métodos.
90
•
dlg_cover_automobil.cpp: Carrega a caixa de diálogo para definição da cobertura
de automóveis. Possui também sua tabela de eventos e as funções associadas a
cada um deles.
•
dlg_cover_automobil.h:
contém
os
includes
necessários
para
o
dlg_cover_automobil.h e a descrição da classe de cobertura de automóveis , com
seus atributos e métodos.
•
dlg_cover_others.cpp: Carrega a caixa de diálogo para definição da cobertura de
outros tipos de seguros que não automóveis. Possui também sua tabela de eventos
e as funções associadas a cada um deles.
•
dlg_cover_others.h: contém os includes necessários para o dlg_cover_others.h e a
descrição da classe de cobertura de outros , com seus atributos e métodos.
•
dlg_search_proposal.cpp: Carrega a caixa de diálogo para localização de
propostas. Possui também sua tabela de eventos e as funções associadas a cada
um deles.
•
dlg_search_proposal.h:
contém
os
includes
necessários
para
o
dlg_search_proposal.cpp e a descrição da classe de cobertura de outros , com seus
atributos e métodos.
•
dlg_fixed_costs.cpp: Carrega a caixa de diálogo para definição dos custos fixos.
Possui também sua tabela de eventos e as funções associadas a cada um deles.
•
dlg_fixed_costs.h: contém os includes necessários para o dlg_fixed_costs.h e a
descrição da classe de cobertura de outros , com seus atributos e métodos.
91
5.5.2. Corretores
Frame do Sistema
Propostas
Corretores
Incluir
Clientes
Localizar
Editar
Seguradoras
Automóveis
Sinistros
Comissões
Relatórios
Usuários
Excluir
Figura 15: Descrição do módulo Corretores
Este módulo faz o controle dos funcionários da corretora. Conforme falado
anteriormente, os clientes possuirão um contato principal na corretora, que será um destes
funcionários.
Arquivos envolvidos:
•
dlg_broker.cpp: Carrega a caixa de diálogo para corretores. Possui também sua
tabela de eventos e as funções associadas a cada um deles.
•
dlg_broker.h: contém os includes necessários para o dlg_broker.cpp e a descrição
da classe de Corretores, com seus atributos e métodos.
•
dlg_search_broker.cpp: Carrega a caixa de diálogo para localização de corretores.
Possui também sua tabela de eventos e as funções associadas a cada um deles.
•
dlg_search_broker.h:
contém
os
includes
necessários
para
o
arquivo
dlg_search_broker.cpp e a descrição da classe de cobertura de outros , com seus
atributos e métodos.
92
5.5.3. Clientes:
Frame do Sistema
Propostas
Funcionários
Incluir
Clientes
Seguradoras
Localizar
Editar
Automóveis
Sinistros
Comissões
Relatórios
Usuários
Excluir
Figura 16: Descrição do módulo Clientes
Neste módulo o usuário poderá manter o seu cadastro de clientes. As operações
básicas de cadastro estão disponíveis.
Arquivos envolvidos:
•
dlg_client.cpp: Carrega a caixa de diálogo para clientes. Possui também sua tabela
de eventos e as funções associadas a cada um deles.
•
dlg_client.h: contém os includes necessários para o dlg_client.h e a descrição da
classe de cobertura de outros, com seus atributos e métodos.
•
dlg_search_client.cpp: Carrega a caixa de diálogo para localização de clientes.
Possui também sua tabela de eventos e as funções associadas a cada um deles.
•
dlg_search_client.h: contém os includes necessários para o dlg_search_client.cpp
e a descrição da classe de cobertura de outros , com seus atributos e métodos.
93
5.5.4. Seguradoras:
Frame do Sistema
Propostas
Funcionários
Incluir
Clientes
Seguradoras
Localizar
Editar
Automóveis
Sinistros
Comissões
Relatórios
Usuários
Excluir
Figura 17: Descrição do módulo Seguradoras
Nesta seção são cadastradas as seguradoras.
Arquivos envolvidos:
•
dlg_insuranceCo.cpp: Carrega a caixa de diálogo para seguradoras. Possui
também sua tabela de eventos e as funções associadas a cada um deles.
•
dlg_insuranceCo.h: contém os includes necessários para o dlg_insuranceCo.cpp e
a descrição da classe de Seguradoras, com seus atributos e métodos.
•
dlg_search_insuranceCo.cpp: Carrega a caixa de diálogo para localização de
seguradoras. Possui também sua tabela de eventos e as funções associadas a cada
um deles.
•
dlg_search_insuranceCo.h: contém os includes necessários para o arquivo
dlg_search_insuranceCo.cpp e a descrição da classe de cobertura de outros , com
seus atributos e métodos.
94
5.5.5. Automóveis:
Frame do Sistema
Propostas
Funcionários
Clientes
Seguradoras
Automóveis
Sinistros
Marcas
Incluir
Localizar
Comissões
Relatórios
Usuários
Modelos
Editar
Excluir
Incluir
Localizar
Editar
Excluir
Figura 18: Descrição do módulo Automóveis
Nesta seção o usuário poderá manter atualizado o seu cadastro dos automóveis
com os quais trabalha ou pode vir a trabalhar. O módulo é dividido em duas partes:
marcas e modelos. Conforme visto anteriormente, ao definir uma cobertura de automóvel,
deverá ser escolhido um modelo contido neste cadastro.
Arquivos envolvidos:
•
dlg_brand.cpp: Carrega a caixa de diálogo para marcas de automóveis. Possui
também sua tabela de eventos e as funções associadas a cada um deles.
•
dlg_brand.h: contém os includes necessários para o dlg_brand.cpp e a descrição
da classe de marcas, com seus atributos e métodos.
•
dlg_search_brand.cpp: Carrega a caixa de diálogo para localização de marcas.
Possui também sua tabela de eventos e as funções associadas a cada um deles.
•
dlg_search_brand.h: contém os includes necessários para o dlg_search_brand.cpp
e a descrição da classe de marca, com seus atributos e métodos.
95
•
dlg_model.cpp: Carrega a caixa de diálogo para modelos de automóveis. Possui
também sua tabela de eventos e as funções associadas a cada um deles.
•
dlg_model.h: contém os includes necessários para o dlg_model.cpp e a descrição
da classe de modelos, com seus atributos e métodos.
5.5.6. Sinistros
Frame do Sistema
Propostas
Funcionários
Clientes
Incluir
Seguradoras
Localizar
Automóveis
Editar
Sinistros
Excluir
Comissões
Relatórios
Usuários
Tipos de seguros
Incluir
Excluir
Figura 19: Descrição do módulo Sinistros
Este módulo permite as 4 operações básicas de banco de dados para os sinistros,
além de manter uma tabela de tipos de sinistros que podem ocorrer.
Arquivos envolvidos:
•
dlg_loss.cpp: Carrega a caixa de diálogo para sinistros. Possui também sua tabela
de eventos e as funções associadas a cada um deles.
•
dlg_loss.cpp.h: contém os includes necessários para o dlg_loss.cpp e a descrição
da classe de sinistros, com seus atributos e métodos.
•
dlg_search_loss.cpp: Carrega a caixa de diálogo para localização de sinistros.
Possui também sua tabela de eventos e as funções associadas a cada um deles.
96
•
dlg_search_loss.h: contém os includes necessários para o dlg_search_loss.cpp e a
descrição da classe de sinistros, com seus atributos e métodos.
5.5.7. Comissões
Frame do Sistema
Propostas
Funcionários
Clientes
Seguradoras
Automóveis
Sinistros
Comissões
Relatórios
Usuários
Localizar comissões de
uma proposta
Editar parcelas
de comissão
Totalizar
comissões
Figura 20: Descrição do módulo Comissões
Neste módulo o usuário realiza uma busca pelas parcelas de comissão de uma
determinada proposta de seguro. As parcelas de comissão para um seguro são previstas a
partir dos seguintes dados informados na proposta: prêmio líquido, quantidade de
parcelas que o segurado irá dividir seu pagamento e a seguradora que fará o seguro
(baseado na quantidade máxima de parcelas que a seguradora realiza o pagamento da
comissão em uma única parcela).
Arquivos envolvidos:
•
dlg_comission.cpp: Carrega a caixa de diálogo para comissoes. Possui também
sua tabela de eventos e as funções associadas a cada um deles.
•
dlg_comission.h: contém os includes necessários para o dlg_comission.cpp e a
descrição da classe de Proposta, com seus atributos e métodos.
97
•
dlg_edit_comission.cpp: Carrega a caixa de diálogo para localização de
comissoes. Possui também sua tabela de eventos e as funções associadas a cada
um deles.
•
dlg_edit_comission.h:
contém
os
includes
necessários
para
o
dlg_edit_comission.cpp e a descrição da classe de sinistros, com seus atributos e
métodos.
5.5.8. Relatórios
Este é um dos módulos mais interessantes do Seguro Fácil e que pode realmente
trazer diversas facilidades para o corretor de seguros. Com a base de dados rica em
informações úteis, pode-se criar relatórios de modo a se obter facilmente informações
úteis, cruzar alguns dados, realizar estatísticas, etc. Nesta primeira versão do Seguro Fácil
foram desenvolvidos dois relatórios: seguros a renovar e apólices em atraso.
Frame do Sistema
Propostas
Funcionários
Clientes
Seguradoras
Automóveis
Sinistros
Comissões
Relatórios
Usuários
Define filtro relatório
Visualiza resultado
Figura 21: Descrição do módulo Relatórios
Arquivos envolvidos:
•
dlg_specify_report_renewal.cpp: Carrega a caixa de diálogo com os filtros para o
relatório de renovações. Possui também sua tabela de eventos e as funções
associadas a cada um deles.
98
•
dlg_report_renewal.cpp: Prepara o relatório de renovações de acordo com as
informações recebidas do banco de dados e o exibe em uma nova janela. Possui
também sua tabela de eventos e as funções associadas a cada um deles.
•
dlg_specify_report_late_policy.cpp: Carrega a caixa de diálogo com os filtros
para o relatório de apólices em atraso. Possui também sua tabela de eventos e as
funções associadas a cada um deles.
•
dlg_report_late_policy.cpp: Prepara o relatório de apólices em atraso de acordo
com as informações recebidas do banco de dados e o exibe em uma nova janela.
Possui também sua tabela de eventos e as funções associadas a cada um deles.
•
dlg_specify_report_renewal.h:
contém
os
includes
necessários
para
o
dlg_specify_report_renewal.cpp e a descrição da classe de especificação do
relatório de renovações, com seus atributos e métodos.
•
dlg_report_renewal.h:
contém
os
includes
necessários
para
o
dlg_report_renewal.cpp e a descrição da classe que exibe o relatório de
renovações, com seus atributos e métodos.
•
dlg_specify_report_late_policy.h: contém os includes necessários para o
dlg_specify_report_late_policy.cpp e a descrição da classe de especificação do
relatório de apólices em atraso, com seus atributos e métodos.
•
dlg_report_late_policy.h:
contém
os
includes
necessários
para
o
dlg_report_late_policy.cpp e a descrição da classe que exibe o relatório de
apólices em atraso, com seus atributos e métodos.
99
5.5.9. Usuários
Este é módulo contempla as operações que envolvem os usuários do sistema.
Frame do Sistema
Propostas
Funcionários
Clientes
Seguradoras
Automóveis
Login
Sinistros
Incluir
Comissões
Editar
Relatórios
Excluir
Usuários
Alterar
senha
Figura 22: Descrição do módulo Usuários
Arquivos envolvidos:
•
dlg_login.cpp: Carrega a caixa de diálogo de login. Possui também sua tabela de
eventos e as funções.
•
dlg_add_user.cpp: Carrega a caixa de diálogo para se adicionar um novo usuário,
o que só pode ser feito pelo Administrador. Possui também sua tabela de eventos
e as funções.
•
dlg_edit_user.cpp: Carrega a caixa de diálogo de para se editar e excluir um
usuário, o que também só pode ser feito pelo Administrador. Possui ainda sua
tabela de eventos e as funções.
•
dlg_change_password.cpp: Carrega a caixa de diálogo de para se trocar a senha.
Um usuário somente pode trocar a sua própria senha. Possui também sua tabela de
eventos e as funções.
100
•
dlg_login.h: contém os includes necessários para o dlg_login.cpp e a descrição da
classe de login, com seus atributos e métodos.
•
dlg_add_user.h: contém os includes necessários para o dlg_add_user.cpp e a
descrição da classe de inclusão de usuários, com seus atributos e métodos.
•
dlg_edit_user.h: contém os includes necessários para o dlg_edit_user.cpp e a
descrição da classe de alteração e exclusão de usuários, com seus atributos e
métodos.
•
dlg_change_password.h:
contém
os
includes
necessários
para
o
dlg_change_password.cpp e a descrição da classe de troca de senha, com seus
atributos e métodos.
5.6. INFORMAÇÕES ADICIONAIS
5.6.1. Demais arquivos envolvidos
Além dos arquivos associados a módulos específicos, o projeto possui outros
arquivos, que são utilizados por todos os módulos. Eles possuem funcionalidades
variadas como, por exemplo, funções para acesso ao Banco de Dados, funções globais,
enumeradores, entre outras. Estes arquivos são explicados em detalhe abaixo:
•
main.cpp: implementa a classe MyApp, que é a mãe de todas as outras classes da
wxWidgets no projeto. Possui também algumas funções globais utilizadas no
sistema, como as funções para ordenar por ordem alfabética um vetor or um array
por uma coluna a ser informada.
•
mysql_methods.cpp: contém a implementação de todos os métodos para o banco
de dados MySQL.
•
sqlserver.cpp: contém a implementação de todos os métodos para o banco de
dados SQL Server.
101
•
vblib.cpp: biblioteca criada por Sérgio Barbosa Villas-Boas. Utilização de sua
classe de string, VBString.
•
Seguro_facil.h: contém includes, enumeradores, além das definições das classes
de banco de dados (uso de métodos virtuais).
•
vblib.h: includes e definições utilizadas para a biblioteca vblib.
102
6. FERRAMENTAS UTILIZADAS NO DESENVOLVIMENTO
6.1. FERRAMENTAS DE HARDWARE E SOFTWARE
6.1.1. Ferramentas de Software
Durante o projeto deste sistema de administração para corretoras de seguros as
seguintes ferramentas de softwares foram utilizadas:
•
Microsoft Visual C++ 6.0:
Ambiente de programação em C++, com interface GUI, para o Sistema
Operacional Windows, que traz diversas facilidades para o programador. Compila
e faz link com bibliotecas externas com grande facilidade e gera o código
executável, que pode ser testado a partir dele próprio. Também possui um bom
sistema de debug, que agiliza a detecção dos pontos de problema e sua correção.
Poderia ter sido escolhido qualquer outra ferramenta de programação em C/C++
para Windows.
•
WxGlade 0.3.2:
Trata-se de um utilitário para a construção de telas para o wxWidgets, de interface
GUI. Agiliza em muito o trabalho de construção das interfaces, uma vez que é
todo baseado em blocos gráficos dos objetos da wxWidgets, que devem somente
ser arrastados para a área de construção e customizados, conforme necessidades e
desejos específicos.
É capaz de gerar o código que constituirá as interfaces gráficas em pynton, XRC,
C++ ou perl. Como já foi comentado durante este trabalho, escolhemos o XRC
por trazer grandes facilidades para o projeto.
103
•
ErWin 4.0:
Software utilizado para modelar o Banco de Dados. Possui uma série de
vantagens para o desenvolvimento do DER e dos modelos lógico e físico. É capaz
de gerar o código de criação do Banco de Dados de acordo com parâmetros
escolhidos para tal. Sua utilização, no entanto, limitou-se ao desenvolvimento do
modelo lógico.
•
MySQL 4.0.21:
Sistema Gerenciador de Banco de Dados que roda em diversos sistemas
operacionais, como o Windows e o Linux, principal motivo pelo qual optamos por
sua utilização. É gratuito, disponível para download na Internet, em sua página:
www.mysql.org . Também possui uma boa documentação e grupos de discussão
sobre ele.
Devido às características do sistema, quaisquer outros bancos de dados baseados
em SQL poderiam ter sido utilizados.
•
Microsoft Word:
Software usado para criar a documentação do projeto.
Foi escolhido por ser um editor padrão, com recursos avançados e de fácil
utilização, de modo a se desenvolver esta documentação dentro das normas
exigidas pelo Departamento de Eltrônica e Computação da UFRJ para o Projeto
Final.
6.1.2 Ferramentas de Hardware
O desenvolvimento do Sistema foi feito em mais de um computador, todos sem
nenhuma configuração acima do normal para usuários caseiros. O sistema é simples de
modo a não requerer grandes recursos computacionais. A maior parte do projeto, no
104
entanto, foi desenvolvida em um laptop DELL Latitude D800, cuja configuração
detalhada é mostrada abaixo:
•
Processador Intel Pentium M 1.50 GHz;
•
1.0 GB de memória RAM;
•
55,8 GB de disco rígido.
6.2. BIBLIOTECAS UTILIZADAS
O desenvolvimento do Sistema foi baseado, principalmente na biblioteca
wxWidgets. Uma outra biblioteca que também foi muito importante do projeto foi a
SQLAPI++.
6.2.1. A wxWidgets
A wxWidgets é uma biblioteca gratuita, cujo objetivo é permitir o
desenvolvimento de poderosas interfaces gráficas em C++, que sejam totalmente multiplataforma, ou seja, funcionem em diversas plataformas de hardware e software. Entre os
ambientes que a wxWidgets funciona, conforme sua documentação, encontram-se:
•
Windows
•
Linux
•
Macintosh MAC OS
•
Sun Solaris
A grande portabilidade desta biblioteca foi a principal característica pela sua
escolha neste projeto. Como já foi exposto anteriormente, não existe um software como
este voltado para o mercado de seguros que rode em Linux, o que pode ser utilizado
como grande ponto de vantagem para sua exploração comercial. Além disso, é
105
interessante desenvolver habilidades de programação que não sejam voltados somente
para alguns nichos específicos, como o Microsoft Windows. A arte de programação
genericamente é uma habilidade que garamte ao programador grande versatilidade e
condições de se diferenciar da maioria.
A seguir, descrevemos as principais classes utilizadas no projeto e algumas de
suas características mais interessantes:
•
wxFrame:
Esta classe cria um frame, que é uma janela que pode ser modificada em tamanho
e posição pelo usuário. Normalmente possui uma barra de título e, opcionalmente,
barra de menus, barra de ferramentas e barra de status. Todas estas características,
exceto a barra de ferramentas foram utilizadas em nosso sistema.
•
wxDialog:
Esta classe cria uma caixa de diálogo, que é uma janela com menos
funcionalidades que o frame. Possui uma barra de título e pode ser movida pelo
usuário pela área de trabalho. Pode conter controles e originar outras janelas, o
que foi utilizado em todo o projeto.
•
wxMenuBar:
Classe que cria uma barra de menus no frame do sistema. O frame pode conter
uma barra de menus intrínseca a ele ou separada. Neste projeto, devido às
facilidades do XRC, implementamos a barra de menus separadamente do frame.
•
wxTextCtrl:
Classe que cria uma lacuna na interface gráfica. Possui uma vasta gama de
métodos, que facilitam bastante o trabalho do programador. Para capturar o seu
conteúdo, utiliza-se o método GetStringValue().
106
•
wxRadioBox:
Classe que cria um radio box, ou seja, uma caixa com diversas opções para que
apenas uma seja selecionada. Pode variar de formato (opções na vertica ou na
horizontal) e possuir ou não um título aparente. Para capturar o seu conteúdo,
utiliza-se o método GetStringSelection() ou GetSelection().
•
wxComboBox:
Classe que cria um combo box, ou seja uma lacuna que possui uma seta em seu
lado direito que expande uma lista para que uma linha seja selecionada. Possui a
opção de permitir ou não a edição de sua lacuna pelo usuário. Para capturar o seu
conteúdo, utiliza-se o método GetStringSelection() ou GetSelection().
•
wxButton:
Classe que cria um botão que após ser clicado volta para seu estado inicial. A
wxWidgets possui um outro tipo de botão que armazena o estado, ou seja, quando
clicado, fica na forma “achatada” e somente após ser clicado novamente volta ao
seu estado normal.
•
wxListCtrl:
Classe que cria uma lista, divida em linhas e colunas. Além disso, possui no topo
das colunas um título que pode funcionar como um botão. Pode-se associar um
evento ao clique em cima do título da coluna, e ainda há meios de se descobrir
qual a posição da coluna do título clicado.
Além dos recursos voltados para a interface gráfica, a wxWidgets também possui
diversas classes de uso geral, que foram muito úteis neste projeto. Entre elas, destacamse:
107
•
wxString:
Poderosa classe de string que possui diversos métodos extremamente úteis, que
muito facilitam a programação. Com suas muitas funcionalidades, economizou-se
muito esforço de programação.
•
wxDateTime:
Poderosa classe de data e hora, foi muito importante neste projeto. Possui
métodos diversos para manipulação de data e hora, como comparações e algumas
operações aritméticas.
•
wxStringTokenizer:
Classe que permite capturar substrings de uma string baseado em um token
definido, ou seja, um caracter especial que separe as substrings.
•
wxEvtHandler:
Permite manipular funções associadas a eventos dinamicamente, o que fornece
grande flexibilidade para alguns desenvolvimentos específicos. Um exemplo de
sua utilidade, utilizado neste projeto, é a capacidade de conectar ou desconectar
eventos, pois nem sempre um evento é desejável no programa.
6.2.2. A SQLAPI++
O objetivo desta biblioteca é permitir que o programa em C++ possa acessar
bancos de dados de maneira fácil e transparente. Ela permitiu o isolamento da camada de
regras de negócio da camada de banco de dados.
A SQLAPI++ possui uma versão para Windows e outra para Linux, ambas
utilizadas neste projeto. A versão utilizada neste projeto foi a 3.7.8.
108
Com a SQLAPI++, o banco de dados é acessado através de métodos de fácil
manipulação. Ela conecta em diversos bancos de dados com a mesma facilidade, o que é
uma de suas grandes vantagens: ser independente do banco de dados utilizados.
Entretanto, para realizar consultas ou alterações em tabelas do banco, são utilizados
métodos que executam comandos SQL, que têm que ser descritos explicitamente. Por
este motivo, as peculiaridades diferentes entre os diversos bancos de dados têm que ser
tratadas pelo programador, uma vez que a SQLAPI não traduz sintaxes SQL. Para tornar
o sistema realmente independente do banco de dados, utilizamos o conceito C++ de late
bind e implementamos todas os métodos de acesso ao banco em arquivos especpificos.
Com este esquema, caso se deseje utilizar um novo banco de dados, tudo que é necessário
é escrever os métodos para o novo banco em um arquivo separado, que siga as
especificações para tal, e incluí-lo no projeto.
As principais funções da SQLAPI++ utlizadas no projeto são:
•
void Connect( const SAString &sDBString , const SAString &sUserID , const
SAString &sPassword , SAClient_t eSAClient = SA_Client_NotSpecified );
throw (SAException);
Este método da classe SAConnection estabelece uma conexão com o banco de dados
especificado em sDBString, to tipo eSAClient, utilizando o usuário sUserID e a senha
sPassword.
Ex: m_connection->Connect(“Sigics”, “Administrador”, “ufrj”, SA_Oracle_Client);
•
SACommand ( SAConnection *pConnection , const SAString &sCmd =
SAString(), SACommandType_t eCmdType = SA_CmdUnknown );
O constructor da classe SACommand pode já criar seu objeto, para a conexão
pConnection, associado a um comando definido em sCmd.
Ex: SACommand cmd (m_connection, “SELECT * from CLIENTE”);
109
•
virtual void Execute(); throw (SAException);
Este método da classe SACommand executa o commando corrente associado ao
objeto da classe.
110
7. CONCLUSÕES
Este trabalho descreve com detalhes o Sistema de Administração para Corretoras
de Seguros. As finalidades deste projeto foram, basicamente o desenvolvimento de um
software de interface gráfica que fosse realemente de encontro às necessidades de uma
corretora de seguros e o aperfeiçoamento de técnicas de programação com C++, com
ênfase em utilização de componentes multi-plataformas.
O projeto deste sistema buscou, em todo momento, facilidades para sua futura
manutenção, portabilidade e extensão. Estas necessidades podem surgir, principalmente
devido a:
•
O ramo de seguros ser extremamente dinâmico e podem have mudanças nas
necessidades das corretoras;
•
Características adicionais podem querer ser acrescidas ao modelo de dados como,
por exemplo, descrições detalhadas de seguros de outros ramos, a exemplo do que
foi desenvolvido para automóveis;
•
Implementação do sistema com um novo banco de dados, como, por exemplo, o
Oracle.
A escolha da linguagem C++ proporciona diversas destas facilidades. Outros
fatores que permitem estas características do sistema foi a escolha pela biblioteca
wxWidgets e SQLAPI++.
Pode-se ter uma idéia da complexidade do projeto através dos seguintes números:
•
Tempo de implementação: 6 meses efetivos
•
Aproximadamente 20 mil linhas de código fonte C++.
•
33 arquivos .cpp
•
37 arquivos .h
•
29 arquivos XRC
111
•
Executável com 1,56 MB. Devem ser utilizadas ainda algumas bibliotecas
dinâmicas (dll’s da SQLAPI e da wxWidgets).
A WXWIDGETS
Durante todo este projeto a biblioteca wxWidgets mostrou-se extremamente
confiável, não tendo sido constatado nenhum bug, o que contribuiu para que o projeto
fluísse tranqüilamente. Além disso, ela é extremamente rica, não só em classes
relacionadas a interfaces gráficas, como também em classes de usp genérico, que
facilitam o trabalho do programador que pode reutilizar bastante estes códigos.
Cabe ainda o elogio à forma como a wxWidgets foi concebida, gratuita, com o
código fonte aberto, diversos exemplos excelentes e uma documentação com muita
qualidade também. Tudo isto junto não só acelera o tempo de aprendizado daqueles que
querem começar a trabalhar com ela, mas também contribui para um aperfeiçoamento da
capacidade de programação de seu usuário.
METODOLOGIA
A metodologia utilizada trouxe algumas vantagens para o desenvolvimento deste
projeto. Em primeiro lugar, a análise estruturada descreve com detalhes e de modo
simples todas as funcionalidades do sistema. Com ela, através dos DFDs, torna-se fácil e
definição dos requisitos do software, que foi feita junto a corretores de seguros. Após a
identificação das necessidades das corretoras e da análise feita e conferida, o projeto
caminhou de modo fácil, cumprindo as especificações descritas na análise.
A arquitetura em camadas também foi uma boa escolha, uma vez que facilitou o
desenvolvimento, além de ter trazido grande flexibilidade para a extensão do sistema.
APRENDIZADO
O aprendizado foi, sem dúvida alguma, um dos maiores sucessos até o momento
deste projeto. Este aprendizado se deu em diversos aspectos.
112
Em primeiro lugar, este trabalho proporcionou um grande conhecimento de
negócios. Saber identificar as necessidades de um determinado mercado ou atividade é
um conhecimento valioso, que pode ser aplicado a outros ramos além de seguros. Além
disso, a modelagem de um problema real em um projeto de software é uma característica
importante de um engenheiro que atue ou venha a atuar no desenvolvimento de sistemas.
Isto o diferencia de outros programadores que não tenham esta visão e habilidade.
Com relação ao aprendizado técnico, o projeto trouxe ao autor um grande
aumento da capacidade de programar em C++, tendo feito uso de várias características
poderosas da liguagem. Muitos conhecimentos de bancos de dados, sobretudo do MySQL
e SQL Server também foram adquiridos e podem ser de grande utilidade no futuro.
FUTURAMENTE
Este projeto, apesar de descrever a maioria das necessidades das corretoras de
seguros, poderia conter mais funcionalidades. Entre as principais melhorias sugeridas
para o futuro, encontram-se:
•
Compilação e execução do sistema no ambiente operacional Linux. Apesar de o
sistema ter sido todo desenvolvido com tecnologias multi-plataformas, ele não
chegou a ser testado no Linux. Isto poderá ser feito futuramente sem maiores
problemas.
•
Instalação do sistema com banco de dados embutido (embedded).
•
Criação de rotinas para backup e restauração do sistema. Isto é muito importante
em sistemas vitais como este, onde a perda parcial ou total dos dados acarreta
grandes problemas ou sérios prejuízos para o empresário.
•
Criação de novos relatórios, de modo a trazer ainda mais facilidades para as
corretoras de seguros. A base de dados é rica em informações e, a partir dela,
podem ser extraídos diversos relatórios que podem trazer mais benefícios às
corretoras de seguros. Como exemplos de relatórios extras sugeridos, pode-se
113
citar os relatórios de clientes que não possuem apólices associadas a ele,
totalização das comissões recebidas em um determinado período de tempo, como,
por exemplo, 1 ano. Além disso, pode-se criar relatórios estatísticos como
participação em percentual de cada seguradora nas propostas da corretora.
•
Ampliação da base de dados para descrever detalhadamente as coberturas de
outros ramos de seguro que não de automóveis, além de possíveis correções
encontradas no futuro.
É interessante notar, ainda, as diversas modalidades com que o software pode ser
explorado comercialmente. Uma hipótese é sua venda para uma empresa de software que
se interesse pelo escopo e/ou a filosofia do projeto. Outra hipótese seria comercializá-lo
diretamente com as corretoras de seguros. Esta última possui a desvantagem para o autor
de se comprometer com a manutenção ou correção de possíveis bugs no sistema, o que
pode ser inviável dependendo da dimensão do trabalho e da disponibilidade de tempo do
autor. Uma outra possível negociação seria dar ou vender a preço bastante acessível o
sistema para corretoras de seguros, com a isenção de responsabilidade de sua
manutenção. Neste caso, poderia ser feito um acordo de possíveis melhorias mediante
pagamento de taxas a serem acordadas com a corretora cliente.
114
8. BIBLIOGRAFIA:
As referências bibliográficas utilizadas neste trabalho foram, em sua maior parte,
as documentações das ferramentas de desenvolvimento utlizadas. Referências adicionais
relacionadas a projetos de engenharia de software também foram utilizadas. A lista
completa da bibliografia deste trabalho encontra-se abaixo:
[1] WXWIDGETS 2.4.2 MANUAL. Disponível em <www.wxwidgets.com>.
[2]
WXGLADE
TUTORIAL.
Disponível
em
<http://wxglade.sourceforge.net/tutorial.php>.
[3]
WXGLADE
USER
MANUAL.
Disponível
em
<http://wxglade.sourceforge.net/manual/index.html>.
[4] PRESSMAN, ROGER - Software Engineering: A Practitioner's Approach, 5a Ed.
McGraw Hill, 2001
[5] GANE, CHRIS e SARSON, TRISH, - Análise Estruturada de Sistemas, Livros
Técnicos e Científicos Editora, 1983.
[6] MYSQL REFERENCE MANUAL. Disponível em <www.mysql.com/documentation/>.
Acesso em 15 de agosto de 2004.
[7] VILLAS-BOAS, SERGIO – C/C++ e Orientação a Objetos em Ambientes
Multiplataforma v 5.1. Disponível em <http://lpi.lps.ufrj.br/~villas/pdf/c++v5b.pdf>
[8] ROCHA, RODRIGO P. – ImovNet - Um Sistema de Compra e Venda de Imóveis via
WEB – Projeto Final defendido no Departamento de Eletrônica, Escola de Engenharia,
Universidade Federal do Rio de Janeiro, 2002.
115
REFERÊNCIAS ADICIONAIS
[1] Home-page da seguradora J. Malucelli - http://www.jmalucelliseguradora.com.br/.
[2] Home-page da Federação Nacional de Seguros Privados, de Capitalização, de
Previdência Privada e das Empresas Corretoras de Seguros - http://www.fenacor.com.br/.
[3]
Home-page
da
Superintendência
de
Seguros
Privados,
Susep
-
http://www.susep.gov.br –
116
APÊDICE:
Modelo Lógico dos dados do Sistema Seguro Fácil
117