Retningslinjer for modellering i TOR - Brønnøysundregistrene

Retningslinjer for modellering i
SERES
Brønnøysundregistrene
Versjon: 2006-05-23
1

1 Innledning .....................................................................................................................................................5
2 Ulike modeller i SERES ...............................................................................................................................7
2.1 Modeller som begrep ............................................................................................................................7
2.2 Informasjonsmodellen...........................................................................................................................8
2.2.1 Domenemodeller ..............................................................................................................................9
2.2.2 Konvertert modell ............................................................................................................................9
2.2.3 Konforme modeller ..........................................................................................................................9
2.2.4 Harmoniserte modeller...................................................................................................................10
2.2.5 Standardmodell ..............................................................................................................................10
2.3 Dokumentmodell .................................................................................................................................11
2.4 Meldingsmodell...................................................................................................................................12
2.4.1 Formatfamilie.................................................................................................................................12
2.4.2 Meldingsspesifikasjon....................................................................................................................12
3 SERES-profil for UML-basert modellering.............................................................................................13
3.1 Generelt om UML ...............................................................................................................................13
3.2 UML-komponenter i SERES................................................................................................................13
3.2.1 Eksempel på informasjonsmodelldiagram .....................................................................................14
3.2.2 Klasser............................................................................................................................................15
3.2.3 Attributter.......................................................................................................................................15
3.2.4 Semantiske typer ............................................................................................................................15
3.2.5 Assosiasjoner..................................................................................................................................16
3.2.6 Assosiasjonsklasser ........................................................................................................................16
3.2.7 Arv .................................................................................................................................................16
3.2.8 Diagrammer....................................................................................................................................17
3.2.9 Pakker.............................................................................................................................................17
3.2.10 Kobling mellom informasjons- og dokumentklasse ..................................................................17
3.2.11 Tagged values............................................................................................................................17
3.2.12 Oppsummering ..........................................................................................................................18
4 Overordnet om informasjonsmodellering ................................................................................................19
4.1 Tilnærming til modelleringen..............................................................................................................19
4.2 Fokus og kontekst................................................................................................................................20
5 Teoretisk og språklig forankring for SERES...........................................................................................21
5.1 Terminologi, læren om begreper.........................................................................................................21
5.2 Navn og språkregler...........................................................................................................................23
5.2.1 Bruk av norsk språk........................................................................................................................23
5.2.2 Navnestandarder.............................................................................................................................24
5.2.3 Generelle retningslinjer for navngiving..........................................................................................24
5.2.3.1 Navngiving av klasser...........................................................................................................24
5.2.3.2 Navngiving av attributter......................................................................................................25
5.2.3.3 Navngiving av semantiske typer...........................................................................................26
5.2.3.4 Navngiving av assosiasjoner og assosiasjonsender ..............................................................26
5.2.3.5 Navngiving av assosiasjonsklasser .......................................................................................26
5.2.3.6 Navngiving av pakker...........................................................................................................26
5.2.3.7 Navngiving av diagrammer ..................................................................................................27
6 Grunnleggende semantiske typer..............................................................................................................28
6.1 alternativ.............................................................................................................................................28
2

6.2 antall ...................................................................................................................................................28
6.3 beløp....................................................................................................................................................28
6.4 binærobjekt .........................................................................................................................................28
6.5 identifikator.........................................................................................................................................28
6.6 kode.....................................................................................................................................................29
6.7 mål ......................................................................................................................................................29
6.8 tall .......................................................................................................................................................29
6.9 tekst .....................................................................................................................................................29
6.10 tidspunkt..............................................................................................................................................30
7 Eksempel - Flyttemelding ..........................................................................................................................31
8 Klasser .........................................................................................................................................................33
8.1 Antall attributter .................................................................................................................................33
8.2 Normalisering .....................................................................................................................................34
9 Attributter...................................................................................................................................................35
9.1 Attributtenes semantikk.......................................................................................................................35
9.2 Avledete verdier ..................................................................................................................................35
10 Arv som presisering av semantikk ............................................................................................................37
10.1 Klasser ................................................................................................................................................37
10.1.1 Identifisering av arveforhold .....................................................................................................37
10.1.2 Attributter i subklasser ..............................................................................................................37
10.1.3 Alias for attributter ....................................................................................................................38
10.1.4 Flyttemeldingseksempelet .........................................................................................................38
10.1.5 Form på arvehierarki .................................................................................................................39
10.1.6 Konsekvenser av brede/dype arvehierarki.................................................................................39
10.2 Spesialisering av semantiske typer......................................................................................................40
11 Assosiasjoner...............................................................................................................................................41
11.1 Urettet assosiasjon..............................................................................................................................41
11.2 Rettet assosiasjon................................................................................................................................41
11.3 Kardinalitet.........................................................................................................................................41
11.4 Flere assosiasjoner mellom to klasser ................................................................................................43
11.5 Assosiasjonsklasser.............................................................................................................................43
11.5.1 Attributter i assosiasjonsklasser.................................................................................................44
12 Diagrammer ................................................................................................................................................45
13 Oppsummering av eksempel Flyttemelding .............................................................................................46
14 Tabeller........................................................................................................................................................47
15 Grunndata og gjenbruk .............................................................................................................................49
15.1 Grunndatamodell ................................................................................................................................49
15.2 Gjenbruk av elementer i informasjonsmodellen..................................................................................49
15.2.1 Eksempel: Gjenbruk i modell av flyttemelding.........................................................................49
15.2.2 Grunndata ..................................................................................................................................50
3

15.2.3 Gjenbruk av egne informasjonselementer .................................................................................51
15.2.4 Gjenbruk av andres informasjonselementer ..............................................................................51
15.3 Oppsummering av informasjonsmodellering ......................................................................................51
16 Dokumentmodellering................................................................................................................................53
16.1 Assosiasjoner ......................................................................................................................................53
16.1.1 Rettede assosiasjoner.................................................................................................................53
16.1.2 Kardinalitet................................................................................................................................53
16.2 Skjuling av attributter .........................................................................................................................54
16.3 Semantiske typer .................................................................................................................................54
16.4 Rotklasse .............................................................................................................................................55
16.5 Dokumentmodell av flyttemelding.......................................................................................................55
17 Meldingsmodellering..................................................................................................................................56
17.1 Format ................................................................................................................................................56
17.2 Formatstandard ..................................................................................................................................56
17.3 Administrering av formater.................................................................................................................57
17.3.1 Kompleksformater.....................................................................................................................57
17.4 Kodelister............................................................................................................................................59
18 Oppsummering ...........................................................................................................................................60
4

1 Innledning
Dette dokumentet er retningsgivende for oppbygging av et nytt register som er etablert av
Brønnøysundregistrene, kalt SERES, som står for SEmantikkRegisteret for Elektronisk
Samhandling. Registeret skal medvirke til at alle data som utveksles elektronisk mellom
hvilket som helst par av offentlige institusjoner har felles beskrivelser slik at avsender og
mottaker er sikre på at de har samme forståelse av hvordan data skal tolkes (semantisk
interoperabilitet).
SERES skal utvikles med direkte bidrag fra alle offentlige etater som ønsker det. Registeret
bygges opp ved hjelp av verktøy som er relativt åpne i måten de kan brukes på. For å oppnå
semantisk interoperabilitet i praksis, trengs regler for hvordan informasjon beskrives. Reglene
er enten av type må, bør eller kan.
Det sentrale verktøyet i løsningen er SERESuml som brukes til å etablere og vedlikeholde en
samordnet informasjonsmodell bestående av informasjonselementer med tilhørende
definisjoner og relasjoner til andre elementer, alt hentet fra informasjonsdomener fra en rekke
offentlige aktører. SERESuml er basert på åpen-kilde-verktøyet ArgoUML, som utvikles
innenfor et internasjonalt prosjekt. Brønnøysundregistrene har først og fremst bidratt med
flerbrukerfunksjonalitet med adgang over Internett samt disse retningslinjene for
informasjonsmodellering. SERES inneholder også verktøy for å lage meldingsspesifikasjoner
basert på uttrekk fra informasjonsmodellen med påkopling av formater fra SERESformat samt
publisering av spesifikasjonene på nettet gjennom SERESnett.
Retningslinjedokumentet er beregnet på:
• etater som mottar og avgir informasjon fra/til borgere og næringsliv
• etater som utveksler informasjon med andre etater
• fagsystemleverandører med moduler som utveksler informasjon med offentlige
systemer
Lesegruppen er først og fremst faktiske og fremtidige brukere av SERES. Men også personer
som planlegger nye løsninger på de omtalte områdene vil kunne ha interesse av dette
dokumentet.
Sentrale teknologier som SERES baserer seg på er:
• UML som er den dominerende generelle modelleringstandarden på IT-området. UML
tilbyr et antall diagrammer, blant annet klassediagram som utgjør den sentrale
funksjonaliteten for SERESuml.
• XML med underteknologien XML Schema. XML er den klart viktigste teknologien i
verden for formatering av komplekse elektroniske meldinger og er dessuten på full fart
inn som format for lagrede dokumenter.
• Core Components (kjerne i ebXML) er den sentrale teknologien fra FN-organet
CEFACT som fremmer felles elektroniske handelsløsninger over Internett. SERES
bruker de sentrale Permissible Representation Terms som grunnlag for løsningens
semantiske (data)typer.
SERES skal altså bli et register som samler bidrag fra alle etater som har interesse for å delta.
Brønnøysundregistrene ved Oppgaveregisteret (OR) vil bistå ved opplæring i bruk av
5

verktøyet og ved den faktiske modelleringen, om ønsket. Spesielt når flere offentlige
institusjoner går sammen om etablering av en felles domenemodell, er det naturlig at OR
hjelper til faglig og praktisk med å harmonisere disse. Det arbeides med opplæringsmateriell
for SERES som både tar for seg modellering i sin alminnelighet og spesifikt mot SERES.
Dette dokumentet er utarbeidet basert på bidrag fra Norske Veritas, KITH, Sintef og
NorStella. Dag Belsnes (rådgivningsfirmaet Pharos og professor II ved Universitetet i Oslo)
har vært sentral i den direkte utformingen av retningslinjene. Vi har også hentet ideer
gjennom flere runder med særlig interesserte etater, spesielt Skattedirektoratet,
Rikstrygdeverket og Statistisk sentralbyrå. Fornyings- og administrasjonsdepartementet har
bidratt gjennom et antall utredninger og høringsprosesser.
SERES er en videreføring av løsningen som er basis for dagens Oppgaveregister hvorfra det
produseres meldingsspesifikasjoner til Altinn. Arbeidet med SERES startet i erkjennelse av at
dagens løsning ikke er et godt nok fundament for gjenbruk av innrapporterte data fra
næringslivet. I en forstudie til neste generasjons Altinn (Altinn II) er det foreslått å
standardisere på meldingsspesifikasjoner fra SERES.
SERES-arbeidet har vært presentert internasjonalt (Skandinavia, Europa, Kina) og mange har
uttrykt stor interesse for det som gjøres.
Den løsningen som nå er lansert har den nødvendige funksjonaliteten for å etablere en
informasjonsmodell og produsere meldingsspesifikasjoner med samordnet semantikk hentet
fra informasjonsmodellen. Det vil bli et videre utviklingsløp i samarbeid med brukerne. Og vi
ønsker allerede nå svært gjerne å få tilbakemeldinger på dette dokumentet. Retningslinjene er
på ingen måter et ferdig dokument.
6

2 Ulike modeller i SERES
SERES brukes til å beskrive informasjon som benyttes i det offentlige i form av
informasjonsmodellering. Verktøyet benyttes også til å generere meldingsspesifikasjoner
brukt til å validere 1 meldinger for utveksling av informasjon. Veien fra en mer abstrakt
informasjonsmodellering til generering av konkrete meldingsspesifikasjoner består av flere
trinn, og vi knytter disse ulike trinnene i prosessen til det vi kaller modeller i SERES.
2.1 Modeller som begrep
Oxford English Dictionary definerer ordet modell på følgende måte:
A simplified or idealized description or conception of a particular system, situation, or
process that is put forward as a basis for calculations, prediction of a particular
system, situation, or process.
Fornorsket blir det noe slik som:
En forenkling eller idealisert beskrivelse eller konsept av et bestemt system, situasjon
eller prosess som er utarbeidet for å kunne gjøre kalkulasjoner eller forutsi
egenskaper ved et system, situasjon eller prosess.
Modeller er den sentrale abstraksjonen eller begrepet i SERES, og all beskrivelse av
informasjon som vi håndterer ligger i en modell. En modell er en forenklet representasjon av
deler av virkeligheten, som fokuserer på de aspektene/detaljene vi er interessert i. Det er tre
hovedtyper modeller i SERES. De har ulike formål og må derfor tolkes forskjellig:
• Informasjonsmodellen
SERES består av én informasjonsmodell som er en generell beskrivelse av
informasjonsstrukturer i norsk offentlig virksomhet. Modellen innholder
informasjonselementer med tilhørende definisjoner og relasjoner mellom disse
elementene. Informasjon som blir modellert danner en viktig bakgrunn for utvikling av
dokumentmodeller som er en spesifikk beskrivelse av en begrenset del av verden.
• Dokumentmodell
SERES består av flere dokumentmodeller. En dokumentmodell definerer strukturen og
semantikken for innholdet i en gitt melding for informasjonsutveksling mellom aktører.
Den henter all semantikk fra informasjonsmodellen ved å være et utplukk av
informasjonselementer herfra med eventuelle justeringer av disse for å tilpasse dem
formålet.
• Meldingsmodell
En meldingsmodell er en dokumentmodell med tilknyttet formatinformasjon. Innholdet
for hvert informasjonselement skal ved hjelp av formatet kunne sjekkes om det fylles
visse regler. Meldingsmodellen utgjør det samlede grunnlaget for å generere en
meldingsspesifikasjon (gjerne kalt en serialisert meldingsmodell).
1 Validering betyr i denne sammenheng test av meldingsstruktur og format av de enkelte meldingselementer.
7

Figur 1: Hovedmodelltyper i SERES
Informasjonsmodellen
2.2 Informasjonsmodellen
Dokumentmodell Meldingsmodell
Informasjonsmodellen er en beskrivelse av informasjonsstrukturer i norsk offentlig
virksomhet. Virksomheten i offentlig sektor er for det meste regulert av lovverk som legger
føringer for hvordan visse informasjonselementer kan brukes. Modellen må derfor være i tråd
med gjeldende lovverk. Også forskrifter og andre typer regelverk av påkrevd eller frivillig art,
for eksempel ISO-standarder, kan påvirke modellens utforming. Ved å beskrive relevant
informasjon hos samarbeidende aktører, søker informasjonsmodellen å etablere en
harmonisert forståelse mellom aktørene angående semantikken i settet av
informasjonselementer som brukes til elektronisk samhandling.
I modellen beskrives immaterielle objekter (for eksempel Foretak) eller fysiske objekter (for
eksempel Person), og relasjoner disse måtte ha seg i mellom. Hovedfokus for
informasjonsmodellen er:
• hvordan informasjon tolkes (semantikk)
• hvordan informasjon integreres (interoperabilitet)
Den skal danne grunnlaget for analyse av semantisk interoperabilitet mellom brukere og
applikasjoner i de ulike etatene. For at nytten skal bli størst mulig, må informasjonsmodellen
tilfredsstille visse krav. Det er blant annet ønskelig at modellen er:
• Stabil (over tid)
• Lettlest (fra navnsetting og grafisk fremstilling)
• Presis (i definisjoner og navnsetting)
8

• Tilstrekkelig (i omfang)
• Tilrettelagt for analyse av interoperabilitet og gjenbruk av informasjonselementer
• Skalerbar (dvs. må tåle å vokse både i omfang og kompleksitet uten å miste de
foregående punktene)
Det finnes kun én informasjonsmodell i SERES, men den består igjen av flere
domenemodeller.
2.2.1 Domenemodeller
Informasjonsmodellen består av et antall domenemodeller, som er beskrivelser av
informasjonsstrukturer innenfor ulike anvendelsesområder. Informasjonsmodellen er således
summen av alle domenemodellene. Domenemodellene inneholder klasser, klasseattributter,
relasjoner mellom klasser, semantiske typer og klassediagrammer for grafisk modellvisning.
Arbeidet med informasjonsmodellen skjer alltid innenfor en domenemodell. Det vil være
minst én domenemodell for hver enkelt etat. Som ledd i harmoniseringsarbeidet mellom to
eller flere etater for å få til en gitt datautveksling eller samordnet datainnhenting, kan det også
være aktuelt å etablere separate domenemodeller for å ta høyde for nødvendige tilpasninger
og kompromisser. I tillegg til disse arbeidsdomene inneholder informasjonsmodellen domener
som i større grad er standardisert. Dette betyr at domenemodeller vil ha ulik karakter i
henhold til nivå av standardisering. Vi plasserer domenemodellene i SERES i følgende
utviklingskategorier:
• UML-konvertert modell (importert til SERES som XMI)
• SERES-konform modell (følger SERES-retningslinjene)
• Harmonisert modell (samordnet mellom aktører)
• Standardmodell (godkjent av standardiseringsorgan)
2.2.2 Konvertert modell
Det er ikke alltid vi starter med blanke ark når vi skal etablere nytt innhold i
informasjonsmodellen. Det finnes mange godt funderte datamodeller i diverse etater.
Generelle datamodeller som ikke er bearbeidet for bruk i SERES betegnes som eksterne
modeller. Typisk eksempel er en databasemodell som beskriver et antall tabeller og
underliggende tabellfelter med tilhørende datatyper. Det er viktig å kunne bygge videre på
disse. Ved å gjennomføre en konvertering av disse modellene kan vi oppnå modeller med en
struktur og eventuelt av et format som kan importeres til SERES. De forholder seg til SERESsettet
av mekanismer i UML klassediagrammer. Modellene foreligger eventuelt i XMI-format
som SERES kan importere direkte. Alternativt er de uttrykt i et SERES-internt format kalt
XMDL som kan konverteres til XMI med verktøyet XMIgen, se vedlegg VI. Her kan
Brønnøysundregistrene være behjelpelig, blant annet gjennom bruk av XMIgen-verktøyet.
Konverterte modeller som er importert kan ikke uten videre lagres som del av den publiserte
informasjonsmodellen. Dette krever at modellen kan betraktes som konform.
2.2.3 Konforme modeller
En konform modell er en domenemodell innenfor informasjonsmodellen som følger
retningslinjene for modellering i SERES. Dette innebærer at:
9

• Klassene er normaliserte, dvs. de har innhold som er redusert til et minimum av det
som må være beskrevet samlet. (Normalitetsbegrepet blir mer presist beskrevet
senere.)
• Klassene er relatert til grunndataklasser, dvs. at de bygger videre på det fellesdomenet
vi kaller grunndata som inneholder de informasjonselementer som de aller fleste
brukes i sine meldinger.
• Klasseattributtene er knyttet til semantiske typer, ikke generelle datatyper.
• Navnene på alle modellelementer følger gitte regler.
• Alle assosiasjonene er (normalt) angitt med spesifiserte assosiasjonsender, det samme
som roller.
Hvert informasjonselement vil kunne merkes som konform av SERES-verktøyet, dvs. de
kriteriene som er mulig å automatisere. Alle elementer i en domenemodell må være konform
for å kunne lagres til den publiserte informasjonsmodellen. En konform modell er en kandidat
for harmonisering.
2.2.4 Harmoniserte modeller
En harmonisert modell er en domenemodell innenfor informasjonsmodellen som består av
semantisk harmoniserte elementer som er felles for to eller flere konforme modeller. De
harmoniserte elementene erstatter de opprinnelige elementene i domenemodellene når de
"flyttes opp" til en høyere utviklingskategori. Grunnlaget for å gi en domenemodell kategorien
harmonisert er enighet mellom to eller flere aktører som deler dette domenet.
Grunndata og sentrale semantiske typer skal være en harmonisert domenemodell basert på
enighet mellom forvaltningsetatene for grunndataregistrene. Harmoniserte modellelementer
skal videre være stabile over tid og følge bestemte prosedyrer for endring. Oppgaveregisteret
påser at alle interessenter er representert, og bidrar ellers med faglig og administrativ bistand i
prosessen.
2.2.5 Standardmodell
Harmoniserte modeller som har faktisk eller potensielt stor gjenbruk, bør etter hvert gis
utviklingskategorien standardmodell. En standardmodell er en harmonisert modell som har
vært behandlet av et offentlig oppnevnt standardiseringsorgan med forankring i Standard
Norge.
10

Harmonisering
Grunndata
Standardmodell
Harmonisert modell Standardisering
Informasjonsmodellen
SERES-konform
domenemodell
Figur 2: Informasjonsmodellen i SERES
UML-konvertert
domenemodell
Konformering
Import
(XMI)
Ekstern
domenemodell
Konvertering
UML-konvertert
domenemodell
Figuren illustrerer informasjonsmodellen som inneholder ulike typer domenemodeller. Disse
kan plasseres i en utviklingsprosess som leder til en høyere grad av standardisering.
Modelleringsprosessen kan enten starte fra scratch internt i SERES, men det er også mulig å
ta utgangspunkt i eksterne modeller som konverteres og importeres. Grunndata er plassert i
standardmodellen da det er et ønske at den skal være på dette nivået i fremtiden.
2.3 Dokumentmodell
I konkrete anvendelser av informasjon, for eksempel i en bestemt blankett eller melding, vil
det være behov for utvalgte deler av den samlede informasjonsmodellen. Vi bruker en
dokumentmodell for å velge ut relevante informasjonselementer. En dokumentmodell består i
hovedsak av et utvalgt sett av klasser og tilhørende relasjoner fra informasjonsmodellen.
Disse klassene er i utgangspunktet identiske med klassene i informasjonsmodellen. For å
tilpasse dokumentmodellen den spesifikke rapporteringen er det mulig å skjule attributter,
spesialisere semantiske typer samt gjøre ytterligere innskrenkninger på relasjoner.
Før dokumentmodeller etableres er det viktig at elementene som benyttes fra
informasjonsmodellen har en tilstrekkelig bearbeidingsgrad. De må som minimum være fra en
konform modell.
Hovedfokus for dokumentmodellen:
• Hvilken informasjon som skal utveksles
• Hvilke regler som må oppfylles for at informasjonen skal være gyldig.
Dokumentmodeller som basis for meldingsmodellen, og derav meldingsspesifikasjoner for
inn-/utrapportering eller datatransport mellom systemer.
11

2.4 Meldingsmodell
En meldingsmodell er en dokumentmodell hvor en i tillegg har knyttet formater (gruppert i en
formatfamilie) til de enkelte informasjonselementene. En meldingsmodell er grunnlaget for en
meldingsspesifikasjon.
2.4.1 Formatfamilie
Et format angir hva som er lovlig datainnhold ved utveksling eller lagring. En formatfamilie
er et sett av koplinger mellom semantiske typer og formater. En semantisk type kan ha en slik
kopling til et format, men trenger det ikke. Et format kan være koplet til en eller flere
semantiske typer.
2.4.2 Meldingsspesifikasjon
En meldingsspesifikasjon genereres på grunnlag av en dokumentmodell og en formatfamilie.
En meldingsspesifikasjon er et XML Schema. Denne definerer strukturen av og innholdet i
meldingene som utveksles i form av XML-dokumenter.
Figur 3 viser prosessen fra informasjonsmodell til sluttprodukt i form av XML schema. Det er
verd å merke seg at høyere grad av standardisering av informasjonselementer vil gi et større
potensial for gjenbruk av informasjonselementer på tvers av etatsdomener. Gjenbruk av
informasjonselementer vil også kunne gi gir mer enhetlige meldingsspesifikasjoner.
Økende
gjenbruk
Standardmodell
Harmoniserte
modeller
Konforme modeller
Andre kategorier modeller
Figur 3: Prosessen fra informasjonsmodell til XML Schema
Dokumentmodell
+
XML Schema
Formatdetaljer

3 SERES-profil for UML-basert modellering
Dette kapittelet beskriver hvordan UML profileres og benyttes som modelleringsspråk i
SERES, og gir bakgrunnsinformasjon for å utføre informasjonsmodellering i SERES. For en
detaljert innføring i standard UML-notasjon og -modellering henviser vi til de mange
lærebøkene og referanseverkene som finnes på markedet. Aktuelle bøker er M. Fowler & K.
Scott: UML Destilled (2000), J. Arlow, Ila Neustadt: UML 2 and the Unified Process (2005).
3.1 Generelt om UML
Mye kan forklares muntlig eller skriftlig, men det er også i mange tilfeller svært nyttig å ha en
grafisk notasjon 2 å støtte seg til. En grafisk notasjon kan gjøre det enklere å kommunisere
rundt løsninger, og kan bidra til en stringent og enhetlig forståelse av et problemområde.
SERES benytter UML 3 -diagrammer for å bidra til å beskrive informasjon som ellers er
vanskelig å kommunisere presist.
Modelleringsspråket Unified Modelling Language (UML) forvaltes av et konsortium av
interessenter kalt Object Management Group (OMG). UML ble opprinnelig utviklet for å
skape en felles enhetlig notasjon for utvikling av programvare, og har etter hvert fått stor
utbredelse. Det er standard lærestoff på alle norske høgskoler og universiteter som underviser
i IT.
Språket omfatter i hovedsak et sett med grafiske notasjoner innenfor et antall diagramtyper
utviklet med tanke på forskjellige bruks- og behovsområder. Disse er utviklet med tanke på
forskjellige bruks- og behovsområder. Ved informasjonsmodellering i SERES bruker vi UML
klassediagram.
3.2 UML-komponenter i SERES
Følgende UML-komponenter benyttes i modellering i SERES:
• Klasser
• Attributter inkl. kardinalitet
• Semantiske typer (datatype med stereotype semantisk type)
• Assosiasjoner inkl. kardinalitet
• Assosiasjonsklasser
• Arv
• Klassediagrammer (statisk struktur)
• Pakker
o Informasjonsdiagram (brukt ved informasjonsmodellering)
o Dokumentdiagram (brukt ved dokumentmodellering)
2
Notasjon betyr en måte å beskrive noe. Den er gjerne kompakt og oversiktig i sammenlikning med vanlig tekst.
3
UML betyr Unified Modeling Language og er en internasjonalt anerkjent samling av diagramtyper med
tilhørende symboler for modellering.
13

o Domenemodeller
o Arbeidspakker
o Dokumentmodeller
• Kobling mellom informasjons- og dokumentklasse (avhengighet) (UML dependency)
• Tagged values (navngitte metadata på alle elementer)
Dette er modelleringselementer som er felles for både informasjons- og dokumentmodellering
da dokumentmodeller ekstraheres fra informasjonsmodellen. Likevel er det, slik som tidligere
beskrevet, en forskjell på disse modelleringsformene. Førstnevnte består i å gi en generell
beskrivelse av informasjon og slik bidra til forståelse for informasjonsstrukturer.
Dokumentmodelleringen vil i høyere grad være kontekstspesifikk og ha større fokus på
sluttproduktet i form av meldingsspesifikasjoner. I prosessen fra informasjonsmodell til
dokumentmodell er det ryddig å tenke to trinn:
1. Generalisering
2. Konkretisering
Dermed skjer det en tilpasning av det utsnittet som er gjort av informasjonsmodellen i
henhold til formålet med dokumentmodellen. I følgende gjennomgang blir disse forskjellene
beskrevet hvor det er relevant i henhold til bruk av modellelementer, mens det er ytterligere
beskrevet i kapittel 16.
3.2.1 Eksempel på informasjonsmodelldiagram
Arv
(spesialisering/
generalisering)
Assosiasjonsklasse
Klasse
Attributt Semantisk type
Figur 4: Modellelementer i informasjonsmodelldiagram
Uretta assosiasjon
Assosiasjonsnavn
Assosiasjonsendenavn
(rolle)
Kardinalitet
14

3.2.2 Klasser
I vårt modelleringsperspektiv ser vi på verden som en samling av objekter som vi ønsker å
beskrive. Objektene kan være fysiske, for eksempel i form av et bestemt hus eller menneske,
eller de kan være immaterielle, som for eksempel en bankkonto. Som regel eksisterer det
mange objekter av samme sort. Når vi lager informasjonsmodeller, ønsker vi ikke å beskrive
hvert enkelt objekt, men basert på fellestrekk klassifiserer vi objektene. I en
informasjonsmodell er derfor en klasse en beskrivelse av et utvalg felles egenskaper for en
gruppe objekter. Klasser representeres grafisk i et klassediagram som firkantete bokser med
tre deler med henholdsvis klassenavn, attributter og operasjoner. Operasjoner benyttes ikke i
vår modellering.
3.2.3 Attributter
Vi beskriver objektene ved å tilegne dem egenskaper. De egenskapene som er relevant for
objektene i vårt modelleringsøyemed representerer vi som attributter i klassene. Egenskaper
for en gruppe objekter kan for eksempel være navn og fødselsnummer for personer.
Attributtene består av et attributtnavn og en tilhørende type. Attributtnavnet står foran
kolontegnet, og attributtypen står bak. Typene i SERES kalles semantiske typer.
3.2.4 Semantiske typer
I UML knytter en vanligvis attributtene til datatyper, slik som for eksempel string.
Datatypene sier oss ikke noe presist om semantikken til attributtet, men de sier noe om
hvordan attributtet skal representeres fysisk. Likevel er det å implementere for eksempel et
navneattributt som en string bare en av flere muligheter. Teknisk sett kan string representere
alt. Vi har løsrevet oss fra formatspesifisering i utviklingen av en informasjonsmodell, og
ønsker heller et informasjonssentrert syn hvor semantikken har fokus. Derfor benytter vi
semantiske typer i stedet for datatyper i vår modellering 4 . De semantiske typene definerer
attributtets mening. Basert på valget av semantiske typer står vi fritt til å velge en spesifikk
datatypeprofil senere i prosessen.
De semantiske typene i SERES danner et arvehierarki med der vi tar utgangspunkt i rottypene
som vi kaller grunnleggende semantiske typer (Figur 5). Disse er basert på Core Components
Primary Representation Terms 5 fra UN/CEFACT 6 , og er således forankret i internasjonalt
standardiseringsarbeid. De grunnleggende semantiske typene er generelle og uavhengig av
klassekontekst. Figur 5 viser de grunnleggende semantiske typene med den grafiske
notasjonen som blir brukt i modelleringen. For ytterligere informasjon vedrørende
arvehierarkiet og definisjon av semantiske typer, se Vedlegg I Semantiske typer.
Figur 5: Grunnleggende semantiske typer (rottyper)
4
Det er mulig å modellere med andre sett en SERES semantiske typer, men da vil ikke modellen bli betraktet
som harmonisert.
5
De semantiske typene er spesifisert i dokumentet Core Components Technical Specification, forkortet CCTS.
6
UN/CEFACT er et FN-organ som jobber med elektronisk forenkling av internasjonal handel.
15

3.2.5 Assosiasjoner
En assosiasjon beskriver et forhold mellom to objekter og definerer de rollene de har overfor
hverandre. Noen ganger er rollene symmetriske, men ikke alltid. Forholdet beskriver vi ved å
gi navn på selve assosiasjonen, mens rollene defineres ut fra å gi navn på assosiasjonsendene.
I tillegg kan vi beskrive assosiasjonen ytterligere ved å angi kardinalitet for hver av
assosiasjonsendene. Kardinaliteten angir antall objekter (av klassen koblet til
assosiasjonsenden) som kan inngå i den gitte assosiasjonen til ethvert objekt av klassen koblet
til den andre assosiasjonsenden.
Vi bruker følgende notasjon for kardinalitet:
Kardinalitet Betyr
1 nøyaktig én
0..* mange (null, én eller flere) (standardverdi)
1..* minst én
0..1 kan finnes en, dvs. null eller én
m..n minimum m og maksimum n forekomster.
Eks: 5..7 betyr 5, 6 eller 7
I en generell informasjonsmodell må det tas høyde for ulik organisering av informasjonen.
Derfor er hovedregelen å bruke urettede assosiasjoner. I dokumentmodellen alltid skal det
benyttes rettede assosiasjoner. Navnet rettet assosiasjon er basert på at knytningen mellom
dem består av en retning indikert med en pil. Pilen er basert på hvilken klasse assosiasjonen
tar utgangpunkt i – leseretningen for assosiasjonen.
Retningslinje
• Informasjonsmodell: Urettet assosiasjoner
• Dokumentmodell: Rettede assosiasjoner
3.2.6 Assosiasjonsklasser
Noen ganger ønsker vi å fortelle mer om forholdet mellom objekter enn det vi klarer å
formidle med kardinalitet og navngiving. En assosiasjonsklasse er en assosiasjon som har ett
eller flere attributter, og den uttrykkes visuelt ved både en assosiasjon og en klasse. Det er
viktig å merke seg at klassen og assosiasjonen er ett og samme modellelement som har
egenskaper både som klasse og assosiasjon. En assosiasjonsklasse benyttes til ytterligere å
presisere en assosiasjon, og eksisterer kun i lys av assosiasjonen. Det er dermed ikke mulig å
bruke klassedelen uavhengig av assosiasjonen.
3.2.7 Arv
Arv mellom to klasser uttrykker at det ene klassen er en spesialisering av den andre klassen.
Begrepene subklasse og superklasse brukes for å beskrive forholdet mellom klasser i et
arveforhold:
• Subklasse – en underordnet klasse, et ”barn”
• Superklasse – en overordnet klasse, en ”forelder”
16

Arv reflekterer at noen konsepter eller ideer har fellestrekk, samtidig som de har særegne
egenskaper som gjør dem forskjellige. Spesialiseringen (subklassen) arver alle egenskapene til
superklassen (fellestrekkene) samt at ytterligere egenskaper kan tilføyes, slik at
spesialiseringen får en mer omfattende semantikk. På den annen side vil det være færre
objekter av spesialiseringen enn av den generaliserte klassen.
I SERES tillates ikke multippel arv. Det betyr at en klasse kun får ha én direkte overordnet
superklasse. Begrunnelsen er at informasjonselementene representerer begreper hvor arv (eller
spesialisering) kun innebærer en avgrensning av forekomstene av tilhørende objekter.
Multippel arv er aktuelt der en ønsker å etablere objekter som har egenskaper i flere retninger.
3.2.8 Diagrammer
Diagrammer er navngitte, visuelle sammenstillinger av de modellelementene som inngår i
modelleringen i SERES. I SERES finnes det to ulike typer diagrammer tilknyttet henholdsvis
informasjonsmodellen og dokumentmodeller:
• Informasjonsmodelldiagram (kortnavn informasjonsdiagram) som visuell framstilling ved
informasjonsmodellering
• Dokumentmodelldiagram (kortnavn dokumentdiagram) som visuell framstilling ved
dokumentmodellering
3.2.9 Pakker
Pakker er det sentrale administrative begrepet i SERES og informasjonsmodellen er
sammensatt av et antall pakker. Denne oppdelingen er kun et praktisk grep som brukes til å
gruppere modellelementer, og har ingen prinsipiell føring for semantiske forhold. Alle
modellelementer hører til en og bare en pakke.
Pakkene har en hierarkisk struktur og ulike stereotyper. Pakker på øverste nivå kalles for
domener og knyttes sammen til fagområder og/eller avdelingsinndeling i etater eller
institusjoner. Under domene kan det fritt opprettes arbeidspakker i henhold til hva som
oppfattes hensiktsmessig ved modellering. Dokumentmodeller representeres også ved pakker,
og avgrenser modelleringselementene brukt ved dokumentmodellering fra
informasjonsmodelleringen. Ved opprettelse av dokumentmodeller genereres det pakker med
stereotype ”dokumentmodell”.
3.2.10 Kobling mellom informasjons- og dokumentklasse
En dokumentklasse har en kopling til den informasjonsklassen den stammer fra, men
egenskapene kan være noe endret på den måten at settet av attributter og assosiasjoner er et
subsett av de opprinnelige og at kardinaliteten av de gjenværende attributter og
assosiasjoner kan være smalere enn utgangspunktet. F.eks. kan en assosiasjonskardinalitet på
0..* (null til mange) i dokumentklassen være satt til 1..3 slik at mulige forekomster fastlegges
mer eksplisitt. Vi kaller en slik kopling mellom klasser en begrensende forfiningsavhengighet
(eng: restriction refinement dependency)
3.2.11 Tagged values
All informasjonsmodellelementer i SERES får knyttet på seg et sett tagged values av
type Dublin Core. Dublin Core er en internasjonal standard for administrativ informasjon slik
som forfatter, bidragsyter, utgiverinstitusjon, beskrivelse, versjonsdato, identifikator, språk,
rettighetsinfo etc.
17

3.2.12 Oppsummering
Tabell 1 viser oversikt over modellelementene som blir brukt i SERES og deres bruksområde.
navn : type
Klasse
Attributt
Semantisk type
Modellelementer
Generalisering (Arv)
Uretta assosiasjon
Retta assosiasjon
Assosiasjonsklasse
Tabell 1: Modellelementer i SERES
IM
IM
IM
IM
IM
(IM)
IM
DM
DM
DM
DM
-
DM
DM
18

