1. Objektorientert systemutvikling

Størrelse: px
Begynne med side:

Download "1. Objektorientert systemutvikling"

Transkript

1 Tore Berg Hansen Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314D Prosjektrettet systemarbeid 1. Resymé: I denne leksjonen skal vi se på hvordan man kan arbeide når man skal utvikler systemer objektorientert. Innhold 1.1. INNLEDNING KLASSER OG OBJEKTER OBJEKTORIENTERT ANALYSE MODELLER OG ARTEFAKTER I ANALYSEN UNIFIED MODELLING LANGUAGE (UML) Innledning Litt historie Byggeklossene i UML Strukturelle ting Oppførselsting Grupperingsting Merknadsting Forhold BRUKSMØNSTER Bruksmønsterdiagrammet PROBLEMDOMENEMODELLEN SYSTEM SEKVENSDIAGRAM KONTRAKTER ORDBOK OBJEKTORIENTERT DESIGN ET EKSEMPEL REFERANSER... 34

2 1.1. Innledning Når man studerer litteraturen om systemutvikling støter man bort i ordet paradigme. Ordet kommer fra gresk og kan bety forbilde, mønster eller felles grunnsyn blant utøverne av en vitenskap. I systemutviklingens korte historie har det vært flere paradigmer. Det betyr altså at synet på hva som er den beste måten å utvikle systemer på, har endret seg med jamne mellomrom. På 1970-tallet kom det strukturerte paradigme med strukturert analyse og design og dataflytskjemaene. Dette paradigmet er behandlet i tidligere leksjoner. Nå er det det objektorienterte paradigme som er mest populært. I denne leksjonen skal se litt på hva det vil si å utvikle objektorientert. Det objektorienterte paradigmet er fremdeles under utvikling. Det har vært, og er ulike oppfatninger både når det gjelder betydningen av begreper og bruk av konkrete fremgangsmåter (metodikken). Vi skal ta for oss én slik fremgangsmåte med tilhørende modeller, og vi skal se på et visualiseringsspråk som kan brukes for å vise disse modellene. Men det første vi skal gjøre er å avklare noen sentrale begreper Klasser og objekter I objektorientering er klasser og objekter det sentrale begrepet. Objekter er flere ting. Det kan være noe konkret fra den virkelige verden, eller det kan være en variabel i et objektorientert programmeringsspråk. I det siste tilfellet bruker men gjerne begrepet instansvariabel. Det kan være hensiktsmessig å klassifisere ting. Ting som naturlig hører sammen fordi de har de samme egenskaper kan man si tilhører den samme klassen. En bestemt ørn som vi observerer på himmelen er et objekt fra den virkelige verden. Vi kan kalle han Ørnulf. Ørnulf har mange egenskaper felles med andre ørner. Den kan fly og den kan fange bytte, den har et vingespenn osv. Dette karakteriserer altså alle ørner og er en måte å klassifisere ørner på. Vi har laget oss en klasse Ørn. Men disse egenskapene har ørner felles med svært mange fugler. Det kan derfor være hensiktsmessig å klassifisere på en slik måte at vi samler egenskaper og adferd som er felles i en klasse som vi kan kalle Fugl. Men en fugl er igjen et dyr. Det som er felles for alle dyr kan vi samle i en klasse Dyr. Det vi her gjør er å generalisere. På den måten kan vi bygge opp et hierarki av klasser hvor vi samler de mest generelle egenskapene øverst. Dette er helt vanlig å gjøre på mange områder i forskjellige vitenskaper. Prinsippet er ført over i objektorientert systemutvikling. Her er et av poengene å bruke de samme begreper (objektbegrepet) også i analyse, design og programmering. På den måten mener man å redusere gapet mellom problembeskrivelse og realisering i et objektorientert språk ved at man hele tiden arbeider med de samme begreper. Men det er en stor forskjell, og som ofte har ført til misforståelser om hva som menes med objekter og klasser i forskjellige sammenhenger. Et objekt i den virkelige verden er én ting, et objekt i et program er en annen ting. En klasse i den virkelige verden er et konsept, mens en klasse i et objektorientert programmeringsspråk er en abstrakt datatype med arv. En abstakt datatype innkapsler data og operasjoner som kan utføres på disse dataene. Operasjon heter metode i Java eller funksjon i C++, som er to av de mest brukte objektorienterte programmeringsspråk. På samme måte som en heltallsvariabel er en instans av datatypen integer, så er et objekt i et program en instans av en klasse. Man sier at man instansierer klassen. Det som skjer er at det avsettes plass til data og operasjoner i minnet til datamaskinen som programmet skal kjøre på. side 2 av 35

3 Klasser i et objektorientert språk henter gjerne sine navn fra konsepter i den virkelige verden. Vi skal se mer på klassebegrepet, hvordan man finner konsepter i den virkelige verden og overgangen til klasser og objekter som skal programmeres, i senere kapitler Objektorientert analyse I Norsk ordbok (Guttu, 1998) kan man finne denne definisjonen: 1. Undersøkelse som består i at noe sammensatt oppløses i enkelte bestanddeler. 2. Utredning med grunnlag i slik undersøkelse. Eller sagt på en annen måte så er analyse et studium av noe gjennom å undersøke dets deler og sammenhengene mellom dem. Det kan også være resultatet av dette studiet. Innen systemutvikling har analyse tradisjonelt vært forbundet med den første fasen i fossefallsmodellen. Der kalles denne fasen Requirements analysis and definition (Dvs. analyse og definisjon av krav). I neste fase foretar man så design. I praksis følges aldri fossefallsmodellen. Man legger opp til å utvikle iterativt og inkrementelt. Det vil si at man i stedet for å følge sekvens av faser med tette skott imellom, gjentar aktiviteter (itererer) og leverer produktet i deler (inkrementer). Resultatene fra aktivitetene er modeller, dokumenter og produkter (med en fellesbetegnelse kalt artefakter). I objektorientert systemutvikling blir ikke analysen knyttet til en bestemt fase. Men det er noe som gjøres i hele prosjektet. Skillet mellom analyse og design blir også mer flytende. Figuren som følger er hentet fra første utgave av en bok skrevet av Craig Larman (Larman, 2002). Her ser forfatteren overgangen fra analyse til design som gradvis. Hovedvekten i analysen ligger likevel på å finne ut hva man skal lage, mens det i design dreier det seg om hvordan man skal få laget ting på "best mulig måte". Hva som er "best mulig måte" skal vi komme tilbake til. Mer analyseorientert Mer designorientert hva krav undersøkelse av domenet hvordan logisk løsning side 3 av 35

