LEVERANSEDOKUMENT
INF3120-PROSJEKT: G15

Versjon: Endelig

13.november 2003

Gruppe 15:
MORTEN M. WANG HANSEN
ESPEN URNE
PER THOMAS KRAABØL
CHRISTER MICHAELSEN

INNHOLD

1 Innledning   3
 
2 Reverse engineering   4
2.1 Klassediagram   4
 
3 Design av ny funksjonalitet   5
3.1 Sekvensdiagram   5
3.2 Beskrivelse av sekvensdiagram   10
3.3 Klassediagram   11
3.4 Beskrivelse av klassediagram   12
 
4 Kodegenerering og implementering   13
4.1 Begrunnelse for valg og prioriteringer   13
4.2 Ny programkode   15
4.3 Beskrivelse av ny programkode   15

1. INNLEDNING

1.1 Innledning

Dette dokumentet beskriver programmets nye funksjonalitet med sekvens- og klassediagram samt henvisning til selve programkoden. Dokumentet forklarer også hvilke valg, prioriteringer og forutsetninger vi har måtte gjort for å rekke tidsfristen med en akseptabel løsning.

2. REVERSE ENGINEERING

2.1 Generert klassediagram

Klassediagram generert fra utlevert kode

3. DESIGN AV NY FUNKSJONALITET

3.1 Sekvensdiagram

3.1.1 addToWaitList

addToWaitList

3.1.2 viewWaitList

viewWaitList

3.1.3 modifyWaitList

modifyWaitList

3.1.4 removeFromWaitList

removeFromWaitList

3.1.5 addOperation

addOperation

3.1.6 viewOperation

viewOperation

3.1.7 modifyOperation

modifyOperation

3.1.8 cancelOperation

cancelOperation

3.1.9 checkIn

checkIn

3.1.10 checkOut

checkOut

3.2 Beskrivelse av sekvensdiagram

Vi har lagt oss på et veldig detaljert nivå i sekvensdiagrammene, for å få hjelp i kodinga og forståelsen, og for å distribuere oppgaven innad i gruppa. Vi ønsker også dette for å lette kommunikasjonen med kunden. Hvert sekvensdiagram beskriver ett bestemt juskejs. Alle metodene knyttet til juskejset er med i det tilsvarende sekvensdiagrammet.

3.3 Klassediagram

NyttKlassediagram

3.4 Beskrivelse av klassediagram

Modellen beskriver hvor data er knyttet sammen og i hvilke objekter de forskjellige metodene finnes. I klassediagrammene synes forskjellen på gammel og ny løsning. Serializable-klassen brukes for å lagre data til disk.

4. KODING OG IMPLEMENTERING

4.1 Valg og prioriteringer av ny funksjonalitet

Vi har foretatt en vurdering, og kommet frem til at implementering av følgende funksjonalitet er realistisk:

Dette er valgt fordi funksjonene er fundamentale i forhold til videre utvikling av systemet. 'Schedulering’ er sentralt for funksjonaliteten og både ventelisten og operasjonsobjektene er en forutsetning for denne. Dette vil også gi sykehuset mye av besparelsene som er forventet av systemet.

Vi har sett det som vesentlig at implementasjonen av ny funskjonalitet går lett for brukerne av systemet. Vi har erfaring for at det første inntrykket brukerne får er vesentlig for deres ønske om å ta det til seg. Vi har som mål at brukerne skal kalle systemet 'sitt’. At de får et eierforhold til det, og med det et ønske om at det skal være bra. Implementering av et system som fungerer dårlig skaper en motstand som det senere er meget tungt å overvinne.

Samtidig må vi overholde tidspunktet hvor systemet er ventet. Forsinkelse er en meget synlig mangel som gir skuffelse hos alle innvolverte.

Vi har et greit forhold til oppdragsgiver og får lett aksept for å tilpasse funksjonaliteten slik at vi oppnår:

Funksjonalitet er valgt bort utfra to kriterier:

Dette må sammenholdes med vår vektlegging av problemfri implementasjon. Mest av alt må vi unngå problemer. Vi ønsker et system hvor vi kan bygge 'sten på sten’ til kunden er tilfreds. Unngå revolusjoner, men hele tiden ha en gradvis utvikling og forfining av systemet.

Vi har også hatt en tidsfrist å holde, slik at vi måtte prioritere den funksjonaliteten som vi ville levere, etter avtale med oppdragsgiver.

Vi er godt fornøyd med produktet vi leverer, det er i samsvar med avtalen og vi har gjort riktige prioriteringer med hensyn på funksjonalitet og tilgjengelig tid.

Kundens mål var effektivisering av sykehus driften, og de ønsket en problemfri implementasjon. De vil heller ha en gradvis utvikling av systemet og unngå at brukerne opplever en revolusjon.

Vi har dristet oss til en endring av GUI'en sin layout med bruk av faner for navigering i systemet. Denne endringen vil gi brukere en følelse av at det er 'skjedd noe' uten å gjøre systemet fremmed. Samtidig har vi fått et godt utgangspunkt for den videreutviklingen kunden ønsker.

Vi har sett på mulighet for videreutvikling av løsningen. Som nevnt har vi har endret noe på GUI'en og litt på systemets struktur. (Presentasjon/GUI, kontroll og data) Strukturen var litt utydelig i eksisterende kode. Videre føring av gammelstruktur ville medført merarbeide som kunden ikke ville fått noen umiddelbar gevinst av. Vi vil forklare betydningen av disse endringene, og tilby å lage en bedre struktur om kunden er interessert i det.

Systemet bør utvikles mot en mer detaljert beskrivelse av rollene. Nå finnes Doctor, Nurse og Patient. Alle disse bør kunne defineres finere, f.eks. overvåkningsykepleier, narkosesykepleier osv. Det samme med leger. De bør fremstå mer spesialiserte også i systemet. For pasienter bør det skilles på polikliniske og innlagte.

Rommene bør nok også spesialiseres senere. Sykehuset vil kunne effektivisere sin drift med det.

Vi har foretatt en akseptansetest i samarbeid med kunden der kunden har vært med på utprøving av systemet før endelig leveranse, slik at eventuelle mangler kunne avdekkes og rettes opp ganske umiddelbart.

4.2 Ny programkode

Kildekode og program ligger under ~i3120g15/HSS. Programmet kan startes med kommandoen ’java hss.HSS’. Kommandoen må kjøres i samme katalogen som hss er.

4.3 Beskrivelse av ny programkode

Vi har ikke endret ytterligere mot en god tredelt struktur. (Presentasjon/GUI, kontroll og data) fordi dette ikke var tydelig i eksisterende kode, og ville medført merarbeid som kunden ikke ville fått noen umiddelbar gevinst av. Isteden har vi videreført en todelt struktur med GUI og kontroll slått sammen. Vi vil forklare betydningen av å endre til en tredelt struktur og gjøre disse endringene, om kunden er interessert i det. Vi endret eksisterende eksisterende programstruktur. Det var en delvis trelags som vi opplevde som vanskelig å videreutvikle og litt uoversiktlig. Vi har rendyrket en tolagsstruktur.

Vurderingen av eksisterende kode ledet oss mot å lage store deler av systemet på nytt. Dette syntes riktig da. Eksisterende kode var tung å sette seg inn i og med inkonsistent datastruktur. Det var bl.a. GUI-elementer i kontrollaget. Vi valgte derfor å lage en ny to-lags-arkitektur. Omfanget av dette arbeidet var noe større enn først antatt. Arbeidet har resultert i en bedre GUI mht. videre utvikling.

Vi har ikke kodet ferdig add- og viewOperation. Basis for denne funksjonaliteten skal hentes fra implementert funksjonalitet for WaitList.