Modelleringskoncept for grunddata

Transkript

1 Modelleringskoncept for grunddata Version: 0.9 Status: Udkast 1

2 Forord Modelleringskonceptet er udarbejdet som led i etableringen af grunddatamodellen: en fælles datamodel for alle grunddata. Etablering af grunddatamodellen omfatter en række andre produkter og leverancer, som modelleringskonceptet skal ses i sammenhæng med: Modelleringsværktøj Værktøj som understøtter etablering og vedligehold af grunddatamodellen i overensstemmelse med modelleringskonceptet. Ibrugtagningsplan Plan for ibrugtagning af modelleringskonceptet i hele grunddataprogrammet. Udstillingsplatform Platform for udstilling af grunddatamodellen for databrugere. Versioneringsregler Regler for versionering af grunddatamodellen. Governanceaftale Aftale om ejerskab og ansvar for grunddatamodellen. Grunddatamodellen skal indgå i den samlede dokumentation af grunddata, som også vil omfatte dokumentation fra Datafordeleren. 2

3 Versionshistorik Version Dato Status Bemærkninger Udkast Første udkast til generelle egenskaber på baggrund af drøftelser på workshops 14/1, 5/2 og 13/ Udkast Drøftelser på workshop 20/ skrevet ind Udkast Opsat disposition for hele modelleringskoncept, tilføjet indledning, disposition til kapitel om modelleringsregler, gennemskrivning af generelle egenskaber samt noter til manglende afsnit Udkast Drøftelse fra workshop 23/ indarbejdet. Revision af alle kapitler. Ny dokumentstruktur Udkast Indarbejdelse af de første kommentarer fra eksternt review (alle kapitler) Udkast Indarbejdelse af resterende kommentarer fra eksternt review (alle kapitler). Ændringer i kapitel 1, 2 og 3. Nye regler i kapitel 5. Kapitel 6 og 7 sammenlagt til nyt kapitel 6. Rettelser og uddybende beskrivelser i alle kapitler Udkast Indarbejdelse af kommentarer fra workshop 27/ Udkast Indarbejdelse af kommentarer fra møder med ERST og MBBL Udkast Klargjort til udsendelse til styregruppen. 3

4 Indholdsfortegnelse 1 INTRODUKTION FORMÅL Hvad betyder en samlet og sammenhængende grunddatamodel? Målsætninger Fordele MÅLGRUPPE GOVERNANCE OG VERSIONERINGSREGLER LÆSEVEJLEDNING Indhold Begreber Forkortelser UDESTÅENDER MODELLERINGSKONCEPTETS FOKUS OG AFGRÆNSNING GRUNDDATAMODELLEN BESTÅR AF DOMÆNEMODELLER MODEL FOR UDSTILLING AF GRUNDDATA INFORMATIONSMODEL OBJEKTNIVEAU AFGRÆNSNING ARKITEKTURMÆSSIGE FORUDSÆTNINGER EKSISTERENDE STANDARDER DATAFORDELEREN DEN FÆLLESKOMMUNALE RAMMEARKITEKTUR Organisationskomponent Klassifikationskomponent Beskedfordeler/ Beskeddrevet arkitektur ANVENDELSE AF REGLER REGLERNE ER ENTEN KRAV ELLER ANBEFALINGER REGLERNE KAN UDBYGGES INDEN FOR FORRETNINGSDOMÆNERNE MØNSTER FOR REGLER GENERELLE MODELLERINGSREGLER DATAMODELLER SKAL UDARBEJDES SOM UML-KLASSEDIAGRAMMER UML-MODELLEN SKAL ORGANISERES I PAKKER ENTITETER SKAL GENBRUGES UML-RELATIONER SKAL MODELLERES FYLDESTGØRENDE STANDARDISEREDE DATATYPER FRA ISO SKAL GENBRUGES UML-STEREOTYPER SKAL ANVENDES NAVNGIVNINGSREGLER SKAL FØLGES SPROGREGLER SKAL ANVENDES DATAMODELLEN SKAL DOKUMENTERES REFERENCER TIL KLASSIFIKATIONER, REFERENCEMODELLER OG ORGANISATIONSMODELLER BØR ANVENDES REGLER OM GENERELLE EGENSKABER

5 6.1 ALLE ENTITETER SKAL MODELLERES MED EN PERSISTENT, UNIK NØGLE ALLE ENTITETER SKAL MODELLERES MED STATUS ALLE ENTITETER SKAL UNDERSTØTTE DOBBELTHISTORIK OG ANGIVELSE AF AKTØR ALLE ENTITETER BØR UNDERSTØTTE BESKEDFORDELING REFERENCER BILAG 1: TABELOVERSIGT OVER REGLER BILAG 2: TABELOVERSIGT OVER GENERELLE EGENSKABER BILAG 3: DOKUMENTATION AF DATAMODELLEN BILAG 4: EKSEMPEL PÅ ENTITET

6 1 Introduktion 1.1 Formål Grunddataprogrammet er igangsat med visionen om, at offentlige grunddata om personer, virksomheder, ejendomme, adresser og geografiske forhold opdateres ét sted og anvendes af alle. En mere detaljeret baggrund for grunddataprogrammet kan findes her [Grunddataprogrammet]. Figur 1 Konceptuelt overblik over grunddataprogrammet De offentlige grunddata bliver vedligeholdt og anvendt af flere forskellige myndigheder, og der er derfor behov for at tænke data sammen i en model, så man kan sikre et samlet overblik og på den måde undgå redundant vedligehold af data. Grunddataprogrammet indeholder forskellige forretningsdomæner, der er relateret til hinanden og på visse områder overlappende. For at kunne skabe en datamodel for grunddata, der fremstår som sammenhængende for interessenterne er det vigtigt at sikre, at man har en fælles tilgang til modelleringsopgaven. Modelleringskonceptet sikrer, at modelleringen af dataentiteter sker ud fra et fælles sæt retningslinjer, og at hele modellen bygger på fælles grundegenskaber. Formålet med modelleringskonceptet for grunddatamodellen er derfor at sikre en samlet og sammenhængende grunddatamodel i et distribueret forvaltningsmiljø. 6

7 Figur 2 Overblik over forretningsdomæner i grunddata baseret på [Begrebsmodel version 0.8] fra Et forretningsdomæne er fx Virksomhed. Den korrekte afgrænsning af forretningsdomæner defineres af grunddataforvalterne Hvad betyder en samlet og sammenhængende grunddatamodel? Vi ønsker at give slutbrugerne (myndigheder, virksomheder og privatpersoner) en samlet og sammenhængende datamodel. Det betyder, at man som bruger oplever relationel integritet på tværs af forretningsdomænerne, og at man oplever ensartet begrebsanvendelse samt ensartede modelleringsregler og generelle egenskaber for entiteterne i grunddatamodellen. Denne oplevelse opretholdes og vedligeholdes på trods af, at data i modellen vedligeholdes af forskellige myndigheder Målsætninger Det primære mål med modelleringskonceptet er at skabe den fælles tilgang til at modellere grunddata, som er nødvendig for at kunne skabe en samlet og sammenhængende datamodel. Konkret skal modelleringskonceptet opfylde følgende målsætninger: Modelleringskonceptet skal danne grundlag for ensartet modellering af grunddata. Modelleringskonceptet skal sikre det nødvendige abstraktionsniveau til at imødekomme alle interessenters behov. Modelleringskonceptet skal sikre genbrug af allerede eksisterende standarder, hvor det er muligt. 7

