Hva vi i alle fall bør huske fra INF1050

Hva vi i alle fall bør huske fra INF1050 Gerhard Skagestein 25. januar 2006 25. januar 2006 INF2120 Prosjekt i modellering 1

Figur 1-3. Et systems livssyklus Idé Krav og ønsker Utforming Realisering Ny idé t... Systemet settes i drift Initiell utvikling og realisering Vedlikehold 25. januar 2006 INF2120 Prosjekt i modellering 2

Modellenes to formål Interesseområdet (UoD) Beskrivelse Oppfatningen av interesseområdet Foreskrivelse Informasjonssystem Brukere 25. januar 2006 INF2120 Prosjekt i modellering 3

Figur 3-8. En trelags-arkitektur for et informasjonssystem Brukergrensesnitt! inn ut Utviklingsverktøy Systemutvikler Applikasjon Virkelighetsmodell Bruker Plattform (programvare) Plattform (maskinvare) 25. januar 2006 INF2120 Prosjekt i modellering 4

Beskrivelser og beskrivelsesspråk I begynnelsen av systemutviklingsprosessen er uformelle beskrivelser det beste! Formelle beskrivelser drar oppmerksomheten mot formalitetene, og vekk fra problemstillingene! UML dekker ikke alt, til tross for at UML er meget omfattende! Hvor høy skal detaljeringsgraden være? Styres av formålet med beskrivelsen Beskrivelse av interesseområdet? Foreskrivelse av informasjonssystemet? 25. januar 2006 INF2120 Prosjekt i modellering 5

Hva oraklet skal kunne vite uttrykkes i ORM, dataorientert UMLklassediagram eller som tabelldatabasestruktur Fra kjernen og ut registrering Interesseområdet påvirkning Fra kjernen og ut : Dataorientert klassediagram -> Relasjonsdatabase -> Spørringer Jeg svarer på alle spørsmål (nesten, da) Oppfatningen av interesseområdet Orakel Informasjonssystem Organisasjonen Brukere 25. januar 2006 INF2120 Prosjekt i modellering 6

De funksjonelle krav uttrykkes i UML-bruksmønstre Fra skallet og inn Interesseområdet Fra skallet og inn: Bruksmønster -> Sekvensdiagram -> Klassediagram registrering påvirkning Jeg gjør det du forventer at jeg skal gjøre Oppfatningen av interesseområdet Informasjonssystem Organisasjonen Brukere 25. januar 2006 INF2120 Prosjekt i modellering 7

Dataorientert vs. objektorientert utforming Program SQL Informasjonssystem CREATE TABLE INSERT INSERT Dataorientert klasse (entitet) metodekall create/new create/new klasse Informasjonssystem Objektorientert 25. januar 2006 INF2120 Prosjekt i modellering 8

Dataorientert vs. objektorientert utforming Både dataorienterte og objektorienterte informasjonssystemer inneholder data. Forskjellen er at i dataorienterte systemer er alle data samlet i en sentral ressurs databasen, mens i objektorienterte systemer er dataene fordelt på objektene ut fra det generelle prinsipp at det objektet som har bruk for data selv tar vare på dem. I objektorienterte systemer får dataene evig liv ved å gjøre objektene persistente. Dette kan realiseres på flere måter for eksempel ved hjelp av en OO-database.. 25. januar 2006 INF2120 Prosjekt i modellering 9

Spesielt for OO-databaser I OO har vi som collection ikke bare mengde, men også bag, list og array > krav om entydighetsskranke faller bort > forekomstene kan ordnes I OO kan strukturer som set, bag, list og array, samt generelle objekter, brukes som verdier > uendelige mange muligheter for hvordan data struktureres I OO er dataene innkapslet i objektene > dataenes struktur er ukjent for omverdenen - de kan bare fås tak i gjennom spørremeldinger i OO har objekter sin egen innebygde identifikator (OID) > concepter behøver ikke alltid ha en representasjon Ah, hvilken frihet - men vi betaler vel noe for dette? 25. januar 2006 INF2120 Prosjekt i modellering 10

Statiske og dynamiske virkelighetsmodeller Interesseområdet t registrering påvirkning Oppfatningen av interesseområdet t t Informasjonssystem Brukere 25. januar 2006 INF2120 Prosjekt i modellering 11

