Hour Registration System (HRS) Oblig 2. DEL 1: COMET Business Modelling

Transkript

1 Hour Registration System (HRS) Oblig 2 DEL 1: COMET Business Modelling Innlevering i inf5120 Av gruppe 3 som består av Øivind Hepsø Geir Ivar Jerstad Kjetil Myhre

2 Business antakelser Ansatt kan registrere antall timer han/hun har jobbet på hvert prosjekt, slik at bedriften kan holde oversikt over sine ressurser, og holde oversikt over avspasering og ferie til gode for hver ansatt. Prosjektleder kan få full oversikt over timer brukt på hvert prosjekt, samt framgang og ressursfordeling. Både vanlige ansatte og prosjektleder skal kunne skrive rapporter. Scoping Statements Context Statement Stakeholders: - Enkelt måte å registrere prosjekttimer - Lett oversikt på hvor mange timer forbrukt på hvert prosjekt - Oversikt på hvor mange feriedager som er til gode eller avspasseringer. - Full oversikt på antall timer pr prosjekt - Oversikt på fremgang pr prosjekt - Oversikt på ressursfordelingen Ansatt Prosjektleder Hour Registration System Vision for change Bedriften hadde ikke god nok oversikt på prosjektene sine og ville derfor få laget et system som holdt bokføring av timer pr ansatt pr prosjekt. Med dette systemet vil de kunne få full oversikt på fremgang, resurssfordeling og hvor mye avspasering og ferie hver ansatt har til gode. Dette vil være med på å effektivisere bedriften, samt til hver tid holde oversikt over prosjektene og deres ressurser, det vil si total kontroll over hvilke personer som sitter på hvert prosjekt til enhver tid. Dette vil hjelpe bedriften til å holde budsjettene sine og holde sine tidsfrister bedre.

3 Goal Model Maksimalt utbytte av ressursene Riktige folk på riktig sted Oversikt over avspasering og ferie pr ansatt Nøyaktig prosjektplan Registrering av timer... Fremgangs oversikt

4 Business Process & Role Model WARM Ansatt registerer prosjekttimer: Ansatt HRS Ansatt logger seg inn Systemet logger inn den ansatte Ansatt velger prosjekt Systemet viser aktuelle prosjekter som den ansatte er deltaker i. Ansatt velger å registere nye timer Systemet lagrer timene og sender en bekreftelse tilbake til den ansatte Ansatt ser bekreftelse og logger ut Systemet logger den ansatte ut av systemet

5 Prosjektleder legger inn nytt prosjekt Prosjektleder HRS Prosjektleder logger seg inn Systemet logger inn Prosjektleder Systemet viser pågående prosjekter Prosjektleder legger inn et nytt prosjekt System henter opp et prosjekt-templat Prosjektleder må spesifisere hvilke resursser som er tilgjengelig Prosjektleder registrer aktivitene som prosjektet utgjør Prosjektleder tildeler resursser til hver aktivitet og spesifiserer hvor mye av resurssene som skal forbrukes. Systemet lagrer informasjonen Systemet oppdaterer prosjektinfomarsjonen hos de respektive ansatte Prosjektleder mottar bekreftelse og logger ut System sender en bekreftelse tilbake til prosjektlederen System logger ut prosjektleder

6 Systemets ansvarsområde (Scope) 1. Clear Statement of outcomes Forbedret håndtering av ressurser på prosjektene, slik at prosjektleder lettere kan ha full kontroll over framskritt og tilgjengelige ressurser. Forbedret oversikt over timer brukt på prosjekt av hver ansatt. Forbedret oversikt over ferie og avspasering til hver ansatt. 2. Clear Statement of those who are to benefit Ledelsen i bedriften kan lettere kontrollere og overholde budsjetter. Økonomi og lønn kan lettere holde oversikt over timer og budsjett. 3. Statement of 'outputs' or 'deliverables' Systemet skal holde oversikt over antall timer som er brukt på hvert prosjekt. Systemet skal også vedlikeholde et personlig timebudsjett for hver av de ansatte i bedriften (slik at man kan holde oversikt over avspasering og ferie). Risikoanalyse Forretningens pengebevilgning går tomt før systemet er ferdig. Ansatt registrerer feil antall timer VIRUS Sykdom Underestimert tidsforbruk Dårlig tilgang på ressurser

7 Hour Registration System (HRS) Oblig 2 DEL 2: COMET Requirements Modelling Innlevering i inf5120 Av gruppe 3 som består av Øivind Hepsø Geir Ivar Jerstad Kjetil Myhre

8 Requirements Model...9 System boundry og aktører...9 Use-case modell:...10 Use-case scenario...11 Use-case: Behandle timeregistrering...11 Aktør...11 Forhåndsbetingelser...11 Hendelsesforløp:...11 Hovedforløp...11 Alternative forløp...11 Use-case: Behandle prosjekter...12 Kort beskrivelse...12 Aktør...12 Forhåndsbetingelser...12 Hendelsesforløp...12 Hovedforløp...12 Alternative forløp...12 Sekvensdiagram...14 Timeregistrering ansatt legger til timer...14 Behandle prosjekt slett timer...15 Subsystem grouping...16 Component structure bus pattern...17

9 Requirements Model Vår utviklingsprosess definerer at disse modellene skal være med i dette dokumentet, men vi tar ikke med prototyping pga uspesifisert i oppgaven (ref. referanseoppgaven). RA analysis er realisert inn i avsnittene: Use-case modell, Subsystem grouping, component infrastructure. Figur 1 - COMET sin Requirements model System boundry og aktører Vi har identifisert de akutelle rollene som systemet krever minimalt og disse er: Den ansatte skal kunne legge til prosjekttimer samt se rapporter. En ansatt er en resurss som prosjektlederen skal styre over. Hovedansvaret til hvert prosjekt ligger på prosjektlederen og dermed har den ansvaret med alt som har med å behandle prosjektet som f.eks legge til prosjekter, oppdaterer de. Ansatt HRS Prosjektleder Figur 2 - Viser avgrensningene til HRS systemet

10 Use-case modell: Behandle timeregistrering Ansatt Behandle prosjekter Prosjektleder Lage prosjektrapporter Figur 3 - use-case modellen til HRS

11 Use-case scenario Use-case: Behandle timeregistrering Kort beskrivelse Den ansatte skal være i stand til å registrere timer som forbrukt på en aktivitet i et prosjekt som den ansatte arbeider i. Aktør Ansatt Forhåndsbetingelser Systemet er oppegående. Ansatt har logget inn i systemet. Hendelsesforløp: Hovedforløp 1. Velg behandling av timeregistrering: A1-1 : Legg til timeregistrering A1-2 : Endre timeregistrering A1-3 : Slett timeregistrering Alternative forløp A1-1 : Legg til timeregistrering 1. Systemet viser hvilke prosjekter som er tilgjengelig 2. Ansatt velger aktuelt prosjekt 3. Systemet viser hvilke aktiviteter som er tilgjengelig 4. Ansatt velger aktivitet 5. Ansatt velger hvilken aktivitet som timene skal registreres på 6. Ansatt skriver inn antall timer forbrukt 7. Ansatt logger ut av systemet A1-2 : Endre timeregistrering 1. Systemet viser hvilke prosjekter som er tilgjengelig 2. Ansatt velger aktuelt prosjekt 3. Systemet viser hvilke aktiviteter som er tilgjengelig 4. Ansatt velger aktivitet 5. Ansatt velger hviken timeregistrering som skal endres (Hver timeregistrering har en timestamp) 6. Ansatt skriver inn antall timer forbrukt 7. Ansatt logger ut av systemet A1-3 : Slett timeregistrering 8. Systemet viser hvilke prosjekter som er tilgjengelig 9. Ansatt velger aktuelt prosjekt 10. Systemet viser hvilke aktiviteter som er tilgjengelig

12 11. Ansatt velger aktivitet 12. Ansatt velger hviken timeregistrering som skal endres (Hver timeregistrering har en timestamp) 13. Ansatt sletter timeregistreringen 14. Ansatt logger ut av systemet Use-case: Behandle prosjekter Kort beskrivelse Prosjektleder skal være i stand til å legge til prosjekter samt også legge til aktiviteter til de registrerte prosjektene. Prosjektleder skal også kunne tilegne resursser til de forskjellige aktivitetene som utgjør prosjektet. Aktør Prosjektleder Forhåndsbetingelser Systemet er oppegående. Prosjektleder har logget inn i systemet. Hendelsesforløp Hovedforløp 2. Velg behandling av : A1-1 : Legg til prosjekt A1-2 : Endre prosjekt A1-3 : Slett prosjekt Alternative forløp A1-1 : Legg til prosjekt 8. Systemet viser hvilke prosjekter som er tilgjengelig 9. Ansatt velger aktuelt prosjekt 10. Systemet viser hvilke aktiviteter som er tilgjengelig 11. Ansatt velger aktivitet 12. Ansatt velger hvilken aktivitet som timene skal registreres på 13. Ansatt skriver inn antall timer forbrukt 14. Ansatt logger ut av systemet A1-2 : Endre prosjekt 15. Systemet viser hvilke prosjekter som er tilgjengelig 16. Ansatt velger aktuelt prosjekt 17. Systemet viser hvilke aktiviteter som er tilgjengelig 18. Ansatt velger aktivitet 19. Ansatt velger hviken timeregistrering som skal endres (Hver timeregistrering har en timestamp) 20. Ansatt skriver inn antall timer forbrukt 21. Ansatt logger ut av systemet

13 A1-3 : Slett prosjekt 22. Systemet viser hvilke prosjekter som er tilgjengelig 23. Ansatt velger aktuelt prosjekt 24. Systemet viser hvilke aktiviteter som er tilgjengelig 25. Ansatt velger aktivitet 26. Ansatt velger hviken timeregistrering som skal endres (Hver timeregistrering har en timestamp) 27. Ansatt sletter timeregistreringen 28. Ansatt logger ut av systemet

14 Sekvensdiagram Her har vi valgt ut to sekvensdiagram for å vise gangen i programmet. Timeregistrering ansatt legger til timer Ansatt HRS main Behandle timer Legg til timer Prosjekt Aktivitet velg timereg new behandle_time legg_til _timer legg_til new velg prosjekt ActionOk() getinfo() velg_aktivitet ActionOk() getinfo() reg timer setinfo() ActionOk() Figur 4 - Sekvensdiagram for "Legg til timer"

15 Behandle prosjekt slett timer Ansatt HRS main Behandle timer Legg til timer Prosjekt Aktivitet velg timereg new behandle_time legg_til _timer legg_til new velg prosjekt ActionOk() getinfo() velg_aktivitet ActionOk() getinfo() reg timer setinfo() ActionOk() Figur 5 - Sekvensdiagram for "Slett timer"

16 Subsystem grouping Dette er en oppdeling av systemet og viser kommunikasjonen mellom de forskjellige subsystemene samt alle roller tilknyttet til disse. Figur 6 - Subsystemoversikt Definisjon av subsystemer: Timeregeditor: Verktøy-komponent som brukes av ansatte når de skal registrere timer på det prosjektetet de sitter på, eventuelt endre på timer. Prosjekteditor: Verktøy-komponent som brukes av prosjektleder til å holde oversikt over prosjektets framgang og dets ressurser. Rapport: Rapport-verktøy som prosjektleder og ansatte legger inn sine rapporter om framgang, status og erfaringer.

17 Component structure bus pattern ProsjektEditor TimeEditor Rapport Component infrastructure Prosjektregistreringstjeneste Timeregistreringstjeneste Prosjektregister Timeregister Ansattregister Figur 7 Oversikt over systemets komponenter Subsystemene Prosjekteditor, Timeeditor, og Rapport brukes av personer (humans) fra figur 1, og de mappes til verktøykomponentene i figur 2. Subsystemene Prosjekttjeneste og Timeregistrerinstjeneste tilbyr tjenester til verktøyene. Verktøyene kommuniserer med business-tjenestene over nettverk. Subsystemene Prosjektregister,Timeregister mappes til ressurstjeneste-komponentene som tilbyr persistente data lagring til Prosjektregistertjeneste, Timeregistreringstjeneste og Ansattregister.

18 Hour Registration System (HRS) Oblig 2 DEL 3: COMET Architecture Modelling Innlevering i inf5120 Av gruppe 3 som består av Øivind Hepsø Geir Ivar Jerstad Kjetil Myhre

19 Architecture Modell Interface and Interaction Specification Klassediagrammer I denne delen definerer vi grensesnittene til komponentene fra Kravspesifikasjonsmodellene. Vi starter med å vise hvilke komponenter som snakker sammen og hvilke grensesnitt disse bruker. Oversikt over hele systemet følger: I alt er det fem grensesnitt som trenger definering: 1. IProsjektRegTjeneste Dette grensesnittet definerer tjenester mot prosjektregisteret. Det er bare aktører med prosjektlederstatus som skal ha tilgang til oppdaterings delene av dette grensesnittet, mens alle skal kunne bruke rapporteringsfunksjonene Grensesnittet er definert som følger:

20 Interface IProsjektRegTjeneste + hentprosjekt(prosjektid:int) : ProsjektData + hentprosjektliste() : ProsjektDataListe + lagreprosjekt(p : Prosjekt) : void 2. ITimeRegTjeneste Dette grensesnittet definerer tjenester mot timeregisteret. Ansatte skal kunne bruke dette grensesnittet til å behandle timeregistreringen sin, og alle skal kunne få ut rapporter fra dette grensesnittet. Grensesnittet er definert som følger: Interface ITimeRegTjeneste + henttimedataliste(prosjektid : int) : TimeDataListe + henttimedataliste(ansattid : int) : TimeDataListe + registrertimedata(t:timedata ) : void + sletttimedata(t : TimeData ) : void 3. IProsjektRegister Dette grensesnittet definerer tjenester direkte mot prosjektregisteret. Tjenestene for timeregistrering og prosjektregistrering skal bruke IProsjektRegister for å hente data om prosjektene som de trenger for å tilby tjenestene sine. Grensesnittet er definert som følger: Interface IProsjektRegister + hentprosjekt(prosjektid : int) : ProsjektData + hentprosjektliste() : ProsjektDataListe + lagreprosjekt(p : Prosjekt) : void 4. ITimeRegister Dette grensesnittet definerer tjenester direkte mot timeregisteret. Timeregisteret er tenkt som et register som kobler sammen ansattregisteret og prosjektregisteret. Grensesnittet er definert som følger: Interface ITimeRegister + henttimedata (ansattid: int) : TimeData + henttimedata(ansattid : int, prosjektid : int) : TimeData + henttimedata(prosjektid : int) : TimeData + lagretimedata(td : TimeData) : void + sletttimedata(td : TimeData) : void + henttimedata(timedataid : int) : TimeData

21 5. IAnsattRegister Dette grensesnittet definerer tjenester direkte mot ansattregisteret. Grensesnittet er definer som følger: Interface IAnsattRegister + hentansatt(ansattid : int) : Ansatt + slettansatt(ansattid : int) : Ansatt + lagreansatt(a : Ansatt) : void

22 Hour Registration System (HRS) Oblig 2 DEL 4: COMET Platform Spesific Model Innlevering i inf5120 Av gruppe 3 som består av Øivind Hepsø Geir Ivar Jerstad Kjetil Myhre

23 Platform Specific Model 1.1 Component Implementation Model I denne delen presenterer vi et implementasjonsdesign av HRS basert på J2EE. J2EE er basert på en flerlagsarkitektur der applikasjonen spres over flere nivåer eller lag. Lagene vi vil komme inn på i denne oppgaven er klientlag, weblag og applikasjonslag. Klienten vår blir en web-browser, for eksempel Opera eller Netscape. Weblaget blir representert ved en httpserver som har støtte for Java server pages (JSP). Dette er et server-side skriptspråk som er godt egnet til å kommunisere med det siste laget i implementasjonen vår: applikasjonstjenerlaget. Vi kunne også ha tatt med et databaselag, men vi velger å se på applikasjonstjeneren som database gjennom å bruke dens støtte for såkalt containermanaged persistence. Dermed blir alle Entitybeans i systemet automatisk lagret når det er gjort forandringer på dem. Nedenfor vises de foskjellige elementene i systemet: Vi tar en ny titt på komponentoversikten fra forrige deloppgave:

24 Denne gangen har vi tegnet en strek slik at alle elementene som skal være i EJB containern er markert ut. Som vi ser er det aller meste av buisinesslogikken plassert nettop i EJB containeren. Når vi gir komponenten vi fokuserte på i forrige deloppgave samme behandling får vi følgende resultat:

25 Vi starter med å se på komponentene som skal bo i EJB containeren: EJB komponenter I følge oppgaveteksten skal vi bruke en J2EE UML profil. Dersom vi skulle modellere HRS strengt i følge J2EE UML profilen ville vi endt opp med en meget komplisert modell. Vi har isteden valg å kun bruke stereotypene EJBEntityBean og EJBSessionBean. Når vi så lar klasser som har disse stereotypene implementere grensesnittene fra componentmodellene våre er det underforstått at det er de diverse home/remote interfacene i J2EE programmeringsmodellen som implementerer disse grensesnittene. På denne måten sparer vi plass, og vi mener og at resultatet blir konseptuellt sett lettere å forstå. Forenklet klassemodell for EJB delene av HRS blir da seende slik ut

26 1.1.3 TimeRegEditor JSP/Webserver Vi vil ikke se på GUI design i denne omgangen. Implementasjon av JSP og koblingene mot EJB er veldig avhengig av hvordan selve brukerinteraksjonen foregår. Vi velger derfor å ikke gå mer i detalj på dette området.

27 1.2 Deployment Model Vi har allerede diskuttert hvilke komponenter som skal bo i hvilke servere tidligere i PSM delen av oppgaven. Vi skal imidlertid tegne opp formell deployment model her. Vi velger å bruke en enkel deployment model. En av fordelene med J2EE er at arkitekturen er svært fleksibel med hensyn til deployment. Det er ikke noe problem å spre en J2EE applikasjon over mange webservere, mange applikasjonservere etc. En enkel deploymentmodel for vår implementasjonsmodell av HRS følger: