Obligatorisk oppgave 2 INF 5120 Modellering med objekter våren 2004

Transkript

1 Obligatorisk oppgave 2 INF 5120 Modellering med objekter våren 2004 Gruppe 4: Cathrine Holten Hanne Kristin Thorsen Helene Frenning Hansen Ingrid Morterud Rosvall

2 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side 1 Innholdsfortegnelse 1 Innledning Business modell Forutsetninger Context statement Scope og kontekst Overordnet virksomhetsprosess Goal Model Business Resource Model Business Process & Role Model Overordnet Business Process Model Administrer prosjekt Administrer timer Requirements Model System Boundary Model Overordnet System Boundary Model Detaljert System Boundary Model Subsystem Grouping Model Use Case beskrivelser UseCase 3. Administrere timer UseCase 15, Hent timer UseCase 16, Oppdater timer Reference Architecture Analysis Model/Component Identification Use Case Scenario Modeller Sekvensdiagram for Use Case 3, Administrere Timer, normal flyt Sekvensdiagram for Use Case 15, Hent Timer, normalflyt Sekvensdiagram for Use Case 16, Oppdater timer, normalflyt Architecture model Component structure Application component structure med detaljering Interface & interaction spesification Grensesnitt beskrivelse Komponent/klasse diagram Grensesnitt beskrivelse QoS Internal design BCE analyse BCE mapping til klasser Intern klassedesign Platform Specific Model Component Implementation Model Deployment Model Notasjoner som er brukt Vedlegg... i 1.1 Vedlegg 1 Use Case beskrivelser... i UseCase 1. Log In... i UseCase 4 Administrere fri... ii Use Case 9, Justere prosjektbudsjett... v UseCase 12 Godkjenn timelister... vii UseCase 13. Se Rapport... viii Use Case 14 Verifiser bruker Include Use Case... ix Use Case 17 Lag rapport Include Use case... xi UseCase 18. Log Out... xii

3 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side 2 1 Innledning Dette er en besvarelse av obligatorisk oppgave 2, INF Oppgaven består i å utvikle en modellbeskrivelse i henhold til COMET-metodikken for et timeregistreringssystem i en bedrift. COMET-metodikken foreskriver utarbeidelse av Business Modell, Requirements Modell, Architecture Model og Platform Specific Model. Det er gitt i oppgaven hvilke elementer av de ulike modellene som skal tas med. (Vi har i tillegg foretatt egne utvalg underveis, begrunnelser for dette er beskrevet under de punktene det gjelder). Problembeskrivelsen gitt i oppgaven er lite utdypende om konteksten for timeregistreringssystemet, som hvilken type bedrift systemet skal være for, systemets aktører og hvilke andre systemer det eventuelt er tenkt å knyttes mot. Vi har derfor modellert et generisk system, med begrenset informasjon om kontekst, som skal kunne brukes av en hvilken som helst bedrift. Av modelleringsverktøy har vi benyttet OptimalJ, Rational Rose og Tau_UML, etter hva de ulike gruppemedlemmene har hatt tilgang på. Dermed er det ikke helt konistent bruk av notasjon/symboler i de ulike modellene, men vi har forsøkt å gi tilleggsforklaringer der dette er nødvendig. Business og Requirements Modelling er gjort i henhold til COMET 2.3, mens Architecture Model og Platform Specific Model er gjort i henhold til COMET 2.4. Dette skyldes at COMET 2.4 ble lagt ut etter at vi hadde påbegynt obligen. Vi har tatt en del forutsetninger, disse er beskrevet i punkt 2.1. Vi har beskrevet hele systemet frem til og med Use Case beskrivelser for Use Casene i Subsystem Grouping Model. Derfra har vi valgt å detaljere kun de mest sentrale Use Casene ned til implementasjon. I Requirements modellen er det derfor gitt Use Case beskrivelser kun for de Use Casene det er valgt å modellere videre, mens de øvrige Use Case beskrivelsene er tatt med i vedlegg 1. Use Case beskrivelsene i vedlegg 1 er ikke oppdatert i forhold til den videre modelleringen av de mest sentrale Use Casene. De fungerer dermed bare som en dokumentasjon på prosessen, og vil måtte oppdateres ved videre arbeid med systemet. Notasjons forklaringer er gitt bakerst i oppgaven, punkt 5.

4 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side 3 2 Business modell Business modellen skal vise hvordan systemet skal fungere (dets rolle) i konteksten gitt av virksomheten som skal finansiere og bruke systemet. En Business Modell i henhold til COMET inneholder Scoping Statements o Context Statement o Vision for change o Risk Analysis Goal Model Community Model o Business Process and Role Model o Business Resource Model o Work Analysis Refinement Modelling (WARM) I denne oppgaven har vi utarbeidet et Context Statement i form av et overordnet Use Case diagram som viser aktører og interesser (2.2.1), og et aktivitetsdiagram som viser de overordnete virksomhetsprosessene (2.2.1). Vision for change, som blant annet skal vise refleksjon over hvilke visjoner som ligger bak utviklingen av systemet og hvilke målsetninger systemet skal bidra til å oppnå, og en produktbeskrivelse med teknisk virksomhets visjon er utelatt da dette ikke er gitt i oppgaven. Det samme gjelder risikoanalyse, som identifiserer virksomhets og tekniske risiki relatert til et utviklingsprosjekt for det planlagte systemet. Begge elementer ville vært viktige å ta med i en komplett modellering. De øvrige elementene Goal Model (2.3), Community Model ( ), Business Resource Model (2.4) og Business Process and Role Model (2.5), hvorav sistnevnte er videre detaljert ved WARM-analyse, er modellert i henhold til Comet Version Forutsetninger Følgende forutsetninger ble tatt for å avgrense de delene av systemet og virksomheten vi ønsker å se på Det er ingen eksterne interessenter (utenfor virksomheten) o Dette kunne vært for eksempel Arbeidstilsynet eller fagforening TR forholder seg ikke til hvor de ansatte er når. Dvs det er ikke et system for å finne de ansatte når noen skal ha tak i dem. De ansatte registrerer timer i etterkant, det er foreløpig ikke fastsatt regler for hvor lenge i etterkant dette kan/må gjøres. TR er ikke designet som en prosjektplanlegger, med budsjett og prosjektstyring o Prosjektplanlegger kan være en mulig utvidelse

