1 Innledning... 4 2 Forretningsmodell... 5 2.1 Skop beskrivelse... 5 2.1.1 Kontekstbeskrivelse... 5 2.1.2 Avgrensinger... 7 2.1.3 Visjoner for endringer... 8 2.1.4 Risikoanalyse... 8 2.2 Målmodell... 8 2.3 Business Prosess og Rolle Modell... 9 2.4 Business Ressurs Modell... 11 2.5 Work Analysis Refinement Model (WARM)... 12 3 Krav Modell... 16 3.1 Use Case Modell... 16 3.1.1 Systemgrense Modell... 16 3.1.2 Aktørbeskrivelse... 17 3.1.2.1 Prosjektleder... 17 3.1.2.2 Generell ledelse... 17 3.1.2.3 Ansatt... 17 3.1.2.4 Database... 17 3.2 Use Case Scenario Modell... 17 3.2.1 Subsystemgruppering... 18 3.2.2 Prosjekteditor... 18 3.2.3 Rapportvisning... 18 3.2.4 Timeregistreringseditor... 18 3.2.5 Prosjekttjeneste... 18 3.2.6 Prosjekteditor use case... 19 3.2.7 Use case 1: Registrere prosjekt... 19 3.2.8 Use case 2: Registrere ansatte på prosjekt... 20 3.2.9 TimeRegistreringsEditor use case... 20 3.2.9.1 Use case 1: Registrere timer... 21 3.3 Referanse Arkitektur Analyse... 22 4 Arkitektur Modell... 24 4.1 Grensesnittmodell... 24 4.1.1 Komponentgrensesnitt... 24 4.1.2 ProsjektEditor-verktøy beskrivelse... 25 4.2 Interaksjons Modell... 27 5 Plattformspesifikk modell... 28 5.1 Komponent Implementasjonsmodell... 28 5.2 Deployment Modell... 29
Figur 1: Rikt bilde av konteksten...5 Figur 2: Timeregistrering kontekst diagram (use case)...6 Figur 3: Overordnet virksomhetsprosess for et prosjekt...7 Figur 4: Målmodell av Timeregistreringssystemet...9 Figur 5: Prosessoversikten til et prosjekt...10 Figur 6: Ressurs modell...11 Figur 7: Aktivitetsdiagram over Registrere nytt prosjekt...12 Figur 8: Aktivitetsdiagram over Administrere ansatte...13 Figur 9: Aktivitetsdiagram over Registrere timer på prosjekt...13 Figur 10: Aktivitetsdiagram over Godkjenning av timer...14 Figur 11: Aktivitetsdiagram over Generere rapport...15 Figur 12: Overordnet use case av systemet...16 Figur 13: Use Case av Timeregistreringssystemet...17 Figur 14: Gruppering av use case i subbsystem...18 Figur 15: Prosjekteditor Use Case...19 Figur 16: TimeRegistreringsEditor Use Case...20 Figur 19: Use case subsystem...22 Figur 20: Referansearkitekturmodell av systemet...22 Figur 21: Komponentstrukturen for systemet...24 Figur 22: ProsjektTjeneste Interface operasjoner...24 Figur 23: ProsjektEditor komponent struktur...25 Figur 24: Sekvensdiagram for komponenten ProsjektEditor...27 Figur 25: Komponentarkitektur av ProsjektEditorapplikasjonen...29 Figur 26: BCE analyse for ProsjektEditor...30 Figur 27: ProsjektEditor klient for klassediagram fra BCE analyse...31 Figur 28: Prosjekteditor interndesign...31 3
1 Innledning Dette dokumentet beskriver et timeregistreringssystem (HRS) for et tenkt firma. Målet med dokumentet er å beskrive hvordan og hvor denne applikasjonen passer inn i forretningsprosessene til firmaet. Vi har selv bestemt hvordan firmaets struktur skal se ut, og har selv satt avgrensinger i oppgaveløsningen. Vi tenker for oss et konsulentfirma som driver hovedsakelig med programutvikling. Firmaet tar på seg oppdrag fra eksterne kunder i tillegg til å utvikle egne produkter. Produktet som skal designes her vil primært være for internt bruk, men det kunne like godt vært utviklet for et eksternt firma. Prinsippet med oppgaven er å forstå og benytte de prosesser som COMET bygger på. Det er viktig at vi forstår og skiller mellom Business, Krav, Arkitektur og Plattform Spesifikk Modell. 4
2 Forretningsmodell Businessmodellen brukes til å forklare rollen til produktet som blir utviklet i sammenheng med firmaet som vil finansiere produktets utvikling og bruke det. Modellen gir også elementer som kan linkes direkte til arkitekturmodellen. Businessmodellen inkluderer aspekter som mål, forretningsprosesser, steg innenfor forretningsprosessene, roller og ressurser. Disse vil vi diskutere nedenfor. 2.1 Skop beskrivelse 2.1.1 Kontekstbeskrivelse Bedriften ø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. 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. Systemet vil også bli brukt til å kalkulere lønninger. Vi viser konteksten til systemet ved å vise både et rikt bilde og et kontekst use case diagram. Nedenfor viser vi et rikt bilde av konteksten. Hensikten med det rike bildet er for at utviklere lettere skal kunne organisere sin forståelse. Figur 1: Rikt bilde av konteksten Bedriften får oppdrag fra andre kunder ved at de er med på anbudsrunder eller at de får et oppdrag direkte. Før bedriften får et oppdrag og en kontrakt kan signeres er det en del møtevirksomhet. I denne prosessen, men også underveis i utviklingen av produktet, kan det oppstå en del konflikter. Under utviklingen vil de prosjektansatte føre timer på de prosjekter de jobber på. Dette vil mest sannsynlig føre til mer effektivt arbeid. De ansatte kan skrive ut rapporter over sitt eget timebudsjett. Ledelse og administrasjon kan skrive ut rapporter og 5
statistikker over hele prosjekt for å se på ressursforbruket i forhold til kontrakter. Dette er en viktig erfaring som vil føre til bedre kontrakter og høyere effektivitet, og som igjen vil føre til bedre økonomi for bedriften. Vi ønsket å finne ut hvem som hadde nytte og bruk for et slikt system. Nedenfor er et kontekst use case diagram over forretningsmodellen som viser stakeholders og hva de vil ha fra systemet. Figur 2: Timeregistrering kontekst diagram (use case) Tabellen nedenfor viser stakeholders i timeregistreringssystemet: Stakeholder Ansatt Prosjektleder Avdelingsleder Kunde Administrator/Support Økonomiavdeling Beskrivelse Ansvarlig for å føre de timene man bruker på hvert prosjekt som den ansatte er involvert i. Ønsker også å holde oversikt over sitt eget personlige timebudsjett (avspaseringer og ferie). Prosjektlederen for et prosjekt ønsker en oversikt over alle ressurser brukt på prosjektet. Budsjettering. Prosjektlederen gir ansatte tilgang til et prosjekt og godkjenner ansattes timelister. Ønsker statistikk over ressurser brukt på alle underliggende prosjekt avdelingen har ansvar for. Budsjettering. Ønsker oversikt over hvor store ressurser det brukes på et bestilt prosjekt. Da spesielt i sammenheng med kontrakten. Person med administrasjonsrettigheter for å oppdatere systemet med hensyn på brukernavn og rettigheter. Vil også supportere andre brukere av systemet. Oversikt over timeforbruket for prosjekter og ansatte for å sette opp lønninger. Budsjettering. Aktivitetsdiagrammet nedenfor viser på et høyt nivå hvordan prosessen til et normalt prosjekt vil forløpe seg. Stegene er som følger: 6
Prosjektanbud er forretningsprosessen som foregår når bedriften forsøker å få et oppdrag hos en kunde. Hvis bedriften ikke får anbudet så avsluttes prosessen. Prosjektkontrakt er prosessen etter at bedriften har fått anbudet og en kontrakt skal skrives med kunden. Prosjektgjennomføringen er selve analysen, designet og implementasjonen av produktet det har blitt inngått en kontrakt om. Prosjektoppsummering er prosessen med å evaluere prosjektgjennomføringen. Evalueringen kan være for eksempel å se på ressursforbruket i forhold til kontrakten. Noe som vil hjelpe bedriften med å skrive kontrakter senere for å få et bedre produkt og større økonomisk gevinst. Figur 3: Overordnet virksomhetsprosess for et prosjekt 2.1.2 Avgrensinger Vi har i denne oppgaven satt oss noen avgrensinger for at omfanget av oppgaven ikke skal bli for stor. Sett ut fra figur 3 vil vi i oppgaven hovedsakelig ta for oss tilstanden Prosjektgjennomføring da det er her selve timeregistreringen vil foregå, men vi vil også komme inn på tilstanden Prosjektoppsummering da dette innebærer generering av rapporter. Dette vil komme tydeligere fram senere i dokumentet. Vi vil også gjøre avgrensninger videre i analysen og designet av produktet, som vi vil dokumentere og forklare underveis i dokumentet. 7
2.1.3 Visjoner for endringer Timeregistreringssystemet vil være et web-basert og mest mulig automatisert redskap for å få en oversikt over ressursbruken på prosjektene i firmaet. Det skal kunne skrives ut rapporter og statistikker. Systemets hovedoppgaver vil være: effektivisering av ressurser, dvs. bedret økonomi oversikt over ressursforbruk på prosjekter oversikt over timebudsjett (avspasering og ferie) for en ansatt 2.1.4 Risikoanalyse Da dette ikke er noe reelt oppdrag vil vi her bare kunne finne risikoer ved å tenke logisk. Slik vi ser det er det ingen store risikoer involvert i dette prosjektet, men i tabellen nedenfor har vi satt opp noen emner: Emne Sikkerhet Teknologi Antall brukere Oppetid Utviklingsgruppen Effektivitet Risiko Systemet vil inneholde data som ikke alle skal ha tilgang på. Derfor må det være mekanismer for streng tilgangskontroll. Systemet skal være Web-basert og utviklet i Java, som utviklerne har gode og lange erfaringer med. Systemet vil ikke i utgangspunktet brukes av mange brukere, men bør designes for å tåle mange brukere for evt. salg av produktet. Systemet må ha en oppetid på 24 timer 7 dager i uken. Utviklingsgruppen har stor erfaring fra lignende prosjekter. Systemet må støtte en effektiv kommunikasjonsprotokoll mellom klienter og serveren. 2.2 Målmodell Meningen med målmodellen er å bli enig med virksomhetens interessenter om businessmål som vil bli oppfylt når man implementerer og tar i bruk systemet. Målet til bedriften er at systemet skal bidra til økt effektivisering av ressursbruk på prosjekter slik at de får bedre oversikt over hvor ressursene brukes og over ansattes personlige timebudsjett. Hovedmål: Effektivisering av ressurser Undermål: Lettere oversikt over ressursbruk per prosjekt. Oversikt over personlig timebudsjett 8
Figur 4: Målmodell av Timeregistreringssystemet 2.3 Business Prosess og Rolle Modell Meningen med denne modellen er å identifisere og detaljere alle prosessene i virksomheten, i den grad det er nødvendig for å detaljere rollen, som blir støttet av timeregistreringssystemet. Vi har tatt for oss selve livsgangen til et prosjekt som den overordnede prosessen. Denne prosessen oppstår når et nytt prosjekt blir dannet og avslutter når prosjektet avslutter. Prosjektprosessen består av 5 del-prosesser: Registrere nytt prosjekt beskriver hvordan et prosjekt blir dannet og opprettet i systemet. Administrere ansatte beskriver hvordan ansatte får tilgang/mister tilgang på prosjekter. Registrere timer på prosjekt beskriver hvordan ansatte registrerer timer på egne prosjekter. Godkjenning av timer beskriver hvordan prosjektleder sjekker timelistene og godkjenner dem. Generere rapport beskriver hvordan stegene for å generere prosjektrapport eller personlig rapport. 9
Figur 5: Prosessoversikten til et prosjekt 10
2.4 Business Ressurs Modell Denne modellen er en typisk klassemodell som viser relasjonene mellom informasjonsobjekter (med attributter) som finnes i forretningsdomenet. Denne modellen er en informasjonsmodell som identifiserer og definerer ting og konsepter (ressurser) i virksomheten som er relevant for HRS. Vi har lagt hovedfokuset på prosjektet som er knyttet til ansatte, kunder og arbeidsperiode. Et prosjekt er alltid knyttet til en ansatt som har rollen prosjektleder. Ansatte kan altså ha to forskjellige roller i forhold til prosjektet, enten som prosjektleder eller medarbeider. Figur 6: Ressurs modell 11
2.5 Work Analysis Refinement Model (WARM) Aktivitetsdiagrammene i figur 7-12 beskriver i detalj delprosessene (pkt 2.3) som inngår i prosjektets levetid. Hver svømmebane i diagrammene korresponderer med en aktør i virksomheten, og aktivitetene i hver svømmebane reflekterer arbeidet som hver aktør er ansvarlig for. I figurene under representerer en (H) et human step, en (T) et tool step og (I) et immidiate step. Registrere nytt prosjekt: Figur 7: Aktivitetsdiagram over Registrere nytt prosjekt Aktivitet Beskrivelse Motta prosjekt Bedriften starter/overtar et nytt prosjekt. Prosjektkontrakt Bedriften/oppdragsgiver utarebeider kontrakt. Kontrakt signeres. Registrere prosjekt Prosjektet registreres i systemet. 12
Administrere ansatte: Figur 8: Aktivitetsdiagram over Administrere ansatte Aktivitet Beskrivelse Finn ansatt(e) Prosjektleder slår opp i database over ansatte for å finne ansatt-id. Gi ansatt(e) tilgang på prosjekt Prosjektleder finner aktuellt prosjekt. Prosjektleder legger inn ansatt-id til ansatt som skal gis tilgang til prosjekt. Fjerne ansatt(e) fra prosjekt Prosjektleder finner aktuelt prosjekt. Prosjektleder legger inn ansatt-id til ansatt som skal fjernes fra prosjekt. Registrere timer på prosjekt: Figur 9: Aktivitetsdiagram over Registrere timer på prosjekt Aktivitet Beskrivelse Velge prosjekt Ansatt finner frem til prosjekt. Føre inn timer Ansatt har valgt prosjekt Fører inn timer på prosjekt Submit Ansatt er ferdig å føre timer og sender timeliste til prosjektleder. 13
Godkjenning av timelister: Figur 10: Aktivitetsdiagram over Godkjenning av timer Aktivitet Beskrivelse Finn prosjektansatt(e) Prosjektleder slår opp i database over ansatte for å finne ansatt-id. Hente registrert timeliste Prosjektleder henter inn timeliste for den aktuelle ansatte. Sjekke timeliste Prosjektleder sjekker timeliste i henhold til personlige notater om ansattes arbeidsmengde. 14
Generere rapport: Figur 11: Aktivitetsdiagram over Generere rapport Aktivitet Beskrivelse Personling rapport Ansatt finner frem til aktuelltprosjekt. Ansatt velger å få generert en rapport om prosjektstatus. Prosjektrapport Prosjektleder finner Prosjektleder fører inn timer på prosjekt 15
3 Krav Modell Målet med kravmodellen er å identifisere systemkrav. Dette involverer funksjonelle krav, ikke-funksjonelle krav (QoS) og begrensninger. Ikke-funksjonelle krav vil være ting som utførelse, tilgjengelighet, sikkerhet, pålitelighet osv. Når det gjelder begrensninger så kan dette være ting som tilgjengelige ressurser, spesielle kundepreferanser, bedriftsstrategi osv. I denne modellen vil vi beskrive use case for systemet, dele det opp i subbsystemer og beskrive et utvalg av scenarioer. I denne oppgaven har vi avgrenset oss til å vise systemgrensemodellen og beskrivelse av subbsystemer og noen av use casene. 3.1 Use Case Modell 3.1.1 Systemgrense Modell Her vil vi vise og beskrive systemgrenser, aktører og deres ansvar, og service gitt av systemet. For å finne disse bruker vi kontekstbeskrivelsen, endringsvisjon, business prosess og business ressursmodell og rollemodellen fra Business Modellen. Figur 13 nedenfor viser en overordnet oversikt over aktørene til systemet. Her har vi her gjort noen avgrensninger ved å ha samlet all ledelse og administrasjon bortsett fra prosjektlederen som en aktør. Vi har også fjernet support aktøren. Grensene til systemet er definert av aktørene utenfor systemet og use casene inne i systemet. Figur 12: Overordnet use case av systemet I figur 14 viser vi use casene som de forskjellige aktørene ønsker av systemet. 16
Figur 13: Use Case av Timeregistreringssystemet 3.1.2 Aktørbeskrivelse 3.1.2.1 Prosjektleder Prosjektlederen er ansvarlig for at et prosjekt gjennomføres etter de rammer og betingelser som er satt økonomisk og i kontrakten. Han er ansvarlig for å administrere prosjekter. 3.1.2.2 Generell ledelse Denne aktøren vil bestå av forskjellige avdelingsledere. Disse har ansvaret for budsjetteringer og kontraktoppfølginger. 3.1.2.3 Ansatt En ansatt er med i ett eller flere prosjekt og er ansvarlig for å utvikle produkter og føre hvor mye tid han bruker på prosjektet. 3.1.2.4 Database Ansvarlig for å til enhver tid være tilgjengelig slik at systemet kan hente og lagre data. 3.2 Use Case Scenario Modell I dette kapitelet skal hvert use case beskrives detaljert. Her hva vi gjort avgrensinger og vil beskrive kun noen få for å vise fremgangsmåten. 17
3.2.1 Subsystemgruppering Vi har her gruppert alle use case i subsystemene, se figur 15. Grupperingen er laget ut fra hvordan aktørene ønsker å bruke systemet - systemet ble delt inn i fire deler. Vi vil først beskrive hvert enkelt subsystem og deretter ta for oss scenarioene for hvert enkelt use case. Figur 14: Gruppering av use case i subbsystem 3.2.2 Prosjekteditor Prosjekteditoren er en verktøykomponent og blir hovedsakelig brukt av prosjektlederen, men også generell ledelse for godkjenning av timeliste. Denne komponenten inneholder alle use case for å administrere et prosjekt i systemet. Tilgangsrettighetene må kontrolleres. 3.2.3 Rapportvisning Rapportvisning er en verktøykomponent brukt av alle aktører. Komponenten er en webbasert klient og vil kun vise rapporter. Tilgangsrettighetene må kontrolleres. 3.2.4 Timeregistreringseditor Denne editoren er verktøykomponent og brukes av prosjektleder og ansatt. Komponenten er webbasert og brukes til å føre timer på prosjekt. Tilgangsrettighetene må kontrolleres. 3.2.5 Prosjekttjeneste Prosjekttjeneste er en business-service komponent som tjener alle de andre subbsystemene. Det har kun to use caser: 9. Lese fra database og 10. Skrive til database. 18
3.2.6 Prosjekteditor use case Alle aktører og use case til subsystemet Prosjekteditor vises i figuren under. Vi avgrenser oppgaven noe her og beskriver to av disse use casene. Figur 15: Prosjekteditor Use Case 3.2.7 Use case 1: Registrere prosjekt Use case 1 Registrere prosjekt Prioritet 1 Mål Registrere et nytt prosjekt i systemet Aktører Prosjektleder Prebetingelser Logget inn på systemet Postbetingelser Prosjekt registrert Trigger Prosjektleder mottar et nytt prosjekt Scenario Som mål. Beskrivelse Steg Handling 1. Aktør legger inn data om nytt prosjekt 2. Systemet lagrer endringene 3. Systemet informerer om at data er lagret Alternativt scenario *.a Systemet feiler 19
3.2.8 Use case 2: Registrere ansatte på prosjekt Use case 1 Registrere ansatte på prosjekt Prioritet 1 Mål Registrere ansatte og gi ansatte tilgang på et prosjekt Aktører Prosjektleder Prebetingelser Logget inn på systemet og rettighet til å registrere ansatte Postbetingelser Data lagret og ansatte har tilgang på prosjektet Trigger En ansatt skal starte å jobbe på et prosjekt Scenario Som mål. Beskrivelse Steg Handling 1. Systemet henter prosjekter som aktør har tilgang på 2. Aktør velger ønsket prosjekt 3. Aktør velger/finner ansatt 4. Aktør gir ansatt tilgang til prosjektet 5. Aktør bekrefter endringer 6. Systemet lagrer endringene 7. Systemet informerer om at data er lagret Alternativt scenario *.a Systemet feiler 4. Endringene er ukorrekte 4.1 Aktør godtar ikke bekreftelsen 4.2 Systemet hopper til steg 2 3.2.9 TimeRegistreringsEditor use case Dette subsystemet har bare en use case og en aktør, se figuren under. Figur 16: TimeRegistreringsEditor Use Case 20
3.2.9.1 Use case 1: Registrere timer Use case 1 Registrere timer Prioritet 1 Mål Registrere timer jobbet på et prosjekt Aktører Ansatt Prebetingelser Logget inn på systemet Postbetingelser Timer registrert og lagret Trigger Det er i slutten av uken og timeliste skal føres Scenario Som mål. Beskrivelse Steg Handling 1. Aktør velger å registrere timer 2. Aktør finner prosjekt 3. Aktør velger tidsperiode 4. Aktør registrerer timer 5. Systemet sjekker for logiske feil 6. Aktør bekrefter timeliste 7. Systemet lagrer data 8. Systemet informerer om at registreringen er lagret Alternativt scenario *.a Systemet feiler 5 Feil inntastede verdier 5.1 Systemet gir en feilmelding 5.2 Systemet merker de verdier det anser som feilaktige 5.3 Systemet hopper til steg 4 6 Timeliste har feil data 6.1 Aktør godtar ikke bekreftelse 6.2 Systemet hopper til steg 2 21
3.3 Referanse Arkitektur Analyse Figur 17: Use case subsystem Use-case diagrammet i figuren over viser subsystemene som er identifisert i dette systemet. Hvert subsystem inneholder igjen et sett med use cases. De forskjellige use casene er gruppert i subsystemer ettersom hvilken funksjonalitet de tilbyr. Menneskelige brukere (aktørene Prosjektleder, Generell ledelse og Ansatt) vil bruke systemet gjennom verktøykomponenter som tilbyr et (grafisk) brukergrensesnitt. Systemaktøren Database vil klassifiseres som et eget subsystem i modellene som følger, men vil ellers regnes som et eksternt system i forhold til HRS-systemet. Denne databasen vil tilby et grensesnitt til subsystemet Produkttjeneste, som muliggjør bruk av databasens tjenester. Figur 18: Referansearkitekturmodell av systemet 22
Figur 20 (over) viser et klassediagram over komponentstrukturen og hvilke kategorier (Tool, BusinessService eller ResourceService) de forskjellige subsystemene tilhører (øverste vertikale lag er Tools, nest nederste lag er BusinessService og nedereste lag er ResourceService). Subsystemene ProsjektEditor, TimeregistreringsEditor og Rapportvisning brukes av menneskelige aktører (sluttbrukerene). ProsjektEditor er en spesialisert klientapplikasjon som brukes av prosjektledere og som må installeres på hver terminal der denne skal brukes, mens TimeregistreringsEditor og Rapportvisning brukes av alle som er involvert i ett eller flere prosjekter, og vil være tilgjengelig via en webserver. Subsystemet ProsjektTjeneste befinner seg på Business-service nivå og tilbyr tjenester til subsystemene på tool-nivå (punktet over). Kommunikasjonen skjer over et nettverk. Subsystemet ProsjektInfo tilbyr database-fasiliteter for persistent lagring til ProsjektTjeneste. Dette subsystemet er modellert utenfor konteksten av selve HRSsystemet, da det forutsettes realisert av eksisterende standardkomponenter (vanlig databasetjener). 23
4 Arkitektur Modell 4.1 Grensesnittmodell 4.1.1 Komponentgrensesnitt Figur 19: Komponentstrukturen for systemet De forskjellige komponentene kommuniserer med hverandre via grensesnitt som illustrert i figur 21. ProsjektTjeneste har i tillegg til subsystemene beskrevet over også interaksjoner med EpostTjener som bruker epost for å sende notifikasjoner om at medarbeidere på et prosjekt har levert timeliste. Klassen ProsjektTjeneste tilbyr sine operasjoner til de forskjellige verktøykomponentene gjennom grensesnittet IProsjektTjeneste, som er vist i klassediagrammet i figuren under. Figur 20: ProsjektTjeneste Interface operasjoner 24
Under har vi valgt å beskrive ProsjektEditor-verktøyet i detalj... 4.1.2 ProsjektEditor-verktøy beskrivelse Figur 21: ProsjektEditor komponent struktur Diagrammet over viser de interne komponentene i ProsjektEditor-verktøyet. ProsjektEditor UI representerer brukergrensesnittet (vil sannsynligvis realiseres som et GUI, dvs. grafisk brukergrensesnitt). ProsjektEditor-verktøyet består som illustrert over av et brukergrensesnitt (ProsjektEditor UI) og en brukertjeneste (ProsjektEditor US). ProsjektEditor UI tilbyr sine operasjoner til ProsjektEditor US gjennom grensesnittet IBrukerTjeneste. Videre har ProsjektEditor US tilgang til operasjonene i subsystemet ProsjektTjeneste gjennom grensesnittet IProsjektTjeneste. UserService Business Ressursmodellen og Use Case diagrammet for subsystemet ProsjektEditor viser sammen hvilken informasjon som skal presenteres til brukeren av prosjekteditoren, og som derfor må tilbys av ProsjektEditor UI. En opplistning av de forskjellige Use Casene i subsystemet ProsjektEditor, hvilke operasjoner som benyttes og hvilke data i Business Ressursmodellen som leses eller endres: «Registrere prosjekt» - bruker leggtilprosjekt() for å registrere data. Følgende klasser/assosiasjoner oppdateres: Prosjektleder blir automatisk den ansatte som utfører «Registrere prosjekt»- use caset. Prosjekt prosjektet gis et unikt navn av prosjektleder. 25
«Registrere ansatte på prosjekt» - bruker hentprosjekterprosjektleder() for å finne det aktuelle prosjektet og hente ut prosjektdata, og leggtilansatt() for å legge til nye ansatte begge fra ProsjektTjeneste. Følgende klasser/assosiasjoner oppdateres: Medarbeider legges inn av prosjektleder. «Endre prosjektdetaljer» - bruker hentprosjekterprosjektleder() for å finne det aktuelle prosjektet og hente ut prosjektdata, og endreprosjektdata() for å registrere endringene begge fra ProsjektTjeneste. Følgende klasser/assosiasjoner oppdateres: Prosjektleder en prosjektleder kan frasi seg rollen som prosjektleder og la en annen ansatt ta over denne rollen. Kunde legges inn av prosjektleder. Medarbeider gir mulighet fjerne medarbeidere fra et prosjekt. «Godkjenne timeliste» - bruker hentprosjekterprosjektleder() for å finne det aktuelle prosjektet og hente ut prosjektdata, og godkjennetimeliste() for å registrere de godkjente timelistene begge fra ProsjektTjeneste. Følgende klasser/assosiasjoner oppdateres: Arbeidsperiode endrer statusflagg for arbeidsperiode til «godkjent». «Avslutt prosjekt» - bruker hentprosjekterprosjektleder() for å finne det aktuelle prosjektet og hente ut prosjektdata og avsluttprosjekt() for å endre status på prosjektet. Følgende klasser/assosiasjoner oppdateres: Prosjekt endrer statusflagg for et prosjekts aktivitetstilstand til «avsluttet». Merk at listen over ikke spesifiserer nærmere navn på de forskjellige attributter som vil forekomme i de forskjellige klassene. 26
4.2 Interaksjons Modell Figur 22: Sekvensdiagram for komponenten ProsjektEditor Eksempelet i sekvensdiagrammet over viser et typisk samspill mellom de gitte subsystemene ved igangsetting av et nytt prosjekt, og operasjonene som kalles i de forskjellige komponentene. 27
5 Plattformspesifikk modell Ved utvikling av den plattformspesifikke modelleringen benyttes artifaktene fra arkitekturmodellen som input. Vi har ikke lagt stor vekt på denne delen, og har prioritert en kort beskrivelse av hvordan en fornuftig komponentarkitektur vil se ut for prosjekteditorapplikasjonen. Elementer i dette kapittelet er ikke beskrevet like nøye som elementer i de foregående kapitler, siden vi hadde inntrykk av at BCE-analyse og implementasjonsmodell ikke var så viktig i denne oppgaven (dette i henhold til informasjon gitt på forelesning). 5.1 Komponent Implementasjonsmodell Figuren nedenfor beskriver arkitekturen for hvordan komponentene lagvis vil kommunisere. Klientapplikasjonen vil implementeres i Java, og kommunisere med forretningslogikken (ProsjektTjeneste) gjennom et distribuert objekt-miljø. Forretningslogikken samt informasjonslaget implemeteres med EJB teknologi, som vil sikre et god distribuert system som tilrettelegger for målene vi har satt oss. 28
Figur 23: Komponentarkitektur av ProsjektEditorapplikasjonen 5.2 Deployment Modell Spesifikt hvilken type applikasjonsserver, samt type database, er foreløpig ikke bestemt. 29
Figur 24: BCE analyse for ProsjektEditor Beskrivelse av BCE-klassene vist i figuren over: ProsjektKontroller - dette er hovedkontroller for utførelse av disse use casene. Enkle dialogbokser: Nytt - brukes for å lage nytt prosjekt. Endre - brukes for å endre eksisterende prosjekt. Åpne - brukes for å åpne et eksisterende prosjekt. Print - brukes for å skrive ut et prosjekt. Avbryt - brukes for å avbryte et prosjekt. Lagre - brukes for å lagre prosjektdata. 30
Diagrammet under viser avbildningen fra BCE-analysemodellen til klassedesignmodellen. Figur 25: ProsjektEditor klient for klassediagram fra BCE analyse 31
Under vises en intern design av strukturen mellom de forskjellige implementasjonsklassene. Vi har ikke tegnet inn eventuelle auxiliary- og entityklasser i figuren under. Figure 28: Prosjekteditor intern design 32