Retningslinjer for datamodellering i UML (Static Structure Diagram)

Transkript

1 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 1 Retningslinjer for datamodellering i UML (Static Structure Diagram)

2 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 2 Innholdsfortegnelse Retningslinjer for datamodellering i UML (Static Structure Diagram) Innledning Bakgrunn Formål Referanser Ord, termer og forkortelser Definisjoner Forkortelser Introduksjon til UML Inndeling av et interesseområde i objekttyper Innledning Avbildning av den virkelige verden Generell objektmodell (General Feature Model) Hovedregler for modellering av applikasjonsskjema Regler Eksempel UML modell basert på Vegnett Pakker som inngår...17 Veglenkemodellen med knytning til punkter...17 Vegpunktmodell med knytning til veglenker Kodelister og datatyper Praktiske regler for modellering Introduksjon Hva en objekttype Hovedstruktur Integrering av modeller Oppdeling av modeller De enkelte komponenter i et applikasjonsskjema (informasjonsmodell) Objekttyper Egenskaper Modellering av basiselementer og gruppeelementer i SOSI Syntaks Forhold Avhengighet Assosiasjoner og rollenavn Generalisering/spesialisering Operasjoner Syntaks Datatyper: 'Basic' datatyper (draft ISO/TS 19103) Brukerdefinerte datatyper Begrensning av verdidomene Initialverdier Angivelse av kodeverdier Bruk av klasser definert i andre skjema Geometri Geometrityper som ikke kan dele geometri Geometrityper som kan dele geometri Eksempler på bruk av geometrityper Kvalitet for geoemtritypene (stedfestingskvalitet) Interpolasjonsmetode Kvalitet Andre skjema Avledninger Utvidelser av UML Stereotyper...39

3 Retningslinjer for datamodellering i UML (Static Structure Diagram), version De mest vanlige stereotypene: Andre stereotyper: Tagged values Constraints (Avhengigheter) Bruk av farger i UML modeller Dokumentasjon Anvendelse av UML modeller...46 Annex A Spesielle tilfeller(informativt)...47 A.1 Introduksjon...47 A.2 Spesielle situasjoner...47 A.2.1 Modellering av avgrensningslinjer A.2.2 Hvordan modellere når samme objekt går igjen i flere datasett...49 Annex B Modellering i Rational Rose...51 B.1 Introduksjon...51 B.2 Multiplisitet...51 B.3 Initialverdier...52 Annex C Utestående...53 C.1 Områder som trenger videre vurdering...53

4 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 4 Figurliste FIGUR 1. GYLDIGHETSOMRÅDE FOR RETNINGSLINJENE...6 FIGUR 2. INTRODUKSJON TIL UML...11 FIGUR 3. AVBILDNING AV DEN VIRKELIGE VERDEN...12 FIGUR 4. UML MODELL AV DEN GENERELLE OBJEKTMODELLEN...13 FIGUR 5. PAKKER SOM INNGÅR I MODELLEN...17 FIGUR 6. VEGLENKE - DEL AV VEGNETTSMODELL...17 FIGUR 7. PUNKT PÅ VEG - DEL AV VEGNETTSMODELL...18 FIGUR 8. KODELISTER OG DATATYPER...18 FIGUR 9. EKSEMPEL PÅ INTEGRERING AV MODELLER...19 FIGUR 10. EKSEMPEL PÅ OPPDELING I PAKKER...20 FIGUR 11. PAKKEDIAGRAM OG EKSEMPEL PÅ BRUK AV KLASSER DEFINERT I ANDRE PAKKER...21 FIGUR 12. EKSEMPEL PÅ EN ENKEL OBJEKTTYPE DEFINERT SOM KLASSE...22 FIGUR 13. EKSEMPEL PÅ EN KLASSE MED EGENSKAPER...22 FIGUR 14. EKSEMPEL PÅ BRUK AV DATATYPE...23 FIGUR 15. EKSEMPEL PÅ ANGIVELSE AV AVHENGIGHET...24 FIGUR 16. ASSOSIASJON...25 FIGUR 17. AGGREGERING...25 FIGUR 18. EKSEMPEL PÅ EN SVAK AGGREGERING MELLOM EIENDOMSGRENSE OG GRENSEPUNKT...25 FIGUR 19. KOMPOSISJON...26 FIGUR 20. EKSEMPEL PÅ EN STERK AGGREGERING /KOMPOSISJON...26 FIGUR 21. ANGIVELSE AV ULIKE TYPER MULTIPLISITET...26 FIGUR 22. EKSEMPEL PÅ ASSOSIASJON MED RETNING...27 FIGUR 23. EKSEMPEL PÅ BRUK AV SPESIALISERING FOR Å ANGI ULIK DETALJERINGSGRAD...28 FIGUR 24. EKSEMPEL PÅ MODELLERINGSTEKNISK BRUK AV GENERALISERING/SPESIALISERING...28 FIGUR 25. EKSEMPEL PÅ ANGIVELSE AV OPERASJONER FOR EN KLASSE (HER OBJEKTTYPEN EIENDOMSTEIG)...29 FIGUR 26. EKSEMPEL PÅ ANGIVELSE AV EN OPERASJON MED 'SIGNATUR'...29 FIGUR 27. EKSEMPEL PÅ BRUKERDEFINERTE DATATYPER...32 FIGUR 28. EKSEMPEL PÅ 'SUBTYPING' AV KODELISTER...33 FIGUR 29. EKSEMPEL PÅ INNSKRENKNING AV VERDIER VED BRUK AV NOTE...33 FIGUR 30. INITIALVERDIER...34 FIGUR 31. ULIKE METODER Å MODELLERE KODELISTER...34 FIGUR 32. SOSI ENKEL GEOMETRI...35 FIGUR 33. SOSI DELBAR GEOMETRI...36 FIGUR 34. EKSEMPEL PÅ BRUK AV GEOMETRI SOM KAN DELES MELLOM OBJEKTTYPER...36 FIGUR 35. EKSEMPEL PÅ EN OBJEKTTYPE MED GEOMETRI SOM KAN DELES...36 FIGUR 36. ANGIVELSE AV POSISJONSNØYAKTIGHET...37 FIGUR 37. EKSEMPEL PÅ ANGIVELSE AV INTERPOLASJONSMETODE FOR KURVEGEOMETRI...38 FIGUR 38. EKSEMPEL PÅ MODELLERING AV AVLEDNING...38 FIGUR 39. EKSEMPEL PÅ BRUK AV AGGREGERING OG SPESIALISERING SOM ALTERNATIV TIL AVLEDNING FIGUR 40. EKSEMPEL PÅ ENUMERATION...40 FIGUR 41. EKSEMPEL PÅ BRUK AV EGENDEFINERT DATATYPE...40 FIGUR 42. EKSEMPEL PÅ BRUK AV KODELISTE...41 FIGUR 43. EKSEMPEL PÅ ANGIVELSE AV INTERFACE...41 FIGUR 44. EKSEMPEL PÅ ANGIVELSE AV <<TYPE>>...41 FIGUR 45. EKSEMPEL PÅ BRUK AV <<LEAF>>...42 FIGUR 46. EKSEMPEL PÅ ANGIVELSE AV AVHENGIGHET SOM NOTE...42 FIGUR 47. EKSEMPEL PÅ ANGIVELSE AV KLASSER DEFINERT I ANDRE PAKKER...47 FIGUR 48. EKSEMPEL PÅ ANGIVELSE AV AVGRENSNINGSLINJE FOR ET POLYGON...48

5 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 5 FIGUR 49. EKSEMPEL PÅ ANGIVELSE AV AVGRENSNINGSLINJE KNYTTET TIL GEOMETRIEN...49 FIGUR 50. EKSEMPEL PÅ BRUK AV ABSTRAKTE KLASSER (KURSIV)...49 FIGUR 51. EKSEMPEL PÅ AT DETTE ER ANGITT SOM EN EGENSKAP TIL OBJEKTTYPEN 50 FIGUR 52. EKSEMPEL PÅ ANGIVELSE SOM EN DEL AV OBJEKTTYPENAVNET...50 FIGUR 53. ANGIVELSE AV MULTIPLISITET - GRAFISK NOTASJON...51 FIGUR 54. CLASS ATTRIBUTE SPECIFICATION FOR MULTIPLICITY IN RATIONAL ROSE 51 FIGUR 55. KODELISTE MED VERDIER + KODE...52 FIGUR 56. ANGIVELSE AV FASTE INITIALVERDIER - GRAFISK NOTASJON...52 FIGUR 57. CLASS ATTRIBUTE SPECIFICATION FOR MULTIPLICITY IN RATIONAL ROSE 52

6 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Innlednin g 1.1 Bakgrunn Bakgrunnen for dette dokumentet er at dagens nasjonale SOSI-standard vil gjennomgå endringer for å kunne være konform med ISO standardene. Referansegruppe K176 har en klar strategi på å konvergere SOSI mot internasjonale standarder, da spesielt ISO 191xx serien. Modelleringsreglene i dette dokumentet er spesielt rettet mot dette, men vil også være retningsgivende for generell modellering av geografisk informasjon. 1.2 Formål Formålet med dette dokumentet er å gi retningslinjer for implementasjonsuavhengig modellering av geografiske objekter i et applikasjonsskjema. Spesifikasjon av systemløsninger, samt modellering for en systemavhengig implementasjon ligger utenfor rammen av disse retningslinjene. Dette dokumentet gir ingen fullstendig innføring i UML. Til dette anbefales generell UML-litteratur, som det finnes mye av. Dokumentet forsøker å gi regler og eksempler på modellering av geografisk informasjon, basert på erfaring med spesielt SOSI og NGIS. I tillegg til eksempler og regler er det tatt med formell syntaks for enkelte av de mest grunnleggende konseptene. Et applikasjonsskjema (informasjonsmodell) beskrevet i UML har to formål: Den skal gi en korrekt menneskelig forståelse av objekter, egenskaper, relasjoner og eventuelt operasjonen innenfor sitt fagområde. (Med fagområde mener her veger, jernbane, topografi, etc.) Den skal være leselig av en datamaskin, for å kunne anvende automatiske rutiner i henhold til implementasjon, dataforvaltning og utveksling. UML er et omfattende språk, og en kan beskrive det samme på flere måter. Dette som omtales her er anbefalinger, andre måter å modellere kan være korrekt i henhold til de normative referansene (ikke minst ISO UML) Imidlertid er det ønskelig å modellere mest mulig ensartet, for å sikre interoperabilitet. UML er et implementasjonsuavhengig språk. Sammen med implementasjonsuavhengige datatyper ('basic data types'), må dette 'mappes' mot ulike implementasjoner. Disse retningslinjene beskriver ikke systemimplementasjoner, dette må gjøres av de respektive systemleverendører, på samme måte som de i dag gjør i forhold til SOSI. Forskjellen nå ligger i at vi legger en internasjonalt akseptert objektmodell (general feature model) til grunn for selve modelleringen, med forventninger om at denne også understøttes av de ulike leverandørene. Formalisme ISO ISO Implementation independent (UML) Retningslinjer for UML modellering mapping implementasjonsavhengig Appl 1 Appl 2 Appl 3 Appl <n> mapping Internt skjema Spatial database Figur 1. Gyldighetsområde for retningslinjene

7 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 7 For å sikre at modellene enkelt lar seg implementere, legger vi stor vekt på i disse retningslinjene å forholde oss til de mest vanlige mekanismene i UML, men uten å legge skjul på at det finnes en rekke andre mekanismer. Disse retningslinjene omfatter UML's static structure diagram, med basis data typer definert i ISO Conceptual Schema Language. Denne versjon av retningslinjene beskriver ikke bruken av OCL (Object Constraint Language) for angivelse av noter (merknader) i maskinlesbar form. Det er en målsetting at dokumentet skal være retningsgivende for det videre arbeidet med SOSI og produktspesifikasjoner, både i forbindelse med AREALIS, FKB og andre produktspesifikasjoner for geodata. Dette dokumentet gir imidlertid ikke føringer for hvor raskt denne endringen skal skje. Disse retningslinjene er i stor grad anvendt for gjeldende versjon av SOSI, og er førende for det videre arbeidet framover, både utvikling av nye objektkataloger og produktspesifikasjoner, samt for konvergeringen mot internasjonale standarder i regi av ISO/TC Referanser ISO 19103, Geographic information Conceptual schema language [CSL] ISO 19104, Geographic information Terminology ISO 19107, Geographic information Spatial Schema ISO 19109, Geographic information Rules for application schema [RAS] ISO 19110, Geographic information Feature cataloguing methodology. [FCM] ISO 19113, Geographic information Quality Principles ISO 19115, Geographic information Metadata ISO 11179, part 5, Naming and Identification Principles for Data Elements. ISO 19501, UML (Unified Modelling Language) UML v.1.1 Semantics, Appendix B - Glossary