4 Overordnet om informasjonsmodellering
Dette kapittelet gir en overordnet beskrivelse av prosessen med utforming av
informasjonsmodell.
4.1 Tilnærming til modelleringen
En første versjon av elementene i en modell kan etableres gjennom:
• en ideell betraktning rundt hvordan "verden er", herunder ut fra kunnskap om lover og
forskrifter (top-down approach)
• et sett skjemaer hvor feltene fra disse blir attributter og feltgrupper blir klasser
(bottom-up approach)
• eksisterende modeller f.eks. databasemodeller hvor hver tabell blir en klasse med
samme navn, tabellfeltene blir klasseattributter med samme navn, datafeltypene blir
datatyper med samme navn og fremmednøkler gjøres om til assosiasjoner (UMLkonvertering)
Hvis vi ser bort fra det å benytte eksisterende modeller, er det altså to typiske scenarier for
den praktiske modelleringen i SERES:
En top-down tilnærming på modellering i SERES innebærer at informasjonsmodellen for
domenet først utarbeides basert på en omfattende analyse av begrepene i domenet og deres
sammenhenger. Deretter lager en dokumentmodeller og herav meldingsspesifikasjoner.
En bottom-up tilnærming til modellering i SERES innebærer at en tar utgangspunkt i
detaljbeskrivelser av skjemaer og databaser og bygger informasjonsmodellen ut fra disse.
Dokumentmodeller og meldingsspesifikasjoner lages underveis.
Disse to tilnærmingene har hver sine fordeler og ulemper. Ved å begynne nedenfra fanger en
fort opp relevante detaljer, og det vil være mulig å fremstille meldingsspesifikasjoner etter
kort tid. Ulempen er at informasjonsmodellen lett blir fragmentarisk og mindre velstrukturert.
Helhetsbildet dempes på grunn av fokus på detaljer – ”en ser ikke skogen for bare trær”. Ved
å begynne på toppen vil det være lettere å sikre at helhetsbildet blir konsistent. Ulempen er
først og fremst at viktige detaljer oversees, og at behovet for disse først identifiseres når en
senere setter sammen informasjonselementer for konkrete dokumentmodeller.
En tredje mulighet er å kombinere disse to perspektivene. Da ser vi på modelleringsprosessen
som en syklus der vi veksler mellom en bottom-up og en top-down tilnærming.
Informasjonsmodellen raffineres gjennom stadige iterasjoner, og meldingsspesifikasjoner kan
produseres underveis.
Informasjonsmodell
Skjema 1..N
19

Figur 6: Iterativ veksling mellom perspektiver
Sett fra den enkelte etats side vil modelleringen i de fleste tilfeller starte fra bunnen med
beskrivelse av skjemaer (et bottom-up perspektiv). Samtidig som skjemaene beskrives,
harmoniseres etatens domenemodell med den øvrige informasjonsmodellen, inkludert
grunndata. Dette krever et top-down perspektiv.
Informasjonsmodellen bør utformes slik at den forteller mest mulig på egen hånd uten behov
for å supplere modellen med store mengder skriftlig dokumentasjon. Leseren skal få et god
forståelse av den modellerte delen av domenet bare ved å se på diagrammene og definisjonene
til modellelementene.
4.2 Fokus og kontekst
En modell er ikke en kopi, men en forenkling av virkeligheten. Den som modellerer må derfor
velge hva som er av interesse / essensielt nok til å bli med i modellen, og la være å ta med
andre deler av virkeligheten. Modellereren må stille seg spørsmålene:
• Hva skal modellen brukes til?
• Hva er målgruppen?
Modellen utvikles i en kontekst, dvs. betingelser og omgivelser for modellen. Konteksten
omfatter blant annet applikasjonsområdet, informasjon om hensikten med modellen,
målgruppen, jurisdiksjon, tidsperiode modellen skal være gyldig, hvilken sammenheng
informasjon basert på modellen skal innhentes, tolkes og brukes, hvordan skal modellen
kunne brukes. Når konteksten til en modell er godt beskrevet og forstått, blir også meningen
med modellen klarere. Modellerere vil forstå hverandres modeller enklere, og muligheten for
gjenbruk av modellelementer øker.
Modellereren må utvikle sine modeller varsomt med følgende dimensjoner i tankene 7 :
• Formål, hvor og hvordan modeller og informasjon er tenkt bruk.
• Abstraksjonsnivå, hvor overordnet kan en definere modeller og modellelementene for
data.
• Presisjon, hvor detaljert / presist må en definere modeller og modellelementene for
data.
• Tilstander, hvilke egenskaper er felles for objekter i en bestemt tilstand.
• Kategorier, hvilke klassifiseringer kan modellelementer systematiseres i henhold til.
• Tid, hvordan endres data og tolkning av data over tid. Modeller og definisjoner må
gjenspeile endringsbehovet.
• Rom, hvordan endres data og tolkning av data når objektet de er knyttet til forflytter
seg i rom.
Et viktig poeng i denne forbindelsen er at når et begrep skal modelleres som en klasse, vil
resultatet være avhengig av konteksten. For eksempel, begrepet ”bil” vil normalt modelleres
med ulike attributter om konteksten er Skatteetaten, Biltilsynet eller et bilverksted. Derfor vil
ofte flere domenemodeller inneholde forskjellige klassedefinisjoner av samme begrep. Dette
er en fundamental problemstilling innen semantisk interoperabilitet.
7 Dimensjonene er basert på ISO 15926 og ebXML
20

Jus og forskrifter endres over tid. Dermed må de deler av informasjonsmodellen som er
knyttet til jus endres i takt med dette og versjoneres. Data og tolkningen av data vil være
knyttet til en versjon av informasjonsmodellen. For eksempel vil data som benyttes til
skatteberegning og regnskap har 10 års lagringskrav på seg. I løpende 10 års-intervaller er det
nødvendig å sikre at alle data presist kan relateres tilbake til riktig versjon av
informasjonsmodellen. Liknende livsløp med ulike tilstander vil gjelde både personer og
virksomheter. Virksomheter etableres, de er aktive og de endrer form eller avvikles som
selvstendige virksomheter ved oppkjøp, fusjon, konkurs etc.
5 Teoretisk og språklig forankring for SERES
Når vi skal modellere informasjon, må vi klare å filtrere dagligspråkets manglende presisjon i
beskrivelsen av tidvis komplekse sammenhenger.
Dette kapittelet presiserer hva vi mener med begreper, termer og definisjoner, og gir en del
overordnede regler for hvordan modellelementer skal navngis og defineres. Navngivingsregler
for ulike typer modellelementer beskrives i de spesifikke kapitlene.
5.1 Terminologi, læren om begreper
Kommunikasjon er utveksling av meningsinnhold mellom individer og grupper ved hjelp av
et felles system av symboler 8 . SERES-modeller vil i denne sammenheng være et slikt felles
system av symboler.
Et begrep er en ide, en tanke som vi kan forestille oss. Vi bruker ordet ”bedrift” for å kunne
kommunisere om begrepet som vi kaller Bedrift. Begrepene vi benytter identifiseres ved et
navn som gjør at vi kan kommunisere om dem. Utfordringene vi møter er at noe kan ha flere
navn og gjerne kommuniseres på flere måter. Et og samme ord kan også henvise til ulike
begreper 9 .
Når vi modellerer må vi skille mellom en faktisk person og begrepet kalt Person. For
tydeligere å forstå hverandre i kommunikasjon, er det vesentlig at vi har definisjoner som er
knyttet til begrepet. Figuren under skisserer sammenhengen mellom elementer som til
sammen benyttes for kommunikasjon og modellering.
8 Aschehough og Gyldendals Store Norske Leksikon.
9 I lingvistikken kalles de ulike betydningene av bar for homonymer (herunder homografer med lik skrivemåte
og homofoner med lik uttale).
21

Modellnivå
Forekomstnivå
informasjon
Forekomstnivå
abstrakte eller
konkrete ting
Navn
Begrep
Informasjonsobjekt
Referent
Definisjon
Figur 7: Referent, objekt, begrep, navn og definisjon
Når vi modellerer i SERES, representerer hver klasse og semantiske type et begrep. Vi gir
begrepene navn som brukes til kommunikasjon. I tillegg trenger vi en utdypende definisjon
som gjør det mulig å skille mellom begrep som likner på hverandre, spesielt begreper som har
lik skrivemåte (homografer).
Vår samling av begreper med sine navn og definisjoner utgjør en modell av informasjonen.
Elektroniske meldinger, innhold i skjemaer, databaser e.l. (en teknisk representasjon av noe
som eksisterer) med innhold fra modellen vår kaller vi objekter (instanser). Referentene er de
faktiske tingene som omtales i instansen.
For å lette arbeidet med å utarbeide definisjoner trenger modellereren forståelse for
sammenhengen mellom elementene referent, objekt, begrep, navn og definisjon slik disse er
vist i Figur 7. Elementene i figuren kan defineres på følgende måte:
Referent:
Enkeltstående fysisk eller abstrakt ting, tilstand, handling eller sammenheng man
refererer til gjennom et begrep. Eksempler er "den fysiske personen Sevald Oddsen",
"ditt sykefravær forrige uke", "nåværende budsjett til avdelingen", "bilen din", "et
bestemt prosjekt", "momstilstanden til firma x i 2. kvartal 2005".
Objekt:
Enkeltstående sett av informasjon som er representert i en melding eller i en database.
Eksempler kan være, sykemeldingsblanketten min fra forrige uke, en fil med
nåværende budsjett til avdelingen, informasjon om bilen din, informasjon om et
bestemt prosjekt, siste momsoppgaven som ble levert fra firma x, informasjon om deg
som person.
Navn:
Språklig benevnelse av et begrep.
For å kunne kommunisere at vi tenker på et begrep, må begrepet ha et navn.
Eksempler på navn for begreper kan være: "sykefravær", "budsjett", "bil" eller "alle
Porsche 911", "MVA-oppgave", "enhet".
Definisjon:
Entydig språklig beskrivelse av et begrep. En definisjon bør bygges opp av:
22

• en grunnleggende del som henviser til et overordnet begrep (et hyperonym i et
generisk begrepssystem (dvs. taksonomi))
• en del som presiserer hvilke kjennetegn som skiller dette begrepet fra andre begrep
som har samme hyperonym.
Begrep:
Mental forestilling om et konsept / en ting eller en samling av referenter med
tilhørende navn og definisjon (mer eller mindre presist formulert). Vår forståelse av
hva som er felles for en rekke referenter. Konseptet som vi tenker på skal kunne gjelde
alle referenter.
Definisjonen skal normalt kunne erstatte termen i løpende tekst. Vi kan for eksempel ha
setningen ”Jeg har en sjelden antikvitet du må se”. Hvis vi erstatter i setningen navnet
antikvitet med definisjonen av antikvitet fra tabellen nedenfor, blir den slik: ”Jeg har en
sjelden vare som er mer enn 100 år gammelt og som omfattes av tolltariffens posisjon 97.06
du må se”.
Eksempel på sammenhenger mellom referenter, objekter, navn og definisjoner for begreper:
Referent Førsteutgaven i din
bokhylle
Objekt Lagret informasjon
om boka, f eks
forfatter, tittel, pris
Eksempel 1 Eksempel 2 Eksempel 3
Du som person Sykemeldingen min
for forrige uke
Lagret informasjon
om deg
Lagret
informasjonen fra
sykemeldingsblanketten
Navn Antikvitet Person Sykemelding
Definisjon Vare som er mer
enn 100 år gammel
og som omfattes av
tolltariffens
posisjon 97.06
5.2 Navn og språkregler
Menneske som
basert på
kommende,
nåværende eller
tidligere
tilstedeværelse eller
handlinger har en
relasjon til en eller
flere enheter i norsk
offentlig sektor og /
eller norsk lov.
Sett av informasjon
for utveksling som
beskriver en
sykdomstilstand og
periode for en
person i et
arbeidsforhold,
hvor hensikten er å
få formalisert
grunnlaget for en
trygdeytelse
5.2.1 Bruk av norsk språk
Det er krevende å lage en informasjonsmodell, og for å lykkes må en ha svært god kontroll
med begreper og deres relasjoner til hverandre. Vi har derfor valgt å bruke norsk, nærmere
bestemt bokmål, i informasjons-modellen. Vår informasjonsmodell skal i hovedsak være en
23

norsk virkelighetsbeskrivelse, og da vil bruk av et fremmed språk, for eksempel engelsk, være
til hinder for dette. Vi finner det også hensiktsmessig å benytte norske navn på de semantiske
typene, slik at informasjonsmodellen fremstår språklig rendyrket og derigjennom mest mulig
forståelig.
5.2.2 Navnestandarder
I SERES velger en modellerer navn på modellelementer som pakker, diagrammer, klasser,
attributter, semantiske typer, relasjoner, relasjonsender. I tillegg velger modellereren navn på
formater og formatfamilier.
Navnet på et modellelement brukes for å kunne skille et begrep fra andre begreper. Samtidig
bør navnet gi en indikasjon om hva betydningen av begrepet er. Navnet til et modellelement
brukes ved generering av XML Schema og blir synlige for teknisk personell som skal lage
systemer som tar imot, bearbeider eller avgir data i henhold til modellene som defineres i
SERES-systemet.
Eksport av modeller fra SERES på ulike formater (XMI eller XML Schema) stiller av
tekniske årsaker visse krav til elementnavn. Får å unngå at det oppstår navnevarianter ved
transformering i produksjonsløypen, er regelverket for navngivning påvirket av dette, spesielt
bruken av CamelCase (ref. ordliste).
5.2.3 Generelle retningslinjer for navngiving
• Det skal brukes norsk bokmål i informasjonsmodellen, både på navn på
informasjonselementer og dets definisjoner
• æ, ø, å er tillatt
• Bruk det navnet som er mest karakteristisk for elementet
• Bruk entallsform for begreper der slike finnes
• Navnet bør ha god uttrykkskraft at man langt på vei kan forstå meningen ut fra navnet
alene.
• Navnet bør være forståelig for allmennheten og akseptert av fagmiljøet.
• Forsøk å bruke vanlige hverdagslige termer og spar faguttrykk til definisjoner eller
andre tekster.
• Navnet skal gjenspeile informasjonselementets eventuelle definisjon.
• Ikke bruk spesialtegn eller tegn som understrekning, skråstrek, punktum, komma etc.
• Dersom flere ord i navnet, sett sammen ordene til et sammenhengende ord uten
mellomrom ved hjelp av CamelCase.
• Unngå engelskinspirert ordoppdeling slik som årsGjennomsnitt. Skriv årsgjennomsnitt
ettersom dette er ett sammenhengende ord.
• Iblant må en relatere norsk begrepsbruk til internasjonale termer. Bruk
modellelementets beskrivelse til å legge inn synonymer, eller henvisning til hvilken
internasjonal term som er fornorsket.
• Ikke lag egne forkortelser, men bruk allment kjente forkortelser som ”nr”, ”id” og så
videre. Se vedlegg III for liste av slike.
• Forkortelser skrives på den vanligste måten, tillater store bokstaver på hele
forkortelser.
5.2.3.1 Navngiving av klasser
Navnet på en klasse skal:
• være unikt i pakken
24

• ha stor forbokstav
• helst velges uavhengig av diagram og pakke, slik at andre lettere ønsker å gjenbruke
dem
• helst være basert på ett ord, f.eks. "Person", "Bedrift"
• skrives i UpperCamelCase dersom navnet kommer fra to eller flere ord
• ikke ha sammenbindingsord som "av", "i", "til" etc. med mindre navnet kan misforstås
uten
Eksempler på anbefalte klassenavn:
• Fartøy
• SalgGrunneiendom (alt. GrunneiendomSalg)
• Omsetningstabell (alt. TabellOmsetning)
• Pasientstatus (alt. StatusPasient)
• MidlertidigAnsatt (alt. AnsattMidlertidig)
Eksempler på dårlige klassenavn:
• FirmaBil: Ordet er sammenhengende på norsk: Firmabil.
• Kundeinfo: Klassen inneholder informasjonselementer, derfor er ” info”-delen av
navnet redundant.
• Personklasse: Navnet betegner en klasse, derfor er ”klasse”-delen av navnet
overflødig.
5.2.3.2 Navngiving av attributter
Navnet på attributtet bør være enkelt, gjenspeile definisjonen og
• være unikt i klassen
• ha liten forbokstav med mindre ordet starter med en forkortelse som er vanlig å skrive
med store bokstaver
• helst bestå av ett ord
• skrives i lowerCamelCase dersom navnet kommer fra to eller flere ord
• ikke ha sammenbindingsord som "av", "i", "til" etc. med mindre navnet kan misforstås
uten
Ved modellering av blanketter vil det være tilfeller der det er behov for å utrykke lengre
feltbeskrivelser ved hjelp av attributter. For å unngå for lange attributtnavn er det verdt å
merke seg at attributtnavnet får tilført betydning ut fra sin klassekontekst og tilhørende
semantiske type. En kan derfor gjerne unngå navneledd som er en kopi av disse.
Eksempler på anbefalte attributtnavn:
• fødselsnummer
• førsteArbeidsdag (alt. arbeidsdagFørste)
• skattemessigBruttoinntekt (alt. bruttoinntektSkattemessig)
• gebyrAksjesalg
Eksempler på dårlige attributtnavn:
• fødselsNummer (Er ett ord på norsk)
• personNavn (Er ett ord på norsk. Dessuten er det sannsynlig at klassenavnet er Person
og typen er navn)
25

• antallEgenmeldinger (Inneholder navn på den semantiske typen antall. Bedre:
egenmeldinger: antall)
5.2.3.3 Navngiving av semantiske typer
Navnsetting for semantiske typer bør være som for klasser. Navnet bør være enkelt, gjenspeile
definisjonen og:
• ha liten forbokstav, med mindre ordet er en forkortelse som er vanlig å skrive med
store bokstaver
• bestå av ett ord eller være en forkortelse som representerer flere ord
• være unikt i pakken
• helst velges uavhengig av diagram og pakke, slik at andre lettere ønsker å gjenbruke
dem
5.2.3.4 Navngiving av assosiasjoner og assosiasjonsender
For assosiasjoner har vi mulighet til å navngi både selve assosiasjonen og assosiasjonsendene
(rollene). Navnet på assosiasjonen skal være beskrivende for det forhold det uttrykker. Navnet
på assosiasjonsenden beskriver rollen/relasjonen objektet på motsatt side av relasjonen har til
dette objektet (klassen der rollen står). Navnene vil som regel være forskjellige i de to endene
av en assosiasjon. Dersom det er naturlig å gi assosiasjonsendene samme navn, bør en
alternativt gi assosiasjonen dette navnet og la endene være uten navn.
• Assosiasjoner skal ha navn enten i form av assosiasjonsnavn eller
assosiasjonsendenavn
• En klasses assosiasjoner skal ha unike assosiasjonsnavn og assosiasjonsendenavn (de
som står lengst fra selve klassen)
• Navnet skal ikke være likt et av attributtnavnene i klassene assosiasjonen knytter
sammen
• Ved bruk av assosiasjonsendenavn skal:
o rettede assosiasjoner ha beskrivende navn på pilenden.
o urettet assosiasjoner ha navn i begge ender
• Navnet skrives med liten forbokstav og i lowerCamelCase dersom navnet kommer fra
to eller flere ord med mindre det er en forkortelse som består av store bokstaver
5.2.3.5 Navngiving av assosiasjonsklasser
Her gjelder de samme regler som for klasser, se kapittel 5.2.3.1.
5.2.3.6 Navngiving av pakker
Pakker er det sentrale administrative begrepet i SERES. På øverste nivå finner vi de ulike
domenemodellene som kan inneholde pakker både i form av arbeidspakker og
dokumentmodeller.
• Navnet på domenemodeller skal være unikt blant andre domenemodeller, mens navnet
på arbeidspakker og dokumentmodeller er unikt innenfor sin domenemodell
• Navnet på dokumentmodeller bør beskrive et bruksområde for modellelementer
• Navnet skrives med stor forbokstav og i UpperCamelCase dersom navnet kommer fra
to eller flere ord
26

