Shape Change er nedlastbar fra følgende adresse:

Transkript

1 Dokument tittel: Generering av GML fra UML i EA Side 1 av 6 Dokumentet beskriver bruk av Shape Change for generering av GML skjema på bakgrunn av UML modeller i Enteprise Architect. I tillegg beskrives hvordan Tagged Values i UML modellen styrer genereringen av GML skjema. 1 Installasjon 1.1 Shape Change Shape Change er nedlastbar fra følgende adresse: Merknader: Denne versjonen er benyttet for å generere GML skjema fra INSPIRE UML modellene for Annex I. Denne versjonen støtter EA direkte, det er ikke lenger behov for å gå veien via XMI. Dette er en versjon som foreløpig ikke er offisiell, det mangler blant annet dokumentasjon samt noen oppryddinger. Dette dokumentet er et forsøk på å løse det første, oppryddingen får vi komme tilbake til. Arkivet inneholder to kataloger: - lib: JAR filer. Her ligger ShapeChange JAR fil samt Xalan & Xerces JARs samt API JAR fil. - config: konfigurasjonsfiler som er brukt for INSPIRE. Merknad: Både SOSI og INSPIRE følger de reglene som er nedfelt i ISO GML Annex E. Men INSPIRE har noen tillegg i konfigureringen som følge av blant annet bruken av VOID. Med andre ord bør vi kunne kjøre på de samme konfigurasjonsfilene, men justert med tanke på f.eks namespace. 1.2 Java Runtime Environment En oppdatert versjon av Java Runtime Environment må være installert på den maskinen som skal kjøre genereringen. [Jar er kompilert for Java 1.6 så det kan være et problem for eldre versjoner] For å få tilgang til EA via Java API må fila SSJavaCOM.dll kopieres til Windows katalogen. For de som har installer EA på standard måte ligger den som følger: C:\Program Files\Sparx Systems\EA\Java API Denne må følgelig kopieres til Windows katalogen, som for Windows XP er C:\WINDOWS\system32

2 Dokument tittel: Generering av GML fra UML i EA Side 2 av 6 2 Konfigurering 2.1 Shape Change Konfigurering må tilpasses lokalt miljø. I fila config\shapechangeconfiguration.xml må alle filreferanser (se etter tilslag på "C:\") oppdateres til lokalt system. Dette må gjøres separat for hvert enkel UML modell, eller for ulike deler av samme UML modell, avhengig av kompleksitet og behov. Det er i utgangspunktet 4 verdier som må settes: inputfile: Navnet på den UML modellen (EAP fila) som er utgangspunktet for generering, med full sti. logfile: Navnet på den fila som log informasjon skrives til, med full sti. OutputDirectory(1) Navnet på den katalogen hvor selve XSD fila skal legges. OutputDirectory(2) Navnet på den katalogen hvor resultatet fra kodelistegenereringen legges. Det som er merket med uthevet skrift må oppdateres:[eksemplet er hentet fra bruken av ShapeChange i ESDIN] <?xml version="1.0" encoding="utf-8"?> <ShapeChangeConfiguration xmlns:xi=" xmlns=" xmlns:sc=" xmlns:xsi=" xsi:schemalocation=" ShapeChangeConfiguration.xsd"> <input> <parameter name="inputmodeltype" value="ea7"/> <parameter name="inputfile" value="c:\data\prosjekter\esdin\wp 7\EA model\ \esdin-exm model eap"/> <parameter name="appschemanamespaceregex" value="^urn:x-inspire:.*"/> <parameter name="publiconly" value="false"/> <parameter name="representtaggedvalues" value=""/> <xi:include href="standardaliases.xml"/> </input> <log> <parameter name="reportlevel" value="info"/> <parameter name="logfile" value="c:\data\prosjekter\esdin\wp 7\EA model\ \result.xml"/> </log> <targets> <TargetXmlSchema class="de.interactive_instruments.shapechange.target.xmlschema.xmlschema"> <targetparameter name="gmlversion" value="3.2"/> <targetparameter name="outputdirectory" value="c:\data\prosjekter\esdin\wp 7\EA model\ \xsd"/> <targetparameter name="defaultencodingrule" value="iso19136_2007_inspire_extensions"/> <targetparameter name="includedocumentation" value="true"/> <targetparameter name="enumstyle" value="global"/> <targetparameter name="basictypestyle" value="global"/> <targetparameter name="schematron" value="false"/> <targetparameter name="nogmltypedefault" value="false"/> <targetparameter name="supportwsdl" value="false"/> <xi:include href="standardnamespaces.xml"/> <xi:include href="standardmapentries.xml"/> <xsdmapentries> <XsdMapEntry type="percentage" xsdencodingrules="notencoded iso19136_2007 iso19136_2007_shapechange_1.0_extensions iso19136_2007_inspire_extensions" xmlpropertytype="anyuri" xmltype="anyuri" xmltypetype="simple" xmltypecontent="simple"/> </xsdmapentries> </TargetXmlSchema> <Target class="de.interactive_instruments.shapechange.target.codelists.codelistdictionaries"> <targetparameter name="outputdirectory" value="c:\data\prosjekter\esdin\wp 7\EA model\ \cl"/> <targetparameter name="enumerations" value="false"/> </Target> </targets> </ShapeChangeConfiguration>

3 Dokument tittel: Generering av GML fra UML i EA Side 3 av 6 Dersom det ikke skal genereres kodelister, fjern <Target> elementet (eller kommenter det ut). 2.2 Modellering i Enterprise Architect ISO Annex E inneholder modelleringsregler som må følges for at det skal være mulig å genererer GML applikasjonsskjema ut fra en UML modell. Dvs at Annex E faktisk beskriver en profil av UML som må følges dersom modellen skal være et utgangspunkt for gnerering av GML skjema. Det som er gjengitt her er kun en kortversjon av disse reglene. For fullstendig beskrivelse samt eksempler henvises til standarden NS-EN ISO 19136:2009 Geografisk informasjon geografisk markeringsspråk Klasser: Alle klasse navn innenfor samme applikasjonsskjema (modell) skal være unike og ha et "NCName" som definert av W3C XML Namespaces:1999. Objekttyper skal modelleres som UML klasser med stereotype <<FeatureType>>. Klasser som ikke er objekttyper skal følgelig ikke stereotypes <<FeatureType>>. UML klasser med stereotype <<Type>> kan ha ingen eller flere operasjoner egenskaper eller assosiasjoner. Operasjoner er ikke mappet til GML applikasjonsskjema. Stereotypen <<Abstract>> skal ikke brukes i et applikasjonsskjema fordi bruken kan være inkonsistent med korrekt UML notasjon. (I EA finnes det en egen måte å angi hva som er abstrakt) Alle instansierbare subtyper av abstrakte typer skal være enten objekttyper (stereotypet <<featuretype>> eller uten stereotyping), eller datatyper. Dvs kodelister skal ikke subtypes av abstrakte kodelister. Enumerasjoner skal modelleres som UML klasser med stereotype <<Enumeration>>. Kodelister skal modelleres om UML klasser med stereotype <<CodeList>> Union skal modelleres om UML klasser med stereotype <<Union>> (som spesifisert i ISO 19107). Alle andre datatyper skal modelleres som UML klasser med stereotype <<DataType>>. Vedrørende bruk av UML klasser fra ISO serien med standarder henvises til ISO standarden for nærmere retningslinjer. Multippel arv (multiple inheritance) støttes ikke ved generering av GML skjema. Dette er også i tråd med ISO som sier at multippel arv bør unngås Egenskaper Alle UML egenskaper, objekttyper, datatyper eller union skal ha et navn NCName og en type.

4 Dokument tittel: Generering av GML fra UML i EA Side 4 av 6 Dersom multiplisitet ikke er lik 1 skal multiplisitet spesifiseres eksakt [dvs at all manglende multiplisitet tolkes som 1 ved generering av GML skjema]. En initialverdi kan spesifiseres for en egenskap med et nummer, en karakterstreng eller en enumerert type (enumeration + codelist) [Initialverdier er ofte benyttet i SOSI] Alle UML egenskaper i en kodeliste skal ha et navn. Type informasjon skal ikke være satt. Ingen multiplisitet eller rekkefølge er tillatt. Initialverdi kan spesifiseres for dokumentere en kode i kodelista. Dersom ikke en kode er angitt benyttes verdien (navn) som kode i GML fila. Egenskaper i en UML klasser er ikke sortert. For å ivareta et spesiell rekkefølge må en benytte følgende Tagged Value, sequencenumber (Verdi domene: integer) Assosiasjoner Alle UML assosiasjoner skal være en assosiasjon med nøyaktig two assosiasjonsender, dvs vanlige assosiasjoner. N are assosiasjoner som er tillatt i UML vil ikke støttes ved generering av GML skjema. Assosiasjonsender skal kun knyttes til objekttyper eller datatyper, og kan bare benyttet stereotypen <<association>>. Manglende stereotype tolkes som <<association>>. Dersom ikke disse reglene følges vil ikke assosiasjoner taes med i genereringen av GML skjema. [merknad: i SOSI benyttes både stereotypene <<Topo>> og <<nettverk>>. Disse assosiasjonene er viktige for SOSI-syntaksen filer, men blir følgelig ikke tatt med i generering av GML skjema. Dette er bevisst, GML har egne mekanismer for å ivareta geometri og topologiknytninger. Assosiasjoner skal ikke inneholde egenskaper. Regler for assosiasjonsender: Dersom en assosiasjonsende er navigerbar skal denne angis og gis et rollenavn. En assosiasjon uten rollenavn vil ignoreres, selv om den er navigerbar. Multiplisitet skal angis. Eventuell aggregeringstype skal angis eksplisit. Dersom target class av en assosiasjon er en datatype, skal aggregeringstypen være komposisjon OCL constraint UML gir mulighet for å benytte OCL for å angi beskrankninger. Regler for dette er ikke angitt i ISO Annex E. ShapeChange har imidlertid noen muligheter, men dette er fortsatt under utvikling og ikke dokumentert. 2.3 Tilrettelegging i Enterprise Architect TaggedValues Følgende TaggedValues er benyttet av INSPIRE og må legges inn på hver eneste klasse i modellen:

5 Dokument tittel: Generering av GML fra UML i EA Side 5 av <<ApplicationSchema>> Shape Change vil generere output filer for alle pakker som er stereotypet <<applicationschema>>. Dersom ingen pakker er stereotype <<applicationschema>> genereres det ikke noe GML skjema. En kan begrense prosesseringen til et subsett av modellen på følgene måter: 1. Bruke "appschemanamespaceregex" parameteren in konfigurasjonsfila. Bare de applikasjonsskjema som har et targetnamespace tagged value som samsvarer med uttykket i paramterverdien vil prosesseres. Et eksempel på dette er bruken av "^urn:xinspire:.*" i INSPIRE. 2. Spesifisere parameteren "appschemaname" i konfiguarasjonsfila. Bare de pakker som har har dette navn vil prosesseres. Spesielt for SOSI og INSPIRE modeller som er omfattende og inneholder hele settet med ISO 191xx modeller er det viktig å begrense prosesseringen. Vi ønsker ikke å lage XSL filer for alle ISO standardene, men vi ønsker å bruke de komponenter i disse som er benyttet direkte i SOSI / INSPIRE. Foreslår at vi gjør dette slik som det er gjort i INSPIRE. [MB , har ikke eksperimentert med disse mulighetene] 3 Kjøring av programmet 3.1 Kommandolinje Programmet kjøres fra kommandolinje (for Windows XP trykk Start, deretter Run, skriv CMD), med kommandoen: java -Dfile.encoding=UTF-8 -jar "lib\shapechange_ jar" -c "config\shapechangeconfiguration.xml" [NB. I kommandofila må en navigere seg til den katalogen hvor EAP fila ligger før en starter kommandoen] Dersom alle parametere og kataloger med filnavn er korrekt, vil den kommandoen generere GML applikasjonsskjema samt kodeliste dictionary for valgt modell. 4 Andre muligheter Shape Change har fått en ny funksjon for å spesifisere innholdet av en UML modell i et Excel regneark, ofte kalt matching files eller mapping files. Dette er en funksjonalitet som benyttes i prosjekter som skal se på mapping fra egne data mot f.eks INSPIRE data. For slike tabeller legger en til en ny <Target> i konfigurasjonsfila og tilpasser output katalogen til hvor disse regnearkene skal ligge.

6 Dokument tittel: Generering av GML fra UML i EA Side 6 av 6 Eksempel fra INSPIRE: <Target class="de.interactive_instruments.shapechange.target.mapping.excel"> <targetparameter name="outputdirectory" value="c:\inspire\excel"/> </Target> 5 Feilmeldinger Som tidligere nevnt er dette er en versjon som foreløpig ikke er offisiell, det mangler blant annet dokumentasjon samt noen oppryddinger. F.eks foreligger det ikke noen utvidet tyding av feilmeldinger. Det arbeides med å lage en oversettelse fra OCL (object Contraint Language) beskrankninger i UML modellen til tilsvarende elementer i Schematron (benyttet av GML). Feilemeldinger som er relatert til OCL trenger en foreløpig ikke å ta hensyn til. Eksemplet under er knyttet til generering av GML skjema for ESDIN data, som er et subset av enkelte INSPIRE Annex I tema.