1. Modellering av objektorienterte systemer

Save this PDF as:
 WORD  PNG  TXT  JPG

Størrelse: px
Begynne med side:

Download "1. Modellering av objektorienterte systemer"

Transkript

1 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 av objektorienterte systemer Resymé: I denne leksjonen skal vi se på hva som genererelt ligger i begrepet modellering. Vi går så over på modellering av objektorienterte systemer og introdusere modelleringsspråket Unified Modelling Language (UML). Innhold 1.1. INNLEDNING HVA ER EN MODELL HVORFOR MODELLERE UML Litt historie BYGGEKLOSSENE I UML Strukturelle ting Oppførselsting Grupperingsting Merknadsting Forhold ET EKSEMPEL Use case modell Domenemodellen Analysemodellen Designmodellen SLUTTKOMMENTAR TIL DENNE LEKSJONEN LESESTOFF TIL DENNE LEKSJONEN REFERANSER... 21

2 Modellering av objektorienterte systemer side 2 av Innledning Dette faget er ikke primært om modellering. Men modellering er etter vår mening sentralt i objektorientert systemutvikling. Derfor har vi denne leksjonen som en introduksjon til modellering og UML. Når man modellerer trenger man et visuelt modelleringsspråk og UML ser ut til å bli det standardspråket de fleste vil bruke Hva er en modell Modell har flere betydninger. I en ordbok leser vi følgende: 1. Representasjon av noe. Vanligvis mindre enn originalen. For eksempel modelljernbane. 2. Noe som lages for å brukes til kopiering i et annet materiale. For eksempel voksmodell av noe som skal støpes. 3. Bestemt type eller design av et produkt. For eksempel bilmodell. 4. Forenklet beskrivelse av et system brukt ved forklaring. For eksempel en økonomisk modell. 5. Noe som man kan arbeide etter. For eksempel en oppskrift. 6. Person eller ting som anses som eksepsjonelle og som det er verdt å etterligne. 7. Person som poserer. For eksempel mannekeng eller akt. 8. Utgaver av klær fra motedesignere. Innenfor vårt fag, systemutvikling, er det 4 og 5 som er aktuelle. Vi har behov for å beskrive forskjellige sider og egenskaper ved programvaresystemer og vi følger utviklingsmodeller når vi utvikler systemene. Også 6 er aktuell i forbindelse med begrepet mønstre (engelsk patterns) som er løsninger som har vist seg å fungere godt i systemer som er utviklet tidligere. Jeg gjorde en gang et søk på Internett i et forsøk på finne noe relevant stoff om modeller og modellering. Jeg fant ikke det jeg håpet å finne. Men en av de tingene jeg fant var dette. Her er det flere typer modeller. Hvilke? 1.3. Hvorfor modellere Innefor 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,

3 Modellering av objektorienterte systemer side 3 av 21 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 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 oppsummerer: Vi lager modeller slik at vi bedre kan forstå de systemene vi vil utvikle. I [1] settes det opp fire grunnprinsipper for modellering: - Vær nøye med hvilke modeller du velger fordi valg av modell har grunnleggende betydning for hvordan man angriper et problem og for hvilken løsning som lages. - Forskjellige modeller gir ulikt detaljeringsnivå. Noen ganger har man behov for å vise et oversiktsbilde, andre ganger er det detaljene man vil konsentrere seg om. En bruker er interessert i å se hvordan systemet vil se ut utenfra, mens en utvikler kan vikle seg inn i detaljer rundt realiseringen av systemet. - De beste modeller er knyttet til virkeligheten. Det gjelder også for programvare. Objektorientert modellering gjør det lettere å oppnå dette. - Det er ikke nok med en enkelt modell. Store systemer vises best gjennom et lite sett med nesten uavhengige modeller. Gjennom utviklingsprosessen lager vi forskjellige modeller. Modeller er sentrale artefakter i de forskjellige disipliner (se leksjonen om utviklingsmodeller). De raffineres i alle faser i livsløpet. Men de forskjellige modeller har ulik betydning i de forskjellige faser. For eksempel arbeider man mer med use case modeller i de to første fasene (av UP) UML UML [1] 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++.

4 Modellering av objektorienterte systemer side 4 av 21 Under utvikling av programvare fremstilles en rekke produkter 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). Videreutviklingen av UML foregår nå i regi av Object Management Group (OMG). Mange personer bidrar til videreutviklingen av UML. I 2005 ble revisjon 2.0 offisielt lansert. Den inneholder en rekke endringer i forhold til tidligere versjoner (1.3, 1.4 og 1.5) 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å.

5 Modellering av objektorienterte systemer side 5 av 21 I sin brukermanual [1] 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 (structural things) - Oppførselsting (behavioral things) - Grupperingsting (grouping things) - Merknadsting (annotation things) Av forhold er det fire typer: - Avhengighet (dependency) - Assosiasjon (association) - Generalisering (generalization) - Realisering (realization) Det er tretten typer diagrammer: - Klassediagram - Objektdiagram - Komponentdiagram - Sammensatt strukturdiagram - Use case diagram - Sekvensdiagram - Kommunikasjonsdiagram (tidligere samarbeidsdiagram) - Tilstandsdiagram - Aktivitetsdiagram - Deploymentdiagram - Pakkediagram - Timingdiagram - Interaksjonsoversiktsdiagram Ting og forhold dreier seg om hvilke symboler som brukes i UML. Samtidig uttrykker de sammenhengene 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.

6 Modellering av objektorienterte systemer side 6 av 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, use case, aktive klasser, komponenter og noder. Alle disse er representert med grafiske symboler i UML. Objektorientert systemutvikling 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. Use case er et sentralt begrep hentet fra Jacobsons [1] utviklingsmetode og tatt med i UML. Kort kan vi si at en use case 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 en use case ser vi programvaresystemet utenfra. Gjennom en use case blir en aktør tilbudt noe av nytte fra systemet. Settet med alle use case 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 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.

7 Modellering av objektorienterte systemer side 7 av 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 noen av de mest brukte symboler. klasse merknad node grensesnitt samarbeid komponent Use case tilstand Aktiv klasse pakke melding avhengighet generalisering realisering Vi kommer tilbake med praktiske eksempler på bruken.

8 Modellering av objektorienterte systemer side 8 av 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. 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) Et eksempel Vi skal her se på et eksempel for å vise noen av de mest brukte modeller og tilhørende diagrammer. For at problemet ikke skal overskygge prinsippene lar vi eksemplet være enkelt. Følgende foreløpige krav til et programvaresystem er identifisert: Det skal lages et system som skal brukes til beregning av areal og omkrets for forskjellige geometriske figurer. Vi begrenser oss til todimensjonale figurer. Når programmet starter skal det komme frem et skjermbilde som viser de typer av figurer som programmet kan utføre beregninger for. Ved å klikke på den aktuelle figuren skal det sprette frem en dialog hvor man kan sette inn nødvendige data for beregningene. Etter at brukeren har klikket på en knapp merket Beregn i dialogen skal programmet gjøre beregningene. Når beregningen er utført skal resultatene vises i et vindu på skjermen. I første omgang skal programmet lages for tre figurer; triangel, rektangel og sirkel. Denne spesifikasjonen er mangelfull. Nye krav vil sannsynligvis bli oppdaget etterhvert som vi modellerer systemet Use case modell Vi følger Rational Unified Process (RUP). Da er vi nå i oppstartsfasen og skal se nærmere på kravene til systemet. Et naturlig startpunkt kan være use case.

9 Modellering av objektorienterte systemer side 9 av 21 Oppstart Detaljering Konstruksjon Overføring Figur 1 Unified Process Jacobson 1 [1] definerer en use case som en rekke av transaksjoner i en dialog med systemet utført av en instans (bruker) av en aktør. En annen definisjon på use case er: Et sett use case instanser. Hver instans er en serie med aksjoner som systemet utfører og som fører til noe som er nyttig for en aktør. En aktør er en representant for hva som samspiller med systemet. Brukeren er den aktuelle personen som bruker systemet. Aktøren representerer en rolle som brukeren kan spille. Man kan si at en aktør er en klasse, mens en bruker er en instans av denne klassen. Alle use case man kan finne for systemet representerer den samlede funksjonalitet for systemet og er det naturlige startpunkt for å finne klasser og objekter som skal tilby denne funksjonaliteten. Med utgangspunkt i use casene lages mange av de andre modellene av systemet. En måte å finne use casene på er å starte med å identifisere aktører og se på hvilken bruk de vil gjøre av systemet. I dette enkle systemet med beregning av areal og omkrets for geometriske figurer er det antagelig bare en aktør, nemlig den som representerer de som er interessert i arealet og omkretsen av geometriske figurer. Hvilket navn skal vi gi denne aktøren? Jeg foreslår FigurBeregner, i mangel av noe bedre. FigurBeregner er en rolle. Forskjellige personer kan gå inn i den rollen avhengig av hvem som bruker systemet. F.eks kan det være en skoleelev, en student eller en arealplanlegger. Det kan for så vidt også være et annet program som har bruk for denne typen beregninger. Hvilken bruk gjør så FigurBeregner seg av systemet? Hvilken funksjonalitet ønskes? I dette tilfellet det vel ganske enkelt å se at det er BeregningAvArealOgOmkrets. Man kunne tenke seg å dele denne i to use case en for beregning av areal og en for beregning av omkrets. Av og til kan det være en smakssak. For store systemer kan man miste oversikten hvis antallet use case blir stort. Det er ikke problemet her. Jeg velger en use case fordi begge beregningene for de fleste figurer kan utføres med basis i de samme dataene. Da har vi identifisert en aktør, FigurBeregner og en use case, BeregningAvArealOgOmkrets. Vi får følgende enkle us case modell som vis i diagrammet i Figur Jacobsen er den som introduserte use case i objektorientert systemutvikling. Derfor er han referert her. I [7], kapittel 6 gis en grundig beskrivelse av use case. Her skjelner forfatteren mellom forskjellige typer av use case. Egentlig er det samme use case, bare på forskjellig detaljeringsnivå, avhengig av hvor langt man er kommet i utviklingsprosessen.

10 Modellering av objektorienterte systemer side 10 av 21 BeregningAvArealOgOmkrets Figur 2 FigurBeregner Symbolet for aktøren er en stilisert person og symbolet for en use case er en ellipse. Legg merke til at navnene som er gitt symbolene er skrevet under. Det er i samsvar med Jacobson [1]. Begrunnelsen er at man på den måten ikke får problemer med å få plass til teksten inne i symbolet. Man kan dermed holde en fast størrelse på symbolene. Ikke alle bruker den praksisen, men legger teksten inne i symbolene. Det er heller ikke alle som trekker sammen navnene på den kompakte formen som jeg har gjort. (Larman [7] legger teksten inne i symbolet). Det neste man nå kan gjøre er å utbrodere use casen tekstlig. Det vil si at man beskriver med ord trinn for trinn det som skjer mellom aktøren og systemet i den gitte use case. Slik jeg tolker Jacobson kaller han også denne teksten for use case, mens andre metodikere skiller mellom use case som abstraksjon og dens innhold. Innholdet kalles hos dem scenario [3], [4] eller script. Use case blir hos dem en slags klasse, mens scenariet eller scriptet kan oppfattes som en instans av denne klassen. I den senere tid etter hvert som bruk av use case har blitt mer utbredt, er formaliserte oppsett av use case blitt introdusert. Larman [7] viser eksempler på det. Men en ting synes alle å være enige om. Det er at use case, uavhengig av form, er nyttig og viktig når man skal forstå oppførselen til det systemet som skal utvikles. I denne introduksjonen følger vi Jacobson. Han tar utgangspunkt i kravspesifikasjonen i en eller annen form. Her følger teksten til use casen:

11 Modellering av objektorienterte systemer side 11 av 21 BeregningAvArealOgOmkrets Programmet starter ved at det kommer opp et skjermbilde som viser en sirkel, et triangel og et rektangel. FigurBeregner klikker på en av figurene. En dialog hvor data kan settes inn spretter frem. Hvis det er en sirkel setter FigurBeregner inn radius, hvis det er rektangel setter FigurBeregner inn bredde og høyde og hvis det er et triangel setter FigurBeregner inn lengden av de tre sidene i tiangelet. FigurBeregner trykker på knappen merket Beregn i dialogen. Programmet vil utføre beregningen av areal og omkrets for den valgte figur. Etter at beregningen er ferdig presenterer programmet resultatet i en dialog. Denne dialogen har en knapp merket OK.FigurBeregner klikker OK og programmet viser skjermbildet med de tre figurene igjen. FigurBeregner kan da få utført nye beregninger. Hvis ikke kan FigurBeregner avslutte programmet. I tilknytning til denne use casen kan det også være hensiktsmessig å lage en prototype som viser brukergrensesnittet.

12 Modellering av objektorienterte systemer side 12 av 21

13 Modellering av objektorienterte systemer side 13 av 21 Dette er en prototype. Det endelige brukergrensesnittet behøver ikke se slik ut. Poenget er å komme frem til enighet om det som skal skje i dialog med brukeren Domenemodellen Use case modellen viser en side ved det systemet som skal utvikles den eksterne funksjonaliteten. Denne modellen skal hjelpe til med å finne frem til hvilket ansvar som skal legges til objekter i programvaren. Men før man arbeider videre med use casene, kan det være nyttig å modellere den virkelige verden knyttet til det problemet som skal løses. Dermed kommer en annen side ved systemet frem. Denne siden vil vise objekter og sammenhenger som er typiske for problemområdet. Disse objektene vil delvis finnes igjen som programvareobjekter i det endelige programmet. Denne modellen av virkeligheten, kalles gjerne problemdomenemodellen [1], [5]. Et annet nav er den konseptuelle modellen [7]. Den vil vises som et klassediagram. I vårt enkle eksempel er det umiddelbart flere kandidatobjekter som dukker opp: - geometrisk figur - sirkel - triangel - rektangel Disse er beslektede. Et første utkast til domenemodell blir derfor et hierarki med geometrisk figur som superklasse og som besitter alle felles egenskaper for alle typer geometriske figurer. GeomtriskFigur Sirkel Rektangel Triangel Figur 3 Figur 3 viser domenemodellen på sitt høyeste abstraksjonsnivå. Klassene er rektangler med navnene skrevet inni rektanglene. I superklassen er navnet skrevet i kursiv. Det forteller at klassen er abstrakt. Det vil si det ikke vil eksistere noen instanser av denne klassen. De konkrete klassene er Sirkel, Rektangel og Triangel. (Egentlig er det bare de konkrete klassene som tilhører problemdomenet. Abstrakte klasser tilhører programvaren). Disse vil det kunne opprettes instanser av i et program. Trekanten som peker mot klassen på toppen i hierarkiet er en diskriminator som forteller at vi har en generalisering/spesialisering, dvs et arvehierarki. Strengt talt har vi gått litt lenger enn å modellere det rene problemdomenet. Dette fordi vi tenderer i retning av programvareklasser ved introduksjon av abstrakte klasser. Men det falt naturlig. Legg merke til at vi er opptatt av konseptene (den virkelige verden) og ikke operasjoner og attributter som tilhører programvareklasser. I problemdomenemodellen er det ellers vanlig å trekke inn noen attributter som er naturlige for å få frem de som er essensielt med et objekt i den virkelige verden. Legg dessuten merke til at problemdomenemodellen er

