De generelle modelregler vedrører udformning af datamodellen. Formålet med reglerne er at sikre det niveau af ensartethed i domænemodellerne med hensyn til diagrammering, som er nødvendigt for at kunne etablere en samlet Grunddatamodel.

5.1 Modeller skal udarbejdes som UML-klassediagrammer

Regel

Datamodeller for Grunddata skal beskrives i UML (Unified Modeling Language) version 2.4.1 som UML-klassediagrammer.

Rationale

En samlet og sammenhængende model forudsætter anvendelsen af et fælles modelleringssprog. UML er valgt, fordi det er et internationalt anerkendt modelleringssprog, hvor den overordnede forståelse af måden at relatere elementer til hinanden er fastlagt.

Implikationer

Der skal for alle grunddata udarbejdes UML-klassediagrammer med klasser, attributter, relationer og kardinaliteter samt tilhørende dokumentation. Der er krav om attributkomplethed, således at al den information, der udstilles som Grunddata, skal kunne findes i Grunddatamodellen.

Der henvises til uml.org for yderligere information. Almene UML symboler og notationer forklares ikke yderligere i dette dokument.

5.2 UML-modellen skal organiseres i pakker

Regel

UML-modellen skal organiseres i pakker, med en pakke for hvert forretningsdomæne.

Rationale

En logisk organisering af modellens elementer i pakker gør det mere overskueligt at navngive og referere til elementer.

Implikationer

Hver domænemodel placeres i en UML-pakke. En pakke kan have underpakker. Hvor det er relevant, gøres elementer offentlige (‘public’), således at elementer i andre pakker kan referere til dem. Grunddatasekretariatet sørger desuden for, at der kan refereres til UML-pakker med elementer, som indgår i generelle egenskaber (se kapitel 6), samt til pakker udviklet af ISO, for eksempel standardiserede datatyper (se regel 5.5). Se endvidere fodnote til afsnit 2.1

5.3 Modelentiteter skal genbruges

Regel

Modelentiteter skal genbruges på tværs af Grunddatamodellen.

Rationale

Det er en forudsætning for grunddataprogrammet, at modelentiteter genbruges på tværs af grunddata for at sikre sammenhæng og undgå redundant vedligehold af data.

Implikationer

Som modelansvarlig skal man modellere modelentiteterne for sit eget forretningsdomæne samt sørge for at relatere til modelentiteter i andre forretningsdomæners UML-pakker. Se endvidere fodnote til afsnit 2.1

Eksempler

Hvis for eksempel person-domænet har behov for at modellere “Adresse”, skal modelleringen referere/genbruge («use») den korrekte modelentitet inden for Adresse-domænet

Figur 5 - Pakken “Person” anvender («use») pakkerne “Adresse” og “Date and Time” (fra ISO/TC 211 Harmonized Model) for at anvende klasserne Postadresse og DateTime.

5.4 Attributter og relationer skal modelleres fyldestgørende

Regel

Attributter og relationer mellem UML-elementer skal modelleres fyldestgørende - det vil sige, at attributter modelleres med multiplicitet og datatype, relationer modelleres med multiplicitet, retning og roller.

Rationale

For at modellen skal være entydig samt danne basis for semantisk forståelse af data, er det nødvendigt, at attributterne og relationerne er beskrevet grundigt.

Implikationer

Attributter skal modelleres med en eksplicit type - se regel 5.5 Standardiserede datatyper skal genbruges - samt med multiplicitet det vil sige antalsregler for, hvor mange værdier attributten kan rumme på en enkelt instans af klassen. Relationer (andre end generalisering/specialisering) mellem UML-elementer (associationer, kompositioner, aggregeringer) skal modelleres med navn, læseretning, navigabilitet, navngiven rolle/relations-ende samt multiplicitet (multiplicitet skal ikke angives for generalisering/specialisering). Se endvidere fodnote til afsnit 2.3

Eksempler

På figuren ses hvordan roller, læseretning, navigabilitet og multiplicitet udtrykker en kompleks association mellem to dataobjekter, som ellers ikke vil kunne kommunikeres i regi af modellen.

5.5 Standardiserede datatyper skal genbruges

Regel

Alle attributter skal enten tildeles en standardiseret datatype eller en datatype, der er modelleret som et UML-element i samme eller en anden pakke.

Ved brug af en standardiseret datatype skal der henvises til ISO 19103, hvor en række standardiserede datatyper er samlet og modelleret i UML. ISO 19107 anvendes til geografi.

Rationale

ISO giver en anerkendt ramme for standardiserede datatyper. Anvendelse af en standard for datatyper gør det nemmere at bygge snitflader, der udstiller Grunddata som nemt anvendelige
services.

