University of Oslo Department of Informatics Hours Registration System (HRS) INF 5120 Oblig 2 Skrevet av: Lars Warholm Astrid Magistad Solvor Skaaden Kristine Sæhlie (lwarholm) (astrim) (sjskaade) (krissae) 3. mai 2004
INNHOLD OBLIG 2-0: INNLEDNING...5 OBLIG 2-1: BUSINESS MODEL...6 2-1.1 Scooping Statements Context Statement...6 2-1.1.1. Avgrensninger... 6 2-1.1.2. Aktører og interesser... 6 2-1.1.3. Rikt Bilde... 7 2-1.1.4. Overordnet Virksomhetsprosess... 8 2-1.2 Målmodell...9 2-1.3 Business Resource Model...10 2-1.4 Business Process & Role Model...11 2-1.4.1. Idémyldring: Registrere Timeliste... 11 2-1.4.2. Idémyldring: Registrere Fravær... 12 2-1.4.3. Idémyldring: Hente ut timer... 12 2-1.4.4. Sammenslåing av figurene over... 13 2-1.4.5. WARM-analyse... 14 2-1.4.6. Registrere time... 15 2-1.4.7. Hente ut info... 16 OBLIG 2-2: REQUIREMENTS MODEL... 17 2-2.1 System Boundary Model...17 2-2.1.1. Use case diagram... 17 2-2.1.2. Aktører... 19 2-2.2 Subsystem Grouping Model...19 2-2.2.1. Subsystem Grouping Model... 20 2-2.2.2. Use Case beskrivelser... 21 2-2.3 Reference Architecture Analysis Model...22 2-2.4 Use Case Scenario Model...23 2-2.4.1. Use case 1 & 2, registrere timer... 23 2-2.4.2. Use case 3 & 14, hente ut timer... 24 OBLIG 2-3: ARCHITECTURE MODEL... 25 2-3.1 Interface & Interaction Specification...25 2-3.1.1. Quality of service constraints... 25 2-3.1.2. Interface spesifikasjoner... 26 2-3.1.3. Samarbeid mellom Komponenter... 27-2 -
2-3.1.3.1. Use case 1 og 2, registrere timer... 27 2-3.1.3.2. Use case 3 og 14, hente ut timer... 28 2-3.2 Component Structure...29 2-3.3 Internal Design...30 2-3.3.1. BCE analyse... 30 2-3.3.1.1. BCE-analyse: Use Case 1 og 2, registrere timer... 30 2-3.3.1.2. Klassediagram: Use Case 1 og 2, registrere timer... 31 2-3.3.1.3. BCE-analyse: Use case 3 og 14, hente ut timer... 31 2-3.3.1.4. Klassediagram: Use case 3 og 14, hente ut timer... 32 2-3.3.2. Mapping til focus/auxiliary klasser... 33 2-3.3.2.1. Use case 1 og 2, registrere timer... 33 2-3.3.2.2. Use case 3 og 14,hente ut timer... 34 OBLIG 2-4: PLATFORM SPECIFIC MODEL (PSM)... 35 2-4.1 Component Implementation Model...35 2-4.2 Deployment Model...36 OBLIG 2-5: REFERANSER... 37-3 -
FIGURLISTE Figur 1: Aktører, deres interesser i det nye systemet... 6 Figur 2: Rikt bilde, beskrivelse av situasjonen.... 7 Figur 3: Overordnet virksomhetsprosess.... 8 Figur 4: Målmodell... 9 Figur 5: Business Resource Model... 10 Figur 6: Business Process & Role model for timeregistrering... 11 Figur 7: Business Process & Role model for fravær registrering... 12 Figur 8: Business Process & Role model for timeuthenting... 12 Figur 9: Business Process Model... 13 Figur 10: Overblikk over timeregistreringssystemet... 14 Figur 11: WARM-analyse, registrere timer.... 15 Figur 12: WARM-analyse, hente ut time informasjon... 16 Figur 13: Use Case diagram, system boundary model... 18 Figur 14: Subsystem Grouping Model... 20 Figur 15: Reference Architecture Analysis Model.... 22 Figur 16: Use case scenario modell for use case 1 og 2... 24 Figur 17: Use case scenario modell for use case 3 og 14... 24 Figur 18: Interface spesifikasjoner... 26 Figur 19: Interface & interaction spec. UC 1 & 2... 27 Figur 20: Inreface & interaction spec. UC 3 & 14... 28 Figur 21: Overordnet Component Structure Diagram,... 29 Figur 22: BCE-analyse: UC 1 & 2... 30 Figur 23: Klassediagram; UC1 & 2... 31 Figur 24: BCE-analyse: UC 3 & 14... 31 Figur 25: Klassediagram: UC 3 & 14... 32 Figur 26: Mapping to focus/auxiliary classes, UC 1 & 2... 33 Figur 27: Mapping to focus/auxiliary classes, UC 3 & 14... 34 Figur 28: Component Implementation Model... 35 Figur 29: Deployment Model... 36-4 -
Oblig 2-0: Innledning Dette er obligatorisk oppgave 2 i INF 5120. Følgende problembeskrivelse er gitt: - En bedrift ø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, dere 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). Ut fra denne problembeskrivelsen skal vi i dette dokumentet utvikle en komplett modellbeskrivelse for timeregistreringssystemet ved hjelp av COMET-metodikken. - 5 -
Oblig 2-1: Business Model Dette kapittelet tar for seg innledning og avgrensning til systemet. Først defineres omfang og dagens situasjon med en figur over den overordnede prosessen. Deretter settes målmodellen opp og til slutt Business Resource Model og Business Process & Role Model. 2-1.1 Scooping Statements Context Statement 2-1.1.1. Avgrensninger Vi har valgt å ikke definere en spesifik bedrift, derfor lager vi businessmodellen ut ifra det vi forstår med oppgaveteksten. Vi har definert følgende avgrensninger: - De ansatte har mulighet til å logge seg på systemet hvor enn de befinner seg. - Systemet skal ikke håndtere lønn. Dette kan være en mulig utvidelse. - Timeantallet blir registrert hver mandag kl 00.00. Frem til da kan de ansatte endre så mye de måtte ønske. - Systemet trenger en systemansvarlig. Denne har ansvaret for å administrere brukere og prosjekter i systemet. - Systemet skal ikke kommunisere med eksisterende systemer. 2-1.1.2. Aktører og interesser Figur 1 gir en oversikt over systemets aktører og deres interesser. Figur 1: Aktører, deres interesser i det nye systemet. - 6 -
2-1.1.3. Rikt Bilde Figur 2: Rikt bilde, beskrivelse av situasjonen. De ansatte kan delta på mange forskjellige prosjekter samtidig. De må holde orden på og registrere det timeantallet de bruker på hvert av prosjektene de deltar i. En gang i uken oppdateres timebudsjettet og timelistene resettes. Det finnes en ansvarlig person som har muligheten til å hente ut informasjon om all ressursbruk. Timeregistreringssystemet er en selvstendig enhet som er uavhengig av andre systemer i bedriften. Se figur 2 for rikt bilde som en beskrivelse over situasjonen med det nye timeregistreringssystemet integrert. - 7 -
2-1.1.4. Overordnet Virksomhetsprosess Figur 3: Overordnet virksomhetsprosess. Figur 3 viser overordnet flyten mellom aktører og en nytt timeregistreringssystem. En ansatt deltar i prosjekter og eventuelt andre ting i som skjer i bedriften. Dette må registreres og holdes orden på i timebudsjettet. De grå feltene i figuren blir utført av systemet, mens de hvite er menneskelige aktiviteter. - 8 -
2-1.2 Målmodell Målmodellen viser bedriftens målsetninger med å innføre et nytt datasystem for timeregistrering. I figur 4 vises øverst de overordnede målene som igjen er delt opp i enkeltmål. Hovedmålet med et nytt timeregistreringssystem er å få en oversikt over hvordan ressursene, her i arbeidstimer, fordeles ut i prosjekter samt å holde rede på en avspassering og ferie oversikt. Oversikt over ressursbruk Registrere fravær Registrere timeliste Hente ut timer Registrer prosjekttimer Registrer ansattimer Registrer sykefravær Registrer ferie Registrer avspassering Hent ansattimer Hent prosjekttimer Hent totale timer Hent fraværtimer Figur 4: Målmodell. - 9 -
2-1.3 Business Resource Model Business Resource Model er en informasjonsmodell som identifiserer og definerer hovedkomponentene i det domenet som er relevant for det systemet som skal lages, se figur 5. Figur 5: Business Resource Model - 10 -
2-1.4 Business Process & Role Model Business Process & Role Model identifiserer og detaljerer foretningenes prosesser som skal støttes av et nytt datasystem. Dette for å forklare rollene til produktet og dens komponenter. Først kobles de tre hovedpunktene opp mot forskjellige mål for deretter å utføre en WARM analyse for timeregistreringssystemet. Vi ser for oss at ansatte må registrere arbeidstimer og eventuelle fraværstimer før disse kan bli hentet ut. 2-1.4.1. Idémyldring: Registrere Timeliste Figur 6 viser oppførsel og delmål for registrer timeliste og hvordan de er tilknyttet RegistrerTimeProsess. Figur 6: Business Process & Role model for timeregistrering - 11 -
2-1.4.2. Idémyldring: Registrere Fravær Figur 7 viser oppførsel og delmål for registrer fravær samt tilknyttet RegistrerFraværProsess. Figur 7: Business Process & Role model for fravær registrering 2-1.4.3. Idémyldring: Hente ut timer Figur 8 viser oppførsel og delmål for hent ut timer samt tilknyttet HentUtInfoProsess. Figur 8: Business Process & Role model for timeuthenting - 12 -
2-1.4.4. Sammenslåing av figurene over Etter litt diskusjon viser det seg at registrere fravær og registrere timeliste vil ha de samme operasjonene. I den forbindelse velger vi å slå sammen prosessene RegistrereFraværProsess og RegistrereTimelisteProsess til Registrere time. En time som skal registreres kan da være alt fra prosjekttime til syketime eller ferietime, se figur 9. Figur 9: Business Process Model - 13 -
2-1.4.5. WARM-analyse Work Analysis Refinement Model (WARM) er en analyse av arbeidsprosessen. Den gir et overblikk over de ulike hovedprosessene og går grundigere inn på disse. Her skilles det mellom aktør og system. I figur 10 ser vi den overordnede prosessen i timeregistreringssystemet. Figur 11 tar for seg registrere time-delen, mens i figur 12 ser vi hente ut-prosessen. Figur 10: Overblikk over timeregistreringssystemet - 14 -
2-1.4.6. Registrere time Figur 11: WARM-analyse, registrere timer. - 15 -
2-1.4.7. Hente ut info Figur 12: WARM-analyse, hente ut time informasjon - 16 -
Oblig 2-2: Requirements Model Dette kapittelet tar for seg modelleringen av funksjonelle krav. Først kommer use case diagrammet med aktørspesifikasjoner. Deretter kommer et nytt use case diagram med grupperinger i subsystemer samt use case scenarioer. Videre er det blitt gjennomført en RA analyse som resulterte i en komponent-/klassemodell. Til slutt er det laget use case scenario modeller i form av sekvensdiagrammer som beskriver hvordan komponenter samarbeider for å realisere use case ene. 2-2.1 System Boundary Model System Boundary Model beskriver systemet som skal lages med dets funksjonelle egenskaper og avgrensninger, samt aktører og deres ansvar. 2-2.1.1. Use case diagram Figur 13 beskriver overordnet use case diagram med alle aktører og deres interaksjon med timeregistreringssystemet. Se punkt 2-2.1.2. for aktørbeskrivelser. I alle diagrammer og spesifikasjoner av use case velger vi å slå sammen use case 1 og 2 samt use case 3 og 14. Det er disse vi konsentrerer oss om i det resterende dokumentet. - 17 -
Figur 13: Use Case diagram, system boundary model - 18 -
2-2.1.2. Aktører Når det gjelder aktørene er Ansatt og Ansvarlig de to viktige aktørene for dette systemet. Administrator blir en støtteaktør som hovedsakelig står for vedlikehold av systemet. Dennes oppgaver blir derfor støtteoppgaver for å få systemet til å fungere. Av denne grunn tar vi kun med Administrator i Subsystem Grouping Model. Etter dette ser vi bort fra å modellere administrators oppaver. Ansatt Ansatt i bedriften som deltar på prosjekter og andre oppgaver i bedriftens regi. Denne har til ansvar å registrere alle timer som blir brukt i forskjellige prosjekter, samt ferie, avspasering og syketimer. Ansatt har også mulighet for å hente ut sitt timebudsjett. Ansvarlig Utvalgte ansatte i bedriften som skal ha tilgang til å se alle timeantall brukt per ansatt og per prosjekt. Denne har tilgang til all informasjon om ferie, avspaseringer, sykdom og ressursbruk i prosjekter. Administrator En utvalgt ansatt i bedriften som har tilgang til å administrere brukere og prosjekter i systemet. Denne har en vedlikeholdsfunksjon. 2-2.2 Subsystem Grouping Model Subsystem Grouping Model er en type use case diagram, der de funksjonelle kravene er gruppert ettersom hvordan de passer sammen. Det vil si at de som gjør tilsvarende oppgaver og hører til samme aktør blir gruppert sammen. - 19 -
2-2.2.1. Subsystem Grouping Model Figur 14: Subsystem Grouping Model - 20 -
2-2.2.2. Use Case beskrivelser Use case 1 & 2 Mål Aktør Prebetingelse Postbetingelse Facade Kvalitets krav Registrer Timer Registrere timer for ansatte i bedriften. Ansatt Det er tid for å registrere timer. Arbeids-, prosjekt-, avspaserings-, syke- og ferietimer er registrert i systemet. Use case 2 inngår i use case 1 beskrivelsen. Ansatte kan kun registrere egne timer. Ansatt kan når som helst avbryte registreringen, og ingen informasjon er blitt registrert. Scenario - Beskrivelse Steg Hendelse 1 Ansatt velger å registrere timer 2 Systemet ber om antall timer og type timer 3 Ansatt fyller inn nødvendig informasjon 4 Systemet validerer oppgitt informasjon 5 Systemet oppdaterer timebudsjettet (use case 2) 6 Systemet lagrer informasjon Variasjon 4a Validering ikke ok. 1 Bruker får oppgitt feilmelding og blir bedt om å fylle inn nødvendig informasjon på nytt. 2 Fortsetter fra punkt 3. Use case 3 & 14 Hent time informasjon Mål Utskrift av forskjellig type time informasjon Aktør Ansatt, Ansvarlig Prebetingelse - Postbetingelse Ønsket informasjon skrevet ut Facade Use case 14 inngår i use case 3 beskrivelsen. Kvalitets krav Ansatt kan kun hente ut informasjon om egne timer. Ansvarlig har tilgang til all type time informasjon Scenario - Beskrivelse Steg Hendelse 1 Bruker velger å hente ut time informasjon 2 Systemet ber bruker om å spesifisere type timer 3 Bruker oppgir typespesifikasjon 4 Systemet validerer spesifikasjonen oppgitt 5 Systemet henter lagret informasjon (use case 14) 6 Systemet skriver ut informasjonen Variasjon 4a Bruker har oppgitt ugyldig data - 21 -
1 Bruker får oppgitt feilmelding og blir bedt om å fylle inn nødvendig informasjon på nytt. 2 Fortsetter fra punkt 3. 2-2.3 Reference Architecture Analysis Model Reference Architecture Analysis Model gir en oversikt over komponentene i systemet. Den er et bindeledd mellom analyse og design. Vi trenger to grensesnittkomponenter, en som tar for seg registreringen og tilhører aktøren ansatt, samt en som tar for seg uthentingen av timer og tilhører aktøren ansvarlig. Begge disse er koblet mot hver sin service, henholdsvis RegistrerService og HenteUtService som igjen er koblet mor samme lager, TimeLager. Se figur 15. Figur 15: Reference Architecture Analysis Model. - 22 -
2-2.4 Use Case Scenario Model Use Case Scenario Model: Viser flyt mellom de ulike usecasene i forhold til aktør og system. Viser ressurser som resultat av handlinger. Vi har tatt utgangspunkt i use case beskrivelsene i punkt 2-2.2.2. 2-2.4.1. Use case 1 & 2, registrere timer - 23 -
Figur 16: Use case scenario modell for use case 1 og 2 2-2.4.2. Use case 3 & 14, hente ut timer Figur 17: Use case scenario modell for use case 3 og 14-24 -
Oblig 2-3: Architecture Model Arkitekturmodellen beskriver den overordnede arkitekturen for et system. I tillegg viser den hvordan systemet er inndelt i komponenter. Denne delen starter med generelle kvalitetskrav, og fortsetter grensesnittspesifikasjoner samt samarbeid komponentene i mellom. Til slutt kommer komponent diagram etterfulgt av BCE-analyse. 2-3.1 Interface & Interaction Specification Interface & Interaction Specification beskriver komponentgrensesnitt og samarbeid mellom komponenter. 2-3.1.1. Quality of service constraints Vi har satt følgende QoS-skranker: Functionality Security Ingen uvedkommende skal kunne få tilgang til opplysninger uten forhåndsklarering. B = Brukere som får tilgang til opplysninger. OCL: Ұ (b : B b har forhåndsklarering) Accuracy Reliability Faulttolerance Usability Operability Alle rapporter fra systemet må være riktige. R = Rapporter fra systemet OCL: Ұ (r : R r er riktig) Systemet støtter ACID, data skal ikke blandes ved samtidig lagring. Hvis systemet er nede, skal ikke data bli berørt/endret. D = Data i systemet OCL: Ұ (d1 : D ٨ d2 : D d1 lagres samtidig som d2 -> d1 = d1@pre ٨ d2 = d2@pre) Ұ (d i D systemet går ned -> d = d@pre) Systemet skal gi gode og forståelige tilbakemeldinger. T = tilbakemeldinger i systemet OCL: Ұ (t : T t er god ٨ t er forståelig) Understandability Systemet må være selvforklarende og enkelt å bruke. O = Operasjoner som systemet skal gjøre for brukeren - 25 -
OCL: Ұ (o : O o er selvforklarende for brukeren ٨ o er enkel å utføre) Efficiency Timebehaviour Systemet skal gi tekstlig tilbakemelding normalt innen 0,5 sek, med sikkerhetsmargin på 10 sek. "Progressbar" for å vise brukeren at systemet jobber. T = tilbakemeldinger i systemet O = operasjoner som gjøres i systemet Ti = Tilstand i systemet OCL: Ұ (o : O З (t : T o -> t)) If Ti = normal then Ұ (t : T t er tekstlig ٨ t kommer innen 0,5sek) else Ұ (t : T t er tekstlig ٨ t kommer innen 10 sek) endif 2-3.1.2. Interface spesifikasjoner Her beskriver vi grensesnittene til registreringstjenesten (RS), data-hentingstjenesten (HUS) og datalagringstjenesten (TL). Figur 18 illustrerer dette. Figur 18: Interface spesifikasjoner - 26 -
2-3.1.3. Samarbeid mellom Komponenter Viser flyt mellom ulike komponenter. Vi har tatt utgangspunkt i use case beskrivelsene i punkt 2-2.2.2. 2-3.1.3.1. Use case 1 og 2, registrere timer Figur 19: Interface & interaction spec. UC 1 & 2-27 -
2-3.1.3.2. Use case 3 og 14, hente ut timer Figur 20: Inreface & interaction spec. UC 3 & 14-28 -
2-3.2 Component Structure Figur 21 er en oversikt over komponenter med interface. Figuren er en utvidelse av figur 15, referance architecture analysis-modellen. På figuren skal krysset illustrere at komponenten er et verktøy, komponent-tegnet skal illustrere at vi snakker om en tjeneste, mens kuben illustrerer at komponenten er et lager. Figur 21: Overordnet Component Structure Diagram, - 29 -
2-3.3 Internal Design 2-3.3.1. BCE analyse BCE analyse gjennomføres for å finne grensesnittkomponenter. Vi tar utgangspunkt i tidligere valgte usecase for å finne disse grensesnittene. Her har vi også valgt å dele de opp i use case 1 & 2 og use case 3 & 14. 2-3.3.1.1. BCE-analyse: Use Case 1 og 2, registrere timer Figur 22: BCE-analyse: UC 1 & 2-30 -
2-3.3.1.2. Klassediagram: Use Case 1 og 2, registrere timer Her har vi tatt utgangspunkt i BCE-analysen i punkt 2-3.3.1.1. Figur 23: Klassediagram; UC1 & 2 2-3.3.1.3. BCE-analyse: Use case 3 og 14, hente ut timer Figur 24: BCE-analyse: UC 3 & 14-31 -
2-3.3.1.4. Klassediagram: Use case 3 og 14, hente ut timer Her har vi tatt utgangspunkt i BCE-analysen i punkt 2-3.3.1.3. Figur 25: Klassediagram: UC 3 & 14-32 -
2-3.3.2. Mapping til focus/auxiliary klasser Her beskriver vi grensesnittskomponenter funnet i BCE-analysen. 2-3.3.2.1. Use case 1 og 2, registrere timer Her har vi tatt utgangspunkt i klassediagrammet i punkt 2-3.3.1.2. Figur 26: Mapping to focus/auxiliary classes, UC 1 & 2-33 -
2-3.3.2.2. Use case 3 og 14,hente ut timer Her har vi tatt utgangspunkt i klassediagrammet i punkt 2-3.3.1.4. Figur 27: Mapping to focus/auxiliary classes, UC 3 & 14-34 -
Oblig 2-4: Platform Specific Model (PSM) Platformspesifikk modell beskriver hvordan komponentene skal implementeres på den bestemte platformen. For å komme frem til de platform spesifikke modellene har vi tatt utgangspunkt i komponent struktur modellen i punkt 2-3.2. Vi har valgt J2EE. Til slutt har vi satt inn deployment diagrammet. 2-4.1 Component Implementation Model Figur 28 viser en implementasjons design modell av komponentene. Figur 28: Component Implementation Model - 35 -
2-4.2 Deployment Model Figur 29 viser et deployering diagram av de ulike komponentene. TCP/IP http Java Java Java Java Figur 29: Deployment Model - 36 -
Oblig 2-5: Referanser [1] Berre, Arne J., Elvesæter, B., Aagedal, Jan Ø., Oldevik, J., Solberg, A., Nordmoen, B. 2004. COMET Componet And Model-based development Methology, COMET Methology Handbook version 2.4. SINTEF ICT. [2] Forelesningsnotater og foiler fra INF 5120. - 37 -