8 Modelleringskonceptet skal gøre det nemt for databrugere at bygge applikationer, der bruger grunddata, og at stille ensartede forespørgsler på tværs af grunddata Fordele Ved at anvende et fælles modelleringskoncept opnår man som grunddatamyndighed en række fordele: Det er nemmere at sikre fælles retningslinjer for datamodellering internt i organisationen. Datamodellen går på tværs af alle forretningsdomæner og giver dermed mulighed for genbrug af data. Det bliver nemmere at udveksle dataobjekter. Det bliver nemmere at sikre en høj datakvalitet. Der vil være mindre begrebsforvirring. Der vil i mindre grad være redundant data på tværs af forretningsdomænerne. 1.2 Målgruppe Modelleringskonceptet har fire primære interessenter: Databrugere Databrugere er de slutbrugere, der gennem grunddataprogrammets anvendelse af modelleringskonceptet vil opleve, at de får en samlet, sammenhængende og effektiv måde at tilgå og anvende grunddata på. Dataejer Dataejerne sidder i de enkelte registermyndigheder, der opbevarer, vedligeholder og udstiller grunddata. Dataejerne har stor interesse i en samlet, sammenhængende datamodel med mulighed for genbrug og effektiv governance. Modelleringskonceptet er en vigtig del af grundlaget for at realisere denne gevinst. Udviklere Udviklere skal her ses som de ledere og projektledere, forretningseksperter og systemleverandører hos såvel dataejere som databrugere, der skal levere løsninger i grunddataprogrammet til såvel udstilling som brug af data. De har en stærk interesse i et modelleringskoncept, der sikrer en samlet, sammenhængende datamodel. Denne gruppe vil have brug for, at den samlede datamodel kan præsenteres på flere forskellige abstraktionsniveauer: konceptuelt, logisk og fysisk. Datamodellører De datamodellører, der skal udforme grunddatamodellen gennem deres arbejde med modellering af forretningsdomænerne, er afhængige af, at modelleringskonceptet er entydigt, klart og og meningsgivende. 8

9 1.3 Governance og versioneringsregler Grunddatasekretariatet varetager vedligeholdelsen af modelleringskonceptet og indarbejder alle godkendte rettelser. Rettelser vedrørende fejl og mangler udføres af grunddatasekretariatet Hermed menes sproglige rettelser og rettelser som vedrører fejl og mangler, som ikke har væsentlige it-mæssige konsekvenser, og som ikke har økonomiske konsekvenser for dataejere og - brugere. Eksempelvis: o Mindre tekst- og figurrettelser som har til formål at rette op på fejl eller misforståelser. o Omformulering af tekst eller forståelsesmæssig uddybning af regler og krav. Grunddatasekretariatet udfører rettelser af fejl og mangler Udgivelseskode lig med Mindre ændringer skal godkendes af styregruppen 1 Hermed menes ændringer, som fordrer ingen eller begrænsede justeringer af it-systemer, og som ikke har større økonomiske konsekvenser for dataejere og -brugere. Eksempelvis: o Mindre justeringer af modelleringsregler eller generelle egenskaber med henblik på forbedret implementering eller brug. Grunddatasekretariatet indstiller mindre ændringer til styregruppen. Udgivelseskode lig med Større ændringer skal godkendes af grunddatabestyrelsen Hermed menes ændringer, som fordrer større justeringer af it-systemer eller/og har økonomiske konsekvenser for dataejere og -brugere. Eksempelvis: o Ændringer i modelleringskonceptets scope. o Tilføjelse til, afskaffelse af eller omfattende ændringer i modelleringsregler eller generelle egenskaber. o Ændringer i konceptets struktur og opbygning. Styregruppen indstiller større ændringer til grunddatabestyrelsen. Udgivelseskode lig med Alle ændringer publiceres på Digitaliseringsstyrelsens hjemmeside. 1 Styregruppen for delprogram 7 i grunddataprogrammet. 9

10 1.4 Læsevejledning Indhold Modelleringskonceptet har følgende indhold: Kapitel 2 - Modelleringskonceptets fokus og afgrænsning Her beskrives fokus og afgrænsning for grunddatamodellen og modelleringskonceptet. Kapitel 3 - Arkitekturmæssige forudsætninger Her beskrives de arkitektur - og infrastrukturmæssige forhold, som har indflydelse på udformningen af modelleringskonceptet. Kapitel 4 - Anvendelse af regler Her forklares, hvordan modelleringskonceptets regler er bygget op, og hvordan de skal efterkommes. Selve reglerne følger i kapitel 5 og 6. Kapitel 5 - Generelle modelleringsregler I dette kapitel opstilles generelle modelleringsregler, som har fokus på datamodellens udformning og vedrører diagrammering. Her opstilles regler for fx modelleringssprog, navngivning af elementer, sprog og dokumentation mv. Kapitel 6 - Regler for generelle egenskaber I dette kapitel opstilles regler, som har fokus på indhold i datamodellen, og som sætter rammer for dataindhold i forretningsobjekterne. Her opstilles regler med betydning for fx forretningsobjekters identifikation og historik. Reglerne udmøntes i specificering af generelle egenskaber for alle entiteter. Kapitel 7 - Referencer Referencer i teksten angives med klammer: [...] og refererer til kapitel 7. Til hjælp for det praktiske modelleringsarbejde er følgende bilag vedlagt: Bilag 1 - Tabeloversigt over regler I bilag 1 gives i tabelform et resumé af alle regler fra kapitel 5 og 6. Tabellen kan bruges som huskeseddel i forbindelse med udarbejdelse af en datamodel. Bilag 2 - Tabeloversigt over generelle egenskaber I bilag 2 gives i tabelform en oversigt over de generelle egenskaber fra kapitel 6. Tabellen kan bruges som huskeseddel i forbindelse med systemdesign. Bilag 3 - Dokumentation af datamodellen I bilag 3 gives en oversigt over, hvordan datamodellen skal dokumenteres. Bilaget er en uddybning af regel 5.9. Oversigten kan bruges som huskeseddel i forbindelse med dokumentation af datamodellen. 10

11 1.4.2 Begreber Begreb Begrebsmodel Beskedfordeler Datafordeleren Datahændelse Dataobjekt Datasnitflader Domænemodel Entitet Forretningshændelse Forretningsobjekt Grunddatamodellen Informationsmodel Klassifikationskomponent Modelansvarlig Organisationskomponent Beskrivelse Giver et overblik over data på et højere abstraktionsniveau end en Informationsmodel. Se fx [Begrebsmodel version 0.8]. Som led i den fælleskommunale rammearkitektur etableres en Beskedfordeler til udveksling af hændelsesbeskeder mellem systemer. Som led i grunddataprogrammet etableres en fællesoffentlig Datafordeler, som effektivt og stabilt distribuerer data fra grunddataregistrene. En ændring i data. Repræsenterer en konkret datainstans af en entitet. Et eksempel på et personobjekt kunne være Person( Jens Hansen, , ). Se også figur 3 herunder. De specifikationer (fx XML-Schema) som sætter rammer for dataformatet i en service. Datamodel for et forretningsdomæne (fx Adresse, Stednavn, Virksomhed ). Alle domænemodellerne tilsammen udgør grunddatamodellen. Repræsenterer modellering af en selvstændig helhed, en ting, et sted eller et fænomen, der kan beskrives enkelt og har tilknyttet oplysninger. F.eks. kan entiteten Person have tilknyttet følgende oplysninger: Navn, CPRnummer og Fødselsdato. Typisk bliver entiteter til en eller flere klasser i UMLmodellen. Se også figur 3 herunder. Begivenhed i virkeligheden, som har udløst en ændring i data. Repræsenterer et konkret - fysisk eller konceptuelt - eksisterende objekt (adresse, vandløb, virksomhed), som indgår i forvaltningen. Se definition her [Arkitekturguide forretningsobjekt]. Se også figur 3 herunder. Den samlede og sammenhængende datamodel for grunddata. Grunddatamodellen er sammensat af domænemodellerne. En informationsmodel beskriver al information i objekter, attributter, relationer og kardinaliteter. Informationsmodel er abstraktionsniveauet for grunddatamodellen. Se afsnit Den myndighed der til enhver tid har ejerskab og ansvar for domænemodellen. Se afsnit

