INF5120 - Oblig 2. Hour Registration System (HRS)

INF5120 - Oblig 2 Hour Registration System (HRS) 1 av 40

1 Innholdsfortegnelse 1 Innholdsfortegnelse... 2 2 Innholdsfortegnelse for figurer... 3 3 Hour Registration System (HRS)... 4 3.1 Introduksjon... 4 3.2 Avgrensning av oppgaven... 4 4 Business model... 4 4.1 Scoping Statements Context Statement... 4 4.1.1 Antagelser... 4 4.1.2 Aktører og interesser... 6 4.1.3 Overordnet virksomhetsprosess... 6 4.2 Goal model... 8 4.2.1 Målhierarki... 9 4.3 Business Process & Role model... 11 4.3.1 Virksomhetsprosesser (2 nivåer), roller... 11 4.4 Business Resource Model... 15 4.4.1 Informasjon, ressurser og relasjoner... 16 5 Requirement Modell... 17 5.1 System Boundry Model... 17 5.1.1 Aktører... 17 5.1.2 Use Cases... 18 5.2 Subsystem Grouping Model... 19 5.2.1 Subsystemer og use cases... 19 5.3 Reference Architecture Analysis Model... 23 5.3.1 Identifiserte komponenter... 23 5.4 Use Case Scenario Model... 23 5.4.1 Hvordan komponentene samarbeider for å realisere use cases... 23 6 Architecture Model... 23 6.1 Interface & Interaction Specification... 23 6.1.1 Grensesnittbeskrivelser for hver komponent... 23 6.1.2 Samarbeid mellom komponenter... 23 6.2 Component Structure... 23 6.2.1 For valgt applikasjonskomponent... 23 6.3 Internal Design... 23 6.3.1 For subkomponenter i valgt applikasjonskomponent... 23 6.3.2 Mapping til focus/auxiliary klasser... 23 7 Platform Specific Modell... 23 7.1 Component Implementation Modell... 23 7.1.1 J2EE implementasjonsdesign vha UML profil... 23 7.2 Deployment Modell... 23 7.2.1 Deployering av komponenter på infrastruktur... 23 2 av 40

2 Innholdsfortegnelse for figurer Figure 1: Viser en oversikt over bedriftens skop og interessenter... 6 Figure 2:Time Registrering Context Diagram... 7 Figure 3: Målhierarki som viser målsettinger... 9 Figure 4:Nivå 1 : Høynivå aktivitetsmodell Timeregistrering Process Overview 11 Figure 5: Nivå 2 - Lavnivå aktivitetsmodell... 12 Figure 6: Viser en oversikt over Timeregistrering... 13 Figure 7: Viser hvordan prosjekt registreringen realiserer målene... 15 Figure 8: Oversikt over informasjonsmodellen... 16 Figure 9: Oversikt over aktuelle aktører... 17 Figure 10:Use Case diagrammet viser en oversikt over hovedfunksjonaliteten i HRS.... 18 Figure 11:Use casene grupperes i fire hovedkomponenter... 19 Figure 12: Bus Pattern klassediagram... 23 Figure 13: Sekvensdiagram for use caset "ProsjektOversikt"... 23 Figure 14: Sekvensdiagram for use caset "OppdaterProsjekt"... 23 Figure 15: Sekvensdiagram for use caset "RegistrerProsjektdeltaker"... 23 Figure 16:Sekvensdiagram for use caset "GodkjennTimeliste"... 23 Figure 17:Sekvensdiagram for use caset "Beregn lønn"... 23 Figure 18:Sekvensdiagram for use caset "VisProsjektTimebudsjett... 23 Figure 19: Sekvensdiagram for use caset "VisPersonligTimebudsjett"... 23 Figure 20: Sekvensdiagram for use caset "RegistrerTimer"... 23 Figure 21:Grensesnittet for den viktigste komponenten i systemet, TimeregistreringsTjeneste... 23 Figure 22: Klassediagram for å realisere grensesnittet for TimeregistreringsTjeneste... 23 Figure 23:Sekvensdiagram for use caset "OppdaterProsjekt"... 23 Figure 24:Sekvensdiagram for use caset "RegistrerTimer"... 23 Figure 25: Komponentstruktur for HRS... 23 Figure 26: BCE analyse... 23 Figure 27: Mapping til Auxiliary... 23 Figure 28:Klassdiagram for sesjons-bønne... 23 Figure 29: Klassediagram for utvalgt entitets-bønne... 23 Figure 30: Deployment diagram... 23 3 av 40

3 Hour Registration System (HRS) 3.1 Introduksjon Dokumentet er besvarelsen på Oblig 2 i INF5120 Våren 2004 for gruppe 11. Oppgaven går ut på å utvikle en komplett modellbeskrivelse for timeregistreringssystemet HRS. En oversikt over de aktuelle modellene som kreves for innlevering er inneholdt i besvarelsen. Gruppen består av Naila Raza, Khudija Mahmood, Emine Gøcmenoglu og Mohammad Asaf Khan. 3.2 Avgrensning av oppgaven Enkelte av modellene er modellert i modelleringsverktøyet Rose, men stort sett er de fleste modellene modellert i Microsoft Visio. Avgrensinger har vi tatt ut ifra antagelsene som er nevnt nedenfor (se punkt 4.1.1). 4 Business model Dette kapittelet viser en Business modell som viser hvilken rolle systemet som skal utvikles/modelleres (HRS) spiller i kontekst av bedriften der systemet skal anvendes. 4.1 Scoping Statements Context Statement 4.1.1 Antagelser Antagelser viser en overordnet forståelse av domene: Bedriften som vi tar utgangspunkt i, driver hovedsakelig med prosjekter. Bedriften har kun faste ansatte som har fast arbeidstid. Antall timer ansatte jobber utenom fast arbeidstid kan tas ut som avspasering. Alle ansatte(leder, prosjektleder og prosjektdeltakere) har brukernavn og et unikt passord for å logge seg inn på systemet. Prosjektleder er også en prosjektdeltaker. 4 av 40

Ved innlogging kan hver prosjektdeltaker registrere antall timer og se sitt personlige timebudsjett. Hvert prosjekt har et entydig navn, en prosjektleder og registrerte prosjektdeltakere Ledelsen må sørge for at prosjektdeltakere registrer antall timer de har jobbet på de ulike prosjektene hver uke. Systemet vedlikeholder og genererer et personlig timebudsjett for hver av prosjektdeltakerne i bedriften. Prosjektlederen har tilgang til de personlige timebudsjettene som systemet har generert. Ledelsen skal kunne få en oversikt over alle prosjekter, mens prosjektleder har kun tilgang til prosjekter vedkommende har deltatt på. Systemet oppdaterer antall timer brukt ved et prosjekt for alle prosjektdeltakere. Vi antar at ressursene som bedriften ønsker å holde oversikt over, er prosjektdeltakere. Hver uke forberedes det budsjetter for både prosjektdeltakere og prosjekter Administrator vedlikeholder systemet. Oppdatering av et prosjekt kan være en av tre tilfeller: registrere, slette eller endre prosjekt 5 av 40

4.1.2 Aktører og interesser Figure 1: Viser en oversikt over bedriftens skop og interessenter 4.1.3 Overordnet virksomhetsprosess Hovedprosessen i konteksten, Time Registrering Context Diagram. Time Registrering inneholder aktiviteter der prosjektdeltakere registrerer seg på prosjekt og registrering av timer. Vedlikeholder skal støttes av HRS. 6 av 40

Vedlikeholder: Operasjoner: Figure 2:Time Registrering Context Diagram 7 av 40

4.2 Goal model Goal modell viser hvordan systemet er forankret opp mot Context Statement. Ledelsen hovedmål for HRS er å skaffe bedre oversikt over ressurbruk. HRS skal gi en bedre oversikt over arbeidstid knyttet til prosjekter. Dette målet settes om hovedmålsetting i målhierarkiet. Den andre viktige målsettingen er å gi prosjektdeltakere en oversikt over personlig timebudsjett. Dette er et undermål siden den er med på å realisere HRSs hovedmålsetting. Målmodellen i figuren under viser hvordan disse målsettingene realiseres av undermål. 8 av 40

4.2.1 Målhierarki Oversikt over ressursforbruk Oppdater informasjon Innføring av timelister Oversikt over personlig timebudsjett Oversikt over prosjekt timebudsjett Oversikt over Oversikt over Oversikt over Avspasering ferie arbeidstimer Figure 3: Målhierarki som viser målsettinger 1. Oversikt over ressursforbruk hovedmålet for systemet er å gi en god oversikt over ressursbruken for bedriften. HRS gir oversikt over personalressurser. 2. Oppdatert informasjon Det er en forutsetning at man har kontinuerlig oppdateringer (se antagelser) 3. Oversikt over timelister viktig med innføring av timelister for å få oversikt over ressursforbruk, både personlig- og prosjekt timebudsjett 9 av 40

a. Oversikt over personlig timebudsjett hovedmålsetting for at prosjektdeltakere skal anvende systemet i. Oversikt over ferie ansatte skal få vite hvor mye ferie vedkommende har til gode. Prosjektleder skal få oversikt over ferieavvikling ii. Oversikt over avspasering - prosjektdeltakere skal få vite hvor mye avspasering vedkommende har til gode. Det kan være et mål for bedriften å begrense underskudd på timer. iii. Oversikt over arbeidstimer prosjektdeltakere skal få en oversikt over antall arbeidstimer vedkommende har jobbet per prosjekt og samlet. b. Oversikt over prosjekt timebudsjett i. Oversikt over arbeidstimer - prosjektleder skal få en oversikt over total arbeidstiden jobbet per prosjekt. 10 av 40

4.3 Business Process & Role model 4.3.1 Virksomhetsprosesser (2 nivåer), roller Figure 4:Nivå 1 : Høynivå aktivitetsmodell Timeregistrering Process Overview 11 av 40

Forbered Prosjekt Prosessen viser gjennomføring av et prosjekt. Oppdragsgiver sender prosjekt informasjon til sikkerhetsansvarlig som identifiserer data for risiko. Deretter mottar leder prosjektinformasjon (hva prosjektet går ut på osv.) og godkjenner. Etter det sender leder prosjektinformasjon til prosjektleder som oppretter/oppdaterer prosjekt. Prosjektleder registrerer så ansatt(prosjektdeltaker) på prosjektet. Tilslutt får prosjektdeltaker muligheten til å registrere timer på prosjektet som godkjennes/ikke godkjennes. Figure 5: Nivå 2 - Lavnivå aktivitetsmodell 12 av 40

Timeregistrering Diagrammet forklarer prosessen ved timeregistrering. Prosjektdeltaker logger seg på HRS og registrerer timer. Prosjektleder godkjenner/godkjenner ikke. Dersom prosjektleder godkjenner vil det genereres et personlig timebudsjett. Dersom prosjektleder er prosjektdeltaker selv, har vedkommende muligheten til å se både prosjektbudsjett og personlig budsjett. Til slutt lagres informasjonen(submit) og prosessen avsluttes. Ved ikke godkjenning avsluttes/gjentas prosessen. Prosjektdeltaker Prosjektleder Logg inn [godkjent] Registrer timer [ikke godkjent] Lag timebudsjett Prosjekt budsjett Personlig budsjett Submit Figure 6: Viser en oversikt over Timeregistrering Figuren under er en utledning av målhierarkiet og viser hvordan stegene i forberedprosjekt realiserer ulike mål i målmodellen. 13 av 40

Oversikt over ressursforbruk Oppdater informasjon Innføring av timelister Oversikt over personlig timebudsjett Oversikt over prosjekt timebudsjett Opprett prosjekt Registrer ansatt Oversikt over Oversikt over Oversikt over ferie avspasering arbeidstimer Registrer timer 14 av 40

Figure 7: Viser hvordan prosjekt registreringen realiserer målene 4.4 Business Resource Model Informasjonsmodellen identifiserer og definerer hovedtingene og konseptene av domene som er relevant for HRS. Tar alle objekter som er funnet i business model og beskriver forholdet mellom disse. 15 av 40

4.4.1 Informasjon, ressurser og relasjoner Prosjekt timebudsjett timebudsjett Personlig timebudsjett ferie avspassering Figure 8: Oversikt over informasjonsmodellen 16 av 40

5 Requirement Modell 5.1 System Boundry Model 5.1.1 Aktører Figure 9: Oversikt over aktuelle aktører 17 av 40

5.1.2 Use Cases HRS ProsjektOversikt «extends» GenerereRapporter Vedliekhold Leder Administrator OppdatereProsjekt RegistrerProsjektde ltaker Prosjektleder GodkjennTimeliste <<include>> BeregnLønn VisProsjektTimebuds jett Økonomisystem VisPersonligTimebud sjett Prosjektdeltaker RegistrerTimer Figure 10:Use Case diagrammet viser en oversikt over hovedfunksjonaliteten i HRS. 18 av 40

5.2 Subsystem Grouping Model 5.2.1 Subsystemer og use cases Use Case Diagram: Forbered prosjekt HRS ProsjektOversikt «extends» Vedlikehold GenerereRapporter Vedliekhold Leder OppdatereProsjekt Administrator RegistrerProsjektde ltaker Prosjektleder Time registrering GodkjennTimeliste <<include>> Økonomitjeneste BeregnLønn VisProsjektTimebuds jett Økonomisystem VisPersonligTimebud sjett Prosjektdeltaker RegistrerTimer Figure 11:Use casene grupperes i fire hovedkomponenter 19 av 40

Use Case Beskrivelser: Use Case ProsjektOversikt Prioritet 1 Mål Vise oversikt over prosjekter Aktør Leder Prekrav Prosjekter må være registrert i systemet Postkrav Få oversikt over tidligere og aktuelle prosjekter, Scenario Leder trenger å hente ut oversikt over prosjekter og ressursbruk, hvem som har jobbet og hvor mange timer til hvert enkelt prosjekt. Beskrivelse 1 Leder logger seg inn i systemet 1a Feil ved innlogging, tilbakemelding fra systemet 2 Systemet åpner bildet for prosjektoversikt. En oversikt over tidligere prosjekter vises med totalforbruk og aktuelle prosjekter med foreløpig forbruk. 2a Dersom ingen prosjekter er registrert, vises en tom liste 3 Leder velger et prosjekt. Det presenteres detaljer med prosjektleder, prosjektmedarbeidere og deres forbruk. 4 Leder logger seg ut av systemet Kommentar Leder har mulighet til å generere rapporter etter at denne use case hendelsen er oppfylt (best case) Use Case OppdatereProsjekt Prioritet 1 Mål Å kunne endre prosjektdata: registrere, slette og endre prosjekt Aktør Prosjektleder Prekrav Et av de tilfellene avhengig av hva prosjektleder ønsker: Registrere: prosjekt må ikke være registrert fra før Slette: prosjektet må være registrert Endre: prosjektet må være registrert Postkrav Registrert, slettet eller oppdatert prosjekter 20 av 40

Scenario Prosjekter skal ha muligheten til å enten opprette et nytt prosjekt slik at prosjektmedarbeidere kan registrere timer mot prosjektet, slette prosjekter eller endre prosjektinformasjon Beskrivelse 1 Prosjektleder logger seg inn i systemet 1a Feil ved innlogging, tilbakemelding fra systemet 2 Prosjekt leder velger en av tilfellene: registrere, slette, endre prosjekter 3 Prosjektleder lagrer oppdatert informasjon (submit) 4 Systemet bekrefter at oppdateringen er vellykket 5 Prosjektleder logger seg ut av systemet Use Case RegistrerProsjektdeltaker Prioritet 1 Mål Registrere en ny prosjektdeltaker Aktør Prosjektleder Prekrav Prosjektdeltaker er ikke registrert fra før, og prosjektet som skal knyttes til prosjektdeltaker må være registrert fra før Postkrav Ny prosjektdeltaker registrert for ett prosjekt Scenario Prosjektleder trenger å knytte en ny prosjektmedarbeider til et prosjekt Beskrivelse 1 Prosjektleder logger seg inn i systemet 1a Feil ved innlogging, tilbakemelding fra systemet 2 Prosjektleder registrerer en ny prosjektdeltaker 3 Prosjektleder lagrer oppdatert informasjon (submit) 4 Systemet bekrefter at registreringen er vellykket 5 Prosjektleder logger seg ut av systemet Use Case GodkjennTimeliste Prioritet 1 Mål Godkjenne timeliste Aktør Prosjektleder 21 av 40

Prekrav Timer må være registrert av prosjektdeltakere Postkrav Timelister godkjennes Scenario Prosjektleder godkjenner timelister hver uke Beskrivelse 1 Prosjektleder logger seg inn i systemet 1a Feil ved innlogging, tilbakemelding fra systemet 2 Systemet viser registrerte timelister 3 Prosjektleder godkjenner timelister 3a Prosjektleder godkjenner ikke timelister pga feil i listen, og sender melding til prosjektdeltaker 4 Systemet bekrefter at registreringen er vellykket 5 Prosjektleder logger seg ut av systemet Kommentar Etter at prosjektleder har godkjent timelister overfører vedkommende videre godkjente lister til økonomisystemet slik at lønn kan beregnes. Use Case Beregn lønn Prioritet 1 Mål Få beregnet lønn for prosjektdeltakere Aktør Økonomisystem Prekrav Godkjente timelister på være registrert Postkrav Lønn er beregnet Scenario Prosjektdeltakere får riktig lønn ut i fra antall arbeidstimer Beskrivelse 1 Økonomisystemet mottar godkjente timelister fra prosjektleder 1a Overføringen mislykkes 2 Økonomisystemet beregner lønn 3 Økonomisystemet lagrer (submit) Use Case VisProsjektTimebudsjett Prioritet 1 Mål Få oversikt over prosjekter med deres timebudsjett 22 av 40

Aktør Prosjektleder Prekrav Prosjekter må være registrert i systemet Postkrav Få oversikt over sine tidligere og aktuelle prosjekter, Scenario Prosjektleder trenger å hente ut oversikt over sine prosjekter og ressursbruk, hvem som har jobbet og hvor mange timer til hvert enkelt prosjekt. Beskrivelse 1 Prosjektleder logger seg inn i systemet 1a Feil ved innlogging, tilbakemelding fra systemet 2 Systemet åpner bildet for prosjektoversikt. En oversikt over prosjektleders tidligere prosjekter vises med totalforbruk og aktuelle prosjekter med foreløpig forbruk. 2a Dersom ingen prosjekter er registrert, vises en tom liste 3 Prosjektleder velger et av sine prosjekter. Det presenteres detaljer med prosjektmedarbeidere og deres forbruk. 4 Prosjektleder logger seg ut av systemet Use Case VisPersonligTimebudsjett Prioritet 1 Mål Få oversikt over sine personlige timebudsjett Aktør Prosjektdeltaker Prekrav Antall timer for prosjektdeltaker må være registrert i systemet Postkrav Få oversikt over sitt personlig timebudsjett, Scenario Prosjektdeltaker trenger å hente ut oversikt over arbeidstimer, ferie og avspasering. Beskrivelse 1 Prosjektdeltaker logger seg inn i systemet 1a Feil ved innlogging, tilbakemelding fra systemet 2 Systemet åpner bildet for personlig timebudsjett. En oversikt over prosjektdeltakers registrerte timer vises med totalforbruk, ferie og avspasering. 2a Dersom ingen arbeidstimer er registrert, vises en tom liste 23 av 40

3 Prosjektdeltaker logger seg ut av systemet Use Case RegistrerTimer Prioritet 1 Mål Få registrert/redigert antall timer arbeidet på prosjekter Aktør Prosjektdeltaker Prekrav Prosjektdeltaker må være registrert i systemet og på prosjektet det skal registrere timer på Postkrav Antall arbeidstimer er registrert og prosjektdeltakers personlige timebudsjett blir lagret. Scenario Prosjektdeltaker fyller ukentlig liste over antall arbeidstimer som vedkommende har jobbet med hvert prosjekt Beskrivelse 1 Prosjektdeltaker logger seg inn i systemet 1a Feil ved innlogging, tilbakemelding fra systemet 2 Systemet viser prosjektdeltakers personlige timeliste 3 Prosjektdeltaker registrerer antall timer på deltatte prosjekter i den aktuelle perioden. 4 Prosjektdeltaker lagrer(submit) 5 Systemet bekrefter oppdateringen 6 Prosjektdeltaker logger seg ut av systemet 5.3 Reference Architecture Analysis Model 5.3.1 Identifiserte komponenter De identifiserte komponentene vises som et bus pattern i henhold til referanse arkitekturens retningslinjer. 24 av 40

Figure 12: Bus Pattern klassediagram 5.4 Use Case Scenario Model 5.4.1 Hvordan komponentene samarbeider for å realisere use cases 25 av 40

Figure 13: Sekvensdiagram for use caset "ProsjektOversikt" 26 av 40

Tar utgangspunkt fra tilfelle der prosjektleder foretar en "registrering" Sekvensdiagram for use caset OppdaterProsjekt ProsjektRegistrering Timeregistreringstjeneste Prosjektleder Logg inn Logg av registrerprosjekt bekrefterdata submit bekreftlagring Figure 14: Sekvensdiagram for use caset "OppdaterProsjekt" Figure 15: Sekvensdiagram for use caset "RegistrerProsjektdeltaker" 27 av 40

Figure 16:Sekvensdiagram for use caset "GodkjennTimeliste" Figure 17:Sekvensdiagram for use caset "Beregn lønn" 28 av 40

Sekvensdiagram for use caset VisProsjektTimebudsjett ProsjektEditor TimeregistreringsTjeneste Prosjektleder Logg inn hentprosjekter velgprosjekt VisProsjektOversikt hentprosjektdetaljer Logg av Figure 18:Sekvensdiagram for use caset "VisProsjektTimebudsjett Figure 19: Sekvensdiagram for use caset "VisPersonligTimebudsjett" 29 av 40

Figure 20: Sekvensdiagram for use caset "RegistrerTimer" 6 Architecture Model Arkitekturmodellen beskriver i detalj hvordan komponentene arbeider sammen. 6.1 Interface & Interaction Specification 6.1.1 Grensesnittbeskrivelser for hver komponent Data som formidles gjennom dette grensesnittet defineres slik det er vist i figuren under. Vi gjenkjenner her objektmodellen fra businessmodellen. Den er utvidet med klasser som inneholder sammendrag av de viktigste objektene. Grensesnitt ITimeregistreringsTjeneste er spesifisert i klassediagrammet under: 30 av 40

Figure 21:Grensesnittet for den viktigste komponenten i systemet, TimeregistreringsTjeneste 31 av 40

Figure 22: Klassediagram for å realisere grensesnittet for TimeregistreringsTjeneste QoS constraints: 32 av 40

Generell forutsetninger/begrensinger: Det forutsettes at HRS-systemet skal kjøres i et lokalt nettverk og at tilgjengeligheten for systemet er 100% innenfor hver virkedag fra kl.06:00 til kl.21:00. 6.1.2 Samarbeid mellom komponenter Sekvensdiagrammer med utgangspunkt i noen av use casene: Figure 23:Sekvensdiagram for use caset "OppdaterProsjekt" 33 av 40

Figure 24:Sekvensdiagram for use caset "RegistrerTimer" 34 av 40

6.2 Component Structure 6.2.1 For valgt applikasjonskomponent TimeEditor ProsjektEditor TimeregistreringsTjeneste ØkonomiTjeneste HRS Database En JDBC forbindelse mellom HRS databasen og timeregistrerijngstjeneste En forbindelse mellom timeregistreringstjeneste og økonomitjeneste: lønn beregnes ut ifra godkjente timelister Figure 25: Komponentstruktur for HRS 6.3 Internal Design 6.3.1 For subkomponenter i valgt applikasjonskomponent Her spesifiseres det interne designet i TimeregistreringsTjeneste komponenten. I BCE analysen har vi avgrenset oss til de boundary objektene som benyttes av TimeEditor komponenten. 35 av 40

Figure 26: BCE analyse 36 av 40

6.3.2 Mapping til focus/auxiliary klasser TimeregistreringsTjeneste <<Fokus>>TimeregistreringsTjeneste <<Entity>>Ansatt IØkonomiTjeneste ØkonomiTjeneste <<Fokus>>Økonomisystem <<Entity>>Leder <<Entity>>Prosjektleder <<Entity>>Prosjektdeltaker 1 Godkjenner 1..* 1 1 <<Entity>>Prosjekt Oversikt over 1..* Deltar i 1..* 1 Gjelder <<Entity>>Timeliste 1 JDBC HRS Database <<Fokus>>HRS Database Figure 27: Mapping til Auxiliary 37 av 40

7 Platform Specific Modell 7.1 Component Implementation Modell Alle entitets-bønner med EJBRemoteInterface har tilgangsmetoder(get- og set-metoder) for alle attributter. All oppdatering skal gå via sesjons-bønnen som gjør bruk av EJBHomeInterface som har forretningsmetoder (create, find, findall osv.) mot entitetsbønnene. EJBImplementation klassen inneholder selve implementasjonen. 7.1.1 J2EE implementasjonsdesign vha UML profil Figure 28:Klassdiagram for sesjons-bønne 38 av 40

Figure 29: Klassediagram for utvalgt entitets-bønne 7.2 Deployment Modell Deployment diagrammet viser hvordan komponentene utplasseres på de ulike nodene i infrastrukturen. 39 av 40

7.2.1 Deployering av komponenter på infrastruktur Figure 30: Deployment diagram 40 av 40