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

Transkript

1 UNIVERSITETET I OSLO Institutt for Informatikk INF5120 Modellering med objekter Oblig 2 Time Master Skrevet av: Kristrun Arnarsdottir Arild Fines Ine Lyche Sigernes - (kriar) - (arildfi) - (inel) 03. mai 2004

2 INNHOLD 1. INNLEDNING PROBLEM BESKRIVELSE FORUTSETNINGER BUSINESS MODEL (VIRKSOMHETSMODELL) SCOPING STATEMENTS (KONTEKST STATEMENT) Avgrensinger Rik bilde Scope and stakeholders GOAL MODEL BUSINESS RESOURCE MODEL BUSINESS PROCESS & ROLE MODEL Projekt gjennomføring Prosess beskrivelse REQUIREMENTS MODEL (KRAV MODELL) SYSTEM BOUNDARY MODEL Detailed Use Case Diagram SUBSYSTEM GROUPING MODEL USE CASE DESCRIPTIONS (USE CASE BESKRIVELSER) Add User Delete User Add Project Change Project Delete Project Show Project Approve Hour List Submit For Approval Register Hours Change Hours REFERENCE ARCHITECTURE ANALYSIS MODEL Component Structure ARKITEKTUR MODELL INTERFACE SPECIFICATION (GRENSESNITTBESKRIVELSE) Hour Editor Tool: Component Structure Hour Editor Tool: UserServiceInterface SAMARBEID MELLOM KOMPONENTER Register Hours INTERNAL DESIGN BCE analyse...19 PLATTFORM SPESIFIKK MODELL COMPONENT IMPLEMENTATION MODEL DEPLOYMENT DIAGRAM

3 1. INNLEDNING Denne oppgaven er obligatorisk oppgave i faget INF5120 Modellering mod objekter. Oppgaven går ut på å lage en komplett modellbeskrivelse for en bedrift som skal håndtere timeregistrering. 1.1 PROBLEM BESKRIVELSE I forbindelse med oppgaven skal vi ta utgangspunkt i følgende problem beskrivelse: 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 å lage et slikt system. I tillegg ti lå 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.) 1.2 FORUTSETNINGER Vi velger å ta utgangspunkt i en bedrift som selger støtteverktøy for utvikling og testing av programvare og som tilbyr konsulenttjenester for å støtte kunden i å bruke disse verktøyene. Vi referere til denne bedriften heretter som Verktøy Leverandør. Salgsavdeling: Salg og markedsføring av verktøy. Konsulent avdeling: Konsulenttjenester i forbindelse med innføring og bruk av verktøy. Teknisk support: Teknisk salg support samt help desk. Administrasjon: Regnskap, lønn og annen administrasjon. Hittil har timeregistrering foregått ved at konsulenter fyller ut xcel som de leverer til sin nærmeste leder men nå skal dette effektiviseres ved å innføre et system. De som jobber i konsulent avdelinger er solgt ut på eksterne oppdrag. Det gjøres hovedsakelig i forbindelse med at et eksternt firma har investert i verktøy fra bedriften. Innføringen blir typisk planlagt som et prosjekt hvor 2-3 konsulenter er involvert i prosessen. Først gjennomfører konsulentene en slags situasjonsanalyse, deretter komme de med forslag om hvordan verktøyet kan best integreres i organisasjonen og deretter gir diverse støtte når verktøy skal tas i bruk i form av opplæring og annen konsulentbistand. I tillegg til å effektivisere selve timeregistreringen bidrar systemet i forbindelse med følgende oppgaver: - danner grunnlag for prosjekt-estimering, - danner grunnlag for bonusordninger - fakturering av timer - registrering av feriedager og avspassering - 3 -

4 2. BUSINESS MODEL (VIRKSOMHETSMODELL) 2.1 SCOPING STATEMENTS (KONTEKST STATEMENT) Oblig2 - INF Modellering med objekter AVGRENSINGER De som skal registrere sine timer er i timeregistrerings-systemet Time-Master er de som er ansatt i konsulent avdelingen. Konsulenter skal registrere alle timer som de jobber, fakturerbare samt ikke fakturerbare. Første versjon av dette systemet skal ikke integreres med andre systemer (lønn, regnskap) Systemet skal ha web-klient. (Gjør det enklere for konsulenter å registrere timer når de er hjemme eller ute på oppdrag) RIK BILDE Nåværende situasjon Faktureringsgrunnlag Fakturerte timer Accounting Konsulenter Endring Ny situasjon Selger/Help Desk Hvem jobber på hvilke prosjekt Hvem blir til stede? Hvem er ledig / ikke fakturerbar? Selger/Admin konsulenttjenester Accounting Input til prosjektplanlegging Faktureringsgrunnlag Input til prosjektplanlegging Timeplan Ledelse Bonusordninger Time Master Fakturerte timer Ikke fakturerte timer Konsulenter - 4 -

5 2.1.3 SCOPE AND STAKEHOLDERS <<summary>> - selger verktøy - bidrar til salg av konsulenter <<summary>> - selger konsulenttjenester - estimerer prosjektarbeid - lager tilbud - lager kontrakter - rapporterer til ledelsen <<summary>> - regnskap - lønn - fakturering Selger konsulenter Selger Verktøy Regnskap/lønn Verktøy Leverandør Konsulent <<summary>> - yter av konsulenttjenester - estimere prosjektarbeid -... Salg support <<summary>> - teknisk suppurt til kunder - teknisk support til selger av verktøy -... Ledelse <<summary>> - målsetninger - ledelse - bonusordninger

6 2.2 GOAL MODEL Tjene mer penger Effektivisere hverdagen hos konsulenter Timeregistrering på web Mer presis tilbudsgrunnlag Mer korrekt/fleksibelt/oppdatert faktureringsgrunnlag Bedre estimeringsgrunnlag (informasjon om timer brukt på tidligere prosjekter) Lettere å gjennomføre aktivitet (tilgjengeliggjøring) Forbedred resursoversikt 2.3 BUSINESS RESOURCE MODEL Consultant Week Schedule Day Schedule * 1 Project * Time Period 1 * BillableProject NonBillableProject - 6 -

7 2.4 BUSINESS PROCESS & ROLE MODEL PROJEKT GJENNOMFØRING PROSESS BESKRIVELSE Prosjektleder Konsulent Regnskap H:Salgsaktivitet T:Sjekke tidl. prosjekter T:Registrere timer T:Sjekke registrerte timer H:Sende Tilbud Prosjekt Timeliste H:Sende Faktura T:Registrere Projekt Resultat av WARM analyse, H: Human step, T:Tool step - 7 -

8 3. REQUIREMENTS MODEL (KRAV MODELL) 3.1 SYSTEM BOUNDARY MODEL Administrator adds and removes users from the system Accounting Accounting uses the system to calculate consultant pay as well as bill clients. Administrator The project lead adds, removes and manages projects. Approves hour lists from consultants. System Project Lead This is the external employee database/directory service, which is used for authentication and authorization Consultant Employee Database The consultant registers his hours on a weekly basis - 8 -

9 3.1.1 DETAILED USE CASE DIAGRAM System Submit For Approv al Add User Employee Database Delete User Consultant Register Hours Change Hours Administrator Add Project Show Project Delete Project Project Lead Accounting Change Project Approve Hour List - 9 -

10 3.2 SUBSYSTEM GROUPING MODEL HourEditor System UserEditor Submit For Approv al Add User Register Hours Delete User Employee Database Change Hours Approv e Hour List Administrator Consultant ProjectEditor Add Project Delete Project Show Project Project Lead Accounting Change Proj ect

11 3.3 USE CASE DESCRIPTIONS (USE CASE BESKRIVELSER) Forutsetninger Det eksisterer et ansattregister (employee database) hvor alle ansatte er registrert. Vi antar at all autentisering skjer opp mot denne databasen. Alle prosjektledere har lov til å slette/endre alle prosjekter ADD USER No. 1 Priority Use case Add User 1 ( 1 Høyest, 2 Med, 3 Lavest) Goal Administrator ønsker å legge til en ny konsulent Actors Administrator, Ansattregister Pre-conditions Konsulent skal ikke eksistere fra før Administrator er logget inn i systemet Konsulent er registrert i ansattregister Post-conditions Ny ansatt er lagret i systemet Facade - Quality Req. - Scenario Normal Description Step Action 1 Starter når administrator velger ny konsulent 2 Administrator velger konsulent fra ansattregister 3 Hvis Konsulent ikke finnes i ansattregister 3.1 Avslutt registreringen 4 Informasjon lagres DELETE USER No.2 Use case Delete User Priority 3 Goal Administrator ønsker å fjerne konsulent fra systemet Actors Administrator Pre-conditions Konsulent finnes i systemet Post-conditions Konsulent er fjernet fra systemet Facade - Quality Req. - Scenario Normal Description Step Action 1 Starter når administrator velger slett konsulent (Delete User) 2 Administrator velger konsulent 3 Administrator sletter konsulenten 4 Systemet ber om bekreftelse 5 Administrator bekrefter 6 Systemet oppdateres

12 3.3.3 ADD PROJECT Oblig2 - INF Modellering med objekter No.3 Use case Add Project Priority 1 Goal Prosjektleder ønsker å legg til nytt prosjekt i systemet Actors Prosjektleder Pre-conditions Ingen Post-conditions Nytt prosjekt er lagt til i systemet Facade - Quality Req. - Scenario Normal Description Step Action 1 Starter når Prosjektleder velger nytt prosjekt (Add Project) 2 Prosjektleder registrerer nødvendig informasjon 3 Hvis ikke informasjonen er tilstrekkelig 3.1 Vis feilmelding 3.2 Gå til step 2 4 Informasjon lagres CHANGE PROJECT No.4 Use case Change Project Priority 3 Goal Prosjektleder ønsker å endre informasjon om et prosjekt Actors Prosjektleder Pre-conditions Prosjektet finnes i systemet Post-conditions Prosjekt er oppdatert Facade Quality Req. Scenario Normal Description Step Action 1 Starter når Prosjektleder velger endre prosjekt (Change Project) 2 Prosjektleder velger prosjekt som skal endres 3 Prosjektleder endrer informasjonen 4 Hvis ikke informasjonen er tilstrekkelig 4.1 Vis feilmelding 4.2 Gå til step 3 5 Informasjon lagres

13 3.3.5 DELETE PROJECT no.5 Use case Delete Project Priority 3 Goal Prosjektleder ønsker å fjerne et prosjekt fra systemet Actors Prosjektleder Pre-conditions Prosjektet finnes i systemet Ingen timer er knyttet opp mot prosjektet Post-conditions Prosjekt er fjernet Facade - Quality Req. - Scenario Normal Description Step Action 1 Starter når Prosjektleder velger slette prosjekt 2 Prosjektleder velger prosjekt som skal slettes 3 Hvis det finnes timer som er knyttet opp mot det prosjektet 3.1 Vis feilmelding 3.2 Systemet gir valgmuligheter, avbryt registrering eller gå til step 2 4 Systemet oppdateres SHOW PROJECT Use Case Use case Show Project no.6 Priority 2 Goal Regnskap ønsker å finne antall timer som er registrert på et prosjekt Actors Regnskap (Accounting) Pre-conditions Ingen Post-conditions Ingen Facade - Quality - Requirements Scenario Normal Description Step Action 1 Starter når Regnskap velger vis prosjekt (Show Project) 2 Systemet viser oversikt over alle prosjekter sortert på dato 3 Regnskap velger prosjektet som skal vises 4 Systemet viser detaljert prosjektinformasjon

14 3.3.7 APPROVE HOUR LIST No.7 Use case Approve Hour List Priority 2 Goal Prosjektleder ønsker å godkjenne timeliste for konsulent Actors Prosjektleder Pre-conditions Konsulent har sendt timeliste til godkjenning Post-conditions Timelisten er godkjent Facade - Quality Req. - Scenario Normal Description Step Action 1 Starter når prosjektleder velger å godkjenne timelister (Approve Hour List) 2 Systemet viser oversikt over alle timelister som er sendt til godkjenning 3 Prosjektleder velger timeliste som skal godkjennes 4 Systemet viser timelisten 5 Hvis prosjektleder ikke godkjenner 5.1 Systemet sender epost til konsulenten 5.2 Gå til step 2 6 Prosjektleder godkjenner timeliste 7 Systemet oppdateres SUBMIT FOR APPROVAL No.8 Use case Submit For Approval Priority 2 Goal Konsulent ønsker å få sin timeliste godkjent Actors Konsulent Pre-conditions Konsulent er ferdig med å registrere timer for en uke (timelisten) Timelisten skal ikke være godkjent fra før Post-conditions Timelisten er sendt for godkjenning Facade - Quality Req. - Scenario Normal Description Step Action 1 Starter når konsulent velger sende til godkjenning (Submit For Approval) 2 Systemet viser oversikt over alle timelister 3 Konsulent velger den timelisten som skal godkjennes 4 Konsulenten velger å sende til godkjenning

15 3.3.9 REGISTER HOURS No.9 Use case Register Hours Priority 1 Goal Konsulent ønsker å registrere timer Actors Konsulent Pre-conditions Ingen Post-conditions Timer er registrert Façade - Quality Req. - Scenario Description Step Action 1 Starter når konsulent velger registrere timer (Register Hours) 2 Konsulent velger uke konsulenten vil registrere timer for 3 Systemet viser registreringsark 4 For hvert prosjekt som konsulent skal registrere for 4.1 Konsulent velger prosjekt 4.2 Konsulent skriver inn antall timer pr. dag 5 Informasjonen lagres CHANGE HOURS No. 10 Use case Change Hours Priority 2 Goal Konsulent ønsker å endre timeliste Actors Konsulent Pre-conditions Timeliste er ikke godkjent Post-conditions Timeliste er oppdatert Facade - Quality Req. - Scenario Normal Description Step Action 1 Starter når konsulent velger endre timeliste (Change Hours) 2 Systemet viser oversikt over alle timelister 3 Konsulenten velger timelisten som skal endres 4 For hvert prosjekt som konsulent skal endre, slette eller legge til 4.1 Konsulent oppdaterer informasjon 5 Informasjon oppdateres

16 3.4 REFERENCE ARCHITECTURE ANALYSIS MODEL COMPONENT STRUCTURE «tool» HourEditor «tool» ProjectEditor «tool» UserEditor Component infrastructure ScheduleService UserService «resource service» ScheduleInfo «resource service» UserInfo

17 4. ARKITEKTUR MODELL 4.1 INTERFACE SPECIFICATION (GRENSESNITTBESKRIVELSE) «tool» HourEditor «tool» ProjectEditor «tool» UserEditor IScheduleService «realize» IProjectService «realize» IUserService «realize» UserService ScheduleService IMailNotifier «realize» MailServ er Existing mail server IScheduleInfo «realize» «resource service» ScheduleInfo IUserInfo «realize» «resource service UserInfo HOUR EDITOR TOOL: COMPONENT STRUCTURE HourEditorUI IHourEditorUS «realize» HourEditorUS

18 4.1.2 HOUR EDITOR TOOL: USERSERVICEINTERFACE «interface» IHourEditorUS + getschedule(weekno :int) : IScheduleInfo + getavailableprojects() : String[] + save(schedule :IScheduleInfo) : void «interface» IScheduleInfo + sethour(day :int, hour :int, project :String) : void + getprojectforhour(day :int, hour :int) : String + create(user :String, weekno :int) : void «interface» IScheduleService + getschedule(weekno :int, user :String) : IScheduleInfo + save(schedule :IScheduleInfo) : void + getprojectsforuser(user :String) : String[] 4.2 SAMARBEID MELLOM KOMPONENTER REGISTER HOURS HourEditorUI HourEditorUS ScheduleService ScheduleInfo :Consultant Register Hours getschedule(weekno) getschedule(user, weekno) [if schedule does exist]: [if schedule does not exist]:create(user, weekno) getprojects displayschedule(schedule) getavailableprojects(user) manipulate schedule sethour(hour, day, project) save(schedule) {while not finished} save(schedule)

19 4.3 INTERNAL DESIGN BCE ANALYSE Ved gjennomføring av BCE analyse, tar vi utgangspunkt i anbefalt artikkel: Robust Object Orientert System Analysis. Brukergrensesnittet skal kjøre I en web-browser og en boundary class vil typisk representere en web side. HourRegister HourController HourView ApproveController WeekSchedule HourFunctions SubmitApprController ProjectView ProjectController Project ProjectRegister ConsultantView ConsultantController Consultant ConsultantRegister

20 5. PLATTFORM SPESIFIKK MODELL 5.1 COMPONENT IMPLEMENTATION MODEL Consultant WeekSchedule DaySchedule * 1 * Billable Project TimePeriod 1 * NonBillable Ved å transformere fra PIM til PSM, for vi tre komponenter. WeekSchedule som inneholder klassene WeekSchedule, DaySchedule og TimePeriod blir transformert til et DataSchema. Project som inneholder klassene Project, Billable og NonBillable blir transformert til et DataSchema og Constultant som inneholder klassen Consultant blir til et DataSchema. WeekSchedule Project Consultant For hver av disse, vil det bli generert følgende: EJBEntityComponent, EJBDataSchema EJBKeyClass Remote interface Remote home interface Vi har igjen valgt å sette sammen WeekSchedule og Project til en kompenent som vi kaller for ScheduleInfo

21 5.2 DEPLOYMENT DIAGRAM