Veileder i å lage informasjonsmodellen i en produktspesifikasjon som et utplukk av objekttyper fra fagområdene i SOSI del 2.

Transkript

1 Veileder i å lage informasjonsmodellen i en produktspesifikasjon som et utplukk av objekttyper fra fagområdene i SOSI del 2. Dokument: Veileder i å modellere produktspesifikasjon som utplukk fra SOSI fagområder på Versjon Kent Jonsrud IT - Teknologi og standarder Kartverket Veilederen forutsetter tilgang til UML-modelleringsverktøyet Enterprise Architect (EA), og tilgang til fagområdemodellene i SOSI del 2 i SOSI modellregisteret (subversion, SVN). Dette er beskrevet i en egen veileder for installering av nødvendig programmvare og lignende: Installasjon av nødvendig programvare for arbeid med SOSI produktspesifikasjoner på Se også for en liste med kjente problemer og løsninger ved bruk av Enterprise Architect og SVN. Veilederen beskriver ei enkel løype med etapper som sikrer at modellen blir i henhold til standarder. Etappene i løypa har en initiell rekkefølge, men det kan være behov for å gå tilbake på ulike steder og iterere flere ganger. Det kan også være en del innbyrdes avhengigheter som må tas hensyn til. Alle skjermutklipp er utført med EA versjon 9.1 så nyere versjoner kan ha noe avvikende utseende. EA versjon 10 kommer med egen støtte for GML, men denne er ikke komplett og må deaktiveres. Gå inn i menyen Settings\MDG Technologies og fjern avhakingen etter GML. I tillegg er tagged values eid av stereotypene i EA 10, så der må stereotype på nye egenskaper og roller ikke fjernes uten først å ha deaktivert MDG for SOSI. (Se deloppgave 13 trinn 3, 4 og 6.)

2 Oversikt og sjekkliste over deloppgavene Nr Deloppgave Status Generell forberedelse 1 Bestem klart hvilke objekttyper produktet skal innholde. 2 Etabler fullstendig oversikt og innsikt i alle relevante fagområder i SOSI del 2. 3 Bestem hvilke fellesegenskaper som skal benyttes fra SOSI_Objekt. Innsamling til EA 4 Last inn kopier av alle relevante SOSI del 2 fagområder fra SOSI modellregisteret. Valg av subsett 5 Lag en ny pakke for produktspesifikasjonen, stereotypet <<applicationschema>>. 6 Merk, og lag kopier av hver relevant fagområdepakke til applikasjonsskjemapakka. 7 Flytt alle ønskede objekttyper, datatyper og kodelister opp i den nye pakka. 8 Dra alle klassene inn i et klassediagram, eventuelt i egne diagram for kodelister. 9 Fjern unødvendige assosiasjoner, egenskaper og koder fra disse klassene. 10 Stram eventuelt inn på multiplisitetskravene på de resterende elementene. 11 Lag supertype som subsett av SOSI_Objekt og ta med ønskede fellesegenskaper. 12 Legg inn at alle objekttyper arver fellesegenskaper. Nye elementer 13 Legg inn nye objekttyper og egenskaper dersom disse ikke finnes i fagområdene. 14 Legg inn tagged values for SOSI_navn og SOSI_lengde o.l. hvis nødvendig Kobling tilbake til fagområde 15 Dokumenter i diagram hvor objekttypene er realisert ifra, og hva som er tatt med. 16 Dokumenter i diagram realisering av fellesegenskaper fra SOSI_Objekt. Sluttbehandling 17 Sjekk og re-etabler alle koblinger til korrekte datatyper. Lagring av modellen 18 Lagre den nye applikasjonsskjemapakka til et egnet register, eksempelvis i SOSI modellregisteret, SOSI del 3 - Standard produktspesifikasjoner. Dokumentere modellen 19 Generer tekstlig dokumentasjon inn i produktspesifikasjonsdokumentet. 20 Klipp alle aktuelle rapporter inn i produktspesifikasjonsdokumentet. Melde inn mangler i fagområdene 21 Meld inn til standardiseringssekretariatet behov om nye objekttyper som manglet i fagområdene, for oppdatering i SOSI del 2 - Generell objektaktalog. Generere SOSI-realisering og SOSI-kontroll parameterfiler 22 Kontroller at tagged values for alle SOSI_navn og SOSI_lengde er lagt inn. 23 Generer SOSI-Kontroll-definisjonsfiler. 24 Generer SOSI-syntaksbeskrivelse og klipp inn i produktspesifikasjonsdokumentet. Generere GML realisering 25 Legg inn nødvendige GML-skjema-metadata som tagged values på denne pakken. 26 Generer GML-skjema med ShapeChange plugin i Enterprise Architect. 27 Lag og valider eksempel på GML data som følger produktspesifikasjonen. 28 Legg inn GML skjema på angitt skjemalokalisering. 29 Legg inn URI og URL til GML skjema i produktspesifikasjonen.

3 Generell forberedelse 1 Bestem klart hvilke objekttyper produktet skal innholde. 2 Etabler fullstendig oversikt og innsikt i innholdet i alle fagområder i SOSI del 2 som er relevante for produktet. 3 Bestem hvilke fellesegenskaper som skal benyttes fra SOSI_Objekt. Innsamling til lokal modell i EA 4 Last inn siste versjon av kopier av alle relevante SOSI del 2 fagområder fra SOSI modellregisteret (subversion SVN). Det forutsettes her at Enterprise Architect har blitt konfigurert som beskrevet i dokumentet Installasjon av nødvendig programvare for arbeid med SOSI-produktspesifikasjoner. Før man begynner arbeidet med en UML-modell for en produktspesifikasjon må man oppdatere sine kopier av fagområdemodellene i SOSI del 2 slik at man har tilgang til de nyeste versjonene av alle objekttyper og kodelister. Man laster inn siste versjon fra SVN-serveren ved å høyreklikke på en pakke i Project Browseren. Så velger man Package Control og Get All Latest.

4 Valg av subsett 5 Lag en ny pakke med stereotype <<applicationschema>> for å lagre informasjonsmodellen i produktspesifikasjonen. UML-modeller for produktspesifikasjoner skal lagres under mappen SOSI Produktspesifikasjoner og der under de respektive partenes mapper. Se eksempel nedenfor. Dersom du starter arbeidet med en ny produktspesifikasjons-uml-modell skal du gå fram slik:

5 I. Sjekk ut aktuell pakke under SOSI Produktspesifikasjoner (se om Check out i installasjonsveiledningen). I tilfellet at det ikke finnes en pakke med navnet til din etat/ditt institutt ta kontakt med SOSI sekretariatet (se punkt 6.1 i installasjonsveiledningen). II. III. Legg til en ny pakke som skal inneholde UML-modellen til den nye produktspesifikasjonen. Det gjør du ved å høyreklikke på pakken som du har sjekket ut under I. Så velger du Add og Add Package. I den nå åpnede dialogboksen New Model package velger du et navn for produktspesifikasjonen pluss hovedversjonsnummer. (eks. Planomriss_4.8). Kryss av Add to Version Control. Det er opsjonelt å krysse av Automatically add new diagram. Du kan enten legge til et nytt diagram nå eller senere. Se punkt VII for en kort beskrivelse. IV. Klikk OK og dialogboksen Package Control Options åpnes. Her må opsjonene Control Package og For all packages, create placeholders for external references krysses av. Velg SOSI under Version Control. Nå må riktig sti velges der xml-filen skal lagres. Klikk på dette symbolet bak XMI

6 Filename. Nå havner du i arbeidsmappen som du anga under konfigurasjonen av SVN-tilgang. Gå til SOSI Del 3 og mappen med navnet til din etat/ditt institutt (her eksempelvis Skog og landskap ). Klikk Save og OK. V. Så kommer det to dialogbokser. På den første er det mest naturlig at du krysser av Keep checked out slik at du kan begynne å jobbe med UML-modellen. På den andre kan du skrive en kort kommentar i forbindelse med at en ny pakke har blitt lagt til. VI. Pakken som du har lagt til skal ha stereotype <<applicationschema>>. Høyreklikk på pakken, velg Properties og i den følgende dialogboksen applicationschema på Stereotype. Klikk så

