INF 5120 Obligatorisk oppgave 2 Timeregistreringssystem (Hour Registration System HRS) Gruppe 14: Mats Bue, Harald Børresen, Vegard Dehlen Del 1 Business Model Aktører og interesser Rich Picture En enkel oversikt over hovedobjektene i systemet. En ansatt registrerer timer han/hun jobber med et bestemt prosjekt. På samme måte har flere ansatte jobbet på det samme prosjektet.
Overordnet virksomhetsprosess Ansatt Personalsjef HRS Sjef Prosjektleder Admin/Drift Målhierarki
Business Resource Model En informasjonsmodell som identifiserer og definerer hovedtingene og konseptene for området som er relevant for produktet. Business Process and Role Modell For et såpass enkelt system som dette, uten noen forretningsvirksomhet å modellere, blir denne modellen veldig enkel.
Del 2 Requirements Model System Boundary Model Overordnet Overvåke timeforbruket til de ansatte og styre lønnsutbetaling Registrere timer og se sitt eget timebudsjett Ansatt Personalsjef HRS Sjef Få oversikt over ressursbruk i hele bedriften Få oversikt over ressursbruk i prosjektet Prosjektleder Admin/Drift Vedlikeholde systemet
Use-Case oversikt Use-Case for HRS-systemet:
Subsystem grouping Use Case diagram Use Case beskrivelser Use Case 1 Registrere timer Prioritet 1 Mål En ansatt skal registrere de timene han har jobbet Aktører Ansatt Prekondisjoner Ingen Postkondisjoner Timene har blitt registrert i systemet Fasade Kvalitetskrav En ansatt må kun ha mulighet til å registrere timer for seg selv, så sikker innlogging er nødvendig Scenario Steg Handling
1 Ansatt logger seg inn på systemet 2 Ansatt velger å registrere timer fra menyen 3 Ansatt velger et prosjekt og registrerer antall timer han har jobbet med dette, gjentar for alle prosjektene som den ansatte har jobbet med denne uken 4 Ansatt logger seg ut av systemet Use Case 2 Se på eget timeforbruk Prioritet 4 Mål En ansatt skal kunne se på hvor mange timer han har jobbet til sammen denne måneden, og se eventuelle opparbeidede timer som kan tas ut i ferie Aktører Ansatt Prekondisjoner Ingen Postkondisjoner Ingen Fasade Kvalitetskrav En ansatt må kun ha mulighet til å se på sitt eget timebudsjett, så sikker innlogging er nødvendig Scenario Steg Handling 1 Ansatt logger seg inn på systemet 2 Ansatt velger å se på timebudsjett fra menyen 3 Ansatt ser på timebudsjettet 4 Ansatt logger seg ut av systemet Use Case 3 Se på ansattes timeforbruk Prioritet 5 Mål Personalsjefen skal kunne se på timeforbruket til de ansatte i bedriften for å få oversikt over hvor mye hver enkelt jobber med hensyn på lønnsutbetaling, overtid, ferie osv. Aktører Personalsjef Prekondisjoner Ingen Postkondisjoner Ingen Fasade Kvalitetskrav Kun personalsjefen skal ha tilgang til disse dataene, så sikker innlogging kreves Scenario Steg Handling 1 Personalsjefen logger seg inn i systemet 2 Personalsjef velger hvilken ansatt han vil se på 3 Timebudsjettet til den valgte ansatte vises 4 Evt ny ansatt velges, og steg 2-3 gjentas 5 Personalsjef logger seg ut av systemet. Use Case 4 Se på ressursbruk i eget prosjekt
Prioritet 5 Mål Prosjektleder skal kunne se på timeforbruket i sitt eget prosjekt. Aktører Prosjektleder Prekondisjoner Ingen Postkondisjoner Ingen Fasade Kvalitetskrav Kun prosjektleder skal ha tilgang til disse dataene, og kun for sitt eget prosjekt, så sikker innlogging kreves. Scenario Steg Handling 1 Prosjektleder logger seg inn i systemet 2 Prosjektleder velger prosjekt (kan være leder for flere prosjekt) 3 Timeforbruk i prosjektet vises 4 Prosjektleder logger seg ut av systemet. Use Case 5 Se på ressursbruk i hele bedriften Prioritet 6 Mål Sjefen for firmaet skal kunne se hvor mange timer alle de ansatte jobber til sammen. Aktører Sjef Prekondisjoner Ingen Postkondisjoner Ingen Fasade Kvalitetskrav Kun sjefen skal ha tilgang til disse dataene, så sikker innlogging kreves Scenario Steg Handling 1 Sjefen logger seg inn i systemet 2 Timeforbruk i firmaet vises 3 Sjefen logger seg ut av systemet. Use Case 6 Vedlikeholde systemet Prioritet 2 Mål Administrator for systemet skal kunne vedlikeholde systemet ved å legge til/fjerne brukere, endre rettigheter, legge til/fjerne prosjekter osv. Aktører Admin/Drift Prekondisjoner Ingen Postkondisjoner Ingen Fasade Kvalitetskrav Kun administrator for systemet skal ha mulighet for å vedlikeholde systemet, så sikker innlogging kreves Scenario Steg Handling 1 Administrator logger seg inn i systemet
2 Administrator velger handling 3 Skjermbilde for den gitte handlingen vises, og administrator fyller ut nødvendige endringer 4 Evt ny handling skal utføres, steg 2-3 gjentas 5 Administrator logger seg ut av systemet. Reference Architecture Analysis Model Klassediagram
Use Case Scenario Model Sekvensdiagrammer Registrere time Se på eget timebudsjett
Vedlikeholde system
Architecture Modell Grensesnittbeskrivelser Klassediagram QoS constraints Functionality: Viktig Reliability: Mindre viktig (Ikke et forretningskritisk system) Usability: Veldig viktig Effeciency: Mindre viktig (Funksjonalitet krever lite ressurser) Maintainability: Veldig viktig Portability: Mindre viktig
ITimeService ITimeService login(in ansattid:int, In password: String): LoginStatus logout() registrerarbeid(in ansattid:int, In prosjektid:int, In uke:int, In år:int, In antalltimer:int) seansatt(in ansattid:int): Ansatt hentalleansatte(): Ansatt List seprosjekttimeforbruk(in prosjektid:int): ProsjektTimeforbruk hentalleprosjekter(): Prosjekt List IAdminService IAdminService login(in ansattid:int, In password: String): boolean logout() leggtilansatt(in ansatt:ansatt): boolean endreansatt(in ansatt: Ansatt): boolean slettansatt(in ansattid: int): boolean leggtilprosjekt(in prosjekt:prosjekt): boolean endreprosjekt(in prosjekt:prosjekt): boolean slettprosjekt(in prosjektid:int): boolean ITimeInfo ITimeInfo finnansatt(in ansattid:int): Ansatt sjekkpassord(in ansattid:int, In passord:string): boolean finnalleansatteid(): int List finnprosjekt(in prosjektid:int): Prosjekt finnalleprosjektid(): int List leggtilansatt(in ansatt:ansatt): boolean endreansatt(in ansatt: Ansatt): boolean slettansatt(in ansattid:int): boolean leggtilprosjekt(in prosjekt:prosjekt): boolean endreprosjekt(in prosjekt:prosjekt): boolean slettprosjekt(in prosjektid:int): boolean
PIM datatyper Vi har brukt flere egne datatyper for å gjøre grensesnittene enklere, disse er som følger: Ansatt int ansattid int ansatttype (*) string passord string navn List Arbeid Prosjekt int prosjektid string prosjektnavn int prosjektlederid LoginStatus int ansattid int ansatttype (*) ProsjektTimeforbruk int prosjektid int timerdennemåned int timertotalt (*) = kan være arbeider, prosjektleder, personalsjef, sjef eller administrator
Component Structure for administrasjonskomponenten Velger å se på komponentstrukturen for administrasjonskomponenten. Vi var valgt å bruke en 3-lags arkitektur og droppe lokal lagring, da dette er unødvendig for et såpass lite og enkelt system som dette. Dermed består administrasjonsapplikasjonskomponenten av følgende deler:
Internal design GUI NyAnsattBilde EndreAnsattBilde SlettAnsattBilde NyttProsjektBilde EndreProsjektBilde SlettProsjektBilde LoginBilde SkjermbildeManager Entiteter Service ServiceFacade Ansatt LoginUC «interface» UC Prosjekt NyAnsattUC EndreAnsattUC SlettAnsattUC NyttProsjektUC EndreProsjektUC SlettProsjektUC Arbeid Info InfoFacade Database
Plattformspesifikk modell (PSM) Grunn-entitetene er Ansatt, Prosjekt og Time, med følgende forbindelser: Ved oversettelse til J2EE ved hjelp av modellen fra MDA-boken får vi følgende grovkornede PSM-model: