Sistem Informatic Privind Activitatea Unei Firme de Asigurari

Economie

Sistem Informatic Privind Activitatea Unei Firme de Asigurari

Byadmin ianuarie 1, 2024

Sistem informatic privind activitatea unei firme de asigurări

Introducere

Dacă vorbim despre asigurări, discutăm implicit despre riscuri și pericol, iar în fața pericolelor omul, implicit societatea umană a căutat mereu soluții, mijloace de evitare, de combatere. În esență, o asigurare este un mijloc de protecție împortiva unui risc, a unui potențial, sau mai bine spus, posibil, pericol.

Pe masura dezvoltării societații umane, s-a dezvoltat implicit și nevoia de protecție a membrilor acesteia în fața unor evenimente care le-ar putea aduce prejudicii atât lor, cât și bunurilor deținute. Ideea este ca dintr-un fond care se strânge de la mai mulți să fie sprijiniți (despăgubiți) cu o sumă cațiva dintre aceștia în momentul în care ceva li se întâmplă și au nevoie de ajutor pentru a-și continua viața cât mai aproape de modul în care o făceau înainte să aibă loc accidentul, evenimentul nefericit etc.

Conform DEX asigurarea este un “contract prin care o persoană este obligată să-l despăgubească pe cel asigurat, în schimbul unei sume de bani plătită periodic, în cazul riscului specificat (accident, incendiu etc)”.

De asemenea, mai putem defini asigurarea ca fiind o operație financiară ce rezultă dintr-un contract de asigurare obligatoriu sau nu, depinzând de legislației țării, prin care firma asiguratoare se obligă să despăgubească pe asigurat sau pe o persoana terță, cum este în cazul răspunderilor civile, pentru pierderile suferite în urma unor accidente survenite în cazul unor întâmplări neprevazute, în schimbul unei sume primite periodic de la asigurat.

Asigurarea a apărut odată cu apariția societății umane. Societatea a fost caracterizată de-a lungul timpului de două tipuri de economii, economii de schimb efectuate cu elemente precum schimbul sau banii și economii naturale care dateaza din cele mai vechi timpuri. În cazul unei economii naturale putem vorbi despre asigurare ca o forma de ajutorare între membrii societății, astfel încât dacă casa unei persoane suferea o catastrofa toată comunitatea ajuta la refacerea pagubelor deoarece dacă nu o făceau și pățeau un lucru similar comunitatea nu i-ar mai fi ajutat.

Creșterea semnificativă a Londrei, spre sfârșitul secolului XVII-lea, ca și centru comercial a dus la apariția cererii asigurarii mai ales pentru comerțul maritim. Cu alte cuvinte apariția asigurărilor este stâns legată de nevoia oamenilor de a se ajuta mutual în cazul daunelor care sunt în permanentă creștere, practic este vorba de recepționarea daunelor și procesul de compensare a acestora.

Așa cum este înțeleasă în zilele nostre, asigurarea își are izvorul în anul 1666 când în Londra a avut loc un mare incendiu ce a distrus 13.200 de case. În urma acestei calamități Nicholas Barbon a deschis primul birou pentru asigurarea clădirilor. Apoi la sfarșitul anului 1680 Edward Lloyd a deschis o firmă de asigurare a navelor, iar în zilele noastre firma este liderul pieței de asigurări maritime. În Statele Unite ale Americii prima companie de asigurări pentru incendii s-a înființat în anul 1732.

În România începând cu anul 2005 asigurarea auto RCA a devenit obligatorie și de asemenea începând cu anul 2012 și asigurarea de locuință.

Capitolul 1. Descrierea domeniului economic

1. Activitățile principale într-o firmă de asigurări

Pentru a înțelege mai bine domeniul asigurărilor, trebuie înțelese anumite noțiuni precum asigurator, asigurat, pagubă, broker de asigurare, contract de asigurare, beneficiarul asigurării, contractantul asigurării, riscul asigurat, evaluarea, suma asigurată, norma de asigurare, prima de asigurare sau durata asigurării. Toate aceste noțiuni sunt definite în Anexa 1.

Pentru a se putea încheia un contract de asigurare acesta trebuie să se incadreze în următoarele condiții : producerea daunei pentru care se încheie asigurarea, să fie posibilă, astfel încat, dacă un anumit bun nu este amenințat de niciun fel de risc, asigurarea acestuia nu este necesară, iar evenimentul are caracter întâmplător, acțiunea evenimentului va trebui să fie luată în calculul statistic. Aceste date stau la baza încheierii poliței, deoarece fără acestea asigurătorul nu poate hotărî probabilitatea apariției evenimentului, producerea să nu depindă de voia asiguratului sau beneficiarului asigurării. În cazul în care cel care se asigura sau beneficiarul poliței a contribuit direct sau indirect la apariția obiectului asigurat, in vederea primiri despăgubirii de asigurare, el va pierde toate drepturile conținute polița de asigurare și va suporta sancțiunile legii.

În contractul de asigurare sunt enumerate:

interesul asigurării;

riscul asigurat;

suma asigurată;

prima de asigurare.

Un element important în cadrul contractului de asigurare sunt precizările esențiale referitoare la risc, obligatorii pentru cel care încheie asigurarea. Dacă împrejurările esențiale privind riscul se schimbă în directia executării contractului, asiguratul este obligat să anunțe imediat asigurătorului schimbarea intervenită. Altfel, asiguratorul va să propune asiguratului modificarea corespunzătoare in contractual de asigurare încă înainte de producerea evenimentului asigurat sau să denunțe contractul atunci cand împrejurările noi referitoare la risc se schimbă și nu le-ar fi acceptat dacă acestea ar fi fost cunoscute de la început. În situația în care evenimentul asigurat s-a produs, asiguratorul are dreptul de a reduce suma, în proporția în care prima de asigurare stabilită la inceput este mai mică decât prima corespunzătoare împrejurărilor intervenite în legătură cu riscul sau de a refuza plata acesteia, când contractul nu a fost încheiat conform modificărilor intervenite.

Contractul de asigurare are un caracter bilateral, toatevpărțile care intervin în asigurare se obligă reciproc. Asiguratul își asumă resposabilitatea de a plăti prima de asigurare, iar asiguratorul, să acorde celui care se asigură o despăgubire în cazul asigurării de bunuri sau de răspundere civilă, ori o sumă asigurată dacă este vorba de asigurare de persoane, condiționat de producerea fenomenului sau evenimentului prevăzut în contract.

Contractul de asigurare are caracteristic și faptul că se execută succesiv. Aceasta înseamnă că asigurătorul și asiguratul au dreptul la prestațiile prevăzute în contractul de asigurare până în momentul când acesta își pierde valabilitatea. Cu toate acestea, contractul de asigurare este unic pe toată perioada pentru care el s-a încheiat, atât în ceea ce privește riscul asigurat, cât și obligațiile ce revin părților.

Contractul de asigurare are caracter întâmplator, deoarece prin încheierea lui se urmărește acoperirea consecințelor unui posibil eveniment. Pentru asigurat, prestația poliței de asigurare, concretizată în plata primei de asigurare, are un character incert, deoarece el are dreptul să încaseze despăgubirea numai în măsura în care riscul asigurat se produce în perioada de valabilitate a poliței. În ceea ce-l privește pe asigurător, încasarea primelor de asigurare este sigură, pe când obligația sa de-a achita suma asigurată are un caracter întâmplător, ea intervenind doar în cazul producerii riscului asigurat.

Valoarea de asigurare poate fi mai mică sau cel mult egală cu valoarea bunului respectiv, înregistrată în contabilitate sau stabilită în funcție de prețul de vânzare-cumpărare, practicat pentru acel bun pe piață, în momentul încheierii asigurării. De exemplu, la clădiri și alte construcții aparținând unor agenți economici, valoarea de asigurare cu care acestea sunt cuprinse în asigurare se stabilește pornind de la valoarea de inventar, fără a putea depăși valoarea reală la momentul daunei. La animalele care pot fi asigurate facultativ – aparținând unor persoane fizice – valoarea de asigurare se stabilește în funcție de prețurile ce se practică pe piața locală la data încheierii contractului de asigurare.

Suma asigurată este valoarea de asigurare pentru care asigurătorul își asumă răspunderea în cazul petrecerii evenimentului pentru care s-a încheiat polița. Suma asigurată stă la baza calculării primei de asigurare. Suma asigurată nu poate fi în nici un caz mai mare decât valoarea bunului asigurat, deoarece polița ar fi astfel concepută încât să nu poată fi acordate despăgubiri mai mari decât pierderile suportate de asigurați.

Duma asigurată poate fi modificată, în cazul anumitor categorii de asigurări, în fiecare an, pentru același obiect al asigurării, ea scăzând sau crescând în funcție de diverși factori: uzură – datorită folosinței; uzură morală; ameliorări semnificative – prin reparații și modernizări; evoluția pieței, numărul de amenzi, atenționări primate etc.

Prima de asigurare reprezintă suma de bani dinainte stabilită pe care asiguratul o plătește asigurătorului pentru ca acesta să-și poată constitui fondul de asigurare necesar achitării despăgubirii de asigurare sau a sumei asigurate la producerea riscului asigurat. Din primele de asigurare încasate, asiguratorul își constituie, pe lângă rezervele necesare achitării despăgubirilor sau a sumelor asigurate, și alte rezerve prevăzute prin dispozițiile legale pentru a-și acoperi cheltuielile privind constituirea și administrarea rezervelor de asigurare.

Volumul primelor de asigurare ce se încasează de la asigurați se determină înmulțind suma asigurată cu cota de primă tarifară stabilită pentru fiecare 100 sau 1.000 unități monetare sumă asigurată.

Cota de primă tarifară, care se mai numește și primă brută, este diferențiată ca nivel în funcție de ramura de asigurare, felul bunului asigurat, frecvența și intensitatea producerii riscurilor asigurate și are în structura sa două elemente, respectiv cota de bază, denumită și primă netă, și adaosul sau suplimentul la aceasta. Prima netă este destinată formării fondului necesar achitării despăgubirilor și sumelor asigurate, iar adaosul servește pentru formarea resurselor bănești necesare acoperirii cheltuielilor pentru constituirea și administrarea fondului de asigurare, finanțării unor măsuri de prevenire a pagubelor, constituirii fondului de rezervă și realizării unui anumit beneficiu (profit).

Dauna este suma de bani pe care asigurătorul o datorează asiguratului în vederea acoperirii pagubei produse de riscul asigurat. Despăgubirea poate fi ,, în limita sumei asigurate,, egală sau mai mică decât paguba, în funcție de modelul aplicat la acoperirea pagubei.

La asigurarea de bunuri, se întâlnesc trei principii care se utilizeaza la acoperirea pagubelor, respectiv: principiul răspunderii proporționale; principiul primului risc; principiul răspunderii limitate.

În cazul răspunderii proporționale, despăgubirea de asigurare față de pagubă se stabilește în aceeași proporție în care se află valoarea asigurată, față de valoarea obiectului asigurat. Prin urmare, în cazul acoperirii pagubei conform principiului răspunderii proporționale, mărimea despăgubirii de asigurare este influențată atât de nivelul pagubei, cât și de raportul dintre suma asigurată și valoarea obiectului asigurat. Cu cât mărimea sumei asigurate este mai apropiată de valoarea bunului asigurat, cu atât nivelul despăgubirii de asigurare este mai apropiat de cuantumul pagubei. În cadrul acestui sistem de acoperire, despăgubirea este egală cu paguba numai atunci când suma asigurată este egală cu valoarea bunului asigurat. Despăgubirea de asigurare se stabilește conform acestui principiu în cazul asigurării animalelor și culturilor agricole, al asigurării mărfurilor în transportul internațional etc. Despăgubirea nu va putea depăși valoarea bunului asigurat decât în condiții expres prevăzute în contract.

Principiul primului risc. La acoperirea pagubei după principiul primului risc, despăgubirea este egală cu paguba fără a putea însă depăși mărimea sumei asigurate. Deci, conform acestui principiu, raportul dintre suma asigurată și valoarea bunului nu mai influențează nivelul despăgubirii, aceasta depinzând doar de mărimea pagubei și a sumei asigurate.

Stabilirea despăgubirii pe baza princii asigurat, cu atât nivelul despăgubirii de asigurare este mai apropiat de cuantumul pagubei. În cadrul acestui sistem de acoperire, despăgubirea este egală cu paguba numai atunci când suma asigurată este egală cu valoarea bunului asigurat. Despăgubirea de asigurare se stabilește conform acestui principiu în cazul asigurării animalelor și culturilor agricole, al asigurării mărfurilor în transportul internațional etc. Despăgubirea nu va putea depăși valoarea bunului asigurat decât în condiții expres prevăzute în contract.

Principiul primului risc. La acoperirea pagubei după principiul primului risc, despăgubirea este egală cu paguba fără a putea însă depăși mărimea sumei asigurate. Deci, conform acestui principiu, raportul dintre suma asigurată și valoarea bunului nu mai influențează nivelul despăgubirii, aceasta depinzând doar de mărimea pagubei și a sumei asigurate.

Stabilirea despăgubirii pe baza principiului primului risc este utilizată la acele asigurări de bunuri, la care daunele totale se produc mai greu. Volumul sumei asigurate este considerat ca reprezentând maximum de pagubă așteptată la bunul respectiv. De exemplu, la asigurarea clădirilor și a altor construcții, despăgubirea se stabilește pe baza acestui principiu. De menționat, că în cadrul ambelor principii de acoperire, partea din pagubă care depășește suma asigurată este suportată de asigurat.

Privind cele două sisteme de acoperire a pagubei prin prisma avantajelor pe care le oferă asiguraților, rezultă că principiul primului risc este mai avantajos pentru asigurați decât cel al răspunderii proporționale, deoarece pagubele sunt compensate într-o măsură mai mare. Această compensare, însă, presupune încasarea de la asigurați a unor prime de asigurare cu un nivel procentual mai ridicat.

Partea din valoarea daunei dinainte stabilită care cade în sarcina asiguratului poartă denumirea de franșiză. Ea poate fi de două feluri: atinsă (simplă) și deductibilă (absolută). În cazul franșizei atinse, asigurătorul acoperă în întregime paguba – până la nivelul sumei asigurate – dacă aceasta este mai mare decât franșiza. Franșiza deductibilă se scade în toate cazurile din pagubă, indiferent cât este volumul acesteia din urmă. Cu alte cuvinte, în cazul franșizei deductibile despăgubirea se acordă numai pentru partea de pagubă care depășește franșiza. Nici în cazul franșizei atinse și nici al celei deductibile, nu se acordă despăgubiri pentru pagubele care se încadrează în limitele franșizei.

Apariția reasigurării ca fenomen și reasigurătorilor ca societăți specializate de asigurare reunite în vederea desdăunării colective în fața unui risc a apărut odată cu cataclismele asigurate, cu daunele de mari proporții, în fața cărora evenimente de genul din 11 septembrie 2001 sau valurile tsunami au dovedit că altfel nici nu se mai poate.

Definită strict în spiritul legii, „reasigurarea este operațiunea de asigurare a unui asigurător de către alt asigurător, primul fiind asigurat, iar cel de al doilea reasigurător”. [21]

Tratatele de asigurări extind definiția: „reasigurarea constituie un mijloc de egalizare, prin divizare, a răspunderilor între mai mulți asigurători, dispersați pe arii geografice cât mai întinse, de menținere a unui echilibru rezonabil între primele încasate și despăgubirile datorate la fiecare asigurător în parte”[22]. Despre reasigurări se poate scrie mult, pentru că până la urmă este vorba de o daună pe care trebuie să o acopere cel puțin doi asigurători, în care cel mai abil se așează cât mai bine la adăpost.

Reasigurarea are și ea regulile ei, de regulă deosebit de severe,intrucât este de dorit ca încă de la incheierea contractului de reasigurare totul sa fie clar negociat, pentru a se evita eventualele conflicte ce pot apărea la desdăunare.

1. Prezentarea activității ce va fi informatizată

Activitatea ce va fi informatizată va cuprinde câteva puncte principale necesare unei firme de asigurări cum ar fi configurarea anumitor produse, gestionarea polițelor și a daunelor, iar în cazul daunelor se vor implementa anumite subprocese specifice.

Configurarea produselor va fi realizată de un utilizator specializat astfel încât la introducerea de polițe să se introducă date corecte și specifice pentru fiecare produs. Configurarea cuprinde de asemenea și limba în care îi este afișată aplicația sau mesajele de eroare.

Gestionarea polițelor cuprinde în general :

– introducerea datelor specifice fiecărui tip de poliță (client, obiect asigurat, acoperiri, riscuri etc.),

– calcularea automată a primei de asigurare bazată pe anumite formule depinzând de produs,

– conversia aplicației în poliță (deoarece un client poate cere doar o estimare de preț fără a încheia polița).

Daunele trebuie înregistrate doar dacă există o poliță în sistem pentru clientul care a solicitat dauna. Dacă polița există atunci datele care se vor capta trebuie să corespundă cu cele din poliță, ceea ce face ca sistemul să fie strâns legat. Subprocesele specifice daunelor care se vor implementa sunt cele de daună totală și antifraudă.

În cazul daunelor totale există un subproces care privește produsele ce asigură autoturismele prin care se face licitație pentru epavă sau compania de asigurări oferă clientului o anumită sumă de bani în schimbul acesteia.

Antifrauda este destinată daunelor care par a fi în neregulă, în sensul că par a fi realizate cu bună știință sau clienții care au raportat dauna figurează pe lista neagră, adică au mai fost depistați că au încercat să fraudeze compania de asigurări. Acestă analiză este una internă despre care clientul nu este informat și care urmează un flux pe care aplicația îl va administra.

Există peste 80 de companii care realizează aplicații software pentru companiile de asigurări în toate colțurile lumii.

Aplicația Insly de la compania cu același nume este o aplicație dezvoltată începând cu anii 2000 și asigură o interfață intuitivă pentru utilizator, personalizare simplă, mediu de stocare în cloud, raportare integrată, sistem de contabilitate și facturare, sistem de management al documentelor, al datoriilor din partea clienților având capacitatea de a trimite e-mail-uri clienților, și nu în ultimul rând sistem pentru managementul polițelor de asigurare și al daunelor. Aplicația are interfață web.

Figură – Exemplu de poliță de asigurare (Insly) (sursa : [23])

Clienți importanți ai acestei companii și implicit care folosesc aplicația sunt IIZI, Aon, Gjensidige, LHV bank, KindlustusEst, Danske Bank, Strategic Insurance Services.

Figură – Sistemul de raportare al aplicației (Insly) (sursa : [23])

Mutual Expert de la firma ECCA are o vechime de 30 de ani în domeniul asigurărilor și are sistem de reasigurare, management de polițe și daune, sistem de contabilitate și facturare, sistem de management al documentelor, dar nu și pentru aplicații de viață sau sănătate. Aplicația este de asememea web.

