Veileder i å modellere en SOSI 5.0 produktspesifikasjon som utplukk fra SOSI 4.0 og 4.5 fagområder.

Transkript

1 Veileder i å modellere en SOSI 5.0 produktspesifikasjon som utplukk fra SOSI 4.0 og 4.5 fagområder. Dokument: " Veileder i å modellere SOSI 5.0 produktspesifikasjon som utplukk fra SOSI 4.0 fagområder" Versjon 2.0.0alfa Kent Jonsrud IT - Standarder og teknologisk utvikling Kartverket Veilederen forutsetter tilgang til UML-modelleringsverktøyet Enterprise Architect (EA) versjon 12 eller nyere, 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 programvare og lignende: på " Installasjon av nødvendig programvare for arbeid med SOSI produktspesifikasjoner" Veilederen beskriver ei enkel løype med 29 etapper som sikrer at modellen blir i henhold til standard. 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 12.1 og prosjektbrowser til høyre, andre versjoner av EA kan ha noe avvikende utseende. EA kommer med egen støtte for GML, men denne er ikke komplett og må deaktiveres. Gå inn i menyen "Settings\MDG Technologies " og påse at avhakingen etter "GML" er fjernet. Eller gå inn i menyen "Settings\MDG Technologies " og ta av alle avhakingene unntatt de tre første. I tillegg er "tagged values" ofte 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.) 1

2 Oversikt og sjekkliste over deloppgavene Nr Deloppgave Status Side Generell forberedelse 1 Bestem klart hvilke objekttyper produktet skal inneholde. 2 Etabler fullstendig oversikt og innsikt i alle relevante fagområder i SOSI del 2. 3 Bestem hvilke fellesegenskaper som skal benyttes fra SOSI generell del. 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 de ikke finnes i fagområdene. 14 Fjern «topo»-assosiasjoner og lag tilsvarende restriksjoner. Lag lovlige navn på koder. Legg inn plattformuavhengige tagged values. Kobling tilbake til fagområde 15 Dokumenter i diagram hvordan objekttypene er realisert, og hva som er nytt. 16 Dokumenter i diagram realisering av fellesegenskaper fra SOSI_Objekt. Sluttbehandling 17 Sjekk og re-etabler alle koblinger til korrekt datatype. Kjør modellvalidering. Lagring av modellen 18 Lagre den nye applikasjonsskjemapakka til et egnet register, som i SOSI-modellregisteret under SOSI-produktspesifikasjoner. Dokumentere modellen 19 Generer tekstlig dokumentasjon og legg inn i produktspesifikasjonsdokumentet. 20 Klipp andre aktuelle rapporter inn i produktspesifikasjonsdokumentet. Melde inn mangler i fagområdene 21 Meld inn til standardiseringssekretariatet behov om elementer som manglet i fagområdene, for oppdatering av fagområdestandardene i SOSI del 2. Generere SOSI-realisering og SOSI-kontroll parameterfiler 22 Legg inn nødvendig innhold i tagged values for SOSI_navn og SOSI_lengde. 23 Generer SOSI-Kontroll-definisjonsfiler. 24 Generer SOSI-syntaks og klipp den inn i produktspesifikasjonsdokumentet. Generere GML realisering 25 Legg inn nødvendige GML-skjema-metadata som tagged values på pakka. 26 Generer GML-applikasjonsskjema med ShapeChange i Enterprise Architect. 27 Lag og valider eksempel på GML-datasett som følger produktspesifikasjonen. 28 Legg inn GML-applikasjonsskjema på angitt skjemaplassering. 29 Legg inn URI og URL til GML-applikasjonsskjema i produktspesifikasjonen. 2

