Kenneth A. Hansen (kennetah) Anders Gravdal (andergra) Thomas H. Espe (thomases)

Like dokumenter
University of Oslo Department of Informatics. INF Modellering med objekter Oblig 2, V2004. Skrevet av:

INF Oblig 2. Hour Registration System (HRS)

INF 5120 Obligatorisk oppgave Nr 2

INF5120 Oblig 2 - Timeregistreringssystem Gruppe 25 Annette Kristin Levine Nils-Kristian Liborg Unni Nyhamar Hinkel

University of Oslo Department of Informatics. Hours Registration System (HRS) INF 5120 Oblig 2. Skrevet av:

1 Innledning Plattformspesifikk modell Komponent Implementasjonsmodell Deployment Modell... 29

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

INF5120 Obligatorisk innleving 2 Gruppe 7. Ole Tommy, Tor Eric, Audun og Kai

INF 5120 Obligatorisk oppgave 2

Oblig 2. Inf5120. Gruppe 21. Espen Stensund (estensun) Nguyen Tran (nguyent) Hung Huynh (qhhuynh)

Oblig2 i INF5120 Modellering med objekter UiO V04, Timelisteføringssystem Ver

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

Eksamen INF

INF Modellering med objekter (Oblig 2) **TimeregistreringSystem** (Designet av Alen Cemer

Conference Centre Portal (CCP)

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl

Obligatorisk oppgave 2

UKE 11 UML modellering og use case. Gruppetime INF1055

Inf5120. Obligatorisk innlevering nr 2, 3.mai Obligatorisk innlevering nr 2. Inf 5120: 5/11/2004

Produktrapport Gruppe 9

Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store. Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson

Oppsett Visma.net Calendar For deg som bruker Huldt & Lillevik Lønn

Eksamen i fag SIF8018 Systemutvikling. Fredag 25. mai 2001 kl

Forslag til løsning. Oppgave 1

Vi vil gjerne vise noen eksempler! 9/13/2016. Hvilke muligheter har vi for oppfølging av rammer og handlingsrom regulert av lover, avtaler og tariffer

UML- Use case drevet analyse og design. Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,

OptimalJ-kurs UIO Oppsummering av kurset. De ulike modellene egenskaper og formål

UKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

Use Case-modellering. INF1050: Gjennomgang, uke 04

Easy Personal. Hurtigguide/innføring

UNIVERSITETET I OSLO Institutt for Informatikk. INF5120 Modellering med objekter Oblig 2 Time Master. Skrevet av: Kristrun Arnarsdottir. 03.

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

iseries Innføring i Client Access Express

Eksamen i Internetteknologi Fagkode: IVA1379

Kravspesifikasjon. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23

Kravspesifikasjon for PLBSys NG. Versjon 1.0

Innsending av timelister. Timeliste. Innsending

UML-Unified Modeling Language

Use case drevet design med UML

Kravspesifikasjon. 14. oktober 2002

KOM I GANG KOM I GANG MED HRESSURS FRA INFOTJENESTER - SYSTEMADMINISTRATOR

Hovedprosjekt i Anvendt Datateknologi Våren 2008 FORSIDE

Kravspesifikasjon. Forord

System Dokumentasjon. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk

1 INNLEDNING Om Altinn Skjemaer som støttes INSTALLASJON OG OPPSTART Nedlasting Registrering...

Fra krav til objektdesign

SRD. Software Requirements and Design GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

BRUKERVEILEDNING TIDBANK

Visma Reconciliation NYHETER OG FORBEDRINGER

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

Use Case-modell. Vurdering av oppdragsgivers krav

Spesifikasjon av Lag emne. Kursregistrering bruksmønstermodell (ny versjon) Dagens forelesning. Fra krav til objektdesign

BRUKERVEILEDNING TIDBANK

2013 Aditro AS 1 (24)

Web services i Nireg

Obligatorisk oppgave 2 INF 5120 Modellering med objekter våren 2004

Huldt & Lillevik Lønn 5.0

DELLEVERANSE 1 INF2120 V06

CORBA Component Model (CCM)

Introduksjon til fagfeltet

Forprosjektrapport Bacheloroppgave 2017

Generelt om operativsystemer

Huldt & Lillevik Ansattportal Ansattportal. Versjon

3.3 Case 3: Opprette en bruker Case 4: Endre en bruker... 8

Vårt system kan kjøres ved å skrive. STUD1 konto fredo 37 (holdeplass)

Leveranse 2. September 27, 2002

Endelig!! WEB påmelding og betaling i DogWeb-Arra, utstilling!

InfoRed Publisering. - produktbeskrivelse. TalkPool WebServices Postboks Åneby

UML 1. Use case drevet analyse og design Kirsten Ribu

Installere konverteringsprogrammet. Innholdsfortegnelse

Samme brukernavn og passord som Min Arbeidsplan (MAP). Velg Mandal kommune RS i feltet foretak.

Gruppe KTN2 innlevering. Endringer gjort siden KTN1:

Guide - mintimebank.no

BRUKERVEILEDNING TIDBANK

BRUKERMANUAL. Telsys Online Backup

MARE NOSTRUM. Del 2 Kravspesifikasjon

Team2 Requirements & Design Document Værsystem

1. SQL server. Beskrivelse og forberedelse til installasjon

KOM I GANG KOM I GANG MED SIMPLOYER FRA INFOTJENESTER- LEDERGUIDE

UNIVERSITETET I OSLO Institutt for informatikk. INF2120: ICU - a surveillance system, Drop 1. gisleal, eivindjo, tanxn, behrozm

Kravspesifikasjon for Telefly NG. Versjon 1.0

NYHETER Proplan Time Oppsummert nyheter i versjon 2.11, 2.12, 2.13

Huldt & Lillevik Lønn 5.0

AP221 Use Case - SBL- Registrer preutfyllingsdata

Hvordan logger man på. Hovedmenyen. For å ta i bruk Kronos Mobile

AMS-case. Eksemplifisering av modellbasert. tilnærming til design av brukergrensesnitt

RFID AutoLogOff - et studentprosjekt

Gruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0>

Brukerveiledning. Igangsettelse og administrasjon av Elev- og lærerundersøkelsen

Planlegging og dokumentasjon

student s104111, s107911, s122357

Kravspesifikasjon MetaView

Prosjektstyring med Projectfronter (En innføring i grunnleggende Projectfronter-funksjonalitet)

KOM I GANG KOM I GANG MED SIMPLOYER FRA INFOTJENESTER - ANSATTGUIDE

Spesifikasjon av Lag emne

Transkript:

!"$#&%('*)+#&%,%.- 2004-05-03 Kenneth A. Hansen (kennetah) Anders Gravdal (andergra) Thomas H. Espe (thomases)

"!$#&%$#('*)+',#-!.0/3254,62782:92;4=<>4=32 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. 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). Dette dokumentet beskriver vår løsning på dette systemet, og fokuserer primært på timeregistreringskomponenten.?a@ 2;B C54DCE/GFIH3254$C54J7784DC Vi har identifisert tre stakeholdere i forhold til systemet, Ansatt, Ledelse og Personalansvarlig. Diagrammet under beskriver stakeholderere og deres interesser. Jobber på prosjekter. Registrerer hver uke antallet timer han/hun har jobbet på et prosjekt denne uka. Ansatt Timeadministrasjonssystem Ledelse Personalansvarlig Overvåker ressursfordelingen på prosjektene, og fordeler ansatte slik at ressursfordelingen blir mest mulig effektiv. Administrerer ferie og avspasering ut fra den ansattes timebudsjett

Det overordnede målet med systemet er å få en god og samlet ressursfordeling, slik det er beskrevet i diagrammet under. Diagrammet viser et hierarki av delmål som understøtter dette overordnede målet. God samlet ressursfordeling God ressursfordeling på prosjekter Oppdatert timeregnskap God ferieavvikling God timeregistrering Oppdatert personlig timebudsjett!"#%$&$ '#()""#+*&,&.-0/23450 God timeregistrering: 6 Registrere riktig timebruk Oppdatert personlig timebudsjett: 6 Korrekt opprettet timebudsjett 6 Oppdatering ved ferie 6 Oppdatering ved avspassering 6 Overføring av ferie fra tidligere år 6 Sikring av overtidsgrenser God ressursfordeling: 6 Generere ressursrapport Oppdatert timeregnskap: 6 Generere timeregnskapsrapport God ferieavvikling: 6 Generere ferierapport

Timebudsjett Bruker Ansatt..* Personalansvarlig Ledelse Timelistelinje * Timeliste..* Prosjekt..*..* Diagrammet over identifiserer de elementene systemet må bestå av for å kunne oppfylle systemkravene. "! #$% # &(')+*-,.0/'/.2* 3'4/ Aktivitetsdiagrammet under viser framgangsmåten ved reistrering av timer.

Logg inn Registrer timer Lagre/logg ut Logg inn [personalansvarlig] [ansatt] Registrere ferieønske Behandle ferieønske Sett opp ferieplan Avslå Innvilg Diagrammet over viser fremgangsmåten for administrering av ferie og avspassering. Søknader om ferie og avspassering behandles på samme måte.

Aktivitetsdiagrammet under viser fremgangsmåten ved ressursovervåking. Etter at aktiviteten Analyser rapport er gjort, kan man refordele ressurser dersom det er behov for dette. Logg inn Bestill tilpasset rapport Bestill standard rapport Analyser rapport Refordel ressurser! "$#%'&( ")+*,!-.0/2 3546 798;: <>=? @A/CB8=>4ED Diagrammet under viser systemets avgrensning mot omverdenen. Ingen av aktørene er innlemmet i systemet. Aktøren Timeinformasjon representerer en lagringsenhet for timeinformasjon. Alle som registrerer timer er definert som Ansatt ved denne aktiviteten, uansett om man også kan være definert som Ledelse eller som Personalansvarlig.

Timeadministreringssystem Planlegg ferie Planlegg avspasering Ansatt Personalansvarlig Registrere timer {<<include>>} {<<include>>} Oppdater timeliste Oppdater timebudsjett Overvåke ressurser Ledelse {<<include>>} Vis timeinfo Timeinformasjon Diagrammet under viser en gruppering av de forskjellige use casene i subsystemer. Vi har delt inn i tre subsystemer, Timeregistrering, Timetjenester og Ressursovervåkning. Disse subsystemene er en logisk oppdeling utifra hva systemet skal gjøre og gir gode muligheter for komponentbasert implementasjon. Nærmere beskrivelse av komponentene kommer senere i besvarelsen.

Timeregistrering Planlegg ferie Planlegg avspasering Ansatt Personalansvarlig Registrere timer Timetjenester {<<include>>} {<<include>>} Oppdater timeliste Oppdater timebudsjett Ressursovervåkning Overvåke ressurser Ledelse {<<include>>} Vis timeinfo Timeinformasjon Under følger en beskrivelse av de forskjellige use casene fra use casediagrammet over. Planlegg ferie: Primært scenario: Use case: Planlegg ferie. Prioritet: Mål: Planlegge ferie for ansatte. Aktører: Ansatt. Pre-betingelser: De ansattes timebudsjetter er opprettet og oppdatert. Post-betingelser: Resultat av ferieønske er lagret. Facade: Kvalitetskrav: Scenario: Innlegging av ferieønske i timeregistreringsverktøyet. Hendelsesforløp:. Den ansatte logger seg inn i systemet. 2. Den ansatte fyller inn ønsket ferie.

Alternativt scenario: Use case: Planlegg ferie. Prioritet: Mål: Planlegge ferie for ansatte. Aktører: Personalansvarlig. Pre-betingelser: De ansattes timebudsjetter er opprettet og oppdatert. Post-betingelser: Resultat av behandling er lagret. Facade: Kvalitetskrav: Scenario: Behandling av ferieønske i timeregistreringsverktøyet. Hendelsesforløp:. Personlansvarlig logger seg inn i systemet. 2. Personalansvarlig innvilger opp mot den ansattes timebudsjett. Alternativt hendelsesforløp:. Personlansvarlig logger seg inn i systemet. 2. Personalansvarlig avslår opp mot den ansattes timebudsjett. Planlegg avspasering: Primært scenario: Use case: Planlegg avspasering. Prioritet: Mål: Planlegge avspasering for ansatte. Aktører: Ansatt. Pre-betingelser: De ansattes timebudsjetter er opprettet og oppdatert. Post-betingelser: Resultat av avspaseringsønske er lagret. Facade: Kvalitetskrav: Scenario: Innlegging av avspaseringsønske i timeregistreringsverktøyet. Hendelsesforløp:. Den ansatte logger seg inn i systemet. 2. Den ansatte fyller inn ønsket avspasering. Alternativt scenario: Use case: Planlegg avspasering. Prioritet: Mål: Planlegge avspasering for ansatte. Aktører: Personalansvarlig. Pre-betingelser: De ansattes timebudsjetter er opprettet og oppdatert. Post-betingelser: Resultat av behandling er lagret.

Facade: Kvalitetskrav: Scenario: Behandling av avspaseringsønske i timeregistreringsverktøyet. Hendelsesforløp:. Personalansvarlig logger seg inn i systemet. 2. Personalansvarlig innvilger opp mot den ansattes timebudsjett. Alternativt hendelsesforløp:. Personalansvarlig logger seg inn på systemet. 2. Personalansvarlig avslår opp mot den ansattes timebudsjett. Registrere timer: Use case: Registrere timer. Prioritet: Mål: Registrere timer ansatte har jobbet på prosjekter siste uke. Aktører: Ansatt. Pre-betingelser: Den ansattes timeliste og timebudsjett er opprettet. Post-betingelser: Den ansattes timeregnskap er oppdatert. Facade: Kvalitetskrav: Scenario: Registrering av timer i timeregistreringsverktøyet. Hendelsesforløp:. Den ansatte logger seg inn i systemet. 2. Den ansatte fyller inn hvor mange timer han/hun har arbeidet på ulike identifiserte prosjekter sist uke. 3. Systemet lagrer timene med hjelp av use caset Oppdater timeliste. 4. Systemet oppdaterer den ansattes timebudsjett ved hjelp av use caset Oppdater timebudsjett. Oppdater timeliste: Use case: Oppdater timeliste. Prioritet: Mål: Oppdatere en ansatts timeliste. Aktører: Timeinformasjon. Pre-betingelser: Den ansatte finnes i systemet. Post-betingelser: Den ansattes timeliste er oppdatert. Facade: Kvalitetskrav: Scenario: Hendelsesforløp:. Mottar timelisteoppdatering fra use caset Registrere timer.

2. Den ansattes timeliste oppdateres hos Timeinfo. Oppdater timebudsjett: Primært scenario: Use case: Oppdater timebudsjett. Prioritet: Mål: Oppdatere en ansatts timebudsjett. Aktører: Timeinformasjon. Pre-betingelser: Den ansatte finnes i systemet. Post-betingelser: Den ansattes timebudsjett er oppdatert. Facade: Kvalitetskrav: Scenario: Hendelsesforløp:. Mottar timebudsjettoppdatering fra use caset registrere timer. 2. Den ansattes timebudsjett oppdateres hos Timeinfo. Alternativt scenario: Use case: Oppdater timebudsjett. Prioritet: Mål: Oppdatere en ansatts timebudsjett. Aktører: Personalansvarlig. Pre-betingelser: Den ansatte finnes i systemet. Post-betingelser: Den ansattes timebudsjett er oppdatert. Facade: Kvalitetskrav: Scenario: Oppdatering av timebudsjett i oppdateringsverktøy. Hendelsesforløp:. Personalansvarlig mottar ansattes ønske om ferie eller avspasering. 2. Den ansattes timebudsjett sjekkes for ønskets gyldighet. 3. Den ansattes timebudsjett oppdateres. Altenativt hendelsesforløp:. Personalansvarlig mottar ansattes ønske om ferie eller avspasering. 2. Den ansattes timebudsjett sjekkes for ønskets gyldighet. 3. Den ansattes ønske kan ikke innfris mot timebudsjettet. Vis timeinfo: Use case: Vis timeinfo.

Prioritet: Mål: Å gi informasjon om ressursfordeling på prosjekter. Aktører: Timeinformasjon. Pre-betingelser: Timeinformasjon er oppdatert. Post-betingelser: Informasjon om ressursfordeling er generert. Facade: Kvalitetskrav: Scenario: Hendelsesforløp:. Mottar ønske om informasjon om ressursfordeling fra use caset Overvåke ressurser. 2. Genererer ønsket rapport. Overvåke ressurser: Use case: Overvåke ressurser. Prioritet: Mål: Å bidra til bedre ressursfordeling på prosjekter. Aktører: Ledelse. Pre-betingelser: Bedriftens timeregnskap er oppdatert. Post-betingelser: Rapport om bedriftens ressursfordeling er levert. Facade: Kvalitetskrav: Scenario: Presentasjon av rapporter om ressursfordeling i ressursovervåkningsverktøyet. Hendelsesforløp:. Leder logger seg inn i systemet. 2. Leder fyller inn informasjon om ønsket rapport. 3. Systemet produserer ønsket rapport ved hjelp av use caset Vis timeinfo. 4. Systemet presenterer rapporten til leder. Diagrammet under viser systemet delt opp i forskjellige komponenter. Komponentene er lagdelt. Nederst har vi en ressurskomponent, ResourceService:Timeinformasjon. Dette representerer datalageret i systemet. Neste lag representerer business servicelaget og er komponenten BusinessService:Timetjenester. Denne inneholder de tjenestene som binder lageret sammen med brukertjenestene. Brukertjenestene er det øverste laget i denne modellen og er delt inn i to verktøykomponenter. Tool:Timeregistrering er for de ansattes registrering av timer brukt på prosjekter og

Tool:Ressursovervåking, for personalansvarlig sin behandling av ferie og avspasering og for manuell oppdatering av timebudsjetter. Tool:Timeregistrering Tool:Ressursovervåkning BusinessService:Timetjenester ResourceService:Timeinformasjon!"#" %$&'"# )(+*,.-0/%#( )(2# "3)(+*, Diagrammet under gir en grafisk fremstilling av grensesnittet mellom de ulike komponentlagene. Interface:Timetjenester: 4 +oppdatertimeliste(in id : integer; In nyetimer : Timeliste) 4 +oppdatertimebudsjett(in id : integer; In nyetimer : Timeliste) 4 +oppdaterferie(in id : integer; In fra : Date; In til : Date) 4 +lagrapport(in rapportid : integer) 4 +lagtilpassetrapport(in rapportvalg : [*] integer) Interface:Timeinfo: 4 +lagretimeliste(in timeliste : Timeliste) 4 +lagretimebudsjett(in timebudsjett : Timebudsjett) 4 +henttimeinfo(in spoerring : String) 4 +lagreferie(in spoerring : String)

Tool:Timeregistrering Tool:Ressursovervåkning Interface:Timetjenester BusinessService:Timetjenester Interface:Timeinformasjon ResourceService:Timeinformasjon De to sekvensdiagrammene under gir en framstilling av samarbeidet mellom komponentene for å realisere to av use casene. Use case beskrevet i det første diagrammet, er Overvåke ressurser. I det andre diagrammet, er det use caset Registrer

timer som er beskrevet. Disse to use casene representerer det vi ser som den viktigste funksjonaliteten i systemet. :Ressursovervåkning :Timetjenester :Timeinfo velg ønsket rapport Lag rapport Hent timeinfo timeinfo generer rapport Rapport : Timereg : Timetjenester :Timeinfo fyllinntimer Oppdater timeliste Lagre timeliste Lagret Oppdater timebudsjett Lagre timebudsjett Lagret Ack

Diagrammet under gir en grafisk framstilling av grensesnittet mellom de to lagene i komponenten timeregistrering. Denne komponenten er delt opp i to lag, et brukergrensesnittlag og et brukertjenestelag. Interface IUserService: 4 +login(in username : String; In passwd : String) 4 +logout() 4 +tjenestevalg(valg : integer) 4 +regtimer() 4 +regferie() Timereg.UI IUserService TimeregistreringUS ITimetjenester!!"$#&%(') Diagrammet under viser BCE-analysen av timeregistreringskomponenten. Dette basere seg på tre border-klasser, login, regstrering og administrasjon, som dekker alle brukeres behov i systemet.

Login LoginKontroller Access Registrering Timereg.Kontroller Timeliste Administrasjon Timebudsjett I tillegg har vi to kontrollere, LoginKontroller og Timereg.Kontroller. LoginKontrolleren er den kontrolleren som gir tilgang til systemet. Derfra overføres kontrollen til Timereg.Kontrolleren. Denne gir tilgang til den resterende funksjonaliteten i systemet.

<<focus>> Registermanager Login Registrering Administrasjon <<frame>> Logindialog <<frame>> Timereg.dialog <<frame>> Timeadm. dialog Diagrammet over viser mappingen fra BCE-diagrammet til klasser, og baserer seg på en fokusklasse, registermanager, som administrer de ulike funksjonalitetsvinduene. UI <<frame>> Logindialog <<frame>> Timereg. dialog <<frame>> Timeadm. dialog <<focus>> Registermanager IUserService UserServices <<focus>> UserService

Figuren over viser oppbyggningen av brukergrensesnittpakken, med grensesnitt (IUserService) mot tjenestene som tilbys til brukergrensesnittet. "!$#% '&)(*&,+.-/!0#2(*!(*&,+/3'+/42 '&650879(* Bruker -navn: String -id: int Timebudsjett -sumovertid: float -sumferie: float +oppdaterovertid(): float +oppdaterferie(): float Ansatt -timereg() -feriereg() -feriestatus() -settpaaprosjekt() * Personalansvarlig -behandlesoknad() -innvilgsoknad() -avslaasoknad() -oppdatertimebudsjett()..* * Prosjekt -prisjektid: String TimelisteLinje -prosjektid: String -timer: float = 0 -datostempel: Date * Timeliste -sum: float = 0 +opprettlinje() Figuren under viser klassene for en J2EE-implementasjon for komponenten Timeregistrering. Siden vi baserer diagrammet på implementasjon av komponenten Timeregistrering, er klassen Ledelse utelatt fra dette diagrammet, da denne ikke er nødvendig for denne komponenten. : (;#/.<"!=(>&,+ : 4?3A@%BC3D! Deploymentdiagrammet under viser hvordan vi ser for oss at timeregistreringssystemet skal implementeres. Vi ser for oss to typer klienter, en for ansatte som registrerer timer og en for de personalansvarlige som administrer ferie, avspassering og de ansattes timebudsjetter. Resten av applikasjonen kjøres på en applikasjonsserver mot en Oracle database.

Client {OS = Linux} timereg AdmClient {OS = Linux} admtimereg AppServer TimeregServer {OS = Linux} Oracle DBMS