Figură – Sistem de raportare (Mutual Expert) (sursa [24])

Jenesis Software are trei modalități de accesare și anume instalată, în cloud sau web și o vechime de 13 ani. Ca parteneri de afaceri are companii de asigurare ca DairyLand Auto, Greenville Casualty, Discovery Insurance Company, Insurance House, Universal Insurance Company, Victoria Insurance, Nation Safe Drivers.

1app – C2MS Insurance Software de la Buckhill are toate funcționalitățile necesare unei aplicații de asigurări : sistem de contabilitate și facturare, sistem de management al documentelor, sistem pentru managementul polițelor de asigurare și al daunelor, sistem de reasigurare etc. Aplicația este web-based.

INSIS realizată de Fadata din anul 1990. Are peste 30 de clienți cum ar fi Generali, Omniasig, Asirom, Unicredit, Groupama, Ardaf, Adnic. Are mai multe versiuni de aplicație atât instalate, cât și web-based. Pentru aplicațiile instalate este folosit Oracle Forms, iar pentru cele web-based este folosit Oracle Application Development Framework – Oracle ADF. Fadata este partener de platină al Oracle și de asemenea oferă și suport pentru aplicații Oracle.

Are toate funcționalitățile pe care un sistem pentru asigurări ar trebui să le dețină : sistem pentru managementul polițelor de asigurare și al daunelor, sistem de contabilitate și facturare, sistem de management al documentelor, sistem de management al tuturor tipurilor de persoane care pot apărea în sistem adică agenți, clienți persoane fizice sau juridice, angajați etc., sistem de raportare, de reasigurare etc.

