Oblig2 i INF5120 Modellering med objekter UiO V04, Timelisteføringssystem Ver 6. 040428 Gruppe 1: Fredrik Melsom Klausen, Andreas Limyr, Odd-Wiking Rahlff, Tho Diu Tang 1...1 2. BUSINESS MODEL...2 2.1 SCOPING STATEMENTS CONTEXT STATEMENT...2 2.1.1 Egne avgrensinger...2 2.1.2 Aktører og interesser...3 2.1.2.1 Use Case Diagram - rikt bilde...3 2.1.3 Overordnet Virksomhetsprosess...4 2.1.3.1 Aktivitetsdiagram...4 2.2 MÅLHIERARKI...5 2.3 BUSINESS RESOURCE MODEL...5 2.4 BUSINESS PROCESS & ROLE MODEL...7 2.4.1.1 Aktivitetsdiagrammer...8 3. REQUIREMENTS MODEL...9 3.1 SYSTEM BOUNDARY MODEL...9 3.1.1 aktører og use cases...10 3.2 SUBSYSTEM GROUPING MODEL...10 3.2.1.1 Use Case scenario Model...10 3.3 REFERENCE ARCHITECTURE ANALYSIS MODEL...12 3.3.1 Identifiserte komponenter...12 4. ARCHITECTURE MODEL...13 4.1 INTERFACE & INTERACTION SPECIFICATION...13 4.1.1.1 Klassediagrammer...13 4.1.1.2 QoS constraints...13 4.1.2 Samarbeid mellom komponenter...14 4.1.2.1 Sekvensdiagrammer med utgangspunkt i use casene (på komponentnivå)...14 4.2 COMPONENT STRUCTURE...15 4.2.1 Klassediagram...17 4.3 INTERNAL DESIGN...17 4.3.1.1 BCE analyse og klassediagrammer...18 4.3.2 Mapping til focus/auxiliary klasser...18 4.3.2.1 Klassediagrammer...20 4.4 GRENSESNITTBESKRIVELSER FOR NOEN AV KOMPONENTENE (PRELIMINÆR UI-SKISSE)...20 5. PLATFORM SPECIFIC MODELL (FOR 1 MODELL)...22 1. 5.1 COMPONENT IMPLEMENTATION MODEL...22 5.1.1 J2EE implementasjonsdesign vha UML profil...22 5.1.1.1 klassediagrammer...22 5.2 DEPLOYMENT MODEL...22 5.2.1 Deployering av komponenter på infrastruktur...22 INF5120 Oblig 2, Gruppe 1, V2004 1
2. Business Model 2.1 Scoping Statements Context Statement Vision of Change er gitt i oppgavedefinisjonen. 2.1.1Egne avgrensinger Vi velger å fokusere på en liten bedrift (SMB). Vi antar fastlønn, slik at lønnsutbetalingssystemet ikke er en del av løsningen vår. Vi skjelner mellom tre roller: Prosjektmedarbeider, Prosjektleder og Administrator. (nytt scope) Vi vil videre i dokumentet fokusere på de tre sentrale rollene. Prosjektmedarbeider (PM) har adgang til å fylle ut og inspisere egen timeliste. Prosjektleder (PL) har adgang til å sette opp og inspisere planlagt prosjektbelegg samt rapportert prosjektpådrag på sitt/sine prosjekter. PL kan også godkjenne timeføring og markere at et prosjekt skal avsluttes. Administrator (ADM) har adgang til alt, full inspeksjons- og endringsrett samt mulighet for å opprette/avslutte prosjekter og allokere Prosjektleder og Prosjektmedarbeidere på prosjektene. Administrator er forøvrig selv prosjektleder for minst ett prosjekt, nemlig prosjektet Administrasjon. Vi antar for enkelthetens skyld at: Alle jobber i full 100% stilling og 40 t/uke. Bordet fanger hver fredag ettermiddag for ukentlig timeføring for prosjektmedarbeiderne. Prosjektleder godkjenner hver måned de førte timene (før fakturering). Ferie og avspasering føres på egne interne prosjektnumre med administrator som prosjektleder. Dermed oppnår vi at ferie kan tas høyde for uten å måtte handtere dette på annen måte enn et hvilkensomhelst annet prosjekt. INF5120 Oblig 2, Gruppe 1, V2004 2
2.1.2Aktører og interesser Prosjektmedarbeider Registrere timer Få oversikt over eget timeforbruk Sette opp personlig timebudsjett (antatt belegg pr prosjekt pr mnd) Prosjektleder Se oversikt over egne prosjekter Godkjenne timeføring på egne prosjekter Avslutte prosjekt Administrator Opprette/endre/slette ansatte Opprette/endre/avslutte prosjekt Allokere ansatte til roller i prosjektene Få totaloversikt over timer/budsjett/prosjekter Legge inn eller rette manglende eller feilførte timer på oppfordring av prosjektmedarbeiderne når dette trengs 2.1.2.1Use Case Diagram - rikt bilde INF5120 Oblig 2, Gruppe 1, V2004 3
2.1.3Overordnet Virksomhetsprosess 2.1.3.1Aktivitetsdiagram Fargekoding: Grå bokser viser aktiviteter som systemet er direkte involvert i HRS-systemet Hvite bokser er aktiviteter utenfor HRS-systemet Som du ser ligger noen av boksene på grenselinjene mellom to roller. Dette betyr at begge rollene er involvert i aktiviteten. F.eks samarbeider prosjektleder med administrator for å avslutte og sluttfakturere prosjektet. INF5120 Oblig 2, Gruppe 1, V2004 4
2.2 Målhierarki 2.3 Business Resource Model INF5120 Oblig 2, Gruppe 1, V2004 5
Vi likte godt selv den enkle versjonen av klassediagrammet her også: INF5120 Oblig 2, Gruppe 1, V2004 6
2.4 Business Process & Role Model (Virksomhetsprosesser (2 nivåer), roller) INF5120 Oblig 2, Gruppe 1, V2004 7
2.4.1.1Aktivitetsdiagrammer Eksempelet her er timeføringen: H: Human step T: Tool step I: Immediate step INF5120 Oblig 2, Gruppe 1, V2004 8
3. Requirements Model 3.1 System Boundary Model INF5120 Oblig 2, Gruppe 1, V2004 9
3.1.1aktører og use cases 3.2 Subsystem Grouping Model Vi ser at administrasjon av de ansatte ikke akkurat er en del av business-caset, men vi har tatt det med likevel. Vi kommer imidlertid ikke til å legge mer vekt på dette i den videre diskusjonen. 3.2.1.1Use Case scenario Model Vi har valgt å fokusere på to forskjellige representative use cases for de tre brukerkategoriene. INF5120 Oblig 2, Gruppe 1, V2004 10
Use case 2 Se oversikt over prosjekter Prioritet 2 Mål Holde oversikt over ressurser Aktør(er) Administrator, Prosjektleder Prebetingelse Bruker er logget inn Postbetingelse - Fasade Kvalitets krav Scenario Beskrivelse Steg Handling 1 Ber om oversikt 2 Får oversikt (ser prosjektpådrag på de prosjektene brukeren har tilgang til) 3 Logger av Use case 5 Registrere timer Prioritet 1 Mål Holde oversikt over forbruk pr ansatt Aktør(er) Medarbeider, Administrator Prebetingelse Bruker er innlogget Bruker er tilknyttet minst ett prosjekt Postbetingelse Timene til medarbeider er registrert i databasen på den/de gjeldende uka/ukene. Fasade Kvalitets krav Scenario Beskrivelse Steg Handling 1 Velger å registrere timer 3 Velger rett uke (default er inneværende uke) 4 Velger rett(e) prosjekt(er) å fylle ut (default for utfylling er siste N ukers prosjekter som Medarbeider har fylt ut før) 4a Ved nytt prosjekt: Velg fra prosjektmeny 5 Timefører prosjektene for uken som er angitt 6 Signalisere lagring INF5120 Oblig 2, Gruppe 1, V2004 11
3.3 Reference Architecture Analysis Model 3.3.1Identifiserte komponenter Vi har identifisert flg. komponenter: INF5120 Oblig 2, Gruppe 1, V2004 12
4. Architecture Model I denne oppgaven fikk vi en aha-opplevelse ved å se at systemdesignet var en iterativ prosess som både omfattet top-down og bottom-up design. Ved en lineær skriftlig fremstilling kommer dette ikke tydelig frem, da alt ser ut som om det er drevet fremover av en mirakuløs målrettet prosess, mens det altså i virkeligheten er et resultat av kvalifiserte antagelser om grensesnitt koplet med behovsanalysen fra tidligere. 4.1 Interface & Interaction Specification 4.1.1.1Klassediagrammer 4.1.1.2QoS constraints Vi ønsker at HRS skal tilfredsstille flg. QoS-krav (ikke-funksjonelle krav): Oppetid: HRS skal være tilgjengelig minst 99 % av tida Integritet: Timeførte data skal ikke kunne endres utilsiktet Respons: HRS skal kunne tåle at alle bedriftens ansatte fører timer samtidig, uten at responstida blir mer enn 2 sekunder. Lagring: Data skal av regnskapstekniske årsaker bevares i minst tre år. INF5120 Oblig 2, Gruppe 1, V2004 13
4.1.2Samarbeid mellom komponenter 4.1.2.1Sekvensdiagrammer med utgangspunkt i use casene (på komponentnivå) Her har vi valgt å se på TimeføringsEditoren: INF5120 Oblig 2, Gruppe 1, V2004 14
4.2 Component Structure Og med ytterligere detaljering av TimeføringsEditoren: INF5120 Oblig 2, Gruppe 1, V2004 15
Og tilsvarende: Og nå har vi skjønt poenget: I og med at vi i følge oppgaven ikke skulle følge WARM, har vi ikke laget noen arbeidsflytmodell basert på en raffinering av WARM, men har konsentrert oss om UML sekvensdiagram for komponentinteraksjon. INF5120 Oblig 2, Gruppe 1, V2004 16
4.2.1Klassediagram Vi har klassene Ansatt (med subtypene Prosjektmedarbeider, Prosjektleder og Administrator) og Prosjekt. Timelisten En timeliste, Timeliste, er egentlig en vektor i relasjonen mellom Ansatt og Prosjekt gjennom prosjektløpet f. eks på format av antall timer forbrukt over dagene i året: (4, 8, 8, 6, 2, 0, 0, 8, 8, 5, 1,...). Det som brukeren kaller timelisten er da egentlig en collection av Timeliste. Timeliste planlagt En planlagt timeliste TimelisteBudsjett angir antatt fremtidig belegg for Ansatt på Prosjekt. Dette blir altså en helt tilsvarende vektor som timeliste. Forskjellen mellom planlagt tidsforbruk og reell bruk, er avvik. Det kumulerte avviket er interessant, for det viser hvorvidt du ligger i forkant eller etter planlagt forbruk. 4.3 Internal Design (for subkomponenter i valgt applikasjonskomponent) INF5120 Oblig 2, Gruppe 1, V2004 17
4.3.1.1BCE analyse og klassediagrammer Her utvider vi nå use-caset fra sist med detaljer: Use case 5 Registrere timer (detaljert) Prioritet 1 Mål Holde oversikt over forbruk pr ansatt Aktør(er) Medarbeider, Administrator Prebetingelse Bruker er innlogget Bruker er tilknyttet minst ett prosjekt Postbetingelse Timene til medarbeider er registrert i databasen på den/de gjeldende uka/ukene. Fasade Kvalitets krav Scenario Beskrivelse Steg Handling 1 Bruker velger Registrer timer i TimeføringsEditoren 2 TimeføringsEditoren ber TimeføringsService om å hente frem timelista og aktuelle prosjekter for brukeren. (default for timelista er inneværende ukes timelister (1 pr prosjekt pr ansatt), default for utfylling av prosjekt er siste N ukers prosjekter som brukeren har fylt ut før) 2b Bruker velger evt en annen uke. 2c Bruker legger evt til nytt prosjekt. (Menyvalg) 3 TimeføringsEditor viser frem tabell over uke og prosjektnavn. 4 Bruker timefører prosjektene for uken som er angitt 5 Bruker velger Lagre timeliste i TimeføringsEditoren 6 TimeføringsEditor ber TimeføringsService om å lagre timelistene. 7 TimeføringsService lagrer timelistene og gir melding om at dette har gått bra. 8 TimeføringsEditor viser Timelisten er lagret!. 4.3.2Mapping til focus/auxiliary klasser Her var det rimelig tynt i COMET angående kokebok på BCE-analyse, men vi kilte iherdig på og tegnet egne ikoner: INF5120 Oblig 2, Gruppe 1, V2004 18
O INF5120 Oblig 2, Gruppe 1, V2004 19
g derfra: 4.3.2.1Klassediagrammer 4.4 Grensesnittbeskrivelser for noen av komponentene (preliminær UI-skisse) TimeFøring Fylles ut av Ansatt (Ansatt) ved ukeslutt (fredag/mandag). Hun velger uke (default=inneværende uke) og angir hvor mye hun har jobbet gjennom ukedagene på de forskjellige prosjektene. Mulighet for å velge fra liste av aktive prosjekter (default=de prosjektene hun tidligere har angitt å jobbe på). Horisontalt: Ukedager Vertikalt: Prosjekter som er jobbet på. TimeføringBudsjett Brukes av Person (Ansatt) for å føre opp hvor mye hun er antatt å jobbe på prosjektene. Viser evt over/underbooking, f.eks i mnd 6 er planlagt å jobbe 120%! Horisontalt: Måneder Vertikalt: Prosjektene hun skal jobbe på ProsjektManager Brukes av Ansatt (Prosjektleder) ved månedsslutt (eller før) for å inspisere hvor stort pådraget er fra prosjektmedarbeiderne. Fylles automatisk med basis i timelistene. Her kan prosjektleder planlegge pådraget fra prosjektmedarbeiderne på månedsbasis. (Budsjett) Horisontalt: Måneder Vertikalt: Ansatte Horisontalt: Uker Vertikalt: Prosjektmedarbeidere på dette prosjektet. ProsjektManager brukes også av Ansatt (Prosjektleder/Administrerende) når som helst for å finne ut hvor mye det er jobbet på alle prosjektene i bedriften. Viser både INF5120 Oblig 2, Gruppe 1, V2004 20
reelt og planlagt pådrag og avviket mellom disse som grunnlag for replanlegging eller andre tiltak. Horisontalt: Måneder Vertikalt: Prosjekter (eller annet view: Ansatte) INF5120 Oblig 2, Gruppe 1, V2004 21
5. Platform Specific Modell (for 1 modell) Denne delen var vi svært usikre på. Det står lite i COMET, så dette ble tynt mot slutten. 5.1 Component Implementation Model 5.1.1J2EE implementasjonsdesign vha UML profil 5.1.1.1klassediagrammer 5.2 Deployment Model 5.2.1Deployering av komponenter på infrastruktur Vi antar at vi utplasserer komponentene slik at alle kjører som webapplikasjoner. Dessuten: Alle kan kjøre Timeføring AC. Kun Administrator har tilgang til å kjøre AnsattManager AC Alle prosjektledere kan kjøre ProsjektManager AC. INF5120 Oblig 2, Gruppe 1, V2004 22