5.2.3.7 Navngiving av diagrammer
• Navnet er unikt innenfor sin domenemodell
• Navnet skrives med stor forbokstav og i UpperCamelCase dersom navnet kommer fra
to eller flere ord
27

6 Grunnleggende semantiske typer
I dette kapittelet presenteres de grunnleggende semantiske typene (toppnodene) som tidligere
nevnt tilsvarer Core Components Primary Representation Terms. Disse er røtter i hvert sitt tre.
Vi har valgt ikke å ha et nivå over disse igjen slik at alt ligger i ett tre.
6.1 alternativ
Den semantiske typen alternativ uttrykker to gjensidig utelukkende boolske verdier. Det vil si
utfall i situasjoner der man skal indikere om en påstand er sann/usann. Eksempler på dette er
om en person:
• er myndig eller ikke myndig
• har barn eller ikke har barn
6.2 antall
Den semantiske typen antall brukes til å angi tellbare mengder. Det er valgt å la antall være en
grunnleggende type og ikke en avledning av tall ettersom det er en fundamental forskjell
mellom tellbare mengder og beregnete forholdstall. Eksempler på hva som bør betegnes som
antall er som følger:
• antall ansatte (antall arbeidsforhold, ikke antall stillingsandeler)
• antall solgte enheter (når disse telles, ikke veies e.l.)
6.3 beløp
For å angi konseptet "en mengde penger" (eller en verdi som kan byttes i samme) bruker vi
den semantiske typen beløp. Denne typen inneholder informasjon både om det numeriske
beløpet og hvilken valuta beløpet er i. Valuta kan koples til en valutakodeliste gjennom et
kompleksformat. Eksempler på den semantiske typen beløp:
• 25 000 NOK
• 150 USD
• 3 450 GBP
6.4 binærobjekt
binærobjekt er en semantisk type som representerer en navnet og enhetlig bytesekvens. Dette
representerer som oftest filer.
6.5 identifikator
Den semantiske typen identifikator brukes for eksplisitt å identifisere et objekt i en mengde av
objekter. Ved hjelp av en slik unik identifikator kan man skille objekter fra hverandre. Det er
viktig å merke seg at en identifikator bare er unik innenfor et identifikasjonsregime. F.eks. er
et studentnummer bare unikt innenfor et gitt universitetsdomene. Et husnummer er bare unikt
innenfor en gate. identifikatorer skal normalt være tilknyttet et forvaltningsorgan /
forvaltningsregime. For eksempel er det Folkeregisteret som forvalter fødselsnummer.
28

Identifikatorer som ikke forvaltes av noen, skal settes abstrakte, dvs. ikke kunne brukes i en
dokumentmodell.
6.6 kode
Den semantiske typen kode brukes gjennom spesialiseringer for kopling til Kodelister En
kodeliste er en samling elementer, kalt kodelisteelementer, som hver har en kode og en
definisjon.
Et attributt knyttet til en slik semantisk type vil lovlig måtte ha en verdi fra kodelisten.
sivilstand er et typisk eksempel på en spesialisering av kode. En tilhørende kodeliste består
f.eks. av kodene "enslig", "samboer", "gift", "partnerskap", "skilt", "enke/-mann", "ukjent". Et
attributt av type sivilstand må ha en verdi blant akkurat disse elementene.
Dersom et attributt koples direkte til kode, må denne koplingen endres i en Dokumentmodell
ettersom kode er Abstrakt (se ordliste).
6.7 mål
Den semantiske typen mål brukes for fysiske størrelser som måles med et verktøy eller
instrument. Både faktisk målte størrelser og størrelser som planlegges for senere måling
kommer inn under denne typen. Et mål består av en numerisk verdi og en fysisk enhet.
Eksempler på mål er:
• lengde (6,43 m)
• arealet (24 m 2 )
• masse (83 kg)
• hastighet (15 m/s)
• temperatur (37 ˚C)
6.8 tall
Den semantiske typen tall brukes til å angi dimensjonsløse (uten enhet) størrelser. Dette er
enten forholdet mellom to tellbare størrelser av samme enhetstype (ref. semantisk type antall)
eller forholdet mellom to målbare størrelser av samme måleenhet (ref. semantiske typer mål
og beløp) eller en matematisk funksjon av andre tall. Eksempler på tall:
• 7,9
• 14
• -294,364489
6.9 tekst
Den semantiske typen tekst er en type som samler alle typer tekstlige uttrykk. Vi anbefaler å
bruke spesialiseringene av typen navn og beskrivelse eller egne spesialiseringer.
Et navn er den offisielle betegnelsen for en ting, person, firma, sted, produkt, konsept osv. Et
navn brukes primært som en praktisk, dagligdags referanse. Forskjellen på et navn og en
identifikator er at navn ikke må være unikt i et domene. Det er mulig for to personer å ha
samme navn selv om de jobber i samme bedrift eller trener på samme treningsstudio.
Eksempler på navn:
• Ola Normann
29

• Oslo
• Aker Kværner
• Nord-Trøndelag
Den semantiske typen beskrivelse gir tilleggsinformasjon om et konsept som for eksempel en:
• kommentar
• hjelpetekst
• hinttekst
6.10 tidspunkt
tidspunkt er en semantisk type som betegner et punkt i historisk tid, dvs. en gitt dato og
klokkeslett i et bestemt år, f.eks. 17. mai 2006 kl. 10:00 (”avmarsj for barnetoget”). Typen
uttrykkes ved å bruke dato og klokkeslett.
30

7 Eksempel - Flyttemelding
I dette kapittelet presenterer vi et eksempel som senere brukes til å illustrere
modelleringspraksis i SERES. Skjemaet RF-1400 Melding til folkeregisteret om flytting
innenlands (heretter kalt flyttemelding) brukes for å melde fra om at en eller flere personer
flytter fra en adresse til en annen. Hvis det for eksempel er en familie som flytter, kan alle
familiemedlemmene registreres på det samme skjemaet.
Skjemaet inneholder opplysninger om selve flyttingen (når den skal finne sted, gammel og ny
adresse osv.), og om hver enkelt person som flytter (navn, fødselsnummer osv.). Dette
hentyder at det er minst to ”ting” (to typer objekter) Det sentrale folkeregisteret ønsker å vite
noe om: Selve flyttingen, og hver enkelt person (en eller flere) som flytter.
Figur 8: Blanketten "Melding til folkeregisteret om flytting innenlands"
Blanketten inneholder også minst to ulike adresser: gammel og ny. I noen tilfeller har vi også
en tredje adresse: Postadresse. Den benyttes hvis posten skal sendes til et annet sted enn
boligadressen, for eksempel hvis de som flytter har en postboks. Alle disse adressene kan ha
flere ulike elementer, for eksempel postnummer og poststed.
I tillegg ser vi at det finnes to ulike typer tilflyttingsadresser: Gateadresse og Stedsadresse
(Stedsadressen brukes der det ikke er gatenavn).
Kontaktinformasjon er felles for alle som flytter, og består av ulike adresser for elektronisk
kommunikasjon (epost, telefon). Denne informasjonen kan enten betraktes som relatert til alle
personene som flytter, eller som relatert til flyttingen.
31

Eksemplene i de neste kapitlene tar utgangspunkt i dette skjemaet. Først illustreres bruken av
de enkelte modellelementene med eksempler fra dette skjemaet. Deretter vises et eksempel på
en samlet modell for informasjonsinnholdet i skjemaet i kapittel 13. Felt som er merket som
til internt bruk hos folkeregisteret er ikke tatt med i modellene.
32

8 Klasser
Klasser skal ha definisjoner eller beskrivelser som presiserer deres meningsinnhold. I kapittel
5 er det beskrevet hvordan slike beskrivelser skal se ut.
En klasse skal representere en type fysisk ”ting” eller et abstrakt (immaterielt) begrep. I
flyttemeldinga kan en person være et eksempel på et fysisk objekt, mens flyttingen er et
immaterielt begrep – vi kan ikke ta på en flytting, selv om vi kan beskrive egenskaper ved
den.
Eksempler på mulige klasser i skjemaet for flyttemelding:
• Person Egenskaper til personer som flytter
• Flytting Egenskaper ved selve flyttingen
8.1 Antall attributter
Som en hovedregel bør en klasse inneholde 2-10 attributter. Hvis det blir færre eller flere enn
dette bør man vurdere å endre på modellen ved å slå sammen eller dele opp klasser.
Ideelt bør en klasse representere ett og bare ett konsept i den virkelige verden, helst et
velforstått og velavrundet begrep. Glushko og McGrath (2005) kaller dette essensialitet – en
modellelementer skal kun inneholde essensielle komponenter, ellers vil modellen kunne bli
tvetydig og integriteten svekkes.
Hvis en og samme klasse representerer flere ulike konsepter vil det kunne oppstå situasjoner
der egenskaper ved et objekt vil kunne endre seg uten at det var meningen, fordi objektet i
praksis er ”låst fast” i et annet.
Fra beskrivelsen av flyttemeldinga vet vi at en person må forholde seg til minst to ulike
adresser – gammel og ny adresse. Dette tyder på at adresser er et separat begrep fra person,
person- og adresseinformasjon bør skilles fra hverandre. En person vil (forhåpentligvis) alltid
være tilknyttet en adresse, men hvilken adresse vil variere over tid. Adressen eksisterer
uavhengig av personene som bebor den. Dette kan vi uttrykke ved å lage separate klasser for
adresse og person, for eksempel som i Figur 9
Figur 9: Essensiell personklasse
33

8.2 Normalisering
Det vi i praksis har gjort i eksempelet over kalles normalisering. Det finnes formelle regler for
hvordan normaliseringen gjennomføres, men i praksis kommer vi langt med sunn fornuft og
en bevissthet om at en klasse kun skal representere ett konsept i den virkelige verden. Det
finner noen formelle normaliseringsregler beskrevet i diverse litteratur, for eksempel Glushko
og McGrath (2005) og Date (2003). Og i noen tilfeller kan det være aktuelt å bruke disse
formelle normaliseringsreglene. Med som oftest vil modellene ”normalisere seg selv” i løpet
av prosessen med å utvikle en modell, rett og slett fordi det viser seg at en normalisert struktur
er hensiktsmessig av andre grunner enn de rent normaliseringstekniske. Om det oppdages
brudd på normalformene er det ikke sikkert at det er hensiktsmessig å splitte opp klassene; de
har tross alt fått sin form i løpet av en bevisst modelleringsprosess der det har blitt bestemt at
klassene representerer virkeligheten på en hensiktsmessig måte. Dette er en avveining som må
gjøres i hvert enkelt tilfelle.
Retningslinje: Essensialitet
• En klasse bør representere ett og bare ett konsept fra den virkelige verden
Retningslinjer: Klasser
• En klasse skal fange essensen til ett enkelt begrep
• En klasse har vanligvis 3-15 attributter
34

9 Attributter
Klasser inneholder som oftest et antall attributter. Attributtene representerer egenskaper ved
objekter (instanser av klassen), og vil som regel ha forskjellige verdier for ulike objekter.
9.1 Attributtenes semantikk
Et attributt får mye av sin semantiske mening (om ikke alt) i kraft av klassen det befinner seg i
og attributtets semantiske type, i tillegg til dets navn.
Attributter tilordnes alltid en semantisk type, som sier noe om attributtets generelle
meningsinnhold, uavhengig av hvilken klasse det befinner seg i.
Betydningen av attributtet i den konkrete klassen det tilhører presiseres gjennom attributtets
navn. Navngiving er derfor viktig, se kapittel 5.2. For å presisere betydningen av attributtet
ytterligere kan det gis en definisjon eller en beskrivelse.
I skjemaet for flyttemelding ser vi at det skal oppgis fornavn, etternavn og eventuelt
mellomnavn for personene som flytter. Dette kan vi betrakte som tre ulike attributter. Alle
disse er en type navn, og kan derfor knyttes til den semantiske typen navn. Attributtenes navn
(fornavn, mellomnavn og etternavn) presiserer betydningen av attributtet i klassen. Vi skal
også oppgi flere opplysninger om hver person, blant annet sivilstand og fødselsnummer. En
person-klasse med disse attributtene vil kunne se slik ut:
Figur 10: Person-klassen
Her ser vi at attributtenes typer forteller hva den generelle betydningen av attributtet er, mens
navnet til attributtet forteller hva attributtet betyr i den konkrete klassen.
9.2 Avledete verdier
Mange skjemaer innholder felter med avledet informasjon. Det vil si informasjon som kan
beregnes på grunnlag av verdien til andre attributter i samme eller andre objekter, for
eksempel summeringer.
En bør vurdere nøye om det faktisk er nødvendig å ta med slike attributter i
informasjonsmodellen, da de teknisk sett inneholder overflødig informasjon. Faktorer som
kan begrunne at det er nødvendig å ta med attributter med avledede verdier:
• At en vil bruke den avledete verdien til å avsløre feil i grunnlagsverdiene
35

• At det er knyttet særskilte juridiske kvalitetskrav til den avledete verdien, men ikke til
grunnlagsverdiene
Glushko og McGrath (2005) anbefaler at en unngår avledede attributtverdier i modellen, da
det bryter med essensialitetsprinsippet – en modell skal ikke inneholde dupliserte eller
overflødige elementer.
36

10 Arv som presisering av semantikk
Spesialisering ved hjelp av arv innebærer en presisering (avgrensning) av semantikken til en
klasse eller en semantisk type i forhold til en annen.
10.1 Klasser
Skjemaet for flyttemelding spesifiserer tre ulike spesialiseringer av adresse – gateadresse,
stedsadresse og postadresse. De tre spesialiseringene innsnevrer betydningen av adressebegrepet,
for eksempel er ikke alle adresser gateadresser, men alle gateadresser er adresser. I
tillegg til at betydningen av klassene er ulike, så ser vi også at de har ulike attributter.
10.1.1 Identifisering av arveforhold
Noen ganger vil modeller få to eller flere klasser som har beslektede betydninger, men ikke er
knyttet sammen i et arvehierarki. Da bør en vurdere å lage en felles superklasse for dem.
Attributter som er felles flyttes opp i superklassen. Det er viktig at en slik prosess ikke bare
skjer på bakgrunn av at klassene har felles attributter, men på bakgrunn av at
meningsinnholdet (semantikken) til klassene faktisk er beslektet. I visse tilfeller kan det være
hensiktsmessig å lage subklasser som ikke har ekstra attributter i forhold til sin superklasse,
men som likevel har en annen definisjon eller andre assosiasjoner enn superklassen.
Fra flyttemeldingseksempelet kjenner vi til eksempelet med steds- og gateadresser. Det er en
situasjon der to klasser er semantisk lignende, slik at det vil være aktuelt å gi dem en felles
superklasse, slik som i Figur 12.
Retningslinje: Felles superklasse
• Meningsinnholdet (semantikken) til to eller flere klasser må være beslektet for at de skal
kunne ha en felles superklasse. Det er ikke nok at de har felles attributter.
Retningslinje: Felles attributter
• Attributter som er felles mellom subklasser skal plasseres så langt opp i arvehierarkiet
som mulig
Noen ganger vil det finnes klasser der de aller fleste instansene kun benytter noen få av
attributtene. Det er altså mange attributter som aldri blir gitt noen verdi i de faktiske
objektene. Dette kan tyde på at klassen egentlig representerer to ulike nivåer av spesialisering.
Da bør det vurderes om klassen skal deles i to: en super- og en subklasse.
Retningslinje: Klasser med attributter som sjelden benyttes
• Når en har attributter i en klasse som er ubenyttet i mange av instansene, bør en vurdere å
splitte klassen i to eller flere nivåer av spesialisering.
10.1.2 Attributter i subklasser
Spesialiserte klasser arver alle attributtene fra sin superklasse. Ofte vil en ønske å tilføye
ekstra attributter for den spesialiserte klassen, slik som i Figur 12.
I eksempelet betyr det i praksis at klassen Gateadresse har attributtene postnr, poststed,
gatenavn, husnummer, husbokstav, bolignr og tilleggsadresse. Attributter i en subklasse bør
37

ha navn som ikke er brukt i dens superklasser. Grunnen til dette er at en i praksis vil få flere
attributter med samme navn i subklassen på grunn av at attributtene arves fra superklassen.
10.1.3 Alias for attributter
I subklasser kan en definere et attributt som alias for et attributt i superklassen. Det betyr at
attributtet i subklassen erstatter attributtet som arves fra superklassen. Dette gjøres typisk for
identifikatorer. For eksempel kan en ha den generelle identifikatoren id i superklassen Subjekt,
og i subklassen Person ha fødselsnummer som alias for id. Det betyr da at fødselsnummer
overtar plassen til id i Person-klassen. Visuelt ser dette slik ut:
Figur 11: Bruk av alias for attributter
Attributter som er alias for et annet, må ha en semantisk type som er subtype av typen til
attributtet den erstatter. I eksempelet er både fødselsnummer og organisasjonsnummer
subtyper av identifikator.
10.1.4 Flyttemeldingseksempelet
Ved å benytte reglene som er diskutert over kan vi lage følgende modell for adressebegrepene
i flyttemeldinga:
Figur 12: Spesialisering – Postadresse, gateadresse og stedsadresse er en spesialisering av Adresse
38

10.1.5 Form på arvehierarki
Arvehierarki kan både vokse i dybden eller i bredden. Sammenlignet med biologisk slektskap
er dette slik:
• Bredt arvehierarki
o Mange søsken, men få ”generasjoner”, altså få arvenivåer.
• Dypt arvehierarki
o Mange generasjoner, men få søsken på hvert nivå.
Figur 13: Eksempler på henholdsvis brede og dype arvehierarkier
10.1.6 Konsekvenser av brede/dype arvehierarki
Arv er en av mekanismene som UML stiller til rådighet for å beskrive virkeligheten. Vi bør
derfor utnytte denne mekanismen for å lage beskrivelsene så gode som mulig. Hvis begreper i
virkeligheten faktisk er spesialiseringer av et annet begrep, bør dette vises i klassediagrammet.
Et bredt og grunt arvehierarki kan derfor være et symptom på en ufullstendig analyse av
slektskap mellom begreper.
Et arvehierarki med svært mange søsken på ett nivå kan også indikere at en har modellert
forskjellige instanser av en klasse, og at nivået derfor er unødvendig.
For eksempel kan en tenke seg at klassen Kommune har subklassene Bergen og Ringerike. De
to subklassene beskriver kun én konkret forekomst av en kommune. Hvis det kun kan bli én
instans (det vil kun finnes ett objekt) av hver klasse, bør det undersøkes om man egentlig har
modellert en instans i stedet for en klasse. I dette eksempelet bør derfor subklassene Bergen
og Ringerike fjernes.
Retningslinje: Klasser med kun én instans
• Hvis det finnes klasser der det kun kan forekomme én instans, bør en vurdere om
klassehierarkiet har for mange spesialiseringer
På den andre siden kan altfor dype arvehierarkier føre til uoversiktlige modeller som er
vanskelige å lese. En klarer ikke å danne seg et fullstendig bilde av hva en klasse faktisk
representerer uten å ta med alle dens superklasser i vurderingen. Det blir spesielt vanskelig å
lese modellen hvis det er mange assosiasjoner knyttet til superklasser på ulike nivåer, siden
assosiasjoner også arves. En bør alltid ha i tankene at formålet med modellene er å formidle
informasjon om informasjonsstrukturer. Lite lesbare modeller gjør formidlingen vanskelig.
Dette kan tale for å begrense dybden på arvehierarki.
39

10.2 Spesialisering av semantiske typer
Arv mellom semantiske typer betyr at den typen som arver er en semantisk begrensning i
forhold til den typen det arves fra. ”fødselsnummer” er aktuell som semantisk type som arver
fra den grunnleggende semantiske type ”identifikator”. Når den semantiske typen B arver fra
den semantiske typen A, betyr det at den semantiske meningen i B er en begrensning i forhold
til den semantiske meningen til A. ”A23” vil for eksempel være lovlig verdi for den
semantiske typen identifikator, men vil ikke være en lovlig verdi for den semantiske typen
fødselsnummer.
Alle brukere av SERESuml kan lage nye semantiske typer, men nye typer må være subtyper
av en allerede eksisterende semantiske type. En bør alltid undersøke nøye om det er mulig å
bruke en eksisterende semantisk type, før en oppretter en ny. Lag en ny semantisk type hvis
det er mulig å gi typen en definisjon som er uavhengig av klassen det skal stå i og helt
bestemte attributter den er tenkt brukt for.
Retningslinjer: Semantiske typer i informasjonsmodellen
• Bruk generelle semantiske typer
• En ny semantisk type må være en subtype av en eksisterende semantisk type
• En forutsetning for å lage en nye semantisk type er at det er mulig å skrive en klar,
kortfattelig, og presis definisjon.
40

11 Assosiasjoner
Alle klasser i informasjonsmodellen skal være knyttet til minst én annen klasse, enten via
assosiasjon eller med arv. Dette for å sikre at modellen ”henger sammen”, og at det finnes
knytninger til grunndata.
Retningslinje: Assosiasjoner mellom klasser
• En klasse i informasjonsmodellen må være knyttet til minst en annen klasse i
informasjonsmodellen med assosiasjon og/eller arv.
11.1 Urettet assosiasjon
En urettet assosiasjon viser at det er en sammenheng mellom to objekter, og at begge kjenner
til eksistensen av det andre objektet.
Figur 14: Urettet assosiasjon
I eksempelet over går det an å finne personer som deltar i en flytting, og det er også mulig å
finne alle flyttingene en person har deltatt i.
Assosiasjonen tolkes slik:
• En person deltar i en eller flere flyttinger
• En flytting gjelder en eller flere personer
11.2 Rettet assosiasjon
I informasjonsmodeller skal det fortrinnsvis benyttes urettede assosiasjoner. Rettede
assosiasjoner bør kun brukes unntaksvis. Rettede assosiasjoner beskrives nærmere i kapittel
Feil! Fant ikke referansekilden. i forbindelse med dokumentmodellering.
11.3 Kardinalitet
I SERES er spesifisering av kardinalitet for assosiasjonsender påkrevd, og standard UMLnotasjon
benyttes.
Evnen til å generalisere til riktig nivå er viktig ved fastsettelse av kardinalitet. Hva som er
riktig kardinalitet i en konkret modell vil blant annet avhenge av hvilket tidsperspektiv vi har
når vi modellerer (i øyeblikket eller over tid).
41

For eksempel må vi bestemme om modellen av flyttemelding skal vise et øyeblikksbilde –
”situasjonen når en bestemt flyttemelding leveres”, eller om modellen skal håndtere endringer
over tid – ”summen av alle flyttemeldinger”. Hvis vi velger å modellere et øyeblikksbilde, er
det tilstrekkelig å si at en person er tilknyttet kun én flytting – den som foregår i øyeblikket.
Hvis vi derimot skal ha et lengre tidsperspektiv, må vi vise at en person kan ha flyttet flere
ganger, og dermed være tilknyttet flere flyttinger.
Når vi skal lage et klassediagram, må vi passe på at diagrammet kan håndtere alle de mulige
kombinasjonene i den virkeligheten som vi har valgt å modellere.
I de fleste tilfellene er det mest hensiktsmessig å bruke de generelle identifikatorene for
kardinalitet (0, 1, *) i informasjonsmodellen. To mulige varianter for kardinaliteten til
assosiasjonen mellom person og flytting blir slik:
Figur 15: ”Øyeblikksbilde”-modell av flytting
Figur 16: "Over tid"-modell av flytting
Det som er et 1:m forhold i et øyeblikksbilde, kan ofte gå over til å bli m:n forhold i en modell
som skal representere virkeligheten over tid. 1:1 forhold vil kunne bli 1:m forhold på samme
måten. Vær derfor alltid bevisst på om modellen er et øyeblikksbilde eller om den skal kunne
representere at ting forandrer seg over tid.
Når en modellerer konkrete blanketter, vil en ofte finne 1-til-mange (1:m) forhold. For
eksempel kan en bedrift rapportere inn informasjon om mange tilsatte. Det vil ofte være slik at
når en går fra en spesifikk blankett til en generell, skjemauavhengig beskrivelse av
virkeligheten, så forandrer 1:m-forholdet seg til et mange-til-mange-forhold (m:n).
I SERES ønsker vi vanligvis å lage informasjonsmodeller som er så generelle som mulig.
Derfor bør kardinaliteten i de fleste tilfellene være slik at den er i stand til å representere
42

endringer som skjer over tid, og den bør håndtere virkeligheten utover det som er beskrevet i
en enkelt blankett.
Retningslinje: Kardinalitet for assosiasjoner i informasjonsmodell
• Kardinalitet skal oppgis for begge ender av en assosiasjon
• I de fleste tilfellene bør kardinaliteten tillate representasjon av endringer over tid
• I de fleste tilfeller bør kardinaliteten tillate representasjon av objekter fra mer enn en
konkret blankett
11.4 Flere assosiasjoner mellom to klasser
I noen tilfeller eksisterer det to eller flere forhold mellom objekter, med ulik betydning. Disse
modelleres da som separate assosiasjoner. Eksempel: To personer kan være i slekt med
hverandre, men en person kan også være arbeidsgiver for en annen. Dette er to separate
forhold: slektskap og arbeidsforhold. Andre ganger kan flere beslektete forhold mellom
klasser beskrives med assosiasjonsklasser og kodelister.
11.5 Assosiasjonsklasser
Figur 17: Assosiasjonsklasse
I flyttemeldingen har vi sett at hver flytting har et forhold til minst to adresser: gammel
adresse og ny adresse, og i noen tilfeller også postadresse. Det går ikke an å se på en adresse i
seg selv om den er en gammel eller en ny adresse for en person, og adressen kan spille ulike
roller for forskjellige flyttinger – noen flytter fra et hus, mens andre flytter til huset.
Spesifisering av gammel og ny adresse kan derfor betraktes som en egenskap ved
assosiasjonen mellom flytting og adresse, og dermed representeres som en assosiasjonsklasse.
Vanligvis vil assosiasjonsklasser ha relativt få attributter. Hvis de har flere enn ca 2-3
attributter, vil det ofte være et tegn på at vi har innført et nytt konsept i modellen, som kanskje
heller skulle vært modellert som en selvstendig klasse med assosiasjoner til de to opprinnelige
klassene. Av samme grunn vil heller ikke assosiasjonsklassene inngå i arveforhold eller ha
assosiasjoner til andre klasser.
Regler: Assosiasjonsklasser
• En assosiasjonsklasse skal vanligvis ikke ha mer enn 3 attributter
• En assosiasjonsklasse kan ikke ha arveforhold eller vanlige assosiasjoner til andre klasser
43

11.5.1 Attributter i assosiasjonsklasser
Prinsipielt er det to hovedtyper attributter i assosiasjonsklasser:
A: Attributtet beskriver et antall ulike assosiasjoner som kan forekomme mellom
objektene
I eksempelet med assosiasjonen med flytting og adresse, er spesifisering av adresserolle et
eksempel på dette. Attributtet må være med på grunn av at hver flytting kan ha minst to
adressetilknytninger. Hver forekomst av Flytting kan være knyttet til flere adresser, og hver
assosiasjon må være spesifisert ved sin adresserolle. Hver forekomst av assosiasjonen mellom
to objekter har da en litt ulik semantisk betydning. Eksempel: en gammel adresse har en annen
betydning enn en ny adresse eller en postadresse.
Noen ganger kan en uttrykke det samme ved å benytte flere assosiasjoner mellom to klasser.
Hvis antallet kan variere, og det er mer enn noen få (2-3) assosiasjoner er det foretrukket å
benytte en assosiasjonsklasse fremfor flere assosiasjoner.
B: Tilleggsopplysninger om selve relasjonen.
Datoen assosiasjonen gjelder fra, er et eksempel på en tilleggsopplysning om assosiasjonen.
Denne informasjonen gis for hver forekomst av en assosiasjon. Som nevnt over kan en
forekomst av Person være knyttet til flere adresser, og for hver slik knytning (assosiasjon)
kunne vi tenke oss at vi ønsker å lagre en fradato. For eksempel kan det spesifiseres at den
nye adressen til en bestemt person begynte å gjelde den 2.4.2005.
Begge typer attributter kan finnes i den samme assosiasjonsklassen. For eksempel kan en
tenke seg at det er ønskelig både å skille mellom type assosiasjon og spesifisere når en
assosiasjon begynte å gjelde.
44

12 Diagrammer
Når en modellerer et domene, er det teknisk mulig å lage ett stort diagram som viser alle
klasser, typer og assosiasjoner for domenet. I praksis er det likevel i de fleste tilfellene mest
hensiktsmessig å lage flere diagrammer som til sammen viser domenets informasjonsmodell.
Kriteriene for oppdeling av modellen i ulike diagrammer er ikke entydige, behovene vil være
forskjellige.
En hovedregel er at diagrammet skal kommunisere sitt meningsinnhold til leseren på en god
måte. Gjør derfor ikke diagrammet så komplekst at det blir ”uleselig”, for eksempel ved svært
mange assosiasjoner og arvepiler som krysser hverandre, og et stort antall klasser.
Menneskehjernen klarer som en tommelfingerregel å håndtere 7 +/- 2 visuelle elementer om
gangen. En kan tenke seg ulike kriterier for oppdeling i ulike diagrammer. Noen slike kriterier
er:
• Oppdeling etter blankett
• Oppdeling etter avdeling
• Oppdeling etter saksområde
• Ett diagram som viser arvestrukturer (hva noe er), og andre diagrammer som viser
bruk av klassene, med assosiasjoner.
45

13 Oppsummering av eksempel Flyttemelding
Diagrammet under viser en av mange mulige modeller for informasjonsinnholdet i
flyttemeldingen, slik den ble presentert i kapittel 5.
.
Figur 18: Informasjonsmodell for flyttemelding
Denne modellen er utformet uten tanke på bruk av grunndataelementer. I kapittel 15.2.1
modifiseres modellen slik at den gjenbruker grunndataelementer.
46

14 Tabeller
Tabeller forekommer i mange blanketter. Normalt er disse todimensjonale, men de kan også
ha flere enn to dimensjoner via en spesiell oppstilling. I elektroniske blanketter representeres
den tredje dimensjonen typisk ved arkfaner.
Når vi skal uttrykke tabeller i en modell, kan vi representere hver av tabelldimensjonene med
et attributt og også selve tabellverdien med et attributt. Vi tenker oss en tabell for
innrapportering av antall innbyggere for hvert fylke og ulike år:
Fylke/Årstall 2000 2001 2002 2003 2004 2005 2006
Østfold
Akershus
Oslo/Akershus
Oslo
Hedmark
Oppland
Buskerud
Vestfold
Telemark
Aust-Agder
Vest-Agder
Rogaland
Hordaland
Sogn og Fjordane
Møre og Romsdal
Sør-Trøndelag
Nord-Trøndelag
Nordland
Troms
Finnmark
Figur 19: Tabell for angivelse av antall innbyggere i alle fylker for ulike år.
Dette kan modelleres med følgende klasse:
Figur 20: Modell for innbyggere i ulike fylker for ulik år.
Attributtet fylke av semantisk type navn representerer den vertikale tabelldimensjonen, mens
årstall av semantisk type år står for den horisontale dimensjonen. Attributtet innbyggere av
semantisk type antall svarer til innholdet i tabellen. Flere dimensjoner i tabellen kan
modelleres med tilsvarende ekstra attributter i klassen.
47

I flyttemeldingseksempelet kan vi betrakte oversikten over personer som en tabellstruktur.
Klassen Person har kolonnene i tabellen som attributter. Radene i tabellen representeres ved at
assosiasjonen mellom Flytting og Person tillater at det eksisterer mange personer for hver
flytting.
48

15 Grunndata og gjenbruk
Det er viktig å gjenbruke klasser for å få til semantisk interoperabilitet og samordning. Det er
ikke ønskelig at det opprettes en ny klasse som prøver å uttrykke det samme som en
eksisterende klasse.
I modelleringsprosessen kan en gjenbruke klasser både fra egne og andres modeller, og fra
grunndatamodellen.
15.1 Grunndatamodell
Grunndata er et sett med felles dataelementer som er mye brukt i mange forskjellige domener
(etater). Typisk vil dette være felter som en vil kunne forvente er forhåndsutfylte i skjemaer.
Det utarbeides informasjonsmodeller som beskriver sentrale egenskaper ved personer,
enheter, bedrifter, adresser og eiendommer. De mest brukte klassene og attributtene er samlet
i en felles grunndatamodell.
Den felles grunndatamodellen skal fryses i fastlagte perioder, og endringer i modellen skal
gjøres etter fastlagte prosedyrer.
Figur 21: Foreløpig modell over de mest sentrale grunndata (versjon 0.1)
Grunndatamodellen i produksjonsversjonen av systemet vil kunne avvike noe fra modellen
som er gjengitt over.
15.2 Gjenbruk av elementer i informasjonsmodellen
15.2.1 Eksempel: Gjenbruk i modell av flyttemelding
Klassediagrammet under viser et eksempel på en modifisert modell for flyttemelding som
benytter grunndataelementer i stor grad.
Person-klassen i grunndata manglet en del informasjonselementer som er nødvendige i
flyttemeldinga, derfor har vi laget en subklasse PersonSomFlytter 10 .
10 Siden grunndata-klassene og klassene som benyttes i modellen av flyttemeldingsskjemaet ligger i ulike pakker,
kunne vi ha kalt klassen for Person, selv om grunndata-klassen også heter Person.
49

Adressestrukturen i grunndatamodellen har likhetstrekk med adressestrukturen i vår tidligere
flyttemeldingsmodell, men en del attributter fordeler seg litt annerledes. Vi antar i dette
tilfellet at adresse-strukturen i grunndatamodellen stort sett kan erstatte vår adressestruktur. Vi
har likevel laget noen subklasser av adresseklassene i grunndatamodellen for å få med
tilleggsadresse og land. Noen attributter i grunndatamodellen har også andre navn enn
attributtene i vår modell, men ved å se på de semantiske typene og på definisjonene til
attributtene og klassene, kan vi se om de likevel representerer det samme.
Figur 22: Flyttemelding modellert med grunndata
Diagrammet i Figur 22 ser ved første øyekast mye mer komplisert ut enn vårt utkast i Figur
18, på grunn av at vi har med en del attributter og superklasser fra grunndatamodellen som i
praksis ikke er relevant for flyttemeldinger. Mye av denne kompleksiteten kan vi gjemme i
dokumentmodellen ved å skjule attributter og fjerne overordnede klasser. Dette vises i kapittel
16.5.
I de neste delkapitlene diskuterer vi enkelte aspekter ved gjenbruk av modellelementer
nærmere, og henviser tilbake til eksempelet over.
15.2.2 Grunndata
For å fremme samordning av data bør en gjenbruke modellelementer fra grunndatamodellen
hvis det er mulig. Domenemodeller som skal opp på konformt eller harmonisert nivå bør ha
en kobling til en eller flere grunndataklasser ved hjelp av arv eller assosiasjoner.
Så tidlig som mulig i modelleringsprosessen bør en identifisere informasjonselementer som
allerede finnes i grunndatamodellen. Dette kan være både klasser og attributter. Noen ganger
lar det seg gjøre å benytte grunndataklasser i domenemodellen uforandret. Andre ganger er
det nødvendig med flere attributter for å beskrive en klasse i domenemodellen enn dem som
50

finnes i grunndatamodellen. I slike tilfeller er det mest hensiktsmessig å lage en subklasse av
en grunndataklasse.
Retningslinjer: Gjenbruk av grunndata
• Identifiser elementer som kan gjenbrukes fra grunndatamodellen som så tidlig som mulig
• Tilpasning av domenemodellen til grunndatamodellen fremmer gjenbruk
Tilsvarende er det ikke alltid vi trenger alle attributtene fra en grunndataklasse i
domenemodellen. Da kan grunndataklassen brukes slik den foreligger. De overflødige
attributtene fra grunndatamodellen kan senere skjules i dokumentmodellene som baserer seg
på domenemodellen, slik at de overflødige attributtene ikke blir med i
meldingsspesifikasjonene. Framgangsmåten for å fjerne attributter i dokumentmodeller er
beskrevet i kapittel 16.2.
Noen ganger er det som ser ut til å være et attributt i domenemodellen, representert ved en
klasse i grunndatamodellen, eller omvendt. Som en generell regel er det alltid gunstigst å
tilpasse domenemodellen til grunndatamodellen.
Hvis en domenemodell for eksempel har et attributt som representerer kommune, går det an å
lage en assosiasjon til Kommune-klassen i grunndatamodellen i stedet for attributtet, slik som
vist i Figur 22.
På denne måten taper en ikke informasjonsrikdom, og sørger samtidig for å øke
gjenbrukbarheten i modellen ved å peke til et eksisterende dataelement (klassen Kommune).
Dermed uttrykker modellen at det en faktisk mener med kommune, er det samme som det alle
andre som refererer til standardklassen Kommune mener. Det er viktig å forsikre seg om at
begrepet i grunndatamodellen faktisk er de samme som begrepet i domenemodellen ved å
sjekke definisjonen til klassen.
Den motsatte situasjonen vil også oppstå, et begrep i virkeligheten kan være representert ved
en klasse i domenemodellen og et attributt i grunndatamodellen. Koblingen mellom klassen i
domenemodellen og attributtet i grunndatamodellen vil da være ivaretatt ved at et attributt i
domeneklassen har et attributt av samme semantiske type som attributtet i grunndatamodellen.
15.2.3 Gjenbruk av egne informasjonselementer
Foreløpig ikke skrevet
15.2.4 Gjenbruk av andres informasjonselementer
Foreløpig ikke skrevet
15.3 Oppsummering av informasjonsmodellering
Modelleringen skal gi minst to ulike resultater; en informasjonsmodell som er en språklig
godt forankret, domene-harmonisert og skjemauavhengig beskrivelse av virkeligheten, og
som kan danne grunnlaget for en analyse av semantisk interoperabilitet.
Informasjonsmodelleringen skal også gjøre det mulig å definere et sett med
dokumentmodeller. Det er trolig lettest å oppnå disse fordelene ved å gjøre
modelleringsarbeidet i en bestemt rekkefølge:
1. Begynn med de enkelte beskrivelsene av den virkeligheten som skal modelleres. Dette
vil ofte være ett eller flere skjemaer, men det kan også være eksisterende
informasjonsmodeller, tekstdokumenter eller lignende. Lag beskrivelse (modell) av
51