Figură – Rapoarte despre agenti(INSIS) (sursa : http://www.fadata.eu/feature/agents-commission/)

Alte aplicații de asigurare existente pe piață :

InsuranceFaces a companiei Target Harlosh

PolicyBox a companiei Aplifi

Transactor a companiei Transactor Global Solutions

INSolve Policy Administration a companiei INSolve

Capitolul 2. Tehnologii informatice utilizate

2.1 Oracle Database Express Edition 11g Release 2

Oracle Database (denumit în mod obișnuit ca Oracle RDBMS sau pur și simplu ca Oracle) este un sistem de management de baze de date relaționale produs și comercializat de Oracle Corporation.

O bază de date reprezintă o colecție de date organizată și omogenă folosită de mai mulți utilizatori. De-a lungul timpului au fost încercări spre realizarea mai multor tipuri de baze de date printre care cele ierarhice, relaționale sau orientate obiect, însă cele mai utilizate au rămas bazele de date relaționale. Acestea utilizează modelul de date relațional fiind bazat pe logica matematică și teoria mulțimilor și astfel putând reprezenta orice structură de date complexă din orice domeniu de activitate.

Bazele de date Oracle sunt produse și comercializate de compania Oracle care încă din anul 1978 a realizat prima versiune de baze de date numite SDL (Storage Data Language). Astăzi compania a ajuns la versiunea a treisprezecea, Oracle Database 11g, și continuă să cerceteze și să adauge noi facilități pentru clienții săi, iar pe 25 iunie 2013 a apărut cea mai nouă versiune a programului Oracle Database 12C.[14]

Oracle Database 11g asigură utilizarea hardware-ului la maxim astfel încât atunci când ceva s-a defectat sau necesită reparații celelalte componente sunt protejate de Real Application Cluster, astfel încât datele să poată fi accesate. Este construit pe baza codului aplicației Enterprise Edition asigurând aceleași funcționalități ca și aceasta, necesitând doar anumite modificări în funcție de cerințele fiecărei firme. Include Oracle Application Express, un mediu unic de dezvoltare on-line, care permite dezvoltatorilor să construiască rapid aplicații de baze de date folosind nimic mai mult decat un navigator Web. De asemenea, oferă Oracle SQL Developer, un instrument gratuit pentru dezvoltarea bazei de date, care permite utilizatorilor să caute obiecte în baza de date, să execute instrucțiunile SQL și scripturi PL/SQL și să editeze și depaneze cod PL / SQL. Oracle Database 11g Standard Edition este, de asemenea, strâns integrat cu Visual Studio prin intermediul Oracle Data Access Components, care permite dezvoltatorilor să construiască cu ușurință de aplicații bazate pe Oracle NET. și servicii web.[15]

2.2 Oracle JDeveloper 11g

JDeveloper este un produs software furnizat de compania Oracle și face parte din pachetul Oracle Developer Suite. Caracteristicile principale ale acestui produs sunt:

este destinat dezvoltatorilor de aplicații cu baze de date care posedă cunoștiințe de programare, lucru cu platforma Java sau cu sistemele de baze de date

descrie un mediu de dezvoltare intergrat care cu ajutorul tehnologiei Java permite conceperea unei aplicații cu baze de date

asigură un ciclu complet de viață al dezvoltării acesteia începând cu editarea aplicației și până la depanare

include capacități de modelare Unified Modelling Language ca limbaj de modelare conceptuală

oferă suport pentru lucrul în echipă cu ajutorul nucleului Oracle Application Server

organizează fizic aplicațiile utilizeazând spațiile de lucru și proiectele, independent de oraganizarea logică

include o fereastra de tip Navigator

oferă posibilitate de asistare a proiectului cu ajutorul asistentului tip Wizard

are definit un set de convenții

are implementată noțiunea de conexiune pusă în comun pentru toți utilizatorii

este optimizat pentru arhitectura multilevel

Fiind un mediu de lucru complet programul JDeveloper oferă un set de facilități permițând proiectantului să dezvolte o aplicație cu baze de date Oracle folosind limbajul Java.

Una dintre facilitățile oferite este faptul că are integrat mediul de dezvoltare Java care permite adăugarea oricărei noi funcționalități în proiectul în curs, asigură o interfață interactivă cu dezvoltatorul și folosește o tehnologie extensivă care permite sincronizarea codului și proiectării în timpul realizării aplicației.

Prin mecanismele interne (Innovation Profiles) JDeveloper îmbunătățește calitatea codului Java, scoțând în evidență eventualele erori. Prin mecanismul Code Coach programul ajută la îmbunătățirea codului printr-o analiză de performanță a acestuia.

Se pot realiza documente XML cu ajutorul tehnologiei implementate Extended Markup Language de tipul B2C (Business-to-Consumer) și B2B (Business-to-Business).

De asemenea în acest instrument există o fereastră în care se pot executa comenzi SQL și edita subprograme PL/SQL direct pe baza de date incluzând un translator și un depanator integrat.

Cu ajutorul produselor Class Modeler și Activity Modeler bazate pe UML JDeveloper oferă suport pentru analiza sistemului existent. Class Modeller permite generarea codului pentru clasele Java garantând că schimbarile efectuate sunt actualizate. Pentru aplicațiile de e-Business din Intranet și Internet Activity Modeler este folosit pentru administrarea fluxurilor acestor aplicații.

Produsele Java integrate în platforma de baze de date Oracle este următoarea :

Servlets care reprezintă clase Java portabile care asigură răspunsuri la solicitările protocolului HTTP și generează automat cod HTML

JSP (Java Server Pages) care asigură suport pentru proiectarea bazată pe componente

JDBC (Java DataBase Conectivity) realizează conexiunea cu baza de date

EJB (Enterprise Java Beans) încapsulează logica aplicației

EB (Entity Beans) menține datele în baza de date

JavaBeans încapsulează mai multe clase într-un singur obiect

BC4J (Business Components four Java) este o componenta a Jdeveloper care ajută la construirea de baze de date multi tier (aplicație în care aplicația, prezentarea aplicației și managementul datelor sunt în module separate)

J2EE (Java two Enterprise Edition) platformă ce oferă lucrul cu intefețe grafice (API Application Programming Interface)

SQLJ (SQL Java) [10]

Am ales instrumentul Jdeveloper pentru a realiza aplicația deoarece are toate facilitățile necesare construirii acesteia, nefiind necasară instralarea mai multor astfel de instrumente.

2.3 Limbajul de programare Java

În anul 1995 James Gosling a conceput limbajul orientat-obiect și de nivel înalt numit Java în cadrul companiei Sun Microsystems care acum este filială a companiei Oracle. Limbajul are un model al obiectelor mai simplu, dar împrumută o mare parte din sintaxa C/C++. Are un nivel de portabilitate foarte mare ceea ce la celelalte limbaje nu există, adică poate fi rulat fără nici o modificare pe oricare platformă care are o mașină virtuală Java instalată deoarece sursele scrise în acest limbaj sunt compilate într-un sistem standard numit byte-code intermediar între codul mașină și codul sursă.[16]

Limbajul Java are următoarele caracteristici principale :

simplitate, eliminând supraîncarcarea operatorilor sau moștenirea multiplă

robustețe adică elimină sursele frecvente de erori ce apar în programare prin eliminarea pointerilor, administrând automat memoria și eliminând fisurile de memorie printr-o procedura de colectare a „gunoiului”(Garbage Collector) care rulează în fundal

complet orientat pe obiect ceea ce înseamnă că lucrează numai cu clase de obiecte predefinite și definite de utilizator, având definite implicit foarte multe clase

securitate fiind cel mai sigur limbaj de programare disponibil în acest moment

portabilitate adică nu depinde de o anumită platformă pentru a fi executat cu succes, ci poate fi mutat de pe un sistem de operare pe altul de pe un calculator pe altul

asigura o performanta ridicata a codului de octeti

permite programarea cu fire de executie (multitheaded)

Programele Java sunt interpretate adică instrucțiunile sunt citite de interpretor linie cu linie și traduse în limbaj de asamblare și compilate adică codul sursă este transformat intr-un cod ce poate fi executat direct de procesor.[17]

Fiind un limbaj de nivel înalt, Java a folosit la dezvoltarea multor tehnologii dedicate soluționării problemelor din diverse domenii, astfel aceste tehnologii au fost grupate pe platforme de lucru. Platformele de lucru conțin seturi de biblioteci scrise în Java și diverse programe utilitare pentru a facilita dezvoltarea de aplicații destinate unor anumite categorii de utilizatori. Așadar sunt folosite următoarele platforme de lucru:

J2SE (Standard Edition) care oferă suport pentru crearea de aplicații independente și aplicații de tip applet, dar și o modalitate ușoară de a lansa și instala programe scrise în Java direct de pe Internet prin tehnologia Java Web Start inclusă în platformă.

J2ME (Micro Edition) dedicată programării în Java pentru dispozitive mobile.

J2EE (Enterprise Edition) oferă API-ul (Application Programming Interface) necesar realizării aplicațiilor complexe cu informații memorate în baze de date distribuite ce trebuie sa ruleze în sisteme neutre. De asemenea ca și J2SE ofera și suportul necesar creării de aplicații Web.[18]

Limbajul Java este „case-sensitive” ceea ce înseamnă că face diferența între majuscule și litere mici (ex: Variabila este diferit de variabila) și lucrează în mod nativ folosind setul de caractere Unicode. Are aproximativ 50 de cuvinte cheie conform Anexei 2, identificatorii nu au voie să fie identici cu cuvintele cheie și pot avea lungimi nelimitate.

Constantele întregi sunt acceptate în 3 baze numerice și anume baza 10, baza 16 și incep cu caracterele ”0x” și baza 8 și încep cu cifra 0, putând fi de lungime normală sau lungă având la final caracterul L sau l. Literalii flotanți trebuie să aibă cel puțin o zecimală după virgulă sau sa aiba sufixul f/F pentru valori normale și d/D pentru valori duble. True și False sunt cei doi literali logici care nu existau în C/C++ , iar constantele de tip caracter se reprezintă folosind o literă sau o secvență scrisă între apostrofuri, secvențele escape sunt prezentate în Anexa 1.

Instrucțiunile unui program scris în Java se separă cu ”;” ,iar separatorii sunt : ” ( ) [ ] ; , . ” . Operatorii sunt aproximativ la fel ca în C/C++ cu mici deosebiri cum ar fi că există operatorul “cast” pentru conversiile dintre tipurile de date sau operatorul + pentru concatenarea șirurilor, iar comentariile sunt puse la fel ca în C/C++ cu diferența că există comentarii specifice documentației pe care generatorul le mută automat în documentația aplicației javadoc, astfel de comentarii fin puse între simbolurile /** și */.

Tipurile de date sunt : byte, short, int, long, float, double, char și boolean, nemaiexistând tipurile de date pointer, struct sau union. Declararea constantelor se face folosind ca prefix cuvantul cheie final.[17]

” Convenția de numire a variabilelor în Java include, printre altele, următoarele criterii:

• variabilele ﬁnale (constante) se scriu cu majuscule;

• variabilele care nu sunt constante se scriu astfel: prima literă mică, iar dacă numele variabilei este format din mai mulți atomi lexicali, atunci primele litere ale celorlalți atomi se scriu cu majuscule. ”

Instrucțiunile de control al execuției sunt aceleași ca și în C/C++ adăugându-se instrucțiunile pentru tratarea excepțiilor ”try-catch-finally” , instrucțiunea ”continue” care termină forțat iterația curentă și trece la următoarea iterație și intrucțiunea ”return [valoare]” care termină o metodă și returnează valoarea trimisă ca parametru. [18]

Referirea valorii unei variabile sau referirea unei metode din cadrul obiectului se face folosind operatorul “.” .

Programatorul nu mai are sarcina de a distruge obiectele deoarece odată cu rularea programului concomitent cu interpretorul Java rulează un proces numit „garbage collector” care se ocupă cu distrugerea obiectelor care nu mai sunt folosite.

Modificatorii claselor în Java sunt “public” (vizibila pentru toate clasele din program), „abstract” și „final” . Modificatorul „abstract” realizează o clasa abstractă ce nu poate fi instanțiată, fiind folosită doar pentru a crea un model comun pentru o serie de subclase, iar cu ajutorul modificatorului ”final” clasa respectivă nu poate avea subclase, acestea fiind folosite pentru securitate sau pentru realizarea ”claselor perfecte” care nu trebuie să aiba subclase.

Modificatorii de acces sunt la fel ca la C/C++ conform următorului Tabelului 1:

Tabel – Accesul la clase în funcție de modificatorii acestora

Pentru afișarea informațiilor pe ecran se folosesc 4 tipuri de utilizare a fluxurilor standard de ieșire System.out.print (argument); System.out.println(argument); System.out.printf (format, argumente…) și System.out.format (format, argumente…) spre deosebire de “cin” (operatorul de citire), „cout” (operatorul de afișare), “scanf” sau „printf” din C/C++.

O clasă abstractă cu metode neimplementate sau declarare de constante se numește interfață. ”O clasă care implementează o interfață trebuie obligatoriu să speciﬁce implementări pentru toate metodele interfeței, supunându-se așadar unui anumit comportament.”

”Un pachet este o colecție de clase și interfețe înrudite din punctul de vedere al funcționaliătății lor. Sunt folosite pentru găsirea și utilizarea mai ușoară a claselor, pentru a evita conﬂictele de nume și pentru a controla accesul la anumite clase. În alte limbaje de programare pachetele se mai numesc librării sau bibilioteci.”[18]

Lucrul cu bazele de date sunt de asemenea un punct forte pentru limbajul Java, legătura realizându-se rapid cu ajutorul unui driver (software ce controlează operațiile de citire și afișare) specific fiecărui tip de SGBD.

JDBC (Java Database Connectivity) este o interfață standard SQL de acces la baze de date. Ea furnizează mecanisme standard pentru utilizatorii ce folosesc bazele de date fiind constituită dintr-un set de clase și intefețe scrise în Java.

Clasele și interfețele ce se folosesc pentru realizarea conexiunii la baza de date sunt:

– DriverManager care se ocupă cu înregistrarea driverelor ce vor fi folosite în aplicație

– Driver este o interfață pe care trebuie să o implementeze orice clasă care descrie un driver

– DriverPropertyInfo prin intermediul căreia pot fi specificate diverse proprietăți ce vor fi utilizate în realizarea conexiunii

– Connection ce descrie obiectele folosite în realizarea conexiunii la baza de date.

După realizarea conexiunii la baza de date există trei interfețe cu ajutorul cărora putem trimite interogări SQL către baza de date. Acestea sunt Statement care oferă prin trei metode executeQuery, executeUpdate și execute trimiterea de secvențe SQL către baza de date, interfața PreparedStatement care conține secvențe SQL deja compilate și CallableStatement care oferă modalitatea de a apela proceduri stocate în baza de date într-un fel comun pentru toate SGBD-urile.

Mai există și interfața ResultSet care va conține toate liniile rezultate în urma interogărilor realizate cu cele trei metode amintite anterior .[18]

2.4 Limbajul UML

Unified Modeling Language (prescurtat UML) este un limbaj standard pentru descrierea de modele și specificații pentru aplicații software. UML este un limbaj vizual de modelare, el nu este încă un limbaj vizual de programare, deoarece nu dispune de întreg sprijinul semantic și vizual pentru a înlocui limbajele de programare.[19] Limbajul a fost creat de către consorțiul Object Management Group (OMG). Este destinat vizualizării, specificării, construirii și documentării sistemelor de aplicații, dar are limitări în ceea ce privește generarea codului .UML a fost la bază dezvoltat pentru reprezentarea complexității programelor orientate pe obiect, al căror fundament este structurarea programelor pe clase și instanțele acestora (numite și obiecte). Cu toate acestea, datorită eficienței și clarității în reprezentarea unor elemente abstracte, UML este utilizat dincolo de domeniul IT. Așa se face că există aplicații ale UML-ului pentru management de proiecte, pentru business Process Design etc. UML reunește cele mai bune tehnici și practici din domeniul ingineriei programării, care și-au dovedit eficiența în construirea sistemelor complexe.[20]

Fondatorii acestui limbaj sunt Grady Booch, Ivar Jacobson și James Rumbaugh. Ei au dezvoltat limbajul bazându-se inclusiv pe limbaje de modelare deja existente, însă incomplete ca gamă de funcționalități și astfel în anul 1990 a apărut prima versiune a limbajului UML 1.0. Dezvoltarea versiunii a doua a UML a început în anul 1997 atunci când OMG a anunțat adoptarea specificațiilor UML ca limbaj standard de modelare. De atunci, UML s-a aflat într-un continuu ciclu de îmbunătățire, astăzi ajungând la varianta UML 2.4.1.[19]

UML oferă o largă gamă de diagrame pentru modelarea diferitelor situații în cadrul unui proiect de dezvoltare software. Principalele parti ale UML sunt:

Vederile (View) – surprind aspecte particulare ale sistemului de modelat. Un view este o abstractizare a sistemului, iar pentru construirea lui se folosesc un număr de diagrame.

Diagramele – sunt grafuri care descriu conținutul unui view. UML are nouă tipuri de diagrame, care pot fi combinate pentru a forma toate view-urile sistemului.

Elementele de modelare – sunt conceptele folosite în diagrame care au corespondență în programarea orientată-obiect, cum ar fi: clase, obiecte, mesaje și relații între acestea: asocierea, dependența, generalizarea. Un element de modelare poate fi folosit în mai multe diagrame diferite și va avea același înteles și același mod de reprezentare.

Mecanismele generale – permit introducerea de comentarii și alte informații despre un anumit element.

Modelarea unui sistem poate fi o muncă foarte dificilă. Ideal ar fi ca pentru descrierea sistemului să se folosească un singur graf, însă de cele mai multe ori acesta nu poate să surprindă toate informațiile necesare descrierii sistemului. Un sistem poate fi descris luând în considerare diferite aspecte:

Ø Funcțional: este descrisă structura statică și comportamentul dinamic al sistemului;

Ø Non-funcțional: necesarul de timp pentru dezvoltarea sistemului

Ø Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de cod. [20]

Viziunea cazurilor de utilizare arată funcționalitatea sistemului, așa cum este ea înțeleasă de actorii externi care interacționează cu sistemul. În componența lui intră diagrame ale cazurilor de utilizare și ocazional, diagrame de activitate. Cei care ar găsi utilă acestă viziune sunt deopotrivă clienții, designerii, dezvoltatorii, dar și cei care vor realiza testarea și validarea sistemului.

Viziunea logică descrie atât structura internă a sistemului (clase, obiecte și relații) cât și colaborările care apar când obiectele trimit unul altuia mesaje pentru a realiza funcționalitatea dorită.

Diagramele pot arăta o parte sau toate caracteristicile elementelor de modelare, conform nivelului de detaliu util în contextul unei diagrame date. Diagramele pot grupa informații interdependente, pentru a arăta, de exemplu caracteristicile moștenite de o clasă. Diagramele UML sunt:

diagrame ale cazurilor de utilizare, care prezintă funcțiile sistemului din punct de vedere al utilizatorului;

diagrame de clasă , care prezintă structura statică în termeni de clase și asocieri (relații);

diagrame de colaborare, care sunt reprezentări spațiale ale obiectelor, legăturilor și interacțiunilor;

diagrame de secvență , care prezintă temporal obiectele și interacțiunile lor;

diagrame de componente, care prezintă componentele fizice ale unei aplicații;

diagrame de construcție , care prezintă construcția componentelor pe dispozitivele hardware;

diagrame de stări-tranziții, care prezintă comportamentul unei clase în termeni de stări;

diagrame de obiecte, care prezintă obiectele și relațiile lor, fiind niște diagrame de colaborare simplificate, fără reprezentarea mesajelor trimise între obiecte;

diagrame de activități, care reprezintă comportamentul unei operații în termeni de acțiuni.[20]

Capitolul 3. Analiza și proiectarea sistemului informatic

3.1 Specificarea cerințelor sistemului informatic

După cum am prezentat și în primul capitol, activitățile principale în cadrul unei companii de asigurări sunt înregistrarea polițelor și a daunelor clienților companiei, iar pentru acestea trebuiesc realizate configurări ale produselor companiei atât în tabelele bazei de date cât și în codul aplicației.

Configurarea produselor constă în înregistrarea anumitor valori ținute în nomenclatoare pentru statusuri, acoperiri, riscuri, evenimente specifice fiecărui produs pentru a nu permite realizarea greșelilor la eliberarea polițelor sau la înregistrarea și rezolvarea daunelor. De asemenea sunt menționate și perioada maximă de durată a unei polițe și tipurile de obiecte acceptate pe acel tip de asigurare.

Înregistrarea polițelor cuprinde în general :

– introducerea datelor specifice fiecărui tip de poliță (client, obiect asigurat, acoperiri, riscuri, suma ce trebuie plătită de către client către firma de asigurare). Datele introduse în sistem despre automobil, eveniment, acoperiri și riscuri nu se pot alege la întâmplare datorită configurării realizate anterior. Nu se poate înregistra o poliță de un anumit tip dacă nu a fost configurat în prealabil.

– calcularea automată a primei de asigurare bazată pe anumite formule depinzând de produs, de exemplu în cazul produselor de asigurare pentru automobile se ia în calcul numărul de incidente anterioare, cu cât numărul acestora va crește cu atât polița va fi mai scumpă

– conversia ofertei în poliță (deoarece un client poate cere doar o estimare de preț fără a încheia polița).

Consemnarea unei daune nu se poate face fără existența unei polițe valide și plătite la momentul producerii evenimentului. Daunele folosesc informațiile stocate în sistem despre asigurarea respectivă și nu se pot face despăgubiri mai mari decât valoarea maximă asigurată de poliță.

Specific fiecărei companii de asigurare în parte sunt subprocesele legate de daune, însă toate companiile de asigurare au un proces de antifraudă activ pentru a verifica daunele care nu corespund declarațiilor proprietarului după investigarea cazului de către specialiștii companiei. Clienții nu sunt înștiințați de o asemenea anchetă doar în cazul rezolvării anchetei cu status pozitiv de tentativă de fraudare și astfel sunt pedepsiți conform legii.

Există în cazul daunelor catalogate ca fiind daune totale un alt subproces care identifică cea mai bună variantă de a scăpa de epavă după ce clientului i-au fost platite pierderile, astfel încât compania să nu iasă în pierdere.

Ca în cazul oricărei companii care dorește să aibă o viziune asupra stadiului pieței pentru previzionarea și aplicarea unor noi produse sau reguli se realizează rapoarte atât pentru polițe cât și pentru daune. De obicei se urmărește raportul dintre numărul de polițe și daune care trebuie să fie pozitiv și mare, se urmăresc polițele elaborate pe tipuri de produse pentru a ști ce produse se caută și ce produse ar trebui scoase din grilă fiind neprofitabile, se urmărește cauza principală a apariției daunelor pentru a putea crește tariful asigurărilor care acoperă acel risc etc.

3.2 Analiza si proiectarea noului sistem

3.2.1 Realizarea schemelor UML

Pentru a înțelege mai bine funcționalitățile aplicației, actorii și procesele se vor realiza câteva scheme UML. Complexitatea deosebită a sistemelor actuale a determinat abordarea pe scară largă a principiilor orientării obiectuale nu doar în ceea ce privește programarea ci și în proiectarea

lor, lucru care a avut consecințe și asupra proiectării bazelor de date. În general modelarea orientată obiect (de exemplu UML) este privită ca apanajul doar al proiectării (sau dezvoltării) aplicațiilor orientate obiect. Aceasta abordare se dovedește însă limitată având în vedere două aspecte :

Pe de o parte proiectarea aplicațiilor (orientate obiect) cu baze de date separată de proiectarea bazei de date va produce un nivel suplimentar de mapare a entităților care figurează în cele două arii la nivel conceptual.

Pe de altă parte modelele logice ale bazelor de date relaționale comerciale propun astazi o serie de concepte noi cum sunt procedurile stocate și declanșatoarele care nu fac parte din modele relaționale tradiționale și de obicei nu sunt luate în considerare în faza proiectării bazei de date[25]

Diagrama generala a cazurilor de utilizare

Figură – Diagrama generala a cazurilor de utilizare

În cazul unei aplicații pentru asigurări, principalele acțiuni care se pot realiza în sistem sunt cele menționate în Figura 6. Realizarea ofertei nu înseamnă și încheierea poliței de asigurare, ea reprezintă doar o posibilitate. Înregistrarea poliței implică colectarea datelor cu privire la client, la obiectele ce vor fi asigurate, la acoperirile și riscurile ce vor fi incluse în poliță și la detaliile despre cum va fi platită.

Plata poliței se va efectua parțial sau integral în momentul în care clientul va plăti asiguratorul pentru serviciile oferite. Anexele pe poliță se referă la faptul că un client poate adăuga obiecte, acoperiri sau riscuri pe poliță.

Înregistrarea unei daune implică din partea clientului existența unei polițe valide la data producerii evenimentului și de asemenea furnizarea documentelor necesare evaluării și calculării indemnizației acesteia. O companie de asigurări poate suspecta un client de o posibilă încercare de a frauda și atunci poate solicita deschiderea unei analize antifraudă fără înștiințarea clientului. Pentru daunele totale există un proces separat de abordare a unui proces de daună, o daună totală este considerată nu doar imposibilitatea de a repara un obiect, dar și dacă dauna valorează mai mult decât poate acoperi polița de asigurare.

Pentru ca un operator să nu introducă greșit anumite obiecte, acoperiri, riscuri sau evenimente pe o poliță sau daună se va face configurarea produselor, astfel încât la emiterea unei polițe sau înregistrarea unei daune condițiile pentru un anumit produs sa fie respectate.

Diagrame detaliate a unor cazuri de utilizare

Figură – Diagrama detaliata a înregistrării unei polițe

Pentru înregistrarea unei polițe sunt necesare autentificarea agentului care va realiza polița sau oferta. Dacă oferta va fi acceptată atunci se vor colecta date privind clientul, obiectul/obiectele, acoperirile și riscurile asigurate prin respectiva poliță. (Figura 7)

Tabel 2 – CU01: Inregistrare poliță

Figură – Diagrama detaliată a înregistrării unei daune

Înregistrarea unei daune implică existența unei polițe, date despre evenimentul care a fost produs, date despre obiectul vătămat și documentele necesare, realizarea unei sau mai multor evaluări de către o persoană specializată, pe baza ultimei evaluări se va calcula suma de plată către client și apoi se va efectua plata către client. (Figura 8)

Tabel 3 – CU02: Inregistrare daună

Figură – Diagrama detaliată a configurării unui produs

Configurarea produselor trebuie sa includă condițiile generale ale produsului, adică perioada maximă pentru care poate fi încheiată acel tip de poliță, ce fel de persoane (fizice sau juridice) pot încheia un astfel de contract etc, trebuie să mai conțină date despre ce fel de tipuri de obiecte pot fi asigurate pe acel tip de poliță și ce riscuri, acoperiri și evenimente sunt specifice produsului.(Figura 9)

Tabel 4 – CU03: Configurare produs

Diagrame de activitate

Pașii urmați pentru a înregistra o poliță este descris mai sus în Figura 10 în diagrama de activitatea specifică pasului de înregistrare a poliței.

Figură – Diagrama de activitate specifică înregistrării unei polițe

În această diagramă (Figura 11) este descris fluxul de înregistrare al unei daune în sistem.

Figură – Diagrama de activitate specifică înregistrării unei daune

Diagrame de stare

Figură – Diagrama de stare pentru o poliță

Stările în care poate fi o poliță sunt (Figura 12):

Ofertă – atunci când un operator realizează o ofertă pentru un client

Ofertă respinsă – dacă nu s-a încheiat o poliță de asigurare

Poliță inregistrată – dacă oferta a fost acceptată si o poliță a fost înregistrată

Poliță platită – dacă polița a fost plătită integral

Poliță reînnoită – dacă după expirarea acesteia a fost reînnoită

Poliță închisă – dacă aceasta a fost închisă sau a expirat

Figură – Diagrama de stare specifică unei daune

Stările în care se poate afla o daună sunt (Figura 13):

Daună înregistrată – dacă polița a fost găsită și dauna a fost înregistrată

Documente primite – dacă documentele necesare continuării procesului au fost primate

Daună evaluata – dacă evaluarea daunei a fost realizată

Daună neplatită – dacă dauna incă nu a fost platită către client

Daună platită – dacă dauna a fost plătită către client

Daună totală – dacă dauna a fost catalogată ca fiind daună totală

Tentativă de fraudă – dacă daunei i s-a deschis o analiza antifraud

Diagrama de clase detaliată

Diagrama de clase este asemănătoare schemei bazei de date. Pentru configurarea produselor vor fi necesare tabele pentru configurarea datelor generale despre produs, pentru acoperiri, evenimente, riscuri, tabele de traducere pentru utilizatori și definire a limbii fiecărui utilizator. Pentru înregistrarea polițelor avem nevoie de tabele pentru obiecte, riscuri, acoperiri, plăți ale polițelor și date generale despre client, iar pentru daune avem nevoie de datele despre poliță, despre obiectul vătămat, evenimentul produs, evaluări, calcul de indemnizație, riscuri și acoperiri aferente incidentului.

De asemenea vom avea și câteva nomenclatoare necesare pentru definirea și refolosirea anumitor stări, acoperiri sau riscuri, și tabela de sarcini specifică celor două subprocese de antifraudă și daună totală. (Figura 14)

Figură – Diagrama de clase detaliată

Diagrama de secvențe

O diagramă de secvență prezintă colaborarea dinamică între un număr de obiecte, mai precis secvențele de mesaje trimise între acestea pe măsura scurgerii timpului. În cazul nostru am realizat diagrama de secvență în cazul cererii unei oferte de poliță și înregistrării unei polițe (Figura 14), în cazul înregistrării unei daune (Figura 15)și specifică configurării sau modificării produselor (Figura 16).

Figură – Diagrama de secvență(poliță)

În cazul nostru am realizat diagrama de secvență în cazul cererii unei oferte de poliță și înregistrării unei polițe (Figura 14), se poate observa modul în care se poate contracta o poliță. Clientul cere o ofertă către operator, apoi îi comunică datele necesare care îi sunt cerute, acceptă sau nu oferta și în cazul în care acceptă plătește și polița. Operatorul pentru a putea realiza toate aceste lucruri trebuie să se conecteze la aplicație, să introducă datele necesare astfel încât să poată face oferta, să inregistreze polița și plata în sistem.

Figură – Diagrama de secvență(daună)

În diagrama de secvență pentru daună (Figura 15) se poate observa acțiunile pe care trebuie să le facă un client pentru ca la sfarșit să beneficieaze de despăgubire. Acesta trebuie să sesizeze dauna telefonic, să ofere informațiile necesare și de asemenea actele necesare și apoi să aștepte definitivarea daunei. În schimb operatorul trebuie să înregistreze dauna, obiectele, evaluarea acestuia, in cazul subproceselor să aștepte rezolvarea lor de către colegi, apoi sa facă documentele de plată și să realizeze plata către client.

3.2.2 Proiectarea schemei bazei de date

Schema conceptuală a bazei de date este descrisă în Figura 17. Există trei module pentru aplicația noastră și pentru fiecare modul avem tabele specifice.

Tabelele care se referă la modulul pentru polițe sunt : polițe, riscuri, acoperiri, obiecte si plăți. În tabela polițe vor exista informații privind clientul poliței precum adresa, numele, codul numeric personal etc., agentul care a încheiat polița (numele, agenția), data de început și de sfarșit a poliței și tipul de produs (dacă este o poliță RCA, CASCO, de viață etc.).

Cum o poliță nu poate exista fără cel puțin un obiect, o acoperire sau câteva riscuri, atunci vom avea tabela de obiecte care va conține infomații specifice fiecărui obiect și care va fi legată prin cheie externă de tabela de polițe. De asemenea tabela de acoperiri și tabela de riscuri va conține acoperirile asigurate pentru fiecare obiect si riscurile pentru fiecare acoperire și va fi legată prin cheie externă de tabela de obiecte.

Modulul de daune se va defini prin folosirea tabelei de daune, care va conține date generale privind dauna, data evenimentului, clientul, agentul, descrierea evenimentului etc., tabela care contine informații despre obiectul daunei, tabela care contine informații despre evaluarea daunei, evaluator, valoarea estimata etc., tabela pentru plata daunei cu detalii despre plata, pentru analiza de antifrauda cu informatii despre inspector, rezultatul analizei etc. și tabela pentru dauna totală care va contine informații despre licitația realizată pentru epavă.

Figură – Schema conceptuala a bazei de date

Configurarea produselor va fi realizată folosind o serie de tabele ce vor fi verificate în momentul creării unei polițe sau a unei daune. Tabela cfg_prod_desc este tabela care definește condițiile generale ale unui produs, numele, valabilitatea etc. Acoperirile specifice pentru un produs sunt definite în tabela cfg_acoperiri care este legată de tabela anterior prezentată prin codul produsului și de tabela nomenclator nom_acop prin codul acoperirii. Pentru fiecare acoperire trebuie definite riscurile și astfel cfg_riscuri este tabela prin care se configurează riscurile si este legată de tabela de configurare a acoperirilor prin codul acoperirii și de tabela nomenclator pentru riscuri nom_risc prin codul riscului. Pentru a vorbi despre o daună trebuie să existe un eveniment declanșator și astfel apare tabela de configurare cfg_evenim care va fi legată de produs și acoperire.

Fiecare poliță și daună trece prin anumite stări, acestea vor fi definite în nomenclatorul nom_status. În cazul analizei de antifraudă și daună totală doar anumiți utilizatori se vor putea ocupa de acestea și pentru acest lucru vom avea tabela de sarcini astfel încât fiecare dintre acești utilizatori să-și vadă propriile sarcini de realizat.

Capitolul 4. Realizarea aplicației informatice

4.1 Implementarea aplicației

Logica aplicației este realizată în mare parte în baza de date, dar parțial și în codul Java. Pentru conexiunea la baza de date am realizat o funcție private folosind librăria Oracle JDBC cu clasa DriverManager și metoda getConnection așa cum se poate observa în codul următor :

Această funcție este apelată în fiecare clasă folosită în metoda de inițializare a clasei jbInit(), iar pentru afișarea mesajelor de informare sau eroare am folosit metoda showMessageDialog a clasei JOptionPane. Pentru autentificarea utilizatorului a fost creată în baza de date o tabelă user_login unde sunt stocate utilizatorul, parola și rolul acestuia. Rolul fiecărui utilizator este necesar pentru a verifica accesul acestuia la modulele aplicației deoarece un utilizator nu poate accesa orice modul.

Primul modul al aplicației este cel de configurare. În cadrul acestei părți a aplicației se configurează produsele, dar și noi utilizatori prin adăugarea unui rol sau crearea unui nou utilizator. Așadar pentru configurarea unui produs sunt stocate date în cinci tabele : cfg_prod_conditions, cfg_covers, cfg_risks, cfg_events și user_login. Există trei pagini de configurare care conțin câmpurile necesare pentru stocarea datelor în tabele. Pentru salvarea datelor în tabele am realizat câte o procedură PL/SQL precum cea de mai jos:

Aceste proceduri sunt apelate pe butoanele aplicației folosind librăriile java.sql.CallableStatement și java.sql.ResultSet. După cum se poate observa din codul de mai jos aceste apeluri trebuie puse în blocuri de tip try..catch pentru a putea captura excepțiile ce pot apărea din cauza bazei de date. Fiecare câmp ce trebuie salvat în baza de date trebuie preluat din TextField-uri, ComboBox-uri sau TextArea-uri ca text și convertite în tipul de dată necesară tabelului bazei de date.

Clasa CallableStatement folosește metoda prepareCall pentru a pregăti apelul procedurii în baza de date, metodele set fiind folosite pentru ca în locul fiecărui semn de întrebare care reprezintă numărul de parametrii necesari executării procedurii, să fie pusă valoarea capturată din câmpurile aplicației.

Pentru modificări aduse configurării am realizat vederi(view) în baza de date care aduc datele necesare populării cu date a câmpurilor din aplicație cu cele din baza de date. Apoi din codul Java am apelat interogarea pe acest view și am populat fiecare câmp cu datele necesare. Pentru configurare am realizat configurare_view care este definită după cum urmează :

Pentru valorile care se pot repeta în diverse contexte ale aplicației am realizat nomenclatoare pentru a elimina redundanța datelor. S-au folosit nomenclatoare pentru tipul de poliță, pentru acoperiri, riscuri sau evenimente. Apelarea acestei interogări s-a realizat folosind clasa PreparedStatement cu metoda executeQuery. Capturarea datelor din interogare pentru popularea câmpurilor aplicației s-a realizat cu clasa ResultSet și metoda set. Verificarea corectitudinii datelor introduse în câmpurile aplicației este realizată în baza de date prin validări definite de utilizator pe tabele(check) dar și în codul Java.

Modulul polițe are patru submeniuri pentru înregistrarea, modificarea, vizualizarea și raportarea polițelor. Primul cât și al doilea submeniu au câte patru pagini de inregistrare respectiv modificare. Pentru adăugarea cât și pentru modificarea poliței în baza de date s-a realizat o procedură PL/SQL.

Pentru atribuirea automată a codului poliței am definit o secvență(sequence) care se apelează folosind metoda nextval la fiecare inserare în baza de date. Toate polițele au stări pentru ca operatorul să fie informat despre clienți și de asemenea pentru raportare. Pentru aceste stări am realizat o funcție PL/SQL care este apelată după cum se poate observa în codul de mai sus, iar pentru apelarea din cod Java a procedurii s-a folosit aceiași abordare ca și cea descrisă pentru configurare. Înainte de orice inserare în baza de date se face întâi validarea datelor folosind funcții Java private de validare precum cea de mai jos:

În cazul în care funcția va returna false mesajul de eroare pentru validarea care nu a fost îndeplinită va fi afișat și inserarea în baza de date nu se va realiza. Pentru modificarea poliței s-a realizat de asemenea o vedere (view) pentru popularea câmpurilor din aplicație și apoi după modificarea câmpului dorit se va apăsa butonul de salvare iar funcția specifică va fi apelată.

Căutarea și vizualizarea polițelor dar și daunelor se realizează după numărul sau codul poliței, respectiv daunei, cât și după CNP-ul clientului. Pentru aceasta se folosește vederile menționate mai devreme iar informațiile sunt afișate sub formă de text într-un câmp de tip TextArea.

Rapoartele vor fi realizate atât pentru polițe cât și pentru daune și se vor urmări polițele/ daunele neplătite, se va realiza o listă neagră a clienților care au încercat să fraudeze, se va urmări care produs este neprofitabil și care este profitabil. Toate acestea vor fi realizate folosind tabele jTabel și grafic de tip bare realizat cu ajutorul limbajului Java care va apela interogări din baza de date.

Modulul daune are șase submeniuri precum înregistrarea/modificarea, vizualizarea, analiza antifraudă, procesul de daună totală, sarcinile utilizatorului și raportarea. Verificarea corectitudinii datelor, înregistrarea și modificarea unei daune folosește abordarea prezentată mai sus. Analiza antifraudă este deschisă de un utilizator obișnuit atunci când ceva pare suspect, însă terminarea acesteia se va realiza de un utilizator specializat care va primi automat înștiintare în propriul lui ecran de sarcini despre analiza nou deschisă. Pentru afișarea acestora s-a folosit un tabel Java care afișează date specifice pentru fiecare rol de utilizator în parte. Pentru a afișa datele am folosit acest tip de abordare :

Procesul de daună totală se deschide automat în momentul în care pe daună s-a realizat o evaluare a pierderilor care duc la clasificarea daunei ca fiind totală. De asemenea această investigare și rezolvare a procesului se face de un utilizator specializat.

4.2 Prezentarea aplicației

După cum am precizat și în capitolul anterior prima pagină a aplicației (Figura 19) este constituită de autentificare. Utilizatorul va fi creat în prealabil de un administrator iar apoi utilizatorul își va putea schimba parola folosind interfața.

Figură – Pagina de autentificare

Următoarea pagină a aplicației (Figura 20) reprezintă principalele trei module ale aplicației. În funcție de rolul fiecărui utilizator aceste meniuri vor fi sau nu accesibile, în cazul în care nu va fi accesibilă afișându-se mesajul “Nu aveți acces! Contactați administratorul!”

Figură – Pagina de start a aplicației

Configurarea produselor conține trei pagini : Condiții Generale(Figura 21), Acoperiri și Riscuri și Creare utilizatori. Primele două pagini se referă la configurarea produselor, între ele este transferat codul produsului și astfel în baza de date va fi creată legătura dintre acestea. Codul produsului va fi numeric pozitiv, numele produsului va fi descrierea acestuia, intervalul pentru valabilitate va fi în format de dată calendaristică, iar pentru celelalte două câmpuri s-au folosit valori din nomenclator pentru a nu se putea realiza vreo greșală de configurare. Pentru a doua pagină vom avea trei valori luate din nomenclatoare pentru acoperire, risc și eveniment și vor fi de asemenea două câmpuri de tip dată calendaristică. Toate verificările necesare pentru validarea datelor sunt realizate în codul Java sau în baza de date.

Pentru modificarea sau adăugarea de noi utilizatori vor exista trei câmpuri pentru utilizator, parola și rol. Un utilizator poate avea minim un rol în aplicație. Rolurile utilizatorilor sunt configurator, operator daune, operator polite, inspector antifrauda sau inspector dauna totala.

Figură – Prima pagină de configurare

Modulul de polițe conține patru submeniuri și anume înregistrare poliță, modificare poliță, vizualizare poliță și raportare. Pentru înregistrarea poliței (Figura 22) se vor valida câmpurile de tip data pentru a conține o data validă și pentru ca data de început a poliței să nu fie mai mare sau egală ca data de sfarșit, de asemenea se va valida corectitudinea CNP-ului, valoarea asigurată și prețul poliței pentru bunul menționat pe poliță să nu fie negativă.

Figură – Prima pagina de introducere a polițelor

Pentru că pot exista mai multe obiecte asigurate pe o poliță am folosit afișarea acestora într-un table și în cazul în care se dorește modificarea obiectului se va selecta din table, modifica și salva, această abordare este folosită și în cazul acoperirilor și riscurilor.

Căutarea unei polițe(Figura 23) se poate realiza după cod și număr de poliță și după CNP-ul clientului. Informațiile vor fi afișate textual mai jos după apăsarea butonului de căutare. Raportarea se va realiza după trei criterii enumerate într-o listă din care utilizatorul își va alege astfel încât raportul să fie realizat automat. Criteriile sunt afișarea polițelor neplătite, fără daune și după categoria de produs.

Figură – Pagina de căutare a polițelor după număr sau cod

Adăugarea unei daune în sistem(Figura 24) presupune verificarea existenței poliței în primul rând. Astfel la introducerea unei daune se va verifica acest aspect, dea semenea se va verifica validitatea poliței la data realizării evenimentului, CNP-ul proprietarului să fie la fel cu cel al clientului de pe poliță în cazul polițelor non RCA și diferit în cazul celor RCA și sumele estimate de pe daună să fie pozitive. Restul informaâiilor necesare sunt preluate automat de pe poliță și din configurarea produselor, deci nu vor fi verificate deoarece nu se pot introduce greșit, în cazul în care un risk nu se potrivește cu o acoperire atunci o eroare va fi afișată.

Figură – Prima pagina de adăugare și modificare a daunei

Vizualizarea daunei ca și cea a poliței se realizează după căutarea codului și numărul daunei și CNP-ului clientului, dar și după codul poliței. În cazul modificării daunei abordarea este similară ca la polițe și doar anumite câmpuri vor fi active pentru modificare, cele care nu impactează în vreun fel analiza inspectorilor de daună. Datele vor fi afișate textual cu toate detaliile necesare

Figură – Pagina de căutare a daunei după număr sau cod

Daunele totale vor fi automat create în momentul în care o evaluare pe o daună va fi catalogată ca fiind totală. Aceste daune vor fi investigate de utiizatori specializați și ca verificări se vor realiza validarea sumei obținute prin licitație, restul câmpurilor fiind automat populate de sistem. Se pot vedea apoi pe pagina de căutare daune mai vechi după numărul daunei sau chiar toate daunele investigate până atunci.

Figură – Pagina unde vor fi înregistrate subprocesul daunelor totale

Procesul de antifraud este deschis de către un utilizator obișnuit care sesizează anumite neconcordanțe pe dauna respective. Acest proces este necunoscut de către client și nu vom avea verificări pentru corectitudinea datelor acestea fiind populate automat. La fel ca și procesul descris anterior există fereastra de căutare a dauneor după numărul daunei sau în totalitate.

Inspectorii specializați si anume cei de antifraud și daună totală, vor avea acces doar la trei ecrane și anume Sarcini pentr a-si vedea sarcinile zilnice, vizualizare daună pentru a investiga mai efficient și dauna totală sau antifraud depinzând de rolul acestora. Doar sarcinile active vor fi afișate în fereastra specifică, iar cele rezolvate se pot căuta în pagina de căutare a antifraudelor sau daunelor totale.

Concluzii

În concluzie domeniul asigurărilor este unul complex, însă pe piața de asigurări din Roânia, predomina asigurarile de non-viata, iar in cadrul acestora, asigurarea autovehiculelor. Asigurarea mijloacelor de transport cuprinde patru clase de asigurari din cele 18 ale claselor de asigurari de viata, si anume clasele III-VI, si acestea se refera la: asigurari ale mijloacelor de transport terestru, altele decat cele feroviare; asigurari ale mijloacelor de transport feroviar; asigurari ale mijloacelor de transport aeriene si asigurari ale mijloacelor de transport navale: maritime, fluviale, lacustre, canale navigabile.

Asigurarile auto au aparut pentru prima data la inceputul secolului al XX – lea, fiind incluse in categoria asigurarilor de accidente. In a doua jumatate a secolului, odata cu dezvoltarea transporturilor rutiere, cu cresterea vertiginoasa a numarului de masini si cu diversificarea acestora, asigurarile de autovehicule s-au desprins din grupa asigurarilor de accidente, devenind o categorie de sine statatoare.

Această lucrare prezintă într-un mod destul de general o parte dintre procesele realizate ăn cadrul ueni companii de asigurări. În continuarea acestei aplicații mai pot fi adăugate numeroase funcționalități precum : integrarea cu un sistem de contabilitate, cu un sistem de raportare, realizarea de tabele și forme specifice pentru diferitele tipuri de obiecte, integrarea cu un sistem BPM (Bussiness Process Management) etc.

Bibliografie

[1] http://dexonline.ro/definitie/asigurare

[2] http://ro.wikipedia.org/wiki/Asigurare

[3] http://en.wikipedia.org/wiki/History_of_insurance

[4] http://ro.wikipedia.org/wiki/Asigurare_de_via%C8%9B%C4%83

[5] http://ro.wikipedia.org/wiki/R%C4%83spundere_Civil%C4%83_Auto

[6] http://www.1asig.ro/Despre-asigurari-13.htm

[7] http://www.capterra.com/insurance-policy-software/

[8] http://www.asfromania.ro/informatii-publice/statistici/statistici-asigurari

[9] http://inf.ucv.ro/~giurca/courses/CB3105/resources/Introducere%20in%20UML.pdf

[10] – Manole Velicanu,Ion Lungu și alții- Sisteme de Baze de Date Evoluate, Editura ASE, București, 2009, ISBN: 978-606-505-217-8

[11] Dr.C.M.Dragan, F.Plopeanu, B.N.Popa – Contabilitatea asigurarilor , Asociatia Europeana de Studii si Consultanta,2005, ISBN 973-0-04139-3

[12] C.M.Dragan – "Assurance et reassurance"- Publicată de Cluburile asiguratorilor din Roma și Londra prin grija Vienna Insurance Group,2007

[13] C. M. Drăgan, Știința asigurărilor, Editura Universitară, 2007

[14]- http://en.wikipedia.org/wiki/Oracle_Database#History

[15]-http://www.oracle.com/technetwork/database/database-11g-standard-edition-datas-130913.pdf?ssSourceSiteId=ocomen

[16]- http://ro.wikipedia.org/wiki/Java_(limbaj_de_programare)

[17]- http://thor.info.uaic.ro/~acf/java/curs/1/introducere.html

[18]- http://thor.info.uaic.ro/~acf/java/Cristian_Frasinaru-Curs_practic_de_Java.pdf

[19] – http://ro.wikipedia.org/wiki/Unified_Modeling_Language

[20] – http://inf.ucv.ro/~giurca/courses/CB3105/resources/Introducere%20in%20UML.pdf

[21] Constantin Alexa, Violeta Ciurel, Emil Sebe, Ana Maria Mihăescu, “Asigurări și reasigurări în comerțul internațional”, Ed. All, București, 1992, p.34

[22] http://www.academia.edu/4706172/2011_mai_Asigurari_si_reasigurari_

[23] https://www.getapp.com/industries-software/a/insly-com/

[24]https://www.google.ro/search?q=insly&espv=2&biw=1289&bih=755&source=lnms&tbm=isch&sa=X&ei=SYdIVbKNHfKy7Qbni4DYAQ&ved=0CAYQ_AUoAQ#tbm=isch&q=mutual+expert&imgrc=SaFXOBohe4J-OM%253A%3BQlngHUYn5MwBrM%3Bhttps%253A%252F%252Fmedia.licdn.com%252Fmedia%252Fp%252F2%252F005%252F06b%252F010%252F04f384f.png%3Bhttps%253A%252F%252Fwww.linkedin.com%252Fcompany%252Fmutual-expert%3B974%3B330

[25] http://revistaie.ase.ro/content/26/Strimbei.pdf

Anexe

Anexa 1 – Termeni din domeniul asigurărilor

Asigurator : este entitatea juridică, societatea de asigurări, care în schimbul unei prime de asigurare de la asigurat îsi asumă responsabilitatea de a acoperi pagubele produse propietatilor sau serviciilor asigurate;

Asigurat : este individual, persoana fizică sau juridică ce se asigură contra unor evenimente ce pot apărea, își asigură bunurile împotriva unor dezastre naturale sau care se asgiruă pentru prejudiciul pe care îl poate produce unor alte persone.

Contract de asigurare : este actul juridic prin care se stabilesc contactele juridice dintre părțile acestuia. Este format dintr-un cumul de documente cuprinzând: cererea de asigurare, polița de asigurare, condițiile contractuale pentru asigurarea de bază și pentru clauzele suplimentare anexate.

Beneficiarul asigurării este individul care are dreptul să încaseze despăgubirea sau suma asigurată, fără ca aceasta să fie parte la contractul de asigurare;

Contractantul asigurării este element specific asigurărilor facultative și reprezintă persoana fizică sau juridică care poate încheia o asigurare, fără însă ca aceasta să obțină calitatea de asigurat;

Riscul asigurat este intamplarea care odată produsă, datorită efectelor sale, obligă pe asigurător să plătească asiguratului, despăgubirea sau suma asigurată;

Evaluarea în vederea asigurării este element specific asigurărilor de bunuri;

Suma asigurată este parte din valoarea de asigurare pentru care asigurătorul își asumă răspunderea în cazul producerii evenimentului pentru care s-a încheiat asigurarea;

Norma de asigurare reprezintă suma asigurată, stabilită prin lege, pe unitatea de obiect asigurat, ea fiind întâlnită numai în cazul asigurărilor de bunuri obligatorii;

Prima de asigurare reprezintă suma de bani dinainte stabilită pe care asiguratul o plătește asigurătorului, pentru ca acesa să-și poată constitui fondul de asigurare necesar achitării despagubirilor;

Durata asigurării reprezintă perioada de timp în care rămân valabile raporturile de asigurare între asigurător și asigurat așa cum au fost ele stabilite prin contractul de asigurare;

Paguba/dauna reprezintă pierderea valorică a unui bun asigurat ca urmare a producerii fenomenului pentru care s-a încheiat asigurarea;

Broker de asigurare este persoana juridică română sau străină, autorizată în condițiile legii, care, pentru clienții săi negociază sau încheie contracte de asigurare și acordă alte servicii în legătură cu protecția împotriva riscurilor și/sau regularizarea daunelor.[2]

Anexa 2 – Secvențele Escape Java

[17]

Anexa 3 – Cuvinte cheie Java

[18]

Tabeluri

Tabel 1- Accesul la clase în funcție de modificatorii acestora 21

Tabel 2 – CU01: Inregistrare poliță 29

Tabel 3 – CU02: Inregistrare daună 31

Tabel 4 – CU03: Configurare produs 32

Figuri

Figură 1 – Exemplu de poliță de asigurare (Insly) (sursa : [23]) 12

Figură 2 – Sistemul de raportare al aplicației (Insly) (sursa : [23]) 13

Figură 3 – Sistem de raportare (Mutual Expert) (sursa [24]) 13

Figură 4 – Rapoarte despre agenti(INSIS) (sursa : http://www.fadata.eu/feature/agents-commission/) 14

Figură 5- Diagrama generala a cazurilor de utilizare 28

Figură 6– Diagrama detaliata a înregistrării unei polițe 29

Figură 7 – Diagrama detaliată a înregistrării unei daune 30

Figură 8 – Diagrama detaliată a configurării unui produs 32

Figură 9 – Diagrama de activitate specifică înregistrării unei polițe 33

Figură 10 – Diagrama de activitate specifică înregistrării unei daune 34

Figură 11 – Diagrama de stare pentru o poliță 34

Figură 12 – Diagrama de stare specifică unei daune 34

Figură 13 – Diagrama de clase detaliată 35

Figură 14 – Diagrama de secvență(poliță) 36

Figură 15 – Diagrama de secvență(daună) 37

Figură 16 – Schema conceptuala a bazei de date 39

Figură 17 – Pagina de autentificare 50

Figură 18 – Pagina de start a aplicației 50

Figură 19 – Prima pagină de configurare 51

Figură 20 – Prima pagina de introducere a polițelor 52

Figură 21 – Pagina de căutare a polițelor după număr sau cod 53

Figură 22 – Prima pagina de adăugare și modificare a daunei 54

Figură 23 – Pagina de căutare a daunei după număr sau cod 54

Figură 24- Pagina unde vor fi înregistrate subprocesul daunelor totale 55