12 Figur 3 - Illustration af forholdet mellem begreberne Forretningsobjekt, Entitet og Dataobjekt Forkortelser Forkortelse UML XML Beskrivelse Unified Modeling Language, Extensible Markup Language, Udeståender I forhold til denne version af modelleringskonceptet er der følgende udeståender: Eksempler på anvendelse af regler: Efter hver regel i kapitel 5 og 6 skal gives et eksempel på reglens anvendelse. Konkrete eksempler forventes tilvejebragt ved gennemførsel af et proof of concept inden udgivelse af version 1.0 af modelleringskonceptet. Bilag 3 om dokumentation skal kvalitetssikres. 12

13 2 Modelleringskonceptets fokus og afgrænsning Her beskrives modelleringskonceptets fokus og afgrænsning. 2.1 Grunddatamodellen består af domænemodeller Grunddatamodellen er sammensat af domænemodeller - dvs. datamodeller for alle forretningsdomænerne i grunddataprogammet (fx Person, Adresse, Virksomhed ). Se også figur 2. Hver domænemodel har en modelansvarlig - dvs. den grunddatamyndighed, som til enhver tid har ejerskab og ansvar for domænemodellen. Det er op til den modelansvarlige at fastlægge domænets omfang og afgrænsning. Den modelansvarlige har ansvaret for, at domænemodellen afspejler domænets data og er modelleret i overensstemmelse med forretningsbehovet samt i overensstemmelse med modelleringskonceptet. 2.2 Model for udstilling af grunddata Grunddatamodellen skal være modellen for udstilling af grunddata fra Datafordeleren. Modelleringskonceptets fokus er derfor på udstilling og kommunikation af grunddata over for databrugere, som skal hente data via Datafordeleren. Databrugere er både eksterne databrugere og de myndigheder, som deltager i grunddataprogrammet. Grunddatamyndighederne har forpligtet sig på at bruge hinandens data på tværs og vil dermed også trække data fra Datafordeleren. Grunddatamodellen vil dermed også udgøre det samlede programs overblik over og forståelse af grunddata. Modelleringskonceptet omfatter ikke datamodeller for lagring eller ajourføring af grunddata internt i grunddataregistrene. Modelleringskonceptet omfatter heller ikke datamodeller for lagring internt i Datafordeleren eller for dataflowet mellem grunddataregistre og Datafordeler. Bemærk dog, at modelleringsreglerne i kapitel 5 og 6 stiller krav til, at visse informationer er indeholdt i grunddata. 2.3 Informationsmodel Modelleringskonceptet har fokus på konceptuel/logisk informationsmodellering af de data, der udstilles som grunddata for databrugere. Se Arkitekturguiden for yderligere definition af logisk informationsmodellering: [Arkitekturguide informationsmodel]. Informationsmodellen skal beskrive al den information, der udstilles som grunddata. Et af perspektiverne med grunddatamodellen er en modeldrevet arkitektur, der samler vedligeholdelse af datamodeller og dokumentation et sted. Det betyder i denne sammenhæng, at informationsmodellen er den centrale datamodel, som vedligeholdes af den modelansvarlige. Ud fra informationsmodellen kan der udledes datamodeller på andre abstraktionsniveauer: begrebsmodel og datasnitflader. 13

14 Begrebsmodellen skal give et helt overordnet overblik over grunddata til brug for beslutningstagere samt til kommunikation, se fx [Begrebsmodel version 0.8]. Begrebsmodellen skal vedligeholdes sammen med informationsmodellen. Datasnitflader (forstået som fx fysiske skemaer i form af XML-Schema) har til formål at gøre datamodellen operationel for systemudviklere. Et af perspektiverne i modelleringskonceptet er at muliggøre automatisk generering af datasnitflader ud fra informationsmodellen. Se endvidere afsnit 3.2. Figur 4: Modelleringskonceptets fokus illustreret i forhold til OIO EA-reolen: Hovedfokus er på informationsmodellering på logisk niveau. Herudfra kan udledes henholdsvis begrebsmodel på konceptuelt niveau og datasnitflader på fysisk niveau. 2.4 Objektniveau Modelleringskonceptet fokuserer på modellering af forretningsobjekter, dvs. fx Person eller Adresse. Det betyder, at modelleringsregler, dokumentationskrav og generelle egenskaber gælder for grunddatamodellens entiteter. Der opstilles således ikke regler på datasætniveau. 2.5 Afgrænsning Modelleringskonceptet indeholder ikke krav til en bestemt fremgangsmåde for udarbejdelse af datamodeller. Informationsmodeller kan fx udvikles top-down ud fra en højniveau-model som fx en begrebsmodel, eller bottom-up fra en fysisk datamodel eller ved systematisk gennemgang af indholdet af det dataregister, der skal udstille data. Se fx vejledning her [OIO arbejdsmodellen]. 14

15 3 Arkitekturmæssige forudsætninger Grunddatamodellen har snitflader til andre projekter og komponenter i den fællesoffentlige it-arkitektur. Disse snitflader er med til at opsætte rammer og formål for, hvordan modellen bedst udformes. Den fælles it-arkitektur er ikke nødvendigvis fastlagt eller stabil, og på samme måde må reglerne for modellering af grunddatamodellen have et vist mål af dynamik for at kunne understøtte integration med den omkringliggende arkitektur. I det følgende gennemgås en række af de elementer i den fællesoffentlige it-arkitektur, som har en direkte indvirkning på modelleringsreglerne - primært for at danne referenceramme ved diskussion af formålet for de enkelte regler. For flere af elementerne gælder, at de ikke er færdigudviklede og i drift og dermed ikke udgør konkrete arkitekturkomponenter, som kan sætte præcise mål for grunddatamodelleringen. Derfor indeholder de følgende afsnit en række antagelser, som er blevet lagt til grund for udformningen af modelleringskonceptets regler. Antagelserne er baseret på dialog med de organisationer, som er ansvarlige for implementeringen af komponenterne, og er tilstræbt så tro mod intentionerne, som det har været muligt. Skulle antagelserne vise sig ikke at afspejle det fremtidige landskab, må det bevirke justering af modelleringsreglerne - naturligvis i overensstemmelse med versioneringsreglerne i afsnit Eksisterende standarder Ved udformningen af modelleringskonceptet er der lagt vægt på tilpasning til eksisterende internationale og nationale standarder med særligt fokus på INSPIRE, ISO og Sag og Dokument: INSPIRE: Flere grunddata er omfattet af EU s INSPIRE-direktiv [INSPIRE]. Modelleringskonceptet må derfor ikke opstille regler, som hindrer, at grunddata kan leve op til INSPIREs standarder og retningslinjer. Derudover har INSPIRE et velfunderet modelmæssigt grundlag baseret på bl.a. ISO-standarder, samt et velafprøvet metodemæssigt grundlag, hvor EU-medlemslandene har samarbejdet om udvikling af datamodeller for INSPIRE-data. Der er derfor lagt vægt på at genbruge INSPIREs standarder og retningslinjer hvor det giver værdi. Yderligere information om INSPIREs modelmæssige grundlag findes her [INSPIRE GCM]. ISO: Der er i modelleringskonceptet lagt vægt på genbrug af ISO standarder for bl.a. datatyper. Udover at ISO standarderne udgør en internationalt anerkendt referenceramme, har ISO også arbejdet med at modellere standarderne i UML, som er det valgte modelleringssprog for grunddatamodellen. På den måde stiller ISO et antal genbrugelige elementer til rådighed for domænernes modellører. Se regel 5.5 og regel 5.6. Sag og Dokument: Består af en række fællesoffentlige standarder på sag- og dokumentområde, som er udviklet med henblik på understøttelse af digitale arbejdsgange samt udveksling af informationer mellem organisationer [Sag og Dokument]. Standarderne omfatter bl.a. en specifikation af generelle egenskaber på sag- og dokumentområdet, se [S&D Generelle Egenskaber], som så vidt muligt er søgt genbrugt i modelleringskonceptets regler om generelle egenskaber i kapitel 6. Derudover anbefaler modelleringskonceptet også brugen af standarderne Klassifikation [Klassifikation] og Organisation [Organisation]. Se også afsnit

16 3.2 Datafordeleren Der etableres i regi af grunddataprogrammet en Datafordeler, som effektivt og sikkert skal distribuere data fra grunddataregistrene, læs mere her [Datafordeler]. Data, som tilgås via datafordeleren er også de data, som modelleres i grunddatamodellen. Da Datafordeleren endnu ikke er etableret, betyder det for modelleringsarbejdet, at der ikke kan opsættes regler for modelleringen, som direkte sigter til at understøtte en specifik servicesnitflade på Datafordeleren. Derimod må dette dokument basere sig på antagelser om, hvordan grunddatamodellen bedst understøtter dataadgang på Datafordeleren. Antagelser: Det antages, at datafordeleren på et tidspunkt vil kunne indgå i en modeldrevet arkitektur, hvor specifikationen af data håndteres i regi af modellen af data frem for i dokumentation, som er adskilt fra data. Det antages, at Datafordeleren vil kunne understøtte distribution af hændelsesbeskeder - at den vil udsende beskeder om datahændelser til en fremtidig beskeddrevet arkitektur [EDA]. Derfor indeholder modelleringskonceptet regler, som skal gøre det nemmere at konvertere de udviklede UML-modeller til andre typer datamodellering. I første runde sigtes der til, at gøre det muligt, at autogenerere XML-Schema på baggrund af UML-modellen. På den måde kan det på sigt gøres muligt, at udvikle grænseflader, hvor databrugere selv sammensætter udtræk og datasnitflader på baggrund af modellen. Autokonvertering af UML-modeller til XML-Schema foregår for eksempel i øjeblikket i regi af INSPIRE. Samtidig vil det være muligt, at omtolke UML-modellen til en RDF-graf, som kan danne udgangspunkt for en række forskellig repræsentationer af data, ligesom den kan bruges ved udstilling af grunddata i en Linked Data/Semantic Web sammenhæng. Yderligere indeholder modelleringskonceptet regler, som skal sikre, at data, der er nødvendige for at danne hændelsesbeskeder, er tilstede i grunddata. Se mere nedenfor. 3.3 Den Fælleskommunale Rammearkitektur I regi af KL og KOMBIT arbejdes der med, at implementere infrastrukturkomponenter som skal varetage generelle funktioner i forbindelse med opbevaring og udstilling af organisations-strukturer og andre typer af referencedata [Den fælleskommunale rammearkitektur]. Sammen med en beskedfordeler, er disse komponenter i udbud. Modellering og anvendelse af grunddata kan effektiviseres betydeligt ved, at anvende funktionalitet fra denne arkitektur, hvorfor modelleringskonceptets regler er udfærdiget med hensyntagen til nedenstående antagelser om komponenterne Organisationskomponent Standarderne for Sags- og dokumentområdet beskriver en logisk struktur for, hvordan en given organisations organisering kan udstilles i et generelt format, som tillader eksterne systemer at referere til dele eller helheder i organisationen [Organisation]. De refererbare aktører i organisationen kan være både specifikke (peron, it-system, funktion) eller overordnede (afsnit, kontor, organisation). Enkelte kommuner har allerede implementeret systemunderstøttelse for organisationskomponenten, og KOMBIT forbereder et udbud af en generelt anvendelig komponent [Den fælleskommunale rammearkitektur - støttesystemer]. Antagelser: Det antages, at organisationkomponenten bliver en permanent og entydig del af den offentlige it-arkitektur. 16

17 Det antages, at staten vil anvende en tilsvarene komponent til udstilling af organisation. Det antages, at organisationskomponenten vil have en service, hvorfra en specifik aktør kan hentes hvis man kende dens ident. Af disse grunde anbefaler reglerne i det følgende fx, at den aktør, som er ansvarlig for dataobjektets registrering i databasen og for dets virkning, lagres og udstilles som en reference til en organisation, udstillet i en organisationskomponent Klassifikationskomponent På samme måde planlægger KOMBIT [Den fælleskommunale rammearkitektur - støttesystemer] at den fælleskommunale rammearkitektur skal indeholde en klassifikationskomponent - også beskrevet i Sag & Dokument-standarderne [Klassifikation]. Klassifikationskomponenten skal opbevare og udstille strukturerere data - taksonomier og grafer - som afspejler forretningsviden, der har en intern struktur og kan bruges til at give forretningsobjekterne kontekst. Eksempler er FORM [FORM] og KLE [KLE], som er strukturerede beskrivelser af det offentliges forretning. I forbindelse med grunddata, kan de strukturerede data anvendes til at give forretnigsobjekterne kontekst og sammenhæng - fx angivelse af hvilket forretningsområde, data er opdateret af. Data, som opbevares i klassifikationskomponenten tildeles dobbelthistorik og revisionsspor, ligesom rammearkitekturen tilsigter distribution og opdatering af indholdet. Derfor er komponenten ideel til opbevaring af en lang række udfaldsrum - også simple lister. Antagelser: Det antages, at klassifikationskomponenten bliver en permanent og entydig del af den offentlige it-arkitektur. Det antages, at staten vil anvende en tilsvarene komponent til udstilling af strukturerede data. Det antages, at klassifikationskomponenten vil have en service, hvorfra en specifik klasse (forretningsområde, status) kan hentes hvis man kender dens ident. Af disse grunde anbefaler reglerne i det følgende fx, at et objekts forretningsområde, forretningsproces og forretningshændelse (se nedenfor), lagres og udstilles som en reference til strukturerede data, udstillet i en klassifikationskomponent.forretningsobjektets status kan også udstilles ved brug af klassifikationskomponenten Beskedfordeler/ Beskeddrevet arkitektur Formålet med beskedfordeling (se [EDA]) er, at kæde administrative processer sammen på tværs af myndigheder. Når en administrativ proces resulterer i en ændring i et dataobjekt, vil ændringen ofte udløse en række andre administrative processer - typisk hos en anden myndighed. Relevante myndigheder skal derfor adviseres om ændringen i dataobjektet. Beskeddrevet arkitektur handler om, at det skal være muligt for et brugersystem at abonnere på oplysninger om ændringer i dataobjekter - i form af en besked. Formålet er, at modtageren af beskeden, fx et IT-system eller en sagsbehandler kan reagere på beskeden og igangsætte administrative processer som følge heraf. Fx kan en ændring i en persons adresse udløse en ændret ydelse. 2 Dette forudsætter, at beskeder om ændringer i data kan distribueres på en meningsfuld måde, hvor det er muligt at opsætte filtre (abonnementer), som kan fordele beskeder til de relevante modtagere. 2 Effektiv Sagsbehandling og Kontrol [ESK] forudsætter en helt automatiseret løbende sagsbehandling, hvor en systemgenereret besked udløser en automatisk genberegning af fx en ydelse. 17

18 Indeholder beskeden kun oplysning om selve ændringen i dataobjektet, vil modtageren selv skulle analysere sig frem til, i hvilket omfang ændringen har relevans for modtagerens forretning. Ved en ændring af en persons adresse, er en sagsbehandler fx nødt til at vide, om ændringen skyldes, at personen faktisk er flyttet, eller der blot er tale om at vejen har fået nyt navn. Langt større kvalitet opnås derfor, hvis beskeden indeholder informationer om den forretningshændelse (i virkeligheden), som udløste ændringen samt om det forretningsområde og den forretningsproces, som har været involveret i ændringen i data. Derved kan beskeden fordeles til den relevante aktør og indgå i en relevant proces i modtagerorganisationen. En intelligent beskedfordeling forudsætter derfor, at disse informationer er til stede i den rigtige form, således, at de kan understøtte distributionen af beskeder. Antagelser: Det antages, at ændringer i grunddata skal afføde hændelsesbeskeder, som skal distribueres af Datafordeleren Det antages, at disse beskeder skal tilflyde den fælleskommunale rammearkitektur/serviceplatform Det antages, at der ikke for indeværende findes initiativer, som sigter til at sætte rammer for systematisering og udstilling af forretningskontekst for hændelser. Der gøres ingen antagelser om den infrastruktur, som skal udsende og modtage beskeder, hvorfor der ikke i dette dokument er yderligere behandling af teknisk protokol eller aftalegrundlaget for beskedfordeling. Derfor opsætter regel 6.4 en række forslag til, hvordan datamodellen kan understøtte systematisering og udstilling af egenskaber ved datahændelsen (forretningshændelse, -område og -proces) som kan understøtte intelligent beskedfordeling. 18

19 4 Anvendelse af regler Her forklares, hvordan modelleringskonceptets regler er opbygget, og hvordan de skal efterkommes. 4.1 Reglerne er enten krav eller anbefalinger Modelleringsregler specificeres som enten krav eller anbefalinger: Regler angivet med skal er krav, som skal efterkommes. Regler angivet med bør er anbefalinger, som bør efterkommes, men der er ikke krav herom. Se desuden bilag 1, som giver en oversigt over alle regler med angivelse af, om der er tale om krav eller anbefalinger. 4.2 Reglerne kan udbygges inden for forretningsdomænerne De modelansvarlige kan vælge at skærpe reglerne eller udbygge egenskaberne efter behov. Ligeledes kan de modelansvarlige have behov for at specificere yderligere regler eller egenskaber, som er gældende for det/de pågældende forretningsdomæne(r). Fx vil de grunddata, som er omfattet af INSPIRE direktivet skulle indeholde egenskaber, som er generelle for INSPIRE-data, men ikke for øvrige grunddata. 4.3 Mønster for regler Modelleringsregler bliver beskrevet efter følgende mønster: Navn Regel Rationale Implikation Angiver navnet på reglen Beskriver klart og præcist reglen Beskriver forretningsværdien ved at følge reglen Beskriver hvilken indvirkning reglen har på forretning og teknisk implementering Reglerne omhandler generelt den egentlige modellering - de udtaler sig om entiteterne, deres attributter, og modellen som sådan. Rationalet for reglen vil typisk være at finde i et argument omkring dataobjekterne - modelleringen skal sikre, at et specifikt dataindhold kan udstilles. Efter reglen vil der i nogle tilfælde være et kort praktisk eksempel, der viser, hvordan man kan anvende reglen. 19

20 5 Generelle modelleringsregler De generelle modelleringsregler 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 Datamodeller skal udarbejdes som UML-klassediagrammer Regel Datamodeller for grunddata skal beskrives i UML (Unified Modeling Language) som UMLklassediagrammer. 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. Implikation 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] 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. Implikation 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. Se reglen uddybet i [INSPIRE GCM] afsnit 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 med udviklet af ISO, fx standardiserede datatyper (se regel 5.5). 20

21 5.3 Entiteter skal genbruges Regel Entiteter skal genbruges på tværs af grunddatamodellen. Rationale Det er en forudsætning for grunddataprogrammet, at objekter genbruges på tværs af grunddata for at sikre sammenhæng og undgå redundant vedligehold af data. Implikation Som modelansvarlig skal man modellere entiteterne for sit eget forretningsdomæne samt sørge for at relatere til entiteter i andre forretningsdomæners UML-pakker. Eksempel Hvis fx person-domænet har behov for at modellere Adresse, skal modelleringen referere/genbruge den korrekte entitet inden for Adresse-domænet. 5.4 UML-relationer skal modelleres fyldestgørende Regel Relationer mellem klasser skal modelleres fyldestgørende - dvs med retning, roller og multiplicitet. Rationale For at modellen skal være entydig samt danne basis for semantisk forståelse af data, er det nødvendigt, at relationerne mellem klasser er beskrevet grundigt. Implikation Relationer mellem klasser (associationer, kompositioner, aggregeringer, generalisering/specialisering) skal modelleres med retning,navngiven rolle/relations-ende samt multiplicitet. Eksempel På figuren ses hvordan roller, retning og multiplicitet udtrykker en kompleks association mellem to dataobjekter, som ellers ikke vil kunne kommunikeres i regi af modellen. Figur 5 - fra 21

22 5.5 Standardiserede datatyper fra ISO skal genbruges Regel Alle attributter skal enten tildeles en standardiseret datatype eller en datatype, der er modelleret som en klasse 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 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. Implikation Standardiserede datatyper i modellen skal referere til ISO eller evt. ISO Se reglen uddybet i [INSPIRE GCM] afsnit Grunddatasekretariatet sørger for, at der kan refereres til pakker med standardiserede datatyper fra ISO og UML-stereotyper skal anvendes Regel Alle klasser 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 (entitet, datatype, enumeration) i 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 fx datasnitflader og ontologier. Stereotyperne tilføjer i første omgang bare roller til elementerne (se Note om tagged values). Implikation Alle forretningsobjekter skal modelleres som UML-klasser med stereotypen «Objekttype». Attributter med kodede værdier skal modelleres med UML-klasser med stereotypen «Enumeration», «Kodeliste» eller «Klassifikation», som værdisæt. - se Note om kodede værdier. Attributter, som ikke er kodede værdier og som ikke tildeles en standardiseret datatype fra ISO (se regel 5.5) skal modelleres med en klasse i samme eller en anden pakke, med stereotypen «Datatype», som værdisæt. Grunddatasekretariatet sørger for, at en UML-profil indeholdende stereotyperne er specificeret. NOTE om tagged values Stereotyper kan indeholde ekstra attributter, kaldet tagged values, som på en gang tilføjes alle klasser der har stereotypen. Disse tagged values kan indeholde specifikke instrukser til det software, som skal fortolke modellen til for eksempel XML-schema - se [INSPIRE GCM] afsnit På nuværende tidspunkt er der ikke overblik over, hvilke instrukser, der er behov for. Derfor er det indtil videre fyldestgørende, at ordne 22

23 elementerne med stereotyper, som så på et senere tidspunkt, relativt nemt, eventuelt kan opdateres med relevante tagged values. NOTE om kodede værdier Kodede værdier kan modelleres på tre måder: Enumeration, hvor værdierne findes explicit som en liste i modellen. Bruges typisk, hvor udfaldsrummet er velforstået, og hvor der ikke forventes ændringer hurtigere end modellens overordnede versioneringscyklus gør muligt. Eksempelvis ugedag: {mandag, tirsdag, onsdag, torsdag, fredag, lørdag, søndag} Kodeliste, hvor værdierne opbevares eksternt, men tilgængeligt på internettet. Se [INSPIRE GCM] afsnit 9.4.9, samt Annex G. Dette giver mulighed for dynamisk tilpasning og udvidelse af kodelisten efter behov, samtidig med, at der er et vist mål af styring af historik og proveniens for værdierne. Klassifikation, hvor værdierne opbevares i en klassifikationskomponent, som følger [Klassifikation]. Klassifikationskomponenten skal udstyre værdierne med metadata, opdaterings-metadata og dobbelthistorik. Klassifikationskomponenten indgår i en fremtidig KL/KOMBIT rammearkitektur. Se afsnit Når en sådan er på plads, kan udformningen af stereotypen «Klassifikation» færdiggøres. 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 modelelementer fra hinanden. Implikation Klasser navngives med UpperCamelCase - dvs. med stort begyndelsesbogstav i både første ord og alle efterfølgende ord i navnet og uden anvendelse af mellemrum i navnet. Attributter og relationsender navngives med lowercamelcase - dvs. med lille begyndelsesbogstav i første ord samt stort begyndelsesbogstav i alle efterfølgende ord i navnet og uden anvendelse af mellemrum i navnet. Navne på klasser for datatyper skal ende på Type. Navne på klasser for enumerationer skal ende på Kode. 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 (fx Integer og codelist ). Datamodellen dokumenteres på dansk, se regel