7 OK. VII. Har du under punkt III ikke valgt at det skal gjøres automatisk, må du legge til et nytt diagram. Høyreklikk på pakken, så velger du Add og Add Diagram. I den følgende dialogboksen velger du et navn for diagrammet og Class under Diagram Types. Bekreft valget ved å klikke OK. Lag om nødvendig egne diagram for kodelister og for datatyper på samme måte. Diagrammer for dokumentasjon av realisering av objekttypene, og realisering av SOSI_Objekt kan også lages. VIII. Er arbeidet med UML-modellen (foreløpig) avsluttet husk å sende den oppdaterte modellen til serveren ved å sjekke inn pakken.

8 6 Merk, og lag kopier av hver relevant fagområdepakke til applikasjonsskjemapakka. Merk og kopier, og lim inn kopiene en etter en. Spesielt viktig å lage kopier av disse pakkene da disse kopiene får nye interne id-er i EA. Derved unngår man å forveksle med eksisterende fagområde-id-er.

9 Lim inn kopien i applikasjonsskjemapakka. Repeter å lage egne kopier for alle pakker med aktuelt innhold. 7 Flytt ønskede objekttyper, datatyper og kodelister opp i den nye applikasjonsskjemapakka. Dra og slipp alle aktuelle klasser fra kopien av sin opprinnelige fagområdepakke direkte inn i applikasjonsskjemapakka. Det resterende innholdet i kopiene av fagområdepakkene skal til slutt slettes, slik at en står igjen med kun modellelementer som er relevante for produktet. Dette bør gjøres først etter punkt 17.

10 8 Dra alle klassene ut i et klassediagram kalt Hovedmodell, eventuelt i egne diagram for kodelister og datatyper. Vis alle objekttypene ved å dra disse inn i valgte diagrammer, som Simple Link. Plasser objekttypene i diagrammene slik at det blir lett å få oversikt over helheten i modellen. Gjenta samme prosess for alle aktuelle datatyper og kodelister. 9 Fjern unødvendige assosiasjoner, egenskaper og koder fra disse klassene. Egenskaper og roller som er opsjonelle ([0..*]) kan fjernes fra klassene. Velg objekttype og så dens egenskaper, eller velg egenskapen direkte (velg kassen, og så klikk på egenskapen i diagrammet):

11 Velg Delete på alle de unødvendige og opsjonelle egenskapene etter tur.

12 10 Stram eventuelt inn på multiplisitetskravene på de resterende egenskapene som skal finnes og kunne være søkbare. I fagområdene er de fleste egenskapene opsjonelle, men i et produkt kan en bestemme seg for å ta med verdier for alle objekter slik at en kan søke på disse verdiene og stole på at de ikke er tomme. Da skal multiplisiteten på egenskapen endres fra [0..1] til [1..1]. (Påkrevede egenskaper viser ikke [1..1].)

13 11 Lag supertype(r) som subsett av SOSI_Objekt og ta med ønskede fellesegenskaper. Lag kopi av pakkene SOSI_Objekt og evt. Posisjonskvalitet i SOSI Generelle typer til klippebordet og lim disse kopiene inn i applikasjonsskjemapakka som tidligere nevnt i punkt 7. Lag så en eller flere kopier av objekttypen SOSI_Objekt i applikasjonsskjemapakka. Klipp ut klassen SOSI_Objekt og lim inn i applikasjonsskjemapakka med nye navn. Gi disse supertypene forståelige navn. (Eks. FellesegenskaperPlanomriss)

14 Fjern alle uønskede fellesegenskaper fra denne/disse på samme måte som i punkt 9, og stram inn opsjonaliteten på samme måte som i punkt 10. Flytt så alle aktuelle datatyper og kodelister fra pakka SOSI_Objekt og Posisjonskvalitet opp til applikasjonsskjemapakka. 12 Legg inn at alle objekttyper arver definerte fellesegenskaper. Velg verktøy for generalisering og trykk musepekeren ned på subtypen, dra over supertypen og slipp.

15 Objekttypene kan visualises med alle sine arvede egenskaper (sammen i objekttypeboksen). Merk objekttypen og velg Feature Visibility og hak så av Inherited Features - Show Attributes.

16 Objekttypene vises nå komplett med alle sine arvede egenskaper samlet.