innholdet i beskrivelsen (skjemaet) som er så generell som mulig. Kontroller at
modellen representerer alle informasjonselementene. Hvis det er flere skjema eller
andre beskrivelser som skal modelleres kan de godt modelleres i ulike diagram, men
det er også mulig lage et felles diagram. Det som er viktig, er å gjenbruke klasser
mellom de ulike diagrammene.
2. Kontroller at den felles modellen inneholder alle informasjonselementer (attributter,
klasser) som er nødvendige for å representere informasjonen i skjemaene som er
modellert. Kontroller dette mot ett og ett skjema om gangen.
3. Undersøk hvorvidt informasjonsstrukturen som er modellert legger til rette for
gjenbrukbarhet, og modifiser eventuelt modellen for å gjøre informasjonsstrukturen
mer gjenbrukbar. Dette trinnet vil muligens ikke gjennomføres i alle tilfeller, men det
anbefales sterkt å gjøre det ved senere revisjoner av modellen.
52

16 Dokumentmodellering
Ved generering av en dokumentmodell fra informasjonsmodellen, vil modellen i
utgangspunktet være helt lik. Alle behov i dokumentmodellen sett fra et modelleringsståsted
skal være dekket av informasjonsmodellen. Du har kun lov til å lage et sant subsett av
informasjonsmodellen. For å tilpasse dokumentmodellen til sitt formål må den bearbeides i
form av at:
• urettede assosiasjonene må endres
• kardinalitet på assosiasjoner kan innskrenkes eventuelt nullstilles
• irrelevante attributter bør skjules
• semantiske typer ved behov ytterligere spesialiseres
• eventuelle rotklasser spesifiseres
16.1 Assosiasjoner
I dokumentmodellen er assosiasjoner både representert med grafiske assosiasjonsstreker (som
i informasjonsmodellen) og som attributter i de klassene som assosiasjonen knytter sammen.
En klasses eventuelle assosiasjoner til andre klasser som ikke inngår i dokumentmodellen vil
også vises som attributter, men vil være indikert deaktivert ved at kardinaliteten er satt til null.
16.1.1 Rettede assosiasjoner
I dokumentmodellen må assosiasjonen omgjøres til å være rettet. Retning på assosiasjoner kan
påvirkes av hvilket skjema som modelleres og eget ståsted. Er det arbeidstaker eller
arbeidsgiver som ”eier” arbeidsforholdet? I dokumentmodellen settes retningen ut fra
modellens spesifikke kontekst og ønsket representasjon i meldingsspesifikasjonen.
I første versjon av SERES er rettede assosiasjoner den eneste typen assosiasjon som er
implementert i den delen av systemet som genererer meldingsspesifikasjoner. SERES støtter
bruk av aggregat og komposisjon i dokumentmodellene, men systemet støtter foreløpig ikke
disse konstruksjonene i generering av meldingsspesifikasjoner. Dette innebærer at rettede
assosiasjoner, aggregering og komposisjon blir seende likt ut i meldingsspesifikasjonene.
Derav regelen om å bruke denne assosiasjonstypen. Det er imidlertid ønskelig med mer
fleksibilitet i generering av meldingsspesifikasjoner. Aggregat og komposisjon vil derfor
støttes i senere utgaver av SERES, og da vil regelen for bruk av assosiasjoner i
dokumentmodellen utvides.
Retningslinje:
• Urettede assosiasjoner må omgjøres til rettede assosiasjoner (aggregering og
komposisjon kan benyttes)
16.1.2 Kardinalitet
Kardinaliteten til en assosiasjonsende kan gjøres strengere (mer begrenset) i en
dokumentmodell og forhold til utgangspunktet fra informasjonsmodellen. Det betyr at
minimum kardinalitet kan økes (typisk fra null) og maksimum kardinalitet kan reduseres
(typisk fra ubegrenset). Kardinaliteten på ”assosiasjonsattributtet” kan også settes til null for å
53

deaktivere assosiasjonen. En viktig forutsetning for dette er at kardinaliteten ikke er satt til
minimum én i informasjonsmodellen.
Retningslinje:
• Kardinaliteten kan gjøres strengere
16.2 Skjuling av attributter
I informasjonsmodellen oppfordres det til gjenbruk av informasjonselementer. Dette vil i
mange tilfeller innebære at modellereren gjenbruker klasser fra andre domener som
inneholder flere attributter enn det som er relevant i modellererens domene. Det er heller ikke
alltid at alle attributter som inngår i en informasjonsklasse, selv om den er laget innenfor eget
domene, er relevant i den videre prosessen i dokumentmodelleringen. Slike attributter skjules
i dokumentmodellen ved å sette kardinaliteten til null.
Retningslinje:
• Irrelevante attributter bør skjules
16.3 Semantiske typer
Informasjonsmodellen har to hovedmål:
1. Den skal støtte en analyse for å finne ut om det er potensial for interoperabilitet.
2. Den skal støtte generering av dokumentmodeller og derav meldingsspesifikasjoner.
Punkt én indikerer at de semantiske typene må være tilstrekkelig semantisk spesifisert for å
unngå misforståelser i en slik prosess. Neste punkt endrer perspektivet på semantiske typer.
Nå blir kobling mot format og muligheter for validering mer relevant. En motivasjon for å
spesialisere kan være at samme semantiske type brukt for forskjellige klasseattributter i
modellen ønskes validert ulikt. Ettersom en semantisk type bare kan være koplet til ett format,
innebærer det at den må spesialiseres for å få til dette.
Derfor er det mulig ytterligere å spesialisere semantiske typer i dokumentmodellen ut fra et
formaterings- og valideringsbehov. Spesialiseringer ut fra slike hensyn bør unngås i
informasjonsmodellen. Indikasjoner på at en semantisk type er blitt for spesialisert i
informasjonsmodellen er at det bare er en eller få forekomster av denne, særlig hvis
forekomstene kun brukes finnes i én klasse.
De semantiske typene kan spesialiseres videre i dokumentmodellen, for eksempel hvis det
trengs spesielle valideringsregler eller en bestemt kodeliste for et attributt. Attributter vil som
regel dekkes tilfredsstillende av de semantiske typene beløp, dato og navn uten spesialisering,
både i informasjonsmodellen og i dokumentmodeller. Når det gjelder bruk av de semantiske
typene kode, mål og identifikator, må vi bygge ut spesialiseringshierarkier av disse for bruk i
dokumentmodeller. Dette fordi en her må kunne serialisere de semantiske typene til ulike
representasjoner avhengig av semantikken i attributtet. Spesialisering av en semantisk type vil
ofte være nødvendig når klassene i en dokumentmodell inneholder flere ulike attributter som
benytter samme semantiske type (kode, mål eller identifikator).
Retningslinjer: Semantiske typer i dokumentmodell
• Semantiske typer kan spesialiseres i en dokumentmodell for å gjøre ønsket grad av
validering mulig
• En ny semantisk type må være en subtype av semantisk type fra informasjonsmodellen
54

16.4 Rotklasse
I dokumentmodellen kan en eller flere klasser defineres som rotklasser. Dette kan være
nødvendig for å gjøre modellen presis nok til at den kan danne grunnlaget meldingsmodeller.
Klasser som settes som rotklasse i dokumentmodellen danner det ”ytterste” nivået i
meldingsspesifikasjonene som baseres på dokumentmodellen. Dette samsvarer på mange
måter logisk med ”hvem sitt perspektiv” en dokumentmodell har. I praksis sier en at
rotklassen er ”det meldingen handler om”. Som en hovedregel vil assosiasjonene være rettet
fra rotklassen.
Retningslinje:
• Rotklasser kan defineres dersom hensiktsmessig
16.5 Dokumentmodell av flyttemelding
Figur 23 viser en dokumentmodell basert på informasjonsdiagrammet av flyttemeldingen
(Figur 22). Her er superklasser vi ikke trenger blitt skjult, og ikke-relevante attributter er grået
ut. Klassene har også automatisk fått attributter som representerer assosiasjonene. Alle
assosiasjoner er videre gjort rettet. Dette innebærer at et objekt kan kjenne til eksistensen av
objekter av den/de klassene pilene peker på. For eksempel er det kun forekomster av klassen
Adresse som kjenne til et objekt av klassen Matrikkelnummer. Alle assosiasjoner knyttet til
klassen Flytting, peker fra Flytting og til de andre klassene. Grunnen til dette er at klassen
Flytting er antatt å være ”hovedtema” for flyttemeldingsskjemaet og dermed også for denne
dokumentmodellen. Klassen er i tillegg satt som rotklasse. Klassen danner da det ”ytterste”
nivået i meldingsspesifikasjonen som lages med utgangspunkt i dokumentmodellen.
Denne modellen kan nå danne utgangspunkt for generering av en meldingsmodell, og slik kan
vi lage en meldingsspesifikasjon for informasjonen i modellen. Ulike aspekter med denne
modellen diskuteres nærmere i de neste kapitlene.
Figur 23: Dokumentmodell for flyttemelding
55

17 Meldingsmodellering
Meldingsmodellering omfatter utarbeidelse av formater og formatfamilier, kobling av
formatfamilier til dokumentmodeller og generering av spesifikasjoner.
17.1 Format
Godkjenning og kontroll (validering) av semantiske typer i en meldingsspesifikasjon skjer
gjennom typenes kopling til formater. En semantisk type knyttes til et format gjennom et
formatfamiliemedlem. Et antall slike medlemmer, hver knyttet til sin semantiske type, inngår i
en formatfamilie. Denne mekanismen ble etablert for å kunne definere formater uavhengig av
en konkret dokumentmodell. Dette gjør det enklere å endre format uten å måtte endre
dokumentmodellen, samt enkelt å regenerere en meldingsbeskrivelse når en dokumentmodell
er endret.
En semantisk type er knyttet til ett format innenfor en valgt formatfamilie, men et format kan
deles av flere semantiske typer innenfor en eller flere formatfamilier. Dersom en semantisk
type ikke er eksplisitt knyttet til et format, er det underforstått at formatet for den nærmeste
supertypen, som har format, skal brukes (implisitt gitt format). De grunnleggende semantiske
typene (toppnodene) skal alltid være representert i en formatfamilie.
Et format er enten et enkelformat eller et kompleksformat. Et enkelformat kan være en
spesialisering av et annet enkelformat, bare med en eller flere nye restriksjoner. Et
enkelformat kan alternativt peke til en kodeliste. Et kompleksformat utgjøres av to sett av
enkelformater, verdielementer og tilleggselementer. Dersom et kompleksformat bare har ett
verdielement, skal navnet på dette ikke brukes i meldingsspesifikasjonene.
Retningslinjer: Format
• Alle grunnleggende semantiske typer skal være knyttet til et format i en formatfamilie.
Andre semantiske typer skal enten være knyttet direkte til et format eller indirekte
gjennom en overliggende type i hierarkiet.
• Et format kan deles av flere semantiske typer.
• Hvert format har et unikt navn blant alle formater i systemet.
• Et format spesifiseres som en kombinasjon av XML Schema-fasetter.
Konseptmodellen er vist i vedlegg II Konseptmodell for semantiske typer og formater.Feil!
Fant ikke referansekilden.
17.2 Formatstandard
Selv om en semantisk type kan representeres med flere alternative formater, vil det være en
fordel å standardisere på ett gitt format for et gitt formål eller et bestemt miljø.
Standardisering av formater bidrar til teknisk interoperabilitet mellom mange involverte
parter. I prinsippet kunne en tenke seg at verktøyet ga brukeren valget mellom et standard
format eller et gitt annet format for hver semantisk type. Dette vil imidlertid gi heterogene
spesifikasjoner som vi ser som uønskelig. I stedet knytter vi et samordnet standard sett av
formater til alle grunnleggende semantiske typer. Avledete semantiske typer vil bruke det
samme formatet, med mindre et annet spesifikt format knyttes til den avledete typen via
formatfamilien.
56

For å illustrere dette vil standardformatet for den semantiske typen dato være datoformatet i
ISO 8601 som også brukes i XML Schema-typen date: År-Måned-Dag, for eksempel "2004-
12-16". Formatet representerer en validering som svarer til xsd:date.
17.3 Administrering av formater
Hvert format har et unikt navn i hele systemet og beskriver hvordan en semantisk type skal
representeres og valideres i meldinger. Formater opprettes og administreres i SERES Format.
Alle XSD-datatyper er tilgjengelig i SERES Format for kopling til enkelformater.
Kompleksformater er sammensatt av verdielementer og tilleggselementer som begge refererer
til spesifikke enkelformater.
Et enkelformat kan beskrives nærmere gjennom å definere en eller flere restriksjoner fra et
sett av slike. Alle restriksjonene skal være oppfylt.
Følgende type restriksjoner er tilgjengelig (tilhørende XML Schema-betegnelser i parentes):
• minimumsverdi (xsd:minInclusive): Minimalt tillatt verdi som også kan oppnås.
• maksmumsverdi (xsd:maxInclusive): Maksimalt tillatt verdi som også kan oppnås.
• minimumsskranke (xsd:minExclusive): Nedre skranke dvs. at verdien kan komme så
nær en nedre verdi en vil, men kan ikke være lik skrankeverdien. F.eks. vekta på en
pakke kan ha en skrankeverdi på null som betyr at vekta kan være så liten en bare kan
tenke seg, men verdi null ønsker vi å signalisere som en feil.
• maksimumsskranke (xsd:maxExclusive): Øvre skranke dvs. at verdien kan komme så
nær en øvre verdi en vil, men kan ikke være lik skrankeverdien.
• absoluttlengde (xsd:length): Verdien uttrykkes med en tekststreng som skal ha en gitt
lengde. F.eks. skal et organisasjonsnummer ha nøyaktig lengde 9.
• minimumslengde (xsd:minLength): Verdien uttrykkes med en tekststreng som ikke kan
være kortere enn et gitt antall tegn. F.eks. skal en identifikator være på minst 3 tegn,
man kan ellers være så lang en bare vil.
• maksimumslengde (xsd:maxLength): Verdien uttrykkes med en tekststreng som ikke
kan være lengre enn et gitt antall tegn. F.eks. skal et navn være på maksimal 50 tegn
for ikke å bli avkortet ved lagring i en gitt database.
• totalsifre (xsd:totalDigits): En verdi skal uttrykkes med et bestemt antall sifre, f.eks. et
fødselsnummer som skal være akkurat 11 sifre.
• desimalsifre (xsd:fractionDigits): En verdi skal
• regulæruttrykk (xsd:pattern)
Noen av restriksjonene kan gjerne administreres i par i brukergrensesnittet:
• mininumsverdi + maksimumsverdi: lukket intervall
• minimumsskranke + maksimumsskranke: åpent intervall
• mininumsverdi + maksimumsskranke eller minimumsskranke + maksimumsverdi:
halvåpent intervall
• minimumslengde + maksimumlengde: lengdeintervall
17.3.1 Kompleksformater
Et enkelformat uttrykkes i XSD gjennom en simpleType, mens et kompleksformat uttrykkes
gjennom en complexType. Et eksempel på semantisk type som kan uttrykkes gjennom et
kompleksformat er dato. Formatet sammensattDato kan defineres med innholdselementene
57

dag, maaned og aar. maaned og dag kan ha enkelformatet positivtHeltall, mens aar kan ha
enkelformatet heltall. Formatet uttrykkes slik:
Et annet eksempel på en semantisk type som kan trenge et kompleksformat er mål. Formatet
sammensattMåling kan bestå av verdielementet verdi og tilleggselementet enhet. Enhet er
påkrevet og har defor ikke standardverdi. Ettersom formatet bare har ett verdielement skal
ikke verdielementets navn brukes. Måling uttrykkes i XSD ved:
En kan videre tenke seg en semantisk type lengde som en avledning av mål. Denne er såpass
spesifikk at den kan ha et format lengdemaal knyttet til en kodeliste lengdeenhet. Videre skal
enhet kunne ha en defaultverdi m. Denne kan spesifiseres slik:
58

17.4 Kodelister
Ethvert enkelformat kan som nevnt koples til en kodeliste. Denne angir lovlige verdier (koder)
for det attributtet som via semantisk type er koplet til dette enkelformatet.
En kodeliste er en samling av kodelisteelementer, der et kodelisteelement består av en kode
samt en definisjon eller beskrivelse av hva koden representerer. I foreliggende versjon er det
ingen begrep-mekanisme mellom (slik konseptmodellen angir). Kodelister kan være flate eller
hierarkiske. Foreløpig er det bare mulig å operere med flate lister som imidlertid implisitt kan
ha en hierarkisk struktur. Hierarkiet må imidlertid hentes ut ved fortolkning av kodeverdiene.
I SERES er kodelister for det meste tenkt koplet til spesialiseringer (subtyper) av den
semantiske typen kode, men også subtyper av andre semantiske typer kan være aktuelle. Det
er ingen tekniske begrensninger for hvilke semantiske typer som (via et enkelformat) kan
koples til en kodeliste.
Kodelister er en egen konstruksjon som administreres for seg uavhengig av formater. Det er
mulig å importere og eksportere kodelister i SERESformat.
59

18 Oppsummering
Informasjonsmodelleringen skal gi minst to ulike resultater; en informasjonsmodell som er en
språklig godt forankret, domene-harmonisert og skjemauavhengig beskrivelse av
virkeligheten, og som kan danne grunnlaget for en analyse av semantisk interoperabilitet.
Informasjonsmodelleringen skal også gjøre det mulig å definere et sett med
dokumentmodeller. Det er trolig lettest å oppnå dette ved å gjøre modelleringsarbeidet i en
bestemt rekkefølge:
1. Begynn med de enkelte beskrivelsene av den virkeligheten som skal modelleres. Dette
vil ofte være ett eller flere skjemaer, men det kan også være eksisterende
informasjonsmodeller, tekstdokumenter eller lignende. Lag beskrivelse (modell) av
innholdet i beskrivelsen (skjemaet) som er så generell som mulig. Kontroller at
modellen representerer alle informasjonselementene. Hvis det er flere skjema eller
andre beskrivelser som skal modelleres kan de godt modelleres i ulike diagram, men
det er også mulig lage et felles diagram. Det som er viktig, er å gjenbruke klasser
mellom de ulike diagrammene.
2. Kontroller at den felles modellen inneholder alle informasjonselementer (attributter,
klasser) som er nødvendige for å representere informasjonen i skjemaene som er
modellert. Kontroller dette mot ett og ett skjema om gangen.
3. Undersøk hvorvidt informasjonsstrukturen som er modellert legger til rette for
gjenbrukbarhet, og modifiser eventuelt modellen for å gjøre informasjonsstrukturen
mer gjenbrukbar. Dette trinnet vil muligens ikke gjennomføres i alle tilfeller, men det
anbefales sterkt å gjøre det ved senere revisjoner av modellen.
Dokumentmodellen beskriver en informasjonsstruktur som kan danne utgangspunkt for en
meldingsmodell, og dermed serialiseres til en meldingsbeskrivelse.
I dokumentmodellen skal det ikke finnes urettede assosiasjoner, og en kan skjule attributter og
klasser som ikke trengs i meldingene basert på modellen. Ved å bestemme hvilke klasser som
skal være rotklasse, bestemmer en hva som blir det ytterste elementet i
meldingspesifikasjonen.
I meldingsmodelleringen lager en formatfamilier, som er et sett med formater, som beskriver
hvordan semantiske typer fysisk skal representeres i en melding.
Meldingsmodellen består av en dokumentmodell koblet til en formatfamilie. Den fysiske
representasjonen av en meldingsmodell er en meldingsspesifikasjon. Meldingsspesifikasjonen
benyttes til å validere (godkjenne) faktiske meldinger som utveksles mellom systemer/etater
60

I Semantiske typer
I.a Figur med arvestruktur
61

I.b Definisjoner på semantiske typer
De semantiske typene som er definert i figuren på forrige side og i tabellen under, representerer en skisse til harmoniserte semantiske typer. Vi
har funnet det viktig å etablere en slikt sett tidlig slik at det ikke gror opp et uttall av varianter som er semantisk nært beslektet. Dette kommer i
tillegg til de grunndataklassene som også gjøres tilgjengelig fra starten av.
Semantisk type Arver Svarer til Definisjon
identifikator cc:Identifier Tegnsekvens som unikt identifiserer et objekt i en forvaltet mengde
av objekter.
kode cc:Code Tegnsekvens som unikt representerer et element av type begrep,
navn, verdi etc. i en liste av beslektete elementer.
tekst cc:Text - Tekstlig, ikke-unik betegnelse eller beskrivelse.
xsd:string
alternativ cc:Indicator -
xsd:boolean
Informasjonselement med to mulige verdier. Eksempler: 'Ja' eller
'Nei', 'Sant' eller Usant', 'Har' eller 'Har ikke', 'Er' eller 'Er ikke', 'På'
eller 'Av'
Dimensjonsløs, beregnet størrelse.
tall cc:Numeric -
xsd:decimal
antall cc:Quantity - Tellbar størrelse uten enhetsangivelse. Eksempler: 'Antall barn',
xsd:integer 'Antall arbeidsgivere'. Det tillates negative antall som uttrykk for
'manglende antall'.
mål cc:Measure Fysisk størrelse som kan måles med et verktøy eller instrument,
eller planlagt størrelse for mulig senere realisering og måling.
Størrelsen består av en numerisk måleverdi og en måleenhet.
beløp cc:Amount Pengeverdi med angitt valuta.
tidspunkt cc:Date Time - Punkt i historisk tid, dvs. en gitt dato og et gitt klokkeslett i et
xsd:dateTime bestemt år og tidssone, eller periodisk tidspunkt i forhold til
standard nullpunkt for standard tidsperiode (år, måned, dag)
binærobjekt cc:Binary
Object
En begrenset sekvens av bytes, typisk en datafil
navn tekst cc:Name Offisielt navn på personer, foretak etc.
beskrivelse tekst Tekstlig beskrivelse
forholdstall tall cc:Rate Tall som stammer fra forholdet mellom to andre tall
62

prosenttall tall cc:Percent Tall som fremkommer som forholdet mellom to tall multiplisert
med 100
dato tidspunkt xsd:date Tidspunkt med døgnoppløsning, dvs tidsrommet innenfor et gitt
historisk døgn
klokkeslett tidspunkt xsd:time Tidspunkt innenfor et gitt døgn
måned tidspunkt xsd:gMonth Periodisk månedsangivelse, dvs. tidsrommet som utgjøres av en gitt
måned uavhengig av år
år tidspunkt xsd:gYear Tidspunkt med årsoppløsning, dvs. et helt historisk år (f.eks. '2006')
månedOgÅr tidspunkt xsd:gYearMont Tidspunkt med månedsoppløsning, dvs. en hel måned i et gitt år
h
(f.eks. '2006-04')
dagOgMåned tidspunkt xsd:gMonthDay Periodisk datoangivelse, dvs. tidsrommet som utgjøres av et helt
døgn i en gitt måned uansett år (f.eks. 05-17)
dagIMåneden tidspunkt xsd:gDay Periodisk dagangivelse, dvs. en bestemt dag i hver måned (f.eks.
'17')
ukedag kode Ukedagene 'mandag', 'tirsdag' ... 'søndag'
ukenummmer tidspunkt Periodisk ukeangivelse, dvs. tidsrommet som utgjøres av en gitt uke
(mandag-søndag) uavhengig av år
lydfil binærobjekt cc:Sound Binærobjekt med lydinnhold, f.eks. av type mp3, wav, mid.
videofil binærobjekt cc:Video Binærobjekt med videoinnhold, f.eks. av type avi, mov, mpeg.
grafikkfil binærobjekt cc:Graphic Binærobjekt med grafisk innhold, dvs. figurer og symboler, f.eks.
av type svg, png, gif.
bildefil binærobjekt cc:Picture Binærobjekt med fotografisk eller malttegnet materiale, f.eks. av
type jpg.
personidentifikator identifikator Identifikasjon av en fysisk person
organisasjonsidentifikator identifikator Identifikasjon av en organisasjon
eiendomsidentifikator identifikator Identifikasjon av fast eiendom
fødselsnummer personidentifikator Et norsk fødselsnummer
organisasjonsnummer organisasjonsidentifikator Et norsk organisasjonsnummer
bedriftsnummer organisasjonsidentifikator En unik identifikator for bedrifter som igjen er organisert under
enheter med sine respektive organisasjonsnummer.
matrikkelnummer eiendomsidentifikator Matrikkelnummer for en eiendom sammensatt av
kommunenummer, gårdsnummer, bruksnummer, seksjonsnummer
og eventuelt festenummer
63

gårdsnummer eiendomsidentifikator Gårdsnummer for en eiendom
bruksnummer eiendomsidentifikator Bruksnummer for en eiendom
seksjonsnummer eiendomsidentifikator Seksjonsnummer for en eiendom
festenummer eiendomsidentifikator Festenummer for en eiendom
eiendelsidentifikator identifikator Identifikasjon av en eiendel (løsøre)
bilkjennemerke eiendelsidentifikator Norsk bilkjennemerke normalt bestående av to bokstaver med
påfølgende 5 sifre. Også 4 sifre og tidligere nummersystemer som
fortsatt er i bruk er inkludert.
åndsverksidentifikator identifikator Identifikasjon av et åndsverk (skrifter, kunstverk, oppfinnelser etc)
ISBN åndsverksidentifikator Det internasjonale identifikasjonssystem for bøker (International
Standard Book Number) administrert av 'International ISBN
Agency'
ISSN åndsverksidentifikator Det internasjonale identifikasjonssystem for tidsskrifter
(International Standard Serial Number) administrert av 'ISSN
International Centre'
ressursidentifikator identifikator Identifikator for fysiske eller elektroniske ressurser
URI ressursidentifikator Identifikasjon av nettressurs (Uniform Resource Identifier)
URL URI Adresse til nettressurs (Uniform Resource Locator
URN URI Navn for nettressurs (Uniform Resource Name)
regionkode kode Kode for et geografisk område
virksomhetskode kode Kode som beskriver ulike aspekter ved en virksomhet
telefonnummer ressursidentifikator Telefonnummer, både norsk og utenlandsk. Gjelder både for
fasttelefoni, mobiltelefoni og telefaks
varighet mål xsd:duration Mål av type tid, dvs. målt eller planlagt forløpt tid uavhengig av når
det skjer
lengde mål Målt eller angitt lengde
areal mål Målt eller angitt areal
volum mål Målt eller angitt volum
hastighet mål Målt eller angitt hastighet
temperatur mål Målt eller angitt temperatur
energi mål Målt eller angitt energi
masse mål Målt eller angitt masse
64

vinkel mål Målt eller angitt vinkel
omkrets lengde Målt eller angitt omkrets, dvs. en lengden av en lukket kurve langs
et objekts ytterside
epost ressursidentifikator Epost-adresse (f.eks.: 'ola.nordmann@firmaet.no')
kommunenummer regionkode Offisielt kommunenummer for norsk kommune, basert på
løpenummer for fylke og kommune i fylke
landkode regionkode Internasjonal landkode, normalt ulike ISO 3166-varianter
kjønn kode Biologisk kjønn
husnummer eiendomsidentifikator Identifikator for en bygning eller del av bygning som er unik
innenfor ei gate.
postnummer regionkode Identifikator for poststeder i Norge som forvaltes av 'Posten Norge
AS'
eiendomstype kode Type og status for eiendom: 'Grunneiendom', 'Anleggseiendom',
'Festegrunn', 'Eiersseksjon', 'Jordsameie', 'Selveier', 'Selveier i
sameie', 'Utgått'.
etasjetype kode Type etasje, f.eks. kjeller, sokkel, hovedetasje, loft
adressetype kode Type adresse: 'Hjemmeadresse', 'Jobbadresse', 'Fakturaadresse',
'Besøksadresse', 'Fritidsboligadresse' etc.
personstatus kode Status for en person, om personen er død, bor i utlandet, er
umyndiggjort eller har en normal status (bor i Norge som myndig
person).
sivilstand kode Sivilstand: 'Enslig', 'Samboer', 'Partnerskap', 'Gift', 'Skilt', 'Enke'
eller 'Enkemann'
registeringstype kode Diplomat, klient, adressesperring ol
organisasjonsform virksomhetskode Type organisasjon som et foretak er: 'Enkeltpersonforetak',
'Aksjeselskap', 'Ansvarlig selskap' etc. Synonymer er 'Selskapsform'
og 'Enhetstype'
næringskode virksomhetskode Type næring i form av en NACE-kode
enhetsstatus virksomhetskode Avvikende status for enhet: Oppløst, konkursåpnet, under
tvangsavvikling, oversendt tingretten etc.
sektorkode virksomhetskode Navn på institusjonell sektorkode som er en organisatorisk
kategorisering
målform kode Målform (bokmål, nynorsk eller samisk) en person eller enhet
65

ønsker for skriflig kommunikasjon med det offentlige
styrerolle virksomhetskode Navn på funksjon i et styre
kapitaltype kode Type kapital f.eks.
'Aksjekapital', 'Selskapskapital', 'Grunnkapital', 'Grunnfondsbeviska
pital' etc.
personrelasjon kode Primærrolle en person har ovenfor en gitt annen person: 'Mor', 'Far',
'Barn', 'Ektefelle', 'Samboer', 'Partner', 'Fostermor', 'Fosterfar',
'Fosterbarn', 'Verge'
kontakttype kode Type kontaktmulighet: 'Hustelefon', 'Mobiltelefon', 'IPTelefon',
'Telefaks', 'Epost', 'Henvendelse via nettadresse'
kontaktsammenheng kode Navn på rolle en har ved kontakt med andre
cc: refererer til Core Component Permissible Representation Term.
xsd: refererer til XML Schema datatype.
Noen av spesialiseringene av de semantiske typene dekker standardens "Secondary Represention Terms", men SERES har ikke satt en endelig
grense for spesialisering av semantiske typer på samme måte som vi finner et endelig sett av Permissible Representation Terms. SERES bygger
ut strukturen av standardiserte semantiske typer til en taksonomi som skal dekke et nasjonalt behov, men vi vil i utgangspunktet søke å unngå
innføring av grunnleggende semantiske typer (rottyper som ligger på øverste nivå) som ikke er definert i CCTS. Om vi lager nye rottyper, bør
disse sendes som utvidelsesforslag til internasjonal standardisering. Kun Brønnøysundregistrene kan etablere nye rottyper i SERES.
66

II Konseptmodell for semantiske typer og formater
Figur 24 Konseptmodell for semantiske typer, formater, formatfamilier mm.
67

III Forkortelser
Forkortelser brukes typisk som et ledd i et CamelCase-basert navn.
adm Administrasjon,
administrativ/t
apr April
av Av verdien
aug August
des Desember
feb Februar
fk Førstkommende
foreg Foregående
grl Grunnlagt
id Identifikator
inkl Inklusive
jan Januar
jr Junior
jun Juni
jul Juli
lø Lørdag
nr Nummer
ma Mandag
mai Mai
mar Mars
min Minimumsverdi
maks Maksimumsverdi
mfl Med flere
mht Med hensyn til
mill Million
min Minutt
mrd Milliard
mva Merverdiavgift
no Norsk
nov November
nto Netto
off Offentlig
ofl Og flere
okt Oktober
ol Og liknende
on Onsdag
osv Og så videre
ovf Ovenfor
pa Pro anno
pb Postboks
pga På grunn av
pkt Punkt
pr Per
pst Prosent
resp Respektive
sep September
spm Spørsmål
sr Senior
sst Samme sted
stk Stykk/er
stud Student
sø Søndag
så Samme år
såk Såkalt
temp Temperatur
ti Tirsdag
tils Til sammen
tilsv Tilsvarende
tlf Telefon
to Torsdag
tom Til og med
ult Ultimo (siste)
UT Universaltid
(tidligere GMT)
utg Utgave
v Vei
vedk Vedkommende
vg Videregående
vha Ved hjelp av
vol Volum
vs Versus
(mot eller i forhold
til)
vsa Ved siden av
årg Årgang
årh Århundre
68

IV Internasjonale standarder
SERES relaterer seg til en rekke internasjonale standarder enten ved at standarden er basis for
detaljer i løsningen eller standarden er studert for å finne gode mekanismer eller det er vurdert
hvordan standarden kan støttes på sikt om det kommer krav om dette.
UML v1.4 Informasjonsmodellene og dokumentmodellene er basert UMLs klassediagram
og følger versjon 1.4 av standarden.
XMI v.1.2 Modelleringsverktøyet kan importere og eksportere modeller som er beskrevet
i denne standarden.
ISO11179 Dette er den gamle metadatastandarden fra ISO. Den er basis for en del av
begrepsapparatet vi bruker.
ebXML og Core Components De grunnleggende semantiske typene er norske
oversettelser av Core Component Permissible Representation Terms (CC PRT)
fra UN/CEFACT. De semantiske typene i SERES har referanser til CC PRT og
er ekvivalente med dem. Grunndataklassene og deres attributter skal ha
referanser til Core Components Library (UN/CCL) der paralleller finnes.
Dublin Core Benyttes som standard for administrative metadata knyttet til modellelementer
(klasser, attributter, typer med flere).
XBRL XBRL (eXtensible Business Reporting Language) er en XML-standard for
regnskapinformasjon og tilgrensende områder. Den er i ferd med å få godt
fotfeste internasjonalt og er derfor en svært aktuell type ekstern referanse for
informasjonselementer i SERES.
HL7 Innenfor helsedomenet finnes den utbredte HL7-standarden (Health Level 7).
Denne er tatt i bruk av KITH for deres hovedoppdragsgiver Rikstrygdeverket
(RTV). HL7 vedlikeholder en standardisert informasjonsmodell (RIM -
Reference Information Model) uttrykt i UML med bruk av arv og
assosiasjoner. KITH-modeller har vært studert i forbindelse med utvikling av
modelleringsretninglinjene i SERES.
V Meldinger over landegrensene
Det er et økende behov for å sende meldinger over landegrensene. I disse tilfelle vil det måtte
benyttes en internasjonal standard for meldingsbeskrivelser som i de fleste tilfelle må
oversettes fra nasjonale beskrivelser. Det er da naturlig å oversette forskjellen både i
informasjonsstruktur og språk i en felles prosess. Det som da vil være nyttig er at vi kan legge
inn tilleggsinformasjon som relaterer våre informasjonselementer til en internasjonal standard,
f.eks. XBRL (se vedlegg Internasjonale standarder).
69

VI Import av eksterne modeller
Som hjelp til import av eksterne modeller er det utviklet et separat verktøy kalt XMIgen som
leser et UML-forankret XML-format XMDL som er svært mye enklere enn XMI. Verktøyet
genererer som navnet antyder en XMI-basert modell som kan importeres av SERESuml.
Programmet kan også generere XMDL-filer basert på SQL-baserte etableringsskript for
databaser.
Programmet skal i utgangspunktet bare brukes internt ved Brønnøysundregistrene. Det viktige
her er XMDL-formatet som alle som vil kan generere for å få spesifisert sine metadata for
enkel import til SERES. Brønnøysundregistrene gir bistand dersom noen vil bruke SQLfunksjonaliteten
til programmet.
Her er et eksempel på innholdet i dette formatet:
Her er en fullt sett av XML-komponenter en kan bruke:
Tagnavn Attributtnav Beskrivelse Subtagge Eksempel
n
r
model Alle
unntatt
'model'
name Kortnavnet på
modellen
name="SSB"
tekst Fullnavnet på tekst="Domenemodel
70

modellen l for SSB"
datatype
name Datatypens navn name="nummer"
def Definisjon av
def="Pengeverdi med
datatypen
enhet"
inherits Navn på supertypen
inherits="identifikator
ved arv
"
abstract Datatypen er abstrakt
hvis verdi er '+'
abstract="+"
root Datatypen har ingen
supertyper hvis verdi
er '+'
root="+"
leaf Dataypen har ingen
leaf="-" (attributtet
subtyper hvis verdi '+'
kan da sløyfes)
cc Tilsvarende Core
Component
Permissible
Representation Term
cc="Date Time"
xsd Tilsvarende XML
Schema Datatype
xsd="dateTime"
iso Tilsvarende ISOstandard-element
class 'attribute'
name Klassenavn name="Pasient"
def Definisjon av klassen def="Fysisk person"
inherits Navn på superklasse inherits="Person"
cc Tilsvarende Aggregate
Core Component
attribute
name Attributtnavn name="gatenavn"
datatype Navn på datatype for
attributtet
datatype="navn"
multiplicity Kardinalitet for
attributtet
multiplicity="1..*"
def Definisjon av
attributtet
def="Offisielt navn"
cc Tilsvarende Basic
Core Component
association 'role'
name Assosiasjonsnavn name="personadresse"
role
name Assosiasjonsendenavn
(rollenavn)
name="har"
class Navn på assosiert
klasse
class="Adresse"
multiplicity Kardinalitet for
assosiasjonsenden
multiplicity="0..*"
71

associationClas
s
def Definisjon av
assosiasjonsenden
name Assosiasjonsklassenav
n
def="Offisielt navn"
'attribute' name="Adressetype"
72

VII Ordliste
1. Abstrakt
Et modellelement kan være abstrakt. Det betyr at det ikke kan instansieres, dvs. det kan ikke
ha forekomster i den utgaven som er abstakt, men bare som spesialiseringer som bygger på
det abstakte elementet. En abstrakt klasse i en informasjonsmodell kan ikke benyttes i en
dokumentmodell, men subklasser som bygger på denne og derigjennom henter attributter og
assosiasjoner fra denne kan brukes. Dersom et attributt er koplet til en abstrakt semantisk type
i informasjonsmodellen, må attributtet i tilhørende dokumentmodell koples til en
spesialisering av den abstakte typen.
2. Antonymer
Ulike ord med motsatt betydning. Disse deles inn i to undertyper: absolutte og relative. De
absolutte har bare to mulige verdier, mens de relative kan ha mellomverdier.
Eksempler på absolutte antonymer: ja og nei, sant og usant, gutt og jente.
Eksempler på relative antonymer: ung og gammel (med mellomverdier litt ung, halvgammel
etc.), høy og lav (med mellomverdi normalhøy).
Ref. Synonymer, Homonymer, Hyponymer og hyperonymer, Polysemer, Metaforer.
3. Arv
Arv er en relasjon som brukes mellom klasser. Klasser som inngår i en arverelasjon er en
spesialisering av /generalisering fra en annen klasse. For eksempel kan klassene ”Bedrift” og
”Person” ha ”Subjekt” som en felles generalisering. Da arver ”Bedrift” og ”Person” fra
”Subjekt” og er altså spesialiseringer av ”Subjekt”. En spesialisering av en klasse arver alle
egenskaper fra superklassen.
4. Assosiasjon
En assosiasjon mellom to klasser beskriver at objekter av hver klasse kan eller skal ha en
forbindelse seg imellom. For eksempel er det naturlig med en assosiasjon mellom en
Arbeidsgiver- og Arbeidstaker-klasse. En assosiasjon har to Assosiasjonsender som uttrykker
hvilke roller objekter av klassene har til hverandre. Noen ganger er rollene symmetriske, men
ikke alltid.
Assosiasjoner er urettede eller rettede. I en urettet assosiasjon er objekter av begge klassene
synlige for hverandre, mens i en rettet assosiasjon er objekter av den klassen synlig som har
en pil rettet mot seg, mens objekter av klassen i andre enden er "ukjent" for den andre.
5. Assosiasjonsende
En assosiasjonsende er koplingen mellom en Assosiasjon og en Klasse. En assosiasjonsende
kan ha et navn, ha kardinalitet og være navigerbar (eller ikke). Navnet benyttes for å indikere
rollen tilknyttet klasse har i forhold til den andre klassen. Kardinaliteten angir antall objekter
(av klassen koblet til assosiasjonsenden) som kan inngå i den gitte assosiasjonen til ethvert
objekt av klassen koblet til den andre assosiasjonsenden. At den er navigerbar betyr at
tilknyttet klasse er synlig for (kan hente informasjon fra) klassen tilknyttet andre
assosiasjonsenden.
6. Assosiasjonsklasse
En assosiasjonsklasse er en assosiasjon som er utvidet med en egen klasse for ekstra
beskrivelse.Den uttrykkes i en klassediagram ved en assosiasjon på vanlig måte og som har en
stiplet linje til en egen klasse. Klassen og assosiasjonen er ett og samme modellelement som
har egenskaper både som klasse og assosiasjon.
73

7. Attributt
Et attributt for en klasse beskriver en karakteristikk eller en egenskap til alle objektene av
denne klassen. For eksempel er fødselsdato en egenskap ved en person, og dermed et aktuelt
attributt for klassen ”Person”.
8. Avgiverdimensjon
En dimensjon er en gitt faktor som er definert for en avgivermodell. Eksempler på
avgiverdimensjoner er: Organisasjonsform, Antall ansatte, Næringstype, Varetype, Eksport /
import osv. En avgivermodell kan ha et visst antall avgiverdimensjoner. Noen
avgivermodeller vil bare ha en avgiverdimensjon, mens andre vil relatere seg til mange eller
alle potensielle avgiverdimensjoner.
9. Avgivermodell
Et viktig spørsmål i forhold til overlappssøk er hvem som kan eller må avgi en blankett eller
en melding. Avgivermodellen er en beskrivelse av hvem som skal levere en blankett eller
melding og for hvilket tidspunkt eller tidsperiode dataene i blankett/meldingen gjelder. All
informasjon som kan være relevant i forhold til hvem som skal levere hvilken informasjon bør
taes med.
10. Blankett
En blankett er et elektronisk eller papirbasert skjema. En blankett inneholder hele eller deler
av informasjonen fra en eller flere dokumentmodeller, og inneholder i tillegg informasjon om
utforming.
11. CamelCase
CamelCase er en måte å sette sammen flere ord til ett sammenhengende "ord" ved å bruke stor
forbokstav på hvert nytt ord som knyttes på, f.eks. LønnForStrevet. Det er to undertyper:
lowerCamelCase som starter med liten forbokstav og UpperCamelCase som starter med stor
forbokstav.
12. Diagram
Et diagram er det en bruker primært opererer gjennom for å bygge opp og endre modeller. Et
diagram er presentert i et egen diagrampanel. Den viser aktuelle klasser med relasjoner som
brukeren selv har valgt ut og er organisert slik brukeren selv ønsker det. For eksempel vil et
diagram ha posisjons- (koordinat-) informasjon koplet til klasse- og relasjonssymboler. En
bruker kan ha flere diagrammer som hver viser ulike utsnitt av informasjonsmodellen, eller de
kan alternativt vise dokumentmodeller.
13. Dimensjonsløs
En størrelse er dimensjonsløs dersom den ikke har en tilknyttet enhet. Dimensjonsløse
størrelser er som regel forholdstall, f.eks. andelen kvinner i en bedrift som uttrykkes som en
fraksjon (0,59) eller en prosent 59%.
14. Dokument
En fil der innholdet har et gitt eksternt definert format.
15. Dokumentmodell
En dokumentmodell definerer strukturen og semantikken for innholdet i en gitt melding som
brukes for informasjonsutveksling mellom aktører. Den henter all semantikk fra
74

informasjonsmodellen ved å være et utplukk av informasjonselementer herfra med eventuelle
justeringer av disse for å passe til meldingen.
16. Format
Et format angir hvordan en semantisk type skal representeres i ulike sammenhenger. Vi skiller
mellom transportformat som beskriver hvordan den semantiske type representeres i
meldinger, lagringsformat som beskriver hvordan den semantiske typen representeres i ulike
databaser og visningsformat som beskriver hvordan den semantiske typen ser ut i elektroniske
blanketter. Hvert format har et navn. Ett av formatene (eller det ene formatet) for en
semantisk type vil være et standardformat. Hvert format er definert gjennom en eller flere
formatregler.
17. Generalisering
Se Arv.
18. Gjenbrukssøk
For å få overlappssøk til å fungere på en god måte er vi avhengige av at man benytter seg av
eksisterende klasser der dette er mulig i stedet for å lage en ny klasse. Hvis bare deler av
funksjonaliteten allerede finnes i klasse A, arver man A for så å lage en ny klasse B basert på
funksjonaliteten i A. Gjenbrukssøket vurderer om det finnes klasser i informasjonsmodellen
som likner på den du prøver å lage. Brukeren får opp en liste over kandidatklasser og velger
den som passer best.
19. Grunndata
Dette er sentrale deler av den totale informasjonsmodellen som arves eller har relasjoner fra
flere etatsspesifikke domenemodeller. Det at alle domenemodellene direkte eller indirekte
skal referere til grunndata gjør at modellene samlet kan betraktes som en stor
informasjonsmodell.
20. Grunnleggende semantiske typer
Dette er de semantiske typer som ikke har supertyper, derfor kalt rottyper. Dette er et sett på
følgende 10 typer identifikator, kode, tekst, alternativ, tall, antall, mål, beløp, tidspunkt,
binærobjekt. Alle andre semantiske typer skal være subtyper (gjennom ett eller flere ledd) av
disse.
21. Homonymer
Ord som skrives og/eller uttales likt, men har flere betydninger. Disse deles inn i to
undergrupper: Homofoner som uttales likt og Homografer som skrives likt.
Eksempel på homofoner: vinn og vind
Eksempel på homograf: egg (spiselig fra høna eller skjæredel på kniv).
22. Hyponymer og hyperonymer
Ord som er submengde eller supermengde av et annet ord.
Eksempler: hingst er et hyponym av hest, mens hest er hyperonym av hingst.
rose er et hyponym av plante, mens plante er hyperonym av rose.
23. Informasjonselement
Dette er et element i en informasjonsmodell som representerer ett enkelt dataelement.
75

24. Informasjonsmodell
I SERES finnes det en informasjonsmodell. Denne inneholder informasjonselementer som
behøves i forbindelse med avgivelse av informasjon til det offentlige og mellom offentlige
etater. Informasjons-modellen består av klasser og relasjoner mellom klassene. Vi arbeider
med informasjonsmodellen i hovedsak gjennom bruk av diagrammer.
25. Klasse
En klasse representerer et begrep i den virkelige verden. Sentrale eksempler på klasser i vårt
system er Person og Enhet. En modellklasse består av et antall beskrivelseselementer som
enten er attributter eller assosiasjoner. Disse elementene beskriver en felles
informasjonsstruktur til alle objektene av klassen. En klasse kan arve attributter og
assosiasjoner fra en annen klasse (som da kalles superklasse). Fra superklassens synspunkt
kalles klassen en subklasse.
26. Kravspesifikasjon
Detter er summen av funksjonelle krav til systemet. Disse kravene ”interesserer seg ikke” for
hvordan systemet skal realiseres i praksis.
27. Kodeliste
En kodeliste er en samling elementer, kalt kodelisteelementer, som hver har en kode og en
definisjon. Koden er unik for hver kodeliste og definisjonen skal entydig beskrive det unike
med elementet.
28. Løvelement
Nederste element i en trestruktur, også kalt løvnode. Elementet har ingen subelementer, bare
eventuelle superelementer. Eksempler på løvelementer er løvklasser og løvtyper. Metaforen er
et tre snudd på hodet slik at løvet (bladene) kommer nederst.
29. Melding
En melding er et dokument som inneholder data i et gitt struktur som er definert av en
meldingsbeskrivelse. En melding sies også å være en instans av en meldings-beskrivelse.
30. Meldingsspesifikasjon
En meldingsspesifikasjon er en definert samling av informasjonsbærere eller metadata med en
gitt struktur. I vårt system vil den være et uttrekk fra en informasjonsmodell via en
dokumentmodell med påbygging av formater og realisert som et XML Schema-dokument.
31. Metadata
Metadata er en definisjon eller beskrivelse av data, såkalt ”data om data”. Metadata gir
informasjon om hva et enkelt dataelement eller en gruppe av data egentlig er. Ordet er utledet
fra gammelgresk "meta" som blant annet betyr "sammen med".
32. Metaforer
Dette er polysemer som er overført fra et gitt bruksområde til et annet.
Eksempler: stolbein (fra menneske/dyrebein), flerarmet lysestake, trestruktur (fra trærne i
skogen), rotelement, ikon (fra religiøse malerier).
33. Modell
En modell er en forenklet beskrivelse av deler av virkeligheten, som fokuserer på de
aspektene/detaljene ved virkeligheten vi er interessert i.
76

34. Modellelement
Dette er et enkeltelement i en modell. Både klasser, klasseattributter, semantiske typer,
assosiasjoner og generaliseringer er modellelementer.
35. Modellering
Modellering er oppbygging og endring av en Modell.
36. Node
En node betegner gjerne et element i en Trestruktur. Toppnoden eller rotnoden er den øverste
i trestrukturen, mens løvnodene er de ytterste/underste i trestrukturen.
37. Ontologi
En ontologi (læren om hvordan ting er) er en informasjonsmodell for et domene som
inneholder beskrivelser av informasjonselementer og relasjoner mellom disse. Ofte brukes
ontologibegrepet om relativt avanserte mekanismer for relasjonsbeskrivelser, men blir også
brukt som en samlebetegnelse for alle typer informasjonsbeskrivelser, også vokabularer,
Taksonomier og Tesauruser.
38. Overlappssøk
Søk etter innrapportering av samme informasjon flere ganger. Eksempel på dette kan være
sjekk av hvorvidt en bedrift må innrapportere antall ansatte ved et gitt årsskifte to eller flere
ganger på like mange ulike blanketter.
39. Pakke
Dette er en administrativ samling av et antall informasjonselementer og diagrammer som
hører til en gitt etat eller fagavdeling i en etat. En klasse kan bare tilhøre en pakke og alle
klasser må tilhøre en pakke.
40. Paradata
Dette er data som beskriver forhold rundt instanser av data, for eksempel hvor mange
forekomster av enkeltdata som ligger bak en middelverdi. Ordet er utledet fra gammelgresk
"para" som betyr "ved siden av".
41. Polysemer
Polysemer likner på homonymer, men ordene har ikke flere ulike betydninger, men flere
beslektede betydninger. Eksempel: vill i de ulike, men beslektede betydningene "ville
blomster" og "ville mennesker".
42. Rotelement
Øverste element i en Trestruktur, også kalt rotnode. Elementet har ingen superelementer, bare
eventuelle subelementer. Eksempler på rotelementer er rotklasser og rottyper. Metaforen er et
tre snudd på hodet slik at roten kommer øverst.
43. Semantikk
Semantikk er beskrivelser av hva begreper betyr. Ofte blir ordene semantikk og Syntaks brukt
i sammenheng. Grunnen til dette er gjerne at man sier at syntaksen er hvordan man skriver
noe. Og at semantikken er meningsinnholdet i det man skriver. I ordene ”blå bil” er de to
ordene med hver sine bokstaver i gitt rekkfølge syntaks, mens en beskrivelse av hva en bil er
og hvordan fargen blå er utgjør semantikken i uttrykket.
77

44. Semantisk type
En semantisk type er et informasjonselement som representerer et sentralt begrep. En
semantisk type er satt sammen av et navn og en definisjon. Alle klasseattributter skal knyttes
til en semantiske type.
45. Serialisering
Serialisering vil si å representere en modell som en lesbar fil. Ideelt sett skal det være et en-tilen-forhold
mellom modellen som en f.eks. ser i form av et diagram og den serialiserte filen.
En meldingsspesifikasjon er en serialisering av en meldingsmodell.
46. Spesialisering
Se Arv
47. Spesifikasjon
I SERES er en spesifikasjon et XML-dokument som representerer en modell, som regel en
meldingsmodell. Det er i størst mulig grad et en-til-en forhold mellom en modell og en
spesifikasjon. All informasjon som finnes i en modell bør også finnes i den tilhørende
spesifikasjonen.
48. Synonymer
Ulike ord med samme eller lik betydning. Eksempler: gate og vei, klokke og ur.
49. Syntaks
Syntaks er formatreglene som gjelder for en skriftlig representasjon av informasjon.
50. Taksonomi
En taksonomi er en samling begreper ordnet i en trestruktur. Taksonomier brukes typisk
innenfor artsbeskrivelser (dyr og planter) og typebetegnelser (utstyr, biler etc). SERES ordner
settet av Semantisk typer i en taksonomi.
51. Tesaurus
En tesaurus en en avansert ordbok hvor alle ord er relatert til hverandre i form av Synonymer,
, Hyponymer og hyperonymer etc.
52. Trestruktur
En trestruktur er en samling elementer (noder) som er knyttet til hverandre i form av foreldreeller
barn-relasjoner, i denne sammenheng som regel betegnet som superelementer
(supernoder) eller subelementer (subnoder).
53. Versjoner
Ulike utgaver av filer og beskrivelser som er knyttet til et gitt tidspunkt og eventuelt en gitt
bruker.
54. XMI
XMI (XML Metadata Interchange) er et XML-format beskrevet i et vokabular hentet fra MOF
(Meta-Object Facility). Åpningstaggen for en klasse kan se ut som følger:

55. XMIgen
XMIgen er et verktøy som leser et UML-forankret XML-format kalt XMDL som er svært
mye enklere enn XMI. Verktøyet genererer en XMI-basert modell som kan importeres av
SERESuml. Programmet kan også generere XMDL-filer basert på SQL-baserte
databaseetableringsskript.
56. Åpen kildekode
Dette er programmer tilgjengelig i form av kildekode som alle kan bruke fullt ut uten å svare
kostnader til den institusjon eller det firma som har intellektuelt eierskap til kildekoden. Det er
god skikk å la egen kode som bygger på den åpne kildekoden også være åpen på samme måte.
Som minimum må en referere til den åpne koden.
57. Åpne standarder
Dette er standarder som alle kan bruke fullt ut uten å svare kostnader til den institusjon eller
det firma som har intellektuelt eierskap til standarden.
58. Åpne system
Dette er systemer som alle kan bruke fullt ut uten å svare kostnader til den institusjon eller det
firma som har intellektuelt eierskap til systemet. Det er normalt et krav at en tydelig forteller
til brukere av sitt eget system at en har implementert hele eller deler av det åpne systemet og
at det angis hvem som har intellektuelt eierskap til dette.
79

VIII Referanser
1. Booch, G., Rumbaugh, J., Jacobson, I.: The Unified Modelling Language User Guide,
2nd edition. Addison-Wesley, Boston, USA, 2005
2. Codd, E. F.: A Relational Model of Data for Large Shared Data Banks.
Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387
3. Date,C.J.: An Introduction to Database Systems, Addison-Wesley, 8th edition, July
2003, 983 pages, ISBN 0321197844
4. Fowler M. & Scott K., 2001, UML distilled: a brief guide to the standard object
modelling language, 2 nd edition, Addison Wesley Longman
5. Glushko, R.J., og McGrath, T.: Document Engineering: analyzing and designing
documents for business informatics and Web services. MIT Press, Cambridge,
Massachusetts, 2005.
6. ISO/IEC 11179, Final committee draft, Parts 1-6
7. ISO 15000-5 ebXML Core Components Technical Specification
8. OASIS: Universal Business Language (UBL) Naming and Design Rules, 15 November
2004
9. Rumbaugh, J., Jacobson, I., Booch, G.: The Unified Modelling Language Reference
Manual, 2nd edition. Addison-Wesley, Boston, USA, 2005
10. W3C: Extensible Markup Language (XML) 1.0 (Second Edition), W3C
Recommendation, 6 October 2000
11. W3C: XML Schema, W3C Recommendations Parts 0, 1, and 2, 2 May 2001
80