1. Innledning

På denne siden forklares noen sentrale UML-elementer som kan finnes i ulike diagramtyper. Kapittelinndelingen nedenfor følger diagramtypene som er mest brukt i UML-modeller i de forskjellige delene av SOSI.

2. Formål

Beskrivelsene av UML-modellelementene på denne siden skal være til hjelp for lesingen og forståelsen av UML-diagrammer i SOSI-standarder og SOSI-produktspesifikasjoner.

3. Endringslogg

Versjon Dato Oppsummering

0.1

2021.10.07

Første versjon - stort sett en kopi av eksisterende presentasjoner som igjen er basert på SOSI - Regler for UML-modellering 5.1

4. Elementer i klassediagrammer

4.1. Eksempel: Klassediagram "Komitémedlemmer med biler"

Eksempelet nedenfor inneholder de mest sentrale elementene i et UML-klassediagram. Elementene i diagrammet beskrives i de følgende kapitlene.

klassediagram
Figure 1. Klassediagram: 'Komitémedlemmer med biler'.

4.2. Klasser

Klasser vises som firkantede bokser med felt for navn, egenskapsliste, operasjoner og restriksjoner.

klasser
Figure 2. Elementer som vanligvis vises for klasser i diagrammene: Navn, egenskapsliste, operasjoner, restriksjoner.

4.2.1. Stereotyper

Stereotyper står rett foran navnet på klassen med «» rundt. Hver stereotype har en spesiell betydning.

Stereotype «FeatureType»

Klasser med stereotype «FeatureType» er geografiske objekttyper som kan ha egenskaper med geometritype, eller ha andre geografiske tilknytninger.

featuretype
Figure 3. Klasse Kjøretøy med stereotype «FeatureType».
Stereotype «dataType»

Klasser med stereotype «dataType» er identitetsløse samlinger av egenskaper som kun kan oppstå som egenskapstyper eller komponenter i andre klasser.

datatype
Figure 4. Klasse Adresse med stereotype «dataType» som er brukt som egenskapstype for egenskap bosted i klassen Person.
Stereotype «enumeration»

Klasser med stereotype «enumeration» er lukkede lister av navnede koder (= lukkede kodelister).

Innholdet i lukkede kodelister forandres ikke under modellens levetid.

enumeration
Figure 5. Klasse Ukedag med stereotype «enumeration»: Lista er lukket og det er åpenbart ikke behov for utvidelse med flere ukedager.
Stereotype «CodeList»

Klasser med stereotype «CodeList» er utvidbare lister av navnede koder (= åpne kodelister).

Innholdet i åpne kodelister kan endres uavhengig av modellens versjon, men klare regler for hvordan kodelistekoder skal kunne endres må gis av ansvarlig etat.

codelist
Figure 6. Klasse Produsent med stereotype «CodeList»: Lista kan utvides med flere bilprodusenter ved behov.

4.2.2. Arv

Arv mellom klasser vises som streker med åpen trekant mot klassen det arves fra (supertype).

Arveforholdet representerer spesialisering og generalisering, og er et viktig konsept i objektorientert arkitektur. Egenskaper, operasjoner, assosiasjoner og restriksjoner blir overført fra supertypen (klassen på et generalisert nivå) til subtypen (klassen på et mer spesialisert nivå).

arv
Figure 7. Arveforhold: Egenskapene og operasjonen i klassen Kjøretøy (supertype) arves av klassene Bil og Tog (subtyper).

4.2.3. Abstrakte klasser

Klasser som har navnet i kursiv er abstrakte klasser og kan ikke instansieres.

abstraktKlasse
Figure 8. Klasse Kjøretøy er abstrakt (legg merke til kursiv klassenavn). I dette eksempelet instansieres aldri Kjøretøy, men egenskapene og operasjonen i klassen Kjøretøy arves av klassen Bil og Tog og instansieres gjennom objekter av disse klassene.

4.3. Assosiasjoner

Assosiasjoner mellom klasser vises som streker mellom de firkantede boksene. De kan ha egne assosiasjonsnavn, og kan angi hvilken retning navnet indikerer.

assosiasjonsnavn
Figure 9. Assosiasjon med navn Eier mellom klasse Person og klasse Bil.

Assosiasjonsender med pil betyr at assosiasjonen er navigerbar i pilens retningen.

Alle navigerbare ender skal ha rollenavn og multiplisitet ([min..maks]).

rollenavn
Figure 10. Assosiasjonen er navigerbar i begge ender. Begge endene har rollenavn (hhv. eier og eiendel) og multiplisitet. I dette eksempelet kan én ('1') eller flere ('*') personer ha rollen som 'eier' av en bil. Mens ingen ('0') eller flere ('*') biler kan være 'eiendel' til en person.

4.3.1. Aggregering

Assosiasjoner med åpen diamant viser at dette er en samling av selvstendige deler. Dette kalles aggregering i UML.

aggregering
Figure 11. I aggregeringen mellom klasse Komité og klasse Person er Komité det samlende element. I dette eksempelet kan to eller flere personer samles i én komité (sett fra en komitéinstans) og en person kan være med i flere ('*') komitéer, men trenger ikke å være det ('0').

4.3.2. Komposisjon

Assosiasjoner med fylt diamant viser at instanser av klassen på diamantsiden eier komponentene sine, dvs. instansene av klassen på den siden uten diamant. Dette kalles komposisjon i UML.

Modelleres relasjoner mellom klasser på denne måten er det en mye sterkere avhenighet enn ved vanlige assosiasjoner (uten diamanter) eller aggregeringer (med åpen diamant).

Komponentene er eksistensiell avhengig av det samlende objektet. Det betyr at når livsløpssyklusen til objektet på diamantsiden tar slutt, ender også livsløpssyklusen til objektene på komponentsiden.

komposisjon
Figure 12. Komposisjon av tre eller flere hjul tilknyttet til en bil.

5. Elementer i pakkediagrammer

I pakkediagrammer er det fokus på pakker og deres relasjoner til hverandre. Pakkediagrammer brukes under SOSI som regel for å vise direkte avhengighet til elementer i en annen pakke (pakkeavhengighetsdiagram) eller for å vise at elementer i en annen pakke er blitt realisert (pakkerealiseringsdiagram).

5.1. Eksempel: "Komitémedlemmer med biler"

Vi fortsetter med eksempelet fra kap. 4.1 og antar at alle elementer i modellen "Komitémedlemmer med biler" er plassert i én pakke "KomitémedlemmerMedBiler".

pakkeavhengighetsdiagram
Figure 13. Pakkeavhengighetsdiagram: Her vises vår pakke 'KomitémedlemmerMedBiler' og at den er avhengig av pakken 'ISO 19107'.

5.2. Pakke

De sentrale elementene i pakkediagrammer er symboler for pakker med felt for navn og innhold i pakka. I tilfellet pakka har fått tildelt en stereotype, står denne foran navnet med «» rundt.

Pakker med stereotypen «ApplicationSchema» inneholder geografiske objekttyper.

pakke
Figure 14. To pakker hhv. 'KomitémedlemmerMedBiler' og 'ISO 19107' med felt for navn og pakkeinnhold. Ved behov kan visning av pakkeinnhold (klasser, underpakker) deaktiveres.

5.3. Pakkeavhenigighet

Pakkeavhengighet viser at noen klasser i en pakke trenger klasser fra en annen pakke.

Avhengighet mellom pakker vises ved en stiplet linje mellom aktuelle pakker, med pil mot den pakka man er avhengig av.

I vårt eksempel i kap. 4.1 har vi sett at klassen Kjøretøy i pakka 'KomitémedlemmerMedBiler' har en egenskap posisjon som er modellert med egenskapstype GM_Point. GM_Point er en Klasse i pakka ISO 19107 (ISOs geometrimodell). Vi har altså en direkte avhengighet mellom de to pakkene.

pakkeavhengighetsdiagram
Figure 15. Pakkeavhengighetsdiagram: I vårt eksempel har vi sett at en klasse i pakka 'KomitémedlemmerMedBiler' er avhengig av en klasse i pakken 'ISO 19107'. Dette kan visualiseres på pakkenivå ved hjelp av en stiplet linje mellom pakkene med pil mot ISO 19107-pakka.