17 Nye elementer 13 Legg inn nye nødvendige objekttyper og egenskaper dersom disse ikke finnes i fagområdene fra før. Følg beskrivelsene i SOSI del 1 Modelleringsregler, og i tilsvarende ISO standarder for applikasjonsskjema og for bruk av UML. Benytt for øvrig enklest mulig UML-element: class Enkle byggeklosser «featuretype» Komité + fastmøtedag :Ukedag + formål :CharacterString [1..3] + postboks :Adresse «datatype» Adresse + gate :CharacterString + husnummer :Integer + postnr :Integer + poststed :CharacterString «featuretype» Kjøretøy + merke :Produsent + passasjerer :Integer + start() :void +komité 0..* +medlem 2..* Organiserer> «featuretype» Person + bosted :Adresse + vekt :Real +eier 1..* Eier> +eiendel 0..* «featuretype» Bil «featuretype» Tog «enumeration» Ukedag NOTE: Må være oppført i et kjøretøyregister «codelist» Produsent mandag tirsdag onsdag torsdag fredag lørdag søndag +bilkomponent 3..* «featuretype» Hjul + bredde :Real + Fiat + Volkswagen + Lada + Skoda

18 Eksempel på innlegging av en helt ny egenskap som ikke finnes i fagområdet. Velg egenskaper, og velg New, og fyll ut merkede felt og velg til slutt Save. Endre så opsjonalitet (Detail) hvis nødvendig. Dersom produktet skal realiseres i SOSI-format bør en benytte verktøyet for SOSI plugin i EA. En har da støtte for å lage ferdige tagged values som det kun skal fylles inn valgte SOSI-navn i. En måte å lage de aller enkleste elementene på er beskrevet i følgende seks trinn.

19 Trinn 1 Velg nytt diagramverktøy av typen SOSI, du får da en ny verktøykasse tilgjengelig.

20 Trinn 2 Lag nye objekttyper og datatyper ved å dra fra verktøykassa inn i diagrammet. Fyll så ut den nye objekttypens navn og definisjon (i Notes-feltet).

21 Trinn 3 Lag nye egenskaper ved å dra fra verktøykassa og inn på en objekttype. Fyll inn egenskapsnavn og velg datatype. Klikk på objekttypen, dobbeltklikk på den merkede egenskapen. Skriv inn den nye egenskapens definisjon, og ta bort egenskapens stereotype (<<Attribute>>) hvis du har EA versjon 9. Trykk så på Save. Har du EA versjon 10 kan du vente til punkt 17, deaktivere MDG for SOSI først, og så trygt fjerne disse stereotypene. Trinn 4 Lag ny assosiasjon ved å dra ifra verktøykassa og inn mellom to objekttyper.

22 Dobbeltklikk på assosiasjonen, og ta bort assosiasjonens stereotype (<<sosirefassosiasjon>>) hvis du har EA 9, velg TargetRole og skriv inn den nye rollens navn og definisjon, og velg multiplisitet. Trykk så på OK. Har du EA versjon 10 kan du vente til punkt 17, deaktivere MDG for SOSI først, og så trygt fjerne disse stereotypene. Trinn 5 Lag nye kodelister ved å dra ifra verktøykassa. Skriv inn kodelistens navn og definisjon og trykk OK. Trinn 6 Lag nye kodeverdier ved å dra ifra verktøykassa og inn på ei kodeliste. Skriv inn kodes navn og sett type til blank. Trykk OK. Gjenta for alle resterende koder. Til slutt gjennomgås alle kodene, og stereotypen (<<sosikodelisteverdi>>) fjernes hvis du har EA 9, og definisjoner legges inn. (Samme måte som for nye egenskaper.) Har du EA versjon 10 kan du vente til punkt 17, deaktivere MDG for SOSI først, og så trygt fjerne disse stereotypene. I EA versjon 10 eies tagged values av stereotyper (der disse finnes), og når en fjerner slike stereotyper fjernes tilhørende tagged-values og alle inntastede verdier! En må derfor deaktivere MDG teknologi for SOSI før en fjerner disse plattformspesifikke SOSI-stereotypene. Husk å aktivere MDG for SOSI igjen etterpå. Modellene som hentes fra SOSI fagområder har ikke dette problemet. Dette problemet gjelder kun egenskaper, koder og roller som lages fra grunnen med verktøykassa i MDG for SOSI.