Dataorientert (statisk) virkelighetsmodell Virkelighetsmodellen omfatter interesseområdets tilstander og deres representasjoner regler for lovlige/ulovlige tilstander og tilstandsoverganger Virkelighetsmodellen omfatter ikke transformasjoner fra en tilstand til den neste Informasjonssystemet får istedenfor en melding om at virkeligheten har endret seg, og virkelighetsmodellen oppdateres ved hjelp av funksjoner i applikasjonslaget. Virkelighetsmodellen deles av alle funksjoner Vi har i INF1050 brukt dataorienterte klassediagrammer (ugrupperte og grupperte) for å beskrive modellene 25. januar 2006 INF2120 Prosjekt i modellering

Objektorientert (dynamisk) virkelighetsmodell Virkelighetsmodellen gjenspeiler konkrete og/eller tenkte (mentale) objekter, med hver sin tilstand og hver sin oppførsel Virkelighetsmodellens objekter kan selv sørge for transformasjoner fra en tilstand til den neste Informasjonssystemet må i tillegg ha funksjoner (ofte implementert ved hjelp av objekter) for (resten av) forretningslogikken brukergrensesnittet 25. januar 2006 INF2120 Prosjekt i modellering

Det dataorienterte vs. det objektorienterte perspektiv I det dataorienterte perspektivet interesserer vi oss for faktaopplysninger av statisk natur om interesseområdet, og skranker som forhindrer registrering av åpenbart uriktige fakta I det objektorienterte perspektivet interesserer vi oss for virkelige og tenkte objekter i interesseområdet, og hvordan disse objektene gjennom samarbeide kan gi en hensiktsmessig modell Javel, men har ikke da disse perspektivene svært lite til felles? 25. januar 2006 INF2120 Prosjekt i modellering 14

Utviklingsretninger og utforminger Fra kjernen og ut Fra skallet og inn Dataorientert utforming? Objektorientert utforming? Er rutene med? interessante? 25. januar 2006 INF2120 Prosjekt i modellering 15

Jakten på de elementære utsagn «concept» Materiale materialnavn {id} gjenvunnet_ materiale * «concept» Avfallsselskap selskapsnavn {id} * avfallsinnsamler Materialgjenvinning * område «concept» Kommune kommunenavn {id} 25. januar 2006 INF2120 Prosjekt i modellering 16

Hva er et elementært utsagn? Et elementært utsagn er et utsagn som ikke kan deles opp uten at meningsinnholdet går tapt Et utsagn er et antall begreper som er knyttet sammen med assosiasjoner Elementære utsagn er som oftest binære (assosiasjon mellom to begreper) 25. januar 2006 INF2120 Prosjekt i modellering 17

Hvorfor elementære utsagn? Modeller basert på elementære utsagn er nøytrale overfor realiseringsplattformen En grundig analyse av høyere ordens assosiasjoner kan avsløre de riktige assosiasjonene Utsetter avgjørelsen om mindre viktige begreper skal realiseres som tabeller eller objekter, eller om de skal degenerere til attributter Synliggjør at samme begrep kan spille flere roller. Viktig f. eks. for å finne fram til datatyper i SQL 1999 Synliggjør hvilke roller som kan sammenliknes, legges sammen og trekkes fra nemlig de som spilles av det samme begrepet Kan leses som en setning på vanlig norsk fordelaktig for at modellen skal kunne kontrolleres av ikkeeksperter Bevisstgjør konseptualiseringen jf. Ogdens trekant 25. januar 2006 INF2120 Prosjekt i modellering 18

Tolkning av en assosiasjon som en tabell «concept» Kommune kommunenr {id} 0..* ligger_i 1..1 omfatter fylkenr {id} «concept» Fylke ligger_i omfatter 0101 01 0104 01 0105 01 25. januar 2006 INF2120 Prosjekt i modellering 19

Figur 6-1. En tabell-linje kan leses som en setning med «concept» Kommune kommunenr {id} 0..* 1..1 ligger_i omfatter med fylkenr {id} «concept» Fylke ligger_i omfatter 0101 01 0104 01 0105 01 Kommune med kommunenr 0101 ligger_i fylke med fylkenr 01 25. januar 2006 INF2120 Prosjekt i modellering 20

Eksempel på elementært utsagn «concept» Materiale materialnavn {id} gjenvunnet_ materiale * «concept» Avfallsselskap selskapsnavn {id} * avfallsinnsamler Materialgjenvinning * område «concept» Kommune kommunenavn {id} Jf. Systemutvikling kjernen/skallet figur 6-4 avfallsinnsamler gjenvunnet_ materiale område Gjenvinning glass Halden Returpapir glass Moss Returpapir papir Halden 25. januar 2006 INF2120 Prosjekt i modellering 21

Figur 6-6. Oppløsning av en høyere ordens assosiasjon «concept» Materiale materialnavn {id} «concept» Avfallsselskap selskapsnavn {id} 1 «identifying» * «concept» «identifying» 1 Materialgjenvinning * område «identifying» avfallsinnsamler gjenvunnet_ materiale * 1 «concept» Kommune kommunenavn {id} 25. januar 2006 INF2120 Prosjekt i modellering 22

Figur 6-8. Forretningsregelen fjerner behovet for en høyere ordens assosiasjon «concept» Materiale materialnavn {id} * * gjenvunnet_ materiale område «concept» Kommune kommunenavn {id} «concept» Avfallsselskap selskapsnavn {id} avfallsinnsamler 1 * «concept» Gjenvinningsoppdrag avfallsinnsamler gjenvunnet_ materiale område Gjenvinning glass Halden Returpapir glass Moss Returpapir glass Halden 25. januar 2006 INF2120 Prosjekt i modellering 23

Jakten på de elementære utsagn Modellér med binære utsagn så langt råd er Begrepsdannelse: Rollekombinasjoner som er gjenstand for entydighetsskranke, kan oppfattes som et nytt begrep (I UML: En concept-stereotypiet assosiasjonsklasse) Bruk N 1-regelen: Relasjoner der kun én rolle er utenfor entydighetsskranken, er elementære Normaliser til Boyce-Codd: Alle determinanter (venstresider i funksjonelle avhengigheter) skal være gjenstand for entydighetsskranke Normalisering til 4NF: Flerverdiavhengigheter erstattes med relasjoner med heldekkende entydighetsskranke 25. januar 2006 INF2120 Prosjekt i modellering 24

Dataorientert klassediagram (ugruppert) «concept» År årstall {id} «concept» Kommune kommunenr {id} * «identifying» 1 1 «identifying» * * «concept» Materialgjenvinning «identifying» * 1 gjenvunnet_ * materiale «concept» Materiale materialnavn {id} 1 «concept» Kommunenavn 0:1 gjenvunnet mengde «concept» Mengde # tonn {id} kommunenavn {id} 25. januar 2006 INF2120 Prosjekt i modellering 25

Dataorientert klassediagram (gruppert) År årstall {id} Kommune kommunenr {id} kommunenavn {fk} * 1 Kommunenavn «identi- 1fying» 1 «identifying» * Materialgjenvinning kommunenr {id}{fk} «identifying» 1 * årstall {id}{fk} * materialnavn {id}{fk} gjenvunnet_ mengde {fk} materiale * 0:1 gjenvunnet mengde Materiale materialnavn {id} Mengde # tonn {id} kommunenavn {id} 25. januar 2006 INF2120 Prosjekt i modellering 26

Undertrykke klasser før generering av relasjonsdatabase År årstall {id} Kommune kommunenr {id} kommunenavn * 1 Kommunenavn «identifying» 1 1 «identifying» * Materialgjenvinning kommunenr {id}{fk} «identifying» 1 * årstall {id} * materialnavn {id} gjenvunnet_ mengde materiale * 0:1 gjenvunnet mengde Materiale materialnavn {id} Mengde # tonn {id} kommunenavn {id} 25. januar 2006 INF2120 Prosjekt i modellering 27

Er OO-klasser lik dataorienterte klasser med metoder? Ser vi de samme fenomener i virkeligheten, uavhengig av om perspektivet er dataorientert eller objektorientert? Merk at: I OO står vi mye friere med hensyn til strukturering av data Objekter har ansvar og oppførsel Med andre ord - får vi et objektorientert klassediagram bare ved å føye til metoder? 25. januar 2006 INF2120 Prosjekt i modellering 28

Figur 10-10. Sekvensdiagram for avfallsstatistikk-system Kontrollobjekt Forretningsobjekter :Brukergrensesnitt :Statstikkinteressert person Be om statistikk create( ) lagstatistikk(args) :Statistikkprodusent hentdata(args) :HeleLandet loop Halden: Kommune Moss: Kommune mengde:=gjenvunnetmengde (periode,materiale) loop Halden1998: Gjenvinning mengde :=gjenvunnetmengde(materiale) mengde := gjenvunnetmengde(materiale) mengde :=gjenvunnetmengde (periode,materiale) loop Halden2001: Gjenvinning mengde := gjenvunnetmengde(materiale) Moss1998: Gjenvinning gjenta for alle aktuelle år Fjern objektet det trengs ikke lenger gjenta for alle kommuner 25. januar 2006 INF2120 Prosjekt i modellering 29

Klassediagram for avfallsstatistikk-system HeleLandet struct hentdata(args) Kommune 1 * kommunenr {id} 1 * kommunenavn int gjenvunnetmengde (periode, materiale) Materialgjenvinning årstall {id} papirmengde glassmengde plastmengde int gjenvunnetmengde (materiale) Objektorientert klassediagram jf. Systemutvikling kjernen/skallet figur 10-11 Dataorientert klassediagram Kommune kommunenr {id} kommunenavn «identifying» 1 * Materialgjenvinning kommunenr {id} årstall {id} materialnavn {id} mengde 25. januar 2006 INF2120 Prosjekt i modellering 30

Realisering av et klassediagram Fylke fylkenr {id} fylkenavn {unique} relasjonsdatabase «identifying» 1 * Kommune fylkenr {id} {fk} komnr2s {id} kommunenavn fylkenr {subset} fylkenavn 01 Østfold Østfold:Fylke 01 Østfold evt. metoder objekter :Kommune 0101 Halden evt. metoder fylkenr komnr2s kommunenavn 01 01 01 04 Halden Moss realiseres ved hjelp av OIDs eller relationships :Kommune 0104 Moss evt. metoder 25. januar 2006 INF2120 Prosjekt i modellering 31

Forholdet mellom det generelle og det spesielle (klasser og objekter) Det generelle, eksisterer det egentlig, eller er det noe vi har funnet på for å beskrive/snakke om verden på en enklere måte? Eks: kråker, mennesker Eksisterer slike fellesbegreper, eller er det bare vår egen begrepsdannelse? Hvis de eksisterer, er de av fysisk eller åndelig natur? Eksisterer det generelle evt. fritt fra de enkelte individene, eller bare som del av disse? Debatt fra 1100- tallet, interessant for systemutviklere 25. januar 2006 INF2120 Prosjekt i modellering 32

Fra datamodell til relasjonsdatabase Fylke fylkenr {id}. omfatter 1:1 primærnøkkel referanseintegritet (fra implisitt delmengdeskranke) Fylke fylkenr 01 02 03 ligger-i * Kommune komnr2s {id}. «identifying» fremmednøkkel null / not null plassering av fremmednøkkel primærnøkkel {subset} Kommune NOT NULL fylkenr 01 01 01 komnr2s 01 04 05 25. januar 2006 INF2120 Prosjekt i modellering 33

Nominalist eller Realist Nominalist Det som eksisterer er bare enkeltindividene. Generelle fellesbegreper er skapt av menneskene, bl.a. for bedre å forstå/beskrive verden (eks. Wilhelm av Occam og Charles Darwin) Realist Generelle fellesbegreper som kråke, menneske har en egen eksistens, og enkeltindividene er dannet etter disse (eks: Platon og Thomas av Aquinas) 25. januar 2006 INF2120 Prosjekt i modellering 34

Klasser eller objekter først? Dataorientert utforming: Begreper og klasser, deretter forekomster Men: Homogenitetsregelen Objektorientert utforming: Objekter, deretter klasser Hvorfor forskjellen i praktisk fremgangsmåte? 25. januar 2006 INF2120 Prosjekt i modellering 35

Eksempel - Hanois tårn Oppgave: Flytt alle ringene fra en pinne til en annen. Du skal bare flytte en ring ad gangen, og det er ikke lov til å legge en større ring oppå en mindre 25. januar 2006 INF2120 Prosjekt i modellering 36

Hanois tårn datadrevet utforming Ring ringnr 0..4 1 er på Pinne pinnenr eller (i verste fall) Ring ringnr pinnenr så føyer vi til metoden: Ring ringnr pinnenr flytt( ) Metode Flytt: Spør VENSTRE pinne: Har du ringer? NEI ---> Si til merket FLYTT-TIL pinnen til HØYRE Flytt til pinnen til VENSTRE Si til "gamlepinnen" FLYTTET JA ---> Spør pinnen om størrelsen på topp-ringen : STØRRE enn deg ---> Si til merket FLYTT-TIL pinne til HØYRE Flytt til pinnen til VENSTRE Si til "gamlepinnen" FLYTTET MINDRE enn deg ---> Spør HØYRE pinne: Har du ringer? NEI ---> Si til merket FLYTT-TIL pinnen til VENSTRE Flytt til pinnen til HØYRE Si til "gamlepinnen" FLYTTET JA ---> Spør pinnen om størrelsen på topp-ringen : STØRRE enn deg ---> Si til merket FLYTT-TIL pinnen til VENSTRE Flytt til pinnen til HØYRE Si til "gamlepinnen" FLYTTET MINDRE enn deg ---> Si til "gamlepinnen" KAN-IKKE 25. januar 2006 INF2120 Prosjekt i modellering

Sekvensdiagram for Hanois tårn Kontrollobjekt Forretningsobjekter :Spiller Startpinne Pinne2 Pinne3 Ring1 Ring2 Ring3 Ring4 «create» :Spillkontroll spill! flyttringer flytt taimotmeg flyttringer flytt taimotmeg flyttringer flytt taimotmeg flyttringer flytt ferdig! ferdig! flyttringer Fjern objektet det trengs ikke lenger 25. januar 2006 INF2120 Prosjekt i modellering 38

Hanois tårn - klassediagram Ring ringnr 0:4 {ordered} 1 venstre 1 høyre Pinne pinnenr flyttringer( ) taimotmeg( ) Ring1 Ring2og4 Ring3 Startpinne toerunder flytt( ) flytt( ) flytt( ) flyttringer( ) 25. januar 2006 INF2120 Prosjekt i modellering 39

Hanois tårn - klassebeskrivelser Klassen Pinne: Metode: taimotmeg Legg ring på topp Metode: flyttringer Har du ringer ---> JA: Si til toppringen flytt ; NEI: Si til Høyre pinne flyttringer ; Klassen StartPinne: Metode: taimotmeg Legg ring på topp Metode : flyttringer Har du ringer ---> JA: Si til toppringen flytt NEI: Ferdig! Klassebeskrivelsene er utarbeidet av Else Nordhagen Klassen Ring1: Boolean toerunder = true; Metode: flytt Si til Høyre pinne taimotmeg ; toerunder := not toerunder; if toerunder then Si til Høyre pinne flyttringer ; else Si til Venstre pinne flyttringer ; Klassen Ring2og4: Metode: flytt Si til Venstre pinne taimotmeg ; Si til Venstre pinne flyttringer ; Klassen Ring3: Metode: flytt Si til Høyre pinne taimotmeg ; Si til Høyre pinne flytt Ringer ; 25. januar 2006 INF2120 Prosjekt i modellering 40

Hanois tårn - Hvorfor forskjellen? Det datadrevne perspektivet overser at ringene har forskjellig oppførsel Det datadrevne perspektivet ser for unyansert på hva ringer og pinner må vite tar med alt for sikkerhets skyld vi må jo være forberedt på adhoc queries! 25. januar 2006 INF2120 Prosjekt i modellering

Figur 7-1. Skrankene skal gjenspeile virkelighetens regler Forretningsregler Virkeligheten (interesseområdet) registrering påvirkning Skranker Oppfatningen av virkeligheten Skranker/ Integritetsregler Informasjonssystem Virksomheten Brukere 25. januar 2006 INF2120 Prosjekt i modellering 42

Figur 7-2. Notasjon for skranker i UML-klassediagrammer {skrankebeskrivelse i OCL e.l} {skrankebeskrivelse i OCL e.l} 25. januar 2006 INF2120 Prosjekt i modellering 43

Figur 7-12. Delmengdeskranken papirgjenvinner gjenvunnet_ papirmengde * «concept» Avfallsselskap selskapsnavn {id} * metallgjenvinner {subset} * 0..1 glassgjenvinner gjenvunnet_ glassmengde «concept» Mengde #tonn {id} gjenvunnet_ metallmengde 0..1 1..1 25. januar 2006 INF2120 Prosjekt i modellering 44

Figur 7-12. Delmengdeskranken papirgjenvinner gjenvunnet_ papirmengde Returpapir 2000 {subset} Gjenvinning 5000 glassgjenvinner gjenvunnet_ glassmengde Gjenvinning 1000 metallgjenvinner gjenvunnet_ metallmengde Returpapir 1500 Gjenvinning 2500 Glasshytta 3500 25. januar 2006 INF2120 Prosjekt i modellering 45

Figur 7-13. Delmengdeskranke etter gruppering {gjenvunnet_papirmengde = nil implies gjenvunnet_glassmengde = nil} selskapsnavn gjenvunnet_ papirmengde Returpapir 2000 Gjenvinning 5000 gjenvunnet_ glassmengde 1000 NOT NULL gjenvunnet_ metallmengde nil 1500 2500 Glasshytta nil nil 3500 25. januar 2006 INF2120 Prosjekt i modellering 46

Implisitt delmengdeskranke i gruppert modell Fylke fylkenr {id} fylkenavn {unique} «identifying» 1 * Kommune fylkenr {id} {fk} komnr2s {id} kommunenavn {subset} fylkenr fylkenavn 01 Østfold fylkenr komnr2s kommunenavn 01 01 01 04 Halden Moss 25. januar 2006 INF2120 Prosjekt i modellering 47

Realisering av delmengdeskranke i SQL Delmengdeskranken realiseres vanligvis ved hjelp av referanseintegritet. Denne deklareres som regel i en separat ALTER TABLE av kontrollert tabell: ALTER TABLE navn_på_kontrollert_tabell ADD CONSTRAINT navn_på_regel FOREIGN KEY(fremmednøkkelattributt1, fremmednøkkelattributt2) REFERENCES navn_på_kontrollerende_tabell (attr1, attr2); Eksempel Fylke Kommune fylkenr {subset} fylkenavn kan utelates da antas primærnøkkelen NOT NULL NOT NULL fylkenr kommunenr2s kommunenavn avfallsmengde innbyggertall ALTER TABLE Kommune ADD CONSTRAINT fylkenr_fk FOREIGN KEY(fylkenr) REFERENCES Fylke; 25. januar 2006 INF2120 Prosjekt i modellering 48

Handlingsmønster ved overtredelse av referanseintegritet ALTER TABLE navn på kontrollert tabell ADD CONSTRAINT navn på regel FOREIGN KEY(fremmednøkkelattributt) REFERENCES navn_på_kontrollerende_tabell ON DELETE referential_action ; eller UPDATE NO ACTION (gi feilmelding) CASCADE (fjern også kontrollerte linjer) SET NULL (sett fremmednøkkel til NULL) SET DEFAULT (sett fremmednøkkel til default -verdi) I Oracle: bare ON DELETE CASCADE 25. januar 2006 INF2120 Prosjekt i modellering 49

Figur 7-3. Hva skrankene brukes til Skranker Strukturering av databasen Deklarative integritetsregler Virkelighetsmodell Brukergrensesnitt Applikasjon Programmerbare integritetsregler - i databasen (triggere) - i applikasjonsprogrammene - i brukergrensesnittene Systemutvikler 25. januar 2006 INF2120 Prosjekt i modellering 50

Skranker Hvorfor er skranker så viktige i dataorientert utforming, og lite omtalt i objektorientert utforming? En relasjonsdatabase har ingen egen bevissthet, og trenger et regelverk og en vaktbikkje til å beskytte seg Objekter har oppførsel, og vi antar at de følger Kardemommeloven: Du skal ikke plage andre, du skal være grei og snill og for øvrig kan du gjøre hva du vil Antagelsen holder ikke nødvendigvis alltid stikk (programmeringsfeil!) derfor er skranker på vei inn også i objektorienterte systemer jfr OCL (Object Constraint Language) 25. januar 2006 INF2120 Prosjekt i modellering 51

Oppsummering Modeller kan brukes både deskriptivt og preskriptivt Dataorienterte klassediagrammer brukes for å gi en statisk beskrivelse av interesseområdet, og har derfor ingen metoder Elementære utsagn er et grunnfjell som er uavhengig av realiseringsplattform Gruppering av ugrupperte klassediagrammer kan gjøres etter ulike kriterier intuitivt relasjonsdatabaseorientert ansvarsdrevet Vær forsiktig med å tenke klasser før objekter Skranker er viktig! 25. januar 2006 INF2120 Prosjekt i modellering 52