3 Generell forberedelse 1 Bestem klart hvilke formål produktet skal dekke, og hvilke objekttyper produktet derfor skal inneholde. Lag gjerne en beskrivelse av hvilke brukstilfeller produktet skal tilfredsstille. En vil da være i stand til å teste produktet og avgjøre om produktet oppfyller formålene. 2 Etabler fullstendig oversikt og innsikt i innholdet i alle fagområder i SOSI del 2 som er relevante for produktet, og de føringer som Geodataloven gir gjennom Inspire-modellene. Søk med fritekstsøk på relevante termer mot SOSI-modellregister gjennom webinnsyn i GeoNorgeportalen og se på relevante internasjonalt harmoniserte spesifikasjoner i 3 Bestem hvilke generelle fellesegenskaper som skal benyttes. Fagområdene inneholder ikke slike fellesegenskaper så disse må tas fra SOSI generelle konsepter. Innsamling til lokal prosjektmodell 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. 3

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: 4

5 I. Sjekk ut aktuell pakke under "SOSI Produktspesifikasjoner" (les om Check out i installasjonsveiledningen). I tilfellet at det ikke finnes en pakke med navnet på din etat/ditt institutt ta kontakt med Kartverket (mailto:standardiseringssekretariatet@kartverket.no). 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. Havnetrafikk-5.0). 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. 5

6 Nå må riktig sti velges der xml-filen skal lagres. Klikk på dette symbolet bak XMI 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 "Statens kartverk"). 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. 6

7 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å OK. VII. Har du under punkt III ikke valgt at det skal gjøres automatisk, må du nå 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". Det er anbefalt å navne slik: "Hoveddiagram Havnetrafikk". Bekreft valget ved å klikke OK. Lag om nødvendig egne diagram for kodelister og for datatyper på samme måte. Egne diagrammer for dokumentasjon av realisering av objekttypene, og for realisering av SOSI_Fellesegenskaper og SOSI_Objekt kan også lages. 7

8 VIII. Er arbeidet med UML-modellen (foreløpig) avsluttet så husk å lagre den oppdaterte modellen tilbake til serveren ved å sjekke inn pakken. Høyreklikk på pakken og velg Package control/check in, og beskriv kort dine siste endringer. 6 Merk, og lag kopier av hver relevant fagområdepakke til din egen applikasjonsskjemapakke. Merk og kopier, og lim inn kopiene en etter en. Det er spesielt viktig å lage kopier av disse pakkene da disse kopiene får nye interne id-er i EA. Derved unngår man å forveksle id-er i egen pakke med eksisterende fagområde-id-er. 8

9 9

10 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 eller underpakker du trenger fra kopien av sin opprinnelige fagområdepakke direkte inn i applikasjonsskjemapakka. 10

11 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. Sletting bør gjøres først etter punkt Dra alle klassene ut i et klassediagram kalt Hoveddiagram Nnn, eventuelt i egne diagram for kodelister og datatyper. Vis alle objekttypene ved å dra disse inn i valgte diagrammer, som "Simpel 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 assosiasjonsroller, egenskaper og koder fra de valgte klassene. Egenskaper og roller som er opsjonelle ([0..1] og [0..*]) og er uønsket i produktet kan fjernes fra klassene. Koder som ikke er relevante i produktet kan også fjernes. Velg klassen og så dens egenskaper, eller velg egenskapen direkte (velg kassen, og så dobbeltklikk på egenskapen i diagrammet): 11

12 12

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

14 10 Stram eventuelt inn på multiplisitetskravene på de resterende egenskapene som alltid skal finnes og kunne være søkbare. I fagområdene er de fleste egenskapene opsjonelle, men i et produkt bør en bestemme seg for å kreve verdier på egenskapen for alle objekter, slik at en bruker kan søke på disse verdiene og stole på at de ikke er tomme. Da skal multiplisiteten på egenskapen endres fra [0..1] til eksakt antall [1..1]. (Påkrevede egenskaper vises uten [1..1], mens påkrevde roller vises med 1 eller 1..*.) 14

15 11 Lag supertype(r) som subsett av SOSI_Fellesegenskaper eller SOSI_Objekt, og ta med påkrevde og ønskede fellesegenskaper. Lag kopi av pakka SOSI_Fellesegenskaper i SOSI 5.0 Generelle typer til klippebordet og lim kopien inn i applikasjonsskjemapakka på samme måte som tidligere nevnt i punkt 7. Lag så en eller flere kopier av objekttypene SOSI_Fellesegenskaper og SOSI_Objekt med nye forståelige navn i applikasjonsskjemapakka. (Eks. Fellesegenskaper og FellesegenskaperKurver.) 15

16 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 klasser, datatyper og kodelister fra kopien av pakka SOSI-Fellesegenskaper opp til egen applikasjonsskjemapakke. 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. 16

17 17

18 Nye elementer 13 Legg inn nye nødvendige objekttyper, assosiasjoner og egenskaper som ikke finnes i fagområdene fra før. Følg beskrivelsene i SOSI del 1 Modelleringsregler versjon 5.0, og i tilsvarende ISO standarder for applikasjonsskjema og for bruk av UML. Benytt enklest mulig UML-modellelement til å beskrive det du har behov for. Her vises et lite sett av UML-modellelementer som det anbefales å benytte : 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

19 Nye modellelementer kan lages ved bruk av en standard UML-profil og ved bruk av ulike skript for innlegging av tagged values. Nye applikasjonsskjemapakker med korrekt stereotype ved å velge verktøy fra SOSI-UML-profil-5.0. sd. Alle modellelementer skal ha en forståelig definisjon, også applikasjonsskjemapakker. sd. Eksempel på innlegging av en helt ny egenskap som ikke finnes fra før til en eksisterende objekttype 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 enkleste elementene på er beskrevet i følgende seks trinn. 19

20 Trinn 1 Velg nytt diagramverktøy av typen SOSI-UML-profil 5.0, du får da en ny verktøykasse tilgjengelig. 20

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

22 Trinn 3 Lag nye egenskaper ved å velge Attributes og legge inn navn, datatype og at egenskaper er synlig (Public). å 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 å velge fra Class Relationships i standard verktøykassa og dra denne fra en objekttype til en annen. 22

23 Dobbeltklikk på assosiasjonen, og ta bort assosiasjonens stereotype (<<sosirefassosiasjon>>) hvis du har EA 9, velg SourceRole eller TargetRole (der endeklassen er den korrekte) og og skriv inn den nye rollens navn og definisjon, sett navigerbarhetspil 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 SOSI-UML-profil-5.0. Skriv inn kodelistens navn og definisjon og trykk OK. Trinn 6 Lag nye kodeverdier ved å klikke på kodelisteklassen og velge Attributes... dra ifra verktøykassa og inn på ei kodeliste. Skriv inn kodes navn og sett type til blank. Trykk OK. 23

24 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 noen vertøy eies tagged values av stereotypen (der disse finnes), og når en endrer eller fjerner slike stereotyper så fjernes tilhørende tagged values og alle inntastede verdier blir borte! En må derfor huske å deaktivere slike verktøy (som "MDG teknologi for SOSI") før en fjerner eller endrer på stereotyper. Husk å aktivere MDG for SOSI igjen etterpå. Dette gjelder særlig produktspesifikasjoner der nye egenskaper, koder og roller er laget fra grunnen med den gamle verktøykassa "SOSI" i "MDG for SOSI". Alle modellene som hentes fra SOSI fagområder har unnveket dette problemet. 24

25 14 Fjern «topo»-assosiasjoner. Lag lovlige navn på koder. Legg inn plattformuavhengige tagged values. De spesielle nasjonale assosiasjonene merket med stereotypen «topo» er ikke videreført i SOSI 5.0. Disse skal derfor fjernes og tilsvarende informasjon overføres til restriksjoner. Dette gjøres helautomatisk ved å høyreklikke på applikasjonsskjemapakka og velge Scripts/endreTopoAssosiasjonTilRestriksjon og trykke Ok(?). tbd. Dersom en ønsker å beskrive ytterligere begrensninger i bruk av modellen angis da dette som en eller flere restriksjoner med selvforklarende navn, og beskrevet i både klart språk og i Object constraint language (OCL). tbd. Mange kodelister hadde tidligere meningsløse tallkoder som initialverdi. Disse initialverdiene kan nå flyttes til en tagged value "SOSI_verdi". Dette gjøres helautomatisk ved å høyreklikke på ei og ei kodeliste, og velge Scripts/flyttInitialverdiPåKodelistekoderTilSOSITag. og trykke Ok(?). tbd. Kodelister må følge samme navneregler som for andre modellelementer. De gamle navnene kan nå flyttes til en tagged value "SOSI_presentasjonsnavn" og navnet gjøres om automatisk. Dersom kodene er egennavn kan blanke erstattes disse med "_" helautomatisk ved å høyreklikke på ei og ei kodeliste, og velge Scripts/lagLovligeEgennavnPåKodelistekoder. og trykke Ok(?). tbd. Dersom kodene er vanlige typenavn kan en lage NCName helautomatisk ved å høyreklikke på ei og ei kodeliste, og velge Scripts/lagLovligeNCNavnPåKodelistekoder. og trykke Ok(?). tbd. 25