Implikationer

Standardiserede datatyper i modellen skal hentes fra ISO/TC 211 Harmonized Model.

Denne er en samling af datatyper, som primært anvendes af geografi-relaterede modelleringsprojekter - fx INSPIRE. Ikke desto mindre indeholder ISO/TC 211 Harmonized Model også generelt anvendelige datatyper (CharacterString, Integer, DateTime med videre) modelleret som UML.

Hvis domænet ikke finder typerne i ISO/TC 211 Harmonized Model anvendelige, kan det opbygge sit eget typebibliotek, som skal publiceres sammen med domænemodellen.

ISO/TC 211 Harmonized Model findes frit tilgængelig på adressen https://github.com/ISO-TC211/HMMG, hvorfra den kan importeres i et modelleringsværktøj. Dokumentet “Modelleringsværktøj”, som Grunddatasekretariatet forventes at publicere, vil beskrive anvendelsen af ISO/TC 211 Harmonized Model i detaljer.

5.6 UML-stereotyper skal anvendes

Regel

Alle UML-elementer tildeles en UML-stereotype.

Rationale
På sigt skal det være muligt, at fortolke modellen til andre modeltyper samt fx datasnitflader. UML kan ikke i sig selv udpege elementernes rolle (modelentitet, datatype, enumeration)modellen, hvorfor det er nødvendigt, at udvide modellen med disse roller. UML-stereotyper er udvidelser af modelleringssproget, som gør det muligt at specificere yderligere egenskaber, samt at kategorisere model-elementerne. Med stereotyper kan man udpege specifikke klasser som havende bestemte roller i datamodellen, hvilket igen gør det muligt for et eksternt værktøj, at fortolke modellen til for eksempel datasnitflader og ontologier. Stereotyperne tilføjer roller til ementerne og strukturerer de tagged values, som indeholder dokumentationen af modelelementerne (se Note om tagged values).

Implikationer

Følgende stereotyper anvendes i Grunddatamodellen*:

• «DKObjekttype»: Alle forvaltningsobjekter skal modelleres som UML-klasser med stereotypen «DKObjekttype».

• «DKEnumeration», «DKKodeliste»,«DKKlassifikation»: Attributter med kodede værdier skal modelleres med UML-elementer med stereotyperne

• «DKEnumeration», «DKKodeliste» eller «DKKlassifikation», som værdisæt - se nedenstående NOTE om kodede værdier.

• «DKDatatype»: Attributter, som ikke er kodede værdier og som ikke tildeles en standardiseret datatype fra ISO (se regel 5.5) skal modelleres med en datatype i samme eller en anden pakke, med stereotypen «DKDatatype», som værdisæt. Se endvidere fodnote til afsnit 2.3

• «DKEgenskab»: Attributter og associationsender i Grunddatamodellen har stereotypen «DKEgenskab».

• «DKDomænemodel»: “Rod”-pakken i en afleveret domænemodel markeres med «DKDomænemodel»

Grunddatasekretariatet sørger for, at en UML-profil indeholdende stereotyperne er specificeret. Se http://digitaliser.dk/group/2494445

NOTE om tagged values

NOTE om kodede værdier

* Modellen kan udvides med domæne-specifikke stereotyper ligesom Grunddata-stereotyperne kan extendes i domænet for eksempel geodatas DKFeaturetype, som extender DKObjekttype

5.7 Navngivningsregler skal følges

Regel

Elementer i UML-modellen skal navngives på ensartet vis i hele Grunddatamodellen. Navngivning skal være entydig inden for domænet - i praksis inden for UML-pakken.

Rationale

En ensartet navnekonvention giver datamodellen et ensartet udtryk og gør det nemmere at identificere og skelne de forskellige klasser af modelelementer fra hinanden.

Implikationer

Klasser og associationer skal navngives entydigt inden for deres pakke.

Klasser, attributter og associationer navngives efter følgende skema:

• Elementer som repræsenterer forvaltningsobjekter (med stereotypen «DKObjekttype»), som er datatyper («DKDatatype»), klassifikationer («DKKlassifikation»), enumerationer («DKEnumeration») eller kodelister («DKKodeliste») navngives med “UpperCamelCase” - det vil sige med stort begyndelsesbogstav i både første ord og alle efterfølgende ord i navnet og uden anvendelse af mellemrum i navnet.

• Attributter, associationer og relationsender navngives med “lowerCamelCase” - det vil sige med lille begyndelsesbogstav i første ord samt stort begyndelsesbogstav i alle efterfølgende ord i navnet og uden anvendelse af mellemrum i navnet *.

NOTE

*Hvor navnene består af akronymer kan man fravige denne regel; for eksempel “NUTS1værdi”, “CPRnummer”

5.8 Sprogregler skal anvendes

Regel

Dansk skal anvendes ved navngivning af elementer, som indgår i generelle egenskaber.

Den modelansvarlige fastsætter det sprog, som anvendes ved navngivning af domænets elementer.

ISO-standarder følger deres engelske betegnelser (for eksempel “Integer” og “codeList”).

Datamodellen dokumenteres på dansk, se regel 5.9.

Rationale

Idet grunddata er det offentliges forvaltningsgrundlag, beskrives de som udgangspunkt på dansk, som er forvaltningssproget. Nogle grunddata kan imidlertid være underlagt internationale forpligtelser, som forudsætter brug af andre sprog. For eksempel er en række Grunddata omfattet af EUdirektivet INSPIRE, og skal som følge heraf genbruge UML-elementer, hvor sproget er engelsk. Det er derfor op til den modelansvarlige for domænet at træffe beslutning om sprog for domænespecifikke elementer.

Implikationer

Det er op til den modelansvarlige at vælge sprog for domænets elementer af modellen. Der kan derfor forekomme modeller, hvor der er en blanding af dansk og andre sprog.

5.9 Datamodellen skal dokumenteres

Regel

Datamodellen skal dokumenteres gennem beskrivelser af elementerne i UML-modellen.

Rationale

Dokumentationen gør det muligt for modellens brugere at forstå modellens elementer. Både når man udvikler og anvender modellen, er det essentielt at kommunikere og forstå betydningsindholdet af de enkelte dele af modellen. Det at dokumentationen er indlejret i datamodellen muliggør automatisk dannelse af et katalog over klasser, attributter og relationer. Yderligere kan dokumentationen indgå i datasnitfladerne, hvis der er ønske herom.

Implikationer

Modellens klasser og deres attributter beskriver forretningsobjekter og deres egenskaber, ligesom de roller, objekterne har i forhold til hinanden beskrives som roller/relationsender i hver ende af af en association. Disse forretningsobjekter, egenskaber og roller skal beskrives i
overensstemmelse med den begrebsmodellering, der er i domænet.

Dokumentation i UML med tagged values

Klasser, attributter og roller/relationsender dokumenteres ved brug af tagged values (se Note om tagged values), som specificeret i tabellen nedenfor. De enkelte tags i dokumentationen modsvarer i videst muligt omfang vidensmodelleringsvokabulariet SKOS. Denne strukturerede måde at dokumentere på, muliggør fleksibel generering af tekstdokumentation på baggrund af modellen, ligesom dokumentationen med stor præcision kan transformeres ind i datasnitflader og afledte modeller.

Værdierne angives i ren tekst

De tagged values, som nævnes i skemaet, er indeholdt i Grunddatamodellens stereotyper, som defineres i regel 5.6 UML-stereotyper skal anvendes.

Værktøjsunderstøttelse: I den MDG og base project, som distribueres af modelsekretariatet, er de relevante tagged values indføjet i stereotyperne i en separat gruppe - Grunddata:dokumentation - https://github.com/digst/grunddata-model-rules-tool-support

NOTE

5.10 Referencer til klassifikationer, forretningsmodeller og organisationsmodeller bør anvendes

Regel

Referencer til ekstern information bør så vidt muligt være referencer til publicerede klassifikationer, forretningsmodeller og organisationsmodeller.

Rationale

De fleste data-objekter skal relateres til klassifikationer og andre typer af strukturer, for derved at give objektet kontekst og sammenhæng. For at styrke genbrugelighed og fremfinding, bør disse referencer pege på eksisterende, publicerede og strukturerede datasæt, som for eksempel FORM. Tilsvarende kan det være relevant, at pege på specifikke organisatoriske enheder - disse kan med fordel genbruges fra publicerede organisationsmodeller. Se endvidere afsnit 3.3.

Der eksisterer ikke på nuværende tidspunkt en infrastruktur, som understøtter sådanne strukturerede data. Derfor kan det være nødvendigt - eventuelt som en migrationsstrategi - at give data sammenhæng på simplere måder - for eksempel med reference til en liste over organisatoriske enheder. På et senere tidspunkt kan sådanne lister så importeres i infrastruktur-komponenter, og referencerne tilpasses.

Implikationer

Området er under udvikling, så derfor kan der ikke opstilles en udtømmende implikation. På samme måde kan denne regel ikke entydigt specificere konkret modellering eller danne grundlag for udvikling af konkret infrastruktur.

Anbefalinger: