University of Oslo Department of Informatics INF5120 - Modellering med objekter Oblig 2, V2004 Skrevet av: Gruppe 16 Geir Atle Hegsvold (gahegsvo) Harald Maalen (haralm) André Sollie (andresol)
2
Index 1 Innledning... 4 1.1 Problembeskrivelse... 4 1.2 Avgrensninger og antagelser... 4 2 Business Model... 5 2.1 Scoping Statements Contex Statements... 5 2.1.1 Aktører og interesser... 5 2.1.2 Overordnet virksomhetsprosess... 6 2.2 Goal Model... 7 2.3 Business Resource Model... 8 2.4 Business Process & Role Model... 9 2.4.1 Nivå 1... 9 2.4.2 Nivå 2... 10 3 Requirements Model... 12 3.1 System Boundary Model... 12 3.2 Subsystem Grouping Model... 13 3.2.1 Use Case... 13 3.2.2 Use Case Beskrivelser... 14 3.3 Reference Architecture Analysis Model... 19 4 Architecture Model... 20 4.1 Interface & Interaction Specification... 20 4.2 Component Structure... 24 4.3 Internal Design... 25 5 Platform Specific Model... 27 5.1 Component Implementation Model... 27 5.2 Deployment Model... 28 Figurer Figur 1-1 - Content Statement... 5 Figur 1-2 - Overordnet virksomhetsprosess... 6 Figur 1-3 - Goal Model... 7 Figur 1-4 - Business Resource Model... 8 Figur 1-5 - Business Process & Role Model Nivå 1... 9 Figur 1-6 - Business Process & Resource Model Nivå 2 Aktivitetsdiagram... 10 Figur 1-7 - Business Process & Resource Model Nivå 2 Use Case diagram... 11 Figur 2-1 - System Boundary Model... 12 Figur 2-2 - System Grouping Model... 13 Figur 2-3 - Reference Architecture Analysis Model... 19 Figur 3-1 - RegistreringsEditor Interface & Interaction Specification... 20 Figur 3-2 - Rapport Interface & Interaction Specification... 21 Figur 3-3 - AdminEditor Interface & Interaction Specification... 22 Figur 3-4 Sekvensdiagram for Use Case 1: Registrer Timer... 22 Figur 3-6 Sekvensdiagram for Use Case 2: Vis timebudsjett for prosjektdeltager... 23 Figur 3-8 - Sekvensdiagram for Use Case 4: Vis alle prosjekter... 23 Figur 3-9 - Component Structure... 24 Figur 3-10 - BCE analyse: Klassediagram... 25 Figur 3-11 - Mapping til fokus/auxiliary klasser... 26 Figur 3-12 - Internt design av RegistreringsEditor... 27 Figur 4-1 - Deployment Model... 28 3
1 Innledning 1.1 Problembeskrivelse Bedriften HRS AS ønsker å holde oversikt over hvor ressursene brukes og har besluttet å innføre timelister. Hver ansatt må da hver uke registrere timene de jobber på de ulike prosjektene som pågår i bedriften slik at man lettere kan holde oversikt over påløpte timer per prosjekt. Bedriften trenger et system for å håndtere timeregistrering, vi er derfor satt til å designe og lage et slikt system. I tillegg til å registrere timer på de ulike prosjektene må systemet også vedlikeholde et personlig timebudsjett for hver av de ansatte i bedriften (slik at man kan holde oversikt over avspasering og ferie). 1.2 Avgrensninger og antagelser Vi antar at hver ansatt (prosjektdeltager) vil ha behov for å registrere arbeidstimer per dag i tillegg til å registrere per uke. Ansatte ytrer ønske om ferietid muntlig eller skriftlig utenfor systemet. En administrator tar seg av registreringen i systemet. Systemet beregner avspasering på grunnlag av antall registrerte timer for en ansatt. Siden vi bare er tre personer som må gjennomføre denne modellbeskrivelsen, har vi valgt å fokusere på registrering av arbeidstimer for en ansatt og enkle listefunksjoner. 4
2 Business Model 2.1 Scoping Statements Contex Statements 2.1.1 Aktører og interesser Figur 2-1 - Content Statement Admin Prosjektdeltager Ledelse IT avdeling Økonomi Avdeling Stakeholders En administrator av systemet er nødvendig for å kunne opprette, fjerne og endre prosjekter og prosjektdeltagere. En prosjektdeltager (PD) er hovedbrukeren av systemet og er viktig for utformingen av systemet. En PD vil benytte dette til å registrere timer han/hun arbeider på prosjekter i bedriften. Ledelsen har autorisasjon til å ta finansielle avgjørelser for utviklingen av produktet. En eventuell IT avdeling kan stille krav til systemet under utvikling mtp sikkerhet og evt integrering med andre systemer. En eventuell økonomiavdeling tar seg av den praktiske delen av økonomien og kan ha interesser i forhold til ferier og avspasering. 5
2.1.2 Overordnet virksomhetsprosess Figur 2-2 - Overordnet virksomhetsprosess 6
2.2 Goal Model Figur 2-3 - Goal Model Det å kunne registrere arbeidstimer for ansatte er det grunnleggende som skal til for å oppnå samtlige mål. Når man først har registret arbeidstimene for de ansatte, kan systemet beregne antall timer som går med til hvert prosjekt, og også kalkulere avspasering hvor hver ansatt. For å oppnå målet med ferieoversikt må man antagelig ha mer enn antall timer de ansatte har jobbet, men dette er noe vi har valgt å se bort ifra (se 1.2). 7
2.3 Business Resource Model Figur 2-4 - Business Resource Model Time Registrering inneholder informasjon om hvilken ansatt som har jobbet hvor mange timer på hvilket prosjekt. 8
2.4 Business Process & Role Model 2.4.1 Nivå 1 Figur 2-5 - Business Process & Role Model Nivå 1 9
2.4.2 Nivå 2 Figur 2-6 - Business Process & Resource Model Nivå 2 Aktivitetsdiagram Timebudsjett er totalt antall timer en ansatt har jobbet. Prosjektbudsjett er totalt antall timer som har gått med til et prosjekt. 10
Figur 2-7 - Business Process & Resource Model Nivå 2 Use Case diagram 11
3 Requirements Model 3.1 System Boundary Model Figur 3-1 - System Boundary Model 12
3.2 Subsystem Grouping Model 3.2.1 Use Case Figur 3-2 - System Grouping Model 13
3.2.2 Use Case Beskrivelser Use case 1 Registrere timer Priority 1 Goal Registrere timer arbeidet på prosjekt og lagre lokalt eller globalt Actors Prosjektdeltager Pre-conditions Bruker er logget inn Post-conditions Brukers input er lagret Façade Quality requirements Scenario Daglig timeregistrering Description Step Action 1 Åpne timebudsjett for inneværende uke 2 Registrere antall timer arbeidet 3 Lagre timebudsjett lokalt Scenario Ukentlig timeregistrering Description Step Action 1 Åpne timebudsjett for inneværende uke 2 Registrere antall timer arbeidet 3 Lagre timebudsjett lokalt 4 Eksportere timebudsjett til global database (Use case 13) Use case 2 Vis timebudsjett for prosjektdeltager Priority 2 Goal Timeoversikt for prosjektdeltager Actors Prosjektdeltager, Admin Pre-conditions Bruker er logget inn Post-conditions Façade - Quality requirements - Scenario Timeoversikt for prosjektdeltager er vist. Normalt hendelsesforløp Description Step Action 1 Bruker velger å vise timebudsjett. 2 Use case 9. 3 Timebudsjett vises på skjermen. 14
Use Case 3 Vis prosjektrapport for prosjektdeltager Priority 2 Goal Timeoversikt for prosjekt Actors Prosjektdeltager, Admin Pre-conditions Bruker er logget inn Post-conditions Facade - Quality requirements - Scenario Timeoversikt for prosjekt er vist. Normalt hendelsesforløp Description Step Action 1 Bruker velger å vise prosjektrapport. 2 Use case 10. 3 Prosjektrapport vises på skjermen. Use Case 4 Vis alle prosjekter Priority 2 Goal Oversikt over alle prosjekter Actors Prosjektdeltager, Admin Pre-conditions Bruker er logget inn Post-conditions Facade - Quality requirements - Scenario Oversikt over alle prosjekter er vist. Normalt hendelsesforløp Description Step Action 1 Bruker velger å vise oversikt over alle prosjekter. 2 Use case 11. 3 Oversikt over alle prosjekter vises på skjermen. Use Case 5 Vis alle prosjektdeltagere Priority 2 Goal Oversikt over alle prosjektdeltagere Actors Prosjektdeltager, Admin Pre-conditions Bruker er logget inn Post-conditions Facade - Quality requirements - Scenario Oversikt over alle prosjektdeltagere er vist. Normalt hendelsesforløp Description Step Action 1 Bruker velger å vise oversikt over alle prosjektdeltagere. 2 Use case 12. 3 Oversikt over alle prosjektdeltagere vises på skjermen. 15
Use Case 6 Priority 3 Goal Ferieoversikt Actors Prosjektdeltager, Admin Pre-conditions Bruker er logget inn Post-conditions Facade - Quality requirements - Scenario Ferieoversikt er vist Normalt hendelsesforløp Håndter ferier Description Step Action 1 Bruker velger å håndtere ferier 2 Bruker gjør ønskede endringer 3 Bruker velger å lagre 4 Use case 13. Use Case 7 Håndter prosjektdeltagere Priority 3 Goal Håndtere prosjektdeltager Actors Admin Pre-conditions Bruker er logget inn Post-conditions Façade - Quality requirements - Scenario Prosjektdeltager er oppdatert. Normalt hendelsesforløp Description Step Action 1 Bruker velger å håndtere prosjektdeltagere 2 Bruker gjør ønskede endringer 3 Bruker velger å lagre 4 Use case 13. Use Case 8 Priority 3 Goal Håndtere prosjekter Actors Admin Pre-conditions Bruker er logget inn Post-conditions Façade - Quality requirements - Scenario Prosjekt er oppdatert. Normalt hendelsesforløp Håndter prosjekter Description Step Action 1 Bruker velger å håndtere prosjekter 2 Bruker gjør ønskede endringer 3 Bruker velger å lagre 4 Use case 13. 16
Use Case 9 Generer timebudsjett for Prosjektdeltager Priority 2 Goal Generer og lever timebudsjett Actors Rapport Pre-conditions - Post-conditions Timebudsjett er generert Façade - Quality requirements - Scenario Normalt hendelsesforløp Description Step Action 1 Hent data om PD 2 Generer timebudsjett 3 Lever timebudsjett til Rapport Use Case 10 Generer prosjektrapport for prosjektdeltager Priority 2 Goal Generer og lever prosjektrapport Actors Rapport Pre-conditions - Post-conditions Lever prosjektrapport Façade Quality requirements Scenario Normalt hendelsesforløp Description Step Action 1 Hent prosjektdata for PD 2 Generer prosjektrapport 3 Lever prosjektrapport Use case 11 Generer prosjektliste Priority 2 Goal Generer og lever prosjektliste Actors Rapport Pre-conditions Post-conditions - Prosjektliste levert Façade Quality requirements Scenario Normalt hendelsesforløp Description Step Action 1 Hent data om prosjekter 2 Generer prosjektliste 3 Lever prosjektliste 17
Use case 12 Generer prosjektdeltagerliste Priority 2 Goal Generer og lever prosjektdeltagerliste Actors Rapport Pre-conditions Post-conditions - prosjektdeltagerliste levert Façade Quality requirements Scenario Normalt hendelsesforløp Description Step Action 1 Hent data om prosjektdeltagere 2 Generer prosjektdeltagerliste 3 Lever prosjektdeltagerliste Use case 13 Oppdater Priority 1 Goal Actors AdminEditor, RegistreringsEditor Pre-conditions - Post-conditions - Data er lagret i database Façade Quality requirements Scenario Normalt hendelsesforløp Description Step Action 1 Systemet oppdaterer databasen 18
3.3 Reference Architecture Analysis Model Figur 3-3 - Reference Architecture Analysis Model Strekene mellom komponentene beskriver kommunikasjonen mellom dem. 19
4 Architecture Model 4.1 Interface & Interaction Specification Figur 4-1 - RegistreringsEditor Interface & Interaction Specification 20
Figur 4-2 - Rapport Interface & Interaction Specification 21
Figur 4-3 - AdminEditor Interface & Interaction Specification Figur 4-4 Sekvensdiagram for Use Case 1: Registrer Timer 22
Figur 4-5 Sekvensdiagram for Use Case 2: Vis timebudsjett for prosjektdeltager Figur 4-6 - Sekvensdiagram for Use Case 4: Vis alle prosjekter 23
4.2 Component Structure Figur 4-7 - Component Structure 24
4.3 Internal Design Figur 4-8 - BCE analyse: Klassediagram 25
Figur 4-9 - Mapping til fokus/auxiliary klasser Knapper og Tekstfelt er aggregeringer av TimeRegistreringsSjema. 26
Figur 4-10 - Internt design av RegistreringsEditor Knapper og Tekstfelt er aggregeringer av TimeRegistreringsSjema. 5 Platform Specific Model 5.1 Component Implementation Model Vi er ikke helt sikre på hva som er fornuftig å ha med her så vi valgte å gå rett til deploymentdiagrammet. Konstruktiv tilbakemelding er velkommen! 27
5.2 Deployment Model Figur 5-1 - Deployment Model Klientsiden inneholder funksjonalitet for å opprette ny timeregistrering, åpne eksisterende lokal timeregistreing for nåværende uke, lagre til lokalt datalager og lagre til sentralt datalager (sentral database på serversiden), og samtlige rapporter. Serversiden inneholder rapporttjenester og oppdateringsfunksjonalitet. 28