4 Vi vil i denne leksjonen definere analyse som de aktiviteter og resulterende artefakter som er knyttet til det med å finne frem til og dokumentere kravene til systemet som skal lages. Det er vår definisjon og er ikke nødvendigvis den samme som andre legger i begrepet. Derfor er det nødvendig med en slik begrepsavklaring. F.eks så har Jacobson (Jacobson m.fl., 1999), en av hovedmennene bak Unified Process (UP), i sin beskrivelse av UP en disiplin han kaller analyse. Han skriver: In analysis we analyze the requirements as described in requirements capture by refining and structuring them. Hovedresultatet er hva han kaller en analysemodell. Denne modellen er en klassemodell og skal brukes av utviklere til å klarlegge hvordan systemet skal utformes. Andre vil oppfatte dette som en tidlig design. Mange som praktiserer UP hopper over denne modellen. I dette kurset gjør vi det. Booch, en av objektorienteringens guruer og medarbeider av Jacobson, har denne definisjon (Booch, 1994) av analyse: Objektorientert analyse er en metode for analyse som undersøker kravene i form av klasser og objekter som man finner i vokabularet til problemdomenet. Og Rumbaugh, også en kjent guru, skriver i sin klassiske bok (Rumbaugh m.fl. 1991) at i analysen så bygger analytikeren modeller av den virkelige verden for å vise dens viktige egenskaper. Analytikeren må arbeide sammen med brukeren for å forstå problemet fordi utsagn om problemet sjeldent er komplette eller korrekte. Analysemodellen er en konsis, presis abstraksjon av hva det ønskede systemet skal gjøre, ikke hvordan det skal gjøre det. Objektene i modellen skal være konsepter fra applikasjonsdomenet og ikke programvarekonsepter. Forvirret? Det er etter vårt syn ikke så viktig hva aktivitetene betegnes som. Det som er viktig er at man legger innsats i å finne og dokumentere krav, både funksjonelle og ikkefunksjonelle. Dette krever igjen en grundig forståelse av problemområdet, brukerne og den terminologi som brukes. Derfor skal vi både se på modellering av kravene til systemet, så vel som på modeller for å belyse og forstå det problemområdet systemet skal brukes i. Arbeidet med dette har størst vekt tidlig i utviklingsprosjektet. Og vi understreker at aktivitetene ikke er knyttet til en bestemt fase, som i fossefallsmodellen, men pågår hele tiden. side 4 av 35

5 1.4. Modeller og artefakter i analysen I det vi betegner som analysen er følgende modeller og artefakter de sentrale: Bruksmønster (Engelsk use case, beskriver funksjonelle krav) Ikke-funksjonelle krav Problemdomenemodell (også kalt konseptuel modell) System sekvensdiagrammer Kontrakter Ordbok I tillegg kommer planer, eventuelle prototyper, visjoner og forretningsmuligheter. Disse vil ikke vektlegges i dette kurset ettersom vi her legger hovedvekten på objektorientert analyse og design. Vi skal etter hvert se nærmere på disse modellene. Men før vi gjør det må vi introdusere et visuelt modelleringsspråk som kan brukes til å vise flere av disse modellene i form av diagrammer. Det modelleringsspråket som har størst utbredelse for tiden er Unified Modelling Language (UML) Unified Modelling Language (UML) Innledning Vi har i tidligere leksjoner sett på behovet for og nytten av å modellere. Vi tar et lite sammendrag. Innenfor mange fagområder er det vanlig å lage modeller. Hensiktene kan være flere. Å få prøvet ut ting under kontrollerte betingelser i mindre skala før man setter i gang produksjon. Eksempler er utprøving i vindtunneler av fly og biler. Man sparer penger fordi modellene er billigere å lage enn det endelige produktet. Å ha noe fast å kommunisere rundt for forskjellige interessenter i et prosjekt. I et systemutviklingsprosjekt er det brukere, analytikere, designere, testere, programmerere og eksperter innen forskjellige fagområder. Forskjellige modeller kan brukes til å belyse forskjellige egenskaper ved det tenkte systemet. Det er lettere å føre diskusjoner mellom forskjellige interessenter om egenskapene til et programvareprodukt som er modellert, enn et som bare eksisterer i form av programkode. Når større byområder planlegges lager byplanleggerne modeller som viser hvordan området vil ta seg ut. Slike modeller gir et grunnlag for å fatte beslutninger. Modellene gir bedre forståelse for eventuelle problemer. Å ha et utgangspunkt for en realisering. Snekkere arbeider vanligvis ut fra arbeidstegninger når de setter opp hus. De samme tegningene kan også brukes i en diskusjon mellom arkitekten og de som skal bebo huset. Når barn bygger hytter i trær, trengs ingen arbeidstegning. Men skal det settes opp et bolighus er det helt nødvendig for å komme frem til ønsket utforming. Modeller gir med andre ord bedre design. Modellene side 5 av 35

6 bidrar til å belyse kravene til det ønskede system. Å håndtere kompleksitet. Gjennom modeller kan man abstrahere bort detaljer og betrakte problemer på et nivå hvor det er mulig å holde oversikten. Vi har også behov for modeller som beskriver hvordan vi kan organisere arbeidet for å oppnå gode resultater. Slike modeller kan vi gjerne si er oppskrifter som skal følges og vi kaller dem prosessmodeller. Et prosjekt er en type prosess. En prosjektmodell forteller hvilke aktiviteter som skal utføres, hvordan aktivitetene kan grupperes og deles inn i faser og rekkefølgen av fasene. Et systemutviklingsprosjekt er en prosess og kan organiseres etter forskjellige modeller. Vi oppsummerer: Vi lager modeller slik at vi bedre kan forstå de systemene vi vil utvikle og vi følger modeller for å kunne håndtere arbeidsoppgaver på en hensiktsmessig måte. Gjennom utviklingsprosessen lager vi forskjellige modeller. Modeller er sentrale produkter gjennom hele utviklingsprosessen. UML (Booch m.fl., 1998) er et modelleringsspråk The Unified Modelling Language. Eller litt mer pragmatisk sagt det er det settet med byggeklosser som gir oss muligheten for å modellere alle viktige sider ved et programvaresystem. Det er et modelleringsspråk fordi det gir oss et vokabular i form av symboler og et sett med regler for hvordan disse symbolene kan brukes for å vise konsepter og den fysiske representasjon av systemet. Vi bruker UML til fire ting. Vi bruker det til å visualisere, spesifisere, konstruere og dokumentere programvaresystemer. UML er et utgangspunkt for å realisere systemer fordi modellene direkte kan avbildes i programmeringsspråk som Java og C++. Under utvikling av programvare fremstilles en rekke produkter (også kalt artefakter) både dokumenter og eksekverbar kode: - Krav - Arkitektur - Kildekode - Prosjektplaner - Tester - Prototyper - Frislipp UML bidrar til å gjøre disse produkter mer forståelige Litt historie Objektorientering er relativt ungt. Mange personer har bidratt med metoder og tilhørende modeller. Blant disse mange er de som er blitt kjent som de tre amigos, nemlig Grady Booch, James Rumbaugh og Ivar Jacobson. UML er resultatet av at disse tre har samordnet (unified) sine metoder og notasjoner i et felles språk. Grady Booch var sterk på design og er kjent for å ha utviklet et rikt modelleringsspråk. James Rumbaugh står bak OMT (Object Modeling Technique) som var sterk på analyse. Ivar Jacobson er kanskje mest kjent for sine Use Case og OOSE som legger sterk vekt på å modellere oppførsel (funksjonalitet). side 6 av 35

7 Byggeklossene i UML Generelt kan man si at et språk består av et sett med symboler som utgjør ordforrådet og regler for hvordan disse symbolene skal settes sammen og tolkes for å gi mening. Slik er det med naturlige språk, og man gjør de samme betraktninger når det gjelder formelle språk. Eksempler på formelle språk er programmeringsspråk. Og altså språk brukt til visuell modellering. Språk analyseres gjerne på tre nivåer: 1. Det leksikalske nivå hvor man ser på ordene som språket består av og hva som er lovlige ord. 2. Det syntaktiske nivå hvor man ser på reglene for hvordan ord kan settes sammen til setninger. 3. Det semantiske nivå hvor man ser på hvilken mening setninger har. Av og til legger man inn ett ekstra nivå mellom det syntaktiske og det semantiske nivå hvor man er interessert i å se på hva som er tillatte setninger i gitte sammenhenger. Dette nivået kalles gjerne det kontekstuelle nivå. I sin brukermanual (Booch m.fl., 1998) lanserer de tre amigos tre typer byggeklosser som utgjør ordforrådet i UML. Disse er: - Ting (Things) - Forhold (Relationships) - Diagrammer (Diagrams) Ting består igjen av: - Strukturelle ting - Oppførselsting - Grupperingsting - Merknadsting Av forhold er det fire typer: - Avhengighet - Assosiasjon - Generalisering - Realisering Det er ni fundamentale diagrammer: - Klassediagram - Objektdiagram - Bruksmønsterdiagram - Sekvensdiagram - Samarbeidsdiagram side 7 av 35

8 - Tilstandsdiagram - Aktivitetsdiagram - Komponentdiagram - Deploymentdiagram Ting og forhold dreier seg om hvilke symboler som brukes i UML. Samtidig uttrykker de sammenhengene (konseptene) som vi vil få frem i modellene. Diagrammene er grafisk visualisering av de forskjellige konsepter. Vi skal i det etterfølgende se litt nærmere på disse begrepene Strukturelle ting UML er altså et modelleringsspråk. De strukturelle tingene er substantivene i språket. De utgjør de statiske delene i modellene og kan være både konseptuelle, dvs logiske, og fysiske ting. De strukturelle tingene er klasser, grensesnitt, samarbeidsforhold, bruksmønster, aktive klasser, komponenter og noder. Alle disse er representert med grafiske symboler i UML. dreier seg om klasser og objekter. Klasser og instanser av klasser (objekter) og deres samarbeidsmønstre utgjør den statiske strukturen i programvaresystemet. Derfor vil man alltid lage klassediagrammer for systemet. Et grensesnitt beskriver en ekstern tjeneste som en klasse eller en samling klasser skal tilby. Grensesnitt er spesielt relevant i moderne distribuerte systemer. Disse bygges opp av distribuerte komponenter som kan være på et hvilket som helst sted i et nettverk. Komponentene gjør seg tilgjengelig gjennom et definert grensesnitt som publiseres i nettet ved hjelp av en broker som f.eks CORBA. Et samarbeidsforhold er en samling klasser, grensesnitt og andre elementer som arbeider sammen. De tilbyr funksjonalitet som er større enn summen av funksjonaliteten til enkeltelementene. Bruksmønster er et sentralt begrep hentet fra Jacobsons (Jacobson m.fl., 1992) utviklingsmetode og tatt med i UML. Kort kan vi si at et bruksmønster er et samspill mellom en ekstern bruker og det programvaresystemet som skal utvikles. I denne sammenheng kalles brukeren en aktør. En aktør behøver ikke være et menneske, men kan også være andre systemer som skal samspille med programvaresystemet. En aktør representerer en rolle som spilles i forhold til systemet. Gjennom et bruksmønmster ser vi programvaresystemet utenfra. Gjennom et bruksmønster blir en aktør tilbudt noe av nytte fra systemet. Settet med alle bruksmønstre er den totale funksjonalitet som systemet tilbyr sine brukere. Aktive klasser har instanser som eier en eller flere prosesser eller eksekverbare tråder. Det betyr at de kan kontrollere utførelsen av et program eller deler av et program. De kan også være samtidige. En komponent er en fysisk del av et programvaresystem. En komponent kan være en eksekverbar del av systemet. En komponent representerer typisk den fysiske pakkingen av elementer som ellers er logisk relaterte. En node er en maskinressurs. Et program eller deler av et program eksekverer på noder. Dvs. at en node vil huse en eller flere komponenter. side 8 av 35

9 Oppførselsting Oppførsel uttrykker dynamikken i tid og rom i et programvaresystem. Prinsippielt er det to typer oppførsel. Man bruker begrepet interaksjon når flere objekter samarbeider gjennom utveksling av meldinger seg imellom for å oppnå et resultat. For at meldinger skal kunne sendes fra et objekt til et annet må det være en lenke (forbindelse) mellom objektene. Objekter vil i løpet av sin levetid kunne være i forskjellige tilstander. Dette kan modelleres som tilstandsmaskiner Grupperingsting I større systemer vil det alltid være behov for å kunne gruppere deler av systemet for å få bedre oversikt. Den primære grupperingstingen er pakke. En pakke samler flere strukturelle og oppførselsting som er tett koblet. En pakke kan igjen bestå av flere pakker Merknadsting Dette er forklaringer. Det er gjerne tekstlige forklaringer og anmerkninger som kan være nødvendige for å øke forståelsen av en modell eller spesielle deler av en modell. Nedenfor er en oversikt over de symboler som brukes. Strukturelle ting i UML Tilhørende symbol i UML klasse grensesnitt (interface) samarbeid bruksmønster aktiv klasse side 9 av 35

10 Strukturelle ting i UML Tilhørende symbol i UML komponent node oppførsel melding gruppering tilstand merknad Forhold Jeg har tillatt meg å oversette det engelske relationship med forhold. Dette har jeg gjort for å skille det fra begrepet relasjon (eng relation) som er et matematisk begrep. En annen ting er at et forhold kan være en relasjon i matematisk forstand. I UML kan man modellere fire typer av forhold: - Avhengighet - Assosiasjon - Generalisering - Realisering Et avhengighetsforhold har vi når en klasse bruker en annen klasse. Vanligvis kommer det til uttrykk ved at en klasse er parameter i en operasjon til en annen klasse. En assosiasjon er et forhold hvor det eksisterer en forbindelse mellom objekter. Dette kan sammenlignes med E-R modeller for relasjonsdatabaser. Forskjellen ligger i at en entitet i en E-R modell bare innkapsler data, mens objekter innkapsler både data og oppførsel. side 10 av 35

11 Generalisering er det samme som arv. Et generaliseringsforhold kommer til uttrykk gjennom et spesialiserings/generaliserings-hierarki. De spesialiserte elementer er subtyper av generelle typer som blir en supertype. Realisering har vi når en klasse oppfyller en kontrakt, f.eks spesifisert i et grensesnitt (interface). Ting og forhold utgjør det leksikalske nivå i UML fordi det dreier seg om symbolene som brukes for å bygge opp modellene. På det syntaktiske, kontekstuelle og semantiske nivå befinner modellene seg. Her dreier det seg om hva som er vel formulerte modeller. Dvs regler for å kombinere modeller og hvordan modellene skal tolkes Bruksmønster Bruksmønster står sentralt i objektorientert systemutvikling selv om det ikke er noe spesielt objektorientert med begrepet. Ivar Jacobson er trolig den som introduserte bruk av bruksmønster i objektorientert systemutvikling. Det gjorde han i sin banebrytende bok om objektorientert systemutvikling (Jacobson m.fl., 1992). Andre teoretikere og praktikere, delvis i samarbeid med Jacobsen, har videreutviklet og systemematisert bruk av bruksmønstre. I den kjente utviklingsprosessen Unified Process, er bruksmønstre det som driver utviklingsprosessen. Jacobsen brukte beuksmønstre i tillegg til tradisjonelle spesifikasjonsmetoder for bedre å forstå kravene til systemet som skal utvikles. I UP er samlingen av bruksmønster de funksjonelle kravene til systemet. Ikke-funksjonelle krav som naturlig kan knyttes til et bruksmønster spesifiseres sammen med bruksmønster en. Hvis det ikke er naturlig spresifiseres de i et eget dokument. I UP kalles dette dokumentet Suplementary Specification. Et bruksmønster er en beskrivelse av et ganske omfattende og komplett samspill mellom brukere (aktører) av systemet og systemet. Bruksmønstre er historier (på engelsk stories). Gjennom å fortelle historier om hvordan systemet skal samspille med brukerne får man en bedre forståelse av hva som kreves av systemet. Historien kan være knapp, den kan bestå av noen få setninger eller være omfattende med mange alternativer. Tradisjonelt har kravspesifikasjoner inneholdt lister med detaljerte krav på formen: Systemet skal. Gjennom å fortelle historier i form av bruksmønstre ser man ikke på enkeltegenskaper, men på samspill. Det øker forståelsen og bedrer kommunikasjonen mellom brukere og utviklere fordi det klarere kommer frem hvilken verdi systemet skal gi brukeren. Samspillet beskrives altså i form av en historie som detaljerer flyten av hendelser mellom brukere og systemet. Hos enkelte forfattere finner man begrepet scenario brukt om den detaljerte flyten av hendelser. Noen bruker dette begrepet om instanser av bruksmønstre. Med det mener de at i en konkret situasjon har et buksmønster et helt bestemt forløp og et konkret sett med data. Man trekker parallellen til klasser og objekter (instanser). Man kan si at en klasse er en beskrivelse av hva objekter kan gjøre, mens man kan ha mange objekter som gjør de samme tingene, men med forskjellige data (verdier på attributtene). side 11 av 35

12 I enkelte bøker kan man finne at det skilles mellom hva man kaller essensielle bruksmønstre og reelle bruksmønster. Et essensielt bruksmønster er et hendelsesforløp som utrykkes på en ideell form. Det vil si at den er mer eller mindre fri for implementasjonsdetaljer. Spesielt gjelder det detaljer knyttet til brukergrensesnittet. Reelle (eller konkrete) bruksmønster er hendelsesforløp beskrevet i detaljerte implementasjonstermer. Hvis det inngår brukergrensesnitt vises disse med detaljert plassering av kontroller og felter. Her er to eksempler fra samspillet med en minibankterminal. Essensiell: Kunden identifiserer seg. Kunden presenteres for forskjellige valgmuligheter osv Reell: Kunden setter inn sitt kort. Systemet ber om PIN kode. Kunden taster inn koden. Systemet viser en meny med valgmuligheter osv Det er med andre ord også her mulighet for begrepsforvirring. Scenario er for mange det samme som reelt bruksmønster. Larman bruker begrepet scenario om historien som fortelles. Det vil si at et scenario kan være både essensielt og reelt (konkret). Men det vi skal legge vekt på er at bruksmønstermodellering er historiefortelling. Det er ikke å tegne diagrammer. Diagrammer er nyttige for visualisering og kommunikasjon. Men historien som detaljerer flyten av hendelser er det essensielle. Mens historiene i Jacobsons bruksmønster var ustrukturerte legges det nå vekt på at bruksmønster skal fortelles i strukturert format. Det er flere måter å gjøre dette på. I (Larman, 2002) finner man den mest omfattende måten. I (Quantrani, 2000) finner vi et noe enklere oppsett. Det har denne formen: side 12 av 35

13 X. Hendelsesforløpet for bruksmønster <navn> X.1 PREBETINGELSE X.2 Hovedløp X.3 Sideløp (hvis det finnes) X.4 Alternative løp X er et tall som identifiserer et scenario. Vi bruker et eksemplet fra et program som skal beregne areal og omkrets for geometriske figurene for å vise hvordan historien i et bruksmønster kan skrives etter denne malen. Bruksmønsteret har vi kalt BeregningAvArealOgOmkrets og aktøren Figurberegner. 1. Hendelsesforløpet for bruksmønster BeregningAvArealOgOmkrets 1.1. Prebetingelse. Ingen (dvs at det ikke er noen annen bruksmønster som må være utført før denne kan starte) Hovedløp. Dette bruksmønster starter med at det kommer opp et skjermbilde som viser en sirkel, et rektangel og et triangel. FigurBeregner har nå mulighet for å få utført beregning av areal og omkrets for slike figurer. FigurBeregner klikker på en av figurene. Hvis figuren er en sirkel, utføres S-1: BeregnSirkel. Hvis figuren er et rektangel, utføres S-2: BeregnRektangel. Hvis figuren er et triangel, utføres S-3: BeregnTriangel. FigurBeregner kan også klikke på ikonet for å avslutte. Da avsluttes bruksmønster en Sideløp S-1: BeregnSirkel. Programmet viser en dialog med et felt for innsetting av radius. FigurBeregner setter inn en radius og klikker på en knapp merket Beregn (A-1). S-4 utføres. S-2: BeregnRektangel. Programmet viser en dialog med et felt for innsetting av høyde og bredde. FigurBeregner setter inn høyde og bredde og klikker på en knapp merket Beregn (A-1). S-4 utføres. S-3: BeregnTriangel. Programmet viser en dialog med et felt for innsetting av triangelets tre sider. FigurBeregner setter inn de tre sider og klikker på en knapp merket Beregn (A-1). S-4 utføres. S-4: VisResultat. Programmet beregner areal og omkrets. En dialog som viser resultatet spretter frem. FigurBeregner klikker på en knapp merket OK og programmet viser skjermbildet med figurene igjen. FigurBeregner kan nå få utført nye beregninger eller avslutte programmet Alternative løp. A-1: Ugyldig verdi. Denne bruksmønster starter når en ugyldig verdi for et datafelt er satt inn. En dialog spretter frem med forklaring av problemet og FigurBeregner får mulighet til å sette inn en ny verdi. Den enkelte står fritt til å velge den formen som man mener er best. Det er en smakssak. side 13 av 35

14 En bruksmønster kan være mer eller mindre detaljert avhengig av hvor langt man er kommet med det: Høynivå (brief) En kortfattet beskrivelse av hendelsesforløpet. Bruksmønster identifiseres med navn og historien består av noen få linjer. Kausal (causal) En fri tekst historie som kan bestå av flere avsnitt som dekker flere scenarier. Fullstendig (fully dressed) Den mest omfattende og strukturerte form. Hvordan finne bruksmønster Etter hvert som bruksmønster har økt i popularitet, har også metodene for å finne dem endret seg. Toneangivende eksperter på skriving av bruksmønstre som Cockburn (Cockburn, 2001), legger han vekt på å identifisere mål hver enkelt aktør har med systemet, dvs hva aktøren ønsker å oppnå av verdi fra systemet. Definer så bruksmønster for hvert av målene. Dette er et skifte fra tidligere oppfatninger om at man oppdager bruksmønster mer eller mindre direkte, til å fokusere på måloppnåelse og deretter finne bruksmønster som viser hvordan målene oppnås i samspill med systemet. Det å finne og definere bruksmønster er ingen enkel oppgave. Vi tror derfor at man godt kan kjenne til og bruke flere måter. Selve arbeidet kan gjøres i idédugnader. I (Larman, 2002) finner man også retningslinjer for hva som er et bruksmønster. Nybegynnere har en tendens til å la enkelttrinn bli bruksmønster. Spesielt gjelder det folk som er vant til å tenke informasjonsflyt. Men bruksmønster er ikke flyt av informasjon. Det er historier som forteller samspillet mellom bruker og system. Legg disse fortellingene på et relativt høyt nivå. Som Larman skriver: I forbindelse med analyse av krav til datamaskinapplikasjoner, legger man bruksmønster på nivået for elementære forretningsprosesser. En elementær forretningsprosess er definert som: En oppgave som utføres av en person på ett sted til en gitt tid, som svar på en hendelse i virksomheten. Oppgaven skal resultere i noe som har målbar verdi for virksomheten. Data skal deretter være i en konsistent tilstand. Mer konkret foreslår Larman denne fremgangsmåten: 1. Fastsett grensene for systemet. 2. Identifiser primære aktører. Der er de som har mål de ønsker å nå gjennom de tjenester systemet må tilby. side 14 av 35

15 3. For hver primæraktør identifiseres målene. Legg målene på et nivå som svarer til definisjonene for en elementær forretningsprosess. 4. Definer bruksmønster som tilfredsstiller disse målene. Gi bruksmønster ene navn som samsvarer med målene. Larman skiller altså mellom flere typer av aktører. Disse er: Primære aktører. Det er de som når mål gjennom bruk av systemet. Støtteaktører. Det er slike som tilbyr tjenester til systemet. Utenforstående aktør. Det er slike som har interesse av systemet uten å være direkte involvert i samspillet med systemet. Aktører kan være både mennesker og andre systemer. Primære aktører er gjerne mennesker, mens støtteaktører oftest er andre systemer. Utenforstående aktører kan være etater eller institusjoner. Gjennom å finne slike sikrer man at alle krav til systemet blir identifisert og tatt vare på. Etter at bruksmønster er identifisert skal de rangeres. Det innebærer å finne ut hvilke bruksmønster som skal realiseres i hvilke iterasjoner i utviklingsprosessen. Her er noen kriterier for rangering av bruksmønster. Det vil si hvilke man skal ta sikte på å realisere i de tidlige inkrement: bruksmønster som har vesentlig innvirkning på utformingen av systemarkitekturen bruksmønster som gir mye informasjon og innsikt uten for store anstrengelser bruksmønster som det knytter seg risiko til eller som er tidskritiske eller har kompleks funksjonalitet bruksmønster som krever ny og risikabel teknologi bruksmønster som fører til økte inntekter eller reduserte kostnader Og glem ikke oppstarts bruksmønster en. Alle systemer har en slik. Den må gjennomløpes før andre bruksmønster kan utføres Bruksmønsterdiagrammet Som understreket tidligere er hovedoppgaven med bruksmønster modellering å fortelle historier. Men i visse sammenhenger kan bilder si mer enn ord. UML, som vi skal se nærmere på, gir oss bruksmønsterdiagrammer som et egnet redskap for det formålet. Det er vanlig for nybegynnere å se på bruksmønsterdiagrammet som et av målene i analysen. Men som poengtert foran så er hovedoppgaven å skrive fortellinger. På den annen side så vil et diagram på en kortfattet måte kommunisere hvilke aktører og bruksmønster som er funnet Problemdomenemodellen Den neste modellen man skal arbeide med i analysen er problemdomenemodellen. Et annet navn som brukes er den konseptuelle modellen. Det er en klassemodell som skal hjelpe oss til side 15 av 35

Løsningsforslag til Case. (Analysen)

Lø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

Detaljer

Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP

Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

Detaljer

1. Objektorientert systemutvikling

1. Objektorientert systemutvikling Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Objektorientert systemutvikling Tore Berg Hansen 25.10.2005 Lærestoffet er utviklet for faget LO314D Prosjektrettet systemarbeid 1. Objektorientert

Detaljer

1. Modellering av objektorienterte systemer

1. Modellering av objektorienterte systemer Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Modellering av objektorienterte systemer Tore Berg Hansen Lærestoffet er utviklet for faget IFUD Objektorientert systemutvikling 1. Modellering

Detaljer

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

Detaljer

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

I 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

Detaljer

1. Modellering av objektorienterte systemer

1. Modellering av objektorienterte systemer Tore Berg Hansen 3.2.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LV339D Objektorientert systemutvikling 1. Resymé: I denne leksjonen skal vi se på hva som genererelt

Detaljer

UML 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 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

Detaljer

God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu 17.03.04

God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu 17.03.04 Mer om UML God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu 17.03.04 1 I dag Litt repetisjon GRASP mønstre og OO design Prosjektoppgaven:

Detaljer

UML-Unified Modeling Language. Prosess-oversikt. Use case realisering

UML-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

Detaljer

UKE 11 UML modellering og use case. Gruppetime INF1055

UKE 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

Detaljer

UML-Unified Modeling Language

UML-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

Detaljer

Use Case-modellering. INF1050: Gjennomgang, uke 04

Use 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

Detaljer

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

Gruppenavn. 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

Detaljer

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

UML- 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

Detaljer

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker

Detaljer

det offentlige kartgrunnlaget (DOK)

det offentlige kartgrunnlaget (DOK) geografiske data som er tilrettelagt for plan- og byggesaksarbeid = det offentlige kartgrunnlaget (DOK) Terje Nuland, geodataavdelingen Det offentlige kartgrunnlaget ØK FKB DOK Lover forskrifter veiledning

Detaljer

Use 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. 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,

Detaljer

Kap3: Klassemodellering

Kap3: Klassemodellering Kap3: Klassemodellering I dag: Litt repetisjon fra sist (innledende om klassemodellen) Deretter egentlig litt mer repetisjon, men nå fra intro- Felt-/Instansvariabler og kurset i Java: Klasser og Objekt,

Detaljer

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

Use 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

Detaljer

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

GJENNOMGANG 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

Detaljer

Use case drevet design med UML

Use 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

Detaljer

Fra krav til objekter. INF1050: Gjennomgang, uke 05

Fra 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

Detaljer

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

UKE 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

Detaljer

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

Gruppenavn. 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

Detaljer

GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING HELGA NYRUD & KRISTIN BRÆNDEN

GJENNOMGANG 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

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET 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:

Detaljer

Universitetet i Oslo Institutt for informatikk. Eskild Busch. UML hefte

Universitetet 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,

Detaljer

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn

Modellering 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

Detaljer

Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5

Innholdsfortegnelse 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

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 31. Mai, 2011 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 6 sider Vedlegg:

Detaljer

Spesifikasjon av Lag emne

Spesifikasjon 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

Detaljer

Inception Elaboration Construction Transition Bemanning 1 1,5 2 2 Varighet i uker Antall iterasjoner (lengde i uker i parentes) Tabell 1

Inception Elaboration Construction Transition Bemanning 1 1,5 2 2 Varighet i uker Antall iterasjoner (lengde i uker i parentes) Tabell 1 Innhold Innledning... 2 Faseplan... 2 Iterasjonsplanlegging... 3 Oppstartsfasen... 3 Artefaktene i oppstartsfasen... 4 Utdypingsfasen... 5 Konstruksjonsfasen... 5 Overføringsfasen... 6 Litteratur... 7

Detaljer

Gruppenavn. Prosjektnavn Kravdokument For Navn på systemet. Versjon <1.0>

Gruppenavn. Prosjektnavn Kravdokument For Navn på systemet. Versjon <1.0> Gruppenavn Prosjektnavn Kravdokument For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning 4 1.1

Detaljer

Objektorientering og UML. INF1050: Gjennomgang, uke 06

Objektorientering 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

Detaljer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Ansvarsdrevet 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

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET 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:

Detaljer

INF1050 Systemutvikling

INF1050 Systemutvikling INF1050 Systemutvikling Krav til innlevering: Innleveringene skal ha: Forside med gruppenummer, dato, leveransenummer, navn på gruppemedlemmer med brukernavn og navn på prosjektet Forklarende overskrifter

Detaljer

Fra krav til objektdesign

Fra 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

Detaljer

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn

Modellering 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

Detaljer

Spesifikasjon av Lag emne. Kursregistrering bruksmønstermodell. Dagens forelesning. Fra krav til objekter

Spesifikasjon 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

Detaljer

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

Spesifikasjon 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

Detaljer

Modellering 1. Modellering

Modellering 1. Modellering Tore Berg Hansen 25.8.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget SO328D Programutviklingsmetoder 1. Resymé: I dette notatet skal vi se på hva som genererelt ligger

Detaljer

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 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

Detaljer

INF1050 Systemutvikling

INF1050 Systemutvikling INF1050 Systemutvikling Prosjektoppgave V2004 Innledning Formålet med kurset er å bli i stand til å delta i utviklingen av informasjonssystemer. Dette inkluderer å kjenne til bruken av informasjonssystemer

Detaljer

Fra krav til modellering av objekter

Fra 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

Detaljer

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009

Kravspesifikasjon 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

Detaljer

Installere JBuilder Foundation i Windows XP

Installere JBuilder Foundation i Windows XP Installere JBuilder Foundation i Windows XP Installasjon av JBuilder Foundation på Windows (dekker her spesifikt fremgangen ved bruk av Microsoft Windows XP Professional, men det vil mest trolig ikke være

Detaljer

Prosjektrettet systemarbeid

Prosjektrettet systemarbeid Prosjektrettet systemarbeid Funksjonsmodellering Faglærer: Kjell Toft Hansen Funksjonsmodellering Fra prosjektets brukerkravdokument: Kap. 3.1 Krav til funksjoner Kravene til funksjoner beskriver hva bruker

Detaljer

Installere JBuilder Foundation i Mandrake Linux 10.0

Installere JBuilder Foundation i Mandrake Linux 10.0 Installere JBuilder Foundation i Mandrake Linux 10.0 Installasjon av JBuilder Foundation på Linux (dekker her spesifikt fremgangen ved bruk av Mandrake Linux 10.0, men distribusjon vil gjøre liten eller

Detaljer

Utvikling fra skallet og inn

Utvikling fra skallet og inn Utvikling fra skallet og inn Kravspesifikasjon Brukergrensesnitt! inn ut Erik Arisholm Simula Research Laboratory Utviklingsretning Applikasjon Virkelighetsmodell Bruker Oppfatning av interesseområdet

Detaljer

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen.

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen. Kort innføring i design og programmeringsfasen Jarle Larsen/Tore Berg Hansen 2.11.04 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314 Prosjektrettet systemarbeid Resymé:

Detaljer

Forslag til løsning. Oppgave 1

Forslag 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

Detaljer

Del - leveranse Del 2. Inf 2120 fredag Gruppe 1 Knut Johannes Dahle

Del - 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)

Detaljer

Flere design mønstre. 19. september 2002, Tore Berg Hansen, TISIP

Flere design mønstre. 19. september 2002, Tore Berg Hansen, TISIP Flere design mønstre 19. september 2002, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

Detaljer

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006

Systemutvikling - 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................................

Detaljer

DRI2001 h04 - Forelesning Systemutvikling og nettsteder

DRI2001 h04 - Forelesning Systemutvikling og nettsteder Systemutvikling utvikling av offentlig nettsteder DRI2001 forelesning 20.10 Litt om eksperimentell systemutvikling og prototyping Systemutviklingsprosessene og utvikling av [offentlige] nettsteder Fasene

Detaljer

TDT4110 Informasjonsteknologi, grunnkurs Uke 35 Introduksjon til programmering i Python

TDT4110 Informasjonsteknologi, grunnkurs Uke 35 Introduksjon til programmering i Python TDT4110 Informasjonsteknologi, grunnkurs Uke 35 Introduksjon til programmering i Python Professor Guttorm Sindre Institutt for datateknikk og informasjonsvitenskap Læringsmål og pensum Mål Vite hva et

Detaljer

Model Driven Architecture (MDA) Interpretasjon og kritikk

Model Driven Architecture (MDA) Interpretasjon og kritikk Model Driven Architecture (MDA) Interpretasjon og kritikk Ragnhild Kobro Runde (Ifi, UiO) Veileder: Ketil Stølen (Ifi/SINTEF) Stuntlunsj SINTEF Oversikt Bakgrunn/utgangspunkt for presentasjonen MDA stuntlunsj

Detaljer

GJENNOMGANG UKESOPPGAVER 6 MER OM OBJEKTORIENTERING OG UML

GJENNOMGANG 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:

Detaljer

1. Designe ER-modeller med MS Visio

1. Designe ER-modeller med MS Visio Kjell Toft Hansen 01.07.2009 Opphavsrett: Forfatter og AITeL Lærestoffet er utviklet for faget LO151D Informatikk 1- databaser 1. I dette notatet skal vi se på hvordan vi kan lage ER-modeller ved å bruke

Detaljer

Spesifikasjon av Lag emne. Kursregistrering g bruksmønstermodell. Dagens forelesning. Fra krav til objekter

Spesifikasjon av Lag emne. Kursregistrering g 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

Detaljer

Programvare arkitekturer

Programvare arkitekturer Programvare arkitekturer 14. oktober 2001, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker

Detaljer

SOSI standard - versjon 4.0 1 Del 1: Regler for navning av geografiske elementer. DEL 1: Regler for navning av geografiske elementer

SOSI standard - versjon 4.0 1 Del 1: Regler for navning av geografiske elementer. DEL 1: Regler for navning av geografiske elementer SOSI standard - versjon 4.0 1 DEL 1: Regler for navning av geografiske elementer SOSI standard - versjon 4.0 2 INNHOLDSFORTEGNELSE DEL 1: Regler for navning av geografiske elementer 1 0 Orientering og

Detaljer

AlgDat 12. Forelesning 2. Gunnar Misund

AlgDat 12. Forelesning 2. Gunnar Misund AlgDat 12 Forelesning 2 Forrige forelesning Følg med på hiof.no/algdat, ikke minst beskjedsida! Algdat: Fundamentalt, klassisk, morsomt,...krevende :) Pensum: Forelesningene, oppgavene (pluss deler av

Detaljer

Kapittel 7 & 8. Kravspesifikasjoner & Data design. Thomas Tjøstheim og Thomas Edvinsen. 20 September Kapittel 7 & 8 p.1/20

Kapittel 7 & 8. Kravspesifikasjoner & Data design. Thomas Tjøstheim og Thomas Edvinsen. 20 September Kapittel 7 & 8 p.1/20 Kapittel 7 & 8 p.1/20 Kapittel 7 & 8 Kravspesifikasjoner & Data design Thomas Tjøstheim og Thomas Edvinsen 20 September 2004 Kapittel 7 & 8 p.2/20 Introduksjon Kravspesifikasjoner består av to underdeler:

Detaljer

INF1300 Introduksjon til databaser

INF1300 Introduksjon til databaser INF1300 Introduksjon til databaser Data (transiente, persistente) DBMS databser informasjon interesseområdet informasjonsmodeller informasjonssystemer Transiente og persistente data Når vi programmerer,

Detaljer

Etter uke 9 skal du. Introduksjon til objektorientert programmering. Innhold. Klasser som abstraksjoner

Etter uke 9 skal du. Introduksjon til objektorientert programmering. Innhold. Klasser som abstraksjoner Etter uke 9 skal du Introduksjon til objektorientert programmering INF1001 Høst 2016 Uke 9 Kunne designe og implementere en programstruktur med flere klasser Kunne etablere og manipulere objekter i (sammensatte)

Detaljer

Innhold. Innledning... 15. Del 1 En vei mot målet

Innhold. Innledning... 15. Del 1 En vei mot målet Innledning.............................................. 15 Del 1 En vei mot målet Kapittel 1 Utviklingsarbeidet.............................. 22 1.1 Systemutviklerens arbeid...............................

Detaljer

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse Dagens forelesning Kravspesifikasjon Kravspesifikasjon og objektorientert analyse Hva skal systemet gjøre? Hvem og hva påvirker krav? Motivasjon: Hvorfor trenger vi UML? Noen resultater fra et UML-eksperiment

Detaljer

GJENNOMGANG UKESOPPGAVER 9 TESTING

GJENNOMGANG UKESOPPGAVER 9 TESTING GJENNOMGANG UKESOPPGAVER 9 TESTING INF1050 V16 KRISTIN BRÆNDEN 1 A) Testing viser feil som du oppdager under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.

Detaljer

Mer om objektorientering og UML

Mer om objektorientering og UML INF1050: Systemutvikling 21. februar 2017 Mer om objektorientering og UML Universitetslektor Yngve Lindsjørn INF1050 > Systemutvikling->objektorientert modellering 1 Temaer i dagens forelesning Ø Objektorientert

Detaljer

Kompleksitetsanalyse Helge Hafting 25.1.2005 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO117D Algoritmiske metoder

Kompleksitetsanalyse Helge Hafting 25.1.2005 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO117D Algoritmiske metoder Helge Hafting 25.1.2005 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO117D Algoritmiske metoder Innhold 1 1 1.1 Hva er en algoritme?............................... 1 1.2

Detaljer

Kravspesifikasjon. Kravspesifikasjon. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Hva skal systemet gjøre? Hvem og hva påvirker krav?

Kravspesifikasjon. Kravspesifikasjon. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Hva skal systemet gjøre? Hvem og hva påvirker krav? Kravspesifikasjon Kravspesifikasjon Erik Arisholm Simula Research Laboratory & Institutt for Informatikk Hva skal systemet gjøre? Hvem og hva påvirker krav? Motivasjon: Hvorfor trenger vi UML? o Noen resultater

Detaljer

2. HVA ER EN KOMPONENT?

2. HVA ER EN KOMPONENT? Innholdsfortegnelse 1. INTRODUKSJON 3 2. HVA ER EN KOMPONENT? 3 2.1. Litt av historien 3 2.2. UML og komponenter 5 2.3. Noen definisjoner 5 REFERANSER 7 1. Introduksjon Komponenter og komponentbasert systemutvikling

Detaljer

Tom Røise 26.02.2007. IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar 2007. Klassediagrammet. Klasse

Tom 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

Detaljer

Tittel Objektorientert systemutvikling 2

Tittel 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

Detaljer

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser 1 Ulike typer prosessmodeller Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2004 De røde er viktige i kurset: Evolusjonær (prototyping) Inkrementell (RUP) XP fossefall

Detaljer

EKSAMENSFORSIDE SKRIFTLIG EKSAMEN

EKSAMENSFORSIDE SKRIFTLIG EKSAMEN EKSAMENSFORSIDE SKRIFTLIG EKSAMEN Fag-/kurskode OBJ110 Fag/kurs Objektorientert systemutvikling 1 Ansvarlig faglærer Viggo Holmstedt Ansvarlig fakultet ØS Klasse(r)/gruppe(r) IS2 Dato 13.12.2010 Eksamenstid,

Detaljer

Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram

Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram Fastsatt som forskrift av Utdanningsdirektoratet 3. april 2006 etter delegasjon i brev 26. september 2005 fra Utdannings-

Detaljer

Gjennomgang av prøveeksamen. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

Gjennomgang av prøveeksamen. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Gjennomgang av prøveeksamen Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski OPPGAVE 1: MUlTIPLE CHOICE SPØRSMÅL 1.1 Hva er et funksjonelt krav? a) Teksten på skjermen skal være svart med hvit bakgrunn.

Detaljer

Planlegging og dokumentasjon

Planlegging og dokumentasjon Planlegging og dokumentasjon Edgar Bostrøm. - leilighetsnotat, etterutdanningskonferansen, 17.02.2010, noe revidert. Generelle kommentarer: Begrunnelse for hovedområdet Planlegging og dokumentasjon : o

Detaljer

21. Objektorientert Analyse (OOA) Kap. 21 Objektorientert Analyse (OOA)

21. Objektorientert Analyse (OOA) Kap. 21 Objektorientert Analyse (OOA) 21. Objektorientert Analyse (OOA) Kap. 21 Objektorientert Analyse (OOA) Når vi skal lage en OO analysemodell, bruker vi 5 hovedprinsipper: 1. Lag en modell av informasjonsdomenet. 2. Beskriv modul-funksjonene

Detaljer

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 21. sept. 05 Informasjonssystem og datasystem Hva er systemutvikling (SU) Et enkelt eksempel å bygge et hus Rammer og perspektiver for SU-arbeidet

Detaljer

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO DRI 2001 13.9 : Introduksjon til systemutvikling. Introduksjon til systemutvikling Systemutvikling og nettstedsutvikling Om ulike typer offentlige nettsteder Kvalitetskrav til offentlige nettsteder Litt

Detaljer

1. Relasjonsmodellen. 1.1. Kommentarer til læreboka

1. Relasjonsmodellen. 1.1. Kommentarer til læreboka Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Relasjonsmodellen Tore Mallaug 2.9.2013 Lærestoffet er utviklet for faget Databaser 1. Relasjonsmodellen Resymé: Denne leksjonen gir en kort

Detaljer

Prosjektoppgave: Bildedatabase. TDT4145 Datamodellering og Databasesystemer. Våren 2007

Prosjektoppgave: Bildedatabase. TDT4145 Datamodellering og Databasesystemer. Våren 2007 Prosjektoppgave: Bildedatabase TDT4145 Datamodellering og Databasesystemer Våren 2007 NB! Kun for de som ikke tar fellesprosjektet. Innledning I løpet av de siste årene har det blitt stadig mer vanlig

Detaljer

Prøv å skrive alle svar på alle spørsmål i det tomme rom i disse sidene. Hvis du trenger mer plass, bruk ekstra sider.

Prøv å skrive alle svar på alle spørsmål i det tomme rom i disse sidene. Hvis du trenger mer plass, bruk ekstra sider. 1 For hver del, alle sub deler teller likt. Prøv å skrive alle svar på alle spørsmål i det tomme rom i disse sidene. Hvis du trenger mer plass, bruk ekstra sider. For hvert spørsmål, hvis du trenger å

Detaljer

Introduksjon til objektorientert programmering

Introduksjon til objektorientert programmering Introduksjon til objektorientert programmering Samt litt mer om strenger og variable INF1000, uke6 Ragnhild Kobro Runde Grunnkurs i objektorientert programmering Strategi: Splitt og hersk Metoder kan brukes

Detaljer

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG INF1050 V16 HVA ER EN SYSTEMUTVIKLINGSPROSESS? De aktivitetene som utføres for å utvikle et IT-system Eksempler på aktiviteter:

Detaljer

Oppsummering. Thomas Lohne Aanes Thomas Amble

Oppsummering. 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

Detaljer

King Kong Erfaren Scratch PDF

King Kong Erfaren Scratch PDF King Kong Erfaren Scratch PDF Introduksjon I dette spillet inspirert av historien om King Kong, skal vi se hvor lett det er å bruke grafikk som ikke allerede ligger i Scratchbiblioteket. I spillet styrer

Detaljer

Tom Røise 2/28/2007. IMT2243 : Systemutvikling 1. Forelesning IMT2243 1. mars 2007. Tema : Litteratur : Strukturert analyse. Strukturert analyse

Tom Røise 2/28/2007. IMT2243 : Systemutvikling 1. Forelesning IMT2243 1. mars 2007. Tema : Litteratur : Strukturert analyse. Strukturert analyse Forelesning IMT2243 1. mars 2007 Tema : Litteratur : Art.saml. Punkt 9 : Kap. 9. SASD - modellen, E. Andersen Metoden går ut på å anvende et sett teknikker i arbeidet med å lage gode systemmodeller /beskrivelser

Detaljer

Debugging. Tore Berg Hansen, TISIP

Debugging. Tore Berg Hansen, TISIP Debugging Tore Berg Hansen, TISIP Innhold Innledning... 1 Å kompilere og bygge et program for debugging... 1 Når debugger er i gang... 2 Symbolene i verktøylinjen... 3 Start på nytt... 3 Stopp debugging...

Detaljer

Kravspesifikasjon med. UML diagrammer. systemutvikling. Dokumentasjon av systemets krav, arkitektur, design og implementasjon

Kravspesifikasjon med. UML diagrammer. systemutvikling. Dokumentasjon av systemets krav, arkitektur, design og implementasjon Kravspesifikasjon med UML use case modellering Erik Arisholm 01.03.2010 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet

Detaljer

GJENNOMGANG OBLIGATORISK OPPGAVE 1

GJENNOMGANG OBLIGATORISK OPPGAVE 1 GJENNOMGANG OBLIGATORISK OPPGAVE 1 INF1050 V16 KRISTIN BRÆNDEN 1 Systemet for utleie av markasykler ønsker a benytte seg av en eksisterende betalingsløsning, og valget har falt pa det samme betalingssystemet

Detaljer

1. Hvilke type krav angår sikkerhet og pålitelighet?

1. Hvilke type krav angår sikkerhet og pålitelighet? 1. Hvilke type krav angår sikkerhet og pålitelighet? a) Funksjonelle b) Ikke-funksjonelle Svar: b), IS side 88, lærebok s.96 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan

Detaljer

Kravspesifikasjon med. Erik Arisholm

Kravspesifikasjon med. Erik Arisholm Kravspesifikasjon med UML use case modellering Erik Arisholm 01.03.2010 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet

Detaljer

Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein. 5.

Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein. 5. 2 Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein 5. april 2017 Innhold 1 Klassediagram 2 Sekvensdiagram 2.1 Oppgave 2a 2.2 Oppgave

Detaljer

Datamodellering med UML. Modellenes to formål. The Unified Modeling Language - UML

Datamodellering med UML. Modellenes to formål. The Unified Modeling Language - UML Figur 5-. Datamodellen dokumenterer vår oppfatning av virkeligheten Interesseområdet Datamodellering med UML registrering påvirkning jfr. Systemutvikling fra kjernen og ut, fra skallet og inn kapittel

Detaljer