8 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Ord, term er og forkortelser 2.1 Definisjoner I dette kapittelet er de fleste termer definert, både på norsk og engelsk. Første linje inneholder termen på norsk, i uthevet skrift. I noen tilfeller er det også en synonym, dvs at det er flere termer for det samme. Neste linje er den engelske termen, skrevet i kursiv Så følger en norsk forklaring og eventuelt en engelsk forklaring, igjen i kursiv. Hensikten med de engelske termene er å lettere kunne relatere dette til internasjonale standarder/dokumenter. Siden dette dokumentet blant annet gir føringer for hvordan en generell beskrivelse av objekter avbildet fra en nærmere angitt virkelighet skal modelleres er det tatt med begreper fra både generell modellering og det skjemaspråk som er valgt innenfor geografisk informasjon, UML. applikasjonsmodell datamodell <Mangler> application schema <Mangler> aggregering svak aggregering <Mangler> aggregation A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element may be used where the more general element is allowed. [UML Semantics, version 1.1] assosiasjon forhold mellom objekttyper eller objekter i form av en vanlig assosiasjon, aggregering eller komposisjon feature association relationship between features NOTE 1 A feature association may occur as a type or an instance. Feature association type or feature association instance is used when only one is meant. NOTE 2 Feature associations include aggregation of features. beskrankninger avhengighet/begrensning constraint semantic condition or restriction represented as an expression. [UML] [ISO 19103] data type <Mangler> data type specification of a legal value domain and legal operations on values in this domain EXAMPLE: Integer, Real, Boolean, String, Date and GM_Point. NOTE A data type is identified by a term, e.g. Integer [ISO 19115, ISO 19118]

9 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 9 komposisjon sterk aggregering <Mangler> composition <Mangler> objekt forekomst (instans) av en objekttype. feature Instance abstraction of real world phenomena NOTE A feature may occur as a type or an instance. Feature type or feature instance should be used when only one is meant. objektegenskap egenskap en objekttypes eller objekts karakteristikk feature attribute characteristic of a feature NOTE 1 A feature attribute may occur as a type or an instance. Feature attribute type or feature attribute instance is used when only one is meant. NOTE 2 A feature attribute type has a name, a data type and a domain associated to it. A feature attribute instance has an attribute value objektkatalog Definisjon og beskrivelse av objekttyper, objektegenskaper samt relasjoner mellom objekter, sammen med eventuelle funksjoner som er anvendt for objektet. Eksempel: SOSI feature Catalogue <Mangler> objektoperasjon operasjon handling som kan utføres på bakgrunn av eller ved hjelp av objekter eller objekttyper????? feature operation operation that may be performed upon or by all instances of a feature type [ISO 19110] EXAMPLE 1 EXAMPLE 2 A feature operation upon the feature type "dam" is to raise the dam. The results of this operation are to raise the height of the "dam" and the level of water in a "reservoir". A feature operation by the feature type "dam" might be to block vessels from navigating along a watercourse. klasse <Mangler> class <Mangler> kodeliste Spesifiserer verdier i et åpent verdidomene. Dette betyr at verdidomet kan endre seg. Ekempelvis vil de fleste egenskapene i SOSI være definert i form av en kodeliste. codelist Can be used to describe a more open enumeration. <<CodeList>> is a flexible enumeration that uses string values through a binding of the Dictionary type key and return values as string types; e.g. Dictionary (String, String). Code lists are useful to for expressing a long list of potential values. If the elements of the list are completely known, an enumeration should be

10 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 10 used; if the only likely values of the elements are known, a code list should be used. Enumerated code lists may be encoded according to a standard, such as the ISO standard for two-letter country codes or for two-letter language code. Code lists are more likely to have their values exposed to the user, and are therefore often mnemonic. Different implementations are likely to use different encoding schemes (with translation tables back to other encoding schemes available). ISO CD CSL lukket kodeliste Spesifiserer verdier i et lukket verdidomene, f.eks. sann/usann for boolske operatorer. Denne benyttes når samtlige verdier i verdidomenet er spesifisert. enumeration A data type whose instances form a list of named literal values. Enumeration means a short list of well-understood potential values within a class. Classic examples are Boolean that has only 2 (or 3) potential values TRUE, FALSE, (and NULL). Most enumerations will be encoded as a sequential set of Integers, unless specified otherwise. The actual encoding is normally only of use to the programming language compilers. ISO CD CSL type <Mangler> type A stereotype of class that is used to specify a domain of instances (objects) together with the operations applicable to the objects. A type may not contain any methods. subtype <Mangler> subtype In a generalization relationship the specialization of another type, the supertype. See generalization. [UML Semantics, version 1.1] supertype <Mangler> supertype In a generalization relationship the generalization of another type, the subtype. See generalization [UML Semantics, version 1.1] UML-pakke <Mangler> package general-purpose mechanism for organizing elements into groups. Packages may be nested within other packages. Both model elements and diagrams may appear in a package. [ISO terminology] 2.2 Forkortelser RAS - ISO 19109, Geographic information Rules for application schema FCM - ISO 19110, Geographic information Feature cataloguing methodology CSL - ISO 19103, Geographic information Conceptual schema language

11 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Introduks jon til UML Eksempel på noen av de viktigste hovedelementene i et UML objektklasse-diagram. Forening + møtedag : Ukedag + formål[0..3] : CharacterString 0..* Kjøretøy + passasjerer : Integer + merke : Produsent + Start() +medlem 2..* Person + vekt : Real + bosted : Adresse +eier Eier > +eiendel 1..* 0..* Bil Tog NOTE: Må være oppført i kjøretøyregisteret +bestanddel Hjul 3..* <<Enumeration>> Ukedag mandag tirsdag onsdag torsdag fredag lørdag søndag <<CodeList>> Produsent Fiat Volkswagen Lada Skoda <<Datatype>> Adresse + gate : CharacterString + husnr : Integer + postnr : Integer + poststed : CharacterString Figur 2. Introduksjon til UML Objekttyper: Interesseområdet kan deles inn i objekttyper som har samme egenskaper, relasjoner og oppførsel. Forening, Person, Bil, Tog, Hjul.. Egenskaper: En forening kan ha minst en, og inntil tre (av egenskapen) formål Foreningen har en fast møtedag, som er tatt ifra en lukket liste over ukedager. En Person kan ha en angitt egenskapsverdi for sin vekt, av typen desimaltall. Et kjøretøy kan ta et antall passasjerer, av typen heltall. Et kjøretøy kan ha et fabrikat, med verdi tatt ifra en åpen liste. Åpen aggregering: En Forening består av medlemmer som er Personer. Foreninger må ha minst to medlemmer. (2..*). En Person kan være medlem av flere Foreninger. Vanlig assosiasjon: Personer Eier> Biler. Null eller flere Biler (0..*) kan ha rollen som en eiendel til en Person. En Bil må ha minst en Person (1..*) som eier. Komposisjon: En Bil har (som eide komponenter) minimum tre Hjul. Pilen angir at instanser av Hjul ikke kan finne ut hvilken Bil de sitter på. Subtyping: Bil er en subtype av Kjøretøy. (Arver egenskaper, relasjoner og operasjoner.) Kjøretøy er supertype av Bil og Tog. Abstrakte supertyper instansieres ikke. Oppførsel: Et Kjøretøy kan utføre en operasjon Start(). Lukket liste Enumeration: Ukedag er en lukket liste hvor ingen nye verdier kan legges inn. Åpen liste Codelist: Produsent er ei liste over kjente produsenter, åpen for nye produsenter. Datatype: Adresse er en egendefinert datatype som beskriver verdidomenet til bostedet for en Person. Note: Noten koblet til Eierskapet mellom Person og Bil er en beskrankning på assosiasjonen.

12 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Inndeling av et interesseområde i objekttyper 4.1 Innledning Det har fra hold fremkommet ønske om å få retningslinjer for hva som er geografisk objekter. En kunne selvsagt ha én objekttype 'geografiskobjekt', med egenskaper som i detalj beskriver objektet. Men dette er lite ønskelig. På den annen side kan vi selvsagt la f.eks. hvert grensemerke bli en egen objekttype, eksempelvis 'bolt i rør', 'kors i fjell', etc. ISO uttrykker følgende: The classification of real world phenomena as features depends on their significance to a particular universe of discourse. 1. Definere ditt interesseområde ('universe of discourse'). 2. Sjekk om det finnes en internasjonal standarder som dekker samme interesseområdet (Dette må forklares nærmere) 3. Objekter med felles definisjon og samme egenskaper er kandidater for en objekttype (klasse). Dersom objekttypen blir vid og favner mange fenomener som har dagligdagse navn bør denne vurderes splittet opp i henhold til disse dagligdagse navnene. Fra tidligere diskusjoner har en endt opp med at en skal benytte objekttyper som en kjenner igjen innenfor de respektive domener. Eksempelvis vei fremfor kilometrert vei. Men andre vil her igjen hevde det motsatte. Kent utdyper dette: Eksempel på ting som bør utdypes: Hvorfor bruke generalisering? 4.2 Avbildning av den virkelige verden Enhver modellering av geografiske objekter tar utgangspunkt i en avbildning av den virkelige verden. Figur 2 viser prosessen fra en avbildning av den virkelige verden ('universe of discourse') til et geografisk datasett. Definisjonen av objekttyper og deres egenskaper innenfor dette applikasjonsområde, avledes av denne avbildningen av den virkelige verden. Objekttypene dokumenteres i en objektkatalog. Avbildning av den virkelige verden Modell basert på objekttyper og deres egenskaper Konseptuell modell Konseptuell Objekt modell katalog Konseptual modell uttrykt i et konseptual skjema språk Applikasjons skjema Data strukturert i samsvar med applikasjons skjema Data Figur 3. Avbildning av den virkelige verden

13 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Generell objektmodell (General Feature Model) ISO spesifiserer en generell objektmodell for beskrivelse av geografiske objekter (GFM) GFM er en modell av konsepter nødvendige for å klassifisere et bilde (avbildning) av den virkelige verden. Den er uttrykt i UML. UML har sin egen modell av konsepter (metamodell). Siden både GFM og UML's metamodell beskriver klassifikasjoner, er konseptene ganske like. Men det er en stor forskjell; konseptene i GFM danner basis for klassifikasjon av objekttyper (metamodell for objekttyper) mens UML's metamodell danner basis for all slags modellering, ikke bare objekttyper. De objektene vi klassifiserer kalles objekttyper, forholdene mellom objekttyper kalles forhold, nærmere presisert gjennom ulike typer assosiasjoner og subtyper/supertyper. Objekttyper har attributter som kalles objektegenskaper eller bare egenskaper, objektoperasjoner og assosiasjoner angitt gjennom rollenavn. Alle disse konseptene er beskrevet som UML metaklasser i GFM. Objekttyper kan dokumenteres i objektkataloger. GFM kan også fungere som en konseptuell modell for en objektkatalogstruktur. ISO Feature Catqaloge Methodology realiserer GFM konseptene i tillegg til noen egne konsepter som er relatert til objektkataloger, slik som 'alisases' for objektypenavn, samt koder for objekttypenavn. Disse konseptene er ikke i konflikt med GFM. GFM definerer en struktur for å klassifisere objekttyper som inngår i et applikasjonsskjema (datamodell). Men en må være klar over at overgangen fra GFM til UML er en enveisovergang, det er ikke mulig å gå fra UML til GFM. For eksempel, et applikasjonsskjema har UML klasser, noen av disse er GFM objekttyper, mens andre er datatyper for egenskaper. Merknad: Dette er vel ikke noe godt eksempel, datatyper blir jo 'stereotypet' med <datatype>. Men det er ikke mulig å skille mellom geografiske objekttyper og andre objekttyper, f.eks. mellom en eiendomsteig og et lån. Konklusjon: GFM er en metamodell for definisjon av objekttyper samt definerer en struktur for objekttyper, mens UML er en metamodell for selve applikasjonsskjema. Siden det her er snakk om et applikasjonsskjema for objekttyper, må GFM's struktur taes hensyn til ved modellering av applikasjonsskjemaet. 1 Generalization +subtype 1 1..* <<Metaclass>> +supertype GF_FeatureType + typename : LocalName + definition : CharacterString + isabstract : Boolean = false +memberof Specialization 0..* 0..* +linkbetween 0..* 0..* GF_InheritanceRelation + name : CharacterString + description : CharacterString + uniqueinstance : Boolean <<Metaclass>> GF_AssociationType 0..* +carrierofcharacteristics <<Abstract>> GF_PropertyType + membername : LocalName + definition : CharacterString 0..* +constrainedby 0..* +constrainedby <<DataType>> GF_Constraint + description : CharacterString 1..* <<Metaclass>> GF_Operation + signature : CharacterString <<Metaclass>> GF_AttributeType + valuetype : TypeName + domainofvalues : CharacterString + cardinality : Multiplicity <<Metaclass>> GF_AssociationRole + valuetype : TypeName + cardinality : Multiplicity Figur 4. UML modell av den generelle objektmodellen