5 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side 4 TR er altså et avansert stemplingsur Man kan ikke registrere timer for andre ansatte o Dette kunne vært en mulig utvidelse, der for eksempel melding ble gitt til den ansatte som det ble registrert for. Det registreres timer som kun tilhører prosjekter. Kompetanse for de ansatte har vi ikke tatt med, selv om det hadde vært bra for administrering av prosjekter Budsjetterte timer i systemet gjelder per prosjekt, og ikke per ansatt. Dette kan være en mulig utvidelse ved videre utvikling av systemet. 2.2 Context statement Context statement er en del av Scoping statement, og definerer scopet og posisjonerer business modellen i sin kontekst. Scopet er den del av virksomheten som er av interesse for aktørene og som har betydning for krav til produktet eller dets karakteristikker. Context statement er her visualisert ved Use Case diagram for scope og kontekst (2.2.1) og aktivitetsdiagram for overordnede virksomhetsprosesser (2.2.2) Scope og kontekst Use Case diagrammet nedenfor viser brukere og interessehavere med roller og behov i forhold til systemet.

6 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Overordnet virksomhetsprosess Aktivitetsdiagrammet nedenfor viser hovedprosessene i bedriften hvor dette timeregistrerings-systemet skal brukes. Timeregistreringssystemet skal støtte timebehandling for prosjektdeltakere og personal og generering av informasjonsdokumenter i form av rapporter, til bruk ved lønnsberegning, statistikkbehandling og projektbudsjettering ved henholdsvis aktørene regnsskap/lønn, ledelse og prosjektledelse. Rapporter i denne modellen er vist med notatboks, men representerer egentlig en artefakt i form av informasjonsflyt mellom aktivitene, en ObjectFlowState stereotypet Resource as artefact. Tau_UML har ikke noe symbol for slike informasjonsdokumenter. Prosjektdeltakere og Personal Regnskap/Lønn Ledelse Prosjektledelse Timebehandling Rapporter Beregne Lønn Behandle Statistikk Planlegge Prosjektbudsjett

7 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Goal Model Scoping statement består som nevnt overfor også av et målhierarki, som beskriver hvordan det planlagte timeregistreringssystemet er forankret opp til bedriftens virksomhetsmål. Gjennom dette målhierarkiet kommer det frem hvor stakeholdernes interesser er adressert, og det skal reflektere nytten av timeregistreringssystemet. Målsetningene bør ideelt sett være målbare for fremtidig evaluering. God oversikt over ressurser Kontroll med prosjekt tid Nøyaktige timelister Oversikt over overtid og ferie Lette personlig arbeidstids planlegging Lett tilgang til historikk Enkel og effektiv timeregistrering Følge AML Unngå utbrenthet

8 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Business Resource Model Business Resource modellen er en informasjonsmodell som identifiserer og definerer hovedelementer og konsepter i domenet som er relevante for timeregistreringssystemet. Da det som nevnt tidligere er valgt å ikke utdype kontekst i særlig større grad enn det som er gitt i problembeskrivelsen er denne modellen relativt enkel. ProsjektOversikt * 1 Kunde 1 FerieOversikt Rapporter * * 1 1 * TimeOversikt Ansatt 1 1 * 1 Kapasitet * 1 Avdeling Name Kunde ProsjektOversikt TimeOversikt Rapporter Ansatt Avdeling Kapasitet FerieOversikt Description Kunder som skal faktureres for prosjekttimer Et sett med timeregistreringer Timeregistreringer pr. ansatt pr. prosjekt Ulike oversikter, benyttes til å beregne lønn, avspasering, til fakturering og til andre statistikker Den enkelte ansatte som faktisk registrerer timer/benytter tid Ansattes tilhørighet. Får lønn og oppdrag via avdeling. Avdeling fakturerer prosjekt for benyttet arbeidstid pr. ansatt Ressurser den ansatte besitter, tid(heltid/deltid/timer pr. uke), kompetanse m.m. Ferieregistrering pr. ansatt

9 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Business Process & Role Model Overordnet Business Process Model

10 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Administrer prosjekt Prosjektoversikt i denne modellen er vist med en svart boks, men representerer en ressursartefakt i form av informasjonsflyt mellom aktivitene, en ObjectFlowState stereotypet Resource as artefact. OptimalJ har ikke støtte for denne notasjonen. En mangel ved denne modellen er at det burdte vært et informasjonsobjekt/ressursartefakt ( Resource as artefact ) også på flyten mellom human stepe ene Vurdere prosjekter1 (ansatte vurderer) og Vurdere prosjekter2 (ledelse vurderer), og tilbake fra disse til diamanten før toolstep Justere prosjekt.

11 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Administrer timer

12 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side 11 3 Requirements Model 3.1 System Boundary Model Overordnet System Boundary Model

13 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Detaljert System Boundary Model

14 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Subsystem Grouping Model I denne modellen er UserInfo og TimeInfo eksterne DBMS som er med som eksterne aktører. Vi tenker oss at det er disse som tar seg av lagringen av alle data fra timeregistreringssystemet.

15 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Use Case beskrivelser Her tar vi bare med Use Case beskrivelser vi syns er viktige for de Use Casene vi detaljerer videre i rapporten, dvs. for TimeEditor og TimeService. Dette er Use Casene 3. Administrer timer, 15. Hent Timer og 16. Oppdater timer. Som nevnt overfor er beskrivelser for de øvrige Use Casene i Subsystem Grouping Model lagt med som vedlegg (Vedlegg 1), men disse er ikke oppdatert i henhold til den videre modelleringen som følger i oppgaven UseCase 3. Administrere timer UseCase 3 UseCase Administrere timer, normal flyt Priority 1 Mål Registrere/endre timer på prosjekter Aktører Ansatt Pre-conditions Ansatt må være logget på Prosjektene må være opprettet Postconditions Time database skal være korrekt oppdatert med timer på riktig prosjekt og ansatt. Kvalitets krav - Scenario Ansatt er i TimeEditor 1 UC15 Hent timer, normalflyt utføres 2 Systemet viser alle timer den innloggede ansatte har jobbet siste måned fordelt på prosjekter. 3 Hent alle gyldige prosjekter 4 Systemet viser alle prosjekter med navn og prosjektnummer 5 Bruker velger prosjekt å føre timer på 6 Bruker registerer hvilken dato det er jobbet 7 Bruker registerer antall timer som er jobbet på det aktuelle prosjektet den aktuelle datoen 8 UC 16 Oppdater timer, normalflyt utføres med den registrerte informasjonen Dette scenariet er ikke iterert ettersom vi har valgt å la dette være funksjonalitet som kommer i en senere versjon av systemet. UseCase 3 UseCase Administrere timer, alternativ scenario1 Priority 1 Mål Registrere/endre timer på prosjekter for annen ansatt Aktører Ansatt Preconditions Ansatt må være logget på Prosjektene må være opprettet Postconditions Time database skal være korrekt oppdatert Kvalitets - krav Scenario Ansatt er i TimeEditor

16 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side 15 1 Velg prosjekt og ansatt å føre timer på 2 Ansatt registrerer timer for prosjektet i perioden som har gått for en annen ansatt 3 Timene blir registrert i timedatabasen 4 Varsel sendes ansatt som har fått registrert timer på seg UseCase 15, Hent timer UseCase 15 Hent timer, normalflyt Priority 1 Mål Alle timer som en ansatt har jobbet siste måned skal hentes med hvilket prosjekt timene er ført på Aktører TimeInfo-database Preconditions UC 3 eller 4 er under utførelse Databasen er operativ Postconditions Korrekte data er hentet fra TimeInfo-databasen og gjort tilgjengelig for aktøren til UC 3 eller 4, Ansatt Kvalitets krav - Scenario Ansatt er i TimeEditor 1 Systemet oppretter kontakt med TimeInfo-databasen 2 Systemet henter alle alle timer jobbet for den påloggede ansatte siste måned UseCase 15 Hent timer, alternativ scenario 1 Priority 2 Mål Alle timer som er brukt på et prosjekt skal finnes på grunnlag av et prosjektnummer Aktører TimeInfo-database Preconditions UC 6 eller 9 er under utførelse og et valid prosjektnummer er oppgitt Databasen er operativ Postconditions Korrekte data er hentet fra TimeInfo-databasen og gjort tilgjengelig for aktøren til UC 6 Prosjektleder Kvalitets - krav Scenario Prosjektleder er i ProsjektEditor 1 Systemet oppretter kontakt med TimeInfo-databasen 2 Systemet finner riktig prosjekt og alle timer tilknyttet prosjektet på grunnlag av prosjektnummeret som er oppgitt i UC6, Sjekk prosjekt 3 Hvis timebudsjettet på prosjektet er overskredet gis det melding om dette

17 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side 16 Kommentar: Budsjetterte timer per ansatt er ikke tatt med i det videre arbeidet med denne versjonen av timeregistreringssystemet, men bare budsjetterte timer per prosjekt. Neste versjon av systemet kan utvides til også å gjelde budsjetterte timer per ansatt for hvert prosjekt. UseCase 15 Hent timer, alternativt scenario 3 Priority 4 Mål Busjetterte timer på et prosjekt skal finnes på grunnlag av et prosjektnummer TimeInfo-database UC 5,6 eller 9 er under utførelse Databasen er operativ Korrekte søkekriterier er angitt UseCase 15 Hent timer, alternativt scenario 2 Priority 3 Mål Alle prosjektmedarbeidere skal finnes på grunnlag av et prosjektnummer Aktører TimeInfo-database Preconditions UC 9 alternativ scenario 2 er under utførelse Databasen er operativ Postconditions Korrekte data er hentet fra TimeInfo-databasen og gjort tilgjengelig for aktøren til UC 9 Prosjektleder Kvalitets - krav Scenario Prosjektleder er i ProsjektEditor 1 Systemet oppretter kontakt med TimeInfo-databasen 2 Systemet finner riktig prosjekt og alle prosjektmedarbeidere som har registrert timer på prosjektet på grunnlag av prosjektnummer oppgitt i UC9 Aktører Preconditions Postconditions Korrekte data er hentet fra TimeInfo-databasen og gjort tilgjengelig for aktøren til UC 5,6,9 Kvalitets krav - Scenario Prosjektleder er i ProsjektEditor 1 Systemet oppretter kontakt med TimeInfo-databasen 2 Systemet finner riktig prosjekt og alle budsjetterte timer på prosjektet på grunnlag av prosjektnummer oppgitt i UC5, 6 eller 9

18 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side UseCase 16, Oppdater timer Kommentar:Hvis det oppdages at den nye timeregistreringen gjør at prosjektets budsjett sprekker, lagres en melding i databasen slik at Prosjektleder får en melding neste gang UC6 Sjekk prosjekttimer utføres. UseCase 16 Oppdater timer, normal flyt Priority 1 Mål Anvendte timer av en ansatt på et prosjekt skal lagres i timeinfo databasen Aktører TimeInfo-database Pre-conditions UC 3 er under utførelse Databasen er operativ Postconditions Korrekte data er lagret i TimeInfo-databasen Kvalitets krav - Scenario Ansatt er i TimeEditor 1 Systemet oppretter kontakt med TimeInfo-databasen 2 Systemet oppdaterer TimeInfo-databasen med antall timer den innloggede ansatte har jobbet på et prosjekt på en spesifikk dato 3 Systemet beregner sum timer arbeidet på prosjektet totalt 4 Systemet beregner differansen mellom timer arbeidet og timer budsjettert 5 Hvis sum timer arbeidet er større enn timer budsjettert, lagres melding i databasen 6 Systemet registrer timer arbeidet utover normalarbeidstid som overtid UseCase 16 Oppdater timer, alternativ scenario 1 Priority 1 Mål Antall timer en ansatt har hatt fri skal lagres i TimeInfo-databasen Aktører TimeInfo-database Pre-conditions UC 4 registrer fri, er under utførelse Databasen er operativ Post-conditions Korrekte data er lagret i TimeInfo-databasen Kvalitets krav - Scenario Ansatt er i TimeEditor 1 Systemet oppretter kontakt med TimeInfo-databasen 2 Systemet oppdaterer TimeInfo-databasen med antall timer den innloggede ansatte har hatt fri i normal arbeidstid 3 Hvis fritiden er avspasering, avregner systemet timene mot overtid.

19 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side 18 UseCase 16 Oppdater timer, alternativ scenario 2 Priority 1 Mål Anvendte timer på et prosjekt skal lagres i timeinfo databasen Aktører TimeInfo-database Pre-conditions UC 9 er under utførelse Databasen er operativ Korrekte søkekriterier er angitt og UC 15 er utført Postconditions Korrekte data er lagret i TimeInfo-databasen Kvalitets krav - Scenario Prosjektleder er i ProsjektEditor 1 Systemet oppretter kontakt med TimeInfo-databasen 2 Systemet lagrer budsjetterte prosjekttimer på prosjektet som er under behandling i UC9 Kommentar: Vi ser av den tydelige delingen av alternativ og normalflyt i UC 15 og 16 at det kunne ha vært en god ide med en deling av timeservice i en TimeService og en ProsjektService, men vi har valgt å ikke gjøre dette i denne iterasjonen da det vil medføre en unødvendig komplisering av arkitekturen inntil det kommer med mer funksjonalitet som har med prosjektadministrasjon å gjøre. Det er derfor bedre å foreta en refactoring når prosjektfunksjonaliteten skal integreres i det nåværende systemet. 3.4 Reference Architecture Analysis Model/Component Identification De omringede komponentene er de vi detaljerer videre.

20 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Use Case Scenario Modeller Sekvensdiagram for Use Case 3, Administrere Timer, normal flyt Sekvensdiagram: UCScenarioAdmintimer normalflyt, komponentnivå Kommentar på notasjon. Ettersom vi har brukt rational rose til å tegne sekvensdiagrammer, har vi ikke hatt tilgang til notasjon fra UML 2.0 Dette har medført at vi bruker piler i følge UML 1.4 og har brukt notatbokser for å vise ny boksenotasjon i forhold til UML 2.0 : Ansatt 0.Open( ) : TimeEditor : TimeService : TimeInfo REF 1.sekvensdiagram for henttimer, normalflyt 2.VisTimer( ) 3.1 hentalleprosjekter( ) 3.2 hentalleprosjekter( ) prosjektliste prosjektliste 4.visAlleProsjekter( ) 5.Velg prosjekt( ) 6.regDato( ) 7.regAntTimer( ) REF 8.sekvensdiagram for oppdater timer, normalflyt

21 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Sekvensdiagram for Use Case 15, Hent Timer, normalflyt Dette sekvensdiagrammer viser normalflyt mellom komponentene. : Ansatt Open( ) : TimeEditor : TimeService : TimeInfo finnansnr( ) hentalletimer() Ansattnummer hentes fra konteksten timeliste hentalletimer( ) timeliste

22 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Sekvensdiagram for Use Case 16, Oppdater timer, normalflyt Sekvensdiagram: UCScenarioOppdaterTimer normalflyt, komponentnivå : Ansatt : TimeEditor : TimeService : TimeInfo regtimerpåprosjekt( ) regtimerpåprosjekt(integer, Integer, Date, Integer) connect( ) OK lagretimerpåprosjekt( ) OK hentbudsjettpåprosjekt( ) hentpåløpetpåprosjekt( ) beregnoverskridelse( ) IF budsjett<sum timer jobbet IF timer > normalarbeidstid regovertid( )

23 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side 22 4 Architecture model 4.1 Component structure Application component structure med detaljering

24 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Interface & interaction spesification Grensesnitt beskrivelse Komponent/klasse diagram Klassediagram/interface som kommer fram som resultat av sekvensdiagrammer for normalflyt for UC Administrer timer, Hent timer og Oppdater timer fra Requirements Model. Vi kom fram til at det ga lite merverdi å lage mer detaljerte sekvensdiagrammer for dette systemet, da det ble få klasser i hvert sekvensdiagram og vi ikke fikk mer detaljer i forhold til å lage komponentenes interface. Det er mulig at dette viser at vi har vært for detaljerte når vi jobbet med sekvensdiagrammer i Requirements Model IUserService Open() VisTimer() visalleprosjekter() Velg prosjekt() regdato() reganttimer() regtimerpåprosjekt() : Boolean finnansnr() : Integer ITimeService hentalleprosjekter() : Collection hentalletimer(ansnr) regtimerpåprosjekt(pnr : Integer, ansnr : Integer, dato : Date, anttimer : Integer) beregnoverskridelse() : Double ITimeInfo hentalleprosjekter() : Collection hentalletimer() connect() : Boolean lagretimerpåprosjekt() : Boolean hentbudsjettpåprosjekt() : Double hentpåløpetpåprosjekt() regoverskredetmelding(overskredet : enum) regovertid() Når vi gikk gjennom alternativ flyt for Admin timer, Hent Timer og Oppdater timer så vi at interfacet til TimeInfo måtte oppdateres som vist i figur under.

25 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Grensesnitt beskrivelse QoS Vi har her innført noen klasse attributter for å skrive OCL: ITimeInfo hentalleprosjekter() : Collection hentalletimer() connect() : Boolean lagretimerpåprosjekt() : Boolean hentbudsjettpåprosjekt() : Double hentpåløpetpåprosjekt() regoverskredetmelding(overskredet : enum) regovertid() settfri(ansnr : Integer) : Boolean settbudsjettertetimer(maxtimer : Integer) : Boolean hentmelding() : String hentprosjektansatte(pnr : Integer) : Collection settavspasering(ansnr : Integer, anttimer : Integer) : Boolean Project har en attributt status av type enum{overskredet, utvidet, ferdig}. Ansatt har en attributt samlaovertid av type Integer. Må holde oversikt over overtid for på en enkel måte å kunne trekke fra avspasering når dette tas ut. Mindre enn 8 timer på en dag trekkes fra samla overtid, hvis de manglende timene ikke er ført på prosjekter som syk, lege, kurs, ymse. Overtid og avspasering føres fortløpende i hele perioden den ansatte jobber for firmaet. context Project inv: let( overskredeteprosjekter = Project->select(status = #overskredet and finished!= true) ) operation TimeOversikt::OppdaterTimer ( pnr:pnr, ansnr:ansnr, dato:dato, timer:timer ) pre pnr.status <> #ferdig post pnr.påløptetimer = pnr.påløptetimer@pre + timer and pnr.påløptetimer >= pnr.maxtimer implies pnr.status = #overskredet operation TimeOversikt:: OppdaterTimer ( pnr:pnr, ansnr:ansnr, dato:dato, timer:timer ) let( overtid = TimeOversikt->iterate( t:timeoversikt, sum:integer if t->select( t t.ansnr = ansnr and t.dato = dato ) then sum = sum + t.timer endif ) > 8 ansatt = Ansatt->select(a a.ansnr = ansnr) )

26 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side 25 in( post ansatt.samlaovertid = ansatt.samlaovertid@pre + overtid ) operation TimeOversikt:: OppdaterTimer ( pnr:pnr, ansnr:ansnr, dato:dato, timer:timer ) let( avspasering = TimeOversikt->iterate( t:timeoversikt, sum:integer if t->select( t t.ansnr = ansnr and t.dato = dato ) then sum = sum + t.timer endif ) < 8 ansatt = Ansatt->select(a a.ansnr = ansnr) ) in( post ansatt.samlaovertid = ansatt.samlaovertid@pre - avspasering ) 4.3 Internal design BCE analyse BCE, TimeEditor Registreringsvelger Ansatt (from Use Case View) TimeRegistreringer RegistreringsController TimeOversikt OK ProsjektOversikt Meldingsfelt

27 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side 26 BCE, TimeService STime SProsjekt SAnsatt ServiceController TimeInfo SFri

28 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side BCE mapping til klasser Denne biten er utelatt modellert i verktøy, kun på papir. Det ble foretatt BCEMapping to focus/auxiliary-classes for TimeEditor og TimeService Intern klassedesign BCEMapping to focus/auxiliary-classes for TimeEditor resulterte i følgende implementasjonsklasser i design modellen. UI <<Frame>> Registreringsvelger US <<auxiliary>> Registreringsdata <<DropDown>> ProsjektListe <<focus>> EditorManager <<focus>> UserService IUserService <<Button>> OK <<TextArea>> Meldingsfelt (from UI) <<auxiliary>> Formaterer BCEMapping to focus/auxiliary for TimeService resulterte i følgende implementasjonsklasser i designmodellen. TimeService TimeData ITimeService <<focus>> FTimeService ITimeInfo <<focus>> FTimeData

29 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side 28 5 Platform Specific Model Den plattform spesifikke modellen tar for en J2EE-implementasjon med en servlet og EJB-klasser. Komponentmodellene viser detaljert design av TimeServiceEJB og TimeInfoEJB Component Implementation Model Detaljert desing av TimeServiceEJB

30 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side 29 Detaljert design av TimeInfoEJB Fordi både TimeService og TimeInfo ligger i samme EJB-container er det nødvendig å opprette et EJBLocalObject av ItimeInfo. Dette lokal-objektet forholder seg kun til TimeServiceEJB og kan bare kalles av dette objektet.

31 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side Deployment Model Deploymentdiagrammet viser de aktuelle instanser som er involvert ved en servlet kommunikasjon. Samtidig viser det hvordan EJB-servleten kommuniserer via RMI med TimeServiceEJB gjennom en EJB-container. Både TimeServiceEJB og TimeInfoEJB ligger i samme EJBContainer. På brukersiden opprettes en proxy med samme interface som TimeService. ClientHost: :UserService TimeServiceProxy: TCP/IP HTTP-tunnelling ServletHost: :Service Engine :TimeServiceServletStub: :TimeServiceEJBServletStub: Java :TimeService: :EJBContainer :TimeServiceEJB RMI Java Java/RMI :TimeInfo: :TimeInfoEJB

32 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side 31 6 Notasjoner som er brukt I en del av modellen har vi brukt noen notasjoner vi måtte lage underveis, fordi tegne og modelleringsverktøyene vi har brukt ikke har vært tilpassa COMET metodikken. Disse er forklart her. T : I. H. BS : RS : Tool Intermediate Human Business Service Resource Service

33 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side i 1 Vedlegg 1.1 Vedlegg 1 Use Case beskrivelser UseCase 1. Log In UseCase 1 Log In - Normal Hendelsesflyt Priority 1 Mål Logge inn på timeregistreringssystem Aktører Ansatt, Prosjektleder (heretter bruker) Pre-conditions Bruker må være registrert i systemet Post-conditions Bruker er innlogget og kan bruke systemet. Facade - Kvalitets krav - Scenario Bruker er i Login View 1 Bruker åpner log in view/ Systemet presentere et grensesnitt for innlogging. 2 Bruker taster inn nødvendige tilgangsopplysninger (f.eks brukernavn og passord) 3 Systemet kontrollerer og verifiserer opplysningene. 4 Bruker logges inn og systemet presenterer hovedgrensesnitt for bruker (kan variere i forhold til bruker-rettigheter). UseCase 1 Log In - Alternativ Hendelsesflyt 1 Priority 1

34 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side ii Mål Logge inn på timeregistreringssystem Aktører Ansatt, Prosjektleder (heretter bruker) Pre-conditions Bruker må være registrert i systemet Post-conditions Bruker er innlogget og kan bruke systemet. Facade - Kvalitets krav - Scenario Bruker er i Login View 1 Bruker åpner log in view/ Systemet presentere et grensesnitt for innlogging. 2 Bruker taster inn nødvendige tilgangsopplysninger (f.eks brukernavn og passord) 3 Systemet kontrollerer opplysningene, finner at de er uriktige, og gir bruker beskjed om dette. 4 Bruker begynner på nytt fra punkt 2 i normal hendelsesflyt UseCase 4 Administrere fri UseCase 4 Administrere fri - Normal Hendelsesflyt Priority 1 Mål Registrere/endre avspasering og ferie Aktører Ansatt Pre-conditions Ansatt må være logget på Post-conditions Time database skal være korrekt oppdatert Facade - Kvalitets krav - Scenario Ansatt er i TimeEditor 1 Ansatt registrerer ønsket avspasering og

35 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side iii ferie 2 Avspasering og ferie blir registrert i timedatabase UseCase 5. Motta timeoversikt (Dette har vi egentlig tatt bort ) Hvor skriver vi om hva som er borte i forhold til den overordna Use Case-modellen? UseCase 5 Motta timeoversikt - Normal Hendelsesflyt Priority 1 Mål Få oversikt over hvor mange timer som er brukt på et prosjekt Aktører Prosjektleder Preconditions Prosjektene må være opprettet og ansatte må ha registrert timer på Prosjektleder må være logget på prosjektet. Postconditions tilstandsendring i systemet. Dette er egentlig bare visning av data, så det vil ikke skje noen Facade Kommentar: Kanskje dette skulle skje hver gang en ansatt har registrert timer, som et immediate step på en måte..men kan da ikke brukes i Sjekk prosjekttimer Kvalitets - krav Scenario Prosjektleder sitter med administrasjoneviewet av TimeRegistrator 1 Prosjektleder velger prosjekt å få oversikt over 2 UC Hent timer utføres 3 Systemet viser samlet antall timer jobbet på prosjektet og hvor mange timer hver prosjektmedarbeider har jobbet på prosjektet Use case 6 Sjekk prosjekttimer Både dette og neste UC trenger egentlig et hjelpecase som heter hent prosjekt, hvis det ikke skal være en variant av hent timer da Men nå ser jeg ikke hvor man får gjort av

36 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side iv budsjetterte timer på et prosjekt. Lar hent timer gjøre alt nå, men skulle kanskje vært delt??? UseCase 6 Sjekk prosjekttimer - Normal Hendelsesflyt Priority 1 Mål Kontrollere ressursbruk i forhold til budsjett på de enkelte prosjektene. Aktører Prosjektleder Preconditions Prosjektleder må være logget på Prosjektene må være opprettet Postconditions Prosjektets budsjettforbruk er oppdatert i prosjektstyringsdatabasen(???? Regner vel med at de må kunne bruke inputen fra dette Use Caset til å oppdatere et prosjektstyringsverktøy, men dette har vi egentlig forutsatt at vi ikke skal forholde oss til, så.) Facade - Kvalitets - krav Scenario Prosjektleder sitter med administrasjoneviewet av TimeRegistrator 1 Utfør UC Motta timeoversikt 2 Prosjektleder finner timebudsjett for hver prosjektmedarbeider som er registrert i følge timeoversikten 3 Prosjektleder beregner differanser mellom budsjetterte og forbrukte timer. 4 Systemet gjør differansen klar for eksport til et eventuelt prosjektstyringsverktøy. UseCase 6 Sjekk prosjekttimer - Alternativ Hendelsesflyt 1 Priority 1 Mål Kontrollere ressursbruk i forhold til budsjett på de enkelte prosjektene. Aktører Prosjektleder Preconditions Prosjektleder må være logget på Prosjektene må være opprettet

37 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side v Postconditions Prosjektets budsjettforbruk er oppdatert i prosjektstyringsdatabasen(???? Regner vel med at de må kunne bruke inputen fra dette Use Caset til å oppdatere et prosjektstyringsverktøy, men dette har vi egentlig forutsatt at vi ikke skal forholde oss til, så.) Facade - Kvalitets - krav Scenario Prosjektleder sitter med administrasjoneviewet av TimeRegistrator 1 Utfør UC Motta timeoversikt 2 Prosjektleder finner timebudsjett for hver prosjektmedarbeider som er registrert i følge timeoversikten 3 Prosjektleder beregner differanser mellom budsjetterte og forbrukte timer. 4 Prosjektleder oppdager at timebudsjettet er overskredet og sender melding til ledelsen om at overskridelser er oppdaget. 4 Systemet gjør differansen klar for eksport til et eventuelt prosjektstyringsverktøy Use Case 9, Justere prosjektbudsjett UseCase 9 Justere prosjektbudsjett - Normal Hendelsesflyt Priority 1 Mål Aktører Prosjektleder Pre-conditions Prosjektleder må være logget på Prosjektene må være opprettet Det er oppstått et behov for å endre antall timer for bruk i et prosjekt Post-conditions Prosjektinformasjonen er korrekt oppdatert i databasen Facade - Kvalitets krav - Scenario Prosjektleder sitter med administrasjoneviewet av TimeRegistrator

38 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side vi 1 Prosjektleder sender melding til ledelsen om at det er oppstått behov for å endre antall timer som skal brukes på et prosjekt. 2 Prosjektleder mottar melding fra ledelsen om at endringsbehovet er godkjent 3 Prosjektleder velger prosjekt som skal endres 4 UC hent timer utføres 5 Prosjektleder oppdaterer prosjektinformasjonen 6 UC Oppdater timer utføres UseCase 9 Justere prosjektbudsjett - Alternativ Hendelsesflyt 1 Priority 1 Mål Aktører Prosjektleder Pre-conditions Prosjektleder må være logget på Prosjektene må være opprettet Det er oppstått et behov for å endre antall timer for bruk i et prosjekt Post-conditions Prosjektinformasjonen er korrekt oppdatert i databasen Facade - Kvalitets krav - Scenario Prosjektleder sitter med administrasjoneviewet av TimeRegistrator 1 Prosjektleder sender melding til ledelsen om at det er oppstått behov for å endre antall timer som skal brukes på et prosjekt. 2 Prosjektleder mottar melding fra ledelsen om at endringsbehovet IKKE er godkjent 3 Prosjektleder lager melding som må sendes til alle prosjektmedarbeidere 4 UC hent timer utføres (nå brukes det til å hente alle ansatte på prosjeketet)

39 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side vii 5 Systemet sender melding til alle medarbeiderne på prosjektet UseCase 12 Godkjenn timelister UseCase 12 Godkjenn timelister - Normal Hendelsesflyt Priority 3 Mål Ansatt godkjenner timeliste for en periode Aktører Ansatt Pre-conditions Ansatt må være logget på Postconditions Timelisten skal være godkjent av ansatt og timedatabasen skal være oppdatert Facade - Kvalitets krav - Scenario Ansatt er i TimeEditor 1 Ansatt vurderer timer, avspasering og fri for perioden 2 Ansatt godkjenner timelisten 3 Godkjenning blir registrert i timedatabase UseCase 12 Godkjenn timelister - Alternativ Hendelsesflyt 1 Priority 3 Mål Ansatt retter timeliste for en periode Aktører Ansatt Pre-conditions Ansatt må være logget på

40 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side viii Postconditions Timelisten skal være rettet av ansatt og timedatabasen skal være oppdatert Facade - Kvalitets krav - Scenario Ansatt er i TimeEditor 1 Ansatt vurderer timer, avspasering og fri for perioden 2 Ansatt retter timelisten 3 Rettelse blir registrert i timedatabase 4 Varsel om rettelse blir sendt ledelse UseCase 13. Se Rapport UseCase 13 Se Rapport - Normal Hendelsesflyt Priority 1 Mål Se rapport generert fra timeregistreringssystem Aktører Ansatt, Prosjektleder, Ledelse (heretter bruker) Pre-conditions Bruker må være logget inn. (Grunnlagsdata for rapport må være lagt inn.) Post-conditions Rapport er generert og fremvist for bruker Facade - Kvalitets krav - Scenario Bruker er i RapportViewer 1 Bruker velger type rapport som ønskes vist 2 Systemet lager rapport 3 Systemet viser rapport 4 Bruker velger å lagre og/eller skrive ut rapport 5 Systemet lagrer/skriver ut rapport

41 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side ix 6 Bruker velger å lukke rapport. UseCase 13 Se Rapport - Alternativ Hendelsesflyt 1 Priority 1 Mål Se rapport generert fra timeregistreringssystem Aktører Ansatt, Prosjektleder, Ledelse (heretter bruker) Pre-conditions Bruker må være logget inn. Post-conditions Rapport er generert og fremvist for bruker. Facade - Kvalitets krav - Scenario Bruker er i RapportViewer 1 Bruker velger type rapport som ønskes vist 2 Systemet mangler data for å lage ønsket rapport, og gir bruker beskjed om dette. 3 Bruker avslutter sekvensen Use Case 14 Verifiser bruker Include Use Case UseCase 14 Verifiser bruker - Normal Hendelsesflyt Priority 1 Mål Verifisere brukerens tilgangsopplysninger Aktører Ansatt, Prosjektleder (heretter bruker) Pre-conditions Bruker må være registrert i systemet med nødvendige tilgangsopplysninger. Post-conditions Systemt har verifisert brukerens tilgangsopplysninger. Facade - Kvalitets krav - Scenario LoginService

42 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side x 1 Systemet mottar nødvendige tilgangsopplysninger (f.eks brukernavn og passord). 2 Systemet kontrollerer opplysningene mot lagrede opplysninger i database og finner at de er riktige. 3 Systemet har verifisert opplysningene og gir beskjed om dette. UseCase 14 Verifiser bruker - Alternativ Hendelsesflyt 1 Priority 1 Mål Verifisere brukerens tilgangsopplysninger Aktører Ansatt, Prosjektleder (heretter bruker) Pre-conditions Bruker må være registrert i systemet med nødvendige tilgangsopplysninger. Post-conditions Systemt har verifisert brukerens tilgangsopplysninger. Facade - Kvalitets krav - Scenario LoginService 1 Systemet mottar nødvendige tilgangsopplysninger (f.eks brukernavn og passord). 2 Systemet kontrollerer opplysningene mot lagrede opplysninger i database og finner at de er uriktige. 3 Systemet verifiserer ikke opplysningene og gir beskjed om dette. 4 Systemet begynner på nytt fra punkt 1 i normal hendelsesflyt

43 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side xi Use Case 17 Lag rapport Include Use case UseCase 17 Lag Rapport Normal Hendelsesflyt Priority 1 Mål Lage rapport basert på grunnlagsdata i timeregistreringssystem Aktører Se-rapport brukergrensesnitt/login View?/Ansatt, Prosjektleder, Ledelse (heretter bruker) Pre-conditions Bruker må være logget inn. (Grunnlagsdata for rapport må være lagt inn.) Post-conditions Rapport er generert. Facade - Kvalitets krav - Scenario Aktør er i RapportService 1 Systemet mottar beskjed (fra Se-rapport - brukergrensesnitt/login View?) om ønsket rapport 2 Systemet henter nødvendige grunnlagsdata fra database. 3 Systemet generer rapport (til Se-rapport brukergrensesnitt/loginview?). UseCase 17 Lag Rapport Alternativ hendelsesflyt 1 Priority 1 Mål Lage rapport basert på grunnlagsdata i timeregistreringssystem Aktører Se-rapport brukergrensesnitt/login View?/Ansatt, Prosjektleder, Ledelse (heretter bruker) Pre-conditions Bruker må være logget inn. (Grunnlagsdata for rapport må være lagt inn.) Post-conditions Rapport er generert

44 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side xii Facade - Kvalitets krav - Scenario Aktør er i RapportService 1 Systemet mottar beskjed (fra Se-rapport - brukergrensesnitt/login View?) om ønsket rapport 2 Systemet forsøker å hente, men finner ikke nødvendige grunnlagsdata i database. 3 Systemet generer ikke rapport og sender beskjed om dette (til Se-rapport brukergrensesnitt/login View?) UseCase 18. Log Out UseCase 18 Log Out - Normal Hendelsesflyt Priority 1 Mål Logge ut av timeregistreringssystem Aktører Ansatt, Prosjektleder (heretter bruker) Pre-conditions Bruker må være innlogget Post-conditions Bruker skal være logget av systemet. Facade - Kvalitets krav - Scenario Bruker er i Log Out View 1 Bruker gir systemet beskjed om at han ønsker å logge seg av. 2 Systemet spør om bruker ønsker å lagre eventuelle filer som ikke er lagret. 3 Systemet ber om bekreftelse på at bruker ønsker å logge seg av. 4 Bruker bekrefter ønske om av logging.

45 Obligatorisk oppgave 2 INF 5120 gruppe 4 Side xiii 5 Systemet bytter fra grensesnitt bruker hadde oppe til grensesnitt for innlogging. UseCase 18 Log Out - Normal Hendelsesflyt Priority 1 Mål Logge ut av timeregistreringssystem Aktører Ansatt, Prosjektleder (heretter bruker) Pre-conditions Bruker må være innlogget Post-conditions (Bruker skal være logget av systemet.) Facade - Kvalitets krav - Scenario Bruker er i Log Out View 1 Bruker gir systemet beskjed om at han ønsker å logge seg av. 2 Systemet spør om bruker ønsker å lagre eventuelle filer som ikke er lagret. 3 Systemet ber om bekreftelse på at bruker ønsker å logge seg av. 4 Bruker bekrefter ikke ønske om av logging. 5 Systemet foretar ikke bytte av grensesnitt og bruker forblir innlogget.