23 14 Legg inn tagged values for SOSI_navn og SOSI_lengde, og eventuelt andre SOSI- og GML-verdier hvis nødvendig. Sjekk eller legg inn nye korrekte verdier i tagged values for SOSI_navn og SOSI_lengde på alle gamle og nye modellelementer i flippen for Tagged Values nede til høyre. Dersom en ønsker at en assosiasjon skal realiseres i SOSI via nøkler så legges tagged value for fremmednøkkel inn med verdi som samme navn som valgt SOSI_navn på assosiert objekttype. Dersom en ønsker å angi at assosiasjonen er topologisk må en huske å stereotype assosiasjonen med <<topo>>. Dersom en ønsker begrensninger (f.eks avgrensning av verdidomene slik at kun enkelte koder i en kodeliste er tillatt), angi da dette som constraint i modellen, beskrevet i både klart språk og OCL.

24 Kobling tilbake til fagområde 15 Dokumenter i diagram hvor objekttypene er realisert ifra, og hva som er tatt med. Dra alle objekttypene som er realisert inn i diagrammet for realisering, dra så de objekttypene fra fagområdepakkene de er realisert ifra i SOSI del 2 inn rett over sin tilsvarende klasse (1.), og legg inn realiseringsforhold (fra verktøylinja (2.)). Dette vil dokumentere hvilke subsett som er tatt med, og hvilke innstramminger og tillegg som er utført.

25 16 Dokumenter i diagram realisering av fellesegenskaper fra SOSI_Objekt. En kan tilsvarede til punkt 15 kopiere inn alt innholdet i diagrammet SOSI_ObjektFull i SOSI del 2 til et eget realiseringsdiagram og vise hva som er og ikke er realisert av fellesegenskaper i subsettet.

26 Sluttbehandling 17 Sjekk og re-etabler alle koblinger til korrekte datatyper og roller. Sjekk at alle objekttyper og datatyper er kopiert inn i applikasjonsskjemapakka. Alle klasser som benyttes må finnes i denne pakka, med unntak av alle basistyper (Integer, Real, CharacterString, Date og DateTime) og geometrityper (Flate, Kurve, Punkt, Sverm). Merk at UML-datatyper som int og string ikke er akseptable, og unknown aksepteres kun i kodelister. Objektegenskapenes (eks. planbestemmelse) datatype (eks. KpPlanbestemmelse) skal kun peke til klasser i denne pakka. Hvis det pekes til forrige valgte klasse må man navigere til, og så dobbetklikke på korrekt klasse og velge Save. Hvis man ser at det pekes til en klasse i en annen pakke må man eventuelt først hente inn de manglende klassene, som beskrevet i punkt 6, og så fullføre prosessen. Dersom alle eksterne avhengigheter er løst opp skal man til slutt fjerne fra sin produktspesifikasjon alle de innkopierte pakkene som inneholder restene av ubrukte fagområdeobjekttyper og lignende. Dette bør gjøres for å unngå unødvendig støy ved generering av SOSI og GML realisering. Det er likevel lurt å lagre en lokal kopi av modellen før sletting, slik at dersom en seinere i arbeidet finner at en har uteglemt ting eller det er andre mangler, så kan en hoppe tilbake til denne lagrede modellen og iterere hele prosessen flere ganger intil alt er feilfritt.

27 Lagring av modellen 18 Lagre den nye applikasjonsskjemapakka til et egnet register, eksempelvis i SOSI modellregisteret under SOSI del 3 Standard produktspesifikasjoner. Det forutsettes her at du enten har fulgt konfigurasjonsanvisning i kapittel 5 slik at pakken allerede har blitt lagt til i SOSI modellregisteret på SVN-serveren, eller at du kan gjøre dette nå. Er arbeidet med UML-modellen (foreløpig) avsluttet husk å sende den oppdaterte modellen til serveren ved å sjekke inn pakken. Høyreklikk på applikasjonsskjemapakken, velg så Package Control og Check In. Se eksempel nedenfor for pakken Min produktspesifikasjon 3.5.