14 Modellering av objektorienterte systemer side 14 av 21 en klassemodell, mens det man snakker om er objekter (også kalt konsepter) i den virkelige verden 2. UML gjør det mulig å lage modeller hvor vi kan legge inn informasjon etter behov. Forskjellige interessenter kan være interessert i forskjellige detaljer i systemet. Brukere er vanligvis opptatt av oversikten, mens designere og testere trenger detaljert informasjon. Vi kan detaljere modellen med attributter og opersjoner for klassene. Da er vi i ferd med å lage en modell med programvareklasser. I den abstrakte klassen legger vi attributter og operasjoner som er felles for alle klassene i hierarkiet. Alle geometriske figurer har et areal og en omkrets. Hvordan disse beregnes vil være forskjellig. Operasjonene har samme navn, men implementasjonen vil være forskjellig i de ulike subklassene 3. Det er dette som kalles polymorfisme. GeomtriskFigur areal omkrets beregnareal() beregnomkrets() hentarealet() hentomkretsen() Sirkel Rektangel Triangel radius beregnareal() beregnomkrets() settradius(radius) hentradius() høyde bredde beregnareal() beregnomkrets() setthøyde(høyde) settbredde(bredde) henthøyde() hentbredde() sideen sideto sidetre beregnareal() beregnomkrets() settsider(sideen, sideto, sidetre) hentsider() Figur 4 2 I [7] kapittel 1 finner man en introduksjon til begrepene og i kapittel 9 flere detaljer. 3 En operasjon som ikke har noen implementasjon i den abstrakte klassen kalles i C++ for en ren virtuell funksjon, i Java en abstrakt metode.

15 Modellering av objektorienterte systemer side 15 av 21 Figur 4 viser det samme diagrammet, men nå med flere detaljer. Det er lagt inn de attributter og operasjoner som er mest åpenbare. Etter hvert som man arbeider videre mot realisering av klassen kan man legge inn enda flere detaljer. Det skal vi komme tilbake til. Vi skal senere se på mer systematiske måter å komme frem til operasjoner og attributter på. Klasse navn Sirkel attributt:type = initialverdi radius:float = 1 operasjon(arg liste):retur type beregnareal() beregnomkrets() settradius(radius:float) hentradius():float (a) (b) Figur 5 Figur 5 viser hvordan en detaljert spesifikasjon av attributter og operasjoner kan gjøres. Til venstre vises den generelle oppbygning. Til høyre har vi et konkret eksempel Analysemodellen Domenemodellen vil ikke være den modellen som uttrykker designet av programvaresystemet. Det er det designmodellen som skal gjøre. Den vil inneholde de klasser som skal gjøre jobben i programmet. Men før man kommer så langt vil man lage en analysemodell. Dette er en logisk modell som viser hva programmet skal gjøre, mens designmodellen viser konkret hvordan vi vil gjøre det. Analysemodellen er uavhengig av implementasjonsmiljøet. Designmodellen tar hensyn til implementasjonsmiljøet [1]. I objektorientert systemutvikling er grensen mellom analyse og design ganske flytende. Davis [6] skriver om det han kaller what versus how dilemmaet. En persons hvordan er en annen persons hva. Analysemodellen er i stor grad også hvordan fordi det er her man finner klassene og hvordan de skal samspille i programmet. Det betyr at man fastlegger den overordnede arkitekturen og dermed strukturen i programmet. Dette er i høy grad hvordan. På den annen side sier analysemodellen hva programmet skal bestå av ikke hvordan den detaljerte realiseringen skal gjøres. Det overlates til design og implementasjon som til sammen utgjør konstruksjonen av systemet. Da er vi over i konstruksjonsfasen. Tilbake til analysen og analysemodellen. For å utvikle et komplett program er ikke domenemodellen nok. Domenemodellen bygges for at vi skal forstå problemområdet. Det er ikke gitt at noen av klassene i domenemodellen gjenfinnes i det ferdige programmet. Men det er sjeldent. Use case modellen og domenemodellen danner utgangspunktet for analysemodellen. Det vil også være fornuftig å se på eksisterende mønstre for god analyse og design. Vi skal lage et interaktivt program. Et mønster for et slikt program er Model View Controller (MVC) kjent fra SmallTalk. Se Figur 6

16 Modellering av objektorienterte systemer side 16 av 21 Model Controller View Figur 6 Modell representerer dataene og kunnskapen i programmet. View er brukergrensesnittet. Controller binder programmet sammen. Jacobson [1] definerer tre typer av objekter grensesnittobjekt, entitetsobjekt og kontrollobjekt. Han hadde egne symboler for disse. I UML kan man bruke stereotyper for å skille mellom typer av klasser eller objekter. Modell er typisk et eller flere entitetsobjekter. View er et eller flere grensesnittobjekter. Controller er et eller flere kontrollobjekter. En gruppering av klasser som logisk hører sammen og som utgjør en større enhet, modelleres som pakker i UML. En pakke har et eget grafisk symbol. MVC modellen kunne derfor også vært vist som i Figur 7. Model Controller View Figur 7 Pilene representerer assosiasjoner mellom klassene (pakkene). Pilene viser retningen på assosiasjonene. F.eks så ser Controller Model, mens Modell ikke har behov for å kjenne til Controller.

17 Modellering av objektorienterte systemer side 17 av 21 Vi bruker dette mønsteret i vårt program. Da blir analysemodell som i Figur 8 SirkelDialog Beregner View RektDialog TriangDialog GeomFigur RersultatDialog Figur 8 Sirkel Rektangel Triangel Designmodellen Vi er nå etterhvert over i design. En av de første tingene vi gjør i design er å designe use casene. Vi skal se på det detaljerte samspill mellom objektene i programmet. Hjelpemidler er interaksjonsdiagrammer. Det er to typer interaksjonsdiagrammer sekvensdiagrammer og kommunikasjonsdiagrammer. Et sekvensdiagram viser rekkefølgen av hendelser i en use case. Sekvensdiagrammer var sentrale hos Jacobson [1]. Han kaller dem faktisk interaksjonsdiagrammer. Rumbaugh [3] hadde noe lignende som han kalte event trace. Ideene er tatt med i UML under betegnelsen sekvensdiagram.

18 Modellering av objektorienterte systemer side 18 av 21 Start hovedvindu vises while flereberegninger FigurBeregner klikker på fiur Programmet viser dialog FigurBeregner setter inn data FigurBeregner klikker OK Dialog tar vare på data Beregning utføres start klikkfigur() settdata OK :Beregner :GeomFigur :View :Dialog :Resultat visview() hentdata() settdata() beregnareal() beregnomkrets() hentareal() hentomkrets() visdialog() hentdata() hentdata() Resultat vises i dialog FigurBeregner klikker OK endwhile slutt slutt OK visresultat(resultat) visdialog() visresultat() Figur 9 Figur 9 er et eksempel på et sekvensdiagram. En av hensiktene med diagrammet er at det skal være til hjelp når man skal fordele og finne frem til operasjoner for de forskjellige objekter som inngår i en use case. Diagrammer viser også rekkefølgen av operasjonene. Diagrammet kan også brukes til å vurdere godheten av en løsning. La oss se på oppbygningen av diagrammet. Helt til venstre er use casen formulert i pseudokode. Øverst er tegnet inn de objekter som inngår i use casen inkludert aktøren 4. De er i dette tilfelle anonyme objekter fordi bare klassenavnet er angitt. Dialogobjektet representerer alle de dialoger som brukes for å lese inn data for forskjellige figurer. Det er gjort for å lette oversikten. Det gjør det også lettere senere å utvide programmet med flere typer figurer uten at diagrammet må endres. Det betyr at 4 Vi har brukt et annet symbol for aktøren i dette tilfellet. Det er tillatt i UML. Man kan legge inn egne symboler for å gjøre en modell rikere.

19 Modellering av objektorienterte systemer side 19 av 21 operasjonene på dette objektet må betraktes som generiske. Det samme er tilfellet med figurobjektet. De stiplede vertikale linjene er såkalte livslinjer for objektene og representerer en tidsdimensjon uten å angi en tidsskala. De horisontale pilene representerer meldinger som et objekt sender til et annet. Teksten over pilene er de operasjoner som utløses som svar på disse meldingene. Et objekt kan sende melding til seg selv. Et kommunikasjonsdiagram viser den samme informasjon i en annen dimensjon. Figur 10 viser et kommunikasjonssdiagram for eksemplet vårt. Eksemplet er selvforklarende. Det dreier seg om samspill mellom objekter. Piler viser retningen på meldingsutvekslingen. Teksten over pilene er navn på operasjoner. Tallet foran operasjonen angir rekkefølgen. 16:visDialog 17:visResultat :Resultat 2:visView 9:hentData 15:visResultat :View 7:hentData 4:visDialog 8:hentData :Dialog 5:settData 3:klikkFigur 6:OK 18:OK :Beregner 1:start 19:slutt 10:settData 11:beregnAreal 12:beregnOmkrets 13:hentAreal 14:hentOmkrets :Figur Figur Sluttkommentar til denne leksjonen. Vi har i denne leksjonen tatt for oss modeller og nytten av å modellere. Det er gjort et raskt sveip innom noen av de mest sentrale modeller som vi lager i objektorientert systemutvikling. UML som modelleringsspråk er introdusert. Men vi har vært litt overfladiske i beskrivelsen av hvordan vi finner frem til klasser og objekter, hvilke faser vi er i, og hvordan objekter skal spille sammen for å realisere et godt programvaresystem. Poenget med dette faget er å introdusere mer systematiske måter å gjøre dette på. Det vil derfor være tema i senere leksjoner. (Jeg gjør oppmerksom på at på figurene 9 og 10 er ikke symbolene helt i samsvar med UML 2.0 fordi det i skrivende stund ikke har lyktes å finne er verktøy som inneholder den siste notasjonen. Det kan være en liten ekstra øvingsoppgave å finne ut hva forskjellen er.)

20 Modellering av objektorienterte systemer side 20 av Lesestoff til denne leksjonen Læreboken følger i sin presentasjon av stoffet trinnene i Unified Process (UP). Tankegangen er at en aktuell modell introduseres sammen med det tema den naturlig hører til. Derfor har ikke læreboken et eget modelleringskapittel. Men i kapittel 1.6 gis en kort introduksjon til UML og det korte kapittel 1.7 har et godt poeng om visuell modellering. Kapittel 2.7 omtaler det som populært kalles Agile Modelling, eller på norsk Smidig modellering. Opphavsmannen er antagelig Scott W. Ambler [8]. Han er igjen inspirert av the Agile Alliance ( Læreboken skriver kort om denne i kapittel 2.6. Et poeng her er at modeller ikke behøver tegnes med et avansert verktøy, men gjerne kan være håndtegnet på papir eller tavle når det er hensiktsmessig. Og modeller behøver ikke tas vare på for all fremtid, men kastes når de ikke lenger tjener hensikten sin. Jeg må innrømme at jeg er fasinert av den the Agile Alliance og deres tanker som er nedfelt i manifestet og prinsippene som dere kan lese på side 29 i læreboken.

21 Modellering av objektorienterte systemer side 21 av Referanser 1. Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User s Guide, 2.utgave, Addison-Wesley 2005, ISBN Ivar Jacobson med flere, Object-Oriented Software Engineering, A Use Case Driven Approach, Addison-Wesley 1992, ISBN James Rumbaugh med flere, Object-Oriented Modelling and Design, Prentice Hall 1991, ISBN Paul Allen & Stuart Frost, Component-Based Development for Enterprise Systems, Cambridge University Press 1998, ISBN Martin Fowler, UML Destilled, Applying the Standard Object Modelling Language, Addison-Wesley 1997, ISBN Alan M. Davis, Software Requirements, Analysis & Specification, Prentice Hall 1990, ISBN Craig Larman, Applying UML And Patterns, An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3.utgave, Prentice Hall 2005, ISBN Scott W. Ambler, Agile modelleing. Effective practices for extreme programming and the unified process, Wiley 2002, ISBN

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

Modellering av objektorienterte systemer

Modellering av objektorienterte systemer Modellering av objektorienterte systemer 16. august 2002, Tore Berg Hansen, Tisip Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere

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

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

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

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

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

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

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

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

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

1. Objektorientert systemutvikling

1. Objektorientert systemutvikling Tore Berg Hansen 26.10.2004 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:

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

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

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

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

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

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

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

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

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

19. januar 2012 Noen punkter fra i går

19. januar 2012 Noen punkter fra i går 1 19. januar 2012 Noen punkter fra i går Godkjente øvinger og prosjekt er obligatorisk for å få gå opp til eksamen Noen myter om systemutvikling Ariane 5 ulykken 2 Noen myter om systemutvikling Myte 1:

Detaljer

INF1000: Forelesning 7. Konstruktører Static

INF1000: Forelesning 7. Konstruktører Static INF1000: Forelesning 7 Klasser og objekter del 2 Konstruktører Static UML REPETISJON 2 Repetisjon Verden består av objekter av ulike typer (klasser). Ofte er det mange objekter av en bestemt type. Objekter

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

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

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

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

A Study of Industrial, Component-Based Development, Ericsson

A Study of Industrial, Component-Based Development, Ericsson A Study of Industrial, Component-Based Development, Ericsson SIF8094 Fordypningsprosjekt Ole Morten Killi Henrik Schwarz Stein-Roar Skånhaug NTNU, 12. des. 2002 Oppgaven Studie av state-of-the-art : utviklingsprosesser

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

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

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

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

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

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

Eksekveringsrekkefølgen (del 1) Oppgave 1. Eksekveringsrekkefølgen (del 2) Kommentar til oppgave 1. } // class Bolighus

Eksekveringsrekkefølgen (del 1) Oppgave 1. Eksekveringsrekkefølgen (del 2) Kommentar til oppgave 1. } // class Bolighus // class Bygning Oppgave 1 System.out.println( Bolighus ); // class Bolighus Hva blir utskriften fra dette programmet? class Blokk extends Bolighus{ // class Blokk IN105subclassesII-1 Eksekveringsrekkefølgen

Detaljer

Om prosesser 1. Om prosesser

Om prosesser 1. Om prosesser Tore Berg Hansen 27.1.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LV339D Objektorientert systemutvikling 1. Resymé: Denne leksjonen handler om utviklingsprosesser.

Detaljer

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

Hensikten med denne delen av kurset. Objektorientering hva er det? Objektets egenskaper. Best practises ved programvareutvikling Objektorientert systemutvikling, litt UML og Rational Unified Process (RUP) UML Distilled kap. 2 Hensikten med denne delen av kurset Å lære og øve på modelleringsteknikker Å lære om gode designprinsipper

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

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

STE6221 Sanntidssystemer Løsningsforslag

STE6221 Sanntidssystemer Løsningsforslag HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT Side 1 av 3 STE6221 Sanntidssystemer Løsningsforslag Tid: Fredag 02.03.2007, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent programmerbar kalkulator,

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

Fra problem til program

Fra problem til program Fra problem til program Gitt et problem, hvordan går man fram for å programmere en løsning? UML klassediagrammer Enhetstesting Dokumentasjon Som student ønsker vi oss et program som kan holde oversikt

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

1. Mer om iterative utviklingsprosesser

1. Mer om iterative utviklingsprosesser Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Mer om iterative utviklingsprosesser Tore Berg Hansen 8.11.2005 Lærestoffet er utviklet for faget LV339D Objektorientert ssytemutvikling

Detaljer

TDT4102 Prosedyre og Objektorientert programmering Vår 2014

TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Norges teknisk naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Øving 10 Frist: 2014-04-11 Mål for denne øvinga:

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

EKSAMEN I FAG SIF8040 - MMI OG GRAFIKK Lørdag 16. august 2003 Tid: kl. 0900-1400

EKSAMEN I FAG SIF8040 - MMI OG GRAFIKK Lørdag 16. august 2003 Tid: kl. 0900-1400 Side 1 av 6 NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET INSTITUTT FOR DATATEKNIKK OG INFORMASJONSVITENSKAP Faglig kontakt under eksamen: Dag Svanæs, Tlf: 73 59 18 42 EKSAMEN I FAG SIF8040 - MMI OG GRAFIKK

Detaljer

SOSI-forvaltning - logisk modell

SOSI-forvaltning - logisk modell SOSI-forvaltning - logisk modell Forfatter: David Skogan, SINTEF Tele og data Dato: 1997-01-21 Forord Min oppgave til møte den 22 var å beskrive den logisk modellen med skranker for SOSI-standarden. Jeg

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

AlgDat 10. Forelesning 2. Gunnar Misund

AlgDat 10. Forelesning 2. Gunnar Misund AlgDat 10 Forelesning 2 Oversikt Java repetisjon IDE eller teksteditor + kommandolinje? Java Collections and Generics Programvareutvikling En mengde mer eller mindre veldefinerte metoder (software engineering):

Detaljer

2 Grafisk grensesnitt 1

2 Grafisk grensesnitt 1 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Grafisk grensesnitt 1 Mildrid Ljosland 01.02.2011 Lærestoffet er utviklet for faget LN350D Applikasjonsutvikling for mobile enheter 2 Grafisk

Detaljer

Førsteamanuensis John I. Dalseng Høgskolen i Finnmark 9500 Alta

Førsteamanuensis John I. Dalseng Høgskolen i Finnmark 9500 Alta Visualisering og animasjon av diskret-event simuleringsmodeller Innledning Førsteamanuensis John I. Dalseng Høgskolen i Finnmark 9500 Alta En diskret-event simuleringsmodell er et program som etterligner

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

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

Shellscripting I. Innhold

Shellscripting I. Innhold Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Shellscripting I Tor Halsan 19.08.2010 Lærestoffet er utviklet for faget LN199D Scripting av Servere Resymé: Leksjonen er første innføring

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

Distributed object architecture

Distributed object architecture Forelesning IMT2243 1. April 2009 Tema: forts. arkitektur og design av programvare Oppsummering fra forrige gang Programvarearkitektur i distribuerte systemer Programvarearkitektur i RUP Eksempler på arkitekturvurderinger

Detaljer

Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING

Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING 1 Word 1.1 Gjør ting raskt med Fortell meg det Du vil legge merke til en tekstboks på båndet i Word 2016 med teksten Fortell meg hva du vil gjøre.

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

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

Metode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur

Metode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur Dagens forelesning o Litt mer om design med UML sekvensdiagrammer Sentralisert og delegert kontrollstil Resultater fra et eksperiment o UML klassediagrammer Notasjon: UML klassediagram og objektdiagram

Detaljer

Rollemodell. for. det norske kraftmarkedet

Rollemodell. for. det norske kraftmarkedet Rollemodell for det norske kraftmarkedet Versjon: 1.1.A Dato: 27. mai 2010 INNHOLD 1. INNLEDNING... 3 1.1 OM ROLLEMODELLEN... 3 1.2 EDIEL/EBIX... 3 1.3 NOEN UAVKLARTE PROBLEMSTILLINGER... 4 1.3.1 Nettområder

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

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

Prosessmodell. Hurtigguider - rammeverk Sist redigert 13.06.2009. Snorre Fossland Eier og driver Snorres Modellbyrå

Prosessmodell. Hurtigguider - rammeverk Sist redigert 13.06.2009. Snorre Fossland Eier og driver Snorres Modellbyrå Prosessmodell Hurtigguider - rammeverk Sist redigert 13.06.2009 For å arbeide med prosessene, må du kunne synliggjøre og kommunisere dem på overordnet nivå. Du må også kunne bryte dem ned i mer detaljerte

Detaljer

Eneboerspillet del 2. Håvard Johnsbråten, januar 2014

Eneboerspillet del 2. Håvard Johnsbråten, januar 2014 Eneboerspillet del 2 Håvard Johnsbråten, januar 2014 I Johnsbråten (2013) løste jeg noen problemer omkring eneboerspillet vha partall/oddetall. I denne parallellversjonen av artikkelen i vil jeg i stedet

Detaljer

Distributed object architecture

Distributed 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

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

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1 Oppsummering : IMT2243 Systemutvikling Målformuleringen i emnebeskrivelsens : Studentene skal ha forståelse for grunnleggende administrative og teknologiske aspekter ved spesifisering, utvikling, innføring

Detaljer

Conference Centre Portal (CCP)

Conference 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

Detaljer

1. Leksjon 01: Introduksjon til faget Prosjektrettet systemarbeid

1. Leksjon 01: Introduksjon til faget Prosjektrettet systemarbeid Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Leksjon 01: Introduksjon til faget Prosjektrettet systemarbeid Greta Hjertø og Tore Berg Hansen 30.08.2005 Revidert av Kjell Toft Hansen

Detaljer

INF5120 - Oblig 2. Hour Registration System (HRS)

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

Detaljer

Kanter, kanter, mange mangekanter

Kanter, kanter, mange mangekanter Kanter, kanter, mange mangekanter Nybegynner Processing PDF Introduksjon: Her skal vi se på litt mer avansert opptegning og bevegelse. Vi skal ta utgangspunkt i oppgaven om den sprettende ballen, men bytte

Detaljer

Læringsmål for forelesningen

Læringsmål for forelesningen Læringsmål for forelesningen Objektorientering Håndtering av unntak (eng: exceptions) Java-programmering Håndtering av unntak Exception-objekter og klasser try, catch og finally throw og throws Eclipse

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

Eksamen i fag SIF8018 Systemutvikling. Fredag 25. mai 2001 kl

Eksamen 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

Detaljer

Distribuerte objekter og objekt-basert mellomvare

Distribuerte objekter og objekt-basert mellomvare Distribuerte objekter og objekt-basert mellomvare INF 5040 H2006 foreleser: Frank Eliassen INF5040 Frank Eliassen 1 Hvorfor objekt-basert distribuert mellomvare? Innkapsling naturlig tilnærming til utvikling

Detaljer

Distribuerte objekter og objekt-basert mellomvare

Distribuerte objekter og objekt-basert mellomvare Distribuerte objekter og objekt-basert mellomvare INF 5040 H2004 foreleser: Frank Eliassen Frank Eliassen, SRL & Ifi/UiO 1 Hvorfor objekt-basert distribuert mellomvare?! Innkapsling " naturlig tilnærming

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

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

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

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

Unified Modeling Language (UML) Kravspesifikasjon med UML use case modellering. UML diagrammer. Notasjon som støtter opp under modellbasert

Unified Modeling Language (UML) Kravspesifikasjon med UML use case modellering. UML diagrammer. Notasjon som støtter opp under modellbasert 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