24 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. Fx er en række grunddata omfattet af EU-direktivet 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. Implikation Det er op til den modelansvarlige at vælge sprog for de 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. Beskrivelserne etableres og vedligeholdes sammen med modellen som beskrevet i bilag 3. 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. Skabelonen for dokumentation i bilag 3 stammer fra INSPIRE, som har et gennemprøvet setup for dokumentation af UML-modeller. Implikation Datamodellens klasser, attributter og relationer skal dokumenteres som beskrevet i bilag Referencer til klassifikationer, referencemodeller og organisationsmodeller bør anvendes Regel Referencer til ekstern information bør så vidt muligt være referencer til publicerede klassifikationer, referencemodeller og organisationsmodeller. Rationale De fleste 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 fx 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 - fx med reference til en liste over organisatoriske enheder. På et senere tidspunkt kan sådanne lister så importeres i infrastruktur-komponenter, og referencerne tilpasses. 24

25 Implikation 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: Ved angivelse af: Brug: Forretningsområde: FORM: Anbefales generelt anvendt ved angivelse af fællesoffentligt forretningsområde. Anbefales specifikt anvendt som udfaldsrum for attributten forretningsområde i regel 6.4. Organisatorisk enhed: ORGANISATION: Anbefales generelt anvendt ved referencer til organisatoriske enheder. Anbefales specifikt anvendt som udfaldsrum for attributterne registreringsaktør og virkningsaktør i regel 6.3. Strukturerede data KLASSIFIKATION: Anbefales generelt anvendt ved referencer som kræver en mere kompleks struktur, end enumeration eller kodeliste kan understøtte. Anbefales specifikt anvendt som udfaldsrum for attributterne status i regel 6.2 og forretningsproces i regel 6.4. Referencer: [FORM],[Organisation],[Klassifikation] 25

26 6 Regler om generelle egenskaber De generelle egenskaber skal understøtte, at grunddata kan anvendes i sammenhæng i et distribueret forvaltningsmiljø. Egenskaberne skal ligeledes sørge for, at brugerne oplever en øget datakvalitet i og med, at data udstilles på en ensartet måde, således at ofte benyttede egenskaber har den samme form bredt ud over grunddata. Yderligere skal reglerne muliggøre en stærk, intelligent beskeddrevet arkitektur. I dette kapitel formuleres reglerne først på forretningsniveau, og efterfølges så af specifikke angivelser af generelle egenskaber, som alle entiteter skal have. De generelle egenskaber og deres indbyrdes sammenhæng er illustreret i figuren herunder. Figur 6: Skabelon for generelle egenskaber Figuren udgør en skabelon for modellering af en entitet, indeholdende de generelle egenskaber, som regelsættes i kapitlet. Entiteter i domænernes modeller vil naturligvis indeholde yderligere attributter; i figuren indikeret med <..>. Se et eksempel på en entitet, der overholder skabelonen i bilag 4. De generelle egenskaber og deres attributter forklares i de følgende regler. I reglens implikation angives for hver generel egenskab, om den er obligatorisk eller valgfri: Obligatorisk egenskab: Skal være til stede og skal modelleres som angivet i dette kapitel. 26

27 Valgfri egenskab: Skal kun være til stede, hvis det giver mening inden for domænet. Hvis egenskaben er til stede, skal den modelleres, som angivet i dette kapitel. I nogle tilfælde kan der ikke stilles krav om, at attributværdien er udfyldt. For hver attribut angives om attributværdien må være tom. 6.1 Alle entiteter skal modelleres med en persistent, unik nøgle Regel Alle entiteter skal modelleres med en persistent, unik nøgle. Rationale Alle objekter skal have et globalt unikt id, som ikke ændres i objektets levetid. Det er nødvendigt at have en unik identifikation af et dataobjekt på tværs af grunddatamodellen, for at sikre en fælles høj datakvalitet. Ofte vil dataobjektet, ud over den unikke nøgle, have en eller flere forretningsnøgler, fx har en matrikel et matrikelnummer. Men forretningsnøglerne kan ikke stå alene, da grunddatamodellen generelt skal understøtte historik, hvilket betyder, at objektet kan have forskellige forretningsnøgler over tid, ligesom den samme forretningsnøgle løbende kan indgå i flere forretningsobjekter. Derfor er det essentielt, at objektets ID er persistent i hele objektets levetid. UUID (Universal Unique IDentifier) anvendes som unik nøgle, idet den ikke indeholder forretningsinformation, som kan blive obsolet i objektets levetid, og fordi metodikken bag genereringen af UUID sikrer unikke værdier uden yderligere organisering eller infrastruktur. Implikation Alle entiteter skal modelleres med attributten id id Betydning Værdi Datatype Udfaldsrum Krav Unik identifikation af objektet Objektets unikke id number UUID (ISO/IEC :200), værdien må ikke være tom Obligatorisk NOTE: Hvis et domæne har behov for anvendelse/udstilling af et namespace, er dette ikke en del af objektets id, og erstatter således ikke kravet om brug af unik identifikation. 27

28 6.2 Alle entiteter skal modelleres med status Regel Alle entiteter skal modelleres med status, der klart angiver, hvor et forretningsobjekt er i sin livscyklus. Rationale Forretningsobjekter gennemløber typisk en livscyklus. Fx kunne en livscyklus for en bygning være: Projekteret > Under opførelse > Ibrugtaget > Under Nedrivning > Historisk bygning. Forretningsdomænet kan opstille regler for hvilke statusser, der er gyldige for et givet objekt, og for, hvordan objektet kan gennemløbe disse. Disse tilstande skal placeres og udstilles i et vedtaget udfaldsrum, som objektet skal referere til. Objektets status udtrykker objektets relevans for databrugeren. Forretningsmæssigt giver det god værdi at udstille et objekts status eksplicit, frem for at lade databrugeren analysere sig frem til informationen. Anvendelsen af status er med til at sikre en høj datakvalitet og potentielt nedbringe udviklingsomkostninger, da der skal implementeres mindre forretningslogik og fejlhåndteringslogik. Implikation Alle entiteter skal have attributten status status Betydning Værdi Datatype Udfaldsrum Krav Forretningsobjektets status En status enumeration, codelist, klassifikation Domænespecifik liste, værdien må ikke være tom Obligatorisk Der skal i domænemodellerne defineres statustilstande for alle forretningsobjekter. Disse statustilstande defineres af den modelansvarlige, og publiceres i den fælles model. Tilstandene kan modelleres som enumeration, kodeliste eller klassifikation (se Note om kodede værdier i afsnit 5.6). 6.3 Alle entiteter skal understøtte dobbelthistorik og angivelse af aktør Regel Alle entiteter skal modelleres med angivelse af registrering, virkning og aktør. Rationale Dobbelthistorik På tværs af grunddata er der behov for at implementere dobbelthistorik, for at kunne understøtte et samlet krav om revisionsspor. Objekter skal med andre ord kunne fremfindes i en versioneret form, hvor der er styr på, hvilken status en given version af objektet havde på det tidspunkt. Formålet hermed er bl.a. at dokumentere det konkrete historiske beslutningsgrundlag i forbindelse med fx sagsbehandling. Dobbelthistorik modelleres ved hjælp af bitemporale egenskaber. Det dobbelte består i, at to tidsaspekter virkningstid og registreringstid håndteres i sammenhæng. 28

29 Registreringstid: Tidsrummet fra versionen registreres i databasen, indtil den enten erstattes af en nyere version eller afregistreres 3 Virkningstid: Tidsrummet, hvor en given version af data svarer til de forhold i virkeligheden, som versionen afbilder. Aktør Oplysning om hvilken aktør, der er ansvarlig for datas indhold, tilfører sporbarhed i forbindelse med revision og anvendelse af data. Aktøren kan være en af en række forskellige typer af aktør, fx en organisation, et it-system, en arbejdsfunktion eller en bruger. Implikation Et data-objekt kan bestå af en række (1-*) versioner (ændres en enkelt attributværdi, betragtes objektet som ændret og dermed versioneret). Alle versioner betragtes som dele af et stamobjekt, og har den samme Identifikation. Alle versioner skal være karakteriseret ved hjælp af deres registreringstid og deres virkningstid. Begge tidsaspekter modelleres ved anvendelse af attributterne registrering og rirkning, som samler information om de forhold, der gør sig gældende i forbindelse med opdatering. Til hver version af et objekt skal der knyttes aktører i betydningen: Reference til den aktør, der afstedkommer iværksættelse af virkningsperioden Reference til den aktør, der har foretaget registreringen Aktør kan være en reference til fx en organisation, et system eller en sagsbehandler se afsnit afsnit og regel Alle entiteter skal have attributten registrering registrering Betydning Værdi Objektets registrering Datatypen Registrering Datatypen Registrering har følgende attributter: registreringfra Betydning Værdi Type Krav Tidspunktet hvor registreringen er foretaget Tidspunkt datetime (ISO 8601), værdien må ikke være tom Obligatorisk registreringtil Betydning Tidspunktet hvor en ny registrering er foretaget på objektet, og hvor denne 3 Passiveres/logisk slettes. Svarende til, at forretningsobjektet ikke længere kan modtage forretningshandlinger. 29

30 version således ikke længere er den seneste. Værdi Udfaldsrum Krav Tidspunkt datetime (ISO 8601), værdien kan være tom Obligatorisk registreringsaktør Betydning Den aktør der har foretaget registreringen Værdi Navnet på en aktør eller en refererence til Organisation (se regel 5.10) Udfaldsrum Domænespecifik aktør, værdien må ikke være tom Krav Obligatorisk Alle entiteter skal have attributten virkning registrering Betydning Objektets virkning Værdi Datatypen Virkning Datatypen Virkning har følgende attributter: virkningfra Betydning Værdi Type Krav Tidspunktet hvorfra objektet har virkning Tidspunkt datetime (ISO 8601), værdien må ikke være tom Obligatorisk virkningtil Betydning Værdi Udfaldsrum Krav Tidspunktet hvor objektets virkning ophører Tidspunkt datetime (ISO 8601), værdien kan være tom Obligatorisk virkningsaktør Betydning Den aktør der har afstedkommet objektets virkning Værdi Navnet på en aktør eller en refererence til Organisation (se regel 5.10). Udfaldsrum Domænespecifik aktør, værdien må ikke være tom 30

31 Krav Obligatorisk Grunddatasekretariatet sørger for, at der kan refereres til en UML-pakke med de elementer, som indgår i generelle egenskaber. 6.4 Alle entiteter bør understøtte beskedfordeling Regel Entiteterne i grunddata bør modelleres således, at dataobjektet kommer til at indeholde informationer, som kan forbedre kvaliteten af hændelsesbeskeder, der udsendes i forbindelse med opdatering af objektet. Disse informationer omfatter den forretningsmæssige kontekst, hvori objektet opdateredes, samt den bagvedliggende forretningsmæssige årsag til opdateringen. Rationale Intelligent beskedfordeling beskrives i kapitel Der findes på nuværende tidspunkt ikke et samlet billede af, hvordan beskedfordelig skal foregå, hvorfor denne regel er formuleret med det formål, at beskrive rammerne for de data der er nødvendige for beskedfordeling. Yderligere arbejde med fællesoffentlig beskedfordeling kan meget vel resultere i justering af denne regel. Intelligent beskedfordeling forudsætter, at det for hver ændring af data registreres hvilken forretningssammenhæng, der ligger til grund for ændringen. Forretningssammenhængen beskrives med tre parametre: forretningshændelse, som betegner den begivenhed i virkeligheden (se afsnit 1.4.2), som udløste ændringen i data forretningsområde - den del af den offentlige forretning, som håndterer hændelsen og derved udvirker ændringen i data forretningsproces - den manuelle eller it-understøttede proces, hvori forretningsområdet håndterer hændelsen. Hændelse, område og proces er udfaldsrum, som typisk vil skulle modelleres af domænet. Forretningshændelser vil typisk (ligesom status - se regel 6.2) være specifikke for det enkelte forretningsobjekt - der skal opbygges en datastruktur, der afspejler forretningens viden om hvilke hændelser, der kan påvirke et forretningsobjekt. Forretningsområdet kan specificeres ud fra FORM Forretningsproceser forudsætter en kortlægning af domænets processer. De tre udfaldsrum kan modelleres mere eller mindre komplekst - som simple lister, indlejret i modellen eller som reference til eksterne data, enten i form af kodelister eller klassifikationskomponenter- se NOTE om kodede værdier i afsnit 5.6 samt afsnit Den modelansvarlige må afgøre på hvilket niveau modelleringen bedst muligt modsvarer forretningskravene. Implikation Datatypen Registrering tilknyttes attributterne forretningsområde og forretningsproces : forretningsområde Betydning Det forretningsområde som har opdateret objektet 31

32 Værdi Type Udfaldsrum Krav Specifikation af et forretningsområde enumeration, codelist,klassifikation Domænespecifik liste, værdien kan være tom Valgfri forretningsproces Betydning Værdi Type Udfaldsrum Krav Den forretningsproces, som har opdateret objektet Specifikation af en forretningsproces enumeration, codelist,klassifikation Domænespecifik liste, værdien kan være tom Valgfri Datatypen Virkning tilknyttes attributten forretningshændelse : forretningshændelse Betydning Den forretningshændelse, som afstedkom opdateringen Værdi Specifikation af en forretningshændelse Type enumeration, codelist,klassifikation Udfaldsrum Domænespecifik liste, værdien kan være tom Krav Valgfri 32

33 7 Referencer Reference Titel Link [Arkitekturguiden] OIO Arkitekturguide Link [Arkitekturguide forretningsobjekt] OIO Arkitekturguide, B1 Forretningsobjekter Link [Arkitekturguide informationsmodel] OIO Arkitekturguide, C1 Informationsobjekter i logisk datamodel [Begrebsmodel version 0.8] Begrebsmodel for grunddata version 0.8 Link [Beskedfordeler] [Datafordeler] Beskedfordeler - scopedokument for fælleskommunal implementering Beskrivelse af den fællesoffentlige Datafordeler på Digitaliseringsstyrelsens hjemmeside [EDA] Event Driven Architecture Link [ESK] Effektiv Sagsbehandling og Kontrol Link [FORM] FORM online Link [Den fælleskommunale rammearkitektur] [Den fælleskommunale rammearkitektur - støttesystemer] KL s hjemmeside om Den Fælleskommunale Rammearkitektur KOMBIT s hjemmeside om udbud af støttesystemer i rammearkitekturen [Grunddataprogrammet] Grunddataprogrammet Link [INSPIRE] INSPIRE direktivet Link [INSPIRE GCM] INSPIRE Generic Conceptual Model Link [INSPIRE dokumentation] Connecting to the public INSPIRE UML repository using Enterprise Architect [Klassifikation] Specifikation af serviceinterface for klassifikation - OIO-Godkendt [vs. 1.1] [KLE] KLE online Link [OIO arbejdsmodellen] [Organisation] Publikationer vedrørende OIO arbejdsmodel for datastandardisering i sektorerne Specifikation af serviceinterface for organisation- OIO-Godkendt [vs. 1.1] [Sag og Dokument] Sag og dokument standarderne Link [S&D Generelle Egenskaber] Generelle egenskaber for services på sags- og dokumentområdet - OIO-Godkendt [vs. 1.1] Link Link Link Link Link Link Link Link Link Link 33

34 [UML] Unified Modelling Language Link 34

35 Bilag 1: Tabeloversigt over regler I tabellen herunder gives et resumé af alle modelleringsreglerne. Tabellen kan bruges som huskeseddel i forbindelse med udarbejdelse af en datamodel. Generel modelleringsregel Krav/ anbefaling Rationale 5.1 UML-klassediagrammer Krav Et fælles modelleringssprog 5.2 UML-pakker Krav Sikre overskuelighed samt mulighed for at referere til andre pakker 5.3 Genbrug af entiteter Krav Sikre sammenhæng og undgå redundant vedligehold af data 5.4 UML-relationer Krav Sikre forståelsen af sammenhængen mellem data 5.5 Brug af standardiserede datatyper fra ISO Note Krav Ensartethed Reglen er en forudsætning for automatisk datasnitfladegenerering. 5.6 Brug af stereotyper Krav Stereotyperne indsnævrer modellens fortolkning, gør den mere specifik. Stereotyperne indeholder tagged values, som muliggør automatisk datasnitfladegenerering 5.7 Navngivningsregler Krav Ensartethed og visuelt overblik over modellen 5.8 Sprogregler Krav Fleksibilitet ved valg af sprog ved modellering 5.9 Dokumentation af datamodellen 5.10 Referencer til klassifikationer, referencemodeller og organisationsmodeller Regel om generelle egenskaber Krav Anbefaling Krav/ anbefaling Genbrugelighed og kommunikation af modellen Genbrug af strukturerede data Rationale 6.1 Unik identifikation Krav Entydig dataanvendelse 6.2 Udstilling af status Krav Udstiling af relevans af data Reglen er en forudsætning for automatisk datasnitfladegenerering. Forudsætter infrastruktur, stipuleret i kapitel 3 Note 35

36 6.3 Understøttelse af dobbelthistorik Krav Revision og sporbarhed 6.4 Understøttelse af beskedfordeling Attributter som indgår i generelle egenskaber Anbefaling Intelligent beskedfordeling Reglen er en forudsætning for beskedfordeling Obligatorisk/ valgfri Rationale id Obligatorisk Unik identifikation af objekter status Obligatorisk Udstilling af relevans af data registrering Obligatorisk Revision og sporbarhed registreringsaktør Obligatorisk Revision og sporbarhed registreringfra Obligatorisk Revision og sporbarhed registreringtil Obligatorisk Revision og sporbarhed forretningsområde Valgfri Identifikation af det forretningsområde, hvori en proces har opdateret objektet forretningsproces Valgfri Identifikation af den proces, som har opdateret objektet virkning Obligatorisk Revision og sporbarhed virkningsaktør Obligatorisk Revision og sporbarhed virkningfra Obligatorisk Revision og sporbarhed virkningtil Obligatorisk Revision og sporbarhed forretningshændelse Valgfri Identifikation af den hændelse, som har afstedkommet ændringen i data Note Attributten er en forudsætning for intelligent hændelsesbesked Attributten er en forudsætning for intelligent hændelsesbesked Attributten er en forudsætning for intelligent hændelsesbesked 36

37 Bilag 2: Tabeloversigt over generelle egenskaber I tabellen herunder gives et resumé af de generelle egenskaber og tilhørende attributter. Tabellen kan bruges som huskeseddel i forbindelse med systemdesign. Generel egenskab Obligatorisk/ valgfri Udfaldsrum Tom attributværdi id Obligatorisk UUID Ikke tilladt status Obligatorisk domænespecifikt Ikke tilladt registrering Obligatorisk Ikke tilladt - registreringsaktør Obligatorisk domænespecifikt Ikke tilladt - registreringfra Obligatorisk datetime Ikke tilladt - registreringtil Obligatorisk datetime Tilladt - forretningsområde Valgfri domænespecifikt Tilladt - forretningsproces Valgfri domænespecifikt Tilladt virkning Obligatorisk Ikke tilladt - virkningsaktør Obligatorisk domænespecifikt Ikke tilladt - virkningfra Obligatorisk datetime Ikke tilladt - virkningtil Obligatorisk datetime Tilladt - forretningshændelse Valgfri domænespecifikt Tilladt 37

38 Bilag 3: Dokumentation af datamodellen Datamodellen skal dokumenteres gennem beskrivelser af elementerne i UML-modellen. Datamodellens klasser, attributter og relationer skal dokumenteres som beskrevet i skabelonen herunder. Skabelonen for dokumentation stammer fra INSPIRE, som har et gennemprøvet setup for dokumentation af UML-modeller [INSPIRE dokumentation]. Dokumentation i UML Klasser, attributter og relationsender dokumenteres ved brug af Notes-tekstfeltet, som er en del af UMLstandarden. Dokumentationen skal følge skabelonerne herunder, således at det er muligt at autogenerere et katalog med dokumentation af datamodellen. Nogle af felterne i skabelonen vil i et modelleringsværktøj kunne autoudfyldes ud fra diagrammet. Dokumentation af klasser Klasser i datamodellen beskrives ud fra følgende skabelon: Navn Stereotype Definition Navn på klassen i UpperCamelCase. Navnet skal som minimum være entydigt inden for UML-pakken. Klassens stereotype Kort og præcis definition. Kan også indeholde et afsnit med en længere beskrivelse, fx med eksempler og henvisning til definitioner. Dokumentation af attributter Klassens attributter beskrives hver især ud fra følgende skabelon: Navn Evt. stereotype Datatype Multiplicitet Definition Navn på attributten i lowercamelcase. Navnet skal som minimum være entydigt inden for klassen. Hvis der er anvendt en stereotype til attributten Standardiseret datatype fra ISO eller et klassenavn for en DataType eller en KodeListe Her angives antaltsregler for, hvor mange værdier, attributten kan rumme på en enkelt instans af klassen. Fx: 0..1, 1..1, 0..*, 0..4, 1..*, 2-4,... Kort og præcis definition. Kan også indeholde et afsnit med en længere beskrivelse, fx formål, referencer, eksempler og kilde. Dokumentation af relationsender Relationer, der ender på klassen beskrives hver især ud fra følgende skabelon: Navn Evt. stereotype Kardinalitet Entydigt navn på relationsenden i lowercamelcase. Navnet er som minimum entydigt inden for UML-pakken. Hvis der er anvendt en stereotype til relationsenden Her angives antalsregler for begrebets deltagelse i relationen. Fx: 0..1, 1..1, 0..*, 1..* 38

39 Definition Kort og præcis definition. Kan også indeholde et afsnit med en længere beskrivelse, fx formål, referencer og eksempler. 39

40 Bilag 4: Eksempel på entitet Her er et eksempel på en entitet, som overholder skabelonen, se figur 6 i kapitel 6. Figur 7: Skabelonen anvendt til at modellere objektet Hundehus 40