Språk for dataorientert modellering Hva forvirrer studentene minst, ORM/NIAM eller UML-stereotyper? (Omkamp mellom «Rundinger» og «Firkanter») Ragnar Normann (med god støtte av Gerhard Skagestein) 1
Bakgrunn og problemstilling Ellen Munthe-Kaas og jeg har observert at våre bachelor-studenter har alt for dårlige forkunnskaper for å klare DBMS-kurset INF3100 Vi har derfor foreslått å gjenopplive INF114 i en «light» versjon (10 studiepoeng mot 5 vekttall i INF114) Vi foreslår å begrense oss til relasjonsdatabaser og å kaste relasjonsalgebra og normaliseringsteori ut av kurset SQL gir seg selv som databasespråk det må våre studenter lære Vårt hovedproblem er valg av modelleringsspråk Sluttresultatet bør være et UML-klassediagram som er direkte oversettbart til et normalisert relasjonsdatabaseskjema Det er foreslått to veier dit: Bruk av ORM/NIAM som i INF114 Bruk av -UML, en UML-dialekt utviklet for INF1050 for å gi UML (tilnærmet) samme uttrykkskraft som ORM/NIAM 2
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 I sin lærebok for INF1050 har Gerhard Skagestein introdusert noen stereotypede UML-klasser for å gjøre det mulig å å gjøre en ORMaktig analyse med UML-syntaks Hensikten er å sørge for at UML klassediagrammer ikke er dårligere enn tidligere tiders datamodelleringsteknikker 3
NIAM en ORM-dialekt ORM Object-Role Modelling NIAM Natural language Information Analysis Methodology NIAM er den eldste ORM-dialekten Her skal vi bruke en revidert versjon av NIAM fra 1982 som vår ORM-dialekt og se hvordan denne kan uttrykkes i UML syntaks NIAM (og alle senere ORM-dialekter) er basert på naturlig språk En NIAM modell er en grafisk fremstilling av vanlige setninger som beskriver vårt interesseområde (UoD Universe of Discourse) 4
Entiteter og begreper En entitet er en gjenstand, egenskap eller hendelse i interesseområdet vårt I objektorientert modellering (som UML) modelleres entiteter som objekter én entitet svarer til ett objekt og omvendt 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) 5
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: er kan representeres med navn og/eller fødselsnummer Biler kan representeres med bilnummer eller chassisnummer 6
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 7
Begreper tegnet i NIAM og UML I NIAM tegnes begreper som heltrukne sirkler og representasjoner som stiplede sirkler Fødselsnr UML har i utgangspunktet ikke noe symbol for begreper Dette løser Gerhard med å definere en stereotypi med den egenskap at den ikke kan ha andre attributter enn sin representasjon («id») Fødselsnr {id} 8
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: 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 Fødselsnr {id} 9
Broer på kortform Siden rollene i broer er redundante, tillater NIAM oss å 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 Gerhards variant av UML, som vi heretter skal kalle -UML (Fødselsnr) tilsvarer Fødselsnr {id} 10
Faktatyper Det at personer eier biler, og at biler eies av personer, tegner vi slik: 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 -UML, ser det slik ut: 1 0..* eier er eid av Bil 11
Faktasetningers dype struktur eier eies av Bil med for med fødselsnummer 12094430256 eier bil med registreringsnummer CE76543 Bil med registreringsnummer CE76543 eies av person med fødselsnummer 12094430256 De to setningene har samme meningsinnhold, dvs. samme dype struktur med for Fødselsnr Reg.- nr 12
Dyp struktur tegnet med UML--klasser eier eies av Bil med for Slik ser samme setning ut i UML: Fødselsnr{id} 1 0..* eier er eid av Bil Reg.- nr{id} De to tegningene uttrykker akkurat det samme med for Fødselsnr Reg.- nr 13
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 14
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 15
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 (F.nr) har med har på for for Navn (Navn) Tlf. (Tlfnr) Bil (Reg.- nr) 16
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 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} 17
Påkrevd (=total) rolle (NIAM) Alle personer skal ha et navn har på Navn (Navn) (F.nr) med for Tlf. (Tlfnr) har for Bil (Reg.- nr) Alle forekomster av begrepet finnes i denne rollen 18
Påkrevd (=total) rolle (UML) Alle personer skal ha et navn F.nr{id} har 0..* 0..* 0..* med for Navn 1..1 Navn{id} på Tlf. Tlfnr{id} 0..1 har 0..* for Bil Reg.- nr{id} I UML angies påkrevde roller som minimumskardinalitet 1 19
Faktatypers aritet (lengde) (gjelder bare NIAM) er gift Unær faktatype (aritet=1) ansatt i med ansatt Firma Binær faktatype (aritet=2) ble ansatt i er ansettelsesdato med ansatt Ternær faktatype (aritet=3) Dag Firma 20
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 21
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 22
Målte Meteorolog NB: Ble målt Tid Denne faktatypen er ikke elementær. Problem: Hvordan skal den splittes? Et eksempel til ettertanke 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 (ansvarlig) meteorolog 23
Begrepsdannelse og kombinert entydighet Måling Tid Ble målt Ble målt Sted Tid Ble målt på Måling på Ble målt Sted Måling er definert som kombinasjonen av tid og sted 24
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. 25
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 26
Måling modellert i -UML versjon 1 Tid dato,klokkeslett {id} {unique} 1 {unique} Sted adresse {id} * 1 * Måling * 1 * 1 Temperatur C {id} Meteorolog ansattnr {id} 27
Måling modellert i -UML versjon 2 Tid dato,klokkeslett {id} Sted adresse {id} 1 «identifying» {unique} * 1 * Måling * 1 «identifying» * 1 Temperatur C {id} Meteorolog ansattnr {id} 28
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 29
Påkrevd rollekombinasjon Bil (Reg.nr) er privatbil for T er firmabil for eier eier (F.nr) Firma (foretaksnr) En bil må være enten firmabil eller privateid (eller begge deler) 30
Påkrevd rollekombinasjon i UML Dette angis med OCL-symbolet {or} mellom to roller * er privatbil for eier 0..1 f.nr {id} Bil reg.nr {id} {or} * 0..1 er firmabil for eier Firma foretaksnr {id} En bil må være enten firmabil eller privateid (eller begge deler) 31
Delmengdeskranken, eksempel, OCL og NIAM * Ansatt ans.nr {id} mottar {subset} er mnd.lønn Penger NOK {id} 0..1 * 0..1 har er bonus Ansatt (ans.nr) mottar mnd.lønn Penger (NOK) har bonus En ansatt kan ikke ha bonus uten å motta månedslønn 32
Delmengdeskranke over en eller flere roller I 1 pnavn {id} skytter {subset} død bjørn * Bjørn bnavn {id} * skinnselger bjørneskinn * skytter død bjørn Bjørn skinnselgerbjørneskinn Selg ikke skinnet før bjørnen er skutt! 33
Delmengdeskranke over en eller flere roller II 1 pnavn {id} skytter {subset} død bjørn * Bjørn bnavn {id} * skinnselger bjørneskinn * skytter død bjørn Bjørn skinnselgerbjørneskinn Selg ikke bjørneskinn før du har skutt en bjørn! 34
Delmengdeskranke over en eller flere roller III 1 pnavn {id} 1 skytter {subset} død bjørn * Bjørn bnavn {id} * OBS! skinnselger bjørneskinn skytter død bjørn Bjørn skinnselgerbjørneskinn Selg ikke skinnet før bjørnen er skutt! (Skutt av deg!) 35
Mengdelikhetsskranken, eksempel Ansatt (ans.nr) = bruttolønn skatt Penger (NOK) En ansatt betaler skatt hvis, og bare hvis, hun eller han mottar lønn 36
Likhetsskranken i OCL * Ansatt mottar {subset} bruttolønn 0..1 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 Dette kan vi utnytte i OCL 37
Mengdeulikhetsskranke over en eller flere roller sager sages av Gren sager sages av Gren sitter på med sitter på med sager sages av Gren Sag ikke av den grenen du sitter på! sitter på med 38
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 Gerhard har valgt å begrense seg til de symboler som Warmer og Kleppe har introdusert Dermed kan vi ikke pr i dag tegne inn ulikhetsskranker i våre UML klassediagrammer 39
Realisering og kvalitetssikring 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 med mindre vi skal bruke det til design av en relasjonsdatabase Et NIAM-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 40
Konklusjon og spørsmål til debatt ORM/NIAM har i utgangspunktet et sterkere skrankeapparat enn det UML klassediagrammer har Men med innføring av stereotypien og de nye OCLsymbolene er ikke forskjellen vesentlig Selve metoden er den samme, men språkene er forskjellige Spørsmålet er: Hva vil forvirre studentene mest? Å innføre en ikke-standard stereotypi i UML og gjennomføre hele analysen ved utelukkende å bruke - klasser for så å omforme dette diagrammet til et standard UMLklassediagram Å ta i bruk et helt annet modelleringsspråk (ORM/NIAM) og bruke dette til å konstruere et standard UML-klassediagram Er det behov for dette kurset, og har vi ressurser til å holde det? Bør det i så fall gå parallelt med INF1050, eller bør det være et 2000-kurs? 41