28 Husk å skrive en kort kommentar om hvilke endringene som har blitt gjort i Add Comment - dialogboksen.

29 Har applikasjonsskjemapakken blitt sjekket inn riktig vil det være nøkkelsymbolet pakkenavnet. foran Husk også å sjekke inn din etats/ditt institutts pakke på samme måten i tilfellet du har sjekket den ut tidligere. Dokumentere modellen 19 Generer tekstlig dokumentasjon via tilrettelagt rapportmal. Se installasjonsveiledningen for installasjon av SOSI dokumentasjonsmal i EA etc. Generer rtf-dokument ved å høyreklikke på applikasjonsskjemapakke og velge RTF rapport:

30 Velg fra lista template: SOSI dokumentasjonsmal i EA og angi filnavn for resultat, trykk så Generate.

31 20 Klipp alle aktuelle rapporter inn i produktspesifikasjonsdokumentet. Lim inn hele den genererte fila som informasjonsmodell under kapittel 5 i produktspesifikasjonen. a. Åpne wordmalen SOSI dokumentasjon fra RTF til DOC.dot som midlertidig dokument (med makroer). b. Gå til den automatisk genererte rtf-fila. c. Merk alt i den genererte rtf-fila og lim det inn i det midlertidige dokumentet. d. Åpne menyen View/Macros View Macros, velg og kjør Bytt_fra_header_til_overskrift e. Merk alt i den midlertidige fila og lim det inn i tomt kapittel 5 i produktspesifikasjonen. Rediger innholdet manuelt hvis ønskelig. Melde inn mangler i fagområdene 21 Meld inn til SOSI-sekretariatet behov om nye objekttyper som manglet i fagområdene, for oppdatering i SOSI generell objektaktalog. Dersom det ble behov for å legge inn nye objekttyper eller andre modellelementer i en eksisterende objekttype må det startes en etterprosess med å tilbakeføre disse inn i standarden for det generelle fagområdet i SOSI del 2. Behovene meldes til mailto:standardiseringssekretariatet@kartverket.no Generere SOSI-kontroll parameterfiler og SOSI-realisering 22 Kontroller at tagged values for alle SOSI_navn og SOSI_lengde er lagt inn. Gå gjennom alle modelelementer og sjekk at ingen av disse tagged values mangler korrekte verdier.

32 Merk at dette SOSI-tillegget kan inneholde mange flere, og til dels komplekse verdier. Merk også at i eksemplet over er datatypen DATO, som har en fast formatering (og skal være tom). 23 Generer SOSI-Kontroll-definisjonsfiler. Viktige taggedvalues som må være satt for applikasjonsskjemapakka er: Verdien av taggedvalue SOSI_kortnavn brukes bl.a. som filnavn ulike steder (eks Planomriss48). Verdien av taggedvalue SOSI_versjon skal angi hviken hovedversjon det bygges på (eks 4.5). Verdien av taggedvalue SOSI_modellstatus kan angi at modellen ikke er komplett (under arbeid). Høyreklikk på applikasjonsskjemapakka og velg Extensions/SOSI/definisjonsfiler for SOSI-Kontroll. Etter en tid vil det komme opp melding om at en katalog med definisjonsfiler er laget. Denne katalogen kan benyttes direkte til å teste mot reelle SOSI-formaterte data, og eventuelt gi muligheten til å gå tilbake og forbedre modelen hvis en oppdager mangler. For å få produktet inn i distribusjon av det offisielle settet med definisjonsfiler for SOSI-Kontroll må en lagre applikasjonsskjemapakka tilbake i SOSI modellregisteret, og melde ifra i epost merket SOSI-Kontroll til Kartverkets post@norgedigitalt.no om at filer skal kunne valideres mot produktet. 24 Generer SOSI-formatbeskrivelse og legg denne inn i produktspesifikasjonsdokumentet. Høyreklikk på applikasjonsskjemapakka og velg Extensions/SOSI/SOSI-formatreralisering. Etter en tid vil det komme opp melding om at et dokument er produsert.

33 Merk og kopier alt innhold i det produserte dokumentet, og lim det inn i produktspesifikasjonsdokumentet under kapittel/vedlegg for SOSI-formatrealisering. Generere GML realisering 25 Legg inn nødvendige GML-skjema-metadata som tagged values på denne pakken. Bestem navn på navnerom, versjonsnummer og skjemafil. Skriv disse inn som tagged values i EA. Verdien av taggedvalue targetnamespace skal inneholde navnet på navnerommet. Verdien av taggedvalue version skal inneholde detaljert versjonsinformasjon. Merk at dette detaljerte versjonsnummeret (eks ) kun vil ligge inne i skjemafila. Det bør likevel henge logisk tett sammen med hovedversjonsnavnet som er siste ledd i navneromsnavnet (/4.8/). Verdien av taggedvalue xmlns er lokal forkortelse for navnerom, og alle bør benytte app. Verdien av taggedvalue xsddocument skal inneholde filnavnet på skjemafila. Verdien av taggedvalue xsdencodingrule skal angi at standarden iso19136_2007 skal benyttes.

34 Navnet på navnerommet skal også benyttes som sti til skjemaplassering, så skjemaet skal ligge som: og eksternt forvaltede kodelister skal ligge tilgjengelig på samme sted, som for eksempel: Dersom eksternt forvaltede kodelister skal benyttes i GML så må disse kodelistene merkes spesielt i modellen, med taggedvalue asdictionary med verdien true. Stien til der den autorative kodelista ligger (codespace), må dokumenteres spesielt i produktspesifikasjonen, for å kunne brukes direkte i datafiler. Det er vanlig å angi full sti pluss kodelistenavnet, men ikke filtype (.xml). Eksempel på fragment fra ei GML-datafil: <kommunenummer codespace= " 0612</kommunenummer> 26 Generer GML-skjema med ShapeChange plugin i Enterprise Architect. Før GML-skjemaet genereres, anbefales det å kopiere applikasjonsskjemapakka til et nytt, tomt EAprosjekt. Hensikten med det er å redusere tiden ShapeChange bruker for å generere GML-skjema. Samtidig vil eventuelle feilmeldinger under genereringsprosessen kun gjelde

35 applikasjonsskjemapakka vi er interessert i og ikke eventuelle andre pakker som befinner seg i samme EA-prosjektet. For å kopiere pakka di, høyreklikk på applikasjonsskjemapakka, velg Copy Package to Clipboard, åpne så et nytt EA-prosjekt (File New Project). I det nye prosjektet høyreklikker du i Project Browser og velger Paste Package from Clipboard. Generer GML-skjema. Høyreklikk på applikasjonsskjemapakke, velg: Extensions/ShapeChange/Transform... Sørg for å hake av for generering av eksterne kodelister dersom slike finnes i modellen. Kontroller at pakkeinformasjonen er korrekt og trykk på Transform. Feilmeldinger vil bli dokumentert i verktøydokumentasjonen under generering. Etter generering kan loggen gjennomgåes for å finne evt. gjenværende feil i modellen. Loggen etter generering heter log.xml og kan finnes på katalogen der modellfila ligger.

36 GML-skjemafila legges på underkatalog \XSD og eksterne kodelister legges på underkatalog \CL. Verifiser at konfigureringen genererer ønsket geometrikompleksitet. (Delbar eller heleid geometri.) 27 Legg inn et valid eksempel på GML data i produktspesifikasjonen. Det anbefales at et eksempeldatasett lages og valideres mot skjemaet, og legges inn under kapittel GML-realisering, eller i eget vedlegg. Dataeksempler bør lages tidlig i prosessen da disse ofte kan initiere forbedringer i modellen. 28 Legg inn GML skjema på angitt skjemalokalisering. Send GML-skjemaet til mailto:standardiseringssekretariatet@kartverket.no for publisering. Skjemaplassering kan også benyttes til publisering av eksempeldata, disse skal da ligge slik: Kvalitetssikring av produktspesifikasjonen og GML-skjema/GML-data bør avtalefestes. Dette kan avtales med Kartverket ved epost til post@norgedigitalt.no merket SOSI-produktspesifikasjon. 29 Legg inn http-uri og URL til GML skjema i produktspesifikasjonen. URI: URL: