HiOA TKD Ingeniørfag Data Programutvikling Eva Hadler Vihovde Prosjektoppgaven 2015 Alternativ 1 - Forsikring - Studentnavn Marius Alexander Skjolden Hans Christian Nenseth Hans Petter Osvold Studentnummer s114143 s236334 s929913 1 / 14
Table of Contents Oppgavebeskrivelse...3 Programmets hovedoppgave...3 Prioriteringsrekkefølge...4 Ekstra funksjonalitet og visjoner...4 Skisser...4 Kunder...5 Forsikringer...6 Skade...8 App Flow...9 Oppbyggning og Java klasser...10 Klasserelasjoner...11 Klassehierarki...12 Datastruktur...12 Utviklingsverktøy...12 Systemkrav...12 Javaversjon...12 Framdriftsplan...13 Arbeidsfordeling...13 2 / 14
Oppgavebeskrivelse Sakset fra fagets hjemmeside: Dere har fått i oppdrag å lage et java-program for et forsikringsselskapet. Programmet skal kunne registrere selskapets kunder, opprette ulike typer forsikringer, registrere skader og utbetale erstatninger. Systemet skal kunne generere ulik type statistikk og historikk, i tillegg til at det skal være enkelt å hente ut forskjellig informasjon. De ulike forsikringstypene selskapet i dag tilbyr er bilforsikring, båtforsikring, hus- og innboforsikring, forsikring av fritidsbolig og reiseforsikring. De har imidlertid planer om å utvide sitt forsikringstilbud og programmet må derfor bygges opp på en måte som gjør at det enkelt å bygges det ut med flere forsikringstyper etterhvert. Forsikringsselskapet tilbyr 10% i rabatt på den årlige forsikringspremien for forsikringskunder som defineres som "totalkunde". For å bli totalkunde må kunden ha minst tre ulike typer forsikringer. Med hensyn til bilforsikring følger selskapet det vanlig bonus-systemet som gjelder i Norge, der kunder som kjører skadefritt opparbeider seg bonus og øker derved sin rabatt på bilforsikringen med en gitt prosent for hvert år. Kunden kan pr idag ikke opparbeide høyere bonus enn 75%. Hvis vedkommende skader bilen, vil bonusen minske og bilforsikringspremien øke. Bonussystemet er imidlertid til revidering og systemet skal derfor lett kunne oppdateres og tilpasses de bonusregler som til enhver tid måtte gjelde. (Sjekk reglene som gjelder i andre forsikringsselskap.) Programmets hovedoppgave Vi har valgt å løse oppgaven fra en forsikringsagents perspektiv. Programmet vil simulere et arbeidsverktøy til bruk for f.eks telefonoppringninger e.l. Vi har i utgangspunktet ingen planer om å lage et grensesnitt for forsikringskunden, hvor oversikt og administrasjon av den enkeltes forsikringer og skader kan administreres. Fokuset på forsikingsagenten mener vi er mer enn nok arbeidsmengde gitt tiden til dette prosjektet. Det at oppgaven krever at det skal bli utviklet et java program legger naturligvis noen føringer på hvordan oppgaven skal løses. Med tanke på pensum og hvilke rammeverk prosjektet tillater å bruke vil det være urealistisk å implementere en kundeportal. Dette kan løses enten ved å lage en Android applikasjon eller et av de tilgjenglige web-rammeverkene til Java. Følgen av dette premisset er at det skal utvikles et CRM (Customer Relationship Management) program som skal fungere som et arbeidsverktøy for ansatte i forsikringsselskapet. 3 / 14
Prioriteringsrekkefølge Del 1: Implementere datastruktur ( Absolutt krav ) Del 2: Implementere abstrakt GUI ( Absolutt krav ) Del 3: Implementere String bibliotek ( Kan sløyfes ) => Refactor => Del 4: Implementere konkret GUI ( Absolutt krav ) Del 5: Implementere generering av avansert statistikk ( Kan sløyfes ) Del 5: Utvide String biblioteket til å innkludere flere språk ( Kan sløyfes ) Ekstra funksjonalitet og visjoner Etter å ha implementert basis funksjonaliteten til applikasjoner aspirerer vi å utvide applikasjonen med ekstra funksjonlitet som: Fram og tilbake navigasjon via stakker (ala fram og tilbake funksjonalitet til en nettleser) Streng bibliotek for sentralisering av alle grensesnittsstrenger (med flerspråkelig funksjonlitet som en heldig bieffekt) Avansert statistikk generering og visualisering (grafer, søyler osv). Skisser Kunde, Forsikring og Skade er klasser i systemet vi anser som hovedklassene i applikasjonen. Alle disse objektene vil ha et standard CRUD (Create, Read, Update, Delete) behov. Vi ser for oss å strømlinjeforme disse prosessene slik at sluttbruker kan føle en rød tråd igjennom applikasjonen. Med andre ord vil oppretting, utlesing, oppdatering og sletting av disse tre hovedobjektene være så lik som mulig. Videre ser vi for oss at applikasjonen skal ha en tradisjonell "MenuBar" med operasjone for åpne fil, lagre til fil, m.m Hovedmenyen til applikasjonen vil være via en venstremeny som skissert under. Denne venstremenyen vil sluttbrukeren kunne bruke til å navigere de tre hovedobjektene og ekstra funksjonalitet som Statistikk Hovedområdet i applikasjonen (til høyre for venstremenyen) ser vi for oss at skal være et "StackPane" 4 / 14
hvor de forskjellige "views" vil ligge over hverandre som en kortstokk. Ved navigasjon og operasjoner vil "views'ene" i stakken stokkes om. Skissene under kan være mangelfulle og inneholde feil. Dette er grunnet trådskissenes ikke-endelige natur. De er tiltenkt i hovedsak som føringer, ikke fasit. Kunder 5 / 14
Forsikringer 6 / 14
7 / 14
Skade 8 / 14
App Flow Nedenfor er et enkelt flytskjema for hvordan vi ser for oss at hovednavigasjonen i applikasjonen skal være. Hovedtanken her er at forsikringer og skademeldinger skal gå igjennom kunden. 9 / 14
Oppbyggning og Java klasser Kunde Forsiking Skade Dette er de tre hovedklassene som vil dominere applikasjonen. Grensesnittet vil i utgangspunktet kun utføre manipulasjon på objekter og lister med objekter av denne typen. Statistikken vil være data hentet ut og generert fra disse listene/dataene. Disse tre hovedklassene vil relatere til hverandre gjennom "pekerlister" som inneholder pekere lik de i hovedlistene for å unngå duplisering av objekter (data). Utover disse tre hovedklassene vil det eksistere datalagringsklasser som håndterer lagring av data og lesing av data til disk. Med bruk av "Collections" sin "List" grensesnitt vil lister og logikk rundt det være noe vi får gratis. Vi har på dette stadiet ikke gjort noe avgjørelse på hvilken konkret listetype vi skal benytte, da vi ønsker å utsette denne avgjørelsen til vi kan utføre noen ytelsestester. 10 / 14
Klasserelasjoner Her er limet til hovedklassene i applikasjonen (representert på engelsk, som vil være språket vi benytter i kildekoden). Disse klassene vil ha flere medlemmer, men de vil ikke ha noe med relasjonene mellom klassene å gjøre. De tre listene på høyre side i skissen er ment som illustrasjon for hovedlistene i applikasjonen. Det er disse tre hovedlistene som blir skrevet og lagret til fil. 11 / 14
Klassehierarki Grunnet kunders flate hierarki struktur ser vi ikke stort behov for å implementere noen abstrakte klasser og arv for denne datatypen. Forsikringer og alle forsikringstypene er en naturlig kandidat for arv av en abstrakt Forsikringstype. Denne abstrakte forsikringstypen vil ha antall medlemer og metoder lik største fellesnevners antall. Skade klassen har en bilskade som vil og være naturlig kandidat for dette. Datastruktur Hoveddatastrukturen til applikasjonen vil være List igjennom Collections. Med bruk av Generics vil lister med de tre hovedklassene beskrevet over være veldig lett å implementere. List vil og være listetypen vi benytter til internrelasjonene mellom konkrete objekter. Vi ønsker å avvente avgjørelsen med hvilken konkret liste type vi ender opp med å benytte, grunnet ønske om å ytelsesteste de forskjellige. Hovedkandidatene er LinkedList og ArrayList. Lagring av data til disk vil gjøres igjennom ObjectOutputStream og ObjectInputStream. Utviklingsverktøy Alle gruppas medlemer bruker IntelliJ IDEA utviklingsverktøy til programutviklingsdelen av oppgaven. Git og GitHub brukes som versjonskontroll, og Redmine til oppgavestyring. Systemkrav Det settes ingen krav til maskinvare utover at det bør være en datamaskin av nyere dato. Vi vil legge ved tre datafiler av liten, medium og stor størrelse for å teste systemets skalerbarhet ved forskjellige maskinkonfigurasjoner. Javaversjon Grunnet bruk av JavaFX komponenter er minst JDK 1.8 påkrevet. Det vil være ønskelig at JDK 1.8u40 er tilgjengelig på maskinen programmet skal kjøres på grunnet bruk av Dialog og Widget bokser gjort tilgjengelig i JavaFX i denne versjonen. 12 / 14
Framdriftsplan Det er vanskelig å tidfeste noen konkterte mål utover og sette opp arbeidesfølgen som følger, når det er sagt vil vi sette som mål å ha en ukes tid i slutten av perioden avsatt til testing og bughunting. Alt etter som hvor sukssefulle vi er vil vi på slutten prøve å få implementert mest mulig av ekstra funksjonene diskutert tidligere. -Struktur -abstrakt/ramme gui (jobbe sammen for å sette felles struktur) -Stringklassen -konkrete gui -Statestikk -Testing (siste uke av perioden) Etter hver bulk er ferdig vil en refactoring av koden utføres. Arbeidsfordeling Prosjektgruppa er en viderføring fra web prosjektet som var forrige semester. Det er et godt samarbeid med en fin fordeling av sterke sider. Alexander Skjolden er prosjektets ekspert på avansert objekt orientert programmering og design patterns. Hans Christian Nenseth er prosjektets ekspert på JavaFX rammeverket. Hans Petter Osvold er prosjektets sekretær og en såkalt jack of all trades som kan fylle flere roller ved behov. Men som vi opplevde under arbeidet med web prosjektet så vil rollene være flytende og samtlige gruppemedlemmer kan utføre hverandres oppgaver. Når det gjelder den konkrete arbeidsfordelingen så gjelder: Implementasjon av datastruktur blir gjort i fellesskap, slik som prosjektoppgaven anbefaler. Det samme gjelder utviklingen av det abstrakte GUI, grafiske bruker grensesnittet. Fordelen med å 13 / 14
gjøre det på denne måten er at det abstrakte GUI vil fungere som en mal når konkret GUI skal implementeres, hvor hvert gruppemedlem vil jobbe med ulike deler av GUI. Når det gjelder utviklingen av ekstra funksjonalitet så vil denne arbeidsfordelingen bli klar ettervert som vi ser at vi har kapasitet til å implementere denne funksjonaliteten og hvilke betingelser tidsbruket setter for oss. Utover dette så vil vi for vår egen del bruke utstrakt unit-testing og dette er noe samtlige gruppemedlemer vil være en del av. For å oppsummere så kommer gruppa til å jobbe en god del i fellesskap, men det er også lagt opp til noe individuelt arbeid. 14 / 14