26 Kobling tilbake til fagområde 15 Dokumenter i diagram hvor objekttypene er realisert ifra, og hva som er tatt med. Finn den opprinnelige fagområdestandarden i prosjektbrowseren. Dra alle objekttypene som er realisert inn som linker 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 hvilket subsett som er tatt med, og hvilke innstramminger og tillegg som er utført slik at innholdet i fagområdestandardene kan forbedres. 26

27 16 Dokumenter i eget diagram realiseringen av fellesegenskaper fra SOSI_Fellesegenskaper og SOSI_Objekt. En kan tilsvarede til punkt 15 kopiere inn linker til i SOSI del 1 til et eget realiseringsdiagram og vise hva som er og ikke er realisert av fellesegenskaper i subsettet. 27

28 Sluttbehandling 17 Re-etabler alle koblinger til korrekte datatyper og roller. Sjekk at alle objekttyper og datatyper er kopiert inn i applikasjonsskjemapakka. Alle klasser som benyttes skal finnes i denne pakka, med unntak av basistyper (Integer, Real, Boolean, CharacterString, Date og DateTime, LanguageString, URI, Vector, Record,...) og geometrityper (Flate, Kurve, Punkt, Sverm samt alle lovlige iso-geometrityper som GM_Point, GM_Curve, GM_Surface, GM_Solid og deres GM_Multi- og GM_Composite- varianter). Merk at UML-datatyper som int og string ikke er akseptable, og at "unknown" aksepteres kun i kodelister. Oppkobling til datatyper innenfor egen pakke der egenskapens datatypenavn tilsvarer en datatypeklasse innenfor pakka kan utføres helautomatisk ved å høyreklikke på pakka og velge Scripts/kobleOppDatatyperFraSammeApplikasjonsskjema. og trykke Ok(?). tbd. Kontroll av at alle egenskaper er oppkoblet kan utføres helautomatisk ved å høyreklikke på pakka og velge Scripts/listDatatyperUtenOppkobling. tbd. Objektegenskapenes (eks. planbestemmelse) datatype (eks. KpPlanbestemmelse) skal kun peke til klasser i denne pakka. Identifisering av datatyper utenfor egen pakke kan utføres helautomatisk ved å høyreklikke på pakka og velge Scripts/listElementerOppkobletUtenforApplikasjonsskjema. tbd??? Egenskapens datatype vises i feltet Type. (1) men det er mulig at dette kun er en tekststreng og ikke en korrekt oppkobling. Dette vises ved å velge knappen med... (2). Hvis det der pekes til forrige valgte klasse må man manuelt 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 samme prosessen flere ganger. 28

29 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. Det er likevel lurt å lagre unna 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. Lagring av modellen 18 Lagre den nye applikasjonsskjemapakka til et egnet register, fortrinnsvis til SOSI modellregister under hoveddelen som heter SOSI del 3 SOSI 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 "Havnetrafikk-5.0". 29

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

31 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 tilrettelagte rapportmaler. Se installasjonsveiledningen for installasjon av "SOSI dokumentasjonsmal i EA" etc. Generer rtf-dokument ved å høyreklikke på applikasjonsskjemapakke og velge RTF rapport: 31

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

33 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. Lesbarheten av produktspesifikasjonen kan forbedres vesentlig dersom en i siste iterasjonsrunde redigerer manuelt og legger inn informative figurer som forklarer modellelementene ytterligere. Kvalitetssikring av produktspesifikasjonsdokumentet bør avtalefestes. Dette kan avtales med Kartverket ved epost til post@norgedigitalt.no merket SOSI-produktspesifikasjon. 33

34 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. De fleste eldre fagområdestandarder har allerede slike tagged valiues for SOSI-format. Manglende tagged values kan legges inn helautomatisk ved å høyreklikke på applikasjonsskjemapakka og velge Scripts/leggInnSOSIformatTagger og trykke Ok(?). Disse må det manuelt settes inn verdier på. 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 (ogsosi_lengde skal være tom). 23 Generer SOSI-Kontroll-definisjonsfiler. Viktige tagged values som må være satt for applikasjonsskjemapakka er: Verdien av tagged value "SOSI_kortnavn" brukes bl.a. som filnavn ulike steder (eks Planomriss48). Verdien av tagged value "SOSI_versjon" skal angi hviken hovedversjon det bygges på (eks 4.5). 34

35 Verdien av tagged value "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. 35

36 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 tagged value "targetnamespace" skal inneholde navnet på navnerommet. Verdien av tagged value "version" skal inneholde detaljert versjonsinformasjon. Merk at dette detaljerte versjonsnummeret (eks beta3) kun vil ligge inne i skjemafila. Det bør likevel henge logisk tett sammen med hovedversjonsnavnet som er siste ledd i navneromsnavnet (/5.0/). Verdien av tagged value "xmlns" er lokal forkortelse for navnerom, og alle bør benytte "app". Verdien av tagged value "xsddocument" skal inneholde filnavnet på skjemafila. Verdien av tagged value "xsdencodingrule" skal være "sosi" som angir at en nasjonal utvidelse av standardencodingen iso19136_2007 skal benyttes. 36

37 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 tagged value "asdictionary" med verdien "true" og i en tagged value "codelist" med verdi som er stien til der den autorative kodelista skal ligge. (codespace) Dette bør også dokumenteres eksplisitt i produktspesifikasjonsdokumentet. Det er vanlig å angi full sti pluss kodelistenavnet, men ikke filtypen (.xml). Eksempel på fragment fra ei GML-datafil: <kommunenummer codespace= " 0612</kommunenummer> 37

38 26 Generer GML-skjema med ShapeChange via 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 den 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. 38

39 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. GML-applikasjonsskjemafila legges på underkatalog \XSD og eksterne kodelister som gml:dictionary legges på underkatalog \CL. 27 Legg inn et valid eksempel på GML data i produktspesifikasjonen. Det anbefales at et pedagogisk eksempeldatasett lages og valideres mot skjemaet, og legges inn under kapittel GML-realisering i produktspesifikasjonsdokumentet, eller i eget vedlegg. Dataeksempler bør lages tidlig i modelleringen da disse ofte vil initiere forbedringer i modellen. tbd. 28 Legg inn GML applikasjonsskjema på angitt skjemalokalisering. Send GML-applikasjonsskjemaet til: mailto:standardiseringssekretariatet@kartverket.no Det vil først legges ut for testing på: der det i en periode kan testes mot reelle datasett og gjøres feilfritt, 39

40 for så å bli endelig publisert på: tbd. Skjemaplassering kan også benyttes til publisering av eksempeldata, disse skal da ligge slik: Skjemaene kan brukes direkte til konfigurering av WFS-tjenester og oppsett av PostGIS databaser. Kvalitetssikring av GML-datasett og WFS-tjenester som følger produktets GML-applikasjonsskjema bør avtalefestes. Dette kan avtales med Kartverket ved epost til merket WFS-tjeneste. 29 Legg inn http-uri og URL til GML-applikajsonsskjema i produktspesifikasjonsdokumentet. Dette kan legges inn i produktspesifikasjonsdokumentet under kapittel X.X: URI: URL: