1 Innledning Plattformspesifikk modell Komponent Implementasjonsmodell Deployment Modell... 29
|
|
- Tone Holt
- 7 år siden
- Visninger:
Transkript
1
2 1 Innledning Forretningsmodell Skop beskrivelse Kontekstbeskrivelse Avgrensinger Visjoner for endringer Risikoanalyse Målmodell Business Prosess og Rolle Modell Business Ressurs Modell Work Analysis Refinement Model (WARM) Krav Modell Use Case Modell Systemgrense Modell Aktørbeskrivelse Prosjektleder Generell ledelse Ansatt Database Use Case Scenario Modell Subsystemgruppering Prosjekteditor Rapportvisning Timeregistreringseditor Prosjekttjeneste Prosjekteditor use case Use case 1: Registrere prosjekt Use case 2: Registrere ansatte på prosjekt TimeRegistreringsEditor use case Use case 1: Registrere timer Referanse Arkitektur Analyse Arkitektur Modell Grensesnittmodell Komponentgrensesnitt ProsjektEditor-verktøy beskrivelse Interaksjons Modell Plattformspesifikk modell Komponent Implementasjonsmodell Deployment Modell... 29
3 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
4 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
5 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 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
6 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
7 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 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
8 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 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
9 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
10 Figur 5: Prosessoversikten til et prosjekt 10
11 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
12 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
13 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
14 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
15 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
16 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 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
17 Figur 13: Use Case av Timeregistreringssystemet Aktørbeskrivelse 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 Generell ledelse Denne aktøren vil bestå av forskjellige avdelingsledere. Disse har ansvaret for budsjetteringer og kontraktoppfølginger 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 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
18 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 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 Rapportvisning Rapportvisning er en verktøykomponent brukt av alle aktører. Komponenten er en webbasert klient og vil kun vise rapporter. Tilgangsrettighetene må kontrolleres 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 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
19 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 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
20 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 TimeRegistreringsEditor use case Dette subsystemet har bare en use case og en aktør, se figuren under. Figur 16: TimeRegistreringsEditor Use Case 20
21 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
22 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
23 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
24 4 Arkitektur Modell 4.1 Grensesnittmodell 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
25 Under har vi valgt å beskrive ProsjektEditor-verktøyet i detalj 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
26 «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
27 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
28 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
29 Figur 23: Komponentarkitektur av ProsjektEditorapplikasjonen 5.2 Deployment Modell Spesifikt hvilken type applikasjonsserver, samt type database, er foreløpig ikke bestemt. 29
30 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
31 Diagrammet under viser avbildningen fra BCE-analysemodellen til klassedesignmodellen. Figur 25: ProsjektEditor klient for klassediagram fra BCE analyse 31
32 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
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...
DetaljerINF5120 Oblig 2 - Timeregistreringssystem Gruppe 25 Annette Kristin Levine Nils-Kristian Liborg Unni Nyhamar Hinkel
INF5120 Oblig 2 - Timeregistreringssystem Gruppe 25 Annette Kristin Levine Nils-Kristian Liborg Unni Nyhamar Hinkel 2-1 Business Model 2-1 a) Scoping statements I Våre avgrensninger Timeregistreringssystemet
DetaljerUniversity of Oslo Department of Informatics. INF Modellering med objekter Oblig 2, V2004. Skrevet av:
University of Oslo Department of Informatics INF5120 - Modellering med objekter Oblig 2, V2004 Skrevet av: Gruppe 16 Geir Atle Hegsvold (gahegsvo) Harald Maalen (haralm) André Sollie (andresol) 2 Index
DetaljerUniversity of Oslo Department of Informatics. Hours Registration System (HRS) INF 5120 Oblig 2. Skrevet av:
University of Oslo Department of Informatics Hours Registration System (HRS) INF 5120 Oblig 2 Skrevet av: Lars Warholm Astrid Magistad Solvor Skaaden Kristine Sæhlie (lwarholm) (astrim) (sjskaade) (krissae)
DetaljerINF 5120 Obligatorisk oppgave Nr 2
INF 5120 Obligatorisk oppgave Nr 2 Vigdis Bye Kampenes Stein Grimstad Gruppe 26 INF 5120 Obligatorisk oppgave Nr 2... 1 1 Business model... 2 Innledende kommentarer... 2 Andre avgrensninger... 2 Scoping
DetaljerOblig2 i INF5120 Modellering med objekter UiO V04, Timelisteføringssystem Ver 6. 040428
Oblig2 i INF5120 Modellering med objekter UiO V04, Timelisteføringssystem Ver 6. 040428 Gruppe 1: Fredrik Melsom Klausen, Andreas Limyr, Odd-Wiking Rahlff, Tho Diu Tang 1...1 2. BUSINESS MODEL...2 2.1
DetaljerEksamen INF
Eksamen INF5120 06.06.2005 Et løsningsforslag Oppgave 1 a) Business Model Oppgaven spør om en business model for samhandlingen mellom Buyer og Seller, og det er da viktig å ikke modellere alt det andre!!!
DetaljerHour Registration System (HRS) Oblig 2. DEL 1: COMET Business Modelling
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 Business antakelser Ansatt kan registrere
DetaljerINF5120 Obligatorisk innleving 2 Gruppe 7. Ole Tommy, Tor Eric, Audun og Kai
INF5120 Obligatorisk innleving 2 Gruppe 7 Ole Tommy, Tor Eric, Audun og Kai Innholdsfortegnelse Innholdsfortegnelse...2 1 Business Model...3 1.1 Scoping Statements...3 1.1.1 Context Statement...3 1.2 Goal
DetaljerForslag til løsning. Oppgave 1
Forslag til løsning Eksamen 2003 Oppgave 1 A) Lag en Business Model (COMET) for krisehåndteringssystemet. B) Diskuter fordeler og ulemper ved bruk av COMET i forhold til (Rational) Unified Process for
DetaljerConference Centre Portal (CCP)
IN-MMO Obligatorisk oppgave 1 Brian Elvesæter mmo-oppgaver@ifi.uio.no 1 Conference Centre Portal (CCP) 2 1 Oblig 1: Problem description [1/3] The Conference Center Portal is an Internet portal that organizers
DetaljerINF 5120 Obligatorisk oppgave 2
INF 5120 Obligatorisk oppgave 2 Timeregistreringssystem (Hour Registration System HRS) Gruppe 14: Mats Bue, Harald Børresen, Vegard Dehlen Del 1 Business Model Aktører og interesser Rich Picture En enkel
DetaljerUse case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?
1/15/2004 1 Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kapittel 8 i Gurholt og Hasle Kirsten
DetaljerUKE 11 UML modellering og use case. Gruppetime INF1055
UKE 11 UML modellering og use case Gruppetime INF1055 Hva skal vi i dag? Analyse og design - kapittel 5 og 7 UML modellering Ukesoppgaver 3: Modellering av krav UML UML Kompetansemål Modellering av krav
DetaljerGJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING HELGA NYRUD & KRISTIN BRÆNDEN
GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING INF1050 V16 HELGA NYRUD & KRISTIN BRÆNDEN TEMAER SÅ LANGT I KURSET Forelesning 1: Systemutvikling og systemutviklingsprosesser Forelesning 2: Prosessmodeller
DetaljerUse case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel
Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kirsten Ribu beskriver kravene til systemet,
DetaljerModellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn
INF1050: Systemutvikling 11. februar 2015 Modellering av krav Universitetslektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering
DetaljerINF Modellering med objekter (Oblig 2) **TimeregistreringSystem** (Designet av Alen Cemer
INF5120 - Modellering med objekter (Oblig 2) **TimeregistreringSystem** (Designet av Alen Cemer alence@ifi.uio.no) 1 2 2-1: Business Model... 5 Scoping Statements Context Statements... 5 Goal modell...
DetaljerGruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0>
Gruppenavn Prosjektnavn Beskrivelse av design For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning
DetaljerGJENNOMGANG UKESOPPGAVER 7 REPETISJON
GJENNOMGANG UKESOPPGAVER 7 REPETISJON INF1050 V16 KRISTIN BRÆNDEN DAGENS TEMA Oppgaver hentet fra tidligere eksamensoppgaver om temaene vi har gått gjennom til nå DAGENS PLAN Gjennomgang av oppgaver Repetisjon
DetaljerUKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski
UKE 13 Mer UML modellering Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Hva skal vi i dag? Objektorientert design - kapittel 5 og 7 UML modellering Aktivitetsdiagrammer Klassediagram Ukesoppgaver
DetaljerProduktrapport Gruppe 9
Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette
DetaljerKenneth A. Hansen (kennetah) Anders Gravdal (andergra) Thomas H. Espe (thomases)
!"$#&%('*)+#&%,%.- 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
DetaljerUse Case-modellering. INF1050: Gjennomgang, uke 04
Use Case-modellering INF1050: Gjennomgang, uke 04 Kompetansemål Modellering av krav Kunne modellere ulike typer krav UML-diagrammer Innføring i grunnleggende UML-modellering Bruksmønster (use case) Sekvensdiagram
DetaljerI dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?
UML Use case drevet analyse og design 31.01.2005 Kirsten Ribu I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 1 2 Domenemodell visualisering
DetaljerUML-Unified Modeling Language
UML-Unified Modeling Language Use case realisering Designmodellering 21.01.2004 Kirsten Ribu Use Case diagram Klassediagram Oppførselsdiagrammer: Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram
DetaljerDel - leveranse Del 2. Inf 2120 fredag Gruppe 1 Knut Johannes Dahle
Del - leveranse Del 2 Inf 2120 fredag 29.4 Gruppe 1 Knut Johannes Dahle AV Catrine Myhre (catrinem@ifi.uio.no) Mehdi Zare (mehdiz@ifi.uio.no) Odd Christer Brovig (oddcb@ifi.uio.no) Christer Aas (chrisva@ifi.uio.no)
DetaljerFra krav til objekter. INF1050: Gjennomgang, uke 05
Fra krav til objekter INF1050: Gjennomgang, uke 05 Kompetansemål Systemmodellering og systemperspektiv Utvikle abstrakte modeller av et system Ulike modeller representerer ulike perspektiver av systemet
DetaljerSpesifikasjon av Lag emne
Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objekter Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use Cases) o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer
DetaljerModellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn
INF1050: Systemutvikling 07. februar 2017 Modellering av krav Førstelektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering av
DetaljerUniversitetet i Oslo Institutt for informatikk. Eskild Busch. UML hefte
Universitetet i Oslo Institutt for informatikk Eskild Busch UML hefte 6. desember 2000 Innhold Dette heftet tar for seg deler av UML som er sentralt i kurset IN29. Use case-, sekvens-, tilstand- og klassediagrammer,
DetaljerAnsvarsdrevet OO: CRC og UML Sekvensdiagrammer
Fra krav til objekter Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer INF1050--1 Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use
DetaljerGJENNOMGANG UKESOPPGAVER 6 MER OM OBJEKTORIENTERING OG UML
GJENNOMGANG UKESOPPGAVER 6 MER OM OBJEKTORIENTERING OG UML INF1050 V16 KRISTIN BRÆNDEN DAGENS TEMA Klassediagram Aktivitetsdiagram Tilstandsdiagram Sekvensdiagram 1 Ta utgangspunkt i følgende klasser:
DetaljerUNIVERSITETET I OSLO
UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 2. juni 2014 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 4 sider Vedlegg: Ingen Tillatte hjelpemidler:
DetaljerUML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu
UML 1 Use case drevet analyse og design 20.01.2004 Kirsten Ribu 1 I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 2 Domenemodell visualisering
DetaljerOptimalJ-kurs UIO Oppsummering av kurset. De ulike modellene egenskaper og formål
OptimalJ-kurs UIO 2004 Agenda Time 1: Oppsummering av kurset Time 2: De ulike modellene egenskaper og formål Team Development med OptimalJ Domain Patterns Egenutviklede transformasjoner (krever Architect
DetaljerDistributed object architecture
Forelesning IMT2243 6. April 2010 Tema: forts. arkitektur og design av programvare Prosjektstatus Programvarearkitektur Oppsummering fra før påske Distribuerte objektarkitektur MDA - Model Driven Architecture
DetaljerLøsningsforslag til Case. (Analysen)
Løsningsforslag til Case (Analysen) Dette er en skisse til løsning av Case et med bussinformasjonssystemet. Jeg kaller det en skisse fordi det på den ene siden ikke er noe fasitsvar og fordi løsningen
DetaljerAkseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer
Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller
DetaljerUML-Unified Modeling Language. Prosess-oversikt. Use case realisering
Use case realisering Designmodellering 31.01.2005 Kirsten Ribu UML-Unified Modeling Language Use Case diagram Klassediagram Oppførselsdiagrammer Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram
DetaljerSystem Dokumentasjon. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk
System Dokumentasjon Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk System Dokumentsjon 23/04/2018 Systemutvikling og dokumentasjon/ia4412
DetaljerObjektorientering og UML. INF1050: Gjennomgang, uke 06
Objektorientering og UML INF1050: Gjennomgang, uke 06 Kompetansemål Objektorientert design Objektdesign og ansvarstilordning Bruk av UML Fokus på klassediagrammer Designmodeller Designmønstre ( design
DetaljerTom Røise 26.02.2007. IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar 2007. Klassediagrammet. Klasse
IMT2243 Systemutvikling 26. februar 2007 Tema : Domenemodellering og Kravspeken - Repetisjon konseptuelle klassediagram - Eksempler - konseptuelle klassediagram (IHID løsningen og OL-Veiviseren) - Maler
DetaljerLæringsutbyttebeskrivelse, Fredrikstad FagAkademi
Navn på utdanningen Nettverksadministrator med design Navn på emnet Windows klient/skybasert klient programvare Nivå 5,1 Kandidaten har kunnskap om bruk og oppsett av gjeldende Windows operativsystem.
DetaljerUNIVERSITETET I OSLO
Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Prøveeksamen i: INF1050 Eksamensdag: 0. mai, 2011 Tid for eksamen: 00:00 00:00 Oppgavesettet er på 6 sider Vedlegg:
DetaljerInnholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5
1 Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5 FRA LEVERANSE 1 (GRUPPE 2)...5 TILLEGG I FORUTSETNINGER... 5 REVIDERT UTGAVE AV SPESIFIKASJON FRA
DetaljerUKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR
INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige
DetaljerProsjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store. Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson
PROSJEKTGRUPPE 1 MGT SOFTWARE LEVERANSE 4 NY FUNKSJONALITET (ENDELIG) Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson Dato:
DetaljerFra krav til modellering av objekter
INF1050: Systemutvikling 14. februar 2017 Fra krav til modellering av objekter Førstelektor Yngve Lindsjørn INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 1 Temaer i dagens forelesning
DetaljerKravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009
Kravspesifikasjon med UML use case modellering Erik Arisholm 25.02.2009 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet
DetaljerMeeting Reservation System
Meeting Reservation System Oblig1c-1 Gruppe 8 Frode Revheim, Sven-Erik Nilsen, Terese Haug, Rolf Vassdokken Krav Vise møteromsoversikt Vise tilgjengelige rom for en gitt tidsperiode og med tilgjengelig
DetaljerRequirements & Design Document
Requirements & Design Document Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk SRD 03/04/2018 Systemutvikling og dokumentasjon/ia4412
DetaljerUML- Use case drevet analyse og design. Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller
UML- Use case drevet analyse og design Bente Anda 23.09.2004 23.09.04 INF320 I dag Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller 23.09.04 INF320
DetaljerMindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen
If you think education is expensive... try ignorance! MindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen Styrende verdier i MindIT:
DetaljerKapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process
INF 329 Web-teknologier Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process Navn: Bjørnar Pettersen bjornarp.ii.uib.no Daniel Lundekvam daniell.ii.uib.no Presentasjonsdato:
DetaljerKravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,
Kravspesifikasjon Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 12.01.2013 Public 2013 Aker Solutions Page 1 of 7 Table of Contents Forord... 3 Om bakgrunnen... 3 Presentasjon...
DetaljerLeveranse 2. September 27, 2002
Leveranse 2 gruppe 42 Nils-Kristian Liborg (brukergrensesnitt), Bente Brevig (beskrivelser, aktørbeskrivelser, diagram, kvalitetssikring), Tom Olav Bruaas (beskrivelser), Eirik Lied (beskrivelser, diagram,
DetaljerKapittel 13 Advanced Hypertext Implementation. Martin Lie Ole Kristian Heggøy
Kapittel 13 Advanced Hypertext Implementation Martin Lie Ole Kristian Heggøy 08.11.04 Forbedring av arkitektur Problem med alt i ett -løsning: Spredning av forretningslogikk. Avhengighet mellom presentasjonssider
DetaljerEksamen i fag SIF8018 Systemutvikling. Fredag 25. mai 2001 kl
Side av 9 NTNU Norges teknisk-naturvitenskapelige universitet BMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:. juni Eksamen i fag SIF808
DetaljerUse case drevet design med UML
Use case drevet design med UML Bente Anda 26.09.2005 23.09.04 INF3120 1 I dag Domenemodeller System sekvensdiagrammer Operasjonskontrakter GRASP patterns Designmodeller med sekvens- og klassediagram 26.09.05
DetaljerSRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie
SRD GLIS Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie Innholdsfortegnelse 1. Systemoversikt... 2 2. Tekniske krav... 3 2.1. Funksjonskrav og brukergrensesnitt spesifikasjon... 3 2.2. Begrensninger...
DetaljerObligatorisk oppgave 5: Modellering av krav
IN1030 - Systemer, krav og konsekvenser Obligatorisk oppgave 5: Modellering av krav Nøkkelord: UML, klassediagram, sekvensdiagram, tekstlig beskrivelse, prosjektplanlegging, risikoanalyse, aktivitetsdiagram.
DetaljerTeam2 Requirements & Design Document Værsystem
Requirements & Design Document Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk SRD 22/01/2018 Systemutvikling og dokumentasjon/ia4412
DetaljerForprosjektrapport Bacheloroppgave 2017
Forprosjektrapport Bacheloroppgave 2017 Chat Modul for Webnodes Content Management System Gruppe 32 Adam Asskali, Anmer Seif, Sara Khan 20.01.2017 Veileder G. Anthony Giannoumis Innholdsfortegnelse 1.Presentasjon
DetaljerEksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl 0900-1300
Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 27. juni, 2006 Eksamen
DetaljerTom Røise 9. Februar 2010
Forelesning IMT2243 9. Februar 2010 Tema : Kravspesifisering : prosessen og produktet Viewpoint en myk tilnærming Pensum : Kap. 6 og 7 i Sommerville, Kravspesifisering Kravspesifisering = arbeidet med
DetaljerIN& &april&2019. Modellering*av*krav. Yngve&Lindsjørn. IN1030&'>Systemutvikling'>&Modellering&av&krav 1
IN&1030 04.&april&2019 Modellering*av*krav Yngve&Lindsjørn ynglin@ifi.uio.no IN1030&'>Systemutvikling'>&Modellering&av&krav 1 Temaer i$dagens$forelesning Modellering&av&krav UML&diagrammer Use$Case$(Bruksmønster)
DetaljerSoftware Development Plan. Software Development Plan. Forum / Nettverkssamfunn Team 2
Forum / Nettverkssamfunn Team 2 1 Innholdsfortegnelse 1 Introduksjon... 3 2 Team & Organisering... 3 3 Brainstorming, tanker og utførelse... 4 3.1 Bruker Registrering og metoder... 4 3.2 Generering av
DetaljerGruppenavn. Beskrivelse av arkitektur For Navn på systemet. Versjon <1.0>
Gruppenavn Beskrivelse av arkitektur For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning 4 1.1
DetaljerSRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie
SRD GLIS Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie Innholdsfortegnelse 1. Systemoversikt... 2 2. Tekniske krav... 3 2.1. Funksjonskrav og brukergrensesnitt spesifikasjon... 3 2.2. Begrensninger...
DetaljerCORBA Component Model (CCM)
CORBA Component Model (CCM) INF5040 Høst 2005 Erlend Birkedal Jan Erik Johnsen Tore Ottersen Løkkeberg Denne presentasjonen CORBA Svakheter ved CORBA Object Model Komponenter CORBA Component Model Hva
DetaljerINF5120 Oblig gjennomgang
INF5120 Oblig gjennomgang 12.05.2005 COMET og MinMax Replenishment Pilotcase for automatisert ordrehåndtering innen bilindustrien. Integrering av systemer. En gruppe = en aktør Service Oriented Architecture
DetaljerOblig 2. Inf5120. Gruppe 21. Espen Stensund (estensun) Nguyen Tran (nguyent) Hung Huynh (qhhuynh)
Oblig 2 Inf5120 Gruppe 21 Espen Stensund (estensun) Nguyen Tran (nguyent) Hung Huynh (qhhuynh) Innholdsfortegnelse. Innholdsfortegnelse. 2 Buisness Modell. 3 Visjon. 3 Aktører og interesser. 3 Risikoanalyse.
DetaljerInfoRed Publisering. - produktbeskrivelse. TalkPool WebServices Postboks Åneby
InfoRed Publisering - produktbeskrivelse www.talkpool.no TalkPool WebServices Postboks 90 1484 Åneby InfoRed Produktbeskrivelse 2 Sammendrag InfoRed Publisering er produktet for å administrere en hel informasjonstjeneste,
DetaljerMindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen
If you think education is expensive... try ignorance! MindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen Styrende verdier i MindIT:
DetaljerPresentasjon av bachelorprosjekt 2009/2010 for Morten Hegstad og Kim Lilleberg. Prosjektnummer 2E
Presentasjon av bachelorprosjekt 2009/2010 for Morten Hegstad og Kim Lilleberg Prosjektnummer 2E 1. Innholdsfortegnelse 1. Innholdsfortegnelse 2 2. Norske Hus Boligsystem AS 3 3. Problemstillingen 3 4.
DetaljerBakgrunn. Kurset krever ingen spesielle forkunnskaper om modellering.
Bakgrunn Modellering har lenge vært et kjent begrep innen systemutvikling. På 80-tallet ble metoder som Yourdon/Demarco og Gane&Sarson brukt for å lage dataflyt-diagrammer. Etter hvert ble disse integrert
DetaljerKravspesifikasjon. 14. oktober 2002
Kravspesifikasjon gruppe 42 Nils-Kristian Liborg (brukergrensesnitt), Bente Brevig (beskrivelser, aktørbeskrivelser, diagram, kvalitetssikring), Tom Olav Bruaas (beskrivelser), Eirik Lied (beskrivelser,
DetaljerObligatorisk oppgave 3. INF1050: Gjennomgang, uke 16
Obligatorisk oppgave 3 INF1050: Gjennomgang, uke 16 Pensum for oppgaven Estimering Arkitektur 4+1 view-modellen og lagdeling Arkitektoniske stiler UML-modellering Tilstands- og aktivitetsdiagrammer Testing
DetaljerOppsummering. Thomas Lohne Aanes Thomas Amble
Oppsummering Thomas Lohne Aanes Thomas Amble 14.11.04 Kapittel 2: Data Modell Mål: Data som skal brukes av applikasjonen blir spesifisert på en formell og likevel intuitiv måte. Resultat: Vi får et konseptuelt
DetaljerMARE NOSTRUM. Del 2 Kravspesifikasjon
MARE NOSTRUM Del 2 Forord Kravenes hensikt og utforming Kravene i kravspesifikasjonen utformet slik at de skal imøtekomme oppdragsgivers krav, ønsker og spesifikasjoner på best mulig måte. Hensikten med
DetaljerMer$om$objektorientering$og$UML
INF1030:&25.&april&2019 Mer$om$objektorientering$og$UML Yngve&Lindsjørn ynglin@ifi.uio.no IN1030& >&Systemutvikling6>objektorientert modellering 1 Gjennomgang&i&dagens&forelesning! Tabeller&(arrays)&vs.&objekter!
DetaljerKravspesifikasjon. Forord
Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den
DetaljerStikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client.
Stikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client. Studenter: Magnus Skomsøy Bae, Marius Eggen, Magnus Krane Klasse: 3ING, Systemutvikling Produserer redaksjonelle
DetaljerAP221 Use Case TUL Utarbeid designdokumenter
AP221 Use Case TUL Utarbeid designdokumenter Utarbeid design Tjenesten designes. Dette er en samling av tre use case: Endre designdokument, Lag nytt designdokument, Last opp designdokument. Designet kan
DetaljerIN2000:&Kravhåndtering,&modellering,&design
IN2000:&Kravhåndtering,&modellering,&design 31&januar&2019 Yngve&Lindsjørn ynglin@ifi.uio.no IN2001&'>&Kravhåndtering og modellering 1 Gode&beskrivelser&av&krav er&viktig&for kontrakt&oppdragsgiver& leverandør
DetaljerFra krav til objektdesign
Fra krav til objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer INF1050-ansvar-1 Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Hva skal systemet gjøre? UML: Bruksmønstermodeller
DetaljerFORPROSJEKT KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK
2017 FORPROSJEKT BACHELOROPPGAVE 2017 KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK PRESENTASJON OPPGAVE: Oppgaven er å lage en webapplikasjon som kan hjelpe bachelor
DetaljerSystemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006
Systemutvikling - oppsummering Alexander Nossum alexander@nossum.net blog.eksplisitt.net 22. mai 2006 INNHOLD 2 Innhold 1 Utviklingsprosessmodeller 3 1.1 Fossefall/waterfall................................
DetaljerInnledende Analyse Del 1.2
Innledende Analyse Del 1.2 Arianna Kyriacou 1. juni 2004 Innhold 1 Spesifikk beskrivelse 2 1.1 Hovedmål............................... 2 1.2 Mål (mer konkret).......................... 2 1.3 Krav..................................
DetaljerPrøveeksamen INF1050: Gjennomgang, uke 15
Prøveeksamen 2016 INF1050: Gjennomgang, uke 15 Overblikk Multiple choice Modellering Aktivitetsdiagram Sekvensdiagram Klassediagram Tilstandsdiagram Krav Ikke-funksjonelle krav og målbarhet Smidig metodikk
DetaljerSpesifikasjon av Lag emne. Kursregistrering bruksmønstermodell. Dagens forelesning. Fra krav til objekter
Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objekter Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use Cases) o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer
DetaljerSpesifikasjon av Lag emne. Kursregistrering bruksmønstermodell (ny versjon) Dagens forelesning. Fra krav til objektdesign
Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objektdesign Hva skal systemet gjøre? UML: Bruksmønstermodeller o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer
DetaljerObligatorisk oppgave 2
Obligatorisk oppgave 2 Gruppe 5 larshol,vijayasi,gorano (Lars Holter, Vijayaroopan Sivarajah, Gøran K. Olsen) Aktører og Interesser Employee: Ønsker å registrere timer jobbet på et prosjekt. Vise oversikt
Detaljer1 Kodegenerering fra Tau Suiten
Kodegenerering fra Tau Suiten For å generere Javakode eller en annen form for programmeringskode ut i fra Tau suiten, er det visse ting som må være utført.. En UML modell må eksistere og være korrekt.
DetaljerForskningsmetoder. INF1050: Gjennomgang, uke 13
Forskningsmetoder INF1050: Gjennomgang, uke 13 Kompetansemål Forskningsmetoder Hva? Hvorfor? Empiriske forskningsmetoder Eksperiment Case-studier Etnografi Aksjonsforskning Spørreskjema Systematisk litteraturstudie
DetaljerSentral Policy Basert Autorisasjonsløsning
Sentral Policy Basert løsning Hvordan håndheve et felles regelverk i en fragmentert applikasjonsportefølge. 09/06/2015 Nordea created through a string of mergers Pre-70 300 banks 1970 s 80 banks 1980 s
DetaljerTittel Objektorientert systemutvikling 2
EKSAMENSFORSIDE Fagnr. OBJ208 Tittel Objektorientert systemutvikling 2 Ansvarlig faglærer Viggo Holmstedt Klasse(r) Dato IS/IN 2 11.06.2009 Eksamensoppgaven Ant. sider inkl. består av følgende: forside
DetaljerBeskrivelse av skjermbilder og funksjoner i PayBack SingelUser.
Beskrivelse av skjermbilder og funksjoner i PayBack SingelUser. 00. PayBack startes ved innlogging til Zylin's webserver. Brukernavn og passord er satt opp etter informasjonen fra webformularet. Adressen
DetaljerFrank Sandersen, EVRY 3. April 2014. Avansert integrasjon Saksbehandling med ephorte som arkiv
Frank Sandersen, EVRY 3. April 2014 Avansert integrasjon Saksbehandling med ephorte som arkiv Meg Småbarnspappa EVRY Porsgrunn Automasjonsingeniør Systemutvikler Integrajonsarkitekt Arkivfaglig 2 3 Søker
Detaljer