Oblig 2 Inf5120 Gruppe 21 Espen Stensund (estensun) Nguyen Tran (nguyent) Hung Huynh (qhhuynh)
Innholdsfortegnelse. Innholdsfortegnelse. 2 Buisness Modell. 3 Visjon. 3 Aktører og interesser. 3 Risikoanalyse. 4 Goal modell. 5 Resurs klassediagram. 6 Process and role modell. 8 Sende timeliste. 9 Oppdater timeliste. 10 Requirements modell. 12 System boundary modell. 12 USE CASE BESKRIVELSE 13 Sub system grouping modell. 14 Use case. 16 Komponent infrastruktur. 21 Architecture modell. 22 Komponent interface. 22 Komponent operasjoner. 23 Timeregistrering Editor. 23 PSM. 25 Teknologi spesifisering. 25 Skjermbilder. 26 Internal design. 28 Sekvensdiagrammer. 29
Buisness Modell. Visjon. Hvorfor skal systemet utvikles? Bedriften ønsker å holde oversikt over hvor ressursene brukes og har derfor besluttet å innføre timeliste. Hver ansatt må da hver uke registrere timene de jobber på de ulike prosjektene som pågår i bedriften slik at man kan holde oversiktet over påløpte timer per prosjekt. Dette vil være enklere og mer tidsbesparende for prosjektleder. Bedriften vil også ha timebudsjett til hver enkel ansatt, slik at prosjektleder eller ledelsen ønsker å se oversikten over ansattes feriedager eller avspaseringer. Aktører og interesser. Ansatt Drift/support Økonomi HRS Prosjektleder Systemutvikler Avdelingsleder Kunder Adm./ledelse Figur 1. Omfanget av HRS.
Stakeholder Ansatte Økonomi Prosjektleder Avdelingsleder Adm./ledelse Kunder Systemutvikler Drift/support Beskrivelse Hovedbruker av systemet. Skal registrere timeforbruket sitt. Bruker systemet for å finne ferie og avspaseringsdager for hvert enkelt ansatt, og beregner lønn etter det. Lettere for ham å holde oversikt over prosjektet. Han kan enkelt finne ut hvor mye prosjektet har kostet. Ansvar for å tildele prosjekter og bestemmer budsjettet for denne. Ønsker at bedriften tjener på systemet. Ønsker at bedriften tjener på systemet. Ønsker at prosjektene koster mindre og blir fortere ferdig. Ønsker at systemet skal tilfredsstille oppdragsgiver og at systemet er lett å oppgradere og modifisere. Skal sørge for den daglige driften og brukersupport. Risikoanalyse. Nedenfor har vi listet opp de viktigste farene og kommentarene med systemet. Dette er langt i fra en komplett liste. Dette er kun ment som en pekepinn for ting som vi må være obs på. En komplett liste vil også inneholde run-time scenario, risikograd og omfang. Dessuten burde det inneholde eventuelle tiltak. Vi har valgt å ikke ta med en komplett liste ennå, fordi vi mener at den først kan lages når vi har kommet lenger ut i utviklingsfasen. Det er da vi kan virkelig se potensielle farer og feller. Risiko System blir ikke levert innen tidsfristen. Systemet har lav ytelse. Sikkerhet. Teknologi endres Antall brukere økes. Virus Systemet blir hacket. Kommentar Systemet må være klar innen tidsfristen for å få maksimalt betalt. Det stilles ingen strenge krav på ytelsen utover normal bruk. Systemet skal inneholde info som berører den enkeltes feriedager og avspaseringer. Viktig at backup blir foretatt på en skikkelig måte. Systemet har ingen krav om å bruke det nyeste innen teknologi. Systemet bygges på klient-tjener prinsipp og skal kunne håndtere mange brukere. Systemet har ingen direkte kontakt med omverden. Gode backup og sikkerhetsrutiner er nødvendige. Systemet har ingen direkte kontakt med omverden. Gode backup og sikkerhetsrutiner er nødvendige.
Goal modell. Tjene mer penger Bedre allokering av resurser Bedre oversikt over ferie og avspasering. Registrere resursforbruk Registrere timeforbruk Holde prosjekt til budsjett Figur 2. De viktigste målene. Ovenfor ser vi de viktigste målene for stakeholdere i forhold til HRS. Målene Registrere timeforbruk, Holde prosjekt til budsjett og Bedre oversikt over ferie og avspasering er nettopp motivasjonen for å opprette HRS. Vi ser her hvordan de underbygger det øverste må for bedriften.
Tjene mer Bedre allokering av resurser. Bedre oversikt over ferie og avspaseringer. Registrere all timeforbruk. Registrere resursforbruk. Registrere all timeforbruk. Holde prosjektet til budsjett. All vil ha mer penger, eller opprettholde dagens nivå. For å unngå svinn og ineffektivt organisering. Prosjektene blir fortere ferdig og dermed mer tid til å jobbe med andre prosjekt. Dagens rutine er rotete og holder ikke mål. Lettere å holde oversikt over resurser. Prosjektleder kan lett se om prosjektet snart overstrider budsjettet. Unngå svinn og ineffektivitet. Lettere å holde oversikt over resurser. Prosjektleder kan lett se om prosjektet snart overstrider budsjettet. Hjelper til å holde utgiftene nede. Resurs klassediagram. 1..1 Ferieplan Timeliste 1..* 1..* 1..1 1..1 Ansatt 1..1 1..1 Avspaserings plan 1..1 0..* Styringsplan 1..1 1..1 Prosjekt Figur 3. Resurs diagram.
Nedenfor har vi beskrevet resursene. Resurs Kommentar Ansatt Dette er en direkte mapping av den virkelige ansatt i bedriften. Han er hovedbruker av systemet. Avspaseringsplan Forteller om hvor mange timer ansatt har til gode. Det gies ikke overtid i bedriften. Ferieplan Forteller om hvor mange dager ansatt har opptjent til nå. Timeliste Ansatt har en timeliste for hvert prosjekt han er involvert i. Styringsplan Forteller mange timer som prosjektet er beregnet til å ta og hvor mange som er faktisk brukt til nå. Prosjekt Representerer et oppdrag som bedriften har. Forteller også hvem som er involvert.
Process and role modell. Lag timeliste [Ikke godkjent] Send timeliste [Stop] Oppdater timeliste Figur 4. Prosess overblikk for timeregistrering. Lag timeliste: subprosessen beskriver rutinen for å lage en timeliste. Send timeliste: subprosessen beskriver rutinen for å få godkjent timelisten og for sende den inn til systemet for oppdatering. Oppdater timeliste: subprosessen beskriver hvordan systemet oppdaterer timelisten.
Sende timeliste. Ansatte Prosjektleder Manuelt Send til prosjektleder Timeliste Godkjenne timeliste Lag timeliste [ Ikke godkjent ] Send til system for oppdatering Godkjent timeliste Figur 5. Subprosessen "Send timeliste". Aktivitet Send til prosjektleder Kommentar Timelistene for hver enkelt ansatt må være godkjent av prosjektleder. Hindrer at noen tilegner seg urettmessige goder på grunn av feil i timelistene. Godkjenne timeliste Prosjektleder har ansvaret for at timelistene er riktig utført og ført timeforbruk stemmer med faktiske timeforbruk. Send til system for oppdatering Systemet skal ha listene for å oppdatere sine informasjon.
Oppdater timeliste. Timelistehåndterer Feriehåndterer Avspaseringhåndterer Oppdatere timeliste Oppdatere prosjektplan Feriedager Oppdatere feriedager Avspaseringer Oppdatere avspasering Figur 6. Subprosessen "Oppdater timeliste".
Aktivitet Oppdatere timeliste Oppdater prosjektplan Oppdatere feriedager Oppdatere avspasering Kommentar Hver ansatt er pliktet til å rapportere inn oversikt over timeforbruk etter endt uke. En ansatt har en timeliste for hvert enkelt prosjekt som han er involvert i. Timelistene må være godkjent av prosjektleder før de blir lagret. Timelisten til den enkelte ansatt vil øke det totale timeforbruket for det aktuelle prosjektet. Det totale timeforbruk for et prosjekt er summen av timelistene til alle som er involvert i prosjektet. Prosjektleder kan hele tiden følge med utviklingen av prosjektet m.h.t. økonomi og tidsforbruk. Den samlede sum av alle timelister til en ansatt bestemmer hvor mye ferie han har rett til. Normalt vil alle heltidsansatte få maksimalt med feriedager i henhold til norsk lov. Deltidsansatte eller andre ansatte som av andre grunner ikke arbeider fullt, vil få beregnet feriedager og feriepenger ettersom hvor mye de har jobbet. Timelistene skal stå som grunnlag for disse beregningene. En arbeidsuke består av 37.5 timers betalt arbeidstid. Timeforbruk utover dette blir ikke regnet som overtid, men den ansatte skal avspasere.
Requirements modell. System boundary modell. 1 Registrere timer include 2 Oppdater timeliste Ansatt include include 3 Oppdatere feriedager 4 Oppdater avspasering Oppdateringsserver 5 Nytt Prosjekt 6 Endre Prosjekt 11 Vis Rapport feriedager Prosjekt leder 7 Avslutt Prosjekt 12 Vis Rapport avspasering Ledelse/ Økonomi 8 Vis Styringsplan 13 Ny bruker 9 Oppdater Styringsplan 14 Endre bruker 10 Vis Status rap for prosjekt 15 Slette bruker Drift Figur 7. Overordnet use case diagram.
USE CASE BESKRIVELSE Nedenfor har vi oppsummert alle use casene. Navn Beskrivelse Aktører 1. Registrere time Ansatt fører antall timer Ansatt, prosjektleder. brukt på forskjellige prosjekter 2. Oppdatere timeliste Timelisten blir oppdatert Oppdateringsserver etter godkjenning av prosjektleder 3. Oppdatere feriedager Sørger for at den ansatte har riktig antall feriedager Oppdateringsserver, ansatt, prosjektleder 4. Oppdatere avspaseringsdag Sørger for at den ansatte har riktig antall Oppdateringsserver, ansatt, prosjektleder avspaseringsdager 5. Ny prosjekt Et nytt prosjekt blir Prosjektleder opprettet 6. Endre prosjekt Prosjektleder ønsker å gjøre Prosjektleder endringer på prosjektet 7. Avslutt prosjekt Et prosjekt er ferdig eller Prosjektleder blir avbrutt 8. Vis styringsplan Styringsplanen viser antall Prosjektleder, ledelsen timer som har blitt brukt på prosjektet 9. Oppdatere styringsplan Sørger for at styringsplanen Prosjektleder, ledelsen blir oppdatert 10. Vis statusrapport for Muligheten for å se på Prosjektleder, ledelsen prosjekt nøkkel tall for prosjektet 11. Vis rapport feriedager Rapport som viser oversikt Ansatt, prosjektleder, 12. Vis rapport avspaseringsdager over feriedager til gode Rapport som viser oversikt over avspaseringsdager til gode 13. Ny bruker Bedriften ansetter en ny person 14. Endre bruker Sørge for å kunne endre data på de ansatte 15. Slette bruker Kunne fjerne en ansatt fra systemet ledelsen Ansatt, prosjektleder, ledelsen Drift Drift Drift
Sub system grouping modell. Subsystemgrupering. TimelisteEditor LokaloppdateringService 1 Registrere timer include 2 Oppdater timeliste Ansatt ProsjektstyringEditor include include 3 Oppdatere feriedager 4 Oppdater avspasering Oppdatering server 5 Nytt Prosjekt Avspasering og ferieviewer 6 Endre Prosjekt 11 Vis Rapport feriedager Prosjekt leder 7 Avslutt Prosjekt 12 Vis Rapport avspasering Ledelse/ Økonomi 8 Vis Styringsplan BrukerEditor 9 Oppdater Styringsplan 13 Ny bruker 10 Vis Status rap for prosjekt 14 Endre bruker 15 Slette bruker Drift Figur 8. Subsystemer. TimeregisterEditor.
TimeregisterEditoren er ett tool-komponent og det er brukt av de ansatte. Denne komponenten inneholder bare en use case, registrere timer. Her vil den ansatte registrere timene som han har jobbet på et prosjekt. LokaloppdateringServices. LokaloppdateringServices er en business-service komponent som implementerer server siden av timeregistereditoren. Den inneholder tre use cases, oppdatere timeliste for styringsplan, oppdatere ferie til gode og oppdatere avspasering. ProsjektstyringEditor. ProsjektstyringEditoren er ett tool-komponent og der brukes hovedsakelig av prosjektlederen, men også litt av ledelsen. ProsjektstyringEditoren brukes for å styre et prosjekt. Den inneholder 6 use cases, opprette prosjekt, endre prosjekt, avslutte prosjekt, vise styringsplan, oppdatere styringsplan og vis status rap for prosjekt. Alle oppdateringer og lagringer av informasjon om prosjektene skjer her. Avspasering og ferieviewer Avspasering og ferievieweren er ett tool-kompoent som brukes av den ansatte, prosjektleder og økonomiberta. Denne inneholder to use cases vis rapport feriedager og vis rapport avspasering. Denne innholder ingen funksjonalitet kun for innsyn. BrukerEditor. BrukerEditoren er en business-service-component som blir brukt av drift. Den inneholder tre use cases ny bruker, endre bruker og slette bruker.
Use case. 1 Registre timer Ansatt Figur 9. Subsystem: TimelisteEditor. Use case 1 Registrere time Prioritet 1 Mål Registrer timer som den ansatte har jobbet på et prosjekt Aktører Ansatt Pre-betingelser Ansatt må ha jobbet på et prosjekt Post-betingelser Timene den ansatte har jobbet på prosjektet blir sendt til prosjektleder Senario Ansatte registrer timer etter endt uke Beskrivelse: 1 Ansatte velger prosjektet han ønsker å registrere timer på. 2 Fyller ut timer han har jobbet den uken. 3 Sender timelisten til prosjektleder. Variasjoner: 1.1a Ansatte er ikke registrert på et prosjekt. Får ikke reg. timer. 1.1b Ansatte må kontakte prosjektleder for prosjektet. 3.1a Får ikke sendt på grunn av feil på nettet. Prøve igjen senere.
2 Oppdater timeliste 3 Oppdatere feriedager 4 Oppdater avspasering Oppdateringsserver Figur 10. Subsystem: LokaleoppdateringerService. Use case 2 Oppdatere timeliste Prioritet 1 Mål Registrer timer som den ansatte har jobbet på et prosjekt Aktører Oppdateringsserver Pre-betingelser Prosjekt leder må ha godkjent timelisten Post-betingelser Timene den ansatte har jobbet på prosjektet blir registrert Senario Oppdaterer timelisten til den ansatte Beskrivelse: 1 Systemet oppdaterer timelisten til den ansatte Variasjoner: 1.1a Systemet er nede. 1.1b Må oppdatere senere.
5 Nytt Prosjekt 6 Endre Prosjekt 10 Vis Status rap for prosjekt Prosjekt leder 8 Vis Styringsplan 7 Avslutt Prosjekt 9 Oppdater Styringsplan Figur 9. Subsystem: ProsjektstyringEditor. Use case 5 Nytt prosjekt Prioritet 1 Mål Opprette et nytt prosjekt Aktører Prosjektleder Pre-betingelser Prosjektleder har fått et prosjekt fra ledelsen Post-betingelser Prosjektet vil bli opprettet Senario Prosjektleder oppretter det nye prosjektet Beskrivelse: 1 Prosjektleder gir prosjektet et unikt navn som er allerede tildelt. 2 Registrerer informasjon som han har fått fra ledelsen. 3 Melder ansatte inn i prosjektet 4 Oppretter prosjektet Variasjoner: Use case 6 1.1a Prosjektet finnes fra før. 2.1a Mangler info for å opprette prosjektet. 3.1a Finner ikke ansatte i basen. 4.1a Mangler informasjon 4.1b Systemet gir beskjed om hva som er galt. Endre prosjekt
Prioritet 1 Mål Endre data for et prosjekt Aktører Prosjektleder Pre-betingelser Prosjektleder ønsker å endre data for et prosjekt Post-betingelser Prosjektet vil bli endret Senario Prosjektleder endrer dataen han ønsker. Beskrivelse: 1 Prosjektleder søker/velger prosjektet han ønsker å forandre. 2 Prosjektlederen får opp informasjon om prosjektet. 3 Han gjør de endringene han ønsker. 4 Lagrer Variasjoner: 1.1a Finner ikke prosjektet. 3.1a Finner ikke ansatt som prosjektleder vil melde på prosjektet. 4.1a Disken er full 4.2a Får ikke lagret pågrunn av tekniske ting. 11 Vis Rapport feriedager 12 Vis Rapport avspasering Ledelse/ Økonomi Figur 10. Subsystem: Avspasering og ferie Viewer. Use case 11 Vis rapport feriedager Prioritet 1 Mål Vise rapport over feriedager Aktører Leder/økonomi, prosjektleder, ansatt Pre-betingelser Ansatte har jobbet med et eller feler prosjekter Post-betingelser Vise ansattes feriedager Senario Aktøren ønsker info om feriedager tilgode Beskrivelse: 1 Aktør skriver in ønsket navn 2 Systemet viser antall feriedager den ansatte har tilgode. Variasjoner: 2.1a Ansatt har ikke jobbet nok til å få feriedager.
13 Ny bruker 14 Endre bruker 15 Slette bruker Drift Figur 11. Subsystem: BrukerEditor. Use case 13 Ny bruker Prioritet 1 Mål Registrere ny bruker Aktører Drift Pre-betingelser Ansatt har ikke tilgang til systemet. Post-betingelser Ny ansatt er lagret i basen Senario Bedriften tar inn en ny ansatt Beskrivelse: 1 Drift registrer in data fra bruker 2 Generer passord til brukeren 3 Legger ny bruker til databasen 4 Lagrer Variasjoner: 1.1a Bruker mangler viktige punkter
Komponent infrastruktur. Timeregistrering Avspasering og ferie Prosjektstyring Bruker adm. Komponent infrastruktur BrukerAdm service Oppdatering service BrukerInfo TimeListeInfo Figur 12. Komponent spesifisering. Systemet vårt bygger på klient-tjener prinsippet. Som vist ovenfor er Timeregistrering, Avspasering og ferie, Prosjektstyring og Bruker Adm ment for klientsiden. Forbindelsen vil skje via lokal nettverk.
Architecture modell. Komponent interface. Diagrammet nedenfor beskriver den interne infrastruktur for HRS. Bruker Editor Timeregistrering Editor Avspasering og ferie Viewer Prosjektstyring Editor IBrukerAdmService IOppdateringService BrukerAdmService OppdateringService IBrukerInfo ITimeListeInfo BrukerInfo TimeListeInfo Figur 13. Komponent struktur. Komponentene BrukerEditor, BrukerAdmService og BrukerInfo og interfacene IBrukerAdmService og IBrukerInfo blir beskrevet ytterligere i senere kapitel.
Komponent operasjoner. IBrukerAdmService + newuser (UserInfo: info) : Boolean + edituser (UserInfo: info ) : Boolean + deleteuser (UserInfo: info) : Boolean + getuserinfo (UserNavn: String) : Boolean IOppdateringService + regtime (Prosjekt: String, anttime: Int) : Boolean + showvacation() : String + showfreedays() : String + visstyringsplan (Prosjektnavn: String) : Prosjekt + editplan ( Prosjektnavn: String, Plan: String) : Boolean + avsluttprosjekt (Prosjektnavn: String): Boolean + newprosjekt(prosjektnavn: String): Boolean + editprosjekt(prosjektnavn: String, Prosjekt: String) : Boolean Timeregistrering Editor. Nedenfor beskrives den interne oppbyggingen av TimeregistreringEditor. Timeregistrering UI TimeregistreringUS ITimeregistrering TilstandsInfo ITilstandsInfo Figur 16. Timeregistrering komponent struktur.
ITimeregistrering + setprojectfocus() : void + setregistrationfocus() : void + setperiodfocus() : void + submitregistration( RegistrationInfo: String) : boolean + selectproject(projectname: String): boolean + selectperiod(period: String) : boolean
PSM. Teknologi spesifisering. Vi vil her klargjøre for hvilke teknologi vi har tenkt for hvert enkelt komponent. Det bygges hovedsakelig rundt Java og HTML. Bruker Editor Timeregistrering Editor Avspasering og ferie Viewer Prosjektstyring Editor IBrukerAdmService IOppdateringService BrukerAdmService OppdateringService IBrukerInfo ITimeListeInfo BrukerInfo TimeListeInfo Figur 17 Komponent struktur for HRS. Komponent Interface Kommentar BrukerEditor Skal bli implementert som Java Server Page (JSP). Klientsiden vil bare trenge en vanlig webbrowser. Denne delen av systemet vil bli beskyttet v.h.a. ny innlogging. Bare drift og support som kan opprette/endre/slette en bruker. Timeregistrering Skal bli implementert JSP. Editor Avspasering og ferie Viewer Skal bli implementert i ren html.
Prosjektstyring Editor BrukerAdmService OppdateringService BrukerInfo TimeListeInfo Skal bli implementert i JSP. IBrukerAdmService Skal bli implementert i Servlet tunneling framwork. IOppdateringService Skal bli implementert i Servlet tunneling framwork. Skal bli implementert som en Java server med Java Servlet. Skal bli implementert som en Java server med Java Servlet. IBrukerInfo Skal bli implementert v.h.a. JDBC. ITimeListeInfo Skal bli implementert v.h.a. JDBC. Skal bli implementert av MySQL. Skal bli implementert av MySQL. Skjermbilder. Figur 14. Registrere time skjermbilde.
Registrere timer. I dette skjermbilde vil brukere kunne gjøre fem ting, velge prosjekt, velge periode, registrere timer, sende timelisten eller avbryte. Det vil bli lastet inn en drop-down meny over alle prosjektene den ansatte er deltaker av. Her kan han velge hvilket prosjekt han ønsker å registrere timer på. I periode feltet vil det komme automatisk opp inneværende periode det skal registreres timer for, men her vil også brukeren kunne velge fritt hvilken uke han vil registrere timer for. Det eneste den ansatte trenger å skrive inn er antall timer han har jobbet, dag og dato vil komme automatisk opp. Hvis ikke brukeren fyller inn noen timer for en dag vil timeantallet bli satt til 0. Brukeren kan avbryte eller sende skjema når han vil. Figur 15. Ny bruker skjermbilde. Ny bruker. I dette skjermbilde må drift registrere informasjon om brukeren. Det vil være obligatorisk å fylle ut alle feltene. Brukeren vil få en feilmelding hvis ikke alt er fylt ut. Passordet må gjentas for å være sikker på at det ikke er noen skrivefeil.
Internal design. BrukerEditor (UI) [ Frame ] LoginDialog [ Frame ] NewUserDialog [ Frame ] EditUserDialog [ Frame ] DeleteUserDialog [ Focus ] EditorManager IBrukerAdmService BrukerAdmService [ Auxiliary] NewUserSQL [ Auxiliary] DeleteUserSQL [ Auxiliary] GetUserSQL [ Auxiliary] EditUserSQL [ Focus ] ServiceManager [ Entity] JDBC-manager IBrukerInfo BrukerInfo [ Entity ] Password 1..1 1..1 [ Focus] InfoManager [ Entity ] PersonalInfo 1..1 1..1 [ Entity ] User 1..* Figur 20. Intern struktur for bruker administrasjonsdelen av systemet.
Sekvensdiagrammer. Use Case 1. i()ansatt Timeregistrering kontrollerer Timelistekontroller Timeliste Starter systemet Hente timelister Hente timelister Generer timelister {velger prosjekt} Vis timeliste {fyller inn timer} Sender timeliste {avslutter} Figur 21. Use Case: Timeregistreing.
Use case2 {Mottar timelise} Oppdatering server Starter oppdateringen Oppdaterings kontroller Oppdaterer Oppdatere timeliste for styreplan Oppdatere ferie tilgode Oppdatere avspasering tilgode Oppdaterer Oppdaterer Figur 22. Use Case: Oppdatere timeliste.
Use case 5 Prosjektleder Prosjektkontroller Prosjekt Styringsplan Ansatt {Mottar prosjekt informasjon} Starter reg. av nytt prosjekt Taster inn informasjon om prosjektet Oppretter nytt prosjekt Registrerer info Registrer info Oppretter Styrings plan Registrerer prosjektmedlemmer Figur 23. Use Case: Nytt prosjekt.
Use case 6 Prosjektleder Prosjektkontroller Prosjekt Ansatt {Ønsker slette ansatt fra prosjekt} Finner prosjektet Henter inn info om prosjektet Sletter valgt ansatt fra prosjektet Sletter timeliste Figur 24. Use Case: Endre prosjekt.
Use Case 11 Aktør Feriedager til gode kontroller Ansatt Ferieplan {Ønsker info om feriedager tilgode} Taster inn ansattes navn Finner ansatt Hent plan Figur 25. Use Case: Vise rapport feriedager.
Use case 13 Drift Bruker kontroller Databasen {Ønsker å legge til ny bruker} Taster inn data Lagrer bruker Sjekk om bruker finnes fra før Figur 16. User Case: Ny bruker.