14 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 14

15 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Hovedreg ler for modellering av applikasjonsskjema 5.1 Regler Reglene under er et utdrag fra ISO Rules for Application Schema (RAS). Det er tatt med henvisning til kapitler i denne standarden samt ISO (CSL) 1. De følgende regler er konforme med ISO og ISO med unntak spesifisert i tillegg X. 1. Oversikt over datamodellen Ref. RAS Oversikten lages ved å benytte UML s package mekanismer Bruk UML avhengigheter for å vise hvilke andre standard modeller / skjema som modellen benytter seg av. Bruk notes i UML til å vise hvilke definisjoner som benyttes i de andre modellen 2. Identifisering av objekttyper og etablering av UML klasser Ref. RAS 8.1 Studer den del av virkeligheten som skal modelleres ('Universe of Discourse') og identifiser de klasser av geografiske objekter (objekttyper) som tilhører applikasjonen. Konkrete geografiske objekttyper (eksempel: Veg, Bygning,..) Abstrakte (faglige) geografiske objekttyper (eksempel: Veglenke, Vegnode, ) Objekttyper modelleres som UML klasser Ref. RAS Supertype / Subtype Organiser objekttypene i en struktur hvor generalisering og spesialisering av klassene framkommer. Kriterier for dette er En objekttype er en subtype av en annen. (Se eksempel: Europaveg, Riksveg, kan modelleres som subtyper av veg.) Flere objekttyper har flere felles egenskaper. Det kan være nødvendig å introdusere nye klasser som representer supertypen. (eksempel: KilometrertVeg) 4. Egenskaper Egenskaper til objekttyper modelleres som UML attributter i de klasser som representerer objekttypen. Dette gjelder også egenskaper som refererer til klasser i andre standardmodeller Egenskapnavn starter med liten bokstav. Hvis navnet er sammensatt av flere, benyttes STOR førstebokstav fra og med andre navn (eksempel: trafikkretning) 5. Assosiasjoner mellom objekttyper Ref. RAS 8.3 Assosiasjoner mellom objekttyper modelleres som UML association mellom tilhørende klasser. Roller skal angis (eksempel: Rollen sammenknytning i relasjonen mellom Vegnode og Veglenke). Rollenavn skrives med små bokstaver. Kardinalitet skal angis (eksempel: i relasjonen mellom Vegnode og Veglenke er en Veglenke alltid være knyttet til 2 Vegnoder )

16 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Kvalitet og andre metadataelementer Ref. RAS 8.5 Kvalitet knyttet direkte til en objekttype modelleres i form av en egenskap i klassen som representerer objekttypen. (Se eksempel: Egenskapen klassifikasjonsnøyaktighet ). Stedfestingnøyaktighet knyttes til geometri, ved at ISO geometritypen subtypes og at kvalitetsegenskapen legges inn som egenskap. Kvalitet knyttet til en egenskap modelleres ved at egen klasse etableres, hvor både egenskapen for objekttypen og dens kvalitetsinformasjon modelleres inn som egenskaper i denne klassen, som 'stereotypes' 'datatype'. Ref. RAS Ref: Ras Ref. RAS Geometri Ref. RAS 8.7 Geometri modelleres i applikasjonsmodellen som egenskaper til objekttyper, med bruk av de klasser som er definert i den norske geometriprofilen (Eksempel: posisjon: Punktgeometri, eller posisjon: EnkelPunktgeometri) Felles geometri, dvs objekttyper deler geometri-beskrivelser, modelleres ved å bruke Punktgeometri, kurvegeometri og flategeometri, Hvis objekttyper har en forretningsregel seg imellom, skal dette modelleres. Hvis sammenhengen kun er deling av geometrisk forløp så ivaretaes det i geometrimodellen. Ref. RAS Ref. RAS Erstatt underforståtte sammenhenger med eksplisitt beskrivelse Assosiasjoner som ofte ligger i sammenhenger på geometrinivå, kan komme til uttrykk i modellen (eksempel: I gamle VBASE var Vegnode implisitt beskrevet via KP i SOSI data, samt PTEMA langs med en linje). Unngå egenskaper som bærer mer enn en opplysning. 9. Definisjon av verdidomener: Lukket kodeliste [Enumerasjon] Brukes til å definere et gitt lukket verdidomene for en gitt egenskap (eksempel: Dag i ukedag) Dersom en applikasjon bare skal utnytte et gitt subsett av et større sett av en verdi domene, etableres en egen enumerasjon som et subsett hvor lovlige verdier angis (eksempel: Vegmedium som spesialisering av Medium) Ref. CSL Definisjon av verdidomener: Kodeliste [Code List] Ref. CSL Brukes når man vil definere et verdidomene som man regner med vil kunne utvides, der det er hensiktsmessig med en String representasjon (eksempel: Vegnummer). 11. Definisjon av verdidomener: 'Gazetteer' Ref. RAS 8.10 Brukes når det er verdier som ligger i andre databaser (f.eks Postnr, Adresse) Referanser til 'Gazetteer' skal benytte SI_LocationInstance som er definert i Gazetteer Schema. 12 Definisjon av enheter Ref. CSL Brukes for å presisere måledomene for egenskaper, f.eks. med SI Units.

17 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Beskrive beskrankninger (Conditionals) Conditionals knyttet til egenskaper og relasjoner beskrives i "notes" og knyttes til det element i modellen som den beskriver (eksempel: Note knyttet til Veglenke) Conditionals skal beskrives om mulig i OCL (eksempel: Innhold i note knyttet til Veglenke) 14 Navngiving Ref. CSL 7.9 Bruk regler for små og store bokstaver som beskrevet i kapittel 6 og CSL Eksempel UML modell basert på Vegnett Denne modellen er en eksempelmodell for å illustrere konsepter i kapittel 5.1, og må ikke forveksles med SOSI Vegnett modell. Eksmepelvis benyttes en rekke objekttyper uten egenskaper, som neppe tilfredsstiller kravene for å være egen objekttyper. Men dette gir ofte en enklere forståelse Pakker som i nngår Av presentasjonshensyn er modellen delt opp i to pakker, PunkterPåVeg og SelveVeglenken. Det er forbindelser mellom disse, som vises i hver av modellene. PunkterPåVeg SelveVeglenken Figur 5. Pakker som inngår i modellen Dette diagrammet angir hvilke delmodeller (Schema) som inngår i den komplette modellen. De stiplede pilene viser hvilke delmodeller som er avhengige av hvilke andre. Kommentarboksene (med brettet hjørne) angir mer spesifikt hvilke objekttyper som refereres, men disse kan igjen dra med seg andre underordnede typer Veglenkemod ellen med knytning til punkter Vegnode (from PunkterPåVeg) +startslutt 2 +vegnode +punktpåveg * 0..* PunktPåVeg (from PunkterPåVeg) +vegpunkt Veglenke + medium[0..1] : Vegmedium + kommunenr : Integer + dato : Date + vegstatus : Vegstatus + veglenkeid : Integer + Klassifikasjonsnøyaktighet : DQ_ThematicAccuracy Geometri +geometri + veggeometri : Kurvegeometri + posisjonsnøyaktighet : DQ_PositionalAccuracy KilometrertVeg + vegnummer : Integer + vpa : VPA + kjørefeltkode : String + veglenkedato : date + trafikkretning : Integer AnnenVeg Europaveg Riksveg Fylkesvei Skogbruksveg Gangveg Privatveg Kommunaveg Figur 6. Veglenke - del av vegnettsmodell

18 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Vegpunktmo dell med knytning til veglenker Posisjon + posisjon : Punktgeometri + Posisjonsnøyaktighet : DQ_PositionalAccura... Vegpunkt + medium : VegMedium + kommunenr : Knr + dato : Date + vegstatus : Vegstatus + vegnummer [0..1] ; Integer Kryss Vegnode + vpa : Vpa +vegnode startslutt +punktpåveg PunktPåVeg 0..* +vegpunkt 0..* VegUnderBane Endepunkt Tvangspunkt Ferjekai Vegbom Planovergang Kommunedele Veglenke (from SelveVeglenken) Figur 7. Punkt på veg - del av vegnettsmodell Kodelister og datatyper <<Kodelist>> KommuneNr Her uten verdier <<Codelist>> Vegstatus + framtidiganleggvedtatt + framtidiganleggikkevedtatt + eksisterendeveg + tidligereveg + vegmedmidlertidigstatus <<Codelist>> VegMedium + ibygning + iluft + påvannoverflaten + påsjøbunn/bakkenivå + underterreng <<DataType>> Vpa + hovedparsell : Integer + meterfra : Lengde + metertil : Lengde <<DataType>> Lengde + mlengde : Integer + enhet : ISOStandardUnits Figur 8. Kodelister og datatyper

19 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Praktiske regler for modellering 6.1 Introduksjon Hensikten med dette kapittel er å gi forslag til løsning på en rekke praktiske problemstillinger knyttet til modellering. Hvert kapittel beskriver et emne, gir en teoretisk beskrivelse, foreslår regler samt viser hvordan dette kan løses i UML. Kapitlet inneholder mange eksempler (figurer) fra modeller til eksisterende standarder. Disse er imidlertid ikke nødvendigvis komplette eller ajourførte i henhold til siste versjon, og må ikke betraktes som annet enn eksempler. 6.2 Hva en objekttype Med objektype mener vi en avbildning av et fenomen i den virkelige verden. Stort sett er det snakk om en avbildning av et stedfestet objekt, f.eks hus, vann, vei, etc). Objekttyper modelleres om klasser i UML. Men det er også mange andre konstruksjoner som modelleres som klasser, f.eks datatyper, kodelister etc., men disse er stereotyper som gir klassen spesiell mening (se 6.8.1). Hovedregelen er at alle klasser i modellen som ikke er 'stereotypet' er objekttyper. 6.3 Hovedstruktur Integrering av modeller Ved utvikling av en større informasjonsmodell er det fordelaktig å bryte dette ned i mindre komponenter. Eksempelvis er selve applikasjonsskjema en del, men andre standardiserte komponenter (modeller) er andre deler. Eksempler på andre komponenter er kvalitetsmodell, geometri/topologi modell, etc, etc. Figuren viser en modell kalt Plan (SOSI-plandatabeskrivelse). Denne benytter komponenter i SOSI_Geometri Profil, som inneholder geometriske primitiver som er nødvendig for å gi en geometrisk posisjon og/eller utstrekning til objekttypene i Plan. Disse geometritypene er beskrevet kun en gang, og integreres ved bruk av 'dependency' (avhengighet) i UML. (Stiplet pil) Det er også mulig å beskrive hvilke komponenter i de respektive pakkene som benyttes. Figur 6.2 viser at det er klassene Kurvegeometri, Punktgeometri og Flategeometri som benyttes. Dette betyr at disse 3 klassene er benyttet som datatype i Planpakka, og er nærmere definert i SOSI_Geometri profil pakka. Plan Plan Benytter KurveGeometri, Punktgeometri og Flategeometri SOSI_Geometri profil SOSI_Geometri profil Figur 9. Eksempel på integrering av modeller

20 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 20 Det er også mulig å anvende klasser i ISO Spatial Schema (geometri/topologi modellen) direkte, men det er en fordel å forholde seg til en nærmere definert profil av denne, ikke minst med tanke på implementasjon. Regler: Selve modellen skal modelleres i et applikasjonsskjema (informasjonsmodell) Dependency (Avhengighet) mekanismen i UML skal benyttes for å integrere andre skjemaer som er nødvendig for å lage en komplett modell. Dersom modellen også skal være grunnlag for datautveksling, må alle klasser i den komplette modellen være instansierbare. Klasser man normalt bruker slik som objekttyper, datatyper, kodelister og enumereringer er alle instansierbare. Dog finnes det stereotyper som gir en klasse helt spesiell mening, som <<Control>>, <<Boundary>>, <<Exception>>, <<Metaclass>> og <<Interface>>, og må brukes med forsiktighet. For eksempel er klasser stereotypet <<Interface>> ikke instansierbare, instanser av klasser stereotypet <<Metaclass>> er selv klasser og ingen av disse kan derfor brukes/integreres i et applikasjonsskjema. Se for mer om stereotyper. Hvilke komponenter i de integrerte skjemaene som skal benyttes kan angis, men det er ingen krav om dette. Dette er kun ut fra lesbarheten i form av menneskelig tolkning av den grafiske modellen. Det er ikke nødvendig med tanke på maksinlesbarheten Oppdeling av modeller På samme måte som en kan integrere flere skjema, kan en også dele opp en applikasjonsmodell i flere skjema. Hensikten med en slik oppdeling er å gjøre de respektive delmodellene enklere å lese (for mennesker). Det har ingen betydning for maskinlesbarheten. Utgangspunktet for en slik oppdeling er å lage fornuftige enheter som er oversiktlige og enklere å forholde seg til. Dette gjelder både under selve modelleringsfasen, samt med tanke på dokumentasjon. Oppdeling av modellen gjør ofte dokumentasjonen enklere. RikspolitiskeBestemmelserOg Retningslinjer Fylkes(del)Planer Kommune(del)Plan Byggeforbud Ekspropriasjon Refusjon EnkeltSaker IkkeJuridiskInformasjonOgIllustrasjoner Figur 10. Eksempel på oppdeling i pakker Figuren viser oppdeling av planmodellen i logiske enheter, UML pakker. Eksempler på slike pakker er Byggeforbud, ekspropriasjon, etc. Hver av disse inneholder underliggende klasser. I henhold til den grafiske notasjonen er alle pakkene likeverdige, dvs ingen av pakkene er overordnet eller underordnet andre. På den annen side står man fritt til å gruppere disse i henhold til en gjensidig

21 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 21 Utgangspunktet for en slik oppdeling er at hver pakke inneholder objektyper som har et nærmere forhold til hverandre (hører sammen). Men det er fullt mulig å referere fra en objekttype i en pakke til en objekttype i en annen pakke. Figur 7 viser et eksempel fra bygninger. Modellen for bygninger er delt inn i 4 pakker, Bygninger, BeskrivendeBygningslinjer, Takoverbygg og Bygningsvedheng. Figuren viser hvordan objekttypen BygningsEnhet i Bygninger forholder seg til objekttypen BeskrivendeBygningslinje i pakken BeskrivendeBygningslinjer samt objekttypen Bygningsvedheng i pakken Bygningsvedheng. <<Application Schema>> Bygninger <<Application Schema>> BeskrivendeBygningslinjer <<Application Schema>> Takoverbygg <<Application Schema>> Bygningsvedheng BygningsEnhet + geometri[0..1] : Flategeometri + geometrip[0..1] : Punktgeometri + by gningty peny e : By ggty p_nbr + medium[0..1] : Medium + kommunenummer : Komm + tiltakstatus[0..1] : TiltakStatus + by gningref eranse[0..1] : By gningref eranse + sekrforregfastekulturminner[0..4] : Sef rakforregfastekulturminner + bruksenhet[0..1] : Bruksenhet??????? + godkjent[0..1] : date + igangsatt[0..1] : Date + tattibruk[0..1] : Date + by gningsenhetensunikeid[0..1] : By gningsenhetensunikeid + bruksenhet[0..1] : Bruksenhet BeskrivendeBygningslinje +by gningslinje (from BeskrivendeBygningslinjer) + geometri : Kurv egeometri 0..* +v edheng 0..* Bygningsvedheng (from Bygningsvedheng) + geometri : Kurv egeometri Figur 11. Pakkediagram og eksempel på bruk av klasser definert i andre pakker Regler: Det er vanskelig å gi klare regler for inndeling i pakker. Dette må gjøres ut fra fagmiljøenes vurdering av hva som oppfattes som fornuftig, og ut fra behovet for dokumentasjon. 6.4 De enkelte komponenter i et applikasjonsskjema (informasjonsmodell) Objekttype r Objekttypene er selve grunnstenen i applikasjonsskjema. Disse modelleres som klasser. Fontene

22 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 22 Figur 12. Eksempel på en enkel objekttype definert som klasse Figuren viser objekttypen Fontene, uten egenskaper. Klasser i UML kan også representere egenskaper samt åpne og lukkede kodelister. Disse skal alltid 'stereotypes' spesielt (se kapittel om stereotyping). Alle andre er å anse som objekttyper Egenskape r Med egenskap menes her en navnet egenskap i en klasse som beskriver et verdidomene som instanser av denne kan ha.. En klasse kan ha ingen eller flere egenskaper, det er ingen begrensning på antallet. Figur 9 viser objekttypen Eiendomsteig, med egenskapene geometri, representasjonspunkt, kommune, eiendomskode, arealkode, grunnidentifikasjon, målebrevsnummer, dekareal og dekstatus. Geometri i form av flate eller punktgeometri er egenskaper på lik linje med andre egenskaper. Eiendomsteig + geometri : Flategeometri + representasjonspunkt : Punktgeometri + kommunenummer : Komm + eiendomskode : Ekode + arealkode : Arkode + grunnidentifikasjon : Grunnidentifikasjon + målebrevsnummer : CharacterString + dekareal : Integer + dekstatus : Dek_stat + hovedteig : Hovedteig + journalnummer : CharacterString Figur 13. Eksempel på en klasse med egenskaper Modellering a v basiselementer og gruppeelementer i SOSI En objekttype i SOSI kan ha egenskaper i form av basiselementer og gruppeelementer. Gruppeelementer inneholder flere basiselementer. Eksempel på et basiselement er kommunenummer i eksemplet over. Grunnidentifikasjon (GID) er et eksempel på et gruppeelement:.gid *..GNR H4..BNR H4..FNR H4 Gruppeelementer i henhold til SOSI kan modelleres som egne klasser (stereotypet datatype), med basiselementene som attributter. Eiendomsteig + representasjonspunkt : GM_Point + geometri : GM_CompositeSurface <<DataType>> + kommune : Kommune GID + eiendomskode : Eiendomskode + gårdsnr : Integer + arealkode : Arealkode + bruksnr : Integer + grunnidentifikasjon[1..*] : GID + FesteNr[0..1 : Integer + målebrevnummer : String + dekareal : DekAreal Statens kartverk, SOSI-sekretariatet + dekstatus : DekStatus

23 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 23 Figur 14. Eksempel på bruk av DataType I modellen har grunnidentifikasjon verdien GID som er en egen klasse stereotypet DataType. Denne klassen har egenskapene gårdsnummer, bruksnummer og festenummer. Alternativt kunne disse egenskapene legges direkte på eiendomsteig-klassen, men en mister da anledningen til å spesifisere multiplisitet overfor gruppen av egenskaper. UML gir mulighet til en mer detaljert spesifikasjon enn vi har gjort i SOSI i dag Syntaks Modelleres som attributter til klasser, og har følgende notasjon: <<stereotype>> [visibility] name [multiplicity] [:type] [= initial value] [{property-string}] Forklaring: <<stereotype>> [visibility] Name [multiplicity] [:type) [=iniatial value] {property string} Se kapittel om stereotyping Spesifiserer tilgjengelighet. Det er tre muligheter (public, protected og private). For modellering av geografiske objekter for en objektkjatalog er i utgangspunktet alle egenskaper tilgjengelige. Navnet på egenskapen Antall instanser av en egenskap, kan være alt fra opsjonell (valgfri) til mange. Se kapittel om multiplisitet. Dersom ingen verdi er gitt, er dette identisk med 1, dvs en instans av egenskapen pr klasse. Datatypen til objektet. Kan enten være 'basic' (f.eks Integer, characterstring) eller en egendefinert datatype modellert som en egen klasse. Default verdi dersom intet annet er oppgitt. (Brukes ofte i forbindelse med spesifikasjon av kodelister). NB - egenskapen kan ha en annen verdi enn defaultverdi, dette er ingen korrekt måte å tildele faste verdier på. Det er 3 definerte egenskaper som kan knyttes til egenskaper (changeable, addonly og fixed). For modellering av geografiske objekttyper i et applikasjonsskjema er det ikke behov for å benytte den fulle syntaksen for egenskaper. Det er tilstrekkelig å angi 'visibility' lik public(+), selve navnet på egenskapen (name), eventuelt multiplisitet (hvor mange instanser som kan forekomme), samt datatype. Eksempler: + gårdsnr : Integer // egenskapen er obligatorisk (grunnet manglende informasjon om multiplisitet + festenr[0..1] : Integer //multiplisitet 0..1 betyr at denne er opsjonell (trenger ikke forekomme), og kan forekomme maksimalt 1 gang Merknad: Hva med initialverdier for kodelister. Denne bør avklares. Hva med '/' for avledet. Hvor kommer dette inn i syntaksen? Forhold UML har fire ulike måter å angi forhold (reationships): Avhengighet (dependency) Assosiasjon (association) Generalisering (generalization) Realisering (realization)

24 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Avhengighet. Avhengighet er et semantisk forhold mellom to elementer, hvor en endring i det ene elementet (det avhengige), påvirker semantikken i det andre elementet (det uavhengige). Angis grafisk som en stiplet linje, kan ha en retning, og noen ganger en tekstforklaring. I eksemplet er innholdet i pakken Plan avhengig av innholdet i pakken SOSI_Geometri profil. Dersom f.eks spesifikasjonen av Kurvegeomeri i SOSI_Geometri pakken endres, vil dette medføre endring i den fullstendige modellen. Plan SOSI_Geometri profil Figur 15. Eksempel på angivelse av avhengighet Merknad Må ikke forveksle avhengighet med 'anker' notasjonen for merknader (noter). I den grafiske modellen ser disse like ut dersom en angir en avhengighet uten retning. I Rational Rose er det ikke mulig å benytte en avhengighet til å knytte sammen modellelementer dersom ikke en av disse er en note. Regler: Benyttes for å angi at et element er avhengig av et annet element, hovedsakelig for å angi avhengighet på pakkenivå, jfr Assosiasjone r En assosiasjon i UML er det semantiske forhold mellom to eller flere modell elementer, og brukes hovedsakelig for å ivareta sammenhenger mellom objekttyper. Assosiasjoner tillegges rollenavn for å forklare en klasses rolle i forhold til en annen klasse, og skal angis som substantiv. ISO CSL angir følgende: All associations shall have cardinalities defined for both association ends. At least one role name shall be defined. If only one role name is defined, the other will by default be inv_rolename. En assosiasjon er beskrevet som følger (CSL): An association is used to describe a relationship between two or more classes. In addition to an ordinary association, UML defines two special types of associations called aggregation and composition. The three types have different semantics. An ordinary association shall be used to represent a general relationship between two classes. The aggregation and composition associations shall be used to create part-whole relationships between two classes.

25 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Generell ass osiasjon (ordinary association) Objekttyper kan ha assosiasjoner til andre objekttyper. De angis med en strek mellom de to impliserte objekttypene. En assosiasjon kan ha et navn (verb) som skal stå midt på forbindelses-streken, men oftest er assosiasjonens "rolle-navn" viktigere. Objektets rolle mot andre objekttypen angir hva det betyr for det andre objektet gjennom denne assosiasjonen. En pil i den ene enden angir at navigering kun er mulig i pilas retning, i seksjon er navigering beskrevet nøyere. class1 r1 A r * class2 association-end association-end Figur 16. Assosiasjon Dette leses som: Class1 ser class2 gjennom rollen r2. Class 1 i assosiasjonen A ser class2 gjennom rollen r2. (Invers for r1) En generell assosiasjon benyttes mellom likestilte (organisatoriske) klasser Aggregering (svak aggregering) En åpen "diamant" angir en svak aggregering, hvor objekttypen på "diamant-siden" består av, og eksisterer i kraft av sine "medlemmer". Objekter kan således være medlemmer eller bestanddeler av flere slike helheter/åpne aggregeringer samtidig class1 B r3 1..* class3 Figur 17. Dette leses som: Class1 ser class3 gjennom rollen r3 Class1 i aggregatet B ser class3 gjennom rollen r3. Aggregering Aggregering er en spesiell form for assosiasjon og benyttes for å angi et strukturelt forhold mellom et 'hele' og de respektive 'deler'. Aggregering er i utgangspunktet et enkelt konsept. Det eneste som ligger i denne spesialiseringen fremfor en ordinær assosiasjon er å skille mellom 'hovedelementer' og deres 'delelementer', dvs hvem av klassene som organisasjonsmessig er overordnet. Bruk av aggregering fremfor en generell assosiasjon gir ingen endring i navigering i modellen. Eksemplet under viser en svak aggregering mellom EiendomsGrenseMedPunkt og Grensepunkt. EiendomsGrenseMedPunkt + følgerterrengdetalj : FølgerTerrengdet + administrativgrense : AdministrativGrense +punktigrense 0..2 GrensePunkt + geometri : Punktgeometri + grensepunktnummer : CharacterString + jordskifteverketpnr : CharacterString Figur 18. Eksempel på en svak aggregering mellom eiendomsgrense og grensepunkt

26 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Komposisjon (sterk aggregering) En fylt "diamant" angir at objekter av objekttypen på "diamant-siden" har, eller eier objekter av objekttypen på "strek-siden" som komponenter. De eide objektenes oppretting og eksistens følger eier-objektets eksistens. Dersom class1 slettes, vil også class4 slettes automatisk. class1 C r4 1..* class4 Figur 19. Dette leses som Class1 ser class4 gjennom rollen r4 Class1 i komposisjonen C ser class3 gjennom rollen r4. Komposisjon Figuren under viser et eksempel på en sterk aggregering mellom KpOmråde og KpPåskrift. KpPåskrift kan bare tilhøre KpOmråde. Dersom KpOmråde slettes, slettes også KpPåskrift. KpOmråde + flategeometri : Flategeometri + representasjonspunkt : Punktgeometri + tema[0..1] : Temakode = 1101 {fixed} + planidentifikasjon : CharacterString + plannavn : CharacterString + kpplantype : KpPlanType + planstatus : KpPlanStatus + ikrafttredelsedato : Date + planbestemmelse : KpPlanBestemmelser 1 +Påskrift 0..n KpPåskrift + geometri : Punktgeometri + tema[0..1] : Temakode = 1180 {fixed} + generelltekststreng : CharacterString Figur 20. Eksempel på en sterk aggregering /komposisjon Kardinalitet/m ultiplisitet Ved enden av assosiasjoner og aggregeringer, og etter egenskaper, kan en angi hvor mange instanser som er lovlige. Det kan benyttes en verdi, ett sett verdier skilt med komma, eller et intervall skilt med to prikker immellom. Asterix betyr mange. UML har følgende syntaks for å uttrykke kardinalitet/multiplisitet mot klasser. Forklaring Notasjon Obligatorisk, kun en instans 1 Klasse1 Opsjonell, kan ha mange instanser 0..* Klasse1 Opsjonell, men ikke mer enn 1 instans Klasse1 Obligatorisk, minst en instans 1..* Klasse1 Obligatorisk, et gitt antall instanser 1,3,7 Klasse1 Figur 21. Angivelse av ulike typer multiplisitet

27 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 27 Den samme notasjonen benyttes for å angi multiplisitet/kardinalitet for en egenskap i en klasse Regler knytte t til assosiasjoner Rollenavn angis i substantivs form og skal angis for alle assosiasjoner. Minst et rollenavn skal angis for hver assosiasjon (ISO CSL). Denne rollen bør ligge på 'mange' siden av assosiasjonen (0..*, 1..*) Rollenavn er unike innenfor den klassen disse står til. Hvis en har behov for like rollenavn er det mest sannsynlig noe feil med selve modellen. En rolle kan oppfattes som en egenskap til en klasse. I eksemplene over er f.eks. rollen r2 å oppfatte som en egenskap til klassen class1. Dersom det er flere assosiasjoner som 'står til' samme klasse, må rollenavnene være unike. Det bør tilstrebes å navngi assosiasjoner, ikke minst for å kunne dokumentere disse Retning på a ssosiasjoner Man kan angi retning på assosiasjonene, retningen på assosiasjonen beskriver det vi kaller navigering i UML. Navigering angir hvilken vei assosiasjonen er rettet, dvs. man angir hvilken klasse som kjenner til forholdet (assosiasjonen). Bruker +eier 1 1..* Passord Figur 22. Eksempel på assosiasjon med retning Eksempelet over viser at assosiasjonen mellom Bruker og Passord er rettet mot Passord. Man sier at Bruker vet om Passord men Passord kan ikke nå navigere til Bruker. I denne sammenheng er assosiasjone rettet fordi et system må gitt en bruker kunne finne brukerens passord, men gitt et passord ønsker man ikke å kunne finne brukeren som er assosiert med passordet. Vi bruker normalt ikke retning på assosiasjonene såfremt det er noe spesielt der vi spesifikt ønsker å angi navigering mellom objekttyper, jamfør eksempelet over Generaliserin g/spesialisering Generalisering og spesialisering angir et forhold hvor alle subtyper (barn) arver egenskaper, operasjoner og assosiasjoner av sine supertyper (foreldre). Generalisering angis med heltrukken strek med åpen trekant i enden Generalisering/spesialisering benyttes på to måter. 1. For å kunne beskrive ting på ulike nivåer. TrigonometriskPunkt + geometri : Punktgeometri + kommunenr : Komm + kommunenummer : Komm + fastmerkeidny : FastmerkeIdNy Fastmerke + kommunesekundær : Integer + fastmerkenavn[0..1] : CharacterString + punkttype[0..1] : Ptype + fastmerkesentrumref : Fmsref Statens kartverk, SOSI-sekretariatet

28 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 28 Figur 23. Eksempel på bruk av spesialisering for å angi ulik detaljeringsgrad. Figuren beskriver fastmerke som en spesialisering av et trigonometrisk punkt. For enkel bruk er det tilstrekkelig å benytte det generaliserte objektet Trigonometrisk punkt, mens det for mer spesialisert bruk kan være nødvendig å benytte objekttypen Fastmerke, som arver egenskapene til trigonometrisk punkt. 2. Modelleringsteknisk for å forenkle modeller, hvor spesialiseringen arver alle egenskaper og assosiasjoner fra supertypen. Figuren under gir et eksempel på en spesialisering av EiendomsgrenseMedPunkt i form av to subtyper (EiendomsGrense og EienhdomsGrenseOmtvistet). Supertypene arver egenskapene fra EiendomsgrenseMedPunkt (følgerterrengdetalj og administrativgrense). I tillegg har objekttypen EiendomsGrense en obligatorisk egenskap (jordskiftevertedid), som ikke er tillatt for EiendomsGrenseOmtvistet. Merknad: I eksemplet under kunne subtypene være kodet som en egenskap (f.eks type) til EiendomsGrenseMedPunkt, med to verdier (EiendomsGrense og EiendomsgrenseOmtvistet) i en kodeliste, dersom ikke EiendomsGrense hadde en obligatorisk egenskap (jordskifteverketid) som ikke skal forekomme på EiendomsGrenseOmtvistet. Klassen EiendomsGrenseMedPunkt er skrevet med kursiv. Det betyr at denne er abstrakt, og vil aldri finnes i form av instanser i et datasett. EiendomsGrenseMedPunkt + følgerterrengdetalj : FølgerTerrengdet + administrativgrense : AdministrativGrense EiendomsGrense + jordskifteverketid : Jordskifteverketid EiendomsGrenseOmtvistet Figur 24. Eksempel på modelleringsteknisk bruk av generalisering/spesialisering Regler Rolle/navn skal ikke angis. Kardinalitet skal ikke angis Brukes i utgangspunkt der det er behov for å angi en spesialisering, men hvor hver av de spesialiserte klassene har egne egenskaper eller spesielle krav til multiplisitet på egenskaper eller assosiasjoner Abstrakte supertyper (dvs objekttyper som ikke skal implementeres) skal angis med klassenavn i kursiv. (Jfr UML-syntaks beskrivelsen) Det er viktig å tenke generalisering/spesialisering i en objektkatalog, da denne skal være utgangspunkt for flere produkter av ulik detaljeringsgrad.

29 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Realisering En realisering beskriver et forhold mellom to modell elementer der det ene elementet spesifiserer en kontrakt/avtale som det andre elementet garanterer å utføre. Forholdet kan beskrives som en krysning mellom avhengighet og generalisering, og angis med stiplet linje med en stor åpen pil i den ene enden. Bruk av realisering mellom objekttyper er forekommer sjelden, men gjør man dette har en realisering følgende semantikk: Objekttypen på streksiden støtter/kan bruke minst alle operasjoner definert i objekttypen på pilsiden. Objekttypen på streksiden trenger nødvendigvis ikke å støtte/bruke egenskapene og assosiasjonene (strukturen) til objekttypen på pilsiden. Som oftest brukes realisering for å spesifisere forholdet mellom et interface og en klasse eller komponent. Et interface spesifiserer en slags kontrakt som et sett operasjoner der en klasse eller komponent via en realisering garanterer å oppfylle kontrakten. Man sier at klassen/komponenten realiserer/implementer et interface. For modellering av geografiske objekter bruker vi sjelden realisering og er en mekanisme vi skal være forsiktige med. Som nevnt kan den brukes mellom to objekttyper, men normalt vil man bruke realisering i sammenheng med bruk av interface er og kollaboreringer. Når vi modellerer geografiske objekter og rene informasjonsmodeller bruker vi ikke interface er, realisering forholdet brukes dermed sjeldent. Skal en derimot modellere tjenester og tradisjonelle datasystemer, eller tilrettelegge for automatisk implementasjon er interface er og realiseringer nyttige mekanismer Operasjone r Operasjoner er funksjoner som kan utføres på alle instanser av den klassen hvor tjenesten er spesifisert. Et eksempel på en slik operasjon er +hentpolygon(), som kan utføres for alle objekter som er uttrykt som en flate. Dette er jo en standard operasjon for alle GIS systemer, og det har ikke vært nødvendig å spesifisere slike enkle operasjoner. Et annet eksempel kan være hvorvidt det er mulig for en lastebil å kjøre over en bro, hvor dette kan utføres som en operasjon basert på akseltrykk og dato. Eksemplet under viser to operasjoner knyttet til objekttypen Eiendomsteig, Den første (hentpolygon) returnerer Flategeometri i henhold til geometrimodellen Den andre operasjonen sier om det er en tvisteteig eller ikke, og returnerer True eller False. Eiendomsteig + hentpolygon() : GM_Surface + ertvisteteig() : Boolean Figur 25. Eksempel på angivelse av operasjoner for en klasse (her objekttypen Eiendomsteig) Et annet eksempel kan gå ut på si om et navn ligger innenfor en nærmere angitt entitet. Under vurderes om et angitt navn ligger i Oslo ved helt av returverdien True/False. Navn + set(in name : Name, in place : String = 'Oslo') : Boolean Figur 26. Eksempel på angivelse av en operasjon med 'signatur'

30 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 30 Regler: Vi har lite erfaring knyttet til modellering av operasjoner, og vi bør foreløpig være forsiktige med å 'krydre' modellene med ulike operasjoner. Dette er selvsagt greit når en skal modellere et system for å håndtere datamodellen, slik som i matrikkelsammenheng. I andre sammenhenger skal data i henhold til modellene kunne overføres mellom ulike systemer, og operasjoner på data er i stor grad avhengig av funksjonaliteten til de systemene som dataene skal behandles i Syntaks <<stereotype>> [visibility] name [(parameter-list)] [:return-type] [{property-string}] [(parameter-list element)]::= [direction] name : type [=default-value] [direction]::= in out inout Med en operasjons signatur forstås navnet på operasjonen sammen med de nødvendige parameterene i 'parameter-list', inkludert 'return-type'. Forklaring: <<stereotype>> [visibility] name [parameter-list] [:return-type) {property string} Se kapittel om stereotyping Spesifiserer tilgjengelighet. Det er tre muligheter (public, protected og private). Name Navnet på egenskapen Navnet på operasjonen Alle parametere som benyttes for operasjoner, både 'in' og 'out' parametere, Den verdien som operasjonen resulterer i. Kan være basic type eller brukerdefinert type. Det er 4 definerte egenskaper knyttet til operasjoner (isquery, sequential, guarded og concurrent. Se UML for nærmere forklaring

31 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Datatyper: 'Basic' data typer (draft ISO/TS 19103) Datatyper er implementasjonsavhengige. Ved implementasjon av en modell vil datatypene måtte 'mappes' over til lovlige datatyper innenfor den aktuelle plattformen Eksempelvis vil en implementasjonsuavhengig CharacterString implementeres som en VARCHAR(2) i Oracle. I SOSI vil for eksempel lengden på en karakterstreng også inkludere spesialtegn (' eller "), dvs at for å kunne angi en tekststreng på 16 posisjoner må selve strenger defineres til 18 tegn. For XML, hvor det er andre spesialtegn og språk-tagger, vil lengden på en streng kunne være annerledes. ISO CSL beskriver CharacterString som følger: A CharacterString is an arbitrary-length sequence of characters including accents and special characters from repertoire of one of the adopted character sets. The maximum length of a CharacterString is dependent on encapsulation and usage. A language tag shall be provided for identification of the language of string values. På den annen side var det også påpekt behovet for et sted å kunne angi eksempelvis lengden på en tekststreng. SOSI-DB er et eksempel på at dette kan angis. For de modellene som er helt eller delvis basert på SOSI-standarden, vil denne type informasjon ligge i SOSI-DB. For modeller som ikke har sitt opphav i SOSI-DB trenger vi en SOSI-DB lignende applikasjon for å ta vare på informasjon som ikke ligger i selve UML-modellen (registry) Det presiseres at UML ikke tillater å spesifisere lengden på en datatype, eksempelvis lengden på en tekststreng eller antall siffer i en Integer. ISO beskriver følgende (under 6.14 Documentations of models): In addition to the diagrams, it is necessary to document the semantics of the model. The meaning of attributes, associations, operations and constraints needs shall be explained. Documentation fields should be used extensively. Regler Alle datatyper er beskrevet i ISO CSL kan benyttes. Imidlertid anbefales følgende datatyper: Integer A signed integer number, the length of an integer is encapsulation and usage dependent. Eksempel : 29, Real A signed real (floating point) number consisting of a mantissa and an exponent, the length of a real is encapsulation and usage dependent. Eksempel: , E-4, CharacterString A CharacterString is an arbitrary-length sequence of characters including accents and special characters from repertoire of one of the adopted character sets ISO/IEC , ISO/IEC Date A date gives values for year, month and day. Character encoding of a date is a string which shall follow the format for date specified by ISO Eksempel : eller Time A time is given by an hour, minute and second. Character encoding of a time is a string that follows the ISO 8601 format. Time zone according to UTC is optional. Eksempel; 18:30:59 or 18:30:59+01:00 DateTime A DateTime is a combination of a date and a time type. Character encoding of a DateTime shall follow ISO Boolean A value specifying TRUE or FALSE Enumeration An enumerated type declaration defines a list of valid identifiers of mnemonic words. Attributes of an enumerated type can only take values from this list. Vi vil neppe få mange eksempler på enumererte typer.

32 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 32 Codelist CodeList can be used to describe a more open enumeration. Dette vil bli den meste vanlige konstruksjonen. Vil benyttes for de fleste verdidomener bestemt i SOSI-standarden Brukerdefin erte datatyper. Dette er datatyper som modelleres av de som er ansvarlige for de ulike domenene (fagområdene). Eksempel på brukerdefinerte datatyper er gruppeelementer som består av flere basiselementer. Gruppeelementer modelleres som datatyper. Datatyper benyttes for å: Angi multiplisitet til en gruppe egenskaper Visualisere avgrensning Gjøre det lettere å bruke de samme egenskapene i ulike sammenhenger. Modellere ulike multiplisitet /avhengighet innenfor en rekke egenskaper Eksempel: Eiendomsteig + representasjonspunkt : GM_Point + geometri : GM_CompositeSurface + kommune : Kommune + eiendomskode : Eiendomskode + arealkode : Arealkode + grunnidentifikasjon[1..*] : GID + målebrevnummer : String + dekareal : DekAreal + dekstatus : DekStatus + temakode[1..3manuelt?] : TemaKode + hentpolygon() : GM_Surface + ertvisteteig() : Boolean <<DataType>> GID + gårdsnr : Integer + bruksnr : Integer + FesteNr[0..1 : Integer Figur 27. Eksempel på brukerdefinerte datatyper I eksempelet over er grunnidentifikasjon modellert som en av egenskapene til Eiendomsteig, med multiplisitet (1..*). Denne har datatype GID. GID er til høyre i eksemplet en egen klasse, stereotypet DataType. Denne har igjen 3 egenskaper, gårdsnr, bruksnr og festenr hvor for hver instans av grunnidentifikasjon, er da gårdsnummer og bruksnummer obligatorisk (påkrevet). Note: Det er usikkert hvordan Date, Time samt DateTime skal benyttes i forhold til datatyper spesifisert i ISO Temporal Schema. Skal f.eks. TM_Instance benyttes i stedet for Date. Foreløpig bruker vi Date, Time samt DateTime som 'basic data types'. UML-modellen vil ikke inneholde en presis spesifikasjon av en datatype, f.eks. at en tekststreng vil være 16 karakterer lang. Dette ligger i dokumentasjonen utenfor modellen. Eksempelvis SOSI-DB eller i dokumentasjonsfeltet i Rational Rose. Det har i flere diskusjoner vært presisert at eksempelvis lengde på tekststrenger, definisjoner i form av tekst og figurer, etc, vil ligge i et register (registry). Det nærmeste vi kommer er SOSI-DB. Denne skal utvikles i henhold til ISO Feature Catalogue Methodology, og vil kunne inneholde tilleggsinformasjon til UML-modellen Begrensnin g av verdidomene. I enkelte sammenhenger er det behov for å angi innskrenkninger i verdiområde for en egenskap. Det er også behov for å kunne angi at kun enkelte verdier i en kodeliste er tillatt.

33 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 33 En korrekt syntaktisk løsning er å lage flere kodelister, og subtype denne til en kodeliste som da arver alle verdiene, dvs det motsatte av 'subtyping' av de fullstendige kodelistene. Her bør vi imidlertid være varsomme, da dette strider mot en anbefaling i ISO 19103: ISO 19103: Multiple inheritance shall be used at a minimum, because it tends to increase model complexity. Eksempel på oppdeling av verdidomene for plantypekoder, hvor noen verdier er lovlige for fylkesplan, noen for reguleringsplan og noen for kommuneplan. Dersom en har behov for å angi alle disse verdiene samlet, lages en ny kodeliste som arver fra de tre andre. Dette er det som kalles multippel arv, og er ikke anbefalt da det ofte øker kompleksiteten i modellen. Imidlertid kan dette gjøres for lettere å se 'mappingen' mot SOSI, som har intensiv bruk av slike kodelister. <<Codelist>> RbPlantype + Reguleringsplan = 30 + Mindre vesentligendring = 31 + Bebyggelsesplan i henhold til reguleringsplan = 32 + Bebyggelsesplan i henhold til kommuneplanens arealdel = 33 <<Codelist>> FpPlantype + Fylkesdelplan = 11 + Samordnet areal- og tranpsortplan = 12 + Fylkesplan = 10 <<Codelist>> KpPlanType + Kommuneplanens arealdel = 20 + Kommuneplanens arealdel = 21 <<Codelist>> PlanType Figur 28. Eksempel på 'subtyping' av kodelister Alternativet til 'subtyping' er å angi begrensning i verdiområde i en Note. Sluse + geometri : Kurv egeometri + slusety pe : Slusety p For egenskapen slusety pe er kun v erdien 'senkedør' tillatt <<CodeList>> SluseType + Dør som åpnes + Senkedør Figur 29. Eksempel på innskrenkning av verdier ved bruk av note Figuren over viser objekttypen Sluse med egenskapen slusetype. SluseType er en kodeliste med to verdier(dør som åpnes og Senkedør). Gjennom en note knyttet til klassen sluse, er verdidomene begrenset til kun 'Senkedør'. For mange slike noter forvansker modellen, og gjør det umulig å ivareta ved automatisk bruk. Regler 'Subtyping' av kodelister bør så langt som mulig unngås. Lager kodelister som dekker de verdidområder en har bruk for. Dersom en også trenger å benytte koder fra flere kodelister, 'subtypes' disse jfr figur 23 Ved enkle verdibegrensinger kan dette også angis som en note i modellen, og må handteres manuelt i en implementasjon.

34 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Initialverdie r Med initialverdier i UML menes 'default'-verdier. Dvs. at dersom ikke noen verdi er oppgitt gjelder 'default'-verdien. Vi kan imidlertid overstyre dette gjennom å bruke 'property' lik {fixed}. På denne måten kan vi ivareta temakoder slik vi har i dag. Eksempel Elv + tema : Temakode = 1024 {fixed} Figur 30. Initialverdier Merknad: Det er viktig å merke seg at bruken av en slik egenskap ikke tilfører objekttypen noen ny informasjon. Det eneste en oppnår i eksemplet over er å si at objekttype Elv faktisk er en elv. Men for enkelte er dette viktig for å ivareta koblingen mot dagens SOSI Angivelse a v kodeverdier Representasjonen av en kodeliste skjer ved hjelp av verdi/kode(par) som egenskaper i en klasse, stereotypet kodeliste. Denne har et egenskapsnavn for hver verdi og koden representerer en initialverdi. I de tilfeller hvor bare egenskapsnavnet er vist, er kodene og deres beskrivelse identiske. NB. Verdier i kodelistene følger navnereglene, men med visse unntak. Egennavn endres ikke. Disse må få lov til å begynne med store bokstaver, og uten sammentrekning. Eksempelvis skal ikke Øvre Eiker endres til øvreeiker. <<CodeList>> MD_DimensionNameType + row + volumn + vertical + track <<CodeList>> SourceCodelist + orto500 = orto1000 = orto2000 = orto5000 = 603 Figur 31. Ulike metoder å modellere kodelister Figuren viser de to forskjellige måtene å angi kodelister på. 6.6 Bruk av klasser definert i andre skjema Geometri ISO spatial schema inneholder klasser som dekker geometriske og topologiske primitiver. I SOSI angir vi om en objekttype skal angis som Punkt, Sverm, Flate, Kurve, Linje, Bue, Buep, Sirkel og SirkelP. For å lage en enkel mapping mot SOSI er det laget to profil av ISO

35 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 35 De geometritypene vi skal forholde oss til i UML-modellene har posisjonsnøyaktighet som en egenskap. Vi forholder oss til 2 sett geoemtrityper. Enkle geometrityper hvor objekttypen 'eier' geometrien Geometrityper som kan dele geometri Geometritype r som ikke kan dele geometri. Angis som EnkelKurvegeometri, EnkelPunktgeometri, EnkelflateGeometri, EnkelvolumGeometri. Disse tillater ikke deling av geometri, dvs geometrien eies i sin helhet av objektet. ENKEL GEOMETRI Geometriprofil for geometri som er hel-eid av moder-objektet. D.v.s. slik som OpenGIS sin "Simple Feature (Geometry)" EnkelGeometri <<Type>> GM_Point (from Geometric primiti... + position : DirectP osition + boun da ry() + bearing () + GM _Point() <<Type>> GM_Curve (from Geometric primitive) + GM_Curve() << T ype>> GM_Surface (from Geometric primitive) + GM_Surface() + GM_Surface() <<Type>> GM_Solid (from Geometric primitive) + boundary() + area() + volume() + GM_Solid() EnkelPunktgeometri posisjonsnøyaktighet : DQ_PositionalAccuracy EnkelKurvegeometri posisjonsnøyaktighet : DQ_PositionalAccuracy interpolasjon [1..*] : GM_CurveInteroplation EnkelFlategeometri interpolasjon [1..*] : GM_SurfaceInterpolation EnkelVolumgeometri <<CodeList>> GM_CurveInterpolation (from Coordinate geometry) + l inea r + g eod esi c + circul ararc3po ints + circulararc2pointwithbulge + elliptical + clo thoid + con ic + polynomialspline + cubicspline + rati on al Sp line <<CodeList>> GM_SurfaceInterpolation (from Coordinate geometry) + none + planar + spherical + elliptical + conic + tin + parametriccurve + polynomialspline + rationalspline + triangulatedspline Figur 32. SOSI Enkel geometri Geometritype r som kan dele geometri Angis som Kurvegeometri, Punktgeometri, Flategeometri og Volumgeometri Interpolasjonsmetode som for enkel geometri. Interpolasjonsmetoden gir mulighet for ytterligere detaljering, slik som kurve, bue, etc. Disse geometritypene tillater deling av geometri, dvs geometrien deles av flere objekter

36 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 36 SOSI DELBAR GEOMETRI Geometri SOSI geometriprofil hvor alle primitiver ender i andre primitiver av lavere "orden". Såkalt "Shared Boundary" modell. <<Type>> GM_P oint (from Geometric primitive) + position : DirectPosition <<Type>> GM_CompositeCurve (from Geometric comple x) <<Type>> GM_CompositeSurface (from Geometric complex) <<Type>> GM_CompositeSolid (from Geometric comple x) + boundary() + bearing() + GM_Point() Punktgeometri posisjonsnøyaktighet : DQ_PositionalAccuracy Kurvegeometri posisjonsnøyaktighet : DQ_PositionalAccuracy interpolasjon [1..*] : GM_CurveInterpolation Flategeometri interpolasjon [1..*] : GM_SurfaceInterpolation Volumgeometri Figur 33. SOSI delbar geometri Eksempler på bruk av geometrityper. Pælebunt + geometri : Punktgeometri Figur 34. Eksempel på bruk av geometri som kan deles mellom objekttyper. Eksemplet viser angivelse av geometri for objekttypen Pælebunt., angitt som PunktGeometri. KpOmråde + flategeometri : Flategeometri + representasjonspunkt : Punktgeometri + tema[0..1] : Temakode = 1101 {fixed} + planidentifikasjon : CharacterString + plannavn : CharacterString + kpplantype : KpPlanType + planstatus : KpPlanStatus + ikrafttredelsedato : Date + planbestemmelse : KpPlanBestemmelser Figur 35. Eksempel på en objekttype med geometri som kan deles. Geometri håndteres som andre egenskaper, her som flategeometri og representasjonspunkt. Det er tillatt med flere geometrier på samme objekttype. Det bør angis et sted i modellen at det må være minst en geometritype knyttet til objektet. Regler Vi forholder oss til 2 sett geoemtrityper. Enkle geometrityper hvor objekttypen 'eier' geometrien Geometrityper som kan dele geometri. Geometriegenskapene bør så langt som mulig gies fornuftige navn (helst ikke bare 'geometri')

37 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 37 Bør bruke geometrityper som kan dele geometri dersom en ikke spesifikt ønsker at dette ikke skal være mulig Kvalitet for ge oemtritypene (stedfestingskvalitet). I SOSI-standarden står det beskrevet at alle geografiske objekter skal ha tilstrekkelig kvalitet. Dette er da tolket til at kvalitet (i form av målemetode og nøyaktighet) skal ligge på punkt og linjer. De geometritypene vi skal forholde oss til i UML-modellene har posisjonsnøyaktighet som en egenskap. Punktgeometri posisjonsnøyaktighet : DQ_PositionalAccuracy Figur 36. Angivelse av posisjonsnøyaktighet Eksemplet over viser hvordan en modellerer posisjonsnøyaktighet for et objekt med punktgeometri. Den fullstendige strukturen til DQ_PositionalAccuracy er ikke definert her Interpolasjon smetode I utgangspunktet bør ikke interpolasjonsmetode angis i UML-modellen. Dette er implementasjonsavhengig. SOSI-geometrimodellen har ikke grafiske elementer/objekter som gjenspeiler alle interpolasjonsmetodene i ISO eller avledede profiler. GML vil ha andre interpolasjonsmetoder, mens ISO/XML vil kunne forholde seg til alle. Det er da ikke korrekt å modellere med hensyn til SOSI-geometri eller annen geometri. På den annen siden, fra et praktisk synspunkt er det nyttig for brukerne å vite hva slags geometrityper som en kan regne med å støte på i en overføringsfil. Dessuten vil de ulike systemleverendørene ikke nødvendigvis implementere alle interpolasjonsmetodene. I enkelte systemer vil f.eks enkelte systemer kunne lese en bue eller sirkel ved at disse representeres som enkeltpunktet (langs buen/sirkelen) med kort avstand mellom punktene. Men disse vil ikke kunne gjøre dette om til f.eks en bue/sirkel ved eksport av data. I enkelte tilfeller er dette uheldig. Eksempelvis i DEK kan selve grensen være matematisk bestemt som bue med tilhørende egenskaper, og en ønsker å bevare dette ved dataoverføring. Merknad: Det er enighet om skrive om dette avsnittet. Vi må fokusere på å kunne gjenskape de geometritypene vi har i SOSI, samt de som det nå er mulig å bruke i GML 3.0. Ansvar: Kent Interpolasjonsmetode kan angis som en 'note' i selve modellen. Eksempel KpSamferdselLinje + tema : TypeSamferdsellinje + vertniv : Vertikalnivå + arealst : Arealstatus + viktig : Viktighet + geometri[1..*] : Kurvegeometri Skal benytte interpolasjonsmetode circulararc2pointwithbulge dersom grensen er angitt eller kan angis som bue + sjekkkorrektplanid()

38 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 38 Figur 37. Eksempel på angivelse av interpolasjonsmetode for kurvegeometri Kvalitet Det arbeides for tiden med å lage en kvalitetsmodell. Dette kapittel vil inneholde retningslinjer for hvordan en modellerer kvalitet inn på de respektive objekttypene i en produktspesifikasjon, samt hvordan dette kan dokumenteres for et datasett Andre skjem a Dette kapittel er ment å ha retningslinjer for bruk av klasser for å dekke det temporale aspektet, samt bruk av geografiske identifikatorer, dvs ikke koordinatbasert stedfesting. 6.7 Avledninger. For avledede data er det viktig å modellere at disse er avledet fra primærdata, både rent praktisk med tanke på datafangst og vedlikehold. Hvordan modellerer vi at en objekttype i N50 for eksempel er avledet fra en tilsvarende objekttype i primærdata. Er f.eks. objekttypen 'TrigonometriskPunkt' en avledning av SKGS's 'Fastmerke'?. Fastmerke (from Fastmerke) + tema[0..1] : Integer + kommune[0..1] : Kommune + sekundærkommune[0..4] : Sekundærkommune + idny[0..1] : FmIdNy + navn[0..1] : CharacterString + punkttype[0..1] : PunktType + sentrumreferanse : SentrumReferanse + høydereferanse[0..1] : fmhøydereferanse + type[0..1] : FmType + Status[0..1] : FmStatus + dato[0..1] : FmDato + signal[0..1] : FmSignal + merknad[0..1] : CharacterString + idgammel[0..1] : CharacterString + iddato[0..1] : Date + høydeoverbakken[0..1] : Real + referanseberegnet[0..1] + referanseberegnethøyde[0..1] + signalhøydereferanse[0..1] + adkomst[0..1] : CharacterString + punktbeskrivelse[0..1] : CharacterString + restriksjon[0..1] : CharacterString + link[0..1] : CharacterString + høydeovereuref89[0..1] Omfatter bare... TrigonometriskPunkt /+ høyde : Integer +fastmerketype /+ diverse : Diverse /+ geometri : EnkeltPunkt + get fastmerke() Figur 38. Eksempel på modellering av avledning Alternativt bør vi innføre generalisering, slik at modellen i utgangspunktet er egnet for ulike anvendelser med tanke på detaljeringsgrad. Figuren under viser hvordan dette kan løses ved generalisering/spesialisering

39 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 39 TrigonometriskPunkt + geometri : Punktgeometri + kommunenr : Komm + kommunenummer : Komm + fastmerkeidny : FastmerkeIdNy Fastmerke + kommunesekundær : Integer + fastmerkenavn[0..1] : CharacterString + punkttype[0..1] : Ptype + fastmerkesentrumref : Fmsref... Figur 39. Eksempel på bruk av aggregering og spesialisering som alternativ til avledning. Regler: Forsøker å ta hensyn til slik bruk på et tidlig stadium ved å innføre generalisering/spesialisering Forholdet mellom opprinnelig og avledet klasse (objekttype) angis med en enkel relasjon. (Relasjonen mellom Fastmerke og Trigonometrisk punkt) En note legges inn for tekstlig å beskrive selve avledningen. (Omfatter bare ) Multiplisitet angis. Ingen angivelse betyr 1. Attributter som avledes fra den opprinnelige klassen beskrives som avledet '/'. (Eks høyde, diverse, geometri). Selve operasjonen som henter egenskaper fra den opprinnelige klassen beskrives gjennom en enkel operasjon. (getfastmerke). 6.8 Utvidelser av UML UML er et standard modeleringsspråk. Ikke noe standard språk er rikt nok til å dekke alle nyanser som er nødvendig innenfor en rekke ulike modelleringsområder til enhver tid. Av denne grunn har UML spesifisert hvordan en kan lage utvidelser på en kontrollert måte. Disse utvidelsen omfatter: 'Stereotype' 'Tagged values' 'Constraint.' Dersom en kommer opp i en situasjon hvor en ikke klarer å uttrykke seg basert på generelle UMLelementer, må en se nærmere på utvidelsesmekanismene Stereotype r Dette er en utvidelsesmekanisme for eksisterende UML konsepter, som utvider vokabularet. Det er et modellelement som brukes for å spesialisere UML elementer slik at de behandles på en spesiell måte. Et eksempel på dette <<DataType>>, som forteller at en egenskap er modellert som en egen klasse med en eller flere attributter. Steretyper kan anvendes på en rekke UML-elementer. Men det er mest vanlig å benytte dette på klasser. En rekke stereotyper er definert i UML. Av disse er følgende spesifisert i ISO/TS CSL og følgelig anvendbare for geografisk informasjon: De mest van lige stereotypene:

40 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 40 <<Enumeration>> En liste med predefinerte verdier som ikke kan utvides. Eksempel på dette er Boolean som har 2 (eller 3) verdier, TRUE,FALSE (NULL). Andre eksempler er ukedager, måneder, etc. <<enumeration>> Boolean + TRUE : Code = 1 + FALSE : Code = 0 Figur 40. Eksempel på enumeration <<DataType>> En deskriptor for et sett verdier som ikke har egen identitet, og som eksisterer uavhengig av den klassen som benytter data typen. <<Data Type>> inkluderer primitive predefinerte typer og brukerdefinerte typer. Eiendomsteig + geometri : Flategeometri + kommunenummer : Komm + eiendomskode : Ekode + arealkode : Arkode + grunnidentifikasjon[0..1] : Grunnidentifikasjon... <<Datatype>> GrunnIdentifikasjon + gårdsnummer : Integer + bruksnummer : Integer + festenummer : Integer Figur 41. Eksempel på bruk av egendefinert datatype Figuren viser at en av egenskapene til klassen (objekttypen) Eiendomsteig heter grunnidentifkasjon. Denne er angitt som egen klasse, Grunnidentifikasjon, stereotypet <<Datatype). <<CodeList>> Beskriver en åpen enumerasjon. De fleste egenskapene i SOSI - standarden er kodelister. Dette fordi nye verdier kan tildeles. Det betyr ikke at brukeren selv kan definere nye verdier, men at en gjennom en registreringsautoritet kan tildele nye verdier. Kodelister benyttes oftest for å angi lengre lister av potensielle verdier. Verdier i en kodeliste angis ofte for brukeren, og er i sin natur mer mnemoniske. Ulike implementasjoner kan benytte ulike interne representasjoner for verdiene i kodelista, men da med oversettelsestabeller slik at de opprinnelige verdier kan gjenskapes. Det er i mange tilfeller ønskelig å benytte SOSI kodeverdiene også i en implementasjon, da dette ivaretaes i standarden (utvekslingsformatet). FpArealBruk (from Plan) + geometri : Flategeometri + ov ersiktplanareal [0..1] : OversiktPlanAreal + ov ersiktplanrestriksjoner [0..1] : Ov ersiktplanrestriksjoner + ov ersiktplanretningslinjer [0..1] : Ov ersiktplanretningslinjer + arealstatus [0..1] : ArealStatus... <<CodeList>> ArealStatus (from Plan) + Framtidig = 2 + Nåv ærende = 1 + Videreutv ikling av nåv ærende = 3

41 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 41 Figur 42. Eksempel på bruk av kodeliste Figuren viser at en av egenskapene i objekttypen (klassen) FpArealBruk heter arealstatus. Denne er modellert som en egen klasse, ArealStatus, stereotypet <<CodeList>. Denne kodelista består av 3 verdier, framtidig, nåværende og Videreutvikling av nåværende. Dersom en er helt sikker på at den ikke kan få flere verdier, burde denne være stereotypet som 'Enumeration'. Imidlertid kan en tenke seg verdier som 'kondemnert', 'ukjent', etc. Navnekonvensjoner benyttes ikke i kodelister. Her kan vi benytte både mellomrom og andre karakterer Andre stereo typer: Dette kapittel omhandler andre stereotyper definert i ISO Conceptual Schema Language som kan anvendes på i modellene. For modellering av geografiske objekter skal disse brukes med stor forsiktighet, dvs. at de er nødvendige kun ved spesielle behov og når man vet det innebærer. Skal en derimot modellere tjenester eller metamodeller, eller tilrettelegge for automatisk implementasjon, kan disse benyttes. <<Interface>> Spesifiserer en samling av operasjoner som er brukt for å spesifisere de tjenester som en klasse eller komponent bærer. (NB. Bør brukes med forsiktighet. Bør ikke brukes for klasser som skal instansieres. <<Type>> GM_Surface + GM_Surface(patch[1..*] : GM_SurfacePatch) : GM_Surface + GM_Surface(bdy : GM_SurfaceBoundary) : GM_Surface <<Interface>> GM_GenericSurface (from Coordinate geometry) surface Segmentation 1..n +patch <<Abstract>> GM_SurfacePatch Figur 43. Eksempel på angivelse av interface <<Type>>. Spesifiserer en abstrakt klasse som kun brukes til å spesifisere struktur og oppførsel til et sett objekter. Spesifiserer ikke implementasjon. <<Type>> GM_Primitive <<Type>> GM_Point + position : DirectPosition + boundary() : NULL + bearing(topoint : GM_Position) : Bearing + GM_Point(position : GM_Position) : GM_Point Figur 44. Eksempel på angivelse av <<Type>> Denne bør forklares. Har vi et bedre eksempel?????

42 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 42 <<Control>> Benyttes for en klasse hvis viktigste oppgave er å tilby en tjeneste uten å representere noen spesielle data. <<Entity>> En entititet spesifiser persistende informasjonsobjekter i en systemmodell. <<Boundary>> Benyttes for en klasse som representerer et eksternt grensesnitt for et system. <<Exception>> Spesifiserer en hendelse som er avvist av de underliggende prosesser. <<MetaClass>> Benyttes for å angi en klasse hvor alle instanser i klassen er egne klasser. Typisk brukt i spesifikasjonen av metamodeller, hvor en klasse har som primæroppgave å holde metadata om en annen klasse. Benyttes ikke for vanlige applikasjonsskjemaer. <<Leaf>> En pakke som inneholder definisjoner, uten sub-pakker. Dvs. laveste nivå. <<Leaf>> Geometric aggregates (from Geometry) <<Leaf>> Geometry root (from Geometry) Figur 45. Eksempel på bruk av <<Leaf>> Kent - Klarer vi å forklare denne. Har vi et bedre eksempel????? Tagged val ues Vi har foreløpig ingen erfaring med bruk av disse utvidelsesmekanismene. Bør brukes med forsiktighet, fortrinnsvis unngås Constraints (Beskrankninger) Vanligvis er en beskrankning beskrevet gjennom å beskrive denne i tilknytning til et element, samt å angi dette i parentes. Eksempel: {complete}. Vi har ingen erfaring knyttet til dette. BygningsEnhet +bygningsavgrensning 1..* Dersom by gningen har flategeometri Bygningsavgrensning + geometri : Kurv egeometri Figur 46. Eksempel på angivelse av avhengighet som note.

43 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 43 En annen måte å angi dette på er å plassere disse i en 'note', og angi dette som en beskrankning til den klassen eller assosiasjonen den er knyttet til. Figuren viser at Bygningsavgrensning kun er obligatorisk dersom bygningen skal angis med flategeometri. Dette er vist gjennom en stiplet linje som i mange tilfeller også har retning (angitt som en pil). Merknad: For at avhengigheter skal være maskinlesbart, må disse angis i henhold til en spesiell syntaks. Det er utviklet et eget språk, OCL (Object Constraint Language), nettopp for dette formål. Denne versjon av retningslinjene for datamodellering gir ingen retningslinjer for bruk av OCL. I de fleste eksemplene er slike avhengigheter bare angitt som ren tekst, dvs for at vi mennesker skal forstå modellen.

44 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Bruk av fa rger i UML modeller Det er ingen krav om at farger skal benyttes. Men dersom farger benyttes så henvises til eget dokument med angivelse av fargekoder.

45 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Dokumen tasjon. ISO beskriver følgende (under 6.14 Documentations of models): In addition to the diagrams, it is necessary to document the semantics of the model. The meaning of attributes, associations, operations and constraints needs shall be explained. Documentation fields should be used extensively. Regler Alle klasser, egenskaper og relasjoner skal defineres i dokumetasjonsfeltet (i datamodelleringsprogrammet). Dette ut fra at en slik dokumentasjon kan kjøres ut i en rapport. Annen informasjon kan angis ved behov. Spesielt er det viktig å angi en link til annen informasjon. Eksempel på slik annen informasjon er nærmere angivelse av lengden på datatyper (Eks T16), temakoder, etc.)

46 Retningslinjer for datamodellering i UML (Static Structure Diagram), version Anvendel se av UML modeller I forbindelse med selve standardiseringsarbeidet benyttes UML modeller i form av en grafisk notasjon. For videre bruk benyttes modellene for implementasjon, generering av XML skjema, etc. For å kunne utveksle modeller finnes det en egen standard, XMI. Ikke alle software produsenter støtter denne standarden, men det er flere initiativer på gang for å bedre dette. Blant annet har OMG (Object Management Group) ute et forslag til aktivitet knyttet til UML 2.0 'Diagram Interchange'. For å sikre at modellene kan overføres til XMI må dette taes hensyn til i modelleringssystemenes interne struktur. Dette er systemprorietært og må håndteres ulikt i de respektive systemer. Et eksempel på dette er multiplisitet som for Rational Rose legges inn som en del av egenskapsnavnet i Rational Rose. For å få med dette i XMI fila må dette også legges inn i Rational Rose's sitt interne format. Dette dokumentet tar ikke sikte på å gi noen detaljert rettledning i hvordan dette gjøres i ulike modelleringsverktøy, men anneks B gir noen eksempler på hvordan dette gjøres i Rational Rose.

47 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 47 Annex A Spesielle tilfeller(informativt) A.1 Introduksjon Dette kapittel inneholder forslag til løsning på en rekke generelle problemstillinger som ikke er utredet tilstrekkelig. Når vi har fått mer erfaring er intensjonen at dette skal løftes over til den normative delen av dokumentet. A.2 Spesielle situasjoner A.2.1 Modellering av avgrensningslinjer. Merknad: IKKE FERDIG Ved uttrekk av en sømløs database, vil alle objekter kunne avgrenses av fiktive linjer. Eksempelvis et hus vil kunne avgrenses av en fiktiv linje i tillegg til eksempelvis takkant. Dette er spesielt knyttet til den detaljerte modellering av produktene, ikke i utgangspunktet til objektkatalogen. Dette er også en generell problemstilling som ikke er knyttet til noe spesielt fagområde, men som vi bør ha en felles løsning rundt. I utgangspunktet bør denne løses på et så høyt nivå som mulig. Bygnan KartbladKant,Ruten ett, etc,etc. SOSI_Geometri profil SOSI_Konsepter Figur 47. Eksempel på angivelse av klasser definert i andre pakker Pakkediagrammet forteller at en benytter objekttypene Kartbladkant, Rutenett, etc,etc, fra pakken SOSI-konsepter, men sier ikke hvordan disse benyttes. Avgrensingslinjer som har egne egenskaper må modelleres som egne klasser. Men avgrensningslinjer (uten egenskaper) som bare er avgrensninger av flate, kan ligge som geometriegenskap direkte på objekttypen, eller modelleres som egne avgrensningslinjer. Alternativ 1: Alle flate/volumobjekter kan deles av generelle avgrensningslinjer. I alternativ 1 kjenner objektet til hva som avgrenser denne. Et eksempel er kystkonturens avgrensning som landareal tatt fram som et godt eksempel. Eksemplet under er basert på denne, men med tillegg av generellavgrensning tatt fra SOSI-konsepter.

48 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 48 Landareal - areal - omkrets + representasjonspunkt[0..1] : PunktGeometri + flate[0..1] : FlateGeometri AvgrensningGenerell 1..n (from SOSI konsepter) +generellavgrensnin + grense : KurveGeoemtri TemakartAvgrensning Lukkelinje Diskontinuitet KantUtsnitt AvgrensningGenerell + grense : KurveGeoemtri Rutenett DataAvgrensning KartbladKant IkkeKartlagtSjømåltGrense RutenettUTM RutenettOffentlig KartbladKantØk KartbladKantUTM Figur 48. Eksempel på angivelse av avgrensningslinje for et polygon Ulempen her er at alle objekttyper som har flategeometri da må ha en assosiasjon til denne klassen, dvs mer kompliserte modeller. I dette eksemplet kan landarealet avgrenses mot alle subtyper av AvgrensningGenerell, som er en abstrakt klasse. I utgangspunktet burde alle flate/volumobjekter være subtype av en metaklasse, f.eks. flate/volumobjekt, og relasjonen mot AvgrensningGenerell kunne henge på denne og dermed være generell for alle flate/volumobjekter. Men hvordan modellere dette???

49 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 49 Alternativ 2. I dette alternativet er denne informasjonen lagt på geometrien, dvs objekttypen vet ikke hva som avgrenser denne uten å spørre geometrien AnnetBygningsmessigAnlegg + tema[0..1] : Integer + punktgeometri[0..1] : Punktgeometri + flategeometri[0..1] : Flategeometri + kurvegeometri[0..1] : EnkelKurvegeometri Count (punktgeometri, flategeometri, kurvegeometri) > 0 <<Ty pe>> GM_Curve (from Geometric primitive) 1..n + GM_Curve() Aktualitet + normal + f iktiv + planlagt EnkelKurvegeometri posisjonsnøyaktighet : DQ_PositionalAccuracy interpolasjon [1..*] : GM_CurveInteroplation aktualitet[0..1] : Aktualitet Figur 49. Eksempel på angivelse av avgrensningslinje knyttet til geometrien I figuren over har klassen 'AnnetBygningsmessigAnlegg' tre geometrier; Punkt, Flate og Kurve. Dersom det er en fiktiv avgrensning angis denne gjennom egenskapen Aktualitet lik 'fiktiv' under EnkelKurveGeometri. Merknad: Denne er ikke ferdig diskutert. En avklaring her er essensielt for det videre arbeidet. A.2.2 Hvordan modellere når samme objekt går igjen i flere datasett Forslag 1: Modelleres ett sted, benyttes på tvers av fagområder. Tek niskeanleggsomdelavkystkonturen KonstruertKystlinje + høyde[0..1] : Real KaiKant Bølgebryter MoloKant SpuntveggKant TekniskeAnleggSomDelAvKystkonturen (from TekniskeAnleggKnyttetTilVannVassdragKyst) SlippKant PirKant Strømbryter Sluse BygningsmessigeAnlegg Figur 50. Eksempel på bruk av abstrakte klasser (kursiv)

50 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 50 I figuren over er det en relasjon mellom KonstruertKystlinje (Kyst og Sjø) og TekniskeAnleggSomDelAvKystkonturen (Bygningsmessige anlegg). Denne siste er en abstrakt 'subtype' av KaiKant, Bølgebryter, etc,etc; med andre ord, alle disse subtypene kan inngå i konstruert kystlinje. Slik er ikke data forvaltet i dag. Forslag 2 Modelleres inn som en egenskap til en objekttype Eiendomsgrense f ølgerterrengdetalj[0..1] : GrenseFølgerTerrengdetalj f ølgeradministrativ Grense[0..1] : GrenseFølgerAdministrativ Gr... <<CodeList>> GrenseFølgerTerrengdetalj havkontur = 4011/16 og 3001, 3003, 3009 innsjøkant = 4011/16 og 3101, 3102, 3104, 3107, 3109 elvebekkekant = 4011/16 og 3201, 3203, 3204, 3207, 3209, 3221 elvebekkemidt = 4011/16 og 3211 bygning = 5002 bygningsanlegg = 6500, 6501, 6601 steingjerde = 6011 annetgjerde = 6012 vegmidt = 7001 vegkant = 7002 stikjerrevegmidt = 7401, 7414 Figur 51. Eksempel på at dette er angitt som en egenskap til objekttypen Figuren over viser en eiendomsgrense som har en egenskap (følgerterrengdetalj) med datatype GrenseFølgerTerrengdetalj. Her kan en modellere inn at en eiendomsgrense følger innsjøkant, bygning, steingjerde, etc, men det er ingen relasjon mellom disse objektene. Dette er mer i overensstemmelse med dagens forvaltningsløsning. Forslag 3 Relasjonene modelleres inn i objekttypenavnet MarkslagGrense MarkslagGrenseSamferdsel MarkslagGrenseVann Figur 52. Eksempel på angivelse som en del av objekttypenavnet Eksemplet er hentet fra DMK, hvor markslagsgrenser som er sammenfallende med henholdsvis samferdsel og vann er modellert inn i objekttypenavnene MarkslagGrenseSamferdsel og MarkslagGrenseVann. Dette igjen har sitt utspring i multippel temakoding, hvor i utgangspunktet objkttypen er identifisert gjennom flere temakoder knyttet til samme objekttype. Regler: Gruppa har tidligere gått inn for at vi bør modellere inn relasjoner mellom objekttyper som ligger i ulike kapitler, samtidig som vi ikke skal beskrive hvordan dette implementeres i forvaltningssystemet. Konklusjonen fra forrige møte var at dette bør taes opp igjen på neste møte, da det er uklart hvor langt en skal gå. Her må vi selvsagt også være pragmatiske.

51 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 51 Annex B Modelleri ng i Rational Rose B.1 Introduksjon UML er en grafisk presentasjon. Dvs. at det er det som er i den grafiske modellen som vi forholder oss til, dvs er normativt. Flere systemleverendører har imidlertid mulighet for å legge inn informasjon i sin interne struktur, uten at det er noen grafisk visning av dette. B.2 Multiplisitet Eksempelvis legges kardinalitet inn som en del av egenskapsnavnet for Rational Rose, mens det for Visio handteres separat. Disse forskjellene er imidlertid viktige med tanke på å bruke disse modellene til å generere XMI. Her må en innenfor hvert enkelt system legge inn nødvendig informasjon slik at det er mulig å generere korrekt XMI. ElvBekk + elvetype[0..1] : Elvetype Figur 53. Angivelse av multiplisitet - grafisk notasjon I Rational Rose må kardinalitet legges inn som 'value' for multiplicity, eksempelvis som Dette vises desverre ikke i den grafiske modellen, hvor dette også må legges inn som en del av navnet. Figur 54. Class attribute specification for multiplicity in Rational Rose

52 Retningslinjer for datamodellering i UML (Static Structure Diagram), version 2 52 B.3 Initialverdier Det har lenge vært ønsket i SOSI arbeidsgruppene å angi SOSI koder med egenskaper i klasser 'stereotypet' som kodeliste. Eksempel: Figur 55. Kodeliste med verdier + kode I henhold til UML kan det legges inn en kode som en initialverdi, og ikke som faste verdier. Det finnes imidlertid en syntaks for å legge inn denne type informasjon, i form av en egenskap med initialverdi med 'property' lik {fixed}. Eksempel Elv + tema : Temakode = 1024 {fixed} Figur 56. Angivelse av faste initialverdier - grafisk notasjon I Rational Rose løses dette ved å sette rose2mof.ischangable to false, dvs at verdien ikke kan endres. Programmet som genererer XMI vil lese dette og generere korrekt XMI, men dette vil ikke kunne leses i den grafiske modellen. Figur 57. Class attribute specification for multiplicity in Rational Rose