INF2120 Dataorientert modellering Ragnar Normann 1. mars 2006 INF2120 Prosjekt i modellering 1
Dataorientering og UML UML har som utgangspunkt et objektorientert syn på tilværelsen hvor oppførsel og samspill mellom objekter er det sentrale UML beskriver datastrukturen i klassediagrammer Et UML klassediagram gir en oversikt over klassene i systemet og de statiske relasjonene mellom dem Metoder for å analysere datastruktur eksisterte lenge før UML ble til Den desidert mest utbredte av disse dataorienterte metodene er ER (Entity-Relationship) som ble introdusert av Chen i 1976, og som siden har kommet i et utall av dialekter UML klassediagrammer kan godt betegnes som en ny ER-dialekt Den vesentligste forskjellen er at UML klassediagrammer, i tillegg til å angi attributter, også inneholder navn på metoder i klassene Bruken av UML øker kraftig, og UML klassediagrammer er i ferd med å bli den dominerende ER-dialekten (Mange vil si: ta over for ER) 1. mars 2006 INF2120 Prosjekt i modellering 2
ORM (Object-Role Modeling) Selv om ER har vært den desidert mest utbredte metoden for å utarbeide datamodeller, er den ikke nødvendigvis den beste Rollemodellering (Engelsk «Object-Role Modelling», forkortet ORM) er en annen metode ORM er mer detaljert og har større utsagnskraft enn ER Det betyr at vi kan utrykke mer kompliserte sammenhenger og skranker med ORM enn det vi kan gjøre med ER, og dermed med tradisjonelle UML klassediagrammer I tillegg inneholder ORM en metode for å kvalitetssikre klassediagrammene, en metode som med fordel kan overføres til UML 1. mars 2006 INF2120 Prosjekt i modellering 3
OCL Object Constraint Language OCL er et språk for å uttrykke skranker som ikke lar seg uttrykke i de «ordinære» UML-diagrammene OCL er beskrevet i en bok av Jos Warmer og Anneke Kleppe: The Object Constraint Language Precise Modelling with UML Der forelår de noen utvidelser av UML klassediagrammer for å gjøre dem tilnærmet like uttrykkskraftige som ORM-diagrammer Formålet med denne forelesningen er å vise noen av ideene bak ORM og hvordan de ved bruk av OCL kan inkorporeres i UML klassediagrammer På den måten kan vi sørge for at ikke UML klassediagrammer er dårligere enn tidligere tiders datamodelleringsteknikker 1. mars 2006 INF2120 Prosjekt i modellering 4
ORM og 100%-prinsippet ORM er en metode for å beskrive informasjonsstruktur ORM baserer seg på 100%-prinsippet: Det er alltid mulig å gi en endelig og fullstendig tekstlig beskrivelse av UoD, dvs. den delen av virkeligheten som interesserer oss (UoD = Universe of Discourse) En slik beskrivelse kalles en informasjonsmodell Informasjonsmodellen kan brukes som forskrift for et datasystem og kalles da datasystemets begrepsmessige skjema Siden utgangspunkt og mål er tekstlige beskrivelser, følger det at ORM er vitenskapelig forankret i (formell) lingvistikk Resultatet av en ORM-analyse er en grafisk fremstilling av en tekstlig beskrivelse av informasjonsstrukturen 1. mars 2006 INF2120 Prosjekt i modellering 5
NIAM en ORM-dialekt NIAM er den eldste ORM-dialekten NIAM ble utviklet i Nederland 1964 1977 av en gruppe ledet av G.M.Nijssen De fleste tror at NIAM betyr «Nijssen's Information Analysis Method» Nijssen selv hevder imidlertid at NIAM er et akronym for «Natural language Information Analysis Methodology» Vi skal bruke en revidert versjon av NIAM fra 1982 som vår ORMdialekt og se hvordan denne kan uttrykkes i UML syntaks En konsekvens av at NIAM (og alle senere ORM-dialekter) er basert på naturlig språk, er at en NIAM modell er en grafisk fremstilling av vanlige setninger 1. mars 2006 INF2120 Prosjekt i modellering 6
Entiteter En entitet er en gjenstand, egenskap eller hendelse i interesseområdet vårt Eksempler: Sigrid Undset Bilen min Studielånet ditt INF2120 Dagen i dag Rød Entiteter beskrives vanligvis med substantiver, men pronomener og adjektiver forekommer også I objektorientert modellering (som UML) modelleres entiteter som objekter én entitet svarer til ett objekt og omvendt 1. mars 2006 INF2120 Prosjekt i modellering 7
Begreper Det første, og vanskeligste, trinnet i modelleringsprosessen er å putte entitetene i interesseområdet inn i båser eller grupper En slik gruppe entiteter kalles en entitetstype Navnet på en entitetstype kalles et begrep (På engelsk: concept) Eksempler på begreper Person Ansatt Lån Farge 1. mars 2006 INF2120 Prosjekt i modellering 8
Eksempel på et «vanskelig» begrep Hvilke entiteter i interesseområdet omfattes av begrepet «bok»? Har du lest Peer Gynt? Når ble boken med ISBN 82-00-22476-6 utgitt? Hvem har lånt eksemplar 5 av denne boken? Merk: Begrepers innhold er avhengig av hva som er vårt interesseområde 1. mars 2006 INF2120 Prosjekt i modellering 9
Representasjonstyper Vanligvis kan ikke entiteter lagres i databasen De data vi lagrer, er representasjoner av entitetene, og disse representasjonene må tilhøre en representasjonstype for det begrepet som entiteten tilhører Et begrep kan tilordnes flere representasjonstyper Eksempler: Personer kan representeres med navn og/eller fødselsnummer Biler kan representeres med bilnummer eller chassisnummer 1. mars 2006 INF2120 Prosjekt i modellering 10
Ogdens trekant 1. mars 2006 INF2120 Prosjekt i modellering 11
Roller Når vi beskriver sammenhenger mellom begreper, sier vi at begrepene spiller roller overfor hverandre Eksempel: Anta at vi har de to begrepene «person» og «bil», og at personer kan eie biler Da sier vi at person spiller rollen «eier» overfor bil, og at bil spiller rollen «er eid av» overfor person Roller uttrykkes vanligvis med verb og/eller preposisjoner 1. mars 2006 INF2120 Prosjekt i modellering 12
Begreper tegnet i NIAM og UML I NIAM tegnes begreper som heltrukne sirkler og representasjoner som stiplede sirkler Person Fødselsnr UML har i utgangspunktet ikke noe symbol for begreper Dette løser vi med å definere en stereotypi med den egenskap at den ikke kan ha andre attributter enn sin representasjon («id») Person Fødselsnr {id} 1. mars 2006 INF2120 Prosjekt i modellering 13
Broer I NIAM kalles sammenhengen mellom et begrep og dets representasjon en bro (broen går mellom modell og representasjon), og vi tegner den slik: Person med for Fødselsnr Rollene i broer er redundante, og vi kan alltid bruke «med» og «for» Broen kan leses begge veier: Begrep med representasjon Representasjon for begrep UML har ikke noen konstruksjon som tilsvarer broer I et er broen implisitt definert ved at alle attributtene inngår i identifikatoren Person Fødselsnr {id} 1. mars 2006 INF2120 Prosjekt i modellering 14
Broer på kortform Siden rollene i broer er redundante, tillater vi oss ofte å la være å tegne broene Da skriver vi representasjonstypen i parentes etter (under) begrepsnavnet Med denne kortformen blir et begrep i NIAM svært likt et i UML Person (Fødselsnr) tilsvarer Person Fødselsnr {id} 1. mars 2006 INF2120 Prosjekt i modellering 15
Faktatyper Det at personer eier biler, og at biler eies av personer, tegner vi slik: Person eier er eid av Bil En slik sammenheng mellom to begreper hvor begrepene spiller hver sin rolle overfor hverandre, kalles en binær faktatype Slike «kjøttben» er de viktigste byggeklossene i NIAM (ORM) I vår variant av UML, som vi skal kalle -UML, ser det slik ut: Person 1 0..* eier er eid av Bil 1. mars 2006 INF2120 Prosjekt i modellering 16
Faktasetningers dype struktur Person eier eies av Bil med på Person med fødselsnummer 12094430256 eier bil med registreringsnummer CE76543 Bil med registreringsnummer CE76543 eies av person med fødselsnummer 12094430256 med på De to setningene har samme meningsinnhold, dvs. samme dype struktur Fødselsnr Reg.- nr 1. mars 2006 INF2120 Prosjekt i modellering 17
Dyp struktur tegnet med UML--klasser Person eier eies av Bil med på Slik ser samme setning ut i UML: Person Fødselsnr{id} 1 0..* eier er eid av Bil Reg.- nr{id} De to tegningene uttrykker akkurat det samme med på Fødselsnr Reg.- nr 1. mars 2006 INF2120 Prosjekt i modellering 18
Syntaksregler i NIAM og -UML Del 1: Begreper og roller Et begrep tegnes i NIAM som en heltrukket sirkel eller ellipse med et navn inni I UML er et begrep det samme som en -stereotypi Samme begrep kan forekomme vilkårlig mange ganger i den ferdige modellen (både i NIAM og UML) Dette er et tegneteknisk hjelpemiddel, og to begreper med samme navn betegner samme begrep I NIAM er en rolle et rektangel med en tekst i I UML er en rolle en kommentar skrevet utenfor klassen knyttet til den linjen som representerer den faktatypen som rollen inngår i En rolle skal knyttes til nøyaktig ett begrep I NIAM har i tillegg også hver representasjonstype nøyaktig en rolle I NIAM tegnes tilknyttingen som en heltrukken linje/kurve mellom randen på rollen og randen på begrepet 1. mars 2006 INF2120 Prosjekt i modellering 19
Syntaksregler i NIAM og -UML Del 2: Faktatyper I NIAM gjelder følgende regler: En faktatype tegnes som en eller flere roller stilt ved siden av hverandre (det kan være vilkårlig mange roller i en faktatype) Et begrep skal ha minst en rolle som inngår i en faktatype (vi sier at begrepet deltar i faktatypen) Et begrep kan ha vilkårlig mange roller og altså delta i vilkårlig mange faktatyper (og broer) Et begrep kan ha flere roller i samme faktatype Disse rollene må da ha forskjellig tekst I UML gjelder følgende: Binære faktatyper, dvs faktatyper med to roller, tegnes som en heltrukken linje mellom de to klassene (begrepene) som spiller disse rollene Lengre faktatyper må særbehandles (vi tar det problemet senere) 1. mars 2006 INF2120 Prosjekt i modellering 20
Elementære setninger En setning kalles elementær hvis den ikke kan deles opp uten å miste meningsinnhold Eksempel: Setningen «Mons spiser grøt og drikker melk» kan deles opp i to elementære setninger «Mons spiser grøt» «Mons drikker melk» De to siste setningene kalles binære fordi de binder sammen to entiteter, hhv. «Mons» med «grøt» og «Mons» med «melk» Binære setninger er alltid elementære Eksempel: Maksimumstemperaturen i Narvik 17.5.1964 var -1 C Dette er en elementær (ternær) setning som binder sammen et sted, et tidspunkt og en temperatur 1. mars 2006 INF2120 Prosjekt i modellering 21
Fakta (setningsforekomster) og semantikkregelen for faktatyper Alle faktatyper beskriver den dype strukturen i en gruppe med setningsforekomster Semantikkregelen for NIAM-modeller: Alle faktatyper i modellen skal være slik at alle setningsforekomster som passer i den, skal være elementære setninger Konsekvens: Ingen faktatype skal kunne erstattes av faktatyper som alle er kortere enn den opprinnelige faktatypen Merk: Siden vi i UML bare kan tegne binære setninger (assosiasjoner), er semantikkregelen automatisk oppfylt i -UML 1. mars 2006 INF2120 Prosjekt i modellering 22
Entydighetsskranker Person (navn) Eier Eies av Bil (reg.nr) Eva Nils Else Eva Per Hans Liv JC 24356 BC 77754 DJ 10765 KE 75643 AA 24680 BC 77754 DE 85975 Det som står under entydighetspilen, kan ikke gjentas 1. mars 2006 INF2120 Prosjekt i modellering 23
Eksempel: Ekteskap Kvinne (F.nr) er gift med er gift med Mann (F.nr) Hvor skal pilen(e) stå? Skriv forekomster! 1. mars 2006 INF2120 Prosjekt i modellering 24
Monogami Kvinne (F.nr) er gift med er gift med Mann (F.nr) Kvinne Fødselsnr{id} 0..1 0..1 er gift med er gift med Mann Fødselsnr{id} Én til én-faktatype 1. mars 2006 INF2120 Prosjekt i modellering 25
Polygyni Kvinne (F.nr) er gift med er gift med Mann (F.nr) Kvinne Fødselsnr{id} 0..* 0..1 er gift med er gift med Mann Fødselsnr{id} Mange til én-faktatype 1. mars 2006 INF2120 Prosjekt i modellering 26
Polyandri Kvinne (F.nr) er gift med er gift med Mann (F.nr) Kvinne Fødselsnr{id} 0..1 0..* er gift med er gift med Mann Fødselsnr{id} Én til mange-faktatype 1. mars 2006 INF2120 Prosjekt i modellering 27
Polygami Kvinne (F.nr) er gift med er gift med Mann (F.nr) Kvinne Fødselsnr{id} 0..* 0..* er gift med er gift med Mann Fødselsnr{id} Mange til mange-faktatype 1. mars 2006 INF2120 Prosjekt i modellering 28
Entydighet et enkelt eksempel (NIAM) En person kan ha ett navn, men ikke flere En person kan ha én eller flere telefoner, og en telefon kan være for én eller flere personer En person kan ha én eller flere biler, men hver bil kan bare ha én eier Person (F.nr) har med har på for for Navn (Navn) Tlf. (Tlfnr) Bil (Reg.- nr) 1. mars 2006 INF2120 Prosjekt i modellering 29
Entydighet et enkelt eksempel (-UML) En person kan ha ett navn, men ikke flere En person kan ha én eller flere telefoner, og en telefon kan være for én eller flere personer En person kan ha én eller flere biler, men hver bil kan bare ha én eier Person F.nr{id} har 0..* 0..* 0..* med for 0..1 har Navn 0..1 Navn{id} på 0..* for Tlf. Tlfnr{id} Bil Reg.- nr{id} 1. mars 2006 INF2120 Prosjekt i modellering 30
Påkrevd (=total) rolle (NIAM) Alle personer skal ha et navn har på Navn (Navn) Person (F.nr) med har for for Tlf. (Tlfnr) Bil (Reg.- nr) Alle forekomster av begrepet finnes i denne rollen 1. mars 2006 INF2120 Prosjekt i modellering 31
Påkrevd (=total) rolle (UML) Alle personer skal ha et navn Person F.nr{id} har 0..* 0..* 0..* med for 0..1 har Navn 1..1 Navn{id} på 0..* for Tlf. Tlfnr{id} Bil Reg.- nr{id} I UML angies påkrevde roller som minimumskardinalitet 1 1. mars 2006 INF2120 Prosjekt i modellering 32
Faktatypers aritet (lengde) (gjelder bare NIAM) Person er gift Unær faktatype (aritet=1) Person ansatt i med ansatt Firma Binær faktatype (aritet=2) ble ansatt i er ansettelsesdato med ansatt Ternær faktatype (aritet=3) Person Dag Firma 1. mars 2006 INF2120 Prosjekt i modellering 33
Entydighet i lange faktatyper ble målt ble målt ble resultat Temperaturen kan måles flere steder samtidig Tid Sted Temp. Den kan også måles flere ganger på samme sted På samme tidspunkt kan flere steder ha samme temperatur Samme sted kan ha samme temperatur på flere tidspunkt På samme tid og sted kan det bare være en temperatur 1. mars 2006 INF2120 Prosjekt i modellering 34
Regler for entydighetsskranker Alle faktatyper skal ha minst én entydighetsskranke Korte entydighetsskranker er strengere enn lange, så ingen entydighetsskranke får lov til totalt å dekke en annen Lange faktatyper kan godt ha overlappende entydighetsskranker 1. mars 2006 INF2120 Prosjekt i modellering 35
Overlappende entydighetsskranker Ble gift For giftermål Ble gift En kvinne kan ikke gifte seg flere ganger på samme dag Kvinne Dag Mann En mann kan ikke gifte seg flere ganger på samme dag En kvinne og en mann kan gifte seg med hverandre flere ganger Dette kan ikke uttrykkes i UML uten å bruke OCL 1. mars 2006 INF2120 Prosjekt i modellering 36
N-1 regelen for entydighetsskranker Gitt en setningstype med aritet N Hvis setningstypen er elementær, har den ingen entydighetsskranke som er kortere enn at den dekker N-1 roller Nesten alltid: Hvis setningstypen ikke har noen entydighetsskranke som dekker mindre enn N-1 roller, så er den elementær 1. mars 2006 INF2120 Prosjekt i modellering 37
Et eksempel til ettertanke Målte Meteorolog Ble målt Tid Ble målt Sted Ble resultat Temp. På sammetidogstedkan det bare være én temperatur En meteorolog kan ikke gjøre to temperaturmålinger på samme tidspunkt En meteorolog kan bare være ett sted på et gitt tidspunkt På sammetidogstedkan det bare være en meteorolog (?) NB: Denne faktatypen er ikke elementær. Problem: Hvordan skal den splittes? 1. mars 2006 INF2120 Prosjekt i modellering 38
Begrepsdannelse Måling Tid Ble målt Ble målt Sted Tid Ble målt på Måling på Ble målt Sted Hvilke skranker trengs for å gjøre denne konstruksjonen syntaktisk korrekt? 1. mars 2006 INF2120 Prosjekt i modellering 39
Kombinert entydighet Måling er definert som kombinasjonen av tid og sted Tid Ble målt på Måling på Ble målt Sted 1. mars 2006 INF2120 Prosjekt i modellering 40
To måter å tegne «måling» på Målte Ble målt Ble målt Ble resultat Meteorolog Tid Sted Temp. Tid Ble målt på Måling på Ble målt Sted Meteorolog Målte Ble målt av Med resultat Ble resultat Temp. 1. mars 2006 INF2120 Prosjekt i modellering 41
Kombinert entydighet i -UML Tid Dato{id} Klokke{id} Måling Sted 1 «identifying» 0..* 0..* «identifying» 1 Adr{id} Ble På På Ble målt målt Ved å markere de to setningene som «identifying» sier vi at representasjonstypene til Tid og Sted inngår i representasjonstypen for Måling (Her utgjør de hele representasjonstypen) Ved hjelp av denne konstruksjonen kan vi uttrykke lange faktatyper som en stereotypi i UML 1. mars 2006 INF2120 Prosjekt i modellering 42
Måling modellert i -UML versjon 1 Tid dato,klokkeslett {id} {unique} 1 {unique} Sted adresse {id} * 1 * Måling * 1 Meteorolog ansattnr {id} * 1 Temperatur C {id} 1. mars 2006 INF2120 Prosjekt i modellering 43
Måling modellert i -UML versjon 2 Tid dato,klokkeslett {id} Sted adresse {id} 1 «identifying» {unique} * 1 * Måling * 1 «identifying» * 1 Temperatur Meteorolog ansattnr {id} C {id} 1. mars 2006 INF2120 Prosjekt i modellering 44
NIAMs skrankeapparat Klassiske UML klassediagrammer har begrensninger i forhold til ORM/NIAM når det gjelder hvilke skranker som kan uttrykkes NIAM har følgende skranker som i UML må uttrykkes ved hjelp av OCL (Object Constraint Language): Påkrevde rollekombinasjoner Mengdeskranker Vi skal ta dem for oss og se på hvordan de tar seg ut i OCL-notasjon 1. mars 2006 INF2120 Prosjekt i modellering 45
Populasjoner for roller og begreper Roller er de eneste informasjonsbærerne i NIAM, dvs. at bare roller kan ha forekomster Mengden av forekomster i en rolle r kalles populasjonen til r og betegnes med pop(r) Begreper har egentlig ikke forekomster Det er likevel praktisk å snakke om populasjonen til begreper Vi definerer populasjonen til et begrep A som pop(a) = U pop(r) der unionen tas over alle roller som spilles av begrepet A 1. mars 2006 INF2120 Prosjekt i modellering 46
Påkrevde roller Repetisjon: Vi sier at en rolle r for begrepet A er påkrevd (mandatory) hvis det for alle tilstander av databasen skal gjelde at pop(a) = pop(r) A V r Påkrevde roller utrykkes i UML ved å ha minimumskardinalitet > 0 Påkrevde roller kalles også for totale roller 1. mars 2006 INF2120 Prosjekt i modellering 47
Påkrevd rollekombinasjon pop(bil) = pop(er privatbil for) U pop(er firmabil for) Bil (Reg.nr) er privatbil for T eier Person (F.nr) er firmabil for eier Firma (foretaksnr) En bil må være enten firmabil eller privateid (eller begge deler) 1. mars 2006 INF2120 Prosjekt i modellering 48
Påkrevd rollekombinasjon i UML Dette angis med OCL-symbolet {or} mellom to roller * Bil reg.nr {id} er privatbil for {or} eier 0..1 * 0..1 er firmabil for eier Person f.nr {id} Firma foretaksnr {id} En bil må være enten firmabil eller privateid (eller begge deler) 1. mars 2006 INF2120 Prosjekt i modellering 49
Mengdeskranker Mengdeskrankene (set-comparison constraints) begrenser mengden av forekomster i en eller flere roller i forhold til forekomstene i andre roller Mengdeskranker finnes i følgende varianter: Delmengdeskranke (Subset constraint) Likhetsskranke (Equality constraint) Ulikhetsskranke (Exclusion constraint) 1. mars 2006 INF2120 Prosjekt i modellering 50
Delmengdeskranken Person r 1 pop(r 1 ) pop(r 2 ) r 2 Den kalles også «først siden» Pilen peker mot «først»-rollen (r 1 ) 1. mars 2006 INF2120 Prosjekt i modellering 51
Delmengdeskranken, eksempel, OCL og NIAM * Ansatt ans.nr {id} mottar Ansatt (ans.nr) {subset} mottar mnd.lønn er mnd.lønn Penger (NOK) Penger NOK {id} 0..1 * 0..1 har er bonus har bonus En ansatt kan ikke ha bonus uten å motta månedslønn 1. mars 2006 INF2120 Prosjekt i modellering 52
Delmengdeskranke over en eller flere roller I 1 Person pnavn {id} skytter {subset} død bjørn * Bjørn bnavn {id} * skinnselger bjørneskinn * skytter død bjørn Person Bjørn skinnselgerbjørneskinn Selg ikke skinnet før bjørnen er skutt! 1. mars 2006 INF2120 Prosjekt i modellering 53
Delmengdeskranke over en eller flere roller II 1 Person pnavn {id} skytter {subset} død bjørn * Bjørn bnavn {id} * skinnselger bjørneskinn * skytter død bjørn Person Bjørn skinnselgerbjørneskinn Selg ikke bjørneskinn før du har skutt en bjørn! 1. mars 2006 INF2120 Prosjekt i modellering 54
Delmengdeskranke over en eller flere roller III 1 Person pnavn {id} skytter {subset} død bjørn * Bjørn bnavn {id} OBS! 1 skinnselger bjørneskinn * skytter død bjørn Person Bjørn skinnselgerbjørneskinn Selg ikke skinnet før bjørnen er skutt! (Skutt av deg!) 1. mars 2006 INF2120 Prosjekt i modellering 55
Mengdelikhetsskranken pop(r1) = pop(r2) for alle tilstander Person (F.nr) r 1 = r 2 1. mars 2006 INF2120 Prosjekt i modellering 56
Mengdelikhetsskranken, eksempel Ansatt (ans.nr) = bruttolønn skatt Penger (NOK) En ansatt betaler skatt hvis, og bare hvis, hun eller han mottar lønn 1. mars 2006 INF2120 Prosjekt i modellering 57
Likhetsskranken i OCL * Ansatt mottar {subset} bruttolønn Penger ans.nr {id} {subset} NOK {id} * 0..1 har skatt En likhetsskranke er det samme som å ha to delmengdeskranker som går i hver sin retning 0..1 Dette kan vi utnytte i OCL 1. mars 2006 INF2120 Prosjekt i modellering 58
Mengdeulikhetsskranken r 1 Person pop(r 1 ) pop(r 2 )= r 2 Mengdeulikhetsskranken kan kombineres med en kombinert påkrevd rolle for å definere en partisjon: Person r 1 r 2 T 1. mars 2006 INF2120 Prosjekt i modellering 59
Mengdeulikhetsskranken, eksempel Avdeling (avdnavn) ans.avd V Ansatt (ans.nr) mnd.lønn timelønn Penger (NOK) 1. mars 2006 INF2120 Prosjekt i modellering 60
Mengdeulikhetsskranke over en eller flere roller Person sager Gren Person sager Gren sitter sitter Person sager Gren Sag ikke av den grenen du sitter på! sitter 1. mars 2006 INF2120 Prosjekt i modellering 61
Den generelle mengdeulikhetsskranken 1 k n 1 m n k m pop(r k ) pop(r m )= A (a) r 1 r 2 B 1 (b 1 ) B 2 (b 2 ) Hvorfor har vi ikke noe tilsvarende for mengdelikhet? r n B n (b n ) 1. mars 2006 INF2120 Prosjekt i modellering 62
Ulikhetsskranker og UML Det er ikke vanskelig å uttrykke ulikhetsskranker som regler i OCL Warmer og Kleppe har imidlertid ikke foreslått noe eget symbol for dette Det er selvfølgelig lett å gjøre det, men jeg har valgt å begrense meg til de symboler som Warmer og Kleppe har introdusert Dermed kan vi ikke pr i dag tegne inn ulikhetsskranker i våre UML klassediagrammer 1. mars 2006 INF2120 Prosjekt i modellering 63
Underbegreper (Subtypes) Noen biler er lastebiler Vekt (kg) for veier V Bil (Reg.nr) V reg_år registrert År (årstall) maxlast frakter V Lastebil V plan lasteplan Areal (m 2 ) 1. mars 2006 INF2120 Prosjekt i modellering 64
Delmengdeskranke eller underbegrep? Ansatt (ans.nr.) lønn Beløp (NOK) selger bonus Ansatt (ans.nr.) Selger V lønn bonus Beløp (NOK) Er det å være selger en permanent tilstand? 1. mars 2006 INF2120 Prosjekt i modellering 65
Sammenligning av det dataorienterte og det objektorienterte perspektivet I det dataorienterte perspektivet interesserer vi oss for faktaopplysninger av statisk natur om interesseområdet, samt skranker som forhindrer registrering av åpenbart uriktige fakta I det objektorienterte perspektivet interesserer vi oss for virkelige og tenkte objekter i interesse-området, og hvordan disse objektene gjennom samarbeide kan gi en hensiktsmessig modell Men har ikke disse to perspektivene svært lite felles? 1. mars 2006 INF2120 Prosjekt i modellering 66
Ekvivalente stier Båt båtnavn {id} 1 dato {id} Dag * Køye køyenr {id} {Køyeplass.køye.båt = Køyeplass.avgang.båt} avgang båt dag passasjer Avgang 1 * * 1 «identifying» «identifying» 1 «identifying» «identifying» * «identifying» * * Køyeplass 1 1 køye båt KH 06 0601 KH 312 pnr100 CF 06 0601 CF 312 pnr109 KH 06 0601 KH 314 pnr115 KH 06 0602 KH 312 pnr217 Passasjer passasjernr {id} 1. mars 2006 INF2120 Prosjekt i modellering 67
Dataorientering vs. objektorientering I Både datasentrerte og objektorienterte informasjonssystemer inneholder data, men måten data er organisert på, er forskjellig I datasentrerte systemer er alle data samlet i en sentral ressurs databasen 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 Dataene gis «evig liv» ved å gjøre objektene «persistente» Dette kan realiseres på flere måter, f.eks. ved hjelp av en OO-database 1. mars 2006 INF2120 Prosjekt i modellering 68
Dataorientering vs. objektorientering II NIAM/ORM er i utgangspunktet (nesten) nøytral overfor hvilket perspektiv som velges Perspektivet kommer inn når de elementære faktatypene skal grupperes til en relasjonsdatabase eller inn i objektklasser Det finnes en algoritme som omformer ethvert syntaktisk lovlig NIAM-diagram til et optimalt normalisert relasjonsdatabaseskjema En tilsvarende algoritme for design av objektklasser finnes ikke, så her må vi ha tilleggsinformasjon (som andre diagramtyper i UML) for å få et best mulig resultat Det finnes riktig nok en algoritme som omformer et NIAM-diagram (og da spesielt et -UML klassediagram) til et (ordinært) UML klassediagram, men vi har ingen garanti for at dette diagrammet gir den optimale datastrukturen for vår anvendelse 1. mars 2006 INF2120 Prosjekt i modellering 69
Andre relevante forskjeller I OO har vi ikke bare mengde, men også «bag» og «list» krav om entydighetsskranke faller bort forekomstene kan ordnes I OO kan strukturer som «set», «bag» og «list», samt generelle objekter, brukes som verdier ubegrenset 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) begreper behøver ikke alltid ha en representasjon 1. mars 2006 INF2120 Prosjekt i modellering 70
Sterke sider ved ORM/NIAM ORM har et sterkere skrankeapparat enn det UML klassediagrammer har Men med innføring av stereotypien og de nye OCLsymbolene er ikke forskjellen vesentlig Et ORM-diagram kan trivielt oversettes til en mengde med elementære faktatyper (dette gjelder også skrankene) Det er vanligvis lett for brukerne å avgjøre om en elementær faktatype er riktig eller gal En slik oversettelse av strukturdiagrammet til naturlig språk bør brukes for å fomidle datamodellen til brukerne Brukere kan ikke forventes å fullt ut forstå UML klassediagrammer, men de bør kunne verifisere at en samling elementære setningstyper er korrekt 1. mars 2006 INF2120 Prosjekt i modellering 71