Vi har i udarbejdelsen af dette afgangsprojekt gjort brug af den objektorienterede systemudviklingsmetode OOSE, som er skabt af Ivar Jacobson4). Begrundelsen for netop at benytte OOSE som udviklingsmetode hænger sammen med vores store erfaring med OOSE, samt at systemet skal implementeres i et objektorienteret sprog, hvilket jo lægger op til brug af en objektorienteret udviklingsmetode. Udover dette så blev der heller ikke stillet noget krav fra Oracle's side om at vi skulle benytte en specifik udviklingsmetode.
Hvorfor overhoved benytte en systemudviklingsmetode, kan man ikke bare skrive sit program direkte ud fra kravene. Nej, det kan simpelthen ikke lade sig gøre, måske hvis det er et meget lille program. Men når man snakker om systemer af en hvis størrelse, så er man nødt til at benytte en eller anden form for systemudviklingsmetode, da det at udvikle sådanne systemer er en meget kompleks opgave. Målet er at få et pålideligt system, der udfører sine opgaver rigtigt.
Systemudvikling er typisk en så kompleks opgave at det ikke kan lade sig gøre at have alle bolde i luften på en gang. Man er derfor nødt til at håndtere kompleksiteten på en eller anden struktureret måde. Det kan man gøre ved at benytte en systemudviklingsmetode, som indeholder forskellige modeller der hver fokusere på forskellige dele af systemet. På denne måde deler man kompleksiteten op i mindre dele, og derved kan man styre hele systemets kompleksitet. OOSE består af fem sådanne modeller, som indgår i OOSE's tre faser:
Intensionerne i OOSE er bl.a at: nedsætte livscyklus omkostninger ifb.m. håndtering af edb-baserede systemer (dvs. gøre vedligeholdelse lettere), give sporbarhed, give indkapsling (dvs. ændringer er så lokale som mulige), give lille semantisk spring (dvs. lille afstand mellem den fysiske verden og den måde vi repræsentere den fysiske verden i en computer), og sørge for at udviklede dele kan genbruges.
I det følgende vil OOSE, dets faser og modeller blive beskrevet.
Analysefasen skal danne grundlag for kravene til systemet, samt give systemet en holdbar/robust objekt struktur der nemt kan ændres. Der bliver lagt vægt på at interagere med brugerne.
Analysefasen indeholder to modeller:
Kravmodellen skal bruges til at afdække de funktionelle krav til systemet, set fra brugerens perspektiv. Denne model udvikles oftest i tæt samarbejde med brugerne. Kravmodellen indeholder tre modeller:
Use-case model bruges til at vise hvad systemet skal kunne overfor brugeren. Er en beskrivelse af hvordan skal vi ved hjælp af edb udfører dit (brugerens) arbejde. Dvs. en beskrivelse af arbejdsprocesser.
Aktører (roller man spiller): hvordan bruger de forskellige aktører systemet.
Domæne Model: er de centraler begreber (objekter/entitetsobjekter) i systemet, ofte navneord, hvordan data gemmes/hvilke data systemet omhandler. Typisk tegne arv (statiske relationer). Om Domæne Modellen skal beskrive/indeholde generelle udsagn om data eller helt ned på primitiv dataform, det kan man diskuterer meget om. Syntaks: OMT(UML syntaks). Sikre at vi taler samme sprog.
Grænseflade model (Mock-up's): Er en tegning af hvordan systemet fremtræder for brugeren. Det er nemmere for brugeren at forstå, end at læse en beskrivelse.
Hvordan kan systemet ideelt modelleres. Laves ud fra den holdning at alt kan lade sig gøre (den ideelle verden). Der er to grunde til dette. For det første er det meget nemmere at arbejde under ideelle forhold: det gør nemlig at man kan minske kompleksiteten og herved rette alle sine kræfter mod at gøre systemets opbygning mere stabilt, robust og logisk. For det andet så vil teknologien, om vi kan lide det eller ej, ændre sig i løbet af systemets levetid, og derfor er det ikke hensigsmæssigt at lade den nuværende teknologi påvirke systemets opbygning. Analysemodellen indeholder to modeller:
ICE model: Usecase-model og Domæne Model inddrages. Hvergang der er en overskridelse af grænsen: lav grænsefladeobjekt (præsenterer systemet for brugeren), kontrolobjekt (kører processen igennem(spilfordeler), styrer usecasen, er primært metodebærende) og entitetsobjekter (databærende). Denne model kaldes også for ICE-modellen (I=interface, C=control, E=entitit)
En klasse består af noget data (entitetsobjekter/modelsiden, det der skal huskes), metoder(grænsefaldeobjektetet) og kroppen (er kontrolobjektet). Det er hele grundlaget for hele objekt teorien, faktisk ICE-modellen.
Udvidet use-case model: Hvis det samme står i to usecase-modeller, slås de sammen, og lav uses-relation, er det der altid skal udføres (eks. login). Hvis der står, hvis dette så gør, eller hvis noget andet så gør dette, så lav extends-relation, det er det der sommetider skal udføres (eks. menu-valg). Det er svært at lave, så derfor laves det kun i interne usecase-beskrivelser (det er ikke fair overfor brugeren, at vise dem dette). Dvs. når de bliver så store.
Det er nu at systemet bliver modelleret ud fra den teknologi det skal konstrureres ud fra.
Konstruktionsfasen indeholder to modeller:
Transformere analysemodel fra ideel verden til teknologisk verden, dvs. til den teknologi systemet skal implementeres i. Analyseobjekter bliver til designblokke (mange objekter).
Transformere designmodel til kildekode i givet programmeringssprog. Fra Domæne Model har vi datasiden af de centrale objekter (entitetsobjekterne). Fra sekvensdiagrammerne har vi klassenavnene og metode hoveder til objekterne, dele af metodekrop i form af pseudokode. Så nu er det bare at kode.
I denne fase skal det udviklede system stå sin prøve, dvs. kan det udføre det som der er opstillet i kravmodellen.
Testfasen indeholder een model:
Testmodellen laves for at verificerer det udviklede system. Indeholder hovedsageligt test specifikationer og test resultater.