ROCZNIKI 2012 GEOMATYKI. Modele danych przestrzennych w UML i ich transformacja do schematów GML i struktur baz danych. Tom X Zeszyt 1(51) Warszawa

Transkrypt

1 POLSKIE TOWARZYSTWO INFORMACJI PRZESTRZENNEJ ROCZNIKI 2012 GEOMATYKI Modele danych przestrzennych w UML i ich transformacja do schematów GML i struktur baz danych ` Tom X Zeszyt 1(51) Warszawa

2

3 LITERATURA 5 Problematyka niniejszej monografii stanowi przedmiot szerokiego zainteresowania œrodowisk wspó³tworz¹cych i wspó³u ytkuj¹cych infrastrukturê informacji przestrzennej budowan¹ w Polsce zgodnie z przepisami krajowymi i unijnymi. Zainteresowanie to znalaz³o swój wyraz w warsztatach Modele danych przestrzennych w UML i ich transformacja do schematów GML i struktur baz danych, które odby³y siê w ramach konferencji Polskiego Towarzystwa Informacji Przestrzennej na temat Informacja przestrzenna dla Polski i Europy, Warszawa, 7 9 listopada 2011 roku. Odpowiadaj¹c na ujawnione wówczas zapotrzebowanie, zespó³ wyk³adowców podj¹³ trud zawarcia zaprezentowanych przez siebie treœci w opracowaniu o charakterze monograficznym. W rezultacie powsta³a publikacja, która przedstawia w sposób uporz¹dkowany bogaty zasób wiadomoœci okreœlonych tytu³em warsztatów i dotycz¹cych wybranych metod i technologii geoprzestrzennych. Godne uznania jest, e zespó³ autorski w sk³adzie: dr in. A. Chojka, dr in. A. Zwirowicz-Rutkowska, dr in. Z. Parzyñski i dr hab. J. Michalak, pe³ni¹cy rolê redaktora naukowego, zrealizowa³ podjête przedsiêwziêcie w stosunkowo krótkim terminie z niew¹tpliw¹ korzyœci¹ dla potencjalnych Czytelników. Warszawa, maj 2012 r. Jerzy GaŸdzicki

4 6 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Autorzy dr hab. Janusz Michalak Wydzia³ Geologii, Uniwersytet Warszawski J.Michalak@uw.edu.pl Redakcja naukowa i rozdzia³y: 1. Wstêp 2. Ró nice pomiêdzy jêzykiem zapisu danych i jego dziedzinow¹ aplikacj¹ 9. Najczêœciej pope³niane b³êdy w modelach UML dla schematów aplikacyjnych GML 11.Schematy aplikacyjne tematów aneksów II i III Dyrektywy INSPIRE 12.Podsumowanie S³ownik podstawowych terminów stosowanych w tekœcie dr in. Agnieszka Chojka Wydzia³ Geodezji i Gospodarki Przestrzennej, Uniwersytet Warmiñsko-Mazurski agnieszka.chojka@uwm.edu.pl Rozdzia³y: 3. Wprowadzenie do modelowania informacji przestrzennej metodyka MDA i diagramy klas UML 6. Budowa schematu aplikacyjnego GML regu³y budowy, narzêdzia i przyk³ady 7. Transformacja schematu aplikacyjnego UML do schematu aplikacyjnego GML wymagania, ograniczenia i wybrane narzêdzia dr in. Agnieszka Zwirowicz-Rutkowska Wydzia³ Geodezji i Gospodarki Przestrzennej, Uniwersytet Warmiñsko-Mazurski agnieszka.zwirowicz@uwm.edu.pl Rozdzia³y: 4. Przegl¹d standardów i narzêdzi wykorzystywanych do modelowania informacji geograficznej 5. Schematy aplikacyjne UML regu³y budowy i przyk³ady 10.Zastosowanie metodyki MDA wybrane zagadnienia transformacji schematów aplikacyjnych UML do struktur relacyjnych baz danych dr in. Zenon Parzyñski Wydzia³ Geodezji i Kartografii, Politechnika Warszawska z.parzynski@gik.pw.edu.pl 8. Przyk³ad zastosowania metod modelowania danych z zakresu S³u by Geodezyjno- Kartograficznej

5 WYKORZYSTANIE POLSKIE SYSTEMU TOWARZYSTWO MA OPOLSKIEJ INFRASTRUKTURY INFORMACJI INFORMACJI PRZESTRZENNEJ (MIIP)... ROCZNIKI GEOMATYKI 2012 m TOM X m ZESZYT 1(51) 7 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML I STRUKTUR BAZ DANYCH S³owa kluczowe: geoinformacja, informacja geograficzna, model pojêciowy, UML, schemat aplikacyjny, GML, model relacyjny, transformacja Streszczenie Celem monografii jest przedstawienie czytelnikom podstawowych metodyk, technik i narzêdzi przeznaczonych do budowy modeli pojêciowych danych przestrzennych na poziomie pojêciowym i implementacyjnym, a nastêpnie do transformacji tych modeli do schematów XSD bazuj¹cych na jêzyku GML i do zapisów struktur baz danych w jêzyku DDL. Ca³oœæ sk³ada siê z dwunastu rozdzia³ów dotycz¹cych poszczególnych aspektów budowy modeli i ich transformacji. Wstêp wprowadza czytelników w ca³¹ przedstawian¹ problematykê i naœwietla szerszy teoretyczny kontekst z zakresu modelowania i wykorzystania modeli w zastosowaniach praktycznych. Rozdzia³ drugi poœwiêcony jest nowym metodom zapisu danych przestrzennych opartego na jêzykach znacznikowych, a w szczególnoœci na jêzyku GML, objaœnia zasady takiego zapisu, zawiera krótk¹ historiê jêzyka GML i przedstawia inne jêzyki znacznikowe z nim powi¹zane. Rozdzia³y trzeci i czwarty stanowi¹ wprowadzenie do modelowania informacji przestrzennej opartego o metodykê MDA z wykorzystaniem jêzyka UML i zawieraj¹ przegl¹d standardów i narzêdzi s³u ¹cych temu modelowaniu. W rozdzia³ach pi¹tym i szóstym przedstawione s¹ podstawowe zasady budowy tematycznych schematów aplikacyjnych w metodyce jêzyka UML i jêzyka GML zilustrowane przyk³adami. Rozdzia³ siódmy poœwiêcony jest zagadnieniom transformacji schematów aplikacyjnych z UML do GML, a w szczególnoœci wymaganiom i ograniczeniom, jakie musz¹ byæ spe³nione, a tak e dostêpnym narzêdziom. Kolejny ósmy rozdzia³ dotyczy modeli UML dedykowanych komponentowi infrastruktury krajowej, przeznaczonym dla S³u by Geodezyjnej i Kartograficznej. W rozdziale dziewi¹tym dokonany jest przegl¹d najczêœciej pope³nianych b³êdów w budowie modeli UML przeznaczonych do utworzenia schematów bazuj¹cych na jêzyku GML. Tematem rozdzia³u dziesi¹tego jest zastosowanie metodyki MDA do transformacji modeli UML do struktur relacyjnych baz danych. Rozdzia³ jedenasty zawiera metodyczn¹ analizê ró nych przypadków wystêpuj¹cych w modelach danych tematów aneksów II i III dyrektywy INSPIRE, w tym porównanie z modelami tematów aneksu I, analizê ró nych typów i form danych, jakie tam wystêpuj¹. Dwunasty rozdzia³ to podsumowanie, w którym zwraca siê szczególn¹ uwagê na dynamiczny rozwój metod z tego zakresu, zmiany zachodz¹ce w zakresie stosowanej terminologii i skutki, jakie te zmiany za sob¹ poci¹gaj¹.

6 8 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... UML GEOSPATIAL DATA MODELS AND THEIR TRANSFORMATION INTO GML SCHEMAS AND DATABASE STRUCTURES Keywords: geoinformation, geographic information, conceptual model, UML, application schema, GML, relational model, transformation Abstract The main objective of the monograph is to present essential methodologies, technologies and software tools dedicated to building conceptual models of geospatial data on conceptual level, and implementation level, and then to be transformed into XSD schemas based on GML language and to encode data bases structures in DDL language. The whole monograph consists of twelve chapters concerning different aspects of models development and their transformation. The introduction familiarizes readers with all issues presented and clarifies broader theoretical context with regard to modeling and exploitation of models in practical applications. The second chapter is dedicated to modern methods of encoding spatial data based on markup languages, in particular on GML language; rules for that encoding are also explained. This chapter contains a short history of GML language and presents other markup languages associated with it. Chapters three and four provide an introduction to spatial information modeling based on MDA methodology with application of UML language and it contains a review of standards and tools dedicated to such modeling. In chapters five and six, essential rules of development of thematic application schemas are presented in the methodology of UML and GML languages. Examples to illustrate them are provided. Chapter seven is dedicated to issues of transformation application schemas from UML to GML, in particular to the requirements and constrains that must be fulfilled and also to available tools. The next chapter eight concerns UML models dedicated to components of the national infrastructure designated for Geodetic and Cartographic Service. In chapter nine, a review of most frequent mistakes committed in drawing up UML models dedicated to generating of schemas based on GML language are presented. The subject of chapter ten is the application of MDA methodology for transformation of UML models into relational databases structures. Chapter eleven contains methodological analysis of various cases occurring in data models for the themes defined in Annex II and III of INSPIRE Directive as well as a comparison with the models for themes defined in Annex I and an analysis of various data forms occuring there. In chapter twelve, the recapitulation is presented, in which dynamic development of methods in this area is taken in consideration. In addition, significant changes in the terminology and the effects of these changes are discussed.

7 WYKORZYSTANIE POLSKIE SYSTEMU TOWARZYSTWO MA OPOLSKIEJ INFRASTRUKTURY INFORMACJI INFORMACJI PRZESTRZENNEJ (MIIP)... ROCZNIKI GEOMATYKI 2012 m TOM X m ZESZYT 1(51) 9 Spis treœci 1. Wstêp Ró nice pomiêdzy jêzykiem zapisu danych i jego dziedzinow¹ aplikacj¹ Podstawy zapisu znacznikowego na bazie jêzyka XML Wprowadzenie do jêzyka GML Krótka historia zapisu geoinformacji Jêzyki oparte na GML i z nim powi¹zane Przysz³oœæ jêzyka GML Modele UML dedykowane zapisom w jêzyku GML Wprowadzenie do modelowania informacji przestrzennej metodyka MDA i diagramy klas UML Wprowadzenie Regu³y budowy schematów aplikacyjnych w UML Przegl¹d standardów i narzêdzi stosowanych do modelowania informacji geograficznej Model dziedzinowy informacji geograficznej Funkcjonalnoœæ narzêdzi do modelowania pojêciowego Schematy aplikacyjne UML regu³y budowy i przyk³ady Pojêcie schematu aplikacyjnego, jego rola i znaczenie Proces budowy schematów aplikacyjnych Przyk³ady schematów aplikacyjnych UML Budowa schematu aplikacyjnego GML regu³y budowy, narzêdzia i przyk³ady Regu³y budowy schematów aplikacyjnych GML Przyk³ad przekszta³cenia schematu aplikacyjnego UML na GML... 66

8 10 SPIS TREŒCI 7. Transformacja schematu aplikacyjnego UML do schematu aplikacyjnego GML wymagania, ograniczenia i wybrane narzêdzia Metody transformacji UML do GML Metoda rêczna Metoda automatyczna Podsumowanie Przyk³ad zastosowania metod modelowania danych z zakresu S³u by Geodezyjno-Kartograficznej Za³o enia przyjête w GUGiK przy opracowywaniu projektów rozporz¹dzeñ Realizacja za³o eñ Przyk³ady schematów aplikacyjnych do projektów rozporz¹dzeñ Najczêœciej pope³niane b³êdy w modelach UML dla schematów aplikacyjnych GML UML jest cierpliwy jak papier Wymagania dotycz¹ce modeli UML dla INSPIRE Zastosowanie metodyki MDA wybrane zagadnienia transformacji schematów aplikacyjnych UML do struktur relacyjnych baz danych Transformacja w ujêciu metodyki MDA Ogólne zasady mapowania pomiêdzy modelem obiektowym i modelem relacyjnym Transformacja schematu aplikacyjnego UML do logicznej struktury relacyjnej bazy danych Schematy aplikacyjne tematów aneksów II i III dyrektywy INSPIRE Nietypowy przypadek temat Geologia Podsumowanie S³ownik podstawowych terminów stosowanych w tekœcie Literatura

9 POLSKIE TOWARZYSTWO 1. WSTÊP INFORMACJI PRZESTRZENNEJ ROCZNIKI GEOMATYKI 2012 m TOM IX m ZESZYT 1(51) 11 Janusz Michalak 1. Wstêp Publikacja ta, ma charakter monografii, zawiera przegl¹d podstawowych zagadnieñ dotycz¹cych opracowywania modeli pojêciowych danych geoprzestrzennych na poziomie niezale nym od platformy implementacyjnej, ich transformacjê do modeli zale nych od tych platform i generowania kodu niezbêdnego do budowy konkretnych implementacji. Przedstawione s¹ szczegó³owo dwie platformy technologiczne. Pierwsza z nich przeznaczona jest do wymiany danych pomiêdzy systemami i jest to tekstowy zapis danych geoprzestrzennych z zastosowaniem regu³ znacznikowego jêzyka XML, a w tym przypadku jego specjalizacji dla informacji geoprzestrzennej, któr¹ jest GML (Geography Markup Language). Drug¹ platform¹, przeznaczon¹ do przechowywania tych danych i ich pobierania jest technologia relacyjnych baz danych zaimplementowana w systemach ich zarz¹dzania (SZBD System Zarz¹dzania Baz¹ Danych, DBMS DataBase Management System). Publikacja jest prac¹ zbiorow¹ czterech autorów: Agnieszki Chojki, Agnieszki Zwirowicz- Rutkowskiej, Zenona Parzyñskiego i Janusza Michalaka pe³ni¹cego tak e rolê redaktora naukowego ca³oœci. W wielu aspektach szczegó³owych przedstawianej problematyki autorzy maj¹ czêsto ró ne podejœcie do poszczególnych kwestii. Wynika to z ich ró nych doœwiadczeñ i niejednakowego zakresu wiedzy, co jest konsekwencj¹ ich zró nicowanych zainteresowañ naukowych i zawodowych, a w szczególnoœci ró nych dyscyplin, jakie reprezentuj¹. Zakres dyscyplin badawczych jest tu szeroki od geodezji szczegó³owej, gdzie podstaw¹ jest precyzyjny pomiar do nauk o Ziemi, w tym geologii i hydrogeologii, gdzie zdobycie ka dej informacji jest trudne, jest ona niepewna i wymaga wszechstronnej analizy w celu praktycznego wykorzystania. Ró ne doœwiadczenia i ró ny zakres wiedzy s¹ tak e przyczyn¹ ró norodnoœci terminologicznej. W poszczególnych rozdzia³ach te same pojêcia mog¹ byæ nazywane ró nie i jedno okreœlenie mo e byæ stosowane do ró nych pojêæ. Z tego wzglêdu na koñcu monografii znajduje siê ma³y s³ownik podstawowych pojêæ z zakresu tej problematyki, u³atwiaj¹cy czytelnikom poprawne zrozumienie treœci poszczególnych rozdzia³ów. Czas opublikowania monografii nie jest przypadkowy. Jak nigdy dot¹d, w wielu oœrodkach liczne zespo³y zajmuj¹ sie t¹ problematyk¹, zarówno w podejœciu czysto badawczym jak i dla konkretnych praktycznych zastosowañ. Wynika to g³ównie z potrzeby realizacji zadañ, jakie przed polskim œrodowiskiem zajmuj¹cym siê geoinformacj¹ postawi³a europejska dyrektywa INSPIRE (EP&CEU, 2007) i krajowa ustawa o IIP (Ustawa, 2010). Zbudowanie polskiej czêœci infrastruktury INSPIRE, stanowi¹cej tak e czêœæ krajowej infrastruktury informacji przestrzennej, jest trudnym zadaniem stoj¹cym przed ca³¹ spo³ecznoœci¹ tworz¹c¹ i wykorzystuj¹c¹ dane geoprzestrzenne. Nowe technologie, przyjête jako podstawa interoperacyjnoœci komponentów infrastruktury, wymagaj¹ miêdzy innymi gruntownego przebudowania dotychczasowych struktur danych. Opracowanie nowych modeli dla danych

10 12 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... przestrzennych niezbêdnych do efektywnego funkcjonowania wielu dziedzin naszej dzia³alnoœci i jednoczesne zharmonizowanie tych modeli z modelami danych INSPIRE wymaga zastosowania zaawansowanych metodyk, w tym te opartych na jêzykach UML, GML i z uwzglêdnieniem wymagañ, jakie wynikaj¹ z potrzeb stosowania relacyjnych baz danych. Monografia przeznaczona jest g³ównie dla osób reprezentuj¹cych ró ne dziedziny zastosowañ geoinformacji, przed którymi stoi zadanie opracowania nowych form zapisu danych przestrzennych, zarówno w aspekcie zakresu tematycznego i szczegó³owej ich zawartoœci, jak i w aspekcie ich struktury i wzajemnych powi¹zañ. Jest to stosunkowo w¹ska grupa specjalistów w porównaniu z licznoœci¹ wszystkich uczestników prac dotycz¹cych budowy krajowej infrastruktury informacji przestrzennej (rys. 1.1A). W dalszych rozdzia³ach przedstawione s¹ trzy œrodowiska trzy platformy: 1. Œrodowisko projektowania struktury danych modelu pojêciowego z zastosowaniem jêzyka UML (Unified Modeling Language). 2. Platforma implementacyjna tekstowego zapisu danych w oparciu o jêzyk GML, jako znacznikowego jêzyka XML (extensible Markup Language). 3. Platforma implementacyjna przechowywania danych w bazie relacyjnej. W tym przypadku wynikiem prac projektowych jest struktura bazy zapisana w jêzyku DDL (Data Definition Language lub Data Description Language). Pominiête zosta³y dwie inne wa ne platformy implementacyjne obiektowe jêzyki programowania, jak na przyk³ad C++ i Java i platforma obiektowych baz danych czêœciowo z tymi jêzykami zwi¹zana. Bazy te s¹ zarz¹dzane przez OSZBD (Obiektowy System Zarz¹dzania Baz¹ Danych, ODBMS Object Database Management System), a struktury danych w tych bazach s¹ zapisywane w jêzyku ODL (Object Definition Language), o sk³adni zbli onej do jêzyków C++ i Java. Pominiêcie to nie jest przypadkiem, poniewa w Polsce prace z zakresu stosowania tych platform dla geoinformacji s¹ ograniczone jedynie do studiów i eksperymentów badawczych. Rysunek 1.1B symbolicznie przedstawia ró nice pomiêdzy platformami projektowania i implementacji stosowanymi do danych geoprzestrzennych. Trudno jest znaleÿæ wspóln¹ p³aszczyznê i wspólne elementy dla ró nych œrodowisk realizacji projektów informatycznych zarówno niezale nych od platformy (jêzyk UML) jak i zale nych od platform implementacyjnych. Dotyczy to zakresu obiektowoœci, mechanizmów dziedziczenia, zagnie d eñ Rys A Schematyczna piramida przedstawiaj¹ca udzia³ poszczególnych grup uczestników prac dotycz¹cych budowy krajowej infrastruktury informacji przestrzennej. B Symboliczne przedstawienie ró nic pomiêdzy platformami projektowania i implementacji stosowanymi do danych geoprzestrzennych.

11 1. WSTÊP 13 elementów i ró nych typów powi¹zañ. Ró nice te s¹ bardziej szczegó³owo przedstawione w dalszych rozdzia³ach. Podstawowym narzêdziem stosowanym obecnie do opracowania modeli danych geoprzestrzennych jest jêzyk UML. Jednak zastosowanie tego jêzyka jest znacznie szersze, s³u y on g³ównie do projektowania i budowy systemów informatycznych (tak e geoinformatycznych). Z tego wzglêdu zarówno sam jêzyk UML, jak i metodykê MDA (Model-Driven Architecture), która go wykorzystuje, trzeba umiejêtnie ograniczyæ do zawê onego aspektu samych danych jedynie do modeli statycznych. Projektowanie struktur relacyjnych baz danych przestrzennych jest zagadnieniem stosunkowo dobrze opracowanym i istnieje ju w kraju wiele tego typu baz danych. Podstawowy problem, jaki jest obecnie do rozwi¹zania, to maksymalne dostosowanie tych struktur do form przyjmowanych w GML tak, aby ró nice pomiêdzy zapisem wewnêtrznym w bazach i zapisem zewnêtrznym w GML by³y jak najmniejsze. Jednak zastosowania praktyczne takiego podejœcia wymagaj¹ wielu mudnych prac nad opracowaniem poprawnych modeli danych, zarówno na wysokim poziomie ontologicznym (w tym semantycznym i taksonomicznym), jak i na poziomie implementacyjnym i aplikacyjnym technologicznym w zakresie kodowania samych danych i budowy systemów, które te dane przetwarzaj¹. W przypadkach nowych zastosowañ dziedzinowych najczêœciej nie jest mo liwe opracowanie poprawnych modeli bez mudnych prac powtarzanych cyklicznie. Jak wykazuj¹ to ró ne przyk³ady, jest to proces wieloetapowy w ramach kolejnych powtarzaj¹cych siê etapów modele danych dla okreœlonej dziedziny staj¹ siê coraz bardziej pe³ne, kompletne, wewnêtrznie spójne i precyzyjne (rys. 1.2A). Rys A Opracowanie modeli UML i schematów XSD dedykowanych okreœlonej dziedzinie jest z koniecznoœci procesem cyklicznym, w którym kolejno postaj¹ coraz bardziej dojrza³e wersje. B Metamodel modeli podstawowe pojêcia z zakresu modelowania i zachodz¹ce miêdzy nimi relacje (Refsgaard, Henriksen, 2004).

12 14 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Rys Od rzeczywistoœci do schematu pojêciowego, opartego na pojêciowym formalizmie i na jêzyku schematów pojêciowych. Cytat z normy ISO (ISO/TC 211, 2005a) z uzupe³nieniami terminów polskich. W tym przypadku jest to tylko model statyczny rzeczywistoœci. Metodyka MDA dotyczy budowy systemów informatycznych, zarówno w ich aspekcie statycznym, jak i dynamicznym. W przypadku danych geoprzestrzennych z okreœlonej dziedziny model jest ograniczony tylko do aspektu statycznego (rys. 1.3). Najczêœciej dane opisuj¹ statycznie otaczaj¹c¹ nas rzeczywistoœæ, jednak rzeczywistoœæ ta nie jest statyczna. Pe³ne modele dotycz¹ce zjawisk œwiata rzeczywistego powinny równie opisywaæ lub symulowaæ dynamikê tych zjawisk, co jest mo liwe tylko przy zastosowaniu oprogramowania symuluj¹cego zachodz¹ce zmiany. Metamodel takich modeli jest schematycznie przedstawiony na rysunku 1.2B. Dla dok³adniejszego zapoznania siê z problematyk¹ terminologiczn¹ dotycz¹c¹ zagadnieñ modeli pojêciowych zjawisk przyrodniczych mo na odes³aæ czytelników do publikacji Refsgaarda i Henriksena (2004): Modelling guidelines terminology and guiding principles. Poniewa tu zajmujemy siê danymi przestrzennymi tu termin model pojêciowy jest ograniczony jedynie do struktur i zawartoœci tych danych.

13 2. RÓ NICE POLSKIE POMIÊDZY TOWARZYSTWO JÊZYKIEM ZAPISU DANYCH INFORMACJI I JEGO DZIEDZINOW PRZESTRZENNEJ APLIKACJ ROCZNIKI GEOMATYKI 2012 m TOM X m ZESZYT 1(51) 15 Janusz Michalak 2. Ró nice pomiêdzy jêzykiem zapisu danych i jego dziedzinow¹ aplikacj¹ Bardzo czêsto, bez g³êbszego zastanowienia siê, jêzyk GML i inne jêzyki z nim powi¹zane nazywa siê formatem zapisu danych przestrzennych. Jednak g³êbsza analiza tego zagadnienia wykazuje, e jest olbrzymia ró nica pomiêdzy tak¹ form¹ zapisu a sztywnymi formatami stosowanymi dawniej i jeszcze obecnie. Z tego wzglêdu w rozdziale tym opisane s¹ podstawy zapisu znacznikowego w oparciu o jêzyk XML, który jest fundamentem dla jêzyka GML. Rozdzia³ zawiera tak e krótk¹ historiê zapisu geoinformacji, relacje pomiêdzy GML a innymi jêzykami od niego pochodnymi lub z nim powi¹zanymi, a tak e informacje na temat dalszych prac nad rozwojem GML Podstawy zapisu znacznikowego na bazie jêzyka XML Zarówno zapisy w GML, jak i w innych jêzykach znacznikowych bazuj¹cych na XML, s¹ zwyk³ym prostym tekstem, czêsto nies³usznie nazywanym formatem ASCII. ASCII to sposób kodowania znaków, który ze wzglêdu na jego ograniczenia jest tu zast¹piony przez standard Unicode w wersji UTF-8. Tekst ten jest podzielony na fragmenty (nazywane elementami) przy pomocy znacznika pocz¹tku elementu w postaci <nazwatypuelementu> i znacznika koñca ró ni¹cego siê znakiem ukoœnika przed nazw¹ (rys. 2.1A). Rys ABC jêzyka XML. Jest to zwyk³y tekst podzielony na fragmenty za pomoc¹ znaczników (Michalak, 2003b). Objaœnienia w tekœcie.

14 16 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Element mo e byæ prosty i taki nie zawiera wewn¹trz innych elementów a jedynie tekst lub mo e byæ z³o ony mo e zawieraæ w sobie wiele innych elementów (rys. 2.1C). Je eli one s¹ równie z³o one mamy do czynienia z wielokrotnym zagnie d eniem, które w szczególnych przypadkach mo e byæ nieskoñczone (rys w rozdziale 2.5). Element mo e posiadaæ atrybuty, które odnosz¹ siê do wnêtrza elementu do jego zawartoœci. Atrybuty s¹ umieszczane w znaczniku pocz¹tku w formie nazwaatrybutu= wartoœætegoatrybutu (rys. 2.1B). Poni ej przedstawiony jest przyk³ad (2.1) zastosowania atrybutu (tekst pogrubiony) do okreœlenia jêzyka w jakim jest napisany tekst wewn¹trz elementu: Przyk³ad 2.1. Elementy tekstowe z podaniem jêzyka w atrybucie elementy. JPG37B)UHH7H[W! JPGWH[W*URXS! JPG/RFDOLVHG&KDUDFWHU6WULQJORFDOH ORFDOHHQJ!:DUVDZJPG/RFDOLVHG&KDUDFWH JPG/RFDOLVHG&KDUDFWHU6WULQJORFDOH ORFDOHSRO!:DUV]DZDJPG/RFDOLVHG&KDUDF JPGWH[W*URXS! JPG37B)UHH7H[W! Dla lepszej czytelnoœci poszczególne sk³adniki zapisu dzieli siê na linie tekstu ze stopniowo powiêkszaj¹cym siê wciêciem dla pokazania hierarchicznego zagnie d ania siê elementów (rys. 2.1D i 2.2). Jest to jednak potrzebne jedynie cz³owiekowi, poniewa system programowy, który generuje takie zapisy, czyta je lub przetwarza nie potrzebuje takiego uk³ad tekstu dla poprawnej analizy zapisu. Rys Regu³y zapisu dokumentu XML s¹ okreœlone w schemacie XSD, który równie jest zapisany w ten sam sposób (Michalak, 2003b). Przyk³ad uproszczony. W pliku tekstowym (dokumencie) mo na zapisywaæ dane z okreœlonej dziedziny tylko przy pomocy zdefiniowanej listy typów elementów (zdefiniowanego s³ownika). Zbiór tych definicji jest zapisany w tak zwanym schemacie XSD (XML Schema Definition). Bardzo prosty i niepe³ny przyk³ad schematu XSD dla zapisu okresu czasu jest przedstawiony na rysunku 2.2, przyk³ad takiego zapisu zgodnego z tym schematem przedstawia rysunek 2.3.

15 2. RÓ NICE POMIÊDZY JÊZYKIEM ZAPISU DANYCH I JEGO DZIEDZINOW APLIKACJ 17 Rys Przyk³ad zapisu XML zgodny ze schematem XSD przedstawionym na rys. 2.2 (Michalak, 2003b). Przyk³ad uproszczony. Poniewa zapisy te s¹ zwyk³ym tekstem, mo na je pisaæ przy pomocy najprostszego edytora teksu, na przyk³ad przy pomocy notatnika (notepad). Jest to jednak trudne i stwarza mo liwoœæ pope³niania wielu b³êdów. Z tego wzglêdu wskazane jest pos³ugiwanie siê przeznaczonymi do tego specjalistycznymi edytorami. Przyk³ady takich edytorów lub fragmentów ich okien przedstawione s¹ na rysunkach 2.9, 2.11, 2.15, 2.16, 9.3, 11.9 i Wiele z nich pozwala na graficzn¹ analizê i edycjê dokumentów XML. Rysunek 2.4 objaœnia sk³adniki diagramu stosowanego w edytorze XML Spy firmy Altova. Przyk³ad innego diagramu elementów stosowanego w edytorze Oxygen (o nazwie w formie znacznika <oxygen/>) firmy Syncro Soft jest przedstawiony na rysunku Rys Edytory XML (i w tym XSD) umo liwiaj¹ graficzne przedstawienie struktury schematu XSD. Rysunek przedstawia objaœnienia konwencji graficznej przyjêtej w edytorze XML Spy (Michalak, 2003a).

16 18 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML Wprowadzenie do jêzyka GML U podstaw koncepcji i aktualnie prowadzonych prac nad GML le y szereg wstêpnych za³o eñ: m jêzyk powinien daæ mo liwoœæ efektywnego zapisu w celu przesy³ania geoinformacji w heterogenicznym rozproszonym œrodowisku systemowym; m jêzyk powinien umo liwiæ przesy³anie tej informacji niezale nie od stopnia agregacji zarówno pojedyncze wyró nienia jak i du e kolekcje danych, na przyk³ad mapy numeryczne; m informacja zapisywana w GML powinna dotyczyæ ca³ego zakresu danych metadanych, opisu elementów geometrycznych wraz ze wspó³rzêdnymi okreœlaj¹cymi te elementy, rodzaje zastosowanych uk³adów odniesienia i odwzorowania wraz ze wszystkimi parametrami tych uk³adów, podstawowe atrybuty wyró nieñ, a tak e informacjê o sposobie ³¹czenia wyró nieñ w zbiory wyró nieñ i o powi¹zaniach z innymi rodzajami informacji; m poszczególne wyró nienia (nawet w obrêbie jednego zbioru wyró nieñ) mog¹ byæ odniesione geoprzestrzennie w ró nych uk³adach; m geoinformacja powinna byæ zapisana niezale nie od skali ewentualnej póÿniejszej wizualizacji (na ekranie lub na papierze) jednak mo e byæ powi¹zana z innymi dokumentami (zapisami tekstowymi) okreœlaj¹cymi graficzne formy przeznaczone do jej wizualizacji, odpowiednimi do jej treœci, a tak e skali. W trakcie rozwoju jêzyka GML (rys. 2.12) okaza³o siê, e zakres jego zastosowañ mo e byæ znacznie szerszy ni pocz¹tkowo zak³adano. Jêzyk ten mo e byæ z równym powodzeniem stosowany tak e do przechowywania danych w bazach i jako rodzimy (wewnêtrzny) format w systemach GIS do przetwarzania, analizy i filtrowania geoinformacji. atwoœæ modyfikowania go i ³¹czenia z innymi jêzykami wyprowadzonymi z XML daje du e mo liwoœci opracowywania wyspecjalizowanych odmian tego jêzyka dla specyficznych zastosowañ w ró nych dziedzinach pos³uguj¹cych siê geoinformacj¹. Przyk³ady takich wyspecjalizowanych rozszerzeñ GML s¹ przedstawione w rozdziale 2.4. Dlaczego jêzyk, a nie format? Istnieje przecie wiele formatów do zapisu geoinformacji w przeró nych postaciach, czy rzeczywiœcie potrzebne jest jeszcze coœ nowego? Doœwiadczenia wynikaj¹ce z zastosowañ zaawansowanych z³o onych systemów geoinformacyjnych i nowych technologii przesy³ania danych wykazuj¹ jednak, e dotychczasowe rozwi¹zania oparte na sztywnych formatach bazuj¹cych na zamkniêtych prostych modelach danych geoprzestrzennych nie s¹ wystarczaj¹ce. Podobne zjawiska obserwuje siê tak e w innych dziedzinach w odniesieniu do innych rodzajów informacji. W przeciwieñstwie do formatu, jêzyk a w tym przypadku GML pozwala na dynamiczne zapisywanie danych w ró nej formie zale nej od zawartoœci tych danych i od aktualnej potrzeby. W rezultacie przy pomocy jêzyka mo na t¹ sam¹ geoinformacj¹ zapisaæ ró nie i nie jest to wada takiego podejœcia, lecz zaleta. T¹ zaletê ilustruje przyk³ad schematu dynamicznego zapisu danych geoprzestrzennych opartego na zapisie modelu danych w jêzyku UML, konwersji tego modelu do zapisu w jêzyku XMI i wygenerowania na tej podstawie schematu XSD dla modyfikacji zapisu danych w jêzyku GML. Schemat ten jest opisany w pracy D. Skogana (1999). Rysunek 2.5 przedstawia taki schemat dynamicznego u ycia tych jêzyków do przekazu geoinformacji.

17 2. RÓ NICE POMIÊDZY JÊZYKIEM ZAPISU DANYCH I JEGO DZIEDZINOW APLIKACJ 19 Rys Ogólny schemat procesu transformacji danych do XML z zastosowaniem modeli UML (Skogan, 1999). S³owo jêzyk kojarzy siê nam najczêœciej z jêzykiem naturalnym. Jednak we wspó³czesnej informatyce stosowana jest olbrzymia liczba przeró nych wyspecjalizowanych notacji nazywanych równie jêzykami. Najogólniej jêzyki te mo na podzieliæ na cztery grupy: 1. Jêzyki programowania jêzyk programowania sk³ada siê z dwóch czêœci, pierwsza to regu³y syntaktyczne i druga to semantyka. Obie te czêœci okreœlaj¹, jak nale y pisaæ poprawne wyra enia i jak maj¹ byæ interpretowane przez kompilatory tych jêzyków. 2. Jêzyki komunikatów interfejsowych do nich nale ¹ jêzyki zapytañ (na przyk³ad SQL i OQL), a tak e jêzyki poleceñ, na przyk³ad w protokóle HTTP sk³adnia poleceñ Get i Post jest u ywana w standardowych us³ugach sieciowych dotycz¹cych danych geoprzestrzennych (CSW, WMS, WFS i innych). 3. Jêzyki specyfikacyjne w przypadku danych s¹ to jêzyki okreœlaj¹ce struktury tych danych i nale ¹ do nich DDL, ODL, XSD i tak e w pewnym stopniu UML, OIL (Ontology Inference Layer lub Ontology Interchange Language) i inne z nim powi¹zane. 4. Jêzyki znacznikowe dziel¹ siê na trzy kategorie: prezentacyjne, proceduralne i opisowe. Zapis w znakowaniu opisowym nazywany tak e semantycznym i dzieli tekst na fragmenty znaczeniowe. Obecnie olbrzymia liczna ró nych dziedzinowych jêzyków opisowych stosuj¹cych znakowanie ogólne (generic markup) oparta jest na standardzie jêzyka (lub raczej metajêzyka) XML. Pomiêdzy jêzykami naturalnymi i jêzykami stosowanymi w informatyce wystêpuje wiele podobieñstw. Mo na tu u yæ metafory ontologicznej porównuj¹c miêdzy sob¹ ró ne komponenty wystêpuj¹ce w obu kategoriach. Syntaktyka w jêzykach informatycznych odpowiada w przybli eniu regu³om gramatycznym jêzyka naturalnego, a semantyka jêzyka informatycznego okreœla znaczenie poszczególnych elementów, co w jêzyku naturalnym odpowiada³oby roli s³ownika (rys. 2.6).

18 20 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Rys A Metaforyczne porównanie jêzyka XML i jego dziedzinowych aplikacji do jêzyka naturalnego objaœnienia w tekœcie. B Jêzyk (zarówno naturalny jak i XML) jest miedzy innymi s³ownikiem (magazynem elementów). Z tego magazynu wybiera siê do schematu aplikacyjnego te elementy, które s¹ potrzebne w okreœlonej dziedzinie zastosowañ. Dokument XML (w tym tak e GML) zawieraj¹cy dane mo na porównaæ z ksi¹ k¹, a jêzyk aplikacyjny zdefiniowany w schemacie XSD, w jakim ten dokument jest zapisany, mo na porównaæ ze s³ownikiem jêzyka naturalnego. Jednak jest tu istotna ró nica powi¹zanie dokumentu (ksi¹ ki) z ró nymi schematami (s³ownikami) wymaga precyzyjnego okreœlenia za pomoc¹ elementu import, a ka dy zaczerpniêty element (s³owo) jest poprzedzone przedrostkiem okreœlaj¹cym przestrzeñ nazw (zakres s³ownika) i wskazuj¹cym z jakiego schematu (s³ownika) pochodzi definicja tego elementu (s³owa). Element (instrukcja) import powoduje przy³¹czenie s³ownika do schematu aplikacyjnego, co daje mo liwoœæ wykorzystywania w schemacie elementów zdefiniowanych w tym s³owniku. W takim przypadku elementy importowane maj¹ inn¹ przestrzeñ nazw ni przestrzeñ aplikacji. Element (instrukcja) include jest u ywana do ³¹czenia poszczególnych dokumentów XSD w ramach jednego schematu aplikacyjnego. Ma to zastosowanie, gdy elementy tego schematu zdefiniowane w jednym dokumencie s¹ u ywane w innych. W takim przypadku najczêœciej wszystkie te elementy maj¹ jedn¹ wspóln¹ przestrzeñ nazw. Zastosowanie jêzyka GML do zapisu danych geoprzestrzennych daje du ¹ przewagê nad zapisami przy u yciu tradycyjnych formatów. Zakres zastosowañ tego jêzyka jest znacznie szerszy (rys. 2.7). Format tekstowy daje du ¹ swobodê w manipulowaniu zapisem. Pliki z zapisami danych w GML, gdy przestrzegane s¹ regu³y dotycz¹ce schematów aplikacyjnych,

19 2. RÓ NICE POMIÊDZY JÊZYKIEM ZAPISU DANYCH I JEGO DZIEDZINOW APLIKACJ 21 Rys Schematyczne przedstawienie zakresu mo liwoœci kodowania, jakie daj¹ sztywne formaty i elastyczny zapis za pomoc¹ jêzyka. A Transformacja z jednego formatu do innego mo e obj¹æ jedynie czêœæ wspóln¹ modeli danych obu tych formatów. B Jêzyk GML daje tak szerokie mo liwoœci zapisu ró nych typów danych, e praktycznie obejmuje wszystkie popularne formaty dla danych przestrzennych. Rys Przyk³ady ³¹czenia i rozdzielania zbiorów danych zapisanych za pomoc¹ jêzyka GML. mo na dowolnie w prosty sposób (np. edytorem tekstu) ³¹czyæ lub dzieliæ, jednak z zachowaniem kilku warunków, w tym deklaracji przestrzeni nazw xmlns i prostok¹ta ograniczaj¹cego BBox (rys. 2.8). W jednym zbiorze danych zapisanym zgodnie z regu³ami XML mo na umieszczaæ elementy z ró nych jêzyków dziedzinowych, zarówno dla danych przestrzennych (w GML i jêzykach od niego pochodnych), jak i danych nieprzestrzennych zawartych w elementach schematów niezale nych od GML. Mo na równie dowolne elementy zdefiniowane w schematach GML u ywaæ w innych jêzykach. Jednak takie postêpowanie wymaga du ego doœwiadczenia i zak³ada z góry, e typowe oprogramowanie dedykowane jêzykowi GML nie bêdzie mog³o poprawnie interpretowaæ takiego zapisu. Rysunek 2.9 przedstawia specyfikacjê elementu ze schematu aplikacyjnego dla tematu Geologia (Geology) dyrektywy INSPIRE. Specyfikacje takie sk³adaj¹ siê z dwóch czêœci deklaracji, w której okreœla sie nazwê i wskazanie na typ okreœlony w drugiej czêœci nazywanej definicj¹ typu. Definicja typu szczegó³owo okreœla zawartoœæ elementu. W przypadku elementów z³o onych zawartoœæ ta mo e sk³adaæ siê z wielu elementów, które mog¹ byæ hierarchiczne zagnie d one. Typy elementów sk³adowych mog¹ byæ zdefiniowane w tym samym schemacie (w tym samym pliku lub pliku przy³¹czonym instrukcj¹ include). Syntaktyka jêzyka XML pozwala na u ycie wiêcej ni jednej deklaracji odwo³uj¹cej siê do jednej definicji. W rezultacie mo e byæ kilka elementów o ró nych nazwach tego samego typu o takiej samej budowie wewnêtrznej okreœlonej w definicji typu.

20 22 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Rys Ka dy element w schemacie aplikacyjnym opartym na GML jest specyfikowany dwukrotnie: jako jego deklaracja i jako definicja jego typu. Tabelaryczne przedstawienie elementów schematu w oknie edytora XML o nazwie </oxygen>. Rysunek 2.10.przedstawia graficzny schemat XSD (w konwencji zobrazowania przyjêtej w edytorze XML </oxygen> ) z³o onego elementy o skomplikowanej budowie Na uwagê zas³uguje fakt, e diagramy graficzne tego edytora s¹ równie zapisane wektorowo przy pomocy jêzyka SVG (Scalable Vector Graphics) przeznaczonego do zapisu takiej grafiki. Dziêki takiemu rozwi¹zaniu zobrazowanie informacji XML jest realizowane te za pomoc¹ tego jêzyka, a œciœlej innej jego aplikacji. Rys Diagram XSD edytora </oxygen> przedstawiaj¹cy skomplikowan¹ budowê wewnêtrzn¹ elementu z³o onego. Przyk³ad pochodzi ze specyfikacji danych INSPIRE tematu Geologia (Geology). Wiêkszoœæ elementów wewnêtrznych jest równie elementami z³o onymi i klikniêcie na znak plus w kó³ku na koñcu symbolu elementu powoduje jego rozwiniêcie.

21 2. RÓ NICE POMIÊDZY JÊZYKIEM ZAPISU DANYCH I JEGO DZIEDZINOW APLIKACJ 23 Kolejnym przyk³adem analogii pomiêdzy jêzykami znacznikowymi a jêzykiem naturalnym s¹ synonimy ró ne okreœlenia maj¹ to samo znaczenie. W jêzyku GML zapis danych w jednym pliku sk³ada siê ze zbioru elementów typu FeatureMember. Ca³y ten zbiór jest umieszczony w jednym elemencie pojemniku (stosowane jest tak e okreœlenie korzeñ root) i w ró nych aplikacjach nazwa tego pojemnika mo e byæ ró na, na przyk³ad specyfikacja us³ugi WFS (Web Feature Service) wymaga, aby nazywa³ siê on FeatureCollection, a dla danych INSPIRE jest wymagana nazwa SpatialDataSet (rys. 2.11). Rys Synonimy jêzykowe dotycz¹ce nazw g³ównych elementów (pojemników okreœlanych tak e jako root). W górnym przyk³adzie dotyczy to danych INSPIRE, a w dolnym specyfikacji WFS i wersji jêzyka GML. Przedstawione w tym rozdziale krótkie wprowadzenie do jêzyka GML porusza tylko kilka wybranych najwa niejszych ogólnych aspektów tego zagadnienia. Nie wystarczy to do pe³nego zrozumienia zasad opracowania schematów aplikacyjnych i praktycznego ich wykorzystania. Z tego wzglêdu warto na zakoñczenie wskazaæ bardziej obszerne Ÿród³a informacji z tego zakresu. Obok ksi¹ ki poœwiêconej temu jêzykowi (Lake i inni, 2004) wyró niæ nale y: 1) ³atwo dostêpne specyfikacje OGC (Open Geospatial Consortium), w tym miêdzy innymi: m GML Extended schemas and encoding rules, v (Portele, 2012), m OpenGIS Geography Markup Language (GML) Encoding Standard, v (Portele, 2007), znany tak e jako norma ISO 19136:2007 (ISO/TC 211, 2007a), m Geography Markup Language (GML) simple features profile (with Corrigendum), v. 2.0 (Brink, Portele, Vretanos, 2011); 2) publikacje naukowe i popularnonaukowe dostêpne w Internecie, na przyk³ad: m The roles of geography markup language (GML), scalable vector graphics (SVG), and Web feature service (WFS) specifications in the development of Internet geographic information systems (GIS) (Peng, Zhang, 2004), m GML-Based Interoperable Geographical Databases (Zhang i inni, 2003), m Building GML-native web-based geographic information systems (Huang i inni, 2009), m Visualization of GML data using XSLT (Tennakoon, 2003).

22 24 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Przedstawione powy ej pozycje to tylko przyk³ady wybrane z wielkiej liczby publikacji dostêpnych w formie elektronicznej Krótka historia zapisu geoinformacji Problem zapisu danych przestrzennych powsta³ równoczeœnie z pierwszymi systemami typu GIS w po³owie lat szeœædziesi¹tych XX w. W pierwszym okresie formy zapisu tych danych by³y œciœle zwi¹zane z konkretnymi systemami programowania i najczêœciej by³y to zapisy binarne. Jednak potrzeba wymiany danych pomiêdzy ró nymi systemami sprawi³a, e zaczêto opracowywaæ formaty niezale ne od systemów, na przyk³ad: POLYVRT (1974), ODYSSEY (1976). Nastêpny krok w tym zakresie to standardowe formaty w Stanach Zjednoczonych dla celów statystycznych (DIME i TIGER). Kolejne lata to dominacja firm Intergraph i ESRI w zakresie zapisu danych, co doprowadzi³o do powstania dojrza³ych rozwi¹zañ, ale ograniczonych tylko do ich w³asnych koncepcji technologicznych. Lata dziewiêædziesi¹te to z kolei burzliwy rozwój formatów narodowych i dalsze pog³êbianie sie problemów z wymian¹ danych pomiêdzy coraz wiêksz¹ liczb¹ ró norodnych systemów. Tendencja do nieujawniania formatów wewnêtrznych przez czo³owe firmy z tego zakresu doprowadzi³a w po³owie lat dziewiêædziesi¹tych do impasu w pracach OGC nad interoperacyjnoœci¹. Jednak kryzys ten zosta³ prze³amany i w roku 1998 Ron Lake zainicjowa³ prace w OGC nad jêzykiem GML. By³ to radykalny zwrot w zakresie zapisu danych geoprzestrzennych, poniewa zastosowanie zapisu znacznikowego XML pozwoli³o na wprowadzenie niezbêdnej elastycznoœci i rozszerzalnoœci sposobu zapisu ró norodnych rodzaj danych stosowanych w ró nych dziedzinach. Prekursorem ca³ej rodziny jêzyków GML by³ jêzyk SFXML (Simple Features XML) opracowany i opublikowany w roku Od tej pory znacznikowy zapis danych geoprzestrzennych (2.12) jest dominuj¹cy i kolejne lata przynosz¹ nowe bardziej dojrza³e i bardziej rozbudowane jego wersje. Na bazie tego jêzyka powsta³o od tego czasu wiele aplikacji dziedzinowych, a tak e dziedzinowych jêzyków pochodnych, które równie s³u ¹ jako baza dla dalszych aplikacji (rys. 2.13). Rys Drzewo genealogiczne jêzyka GML

23 2. RÓ NICE POMIÊDZY JÊZYKIEM ZAPISU DANYCH I JEGO DZIEDZINOW APLIKACJ 25 Rys Hierarchiczna struktura jêzyków i nierozszeralnych schematów aplikacyjnych dla nauk o Ziemi, w tym geologii i hydrogeologii (Michalak i in., 2011). Objaœnienia w tekœcie. Jednak w tym szybkim i burzliwym rozwoju jêzyka GML mo na zaobserwowaæ niepokoj¹ce zjawiska. Ponownie pojawi³ siê problem z rozwi¹zaniami narodowymi, szczególnie w zakresie danych topograficznych. Z tego powodu interoperacyjne ³¹czenie danych topograficznych z s¹siednich krajów jest bardzo trudne, a czasem niemo liwe. Mo na z przek¹sem powiedzieæ, e dziêki ujednoliconej symbolice kartograficznej interoperacyjnoœæ tradycyjnych map papierowych by³a wiêksza, poniewa mapy z krajów s¹siaduj¹cych mo na by³o z powodzeniem sklejaæ. Inny problem zwi¹zany z aplikacjami dziedzinowymi GML to opracowywanie w ró nych oœrodkach schematów aplikacyjnych dla tych samych zastosowañ. To równie prowadzi do problemów z zakresu interoperacyjnoœci oraz wykazuje niedojrza³oœæ w podejmowaniu takich przedsiêwziêæ Jêzyki oparte na GML i z nim powi¹zane Cech¹ specyficzn¹ dla aplikacji XML, a w tym przypadku bazuj¹cych tak e na jêzyku GML, jest mo liwoœæ tworzenia hierarchicznych struktur aplikacyjnych. Rysunek 2.13 przedstawia przyk³ad takiej struktury z zakresu danych w obszarze nauk o Ziemi. Kolejne schematy aplikacyjne s¹ coraz bardziej wyspecjalizowane i dedykowane coraz wê szemu zakresowi tematycznemu. Baz¹ s¹ w takich przypadkach jêzyki (na przyk³ad XML i GML), a na samej górze wystêpuj¹ œciœle ograniczone i jednoznacznie wyspecyfikowane schematy aplikacyjne do dok³adnie okreœlonych zastosowañ, najczêœciej ju dalej nierozszerzalne. W takiej strukturze hierarchicznej czêsto jest trudno dok³adnie okreœliæ, co jest jeszcze jêzykiem, a co ju nierozszerzalnym schematem aplikacyjnym. Na rysunku 2.13 strza³ki pionowe okreœlaj¹ zale noœci pomiêdzy poszczególnymi aplikacjami, na przyk³ad jêzyk GWML (Boisvert, Brodaric, 2008) wykorzystuje elementy zdefiniowane w jêzyku GeoSciML (IGW-CGI-IUGS, 2008) i w jêzyku GML (Michalak, 2005b). Strza³ki poziome przypisuj¹ poszczególnym aplikacjom przestrzenie nazw elementów, na przyk³ad schematy specyfikacji danych tematu Geologia (Geology) dyrektywy INSPIRE definiuj¹ elementy z przestrzeni geo:. Jedn¹ z generalnych zasad dotycz¹cych jêzyków jest pozostawianie du ej swobody w okreœlaniu typów elementów, dla których s¹ zdefiniowane hierarchiczne struktury dziedziczenia. Mo e to na przyk³ad dotyczyæ wektorowych atrybutów geometrycznych dla wyró -

24 26 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... nieñ (feature) i przyk³ad takiej struktury przedstawiony jest w rozdziale 9.1 (rys. 9.2) lub atrybutów geometrycznych dla pokryæ (coverage), co przedstawia rysunek 9.5 w rozdziale 9.2. W takich przypadkach w jêzyku powinno siê specyfikowaæ typ po³o ony mo liwie najwy ej w drzewie hierarchicznym, aby w schemacie aplikacyjnym mo na by³o wybraæ stosowny w danym przypadku i najczêœciej jedyny typ le ¹cy poni ej. Inny przyk³ad pozostawienia du ej swobody to proste typy danych okreœlane dla elementów prostych. Poniewa jêzyk jest w pewnym sensie szablonem dla opracowywania œcis³ych aplikacji, zadeklarowanie typu prostego jako Any (dowolny) lub AnyType daje du ¹ swobodê w dostosowaniu tego elementu do okreœlonych potrzeb aplikacyjnych przez podstawienie dowolnego typu prostego po³o onego ni ej w hierarchii, na przyk³ad: m characterstring dla dowolnego ci¹gu znaków, najczêœciej kodu lub tekstu bez okreœlenia jêzyka, m localizedcharacterstring dla tekstu z okreœleniem jêzyka w atrybucie, m PT_FreeText dla sekwencji elementów typu localizedcharacterstring, gdy jest to w kilku jêzykach (przyk³ad 2.1 w rozdziale 2.1), m mog¹ to tak e byæ dowolne typy liczbowe: integer, unsignedinteger, float lub double, a tak e bardziej ogólny decimal, m równie inne proste typy, jak date, datetime lub boolean. Przyk³ad hierarchii prostych typów zdefiniowanych (built-in) w jêzyku XML przedstawia rysunek Rys Hierarchia prostych typów wbudowanych (built-in) w jêzyku XML (Biron, Permanente, Malhotra, 2004). Objaœnienia w tekœcie.

25 2. RÓ NICE POMIÊDZY JÊZYKIEM ZAPISU DANYCH I JEGO DZIEDZINOW APLIKACJ 27 Rys Fragment diagramu elementów schematu WGML utworzonego za pomoc¹ programu XML SPY. Objaœnienia w tekœcie. W konkretnej specjalizowanej do okreœlonych potrzeb aplikacji stosowanie typów ogólnych jest niepoprawne, poniewa powoduje to niejasnoœæ i brak precyzji, co z kolei prowadzi do dowolnoœci wyboru typu w zapisach danych okreœlonych schematem aplikacyjnym i jest przyczyn¹ b³êdów. Znacznie utrudnia to lub uniemo liwia interpretacjê takich zapisów i stwarza powa ne problemy z zakresu interoperacyjnoœci. Jest tak e szereg innych przypadków, w których obowi¹zuj¹ inne zasady dla jêzyka i inne dla specjalizowanej aplikacji. Miêdzy innymi dotyczy to stosowania w jêzykach szablonów (templete), na przyk³ad w jêzyku GeoSciML do takich szablonów nale ¹: ScopedName,ControlledConcept, LocalizableGenericName i CGI_Term (rys w rozdziale 11). Mo liwoœæ korzystania z elementów zdefiniowanych w ró nych jêzykach w specjalizowanej dla danych zastosowañ aplikacji jest bardzo cenn¹ zalet¹ zapisu znacznikowego. Pozwala to na ³¹czenie typów elementów (pozycji s³ownikowych) z ró nych dziedzin w jednej aplikacji, która przez to mo e mieæ charakter interdyscyplinarny. Przyk³ad takiego ³¹czenia przedstawia rysunek Element z³o ony HydrogeologicalDescription zawiera elementy z dwóch jêzyków: gsml:permeability i gsml:porosity z jêzyka GeoSciML oraz równie gwml:capacity, gwml:hydraulicconductivity i gwml:storativity z jêzyka GroundWaterML Przysz³oœæ jêzyka GML W rozdziale 2.3 przedstawiono historiê jêzyka GML. Kolejne wersje przedstawione na rysunku by³y coraz bardziej dojrza³e, rozbudowane i uniwersalne. Pozwala³y na zapis prawie wszystkich typów danych okreœlonych w normach grupy ISO z uwzglêdnieniem specyficznych wymogów ró norodnych dziedzin zastosowañ. W pracach nad rozwojem tego jêzyka przyk³adano szczególn¹ wagê do tego, aby by³ on rozszerzalny i elastyczny. Jednak, aby móg³ byæ skutecznie implementowany na ró nych platformach konieczne by³o okreœlenie wielu ograniczeñ przedstawionych w aneksie Do normy ISO 19136, specyfikuj¹cym regu³y transformacji modelu UML do schematów XSD.

26 28 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Rys Przyk³ad problemów z zastosowaniem jêzyka GML niekoñcz¹ce siê zagnie d enie elementów _FeatureCollection. Objaœnienia w tekœcie. Jednak praktyka wykaza³a, e ci¹g³e rozbudowywanie stosunkowo prostego na pocz¹tku jêzyka GML prowadzi do stopniowo rosn¹cych trudnoœci z jego implementacjami w konkretnych systemach programowych. Do chwili obecnej adne oprogramowanie geoinformacyjne obs³uguj¹ce ten jêzyk nie ma zaimplementowanej pe³nej wersji GML 3.2.1, a te, które maj¹ j¹ zaimplementowan¹ czêœciowo równie maj¹ problemy z interoperacyjnoœci¹. Zapisy generowane przez jedne systemy nie s¹ poprawnie przyjmowane przez inne. D¹ enie do jak najdalej posuniêtej uniwersalnoœci i elastycznoœci rodzi tak e wiele problemów. Przyk³adem s¹ nieskoñczone wzajemne zagnie d enia elementów: krzywa (Curve) jako typ geometrii jest podtypem krzywej abstrakcyjnej AbstractCurve), która to mo e mieæ tak e podtyp krzywa z³o ona (CompositeCurve), który z kolei sk³ada siê z elementów sk³adniki krzywej (curvemember) zawierajce typ krzywa abstrakcyjna (AbstractCurve), która jak wczeœniej mo e mieæ podtyp krzywa z³o ona (CompositeCurve) i tak w nieskoñczonoœæ. Inny przyk³ad nieskoñczonego zagnie d enia przedstawia rysunek W tym przypadku element _FeatureCollection mo e zawieraæ elementy typu FeatureMember, których sk³adnikami mog¹ byæ ponownie elementy typu _FeatureCollection, co w sposób oczywisty prowadzi do nieskoñczonego zagnie d enia. W wielu przypadkach nie powoduje to powa nych b³êdów zapisu, jednak stwarza realne zagro enie zapêtlenia siê procedury kodowania zbioru danych lub jego interpretacji. Wymownym przyk³adem jest generowanie plików testowych zapisu danych GML na podstawie rozpatrywanego pliku XSD definiuj¹cego elementy schematu aplikacyjnego GML. Problemy implementacyjne jêzyka GML sta³y siê przyczyn¹ coraz czêstszych opinii krytycznych. G³êbsze zapoznanie siê z tymi g³osami krytycznymi wskazuje, e s¹ uzasadnione. Zespó³ roboczy OGC zajmuj¹cy siê rozwojem jêzyka GML zainicjowa³ otwart¹ dyskusjê nad podstawowymi problemami, jakie powinny byæ rozwi¹zane w nowej wersji tego jêzyka, która bêdzie oznaczona jako 4.0 (Burggraf, 2011). Równolegle do tych dzia³añ prowadzone

27 2. RÓ NICE POMIÊDZY JÊZYKIEM ZAPISU DANYCH I JEGO DZIEDZINOW APLIKACJ 29 by³y prace nad uzupe³nieniem obecnej oficjalnej wersji w zakresie wczeœniej zg³oszonych uwag. Na pocz¹tku roku 2012 zosta³a opublikowana nowa wersja 3.3. Jest to jednak tylko rozszerzenie wersji poprzedniej i nie zmienia istotnie funkcjonalnoœci ca³ego jêzyka: m wprowadzono dwa nowe typy proste: LanguageString i TimePositionUnion; m m m m elementy geometryczne zosta³y rozszerzone o typy uproszczone: SimplePolygon, SimpleRectangle, SimpleTriangle, SimpleArcString, SimpleArc, SimpleArcByCenterPoint, SimpleArcStringByBulge, SimpleArcBy- Bulge, SimpleCircle, SimpleCircleByCenterPoint, SimpleMulti- PointType i MultiPointProperty; dodano schemat aplikacyjny dla siatek trójk¹tnych (TIN), w tym elementy: TriangulatedSurface, SimpleTrianglePatch, TIN, TINElement, TINElementProperty i TINElementType; dodano schemat dla uk³adów odniesieñ liniowych z elementami: PositionExpression z PositionExpressionProperty, LinearElement z LinearElementProperty, StartValue, LinearReferencingMethod z LinearReferencingMethodProperty, DistanceExpression z DistanceExpressionProperty, AlongReferent z AlongReferentProperty, Referent z ReferentProperty, Measure, LRMName z LRMType, ReferentType, LinearSRS z LinearSRSProperty, DualAlongReferent z DualAlongReferentProperty, LRMWithOffset z LRMWithOffsetProperty, LateralOffsetDistanceExpression, VerticalOffsetExpression, LateralOffsetDirection, VerticalOffsetDirection, LateralOffsetLinearSRS z LateralOffsetLinearSRSProperty, VectorOffsetDistanceExpression, VectorOffsetExpression, VectorOffsetLinearSRS; uzupe³niono pakiet dla pokryæ o schematy dla nietypowych siatek, dla których mo e byæ okreœlone odniesienie przestrzenne, w tym elementy: AbstractReferenceableGrid z ReferenceableGridProperty, ReferenceableGridByArray, ReferenceableGridByVectors, ReferenceableGridByTransformation i gridcrs z GridCRSProperty. Zasadnicze zmiany w jêzyku GML s¹ zapowiadane w wersji 4.0. Bêd¹ dotyczy³y g³ównie modularyzacji ca³oœci tak, aby mo na by³o dla konkretnych zastosowañ wybraæ tylko potrzebne modu³y, a nie jak jest to obecnie, e w ka dym przypadku musz¹ byæ zastosowane wszystkie schematy GML, poniewa ich wzajemne powi¹zanie tego wymaga. Proponowany podzia³ na modu³y zosta³ przedstawiony nastêpuj¹co: gmlcoreprofile, gmlmeasuresprofile, gml2dfeatureprofile, gml3dfeatureprofile, gmldictionaryprofile, gmlcrsprofile, gmlgrid- CoverageProfile, gmlallcoverageprofile, gmlobservationsandmeasurementsprofile, gml- TemporalProfile i gmldynamicfeatureprofile. Druga istotna zmiana w koncepcji organizacji jêzyka GML to opracowanie wielu profili (zawê eñ) maj¹cych za zadanie tak e znaczne ograniczenie objêtoœci schematów i liczby elementów wykorzystywanych w ró nych zastosowaniach praktycznych. Proponowane s¹ nastêpuj¹ce kategorie profili: m trzy grupy profili dla wyró nieñ (features) Profile Schemas for Restricted Feature Data (dla danych o ograniczonym dostêpie), Profile Schemas for NSDI Foundation Data (dla podstawowych danych w infrastrukturach) i Profile Schemas for NGA Product (dla produktów s³u b geodezyjnych);

28 30 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... m dwie grupy profili dla geometrii Profile Schemas for Geometries (geometrie bez topologii) i Profile Schemas for Topology and Geometry (geometrie z topologi¹); m dwie grupy profili dla pokryæ (coverages) Profile Schemas for Grid Coverages (w³¹cznie z ortoobrazami) i Profile Schemas for Non-Grid Coverages (dla pokryæ innych ni siatkowe); m dwie grupy profili dla uk³adów odniesienia i transformacji danych miêdzy uk³adami: Profile Schemas for Coordinate Reference Systems (w zakresie definicji uk³adów) i Profile Schemas for Coordinate Operations (w zakresie transformacji wspó³rzêdnych); m grupa profili dla us³ug sieciowych Profile Schemas for Specific OGC Services; m grupa profili w zakresie metadanych Profile Schemas for ISO Mo na oczekiwaæ, e planowane zmiany organizacyjne w GML 4.0 wyeliminuj¹ obecn¹ sytuacjê, w której musimy siê pos³ugiwaæ wielkim i ciê kim monolitem w ka dym zastosowaniu, nawet najprostszym Modele UML dedykowane zapisom w jêzyku GML Tematem monografii jest transformacja modeli danych zapisanych w UML do form przyjêtych w GML i bazach danych. Zak³ada siê, e takie modele ju istniej¹ i s¹ opracowane poprawnie pod wzglêdem merytorycznym i formalnym, a tak e spe³niaj¹ wymagania niezbêdne do wykonania takiej transformacji. Bardzo czêsto jednak tak nie jest i wiêcej szczegó- ³owych problemów z tego zakresu jest przedstawione w rozdzia³ach 9 i 11. Z tego wzglêdu trzeba przedstawiæ podstawowe zasadny opracowywania modelu danych w UML i szerszy kontekst technologii modelowania danych geoprzestrzennych. W roku 1998 w g³ównych centrach œwiatowych zajmuj¹cych siê geoinformacj¹, w Open Geospatial Consortium (wtedy jeszcze Open GIS Consortium) i w komitecie technicznym ISO/TC 211 podjêto decyzjê o zastosowaniu jêzyka UML do opisu modeli danych. Wkrótce Rys Przyk³ad podwójnego dziedziczenia, które nie mo e byæ zaimplementowane w schemacie aplikacyjnym XSD jêzyka GML. Przyk³ad pochodzi z normy ISO (ISO/TC 211, 2002b) i dotyczy topologii czasu.

29 2. RÓ NICE POMIÊDZY JÊZYKIEM ZAPISU DANYCH I JEGO DZIEDZINOW APLIKACJ 31 zdefiniowano profil tego jêzyka do geoinformacji i od tej pory wszystkie specyfikacje, standardy i normy pos³uguj¹ siê tym jêzykiem do okreslania struktur danych przestrzennych. W tym czasie jeszcze nie myœlano o powszechnym zastosowaniu zapisu danych w postaci znacznikowej na bazie XML pierwsze prace nad tym zainicjowano w OGC w roku 1999, co bardziej szczegó³owo opisano w rozdziale 2.3. D³ugo jeszcze w latach nastêpnych powstawa³y tam modele nie uwzglêdniaj¹ce wymagañ transformacji do jêzyka GML. Wiele oficjalnych dokumentów standaryzacyjnych OGC i norm ISO, które powsta³y w tamtym okresie i s¹ nadal stosowane pos³uguje siê profilem UML zawieraj¹cym konstrukcje niemo - liwe do przeniesienia do jêzyka GML. Do tej kategorii nale y wielokrotne dziedziczenie, którego przyk³ad przedstawia rysunek Podstawowe elementy jêzyka UML stosowane w opisie modeli danych geoprzestrzennych s¹ wyszczególnione na rysunku Jednak czêœæ przedstawionych elementów i konstrukcji nie mo e lub nie powinna byæ stosowana w przypadku, gdy model ma byæ transformowany do schematu XSD dla jêzyka GML. Nale ¹ do nich: m operacje wyszczególnione w trzeciej od góry sekcji graficznego symbolu klasy (poni- ej sekcji atrybutów), poniewa nie maj¹ znaczenia w opisie struktur danych, m ograniczenia (constrains) zarówno w OCL (Object Constrain Language), jak i w innej formie, poniewa nie s¹ transformowalne do GML, m podwójne (i wielokrotne) dziedziczenia nie maj¹ swojego odpowiednika w aplikacjach XML, m wszelkiego typu klasy interfejsowe i asocjacyjne równie nie mog¹ byæ odwzorowane w GML, m powi¹zania pomiêdzy klasami typu realizacja lub zale noœæ nie maj¹ odpowiednika w XML, m stosowanie agregacji stwarza trudnoœci implementacyjne i praktycznie we wszyst- m kich przypadkach mo e byæ zast¹pione asocjacj¹ jedno- lub dwukierunkow¹, kompozycje mog¹ byæ równie zastêpowane asocjacjami, jednak w takim przypadku nie mo e byæ zagwarantowana koniecznoœæ usuwania elementów sk³adowych, gdy zostaje ze zbioru danych usuniêty element g³ówny w takim przypadku mo na to zast¹piæ atrybutem typu klasa sk³adowa w klasie g³ównej. Jêzyk UML jest okreœlany jako graficzny jêzyk do obrazowania, specyfikowania tworzenia i dokumentowania elementów systemów informatycznych (Booch, Rumbaugh i Jakobson, 2002). W opisywanej problematyce zastosowanie jêzyka UML jest ograniczone jedynie do modeli danych. Trzeba wyraÿnie podkreœliæ, e jêzyk UML nie jest jedynie notacj¹ graficzn¹. Graficzne diagramy tego jêzyka przedstawiaj¹ tylko najwa niejsze elementy modelu (czêœæ lewa rysunku 2.19), a wiele szczegó³ów modelu pojêciowego nie jest na diagramach bezpoœrednio widoczna. Aby je przeczytaæ lub edytowaæ oprogramowanie narzêdziowe jêzyka UML pozwala na otworzenie dodatkowego okna tekstowego (czêœæ prawa rysunku 2.19). W zastosowaniach dotycz¹cych geoinformacji wprowadzono szereg regu³, miedzy innymi w zakresie stosowania nazw w modelach i schematach XSD. Zasady te s¹ istotne, szczególnie w przypadku infrastruktury INSPIRE, gdzie wystêpuje problem wielojêzycznoœci, zarówno w aspekcie danych, jak i w aspekcie us³ug sieciowych zwi¹zanych z tymi danymi. W myœl tych zasad nazwy klas danych, typów danych, atrybutów i elementów wystêpuj¹cych w zapisach w jêzyku UML, XML i jego aplikacjach s¹ s³owami kluczowymi w sensie informatycznym. Z tego wzglêdu w ka dym przypadku zachowuje siê ich dok³adn¹ pisowniê w jêzyku angielskim. Nazwy wielowyrazowe pisane s¹ tak zwanym wielb³¹dem (CamelCase), to znaczy nazwy wielowyrazowe s¹ pisane bez przerw (spacji) i poszczególne

30 32 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... mo e istnieæ bez klasy C. Rys Notacja graficzna diagramów klas UML w zakresie profilu ISO dla modeli pojêciowych danych geoprzestrzennych (Michalak, 2003a).

31 2. RÓ NICE POMIÊDZY JÊZYKIEM ZAPISU DANYCH I JEGO DZIEDZINOW APLIKACJ 33 Rys Przyk³ad modelu danych geoprzestrzennych w UML. Po lewej przyk³ad diagramu klas modelu danych geoprzestrzennych. Po prawej okno w³aœciwoœci elementu modelu przedstawiaj¹ce jedynie czêœæ elementów niewidocznych na diagramie (Michalak i inni, 2011). m wyrazy zaczynaj¹ siê od du ej litery. Nazwy klas, typów i elementów rozpoczynaj¹ siê du ¹ liter¹, a pozosta³e ma³¹ na przyk³ad: ToJestNazwaKlasy, a tojestnazwaatrybutu. Czêsto dla lepszej czytelnoœci akronimy wystêpuj¹ce w nazwach oddzielane s¹ podkreœleniem (underscore), na przyk³ad CGI_Term termin z zakresu nazw stosowanych przez CGI (Commission for the Management and Application of Geoscience Information). Modele danych, w tym tak e geoprzestrzennych, s¹ najczêœciej opracowywane na dwóch poziomach ogólnoœci: m modele pojêciowe niezale ne od platformy implementacyjnej okreœlane akronimem PIM (Platform-Independent Model), czêsto tak e nazywane modelami abstrakcyjnymi, na przyk³ad w specyfikacjach abstrakcyjnych OGC, modele dedykowane okreœlonym platformom (PSM Platform-Specific Model), na przyk³ad zapisom znacznikowym w jêzykach XML i GML, jêzykom programowania C++ lub Java albo relacyjnym lub obiektowym bazom danych. Wiêcej na temat tych dwóch kategorii modeli w ujêciu metodyki MDA (Model-Driven Architecture) zawieraj¹ rozdzia³y 3 i 10. Tu warto jeszcze zwróciæ uwagê na ró ne podejœcia do transformacji modelu abstrakcyjnego (PIM) do modelu dedykowanego okreœlonej platfor-

32 34 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... mie (PSM). Aby model niezale ny (PIM) przekszta³ciæ w model zale ny od platformy (PSM) trzeba w nim dokonaæ zmian. Koniecznoœæ tych zmian wynika z ograniczeñ, jakie narzuca ta platforma. Inne ograniczenia s¹ niezbêdne w przypadku relacyjnej bazy danych, a inne w przypadku znacznikowego zapisu danych na bazie XML. W rezultacie oba modele wynikowe mog¹ siê znacznie ró niæ, chocia zamiar by³ taki, aby by³y do siebie jak najbardziej podobne. Czêsto transformacja modelu PIM do modelu PSM jest tak g³êboka, e proces ten nale y traktowaæ jako nieodwracalny, poniewa pewne elementy modelu lub jego konstrukcje s¹ tracone, a ponadto podczas transformacji powstaj¹ nowe elementy i konstrukcje. Dobitnym tego przyk³adem jest jêzyk GML. Specyfikacja tego jêzyka (Portele, 2007 lub ISO/TC 211, 2007a) zawiera wskazówki i regu³y transformacji wprost (UML do GML aneks E) i odwrotnej (GML do UML aneks F), jednak transformacja odwrotna (nazywana tak e in ynieri¹ odwrotn¹) jest tak trudna, e nie s¹ znane przypadki jej zastosowania. Rysunek 2.20 przedstawia wynik transformacji odwrotnej wykonanej w sposób zgodny z ogólnie przyjêtymi regu³ami w metodyce opartej na jêzyku UML. Uzyskany t¹ drog¹ wynik jest zupe³nie ró ny, ni pierwotna Ÿród³owa postaæ modelu danych, na której podstawie uzyskano schemat aplikacyjny XSD jêzyka GML. W rozdziale tym przedstawionych jest tylko kilka wybranych najwa niejszych problemów dotycz¹cych wymagañ jêzyka GML w stosunku do modeli danych w jêzyku UML. Inne przyk³ady s¹ opisane w rozdzia³ach 9 i 11. Rys Przyk³ad zastosowania in ynierii odwrotnej odtworzenie modelu danych UML na podstawie schematu XSD jêzyka GML. W przyk³adzie wykorzystano jeden ze schematów tematu INSPIRE: Gospodarowanie obszarem, strefy ograniczone i regulacyjne oraz jednostki sprawozdawcze (Area management/ restriction/ regulation zones and reporting units).

33 3. WPROWADZENIE DO MODELOWANIA INFORMACJI PRZESTRZENNEJ METODYKA MDA I DIAGRAMY KLAS UML POLSKIE TOWARZYSTWO INFORMACJI PRZESTRZENNEJ ROCZNIKI GEOMATYKI 2012 m TOM X m ZESZYT 1(51) 35 Agnieszka Chojka 3. Wprowadzenie do modelowania informacji przestrzennej metodyka MDA i diagramy klas UML Perspektywa danych 3.1 Wprowadzenie Infrastrukturê danych przestrzennych mo na rozpatrywaæ pod k¹tem danych lub us³ug. Perspektywa danych (data-centric view) dotyczy g³ównie schematów aplikacyjnych i metadanych, a perspektywa us³ug (service-centric view) koncentruje siê przede wszystkim na idei interoperacyjnoœci i architekturze zorientowanej na us³ugi. Z perspektyw¹ danych zwi¹zane jest podejœcie oparte na modelu MDA (Model Driven Approach), gdzie niezale ny od implementacji schemat aplikacyjny zostaje odwzorowany na ró ne specyfikacje (wykorzystuj¹ce ró ne technologie, np. us³ugi sieciowe, relacyjne bazy danych, XML), a te z kolei mog¹ zostaæ zaimplementowane (wdro one) na ró nych platformach sprzêtowo-programowych (rys. 3.1). Rys Podejœcie oparte na modelu: pojêciowym, logicznym i fizycznym (CEN, 2006).

34 36 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Podejœcie oparte na modelu (pojêciowym, logicznym i fizycznym) wykorzystuje koncepcjê MDA opracowan¹ przez miêdzynarodow¹ organizacjê OMG (Object Management Group), której celem jest rozwi¹zywanie problemów zwi¹zanych z integracj¹ systemów informatycznych pochodz¹cych od ró nych dostawców oraz dzia³aj¹cych na ró nych platformach informatycznych (wykorzystuj¹cych ró ne technologie, np. ró ne systemy operacyjne, ró ne standardy sieciowe, ró ne jêzyki programowania). MDA wyró nia cztery, coraz bardziej szczegó³owe, modele systemu: m CIM (Computation Independent Model) model stanowi¹cy specyfikacjê wymagañ funkcjonalnych i niefunkcjonalnych systemu, m PIM (Platform Independent Model) model pojêciowy niezale ny od platformy sprzêtowo-programowej (definiuje pojêcia z okreœlonej dziedziny problemu), m PSM (Platform Specific Model) model logiczny zale ny od wybranej platformy m sprzêtowo-programowej, czêsto tak e nazywany modelem implementacyjnym, Implementacja (Implementation) system fizyczny np. dzia³aj¹cy program zapisany w konkretnym jêzyku programowania, struktura bazy danych i tym podobne. Kluczow¹ rolê w technologii MDA odgrywa modelowanie systemu w jêzyku UML (Unified Modeling Language), który jest równie zalecanym przez normy ISO serii jêzykiem schematu pojêciowego (conceptual schema language). UML to œrodek formalny modelowania informacji (tak e geograficznej), który umo liwia zapis informacji geograficznej (struktur danych przestrzennych) w sposób niezale ny od platform sprzêtowo-programowych (w tym systemów geoinformacyjnych), zapewniaj¹c dziêki temu interoperacyjnoœæ miêdzy ró - nymi systemami geoinformacyjnymi. Schemat aplikacyjny Celem norm ISO serii jest zapewnienie interoperacyjnoœci miêdzy ró norodnymi systemami geoinformacyjnymi (systemami informacji geograficznej, systemami informacji przestrzennej). Interoperacyjnoœæ to zdolnoœæ do wspó³dzia³ania, a wiêc miêdzy innymi zdolnoœæ do komunikowania, a co za tym idzie dokonywania transferu danych miêdzy systemami. Aby osi¹gn¹æ interoperacyjnoœæ miêdzy ró nymi systemami wymagane jest zdefiniowanie: m semantyki zawartoœci i struktur logicznych danych przestrzennych tzw. schemat m aplikacyjny (application schema), struktury danych niezale nej od platformy sprzêtowo-programowej struktury danych, która mo e reprezentowaæ dane zgodnie ze schematem aplikacyjnym. Schemat aplikacyjny to schemat pojêciowy (conceptual schema) dla danych wykorzystywanych przez jedn¹ lub wiêcej aplikacji komputerowych (element oprogramowania u ytkowego), dla okreœlonej dziedziny problemowej. Schemat pojêciowy to formalny opis modelu pojêciowego (conceptual model) w okreœlonym jêzyku schematu pojêciowego, a model pojêciowy to model definiuj¹cy pojêcia z pewnej przestrzeni rozwa añ (przedmiotu zainteresowañ). Schemat aplikacyjny stanowi podstawê pomyœlnej wymiany danych, definiuje mo liw¹ zawartoœæ oraz strukturê danych. Schemat aplikacyjny stosowany do wymiany danych powinien byæ zapisany w jêzyku schematu pojêciowego UML, zgodnie z normami ISO/TS i ISO (okreœlaj¹ one zasady zapisu schematów aplikacyjnych). Taki schemat aplikacyjny powinien byæ dostêpny dla obu uczestników procesu wymiany danych (nadawcy i odbiorcy), aby zapewniæ jego pomyœlny przebieg.

35 3. WPROWADZENIE DO MODELOWANIA INFORMACJI PRZESTRZENNEJ METODYKA MDA I DIAGRAMY KLAS UML 37 Interoperacyjna wymiana danych Ogóln¹ ideê wymiany danych przedstawia rysunek 3.2. Zagadnienie polega na przes³aniu zbioru danych z systemu A do systemu B. W celu zapewnienia pomyœlnej wymiany danych miêdzy systemami A i B nale y zdecydowaæ: m o wspólnym schemacie aplikacyjnym I, m jak¹ zastosowaæ regu³ê kodowania R, m jaki wykorzystaæ rodzaj protoko³u transferu. Schemat aplikacyjny jest podstaw¹ udanego transferu danych. Definiuje on mo liw¹ zawartoœæ oraz strukturê przesy³anych danych. Regu³a kodowania okreœla regu³y konwersji ustalaj¹ce jak kodowaæ dane na strukturê danych niezale n¹ od systemu. Oba systemy, A i B, przechowuj¹ dane w wewnêtrznych bazach danych zgodnie ze swoimi wewnêtrznymi schematami i zazwyczaj te schematy s¹ ró ne. Zatem, przeniesienie zbioru danych z wewnêtrznej bazy danych systemu A do wewnêtrznej bazy danych systemu B, musi przebiegaæ w nastêpuj¹cy sposób: m nale y przet³umaczyæ wewnêtrzne dane systemu A na strukturê danych zgodn¹ ze wspólnym schematem aplikacyjnym I wynikiem tego dzia³ania jest schemat aplikacyjny okreœlonej struktury danych i A, m m m m m trzeba wykorzystaæ us³ugê kodowania, która stosuje regu³ê kodowania R do stworzenia struktury danych d niezale nej od systemu, a wiêc odpowiedniej do transferu, z poziomu systemu A nale y wywo³aæ us³ugê transferu, aby przes³aæ zakodowany zbiór danych d do systemu B, us³uga transferu w systemie B odbiera przesy³any zbiór danych, stosuj¹c odwrotn¹ regu³ê kodowania R 1 z poziomu systemu B otrzymywany jest schemat aplikacyjny okreœlonej struktury danych i B, nale y przet³umaczyæ schemat aplikacyjny okreœlonej struktury danych i B na wewnêtrzn¹ bazê danych systemu B. Jednak w przypadku du ych ró nic pomiêdzy wewnêtrznymi modelami obu systemów, istnieje mo liwoœæ przes³ania jedynie czêœci wspólnej dla obu zbiorów danych. Regu³y kodowania Obecnie normy ISO serii okreœlaj¹ dwie regu³y kodowania oparte na jêzyku XML (ang. Extensible Markup Language): m ISO (GML), Za³¹cznik E okreœla regu³ê kodowania opart¹ na XML dla schematów aplikacyjnych zgodnych z norm¹ ISO 19109, które mog¹ byæ przedstawione za pomoc¹ ograniczonego profilu UML, pozwalaj¹cego na konwersjê do jêzyka XML Schema, m ISO/TS okreœla regu³ê kodowania opart¹ na XML dla schematów pojêciowych okreœlaj¹cych typy, które opisuj¹ zasoby danych geograficznych, np. metadane wed³ug normy ISO i katalogi obiektów wed³ug normy ISO Regu³a kodowania powinna okreœlaæ regu³y konwersji schematu (logicznych struktur danych) oraz regu³y konwersji instancji (konkretnych danych) (rys. 3.3). Regu³y konwersji oparte na jêzyku XML dla neutralnej wymiany danych zak³adaj¹, e definicje klas w schemacie aplikacyjnym s¹ odwzorowywane na deklaracje typów elementów w schemacie XML (logiczna struktura danych zapisana w XML Schema), a obiekty w modelu instancji (konkretne dane) s¹ odwzorowywane na odpowiadaj¹ce im struktury elementów w dokumencie XML.

36 38 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Rys Ogólna idea wymiany danych miêdzy dwoma systemami (CEN, 2006).

37 3. WPROWADZENIE DO MODELOWANIA INFORMACJI PRZESTRZENNEJ METODYKA MDA I DIAGRAMY KLAS UML 39 Rys Regu³a kodowania oparta na XML (ISO/TC 211, 2011) Regu³y budowy schematów aplikacyjnych w UML Schemat aplikacyjny powinien byæ zapisany w jêzyku schematu pojêciowego UML wed³ug zasad okreœlonych w standardach ISO/TS i ISO Schemat aplikacyjny sk³ada siê z pojêæ okreœlonych przez dziedzinê zastosowañ wyra onych jako klasy i powi¹zania. Niektóre z klas mog¹ byæ zaimportowane ze schematów znormalizowanych z innych standardów, tzn. schemat aplikacyjny opracowany przez u ytkownika, poza klasami opisuj¹cymi dan¹ dziedzinê zastosowañ, mo e dodatkowo zawieraæ klasy pochodz¹ce ze schematów aplikacyjnych zdefiniowanych w normach ISO serii lub innych dokumentach standaryzacyjnych. Norma ISO Norma ISO podaje ogólne regu³y budowy i dokumentowania schematów aplikacyjnych, w tym zasady modelowania pojêciowego obiektów oraz ich w³aœciwoœci, regu³y definiowania schematu aplikacyjnego za pomoc¹ jêzyka schematu pojêciowego, wyra anie pojêæ z modelu pojêciowego w postaci typów danych w schemacie aplikacyjnym oraz zasady integracji schematu aplikacyjnego ze znormalizowanymi schematami pojêciowymi informacji geograficznej. Istot¹ normy ISO jest definicja obiektu geograficznego (geographic feature), który reprezentuje wyodrêbniony element (zjawisko) œwiata rzeczywistego, powi¹zany z powierzchni¹ Ziemi. Obiekt mo e wystêpowaæ jako typ (wzorzec obiektu) lub jako instancja (konkretny egzemplarz obiektu). W sytuacji, gdy rozpatrywane jest tylko jedno z powy - szych wyst¹pieñ pojêcia, nale y u ywaæ odpowiednio pojêæ: typ obiektu lub instancja obiektu. Przyk³adem obiektu geograficznego mo e byæ budynek, s³upek graniczny dzia³ki, drzewo, obraz satelitarny. Aby zintegrowaæ typ obiektu z modelem informacji geograficznej w jednorodny (homogeniczny) sposób, norma ISO definiuje General Feature Model (GFM, rys. 3.4), który opisuje abstrakcyjny typ obiektów z atrybutami i rolami w asocjacjach (w³asnoœci obiektu).

38 40 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Rys General Feature Model (GFM) wed³ug normy ISO 19109:2009 (ISO/TC 211, 2005b). Specyfikacja ISO/TS Specyfikacja techniczna ISO/TS definiuje profil UML w dziedzinie informacji geograficznej (geoinformatyki/geomatyki) dostosowany do norm ISO serii (przyjêta konwencja nazywania i modelowania pozostaje niezmienna dla ca³ej serii norm). Okreœla miêdzy innymi zasady definiowania klas, atrybutów, typów danych, operacji, zwi¹zków i stereotypów. Modele normatywne wykorzystuj¹ diagramy klas i diagramy pakietów. Inne diagramy UML mog¹ byæ stosowane w normach informacyjnie. Jêzyk UML Najwiêksz¹ rolê w modelowaniu geoinformacji odgrywaj¹ strukturalne diagramy UML, a w szczególnoœci diagramy klas. Stanowi¹ one opisy zbiorów danych i zale noœci pomiêdzy nimi. Podstawowymi elementami diagramów klas s¹: oznaczenia klas, zwi¹zków pomiêdzy nimi i ich atrybuty oraz oznaczenia pomocnicze (np. stereotypy, metki, ograniczenia itp.). Klasy mo na zorganizowaæ w pakiety. Pakiety porz¹dkuj¹ strukturê zale noœci w systemie, w który mo na wyró niæ bardzo wiele klas, przypadków u ycia i tym podobnych. Struktura pakietów przedstawia podzia³ systemu z logicznego punktu widzenia.

39 3. WPROWADZENIE DO MODELOWANIA INFORMACJI PRZESTRZENNEJ METODYKA MDA I DIAGRAMY KLAS UML 41 Poni ej przedstawiono przyk³ad diagramu klas w UML (rys. 3.5) oraz przyk³ad diagramu pakietów w UML (rys. 3.6). Rys Przyk³ad diagramu klas w UML. Rys Przyk³ad diagramu pakietów w UML.

40

41 4. PRZEGL D STANDARDÓW POLSKIE I NARZÊDZI TOWARZYSTWO STOSOWANYCH INFORMACJI DO MODELOWANIA PRZESTRZENNEJ INFORMACJI GEOGRAFICZNEJ ROCZNIKI GEOMATYKI 2012 m TOM IX m ZESZYT 1(51) 43 Agnieszka Zwirowicz-Rutkowska 4. Przegl¹d standardów i narzêdzi stosowanych do modelowania informacji geograficznej Modelowanie pojêciowe (rys. 4.1), rozumiane jako abstrakcyjne wyobra enie pewnych aspektów rzeczywistoœci, wymaga zastosowania odpowiedniej metodyki, która obejmuje zestaw pojêæ, modeli formalnych, jêzyków i sposobów postêpowania s³u ¹cych do analizy dziedziny problemowej. Metodyki (rys. 4.2) s¹ powi¹zane z okreœlonymi œrodkami formalnymi (rys. 4.3), pozwalaj¹cymi na utrwalenie wyników (wykonanie opisu formalnego) modeli pojêciowych. Proces modelowania wspieraj¹ tak e narzêdzia, które wspomagaj¹ jedn¹ metodykê, b¹dÿ umo liwiaj¹ zastosowanie zarówno notacji strukturalnych (przyp. red. nauk.: w znaczeniu metodyki baz relacyjnych), jak i obiektowych. Rys Modelowanie pojêciowe, logiczne i fizyczne dziedziny przedmiotowej (Chojka, 2006).

42 44 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Rys Typologia metodyk modelowania pojêciowego. Rys Typologia œrodków formalnych wykorzystywanych w modelowaniu pojêciowym Model dziedzinowy informacji geograficznej Rozwa aj¹c dziedzinê przedmiotow¹, jak¹ jest informacja geograficzna, nale y zwróciæ szczególn¹ uwagê na zagadnienia zwi¹zane z cechami charakterystycznymi tej e informacji oraz jej wykorzystaniem, prezentacj¹, przechowywaniem, wymian¹ i analiz¹. Spójne podejœcie do tworzenia modeli pojêciowych w dziedzinie informacji geograficznej oraz zasady i œrodki zgodnych implementacji tych modeli w zró nicowanych œrodowiskach narzêdziowych przedstawiaj¹ normy serii ISO Szczególn¹ rolê odgrywa norma ISO (ISO/TC 211, 2002a), która okreœla model odniesienia dla pozosta³ych norm, miêdzy innymi poprzez opis za³o eñ dotycz¹cych modelowania informacji geograficznej. Ponadto w grupie norm ISO 19100, które opisuj¹ formalizm modelowania pojêciowego, jest specyfikacja techniczna ISO/TS (ISO/TC 211, 2005a) dotycz¹ca jêzyka schematu pojêciowego oraz specyfikacja techniczna ISO/TS (ISO/TC 211, 2009) omawiaj¹ca zagadnienia terminologiczne w informacji geograficznej. Rys Diagram klas opisuj¹cy dziedzinê informacji geograficznej (ISO/TC 211, 2002a)

43 4. PRZEGL D STANDARDÓW I NARZÊDZI STOSOWANYCH DO MODELOWANIA INFORMACJI GEOGRAFICZNEJ 45 Aspekty informacji geograficznej, które s¹ przedmiotem normalizacji, przedstawia model dziedzinowy. Model dziedzinowy informacji geograficznej rozpatrywany jest na trzech poziomach: danych, modelu aplikacji i meta-modelu. Rysunek 4.4 przedstawia zagadnienia poziomu danych i modelu aplikacji. Na poziomie danych wyró nia siê zbiory danych, zbiory metadanych i us³ugi informacji geograficznej. Zasadnicz¹ czêœci¹ zbioru danych s¹ instancje (feature instances), o okreœlonych atrybutach, operacjach i relacjach. Przestrzenny aspekt instancji opisuj¹ obiekty przestrzenne (spatial objects), po³o one (position) w czasie i przestrzeni. Zbiór metadanych umo liwia u ytkownikom wyszukanie, ocenê, porównanie i pozyskania danych geograficznych. Us³uga informacji geograficznej pozwala wykonywaæ operacje na zbiorach danych. Poziom modelu aplikacji i meta-modelu (Ogólnego Modelu Obiektów) omówiony jest w rozdziale Funkcjonalnoœæ narzêdzi do modelowania pojêciowego Narzêdzia do modelowania pojêciowego mo na klasyfikowaæ bior¹c pod uwagê nastêpuj¹ce kryteria: m kategoria oprogramowania ze wzglêdu na mo liwoœæ rozwijania narzêdzia, dostêp do kodu Ÿród³owego; m metodyka modelowania ze wzglêdu na zaimplementowane sposoby i metody pracy nad schematami pojêciowymi; m funkcjonalnoœæ zakres dostêpnych funkcji przydatnych w modelowaniu, tworzeniu dokumentacji, a tak e intuicyjnoœæ interfejsu graficznego u ytkownika. Rysunek 4.5 przedstawia dwie zasadnicze kategorie narzêdzi do modelowania typu open source (dostêpnego wraz z kodem Ÿród³owym na ró nych licencjach, miêdzy innymi Rys Kategorie narzêdzi do modelowania pojêciowego.

44 46 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... GPL) oraz oprogramowania komercyjnego, wœród którego wyró nia siê tak e bezp³atne wersje, takie jak: freeware, shareware, community edition. Przyk³ady narzêdzi wyró nionych ze wzglêdu na metodykê modelowania przedstawia tabela 4.1. Wœród narzêdzi mo na wskazaæ zarówno te, które pozwalaj¹ modelowaæ w metodyce obiektowej, jak równie relacyjnej. Na rynku wystêpuje tak e grupa programów umo liwiaj¹cych tworzenie schematów pojêciowych w obu metodykach. Tabela 4.1. Przyk³ady narzêdzi sklasyfikowanych ze wzglêdu na metodykê modelowania Lp. Rodzaj metodyk i 1. Metodyka obiektowa 2 Metodyka relacyjn a 3 Metodyka obiektowa i relacyjn a Przyk³ady narzêdz i ArgoUML, Enterprise Architect, Rational Rose DBDesigner, Toad Data Modeler DiaCze, Visual Paradigm Znormalizowane podejœcie do modelowania informacji geograficznej zak³ada wykorzystywanie metodyki obiektowej i jêzyka UML jako formalizmu pojêciowego, który zosta³ opisany w profilu UML, w specyfikacji ISO/TS (ISO/TC 211, 2005a). Analiza funkcjonalnoœci ró nych narzêdzi do modelowania pojêciowego w metodyce obiektowej pozwala wyró niæ piêæ kategorii parametrów, którymi cechuj¹ siê poszczególne programy: m parametry ogólne dotycz¹ce UML; m parametry projektu; m parametry diagramu i elementu; m parametry interfejsu aplikacji; m parametry ogólne aplikacji. Tabela 4.2 przedstawia parametry wyró nione dla poszczególnych kategorii, natomiast tabela 4.3 zawiera wyniki porównania kilku przyk³adowych programów do modelowania w metodyce obiektowej, które mog¹ mieæ zastosowanie do informacji geograficznej. Bior¹c po uwagê w³aœciwoœci informacji geograficznej, cel schematów aplikacyjnych oraz normy serii ISO 1900, w stosunku do narzêdzi przeznaczonych do modelowania informacji geograficznej, mo na wskazaæ kilka szczególnie po ¹danych funkcji: m wbudowany profil UML zgodny ze specyfikacj¹ ISO/TS (typy danych i stereotypy), m m realizacja technologii MDA tworzenie schematów aplikacyjnych GML, skrypty SQL, schematy XSD, bezpoœredni (bez koniecznoœci wykonywania dodatkowych kroków) dostêp do schematów znormalizowanych. Wymieniona powy ej po ¹dana funkcjonalnoœæ realizowana jest tylko w sposób czêœciowy przez ró ne narzêdzia do modelowania pojêciowego, poniewa na rynku nie ma specjalnego programu dedykowanego modelowaniu informacji geograficznej.

45 4. PRZEGL D STANDARDÓW I NARZÊDZI STOSOWANYCH DO MODELOWANIA INFORMACJI GEOGRAFICZNEJ 47 Lp. Tabela 4.2. Parametry oceny funkcjonalnoœci narzêdzi do modelowania pojêciowego Nazwa kategorii parametró w 1. Parametry ogólne dotycz¹ce UML 2. Parametry projektu Liczba typów diagramó w Parametr y K opiowanie, kopiowanie do schowka (clipboard ) Zaznaczania (wszystko, wzglêdem typu) Wyszukiwanie w projekcie Dodawanie/usuwanie elementów Tworzenie dokumentacji Generowanie skryptu SQL, import DB Schema Transformacje modeli (XSD, Walidacja modeli Generowanie/import WSDL Generowanie/import XML Schema Import/eksport XMI Import/eksport CSV (wersja XMI) WSDL, Java) 3. P arametry diagramu i element u Zmiana grafiki (kolor t³a, elementów, po³¹czeñ ) 4. Parametry interfejs u 5. Parametry ogólne programu Zmiana widocznoœci elementów Zmiana rozmiaru Zapis jako obraz Intuicyjnoœ æ Grafika Zaskakiwanie u ytkownika zachowaniem programu Kontrola u ytkownika (mo liwoœæ cofniêcia, ponowienia czynnoœci, dobrze oznaczone wyjœcia, utrudnienie wykonania nieodwracalnych czynnoœci) Pomoc i dokumentacja (porady dla Elastycznoœæ Rozmiar programu Z³o onoœæ i wydajnoœæ programu Trudnoœæ wykorzystania programu u ytkownika) (skróty klawiszowe, belki narzêdziowe)

46 48 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Tabela 4.3. Analiza funkcjonalnoœci wybranych narzêdzi Open Source do modelowania pojêciowego w metodyce obiektowej

47 POLSKIE 5. SCHEMATY TOWARZYSTWO APLIKACYJNE UML INFORMACJI REGU Y BUDOWY PRZESTRZENNEJ I PRZYK ADY ROCZNIKI GEOMATYKI 2012 m TOM X m ZESZYT 1(51) 49 Agnieszka Zwirowicz-Rutkowska 5. Schematy aplikacyjne UML regu³y budowy i przyk³ady Rozdzia³ dotyczy wyników procesu modelowania pojêciowego schematów aplikacyjnych. Istotnym zagadnieniem jest zarówno przedstawienie ich roli i zastosowania, jak równie znormalizowanych zasad ich budowy Pojêcie schematu aplikacyjnego, jego rola i znaczenie Schemat aplikacyjny definiuje zawartoœæ i strukturê danych oraz specyfikacje operacji s³u ¹cych do przetwarzania danych przez aplikacje. Pozwala osi¹gn¹æ powszechne i poprawne rozumienie danych, a tak e zastosowanie automatycznych mechanizmów zarz¹dzania danymi. Schemat powstaje w wyniku modelowania pojêciowego. Zgodnie z norm¹ ISO schemat aplikacyjny jest schematem pojêciowym dla danych wykorzystywanych przez jedn¹ lub wiêcej aplikacji (ISO/TC 211, 2002a). Aplikacja, zgodnie z normami serii ISO 19100, to operowanie i przetwarzanie danych w celu spe³nienia wymagañ u ytkownika. Rysunek 5.1 przedstawia objaœnienie pojêæ model pojêciowy, schemat pojêciowy i schemat aplikacyjny oraz zale noœci miêdzy nimi. Schemat aplikacyjny, który budowany jest zgodnie norami w dziedzinie informacji geograficznej, wyra ony jest w jêzyku schematu pojêciowego i zawiera: Rys Model pojêciowy, schemat pojêciowy, schemat aplikacyjny (na podstawie: Subieta, 1998 i ISO/TC 211, 2002a).

48 50 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... m m m m typy obiektów geograficznych i ich w³aœciwoœci, realizuj¹c w ten sposób pojêcia i strukturê okreœlon¹ w meta-modelu Ogólnym Modelu Obiektów (General Feature Model); specyfikacjê dotycz¹c¹ systemów odniesienia wykorzystanych do okreœlenia po³o enia obiektów; typy obiektów przestrzennych, które reprezentuj¹ przestrzenny aspekt obiektów (feature); elementy jakoœci danych oraz przegl¹dowe elementy jakoœci danych, które informuj¹ o jakoœci poszczególnych obiektów, ich atrybutów i relacji. Przyk³adem elementów jakoœci danych jest kompletnoœæ, natomiast przegl¹dowego elementu jakoœci danych pochodzenie. Zwi¹zek miêdzy Ogólnym Modelem Obiektów, schematem aplikacyjnym i zbiorem danych przedstawia rysunek 5.2. Ogólny Model Obiektów definiuje strukturê potrzebn¹ do klasyfikacji typów obiektów, które nale y uwzglêdniæ podczas tworzenia schematu aplikacyjnego w UML. Przejœcie od pojêæ wyra onych na poziomie meta-modelu na typy zdefiniowane w schemacie aplikacyjnym nosi nazwê mapowania. Wed³ug struktury zdefiniowanej w schemacie aplikacyjnym, na poziomie danych gromadzone s¹ konkretne instancje obiektów. Rys Zwi¹zek miêdzy Ogólnym Modelem Obiektów (GFM), schematem aplikacyjnym i zbiorem danych (ISO/TC 211, 2002a) Proces budowy schematów aplikacyjnych Norma ISO (ISO/TC 211, 2005b) przedstawia znormalizowany sposób podejœcia do budowy schematów aplikacyjnych. W ogólnym zarysie tworzenie schematu sk³ada siê z nastêpuj¹cych etapów (rys.5.3): analiza dziedziny przedmiotowej, okreœlenie wymagañ dla zakresu aplikacji (dziedziny problemu), identyfikacja typów obiektów i ich w³aœciwoœci, opis modelu pojêciowego w wybranym jêzyku schematu pojêciowego, integracja schematu aplikacyjnego ze schematami znormalizowanymi, zawartymi w normach ISO serii

49 5. SCHEMATY APLIKACYJNE UML REGU Y BUDOWY I PRZYK ADY 51 Rys Proces budowy schematu aplikacyjnego. Proces budowy schematów aplikacyjnych wymaga uwzglêdnienia dwóch zbiorów regu³ dotycz¹cych: m mapowania typów obiektów wyra onych w pojêciach Ogólnego Modelu Obiektów na formalizmy u yte w schemacie aplikacyjnym UML, m u ywania schematów znormalizowanych. Do opisu schematu aplikacyjnego stosuje siê formalny jêzyk, którym w normach ISO jest UML. Specyfikacja techniczna ISO/TS (ISO/TC 211, 2005a) okreœla stereotypy i podstawowe typy danych, które s¹ wykorzystywane do budowy schematów aplikacyjnych dotycz¹cych informacji geograficznej. Ka dy schemat aplikacyjny powinien mieæ podana nazwê i wersjê, a tak e dokumentacjê. Do tworzenia dokumentacji mo na wykorzystywaæ funkcje oprogramowania, w którym tworzone s¹ schematy. W zakresie dokumentowania typów obiektów geograficznych powinien byæ stworzony katalog, który wykorzystuje pojêcia zdefiniowane w ogólnym modelu obiektów geograficznych.

50 52 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Tabela 5.1. Wybrane regu³y mapowania (ISO/TC 211, 2005b) Nazwa znormalizowana w Ogólnym Modelu Obiektów (ISO/TC b) GF_FeatureType GF_AssociationType GF_AggregationType GF_AttributeType GF_AssociationRole GF_Operation GF_InheritanceRelation GF_Constraint klasa Zapis w UML asocjacja klasa asocjacyjna agregacja (sk³adniki mog¹ istnieæ innych agregacji) kompozycja (sk³adniki nie do jednej kompozycji) atrybut rola na odpowiednim koñcu asocjacji operacja zdefiniowana w klasie generalizacj a niezale nie i mog¹ nale eæ do mog¹ istnieæ samodzielnie i nale ¹ tylko zapis np. w jêzyku OCL i dodany do klasy, operacji, relacji Wybrane regu³y mapowania typów zdefiniowanych w Ogólnym Modelu Obiektów na formalizmy u ywane w schemacie aplikacyjnym UML przedstawia tabela Przyk³ady schematów aplikacyjnych UML Przyk³ady 1 3 przedstawiaj¹ ró ne schematy aplikacyjne, dla opisu których zastosowano notacjê UML. Przyk³ady dotycz¹ zarówno schematów niezgodnych, jak i zgodnych ze znormalizowanym podejœciem okreœlonym w normach serii ISO W przypadku schematów aplikacyjnych zgodnych z regu³ami budowy schematów aplikacyjnych zaprezentowano sposoby integracji ze schematami znormalizowanymi (przyk³ady 2 i 3). Przyk³ad 1 Przyk³ad dotyczy schematu aplikacyjnego, przy budowie którego nie wykorzystano norm ISO Rysunek 5.4 prezentuje fragment schematu aplikacyjnego bazy danych ewidencyjnych. Brak powo³añ normatywnych (przyp. red. nauk.: w znaczeniu przyjêtym przez Polski Komitet Normalizacyjny) przejawia siê miêdzy innymi niezastosowaniem regu³ dotycz¹cych zapisu nazw klas, nazw asocjacji, a tak e nie uwzglêdnienia integracji ze schematami znormalizowanymi. Rys Fragment schematu aplikacyjnego bazy danych ewidencyjnych.

51 5. SCHEMATY APLIKACYJNE UML REGU Y BUDOWY I PRZYK ADY 53 Przyk³ad 2 Przyk³ad dotyczy schematu aplikacyjnego, dla którego zastosowano normy ISO (rys. 5.5). Analiza atrybutów w klasach wskazuje na zastosowan¹ integracjê schematu ze schemat znormalizowanym: przestrzennym (ISO/TC 211, 2003) GM_Point, czasowym (ISO/TC 211, 2002b) TM_Instant, a tak e specyfikacj¹ ISO/TS (ISO/TC 211, 2005a) poprzez typ CharacterString oraz zasady dotycz¹ce zapisu nazw atrybutów, asocjacji. Przyk³ad 3 Rys.5.5. Diagram klas dla stacji pomiarowej (ISO/TC 211, 2005b). Przyk³ad dotyczy schematu aplikacyjnego, dla którego zastosowano normy ISO Analiza atrybutów w klasach wskazuje na zastosowan¹ integracjê schematu ze schematem przestrzennym (ISO/TC 211, 2003) poprzez typy GM_MultiSurface, GM_Point. Wykorzystano tak e typy zalecone w specyfikacji ISO/TS (ISO/TC 211, 2005a): CharacterString, DateTime, Length, Integer oraz zastosowano zasady zapisu nazw klas, atrybutów i roli. Ponadto nawi¹zano do stereotypu okreœlonego w normie ISO (ISO/TC 211, 2007a lub Portele,2007) «featuretype». Rys.5.6. Klasa CadastralZoning w schemacie aplikacyjnym dla tematu dzia³ki ewidencyjne INSPIRE (TWG-CP, 2010).

52

53 6. BUDOWA POLSKIE SCHEMATU APLIKACYJNEGO TOWARZYSTWO GML INFORMACJI REGU Y BUDOWY, PRZESTRZENNEJ NARZÊDZIA I PRZYK ADY ROCZNIKI GEOMATYKI 2012 m TOM X m ZESZYT 1(51) 55 Agnieszka Chojka 6. Budowa schematu aplikacyjnego GML regu³y budowy, narzêdzia i przyk³ady W rozdziale opisano regu³y budowy schematu aplikacyjnego GML, w tym regu³y przekszta³cania schematu aplikacyjnego UML na schemat aplikacyjny GML. Umieszczono w nim równie przyk³ady przekszta³cania poszczególnych elementów UML na stosowne konstrukcje w GML oraz przyk³ady dostêpnych narzêdzi programowych wspomagaj¹ce takie odwzorowania. Norma ISO Regu³y budowy schematów aplikacyjnych GML Norma ISO to specyfikacja implementacyjna jêzyka GML (ang. Geography Markup Language) jêzyka znaczników geograficznych, który jest otwartym formatem wymiany danych przestrzennych pomiêdzy ró nymi systemami geoinformacyjnymi. GML jest aplikacj¹ XML, okreœla regu³ê kodowania dla schematów aplikacyjnych zgodnych z normami ISO serii 19100, opart¹ na XML zgodnie z ISO Definiuje sposób zapisu w XML Schema okreœlonych w³aœciwoœci przestrzennych i nieprzestrzennych (zdefiniowanych w normach ISO serii 19100) obiektów geograficznych, np. jednostki miary, geometria i topologia, systemy odniesienia. Norma ISO okreœla zasady przekszta³cania schematów aplikacyjnych zapisanych w UML zgodnie z norm¹ ISO na schematy aplikacyjne GML zapisane w XML Schema. Schemat GML i schemat aplikacyjny GML Schemat GML sk³ada siê z komponentów w przestrzeni nazw XML, której pe³na nazwa podawana jest w postaci adresu URL (szczególny przypadek URI, czyli jednoznacznego identyfikatora zasobu w sieci Internet): Komponenty te przeznaczone s¹ do zapisu okreœlonych w³aœciwoœci przestrzennych i nieprzestrzennych obiektów geograficznych. Schemat aplikacyjny GML jest schematem aplikacyjnym zapisanym w jêzyku XML Schema zgodnie z regu³ami okreœlonymi w normie ISO Budowa schematu aplikacyjnego GML dla okreœlonej dziedziny zastosowañ mo e wymagaæ rozszerzenia lub ograniczenia typów zdefiniowanych przez schemat GML. Schemat aplikacyjny GML musi byæ okreœlony w XML Schema i musi importowaæ schematy GML (rys. 6.1).

54 56 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Rys Zale noœci miêdzy norm¹ ISO a innymi normami ISO z serii oraz miêdzy schematem aplikacyjnym GML a schematem GML (ISO/TC 211, 2007a lub Portele, 2007). Schemat aplikacyjny GML mo e zostaæ skonstruowany na dwa sposoby przez: m zastosowanie regu³ dla schematów aplikacyjnych GML okreœlonych w normie ISO dla tworzenia schematów aplikacyjnych bezpoœrednio w XML Schema; m opracowanie schematu aplikacyjnego w UML z zastosowaniem regu³ okreœlonych w normie ISO 19109, a nastêpnie przekszta³cenie go na odpowiadaj¹cy mu schemat aplikacyjny w GML, zapisany w XML Schema zgodnie z regu³ami kodowania okreœlonymi w normach ISO i ISO Regu³y przekszta³cenia modelu UML do schematu GML Przekszta³cenie schematu aplikacyjnego UML, zgodnego z norm¹ ISO 19109, na odpowiadaj¹cy mu schemat aplikacyjny GML, oparte jest na zbiorze regu³ kodowania okreœlonych w normie ISO Zasady te podano w Za³¹czniku E (ISO/TC 211, 2007a lub Portele, 2007) i oparto na ogólnym za³o eniu, e definicja klasy w schemacie aplikacyjnym UML jest przekszta³cana na deklaracjê typu i elementu w schemacie GML (XML Schema) wed³ug zale noœci podanych w poni szej tabeli (tab. 6.1). Dodatkowo dla ró nych elementów modelu UML mo na okreœliæ metki (tab. 6.2), które pozwalaj¹ kontrolowaæ przekszta³canie schematu aplikacyjnego UML na XML Schema (schemat aplikacyjny GML), szczególnie podczas stosowania narzêdzi umo liwiaj¹cych automatyczne generowanie plików XSD, np. systemy przekszta³cania modeli ShapeChange lub FullMoon.

55 6. BUDOWA SCHEMATU APLIKACYJNEGO GML REGU Y BUDOWY, NARZÊDZIA I PRZYK ADY 57 Tabela 6.1. Regu³y kodowania UML do GML (ISO/TC 211, 2007a lub Portele, 2007) Schemat aplikacyjny UML Schemat aplikacyjny GML P akiet Jeden dokument XML Schema na pakiet (przekszta³cenie domyœlne ) > >application Schema<< Dokument XML Schema < <datatype>> Element globalny, którego modelem zawartoœci jest elemen t complextyp w XML Schema o zakresie globalnym, typ w³aœciwoœci < <enumeration>> Ograniczeni e xsd:string z wartoœciami wyliczeni a < <codelist>> Unia wyliczenia i wzorca (przekszta³cenie domyœlne, przekszta³cenie m alternatywnym jest odwo³anie do s³ownika) < <union>> Grupa wyboru, której sk³adnikami s¹ obiekty GML lub obiekty odpowiadaj¹ce DataType < <featuretype>> Element globalny, którego modelem zawartoœci jest typ XML Schema o zakresie globalnym, pochodz¹cy z bezpoœredniego/poœredniego rozszerzenia g ml: AbstractFeatureType, typ w³aœciwoœc i Brak stereotypu lub <<type>> Operacje Atrybut Rola powi¹zania (asocjacji) Ograniczenia OCL Element globalny, którego modelem zawartoœci jest typ XML Schema o zakresie globalnym, pochodz¹cy z bezpoœredniego/poœredniego rozszerzenia g ml: AbstractGMLType, typ w³aœciwoœc i Nie kodowane L okalny xsd:element, typ jest równie typem w³aœciwoœci (jeœli typ jest typem z³o onym) lub typem prostym L okalny xsd:element, typ jest zawsze typem w³aœciwoœci (tylko role nazwane i nawigowalne) Nie kodowane** Jednak w XML Schema istnieje mo liwoœæ ograniczenia za pomoc¹ elementu restriction zapisani a Tabela 6.2. Podstawowe metki (Tagged Values) stosowane dla poszczególnych elementów modelu UML (ISO/TC 211, 2007a lub Portele, 2007) Pakiet Klasa Element modelu UML Atrybut lub zakoñczenie powi¹zania Stosowana metka documentatio n xsddocument targetnamespace (tylko dla << a plication Schema> > xmlns (tylko dla << a pplication Schema>> ) version (tylko dla << a pplication Schema>> ) gmlprofileschema (tylko dla << a pplication Schema>> ) documentatio n nopropertytype byvaluepropertytype iscollection asdictionary (tylko dla < <codelist>> ) xmlschematype (tylko dla << t ype>> ) documentation sequencenumber inlineorbyreference ismetadata

56 58 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Element Pakiet Pakiet w UML przekszta³cany jest na jeden dokument XML Schema z metk¹ xsddocument okreœlaj¹c¹ nazwê pliku XSD. Jeœli metka xsddocument zosta³a ustawiona dla pakietu, wtedy dokument schematu zawiera wszystkie sk³adniki XML Schema wynikaj¹ce z klas UML zawartych bezpoœrednio w pakiecie. W przeciwnym wypadku, wszystkie sk³adniki schematu deklarowane s¹ w dokumencie schematu pakietu, w którym zawarty jest ten pakiet. Ustawienie metki xsddocument jest obowi¹zkowe dla wszystkich pakietów ze stereotypem «applicationschema». Dla ka dego dokumentu schematu nale y ustawiæ wartoœci atrybutów targetnamespace i version elementu g³ównego za pomoc¹ odpowiednich metek w pakiecie reprezentuj¹cym schemat aplikacyjny UML. Ponadto powinien zostaæ okreœlony atrybut xmlns dla docelowej przestrzeni nazw (metka xmlns). Nale y równie okreœliæ wzajemne zale noœci miêdzy poszczególnymi pakietami, aby ustaliæ, czy wymagane bêdzie zaimportowanie (element import), czy w³¹czenie (element include) schematów aplikacyjnych z innych pakietów. Element import pozwala na dodanie do dokumentu XML Schema schematów z ró nymi docelowymi przestrzeniami nazw, a element include pozwala na dodanie schematów z t¹ sam¹ docelow¹ przestrzeni¹ nazw. Element klasa Na schemat aplikacyjny GML przekszta³cane s¹ jedynie klasy UML bez stereotypu lub ze stereotypem «featuretype», «type», «datatype», «union», «codelist» i «enumeration». Wszystkie klasy UML powinny mieæ zero lub jeden nadtyp, to znaczy e klasa mo e dziedziczyæ jedynie od jednej klasy. Ka da klasa UML przekszta³cana jest na typ nazwany i otrzymuje przyrostek Type. Typy danych zdefiniowane przez normy ISO serii przekszta³cane s¹ na odpowiadaj¹ce im typy danych w XML Schema (tab. 6.3). W tabeli 6.3 klasa UML to klasa pochodz¹ca z norm ISO serii 19100, zaimplementowana w schemacie GML. Typ GML okreœla typ obiektu zapisanego w XML Schema, a typ sk³adnika (w³aœciwoœci) GML jest typem XML Schema u ywanym jako wartoœæ okreœlonej w³aœciwoœci w schemacie aplikacyjnym GML (np. atrybut, rola). Tabela 6.3. Przyk³ady implementacji typów danych z norm ISO serii w schemacie aplikacyjnym GML (ISO/TC 211, 2007a lub Portele, 2007) Klasa UML Element obiektu GML Typ GML Typ sk³adnik a (w³aœciwoœci) GML GM_Object gml:abstractgeometr y gml:abstractgeometrytyp e gml:geometrypropertytyp e GM_Point gml:poin t gml:pointtyp e gml:pointpropertytyp e TP_Edge gml:edg e gml:edgetyp e gml:directededgepropertytyp e SC_CRS gml:abstractcr S gml:abstractcrstyp e gml:crspropertytyp e C haracterstring xsd:strin g I nteger xsd:integer, xsd:nonpositiveinteger, xsd:negativeinteger, xsd:nonnegativeinteger, xsd:positiveinteger L ength, Distance gml:lengthtyp e

57 6. BUDOWA SCHEMATU APLIKACYJNEGO GML REGU Y BUDOWY, NARZÊDZIA I PRZYK ADY 59 Klasa ze stereotypem «datatype» m Klasa ze stereotypem «datatype» jest przekszta³cana na typ z³o ony (element complextype) w XML Schema. m Jeœli klasa nie ma nadtypu (tzn. nie jest utworzona poprzez dziedziczenie od innej klasy), nie jest typem pochodnym w XML Schema (nie stanowi rozszerzenia extension adnego elementu XML Schema). W przeciwnym przypadku stanowi rozszerzenie swojego nadtypu, który nie mo e byæ typem pochodnym od gml:abstractgmltype, tzn. nie mo e bezpoœrednio lub poœrednio dziedziczyæ z gml:abstractgmltype (stanowiæ rozszerzenia tego elementu w XML Schema). Nadtypy abstrakcyjne bez atrybutów i nawigacyjnych ról asocjacji s¹ pomijane. m Dla klas ze stereotypem «datatype» nale y zdefiniowaæ elementy globalne XML z odpowiednimi ustawieniami dla nazwy (nazwa klasy UML), typu (nazwa klasy z przyrostkiem Type), abstrakcyjnoœci (jeœli klasa jest abstrakcyjna) i grup¹ zastêpowania (nazwa okreœlaj¹ca element nadtypu lub gml:abstractobject, jeœli klasa nie ma nadtypu). m Nale y utworzyæ nazwany typ z³o ony, którego nazwa zawiera nazwê klasy UML z przyrostkiem PropertyType, jeœli dla klasy nie ustawiono metki nopropertytype z wartoœci¹ true. Przyk³ad (rys. 6.2) przekszta³cenia klasy Adres na odpowiedni¹ strukturê w GML: Rys Przyk³ad klasy ze stereotypem «datatype». FRPSOH[7\SHQDPH $GUHV7\SH! VHTXHQFH! HOHPHQWQDPH XOLFDW\SH VWULQJ! HOHPHQWQDPH NRGW\SH VWULQJ! HOHPHQWQDPH PLHMVFRZR üw\sh VWULQJPLQ2FFXUV! VHTXHQFH! FRPSOH[7\SH! HOHPHQWQDPH $GUHVW\SH QS$GUHV7\SHVXEVWLWXWLRQ*URXS JPO$EVWUDFW2EMHF FRPSOH[7\SHQDPH $GUHV3URSHUW\7\SH! VHTXHQFH! HOHPHQWUHI QS$GUHV! VHTXHQFH! DWWULEXWH*URXSUHI JPO2ZQHUVKLS$WWULEXWH*URXS! FRPSOH[7\SH!

58 60 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Klasa ze stereotypem «featuretype» m Klasy ze stereotypem «featuretype» pochodz¹ bezpoœrednio lub poœrednio od gml:abstractfeaturetype. Jeœli klasa nie ma nadtypu to stanowi bezpoœrednie rozszerzenie gml:abstractfeaturetype, w przeciwnym razie stanowi rozszerzenie nadtypu, który powinien pochodziæ od gml:abstractfeaturetype (bezpoœrednio lub poœrednio). m Dla klas ze stereotypem «featuretype» nale y zdefiniowaæ elementy globalne XML z odpowiednimi ustawieniami dla nazwy (nazwa klasy UML), typu (nazwa klasy z przyrostkiem Type), abstrakcyjnoœci (jeœli klasa jest abstrakcyjna) i grup¹ zastêpowania (nazwa nadtypu lub gml:abstractfeature). m Jeœli klasa ma pojedyncze powi¹zanie, które jest agregacj¹ zwyk³¹ lub ca³kowit¹ (kompozycj¹), rola powi¹zania jest przekszta³cana na element w³aœciwoœci, a klasa przenosi metkê iscollection z wartoœci¹ true oraz do typu z³o onego dodawana jest grupa atrybutów gml:aggregationattributegroup. m Dla klasy nale y utworzyæ nazwany typ z³o ony, którego nazwa zawiera nazwê klasy UML z przyrostkiem PropertyType, jeœli dla klasy nie ustawiono metki nopropertytype z wartoœci¹ true. m Dla klasy nale y utworzyæ nazwany typ z³o ony, którego nazwa zawiera nazwê klasy UML z przyrostkiem PropertyByValueType, jeœli dla klasy ustawiono metkê Rys Przyk³ad klasy ze stereotypem «featuretype». byvaluepropertytype z wartoœci¹ true. Przyk³ad (rys. 6.3) przekszta³cenia klasy Budynek na odpowiedni¹ strukturê w GML: FRPSOH[7\SHQDPH %XG\QHN7\SH! FRPSOH[&RQWHQW! H[WHQVLRQEDVH JPO$EVWUDFW)HDWXUH7\SH! VHTXHQFH! HOHPHQWQDPH REV]DUW\SH JPO6XUIDFH3URSHUW\7\SH! HOHPHQWQDPH DGUHVW\SH QS$GUHV3URSHUW\7\SH! HOHPHQWQDPH URG]DM%XG\QNXW\SH QS5RG]DM%XG\QNX7\SH! VHTXHQFH! H[WHQVLRQ! FRPSOH[&RQWHQW! FRPSOH[7\SH! FRPSOH[7\SHQDPH %XG\QHN3URSHUW\7\SH! VHTXHQFHPLQ2FFXUV! HOHPHQWUHI QS%XG\QHN! VHTXHQFH! DWWULEXWH*URXSUHI JPO$VVRFLDWLRQ$WWULEXWH*URXS! DWWULEXWH*URXSUHI JPO2ZQHUVKLS$WWULEXWH*URXS! FRPSOH[7\SH! FRPSOH[7\SHQDPH %XG\QHN3URSHUW\%\9DOXH7\SH! VHTXHQFH! HOHPHQWUHI QS%XG\QHN! VHTXHQFH! DWWULEXWH*URXSUHI JPO2ZQHUVKLS$WWULEXWH*URXS! FRPSOH[7\SH! HOHPHQWQDPH %XG\QHNW\SH QS%XG\QHN7\SHVXEVWLWXWLRQ*URXS JPO$EVWUDFW)HDWXUH!

59 6. BUDOWA SCHEMATU APLIKACYJNEGO GML REGU Y BUDOWY, NARZÊDZIA I PRZYK ADY 61 Klasa ze stereotypem «type» lub bez stereotypu m m m m m Klasa bez stereotypu lub ze stereotypem «type» pochodzi bezpoœrednio lub poœrednio z gml:abstractgmltype. Jeœli klasa nie ma nadtypu stanowi bezpoœrednie rozszerzenie gml:abstractgmltype, w przeciwnym razie stanowi rozszerzenie nadtypu, który powinien pochodziæ od gml:abstractgmltype (bezpoœrednio lub poœrednio), ale nie z gml:abstractfeaturetype (bezpoœrednio lub poœrednio). Dla klas ze stereotypem «type» nale y zdefiniowaæ elementy globalne XML z odpowiednimi ustawieniami dla nazwy (nazwa klasy UML), typu (nazwa klasy z przyrostkiem Type), abstrakcyjnoœci (jeœli klasa jest abstrakcyjna) i grup¹ zastêpowania (nazwa nadtypu lub AbstractGML). Jeœli klasa ma pojedyncze powi¹zanie, które jest agregacj¹ zwyk³¹ lub ca³kowit¹, rola powi¹zania jest przekszta³cana na element w³aœciwoœci, a klasa przenosi metkê iscollection z wartoœci¹ true oraz do typu z³o onego dodawana jest grupa atrybutów gml:aggregationattributegroup. Dla klasy nale y utworzyæ nazwany typ z³o ony, którego nazwa zawiera nazwê klasy UML z przyrostkiem PropertyType, jeœli dla klasy nie ustawiono metki nopropertytype z wartoœci¹ true. Rys Przyk³ad klasy bez stereotypu. Dla klasy nale y utworzyæ nazwany typ z³o ony, którego nazwa zawiera nazwê klasy UML z przyrostkiem PropertyByValueType, jeœli dla klasy ustawiono metkê byvaluepropertytype z wartoœci¹ true. Przyk³ad (rys. 6.4) przekszta³cenia klasy Elipsa na odpowiedni¹ strukturê w GML. Klasa abstrakcyjna GM_CurveSegment pochodzi z normy ISO i reprezentuje prosty element geometryczny segment krzywej: HOHPHQWQDPH (OLSVDW\SH QS(OLSVD7\SHVXEVWLWXWLRQ*URXS JPO$EVWUDFW&XUYH6HJPHQW! FRPSOH[7\SHQDPH (OLSVD7\SH! FRPSOH[&RQWHQW! H[WHQVLRQEDVH JPO$EVWUDFW&XUYH6HJPHQW7\SH! VHTXHQFH! HOHPHQWQDPH URGHNW\SH JPO'LUHFW3RVLWLRQ7\SH! HOHPHQWQDPH PDáD3yáR W\SH JPO9HFWRU7\SH! HOHPHQWQDPH ZLHOND3yáR W\SH JPO9HFWRU7\SH! VHTXHQFH! H[WHQVLRQ! FRPSOH[&RQWHQW! FRPSOH[7\SH! Klasa ze stereotypem «enumeration» Klasa ze stereotypem «enumeration» jest przekszta³cana na typ prosty (simpletype) w XML Schema. Typem podstawowym jest string, a dziedzina wartoœci zosta³a ograniczona do zbioru wartoœci okreœlonych przez nazwy atrybutów klasy UML. Rys Przyk³ad klasy ze stereotypem «enumeration».

60 62 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Przyk³ad (rys. 6.5) przekszta³cenia klasy P³eæ na odpowiedni¹ strukturê w GML: VLPSOH7\SHQDPH 3áHü! UHVWULFWLRQEDVH VWULQJ! HQXPHUDWLRQYDOXH NRELHWD! HQXPHUDWLRQYDOXH P F]\]QD! UHVWULFWLRQ! VLPSOH7\SH! Klasa ze stereotypem «codelist» Klasa ze stereotypem «codelist» i bez ustawionej metki asdictionary na true powinna zostaæ przekszta³cona tak jak klasa ze stereotypem «enumeration», ale z t¹ ró nic¹, e: m nale y dodaæ wzorzec <pattern value= other: \w{2,} />, który dopuszcza inne wartoœci tekstowe poza zdefiniowanymi (wartoœci te s¹ poprzedzone przedrostkiem other); m jeœli okreœlony jest kod dla wartoœci listy kodowej, Rys Przyk³ad klasy ze stereotypem «codelist». tylko kod powinien byæ reprezentowany jako wzorzec wyliczenia; m wartoœæ kodu powinna byæ okreœlona za pomoc¹ elementów annotation oraz appinfo z elementem gml:description okreœlaj¹cym wartoœæ tekstow¹ wartoœci wyliczanej. Przyk³ad (rys. 6.6) przekszta³cenia klasy PrzeznaczenieTerenu na odpowiedni¹ strukturê w GML: VLPSOH7\SHQDPH 3U]H]QDF]HQLH7HUHQX7\SH! XQLRQPHPEHU7\SHV QS3U]H]QDF]HQLH7HUHQX(QXPHUDWLRQ7\SHQS3U]H]QDF]HQLH7HUHQX2WKHU7 VLPSOH7\SH! VLPSOH7\SHQDPH 3U]H]QDF]HQLH7HUHQX(QXPHUDWLRQ7\SH! UHVWULFWLRQEDVH VWULQJ! HQXPHUDWLRQYDOXH! DQQRWDWLRQ! DSSLQIR!JPOGHVFULSWLRQ!]DEXGRZD0LHV]NDQLRZDJPOGHVFULSWLRQ!DSSLQIR! DQQRWDWLRQ! HQXPHUDWLRQ! HQXPHUDWLRQYDOXH! DQQRWDWLRQ! DSSLQIR!JPOGHVFULSWLRQ!GURJDJPOGHVFULSWLRQ!DSSLQIR! DQQRWDWLRQ! HQXPHUDWLRQ! HQXPHUDWLRQYDOXH! DQQRWDWLRQ! DSSLQIR!JPOGHVFULSWLRQ!]ELRUQLN:RGQ\JPOGHVFULSWLRQ!DSSLQIR! DQQRWDWLRQ! HQXPHUDWLRQ! UHVWULFWLRQ! VLPSOH7\SH! VLPSOH7\SHQDPH 3U]H]QDF]HQLH7HUHQX2WKHU7\SH! UHVWULFWLRQEDVH VWULQJ! SDWWHUQYDOXH RWKHU?Z^`! UHVWULFWLRQ! VLPSOH7\SH!

61 6. BUDOWA SCHEMATU APLIKACYJNEGO GML REGU Y BUDOWY, NARZÊDZIA I PRZYK ADY 63 Klasa ze stereotypem «union» Klasa ze stereotypem «union» jest przekszta³cana na typ z³o ony (complextype) w XML Schema, podobnie jak klasa ze stereotypem «datatype», przy czym zamiast elementu sequence pojawia siê element choice, który oznacza, e tylko jedna z w³aœciwoœci mo e pojawiæ siê w instancji unii. Przyk³ad przekszta³cenia klasy ze stereotypem «union» na odpowiedni¹ strukturê w GML: FRPSOH[7\SHQDPH $UW\VWD7\SH! FKRLFH! HOHPHQWQDPH QD]ZLVNRW\SH VWULQJ! HOHPHQWQDPH SVHXGRQLPW\SH VWULQJ! FKRLFH! FRPSOH[7\SH! Atrybuty i nazwy ról Atrybut lub rola powi¹zania obiektu w UML s¹ przekszta³cane na elementy lokalne z t¹ sam¹ nazw¹ typu z³o onego (complextype), który definiuje model zawartoœci typu obiektu. Ograniczenia atrybutów minoccurs i maxoccurs s¹ ustawiane zgodnie z definicjami ich krotnoœci (licznoœci) w modelu UML. Typ zale y od typu wartoœci w³aœciwoœci w UML. Je eli typ wartoœci w³aœciwoœci jest: m zawartoœci¹ prost¹, wtedy taki typ stosowany jest bezpoœrednio (np. integer); m zawartoœci¹ z³o on¹, wtedy zostanie u yta w³aœciwoœæ. Domyœlna transformacja (bez ustawiania metek) w³aœciwoœci typu pozwala zarówno na reprezentacjê wbudowan¹ (inline), jak i przez referencjê (by-reference) dla typów obiektów oraz reprezentacjê wbudowan¹ (inline) dla typów danych i unii. Dla typów obiektów reprezentacja mo e zostaæ ograniczona do wbudowanej lub przez referencjê przez zastosowanie metki inlineorbyreference odpowiednio z wartoœci¹ inline lub byreference. Nale y zastosowaæ transformacjê domyœln¹ jeœli metka nie zostanie ustawiona lub zostanie ustawiona na inlineorbyreference. Jeœli typ w³aœciwoœci zosta³ ju okreœlony w schemacie aplikacyjnym, jako typ nazwany (nale y sprawdziæ metki nopropertytype i byvaluepropertytype), nale y odwo³aæ siê do tego sk³adnika schematu, w przeciwnym razie lokalnie zostanie zdefiniowany anonimowy typ w³aœciwoœci w elemencie w³aœciwoœci. Je eli kodowana w³aœciwoœæ jest koñcem powi¹zania i drugi koniec powi¹zania jest równie kodowany na schemat aplikacyjny GML, nazwa w³aœciwoœci drugiego koñca powi¹zania powinna zostaæ przekszta³cona na element gml:reversepropertyname w elementach annotation i appinfo elementu w³aœciwoœci. Rys Przyk³ad ról w powi¹zaniu.

62 64 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Przyk³ad (rys. 6.7) przekszta³cenia w³aœciwoœci typu na reprezentacjê wbudowan¹ (inline) i przez referencjê (by-reference) w GML: HOHPHQWQDPH ZáD FLFLHOW\SH QS2VRED3URSHUW\7\SHPD[2FFXUV XQERXQGHG! DQQRWDWLRQ! DSSLQIR! JPOUHYHUVH3URSHUW\1DPH!QSZáDVQR üjpouhyhuvh3urshuw\1dph! DSSLQIR! DQQRWDWLRQ! HOHPHQW! «FRPSOH[7\SHQDPH 2VRED3URSHUW\7\SH! VHTXHQFHPLQ2FFXUV! HOHPHQWUHI QS2VRED! VHTXHQFH! DWWULEXWH*URXSUHI JPO$VVRFLDWLRQ$WWULEXWH*URXS! DWWULEXWH*URXSUHI JPO2ZQHUVKLS$WWULEXWH*URXS! FRPSOH[7\SH! lub: HOHPHQWQDPH ZáD FLFLHOPD[2FFXUV XQERXQGHG! DQQRWDWLRQ! DSSLQIR! JPOUHYHUVH3URSHUW\1DPH!QSZáDVQR üjpouhyhuvh3urshuw\1dph! DSSLQIR! DQQRWDWLRQ! FRPSOH[7\SH! VHTXHQFHPLQ2FFXUV! HOHPHQWUHI QS2VRED! VHTXHQFH! DWWULEXWH*URXSUHI JPO$VVRFLDWLRQ$WWULEXWH*URXS! FRPSOH[7\SH! HOHPHQW! Alternatywnie typ w³aœciwoœci mo e posiadaæ tylko jedn¹ z reprezentacji, wbudowan¹ lub przez referencjê, w zale noœci od wartoœci metki inlineorbyreference. Przyk³ad przekszta³cenia w³aœciwoœci typu tylko na reprezentacjê wbudowan¹ (inline) w GML: HOHPHQWQDPH ZáD FLFLHOW\SH QS2VRED3URSHUW\%\9DOXH7\SHPD[2FFXUV XQERXQGHG! «FRPSOH[7\SHQDPH 2VRED3URSHUW\%\9DOXH7\SH! VHTXHQFH! HOHPHQWUHI QS2VRED! VHTXHQFH! FRPSOH[7\SH! lub: HOHPHQWQDPH ZáD FLFLHOPD[2FFXUV XQERXQGHG! FRPSOH[7\SH! VHTXHQFH! HOHPHQWUHI QS2VRED! VHTXHQFH! FRPSOH[7\SH! HOHPHQW!

63 6. BUDOWA SCHEMATU APLIKACYJNEGO GML REGU Y BUDOWY, NARZÊDZIA I PRZYK ADY 65 Jeœli dopuszczalna jest tylko reprezentacja przez referencjê, wtedy element w³aœciwoœci nale y ograniczyæ za pomoc¹ znaczników annotation i appinfo elementem gml:targetelement, który okreœla nazwê elementu typu docelowego: HOHPHQWQDPH HOHPHQW'RFHORZ\W\SH VWULQJ! Jeœli kodowana w³aœciwoœæ jest koñcem powi¹zania i drugi koniec powi¹zania jest równie kodowany na schemat aplikacyjny GML, wtedy nazwê w³aœciwoœci drugiego koñca powi¹zania nale y zapisaæ za pomoc¹ znaczników annotation i appinfo oraz elementu gml:reversepropertyname. Przyk³ad przekszta³cenia w³aœciwoœci typu tylko na reprezentacjê przez referencjê (by-reference) w GML: HOHPHQWQDPH ZáD FLFLHOW\SH JPO5HIHUHQFH7\SHPD[2FFXUV XQERXQGHG! DQQRWDWLRQ! DSSLQIR! JPOWDUJHW(OHPHQW!QS2VREDJPOWDUJHW(OHPHQW! JPOUHYHUVH3URSHUW\1DPH!QSZáDVQR üjpouhyhuvh3urshuw\1dph! DSSLQIR! DQQRWDWLRQ! HOHPHQW! Dziedziczenie Do XML Schema mo e byæ transformowane tylko dziedziczenie pojedyncze, które jest realizowane poprzez mechanizm rozszerzenia (extension) lub ograniczenia (restriction) XML Schema oraz wykorzystanie elementu zastêpowania (substitutiongroup). Przyk³ad (rys. 6.4, str. 61) przekszta³cenia klasy Elipsa, która dziedziczy z klasy abstrakcyjnej GM_CurveSegment, na odpowiedni¹ strukturê w GML: HOHPHQWQDPH (OLSVDW\SH QS(OLSVD7\SHVXEVWLWXWLRQ*URXS JPO$EVWUDFW&XUYH6HJPHQW! FRPSOH[7\SHQDPH (OLSVD7\SH! FRPSOH[&RQWHQW! H[WHQVLRQEDVH JPO$EVWUDFW&XUYH6HJPHQW7\SH! VHTXHQFH! HOHPHQWQDPH URGHNW\SH JPO'LUHFW3RVLWLRQ7\SH! HOHPHQWQDPH PDáD3yáR W\SH JPO9HFWRU7\SH! HOHPHQWQDPH ZLHOND3yáR W\SH JPO9HFWRU7\SH! VHTXHQFH! H[WHQVLRQ! FRPSOH[&RQWHQW! FRPSOH[7\SH!

64 66 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML Przyk³ad przekszta³cenia schematu aplikacyjnego UML na GML W podrozdziale tym przedstawiono przyk³ad przekszta³cenia schematu aplikacyjnego UML, zapisanego w postaci prostego diagramu klas, na odpowiadaj¹cy mu schemat aplikacyjny GML. Rys Przyk³ad schematu aplikacyjnego w UML Przyk³ad (rys. 6.8) przekszta³cenia schematu aplikacyjnego w UML na odpowiadaj¹cy mu schemat aplikacyjny w GML: "[POYHUVLRQ HQFRGLQJ,62"! VFKHPD[POQV KWWSZZZZRUJ;0/6FKHPD[POQVXV KWWSZZZDVWURQRPLDSOXNODGBVORQHF]Q\ [POQVJPO KWWSZZZRSHQJLVQHWJPOWDUJHW1DPHVSDFH KWWSZZZDVWURQRPLDSOXNODGBVORQHF]Q\ HOHPHQW)RUP'HIDXOW TXDOLILHGYHUVLRQ!! LPSRUWQDPHVSDFH KWWSZZZRSHQJLVQHWJPO VFKHPD/RFDWLRQ KWWSVFKHPDVRSHQJLVQHWJPOJPO[VG!! HOHPHQWQDPH 86B3ODQHWDVXEVWLWXWLRQ*URXS JPO$EVWUDFW)HDWXUH! FRPSOH[7\SH! FRPSOH[&RQWHQW! H[WHQVLRQEDVH JPO$EVWUDFW)HDWXUH7\SH! VHTXHQFH! HOHPHQWQDPH QD]ZDW\SH VWULQJ! HOHPHQWQDPH URG]DMW\SH XV86B5RG]DM3ODQHW\7\SHPLQ2FFXUV!

65 6. BUDOWA SCHEMATU APLIKACYJNEGO GML REGU Y BUDOWY, NARZÊDZIA I PRZYK ADY 67 HOHPHQWQDPH UHGQLFDW\SH JPO9HFWRU7\SHPLQ2FFXUV PD[2FFXUV XQERXQGHG! HOHPHQWQDPH RGOHJáR ü2g6ár FDW\SH JPO/HQJWK7\SH! HOHPHQWQDPH RNUHV2ELHJX:RNyá6áR FDW\SH JPO7LPH7\SH! HOHPHQWQDPH PDVDW\SH JPO9ROXPH7\SHPLQ2FFXUV! HOHPHQWQDPH JZLD]GDW\SH XV86B6áR FH3URSHUW\7\SH! DQQRWDWLRQ! DSSLQIR! JPOUHYHUVH3URSHUW\!XVFLDáR1LHELHVNLHJPOUHYHUVH3URSHUW\! DSSLQIR! DQQRWDWLRQ! HOHPHQW! HOHPHQWQDPH VDWHOLWDW\SH XV86B.VL \F3URSHUW\7\SHPLQ2FFXUV PD[2FFXUV XQERXQGHG! VHTXHQFH! H[WHQVLRQ! FRPSOH[&RQWHQW! FRPSOH[7\SH! HOHPHQW! FRPSOH[7\SHQDPH 86B3ODQHWD3URSHUW\7\SH! VHTXHQFHPLQ2FFXUV! HOHPHQWUHI XV86B3ODQHWD! VHTXHQFH! DWWULEXWH*URXSUHI JPO$VVRFLDWLRQ$WWULEXWH*URXS! DWWULEXWH*URXSUHI JPO2ZQHUVKLS$WWULEXWH*URXS! FRPSOH[7\SH!! HOHPHQWQDPH 86B.VL \FVXEVWLWXWLRQ*URXS JPO$EVWUDFW)HDWXUH! FRPSOH[7\SH! FRPSOH[&RQWHQW! H[WHQVLRQEDVH JPO$EVWUDFW)HDWXUH7\SH! VHTXHQFH! HOHPHQWQDPH QD]ZDW\SH VWULQJ! HOHPHQWQDPH RNUHV2ELHJX:RNyá3ODQHW\W\SH JPO7LPH7\SH! VHTXHQFH! H[WHQVLRQ! FRPSOH[&RQWHQW! FRPSOH[7\SH! HOHPHQW! FRPSOH[7\SHQDPH 86B.VL \F3URSHUW\7\SH! VHTXHQFHPLQ2FFXUV! HOHPHQWUHI XV86B.VL \F! VHTXHQFH! DWWULEXWH*URXSUHI JPO$VVRFLDWLRQ$WWULEXWH*URXS! DWWULEXWH*URXSUHI JPO2ZQHUVKLS$WWULEXWH*URXS! FRPSOH[7\SH!! HOHPHQWQDPH 86B6áR FHVXEVWLWXWLRQ*URXS JPO$EVWUDFW)HDWXUH! FRPSOH[7\SH! FRPSOH[&RQWHQW! H[WHQVLRQEDVH JPO$EVWUDFW)HDWXUH7\SH! VHTXHQFH! HOHPHQWQDPH URG]DM&LDáD1LHELHVNLHJR! FRPSOH[7\SH! VHTXHQFH! HOHPHQWQDPH 86B*ZLD]GDW\SH XV86B*ZLD]GD3URSHUW\7\SH! VHTXHQFH! FRPSOH[7\SH! HOHPHQW! HOHPHQWQDPH FLDáR1LHELHVNLHW\SH XV86B3ODQHWD3URSHUW\7\SHPLQ2FFXUV PD[2FFXUV XQERXQGHG! DQQRWDWLRQ! DSSLQIR!

66 68 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... JPOUHYHUVH3URSHUW\!XVJZLD]GDJPOUHYHUVH3URSHUW\! DSSLQIR! DQQRWDWLRQ! HOHPHQW! VHTXHQFH! H[WHQVLRQ! FRPSOH[&RQWHQW! FRPSOH[7\SH! HOHPHQW! FRPSOH[7\SHQDPH 86B6áR FH3URSHUW\7\SH! VHTXHQFHPLQ2FFXUV! HOHPHQWUHI XV86B6áR FH! VHTXHQFH! DWWULEXWH*URXSUHI JPO$VVRFLDWLRQ$WWULEXWH*URXS! DWWULEXWH*URXSUHI JPO2ZQHUVKLS$WWULEXWH*URXS! FRPSOH[7\SH!! HOHPHQWQDPH 86B*ZLD]GDW\SH XV86B*ZLD]GD7\SH! FRPSOH[7\SHQDPH 86B*ZLD]GD7\SH! VHTXHQFH! HOHPHQWQDPH UHGQLFDW\SH JPO9HFWRU7\SHPLQ2FFXUV! HOHPHQWQDPH PDVDW\SH JPO9ROXPH7\SHPLQ2FFXUV! HOHPHQWQDPH RNUHV2ELHJXW\SH JPO7LPH7\SH! HOHPHQWQDPH MDVQR üw\sh LQWHJHU! HOHPHQWQDPH VWDGLXP(ZROXFMLW\SH XV86B6WDGLXP(ZROXFML7\SHGHIDXOW JZLD]GDPLQ2FFXUV! VHTXHQFH! FRPSOH[7\SH! FRPSOH[7\SHQDPH 86B*ZLD]GD3URSHUW\7\SH! VHTXHQFHPLQ2FFXUV! HOHPHQWUHI XV86B*ZLD]GD! VHTXHQFH! DWWULEXWH*URXSUHI JPO2ZQHUVKLS$WWULEXWH*URXS! FRPSOH[7\SH!! VLPSOH7\SHQDPH 86B5RG]DM3ODQHW\7\SH! UHVWULFWLRQEDVH VWULQJ! HQXPHUDWLRQYDOXH VNDOLVWD! HQXPHUDWLRQYDOXH JD]RZD! HQXPHUDWLRQYDOXH NDUáRZDWD! UHVWULFWLRQ! VLPSOH7\SH!! VLPSOH7\SHQDPH 86B6WDGLXP(ZROXFML7\SH! XQLRQPHPEHU7\SHV XV86B6WDGLXP(ZROXFML(QXPHUDWLRQ7\SHXV86B6WDGLXP(ZROXFML2WKHU7\SH! VLPSOH7\SH! VLPSOH7\SHQDPH 86B6WDGLXP(ZROXFML(QXPHUDWLRQ7\SH! UHVWULFWLRQEDVH VWULQJ! HQXPHUDWLRQYDOXH SURWRJZLD]GD! HQXPHUDWLRQYDOXH JZLD]GD! HQXPHUDWLRQYDOXH F]HUZRQ\ROEU]\P! HQXPHUDWLRQYDOXH ELDá\NDU]Há! HQXPHUDWLRQYDOXH VXSHUQRZD! HQXPHUDWLRQYDOXH! UHVWULFWLRQ! VLPSOH7\SH! VLPSOH7\SHQDPH 86B6WDGLXP(ZROXFML2WKHU7\SH! UHVWULFWLRQEDVH VWULQJ! SDWWHUQYDOXH RWKHU?Z^`! UHVWULFWLRQ! VLPSOH7\SH! VFKHPD!

67 7. TRANSFORMACJA POLSKIE SCHEMATU TOWARZYSTWO APLIKACYJNEGO INFORMACJI UML DO SCHEMATU PRZESTRZENNEJ APLIKACYJNEGO GML... ROCZNIKI GEOMATYKI 2012 m TOM X m ZESZYT 1(51) 69 Agnieszka Chojka 7. Transformacja schematu aplikacyjnego UML do schematu aplikacyjnego GML wymagania, ograniczenia i wybrane narzêdzia Rozdzia³ prezentuje metody transformacji schematu aplikacyjnego UML na odpowiadaj¹cy mu schemat aplikacyjny GML oraz aplikacje komputerowe wspomagaj¹ce takie przekszta³cenia. W rozdziale opisano równie ró nice w schematach aplikacyjnych GML otrzymanych przy zastosowaniu ró nych metod Metody transformacji UML do GML Mo na wyró niæ dwie metody przekszta³cania schematu aplikacyjnego UML na schemat aplikacyjny GML: metodê rêczn¹ i metodê automatyczn¹. W tabeli 7.1 zestawiono wymagania dla obu metod, jak równie ich wady i zalety. Tabela 7.1. Porównanie metod transformacji schematu aplikacyjnego UML na schemat aplikacyjny GML Metoda Wymagani a Zalet y Wady R êczna dobra znajomoœæ normy ISO 19136, w szczególnoœci za³¹cznika E (regu³a kodowania schematów aplikacyjnych UML-GML) narzêdzie (darmowe lub komercyjne) wspomagaj¹ce tworzenie plików XSD ( XML Schema), np. XMLSpy Automatyczna podstawowa znajomoœæ normy ISO oprogramowanie (komercyjne) Rational Rose lub Enterprise Architect umo liwiaj¹ce w³aœciwe przygotowanie schematu aplikacyjnego UML (plik profilu UML z metkami) oprogramowanie (bezp³atne) umo liwiaj¹ce transformacjê UML-GML, np. ShapeChang e lub FullMoon pe³na kontrola procesu transformacji metoda szybka gwarancja zgod- noœci z normami ISO serii metoda mudna i pracoch³onna nietrudno o pomy³kê koniecznoœæ insta- lacji wielu aplikacji skomplikowana konfiguracja oprogra- mowania (zw³aszcza F ullmoon) ustawienie odpowied- nich metek w UML

68 70 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML Metoda rêczna m Metoda rêczna wymaga przede wszystkim bardzo dobrej znajomoœci norm ISO serii 19100, w szczególnoœci ISO/TS i ISO 19109, które okreœlaj¹ zasady budowy schematów aplikacyjnych UML oraz normy ISO 19136, za³¹cznik E, w którym zdefiniowano regu³ê kodowania schematów aplikacyjnych UML do GML. W metodzie tej wystarczy opracowaæ schemat aplikacyjny UML w dowolnym narzêdziu wspomagaj¹cym tworzenie diagramów klas UML (równie dobrze taki schemat mo na narysowaæ na kartce papieru), a nastêpnie korzystaj¹c z normy ISO napisaæ kod GML odpowiadaj¹cy schematowi aplikacyjnemu UML. Najlepiej skorzystaæ tutaj z oprogramowania (bezp³atnego lub komercyjnego), które wspomaga tworzenie plików XSD (XML Schema) i dokonuje ich walidacji (kontrola poprawnoœci sk³adniowej). Przyk³adem takiego oprogramowania (komercyjnego) jest XMLSpy firmy Altova (rys. 7.1). Aplikacja ta, to najbardziej wszechstronne narzêdzie do projektowania zaawansowanych aplikacji XML: m stanowi standard przemys³owy w dziedzinie œrodowiska projektowego dla projektowania, edytowania i debugowania zaawansowanych aplikacji wykorzystuj¹cych technologie takie jak XML, XML Schema, XSL/XSLT, SOAP, WDSL i Web services, m umo liwia automatyczne generowanie kodu dla aplikacji w wielu jêzykach programowania, rozszerza i uzupe³nia technologie takie jak J2EE,.NET, Eclipse oraz jest podstawowym narzêdziem dla programistów wykorzystuj¹cych najnowsze technologie XML, Web services oraz bazy danych. W zale noœci od mo liwoœci, plik GML (XSD) mo na równie opracowaæ w zwyk³ym notatniku, a nastêpnie skorzystaæ z dostêpnych w Internecie darmowych walidatorów webowych plików XSD: m walidator dla XML Schema REC ( ) version (rys. 7.2), dostêpny pod adresem: m XML Schema Validator (rys. 7.3), dostêpny pod adresem: Rêczne opracowanie schematu aplikacyjnego GML (np. w XMLSpy) mog³oby przebiegaæ w nastêpuj¹cych krokach: 1) utworzenie nowego pliku XSD, 2) przypisanie odpowiedniej przestrzeni nazw. 3) zaimportowanie schematu gml (gml.xsd) z gml.xsd, 4) utworzenie typów prostych i typów z³o onych, 5) dodatnie elementów (odpowiedniki atrybutów w UML) do typów z³o onych, 6) ustawienie licznoœci elementów bêd¹cych odpowiednikami atrybutów w UML, 7) dodanie elementów do typów w³aœciwoœci, 8) ustawienie atrybutów powi¹zania (roli), 9) zdefiniowanie zawi¹zków miêdzy elementami (klasami UML) dodanie atrybutów-ról do w³aœciwych klas i przypisanie im odpowiednich typów, ustawienie krotnoœci, 10) opcjonalnie dopisanie <gml:reverseproperty> w powi¹zaniach dwukierunkowych, 11)przeprowadzenie walidacji utworzonego schematu GML (tak naprawdê powinna odbywaæ siê po ka dej operacji, poniewa ³atwiej wtedy wychwyciæ b³êdy w schemacie), 12) zapisanie pliku projektu.

69 Rys Œrodowisko pracy w XML Spy

70 Rys Walidator dla XML Schema REC ( ) version Rys XML Schema Validator opracowany przez Christpha Schneegansa

71 7. TRANSFORMACJA SCHEMATU APLIKACYJNEGO UML DO SCHEMATU APLIKACYJNEGO GML Metoda automatyczna Metoda automatyczna wymaga przede wszystkim odpowiedniego oprogramowania, które umo liwia automatyczne wygenerowanie schematu aplikacyjnego GML ze schematu aplikacyjnego UML. Obecnie dostêpne s¹ dwa takie narzêdzia: ShapeChange i FullMoon, oba bezp³atne. Jednak wymagaj¹ one dodatkowo wykorzystania komercyjnego oprogramowania Enterprise Architect lub Rational Rose pozwalaj¹cego na w³aœciwe przygotowanie wyjœciowego schematu aplikacyjnego UML (plik profilu UML z odpowiednimi metkami). Dla programu Rational Rose odpowiednie pliki konfiguracyjne s¹ do³¹czone do oprogramowania ShapeChange (w katalogu config). Program ShapeChange Oprogramowanie pozwalaj¹ce na generowanie poprawnych schematów aplikacyjnych GML (GML 3.2.1) ze schematów aplikacyjnych UML, przy czym modele UML nale y opracowaæ zgodnie z zasadami okreœlonymi w dokumencie UGAS Guidelines and Encoding Rules (Portele, 2008a). ShapeChange wymaga zapisania modeli UML w formacie XMI (ang. XML Metadata Interchange), który pe³ni rolê poœrednika w wymianie modeli miêdzy ró nymi narzêdziami. Jest to aplikacja Java, wiêc mo e byæ uruchomiona z poziomu wiersza poleceñ. Ró ne parametry poleceñ pozwalaj¹ na dostosowanie regu³ kodowania schematu aplikacyjnego UML na GML. ShapeChange jest us³ug¹ kodowania zgodnie z norm¹ ISO i implementuje operacjê generowania XML Schema (generatexmlschema). Aktualnie dostêpna publicznie wersja tego oprogramowania to 1.0. Zosta³a opracowana na podstawie nastêpuj¹cych dokumentów ISO/TC 211 i OGC: m GML (ISO/TC 211, 2007a lub Portele, 2007), m ISO/TS 19139:2007, m ISO rev. 1 (draft), m ISO/TS 19103:2005 and ISO (draft), m ISO 19109:2005 (Portele, 2008b). HollowWorld i FullMoon HollowWorld jest œrodowiskiem, które umo liwia ekspertom (w danej dziedzinie) wykorzystuj¹cym informacjê przestrzenn¹ (geograficzn¹) na tworzenie schematów pojêciowych dla ich dziedzin zastosowañ, które z kolei odpowiadaj¹ normom miêdzynarodowym w zakresie interoperacyjnoœci informacji przestrzennej. Tak opracowane modele mog¹ zostaæ ³atwo przekszta³cone na odpowiadaj¹ce im schematy GML (XML Schema), które okreœlaj¹ format dokumentu na potrzeby przesy³ania danych (z danej dziedziny) jako standardowy dokument XML, zgodny ze specyfikacj¹ WFS opracowan¹ przez OGC. HollowWorld umo liwia wykorzystanie specjalnego szablonu UML, który zawiera komponenty opisane w normach ISO serii 19100, g³ównie z ISO/TC 211 Harmonized Model (ISO/TC 211, 2012). Ponadto dla u ytkowników oprogramowania Enterprise Architect (firmy Sparx Systems) opracowano profil UML zawieraj¹cy standardowe stereotypy i metki okreœlone przez normê ISO Implementacja modelu w XML Schema mo e zostaæ wygenerowana automatycznie, przy czym model UML musi stosowaæ siê do regu³ opisanych w za³¹czniku E do normy ISO 19136, a w szczególnoœci musi zawieraæ:

72 72 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... m okreœlone kierunki nawigacji i nazwy ról dla powi¹zañ asocjacyjnych, m tylko standardowe stereotypy, m wymagane metki. FullMoon XML Processing Framework to oprogramowanie narzêdziowe, które umo liwia ³atwe przekszta³cenie schematu aplikacyjnego na jego reprezentacjê w XML Schema. Zosta³o opracowane na potrzeby przetwarzania du ych modeli UML wed³ug regu³ kodowania okreœlonych w normach ISO 19118, ISO oraz FullMoon przetwarza model UML zapisany w formacie XMI, tworz¹c XML Schema (Githaiga, 2010; Cox, 2011). Oprogramowanie Enterprise Architect (firmy Sparx Systems) Zaawansowane narzêdzie do modelowania systemów za pomoc¹ UML (rys. 7.4). Charakteryzuje siê: m pe³nym wsparciem dla specyfikacji UML 2.0 (wszystkie 13 rodzajów diagramów), m intuicyjnym i ergonomicznym interfejsem u ytkownika (du a liczba pasków narzêdzi, dokowalnych okien i styli wizualizacji), m wsparciem dla technologii MDA, m ³atwoœci¹ tworzenia dokumentacji. W metodzie automatycznej kluczowym etapem jest odpowiednie przygotowanie schematu aplikacyjnego UML w œrodowisku Enterprise Architect. Przede wszystkim nale y skorzystaæ z odpowiedniego repozytorium modeli ISO ( a w przypadku specyfikacji INSPIRE tak e z repozytorium INSPIRE ( inspire-twg.jrc.ec.europa.eu/svn/inspire-model/branches/public/) oraz ze specjalnego profilu UML dla GML. Jest to plik XML (dostêpny pod adresem w którym ka demu elementowi UML przypisano w³aœciwe metki u³atwiaj¹ce proces transformacji UML-GML. Opracowanie schematu aplikacyjnego UML w Enterprise Architect mog³oby przebiegaæ wed³ug nastêpuj¹cych kroków: 1) utworzenie nowego projektu, 2) wczytanie ca³ego repozytorium ISO/TC211 lub tylko wybranych norm ISO (np , 19107, 19109), 3) wczytanie pliku profilu UML (dostêpny pod adresem europa.eu/svn/inspire-model/branches/public/uml_profile/), 4) nazwanie pakietu i diagramu, 5) dodanie diagramu pakietów, 6) przeci¹gniêcie z UML Profiles pakietu «application Schema» i przypisanie mu nazwy, 7) przeci¹gniêcie z UML Profiles potrzebnych klas («featuretype», «datatype», itd.), 8) przypisanie nazw klasom, 9) dodanie atrybutów, 10) okreœlenie licznoœci, widocznoœci i typu danych (ze specyfikacji ISO/TC 19103) dla atrybutów, 11) utworzenie zwi¹zków miêdzy klasami, 12) opisanie zwi¹zków rolami i krotnoœciami, 13) ustawienie nawigowalnoœci zwi¹zków, 14) ustawienie odpowiednich metek, zw³aszcza dla pakietu «application Schema», 15) Zapisanie gotowego modelu (rys. 7.5).

73 7. TRANSFORMACJA SCHEMATU APLIKACYJNEGO UML DO SCHEMATU APLIKACYJNEGO GML Rys Œrodowisko pracy w Enterprise Architect

74 74 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Rys Przyk³ad schematu aplikacyjnego w postaci diagramu klas UML Automatyczne wygenerowanie schematu aplikacyjnego GML ze schematu aplikacyjnego UML za pomoc¹ aplikacji ShapeChange lub FullMoon mog³oby przebiegaæ nastêpuj¹co: 1) otworzenie wczeœniej opracowanego schematu aplikacyjnego UML w Enterprise Architect, 2) eksport pakietu «application Schema» do formatu XMI (XML), 3) wprowadzenie odpowiednich ustawieñ dla pliku XML (ró ne dla obu aplikacji, m.in. rodzaj XMI dla ShapeChange XMI 1.0, dla FullMoon XMI 1.1), 4) uruchomienie aplikacji ShapeChange lub z FullMoon wiersza poleceñ. Na rysunku 7.6 przedstawiono gotowy plik XSD dla GML.

75 7. TRANSFORMACJA SCHEMATU APLIKACYJNEGO UML DO SCHEMATU APLIKACYJNEGO GML Rys Przyk³adowe przekszta³cenie wczeœniej utworzonego schematu aplikacyjnego UML na odpowiadaj¹cy mu schemat aplikacyjny GML

76 76 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML Podsumowanie Ró nice w wygenerowanych schematach aplikacyjnych GML Schematy aplikacyjne GML otrzymane przy u yciu ró nych metod ró ni¹ siê nieznacznie miêdzy sob¹. G³ówne ró nice widoczne s¹ w sposobie kodowania elementów typów w³aœciwoœci oraz zwi¹zków miêdzy klasami. Nale y równie zwróciæ uwagê na to, i w schematach aplikacyjnych utworzonych za pomoc¹ narzêdzia FullMoon brakuje mapowañ typów danych pochodz¹cych ze schematów znormalizowanych (np. CharacterString, GM_Surface). Aplikacja ma ustawione nieaktualne œcie ki do dokumentów zawieraj¹cych odpowiednie tablice mapowañ, a aktualizacja tych œcie ek powoduje niestety wadliwe funkcjonowanie oprogramowania. Kodowanie typów w³aœciwoœci Zgodnie z norm¹ ISO 19136, dla klas UML ze stereotypem «datatype» lub «featuretype» w XML Schema nale y utworzyæ nazwane typy z³o one, których nazwa zawiera nazwê danej klasy UML oraz przyrostek PropertyType. Aby w GML wyraziæ zwi¹zek posiadania miêdzy klasami, do takiego typu w³aœciwoœci nale y dodaæ grupê atrybutów gml:ownershipattributegroup. Przez posiadanie nale y tu rozmieæ posiadanie jednej klasy przez drug¹, to znaczy e jedna klasa UML posiada atrybut typu inna klasa UML. Natomiast, gdy zachodzi potrzeba odwzorowania zwyk³ego powi¹zania (asocjacji) miêdzy klasami UML, wtedy do typu w³aœciwoœci nale y dodaæ grupê atrybutów gml:associationattributegroup. W schemacie aplikacyjnym GML wygenerowanym przez ShapeChange dla klasy ze stereotypem «datatype» do typu w³aœciwoœci nie dodano adnej grupy atrybutów, natomiast w schemacie otrzymanym z aplikacji FullMoon typ w³aœciwoœci mia³ przypisan¹ grupê gml:ownershipattributegroup. W przypadku klas ze stereotypem «featuretype», niezale nie od zastosowanej metody transformacji UML do GML, ka dy typ w³aœciwoœci mia³ przypisane obie grupy atrybutów. Kodowanie zwi¹zków miêdzy klasami UML Role w powi¹zaniach miêdzy klasami UML w GML s¹ przekszta³cane na elementy lokalne z t¹ sam¹ nazw¹ typu z³o onego, który definiuje model zawartoœci typu obiektu. Jeœli powi¹zanie jest opisane z dwóch stron rolami, obie s¹ przekszta³cane na GML i dodatkowo do ich opisu stosowany jest element gml:reversepropertyname, umieszczony wewn¹trz elementów annotation i appinfo, który wskazuje nazwê roli na drugim koñcu powi¹zania. W przypadku powi¹zañ z jedn¹ nazwan¹ rol¹, zarówno ShapeChange, jak i FullMoon poprawnie (zgodnie z norm¹ ISO 19136) koduj¹ takie elementy (pod warunkiem, e s¹ to role klas Ÿród³owych, tzn. klas od których rysowane jest powi¹zanie w Enterprise Architect). Natomiast w przypadku powi¹zañ opisanych dwiema rolami, ShapeChange koduje tylko rolê klasy docelowej (tzn. klasy, do której rysowane jest powi¹zanie w Enterprise Architect) i bez elementu gml:reversepropertyname. Z kolei aplikacja FullMoon koduje obie role, równie bez dodatkowego elementu gml:reversepropertyname, ale niestety z b³êdem. Asocjacja kodowana jest poprawnie od strony klasy docelowej, ale b³êdnie nazwana jest rola od strony klasy Ÿród³owej (nazywa siê tak samo jak rola klasy docelowej ) i ma ona równie b³êdnie przypisany typ danych. Poni ej przedstawiono odpowiednie fragmenty kodu GML obrazuj¹ce powy sze ró nice.

77 7. TRANSFORMACJA SCHEMATU APLIKACYJNEGO UML DO SCHEMATU APLIKACYJNEGO GML Przyk³ad zapisu metod¹ rêczn¹ [VFRPSOH[7\SHQDPH 13B']LDOND7\SH! «««[VVHTXHQFH! «««[VHOHPHQWQDPH ZODVFLFLHOW\SH QS13B2VRED3URSHUW\7\SHPD[2FFXUV XQERXQGHG! [VDQQRWDWLRQ! [VDSSLQIR! JPOUHYHUVH3URSHUW\!QSZODVQRVFJPOUHYHUVH3URSHUW\! [VDSSLQIR! [VDQQRWDWLRQ! [VHOHPHQW! [VVHTXHQFH! [VFRPSOH[7\SH! [VFRPSOH[7\SHQDPH 13B2VRED7\SH! «««[VVHTXHQFH! «««[VHOHPHQWQDPH ZODVQRVFW\SH QS13B']LDOND3URSHUW\7\SHPLQ2FFXUV PD[2FFXUV XQ [VDQQRWDWLRQ! [VDSSLQIR! JPOUHYHUVH3URSHUW\!QSZODVFLFLHOJPOUHYHUVH3URSHUW\! [VDSSLQIR! [VDQQRWDWLRQ! [VHOHPHQW! [VVHTXHQFH! [VFRPSOH[7\SH! Przyk³ad zapisu oprogramowaniem ShapeChange FRPSOH[7\SHQDPH 13B']LDOND7\SH! «««VHTXHQFH! «««HOHPHQWQDPH ZODVFLFLHOW\SH QS13B2VRED3URSHUW\7\SHPD[2FFXUV XQERXQGHG! VHTXHQFH! FRPSOH[7\SH! Przyk³ad zapisu oprogramowaniem FullMoon FRPSOH[7\SHQDPH 13B']LDOND7\SH! «««VHTXHQFH! «««HOHPHQWQDPH ZODVQRVFW\SH QS13B']LDOND3URSHUW\7\SHPLQ2FFXUV PD[2FFXUV XQE VHTXHQFH! FRPSOH[7\SH! FRPSOH[7\SHQDPH 13B2VRED7\SH! «««VHTXHQFH! «««HOHPHQWQDPH ZODVQRVFW\SH QS13B']LDOND3URSHUW\7\SHPLQ2FFXUV PD[2FFXUV XQE VHTXHQFH! FRPSOH[7\SH!

78

79 8. PRZYK AD POLSKIE ZASTOSOWANIA TOWARZYSTWO METOD MODELOWANIA INFORMACJI DANYCH Z PRZESTRZENNEJ ZAKRESU S U BY G-K ROCZNIKI GEOMATYKI 2012 m TOM X m ZESZYT 1(51) 79 Zenon Parzyñski 8. Przyk³ad zastosowania metod modelowania danych z zakresu S³u by Geodezyjno-Kartograficznej Obecnie obowi¹zuj¹ce standardy techniczne w geodezji w postaci instrukcji i wytycznych technicznych wymagaj¹ zmiany. W du ej czêœci s¹ przestarza³e technologicznie. Z drugiej strony stawiane s¹ zarzuty na przyk³ad wytycznym, e nie powinny obowi¹zywaæ, poniewa zosta³y w wadliwy sposób (z prawnego punktu widzenia) wprowadzone w ycie. Istnia³a wiêc coraz wiêksza potrzeba uporz¹dkowania tych kwestii. Czeka nas te spe³nienie wymagañ dyrektywy INSPIRE (EP&CEU, 2007), które dotycz¹ czêœci danych. W G³ównym Urzêdzie Geodezji i Kartografii (GUGiK) zosta³a podjêta decyzja, e zostan¹ opracowane projekty rozporz¹dzeñ w³aœciwego Ministra lub Rady Ministrów. Na przyk³ad w sprawie ewidencji miejscowoœci, ulic i adresów EMUiA, w sprawie bazy danych geodezyjnej ewidencji sieci uzbrojenia terenu, bazy danych obiektów topograficznych oraz mapy zasadniczej i innych. Rozporz¹dzenia te bêd¹ aktami wykonawczymi do ustawy o infrastrukturze informacji przestrzennej (Ustawa, 2010) i zast¹pi¹ obecne instrukcje i wytyczne techniczne. W nastêpnym kroku zostan¹ spe³nione wymagania przepisów wykonawczych (Implementing Rules) dyrektywy INSPIRE dotycz¹ce czêœci danych gromadzonych w geodezyjnych bazach danych Za³o enia przyjête w GUGiK przy opracowywaniu projektów rozporz¹dzeñ Projekty rozporz¹dzeñ bêd¹ siê sk³adaæ z dwóch czêœci. W czêœci pierwszej znajdzie siê w³aœciwy tekst projektu z ewentualnymi za³¹cznikami. Teksty projektów by³y przygotowywane przez grupy ekspertów z poszczególnych dziedzin zaanga owanych przez GUGiK. Czêœæ druga bêdzie siê sk³adaæ ze schematu aplikacyjnego UML, który bêdzie modelem struktury danych okreœlonej w czêœci pierwszej projektu rozporz¹dzenia, katalogu typów obiektów, schematu aplikacyjnego GML i struktury bazy danych. Bêd¹ one opracowane zgodnie z metodyk¹ modelowania pojêciowego, zdefiniowan¹ w normach miêdzynarodowych ISO serii Geographic Information: m Schematy aplikacyjne UML z norm¹ PN-EN-ISO Geographic information Rules for Application Schema (ISO/TC 211, 2005b) oraz ze specyfikacj¹ techniczn¹ ISO/TS Geographic information Conceptual schema language (ISO/TC 211, 2005a). m Katalog obiektów z norm¹ PN-EN-ISO Geographic information Methodology for feature cataloguing (ISO/TC 211, 2006). m Schematy aplikacyjne GML z norm¹ ISO Geographic information Geography Markup Language GML (ISO/TC 211, 2007a).

80 80 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Ograniczenia dotycz¹ce klas i atrybutów zosta³y zapisane w jêzyku Object Constraint Language (OCL) w wersji 2.2 opracowanym przez konsorcjum Object Management Group (OMG, 2010). Modele UML bêd¹ zharmonizowane ze sob¹ i zintegrowane z normami ISO serii Czêœciowo te bêd¹ w nich uwzglêdnione wybrane regu³y implementacyjne INSPIRE. Przy opracowywaniu modeli UML postanowiono wykorzystaæ koncepcjê Ogólnego Modelu Geodezyjnego (OMG) opublikowan¹ po raz pierwszy w materia³ach z XVII Konferencji PTIP w 2007 roku. (Pachelski, Parzyñski, 2007) Realizacja za³o eñ Wszystkie za³o enia uda³o siê zrealizowaæ jednak w ró nym stopniu. Trochê inaczej ni planowano przebieg³a realizacja idei OMG. Ogólny Model Geodezyjny mia³ zawieraæ definicje klas wykorzystywanych przy budowie kilku schematów aplikacyjnych dla projektów rozporz¹dzeñ i pierwsza wersja opiera³a siê na zale noœciach wystêpuj¹cych w katastrze pomiêdzy nieruchomoœciami, podmiotami i prawami do nieruchomoœci (rys. 8.1). Kolejnoœæ opracowywanych projektów rozporz¹dzeñ by³a jednak inna. Pocz¹tek stanowi³y projekty Ewidencji Miejscowoœci, Ulic i Adresów (EMUiA) oraz Zintegrowanego Systemu Informacji o Nieruchomoœciach (ZSIN). W zwi¹zku z tym zosta³ utworzony Model Podstawowy (jako praktyczna realizacja OMG), w którym by³y sukcesywnie umieszczane klasy pojawiaj¹ce siê w kolejnych schematach aplikacyjnych UML, o których jednoczeœnie by³o wiadomo, e bêd¹ wykorzystywane w kilku kolejnych modelach. Model Podstawowy zosta³ podzielony na 5 modeli (rys. 8.2). W modelu Dokument (rys. 8.3) jest zdefiniowana klasa BT_Dokument wraz z niezbêdnymi typami danych s³u ¹ca do opisu dokumentów, które s¹ podstaw¹ podejmowania ró nych dzia³añ w dziedzinie geodezji i kartografii, na przyk³ad dokonania aktualizacji bazy danych. Zosta³a przyjêta zasada, e w nazwach klas, atrybutów nie bêd¹ u ywane polskie litery: ¹, æ, ê, ³, ñ, ó, œ, Ÿ,, æ, itp. Rys Szkic Ogólnego Modelu Geodezyjnego

81 8. PRZYK AD ZASTOSOWANIA METOD MODELOWANIA DANYCH Z ZAKRESU S U BY G-K 81 Rys Modele utworzone w ramach Modelu Podstawowego. Rys Model Dokument. Z kolei w modelu Typy podstawowe (rys. 8.4) zosta³y zdefiniowane typy danych wykorzystywane w opracowywanych modelach. Typ BT_Identyfikator zosta³ wykorzystany w ka dej klasie reprezentuj¹cej dowolny obiekt przestrzenny (na wzór wymagañ INSPIRE), klasa BT_Zbior reprezentuje zbiory danych, które nie s¹ zbiorami danych przestrzennych. W BT_CyklZyciaInfo s¹ zapisywane daty pocz¹tku i koñca kolejnych wersji obiektów przechowywanych w zbiorach danych. W celu zrealizowania referencji do innych obiektów, które mog¹ siê znajdowaæ tak e w innych bazach (modelach) opracowane zosta³y modele Obiekt przestrzenny (rys. 8.5) i Referencja pomiêdzy obiektami infrastruktury (rys. 8.6), w których s¹ widoczne zale noœci pomiêdzy zbiorem danych przestrzennych, obiektem przestrzennym, referencyjnym obiektem oraz referencj¹ do obiektu. Klasa BT_ReferencjaDoObiektu zosta³a zdefiniowana jako: typ wyboru pozwalaj¹cy na zdefiniowanie bezpoœredniej (informacja o obiekcie zapisana bezpoœrednio w strukturze atrybutu definiuj¹cego odwo³anie) lub poœredniej (podanie identyfikatora IIP obiektu) referencji do instancji klasy dostêpnej w ramach krajowej infrastruktury informacji przestrzennej.

82 82 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Rys Model Typy Podstawowe. Rys Model Obiekt przestrzenny.

83 8. PRZYK AD ZASTOSOWANIA METOD MODELOWANIA DANYCH Z ZAKRESU S U BY G-K 83 Rys Model Referencja pomiêdzy obiektami IIP. Pewien element wymaga wyjaœnienia. Otó stereotyp «union» u yty w klasie BT_ReferencjaDoObiektu oznacza, e mamy kilka atrybutów do wyboru i wybieramy z nich jeden. W tym konkretnym przypadku wybór nastêpuje pomiêdzy atrybutem idiip a relacj¹ do klasy BT_ReferencyjnyObiektPrzestrzenny. Relacja w przypadku stereotypu «union» jest traktowana jak atrybut, wiêc mamy wybór pomiêdzy dwiema mo liwoœciami. Konkretne sposoby odwo³ywania siê do innych modeli czy baz zostan¹ omówione w dalszej czêœci tego rozdzia³u. Model Podstawowy jest zintegrowany z normami ISO, co oznacza, e s¹ w nim wykorzystywane typy i klasy zalecane w normach, na przyk³ad typ CharacterString w 19103; Date i DateTime w 19108, a MD_Metadata i CI_ResponsibleParty s¹ zdefiniowane w normie Przyk³ady schematów aplikacyjnych do projektów rozporz¹dzeñ Jak wy ej zosta³o stwierdzone Model Podstawowy stanowi³, oprócz norm ISO serii 19100, podstawê do budowy kolejnych schematów aplikacyjnych do poszczególnych projektów rozporz¹dzeñ. W du ym skrócie zostan¹ omówione dwa przyk³adowe konkretne schematy utworzone do projektów rozporz¹dzeñ dotycz¹cych ewidencji miejscowoœci, ulic i adresów (EMUiA) oraz mapy zasadniczej. Schemat aplikacyjny dla Ewidencji miejscowoœci, ulic i adresów W modelu dla EMUiA wykorzystane s¹ typy zdefiniowane w Modelu Podstawowym: BT_Identyfikator, BT_CyklZyciaInfo i BT_Dokument oraz jest okreœlona referencja do elementów danych w innej bazie danych. Oficjalna (obowi¹zuj¹ca) nazwa miejscowoœci jest przechowywana w Pañstwowym Rejestrze Nazw Geograficznych (PRNG) i dlatego w modelu zosta³a okreœlona referencja do PRNG, a konkretnie do klasy NG_NazwaGeografRP, której obiekty zawieraj¹ dane o nazwach geograficznych z terenu Polski. W schemacie aplikacyjnym UML dla EMUiA s¹ te wykorzystane klasy z norm ISO. W klasie AD_Miejscowosc wystêpuj¹ jako definicje typów atrybutów klasy: GM_Point, Area i GM_MultiSurface oraz typy zdefiniowane w modelu EMUiA, na przyk³ad AD_EndonimStandaryzowany. Fragment schematu aplikacyjnego dla EMUiA jest przedstawiony na rysunku 8.7.

84 84 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Rys Klasa AD_Miejscowosc ze schematu aplikacyjnego EMUiA. Schemat aplikacyjny dla mapy zasadniczej Innym przyk³adem wykorzystania Modelu Podstawowego mo e byæ schemat aplikacyjny dla mapy zasadniczej. Na mapie zasadniczej wystêpuj¹ obiekty znajduj¹ce siê w ró nych bazach danych. Oprócz napisów, siatki kwadratów i tym podobnych nie ma na mapie obiektu, który nie znajdowa³by siê w jakieœ bazie danych. Aby umieœciæ na mapie obiekt trzeba znaæ jego typ (decyduje o znaku na mapie), geometriê (decyduje o miejscu umieszczenia i o kszta³cie dla obiektów liniowych i powierzchniowych) oraz jakie ewentualne napisy nale y umieœæ na rysunku obiektu (np. numer dla dzia³ki czy budynku). Jest to wiêc odpowiednia sytuacja do zastosowania mechanizmu referencji do innych baz danych. Tak te wygl¹da schemat aplikacyjny dla mapy zasadniczej sk³ada siê g³ównie z klasy BT_ReferencjaDoObiektu. Na rysunku 8.8 jest przedstawiony ca³y schemat aplikacyjny dla mapy zasadniczej, podczas gdy dla EMUiA (rys.8.7) przedstawiono tylko czêœæ schematu aplikacyjnego. Klasa MZ_OgolnyObiekt jest reprezentacj¹ dowolnego typu obiektu, który ma zostaæ umieszczony na mapie, a w klasie KR_ObiektKarto s¹ przechowywane dane dotycz¹ce obiektów znajduj¹cych siê na kolejnych wersjach edytowanej mapy. Przy przygotowywaniu mapy prawie zawsze zachodzi potrzeba jej redakcji chocia by w minimalnym zakresie, to znaczy zmiany po³o enia czêœci opisów, jak na przyk³ad numerów dzia³ek, budynków, nazw ulic i tym podobne. Do ka dego schematu aplikacyjnego UML jest do³¹czany katalog typów obiektów opracowany zgodnie z norm¹ Jako przyk³ad pos³u y³ tu fragment katalogu typów obiektów dla mapy zasadniczej (tab. 8.1).

85 8. PRZYK AD ZASTOSOWANIA METOD MODELOWANIA DANYCH Z ZAKRESU S U BY G-K 85 Rys Schemat aplikacyjny Mapa zasadnicza. Klasa: Tabela 8.1. Fragment katalogu obiektów mapy zasadniczej MZ_OgolnyObiekt MZ_OgolnyObiekt Nazwa: Definicja: R elacja: Typ: Abstract Klasa bazowa: Ogólny obiekt S tereotypy: <<featuretype> > Rola: Dziedzina: Klasa, która jest abstrakcyjn¹ reprezentacj¹ dowolnego umieszczanego w bazie danych mapy zasadniczej Associatio n EGiB L icznoœæ : 0.. * Definicja: BT_ReferencjaDoObiektu Referencja do Ewidencji Gruntów i Budynków obiektu

86 86 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... W za³¹czniku do projektu rozporz¹dzenia zmieniaj¹cego rozporz¹dzenie o ewidencji gruntów i budynków s¹ zdefiniowane typy obiektów oraz informacje, jakie o tych obiektach zostan¹ skopiowane z bazy danych EGiB do bazy mapy zasadniczej. Tak przygotowane schematy aplikacyjne zintegrowane z normami ISO i zharmonizowane w du ej czêœci ze sob¹ (miêdzy innymi poprzez wykorzystanie Modelu Podstawowego) bêd¹ dobr¹ podstaw¹ do wykonania nastêpnego etapu realizacji zadañ projektowania i budowy infrastruktury krajowej.

87 9. NAJCZÊŒCIEJ POLSKIE POPE NIANE TOWARZYSTWO B ÊDY W MODELACH INFORMACJI UML DLA SCHEMATÓW PRZESTRZENNEJ APLIKACYJNYCH GML ROCZNIKI GEOMATYKI 2012 m TOM X m ZESZYT 1(51) 87 Janusz Michalak 9. Najczêœciej pope³niane b³êdy w modelach UML dla schematów aplikacyjnych GML W rozdziale 2.6 przedstawione s¹ podstawowe regu³y konstruowania modeli w jêzyku UML dedykowane schematom XSD dla jêzyka GML. Jednak sama znajomoœæ tych regu³ nie wystarczy do opracowania modelu w pe³ni poprawnego i u ytecznego. Tu trzeba powróciæ do metaforycznego porównania jêzyka GML do jêzyka naturalnego z rozdzia³u 2.2, poniewa model danych w UML nie jest celem samym w sobie, lecz jedynie drog¹ do opracowania schematu XSD lub (albo tak e) struktury bazy danych w jêzyku DDL. Aby napisaæ dobr¹ ksi¹ kê trzeba przedtem przeczytaæ wiele innych, zarówno dobrych jak i z³ych. Poznawanie z³ych przyk³adów jest tak e bardzo pouczaj¹ce. Z tego wzglêdu w rozdziale tym jest przedstawionych wiele przyk³adów b³êdów, których nale y unikaæ w modelach dedykowanych aplikacjom jêzyka GML UML jest cierpliwy jak papier Zarówno metodyka obiektowego modelowania danych, jak i jêzyk UML, który jest jej podstawowym narzêdziem, a tak e edytory dla tego jêzyka, na przyk³ad Rational Rose lub Enterprise Achitect nie posiadaj¹ wbudowanych mechanizmów chroni¹cych przed pope³nianymi b³êdami. Rysunek 9.1 przedstawia ca³kowicie b³êdny model danych ze wzglêdu na zastosowanie wykluczaj¹cych siê wzajemnie powi¹zañ pomiêdzy klasami. Podczas konstruowania takich powi¹zañ program nie sygnalizuje adnych nieprawid³owoœci. Kontynuuj¹c Rys Przyk³ad ca³kowicie b³êdnego diagramu klas UML opracowany programem Enterprise Architect.

88 88 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... porównanie do jêzyka naturalnego opisane w rozdziale 2.2 mo na powiedzieæ, e zarówno jêzyk UML jak i oprogramowanie dla niego przeznaczone s¹ cierpliwe jak papier ca³a odpowiedzialnoœæ za formaln¹ i merytoryczn¹ poprawnoœæ modelu spoczywa na jego autorze. W ró nych dokumentach i specyfikacjach stosowane s¹ ró ne okreœlenia dotycz¹ce stopnia ogólnoœci modeli i specyfikacji standardów. Przyjêty obecnie powszechnie podzia³ za metodyk¹ MDA na modele i specyfikacje niezale ne od platformy (PIM) i od niej zale ne (PSM) jest wyraÿnie widoczny, jednak stosowana jest tam czêsto ró na terminologia. Dotyczy to zarówno opracowañ OGC, jak i ISO/TC 211 i mo na zaobserwowaæ zmiany w stosowaniu tej terminologii z up³ywem lat. Z tego wzglêdu potrzebne jest uporz¹dkowanie w zakresie tych dwóch pojêæ. Okreœlenie platform-neutral jest synonimem okreœlenia platform-independent. Norma ISO okreœla, e model platform-neutral powinien byæ wyspecyfikowany zgodnie z regu³ami opisanymi w specyfikacji technicznej Czêsto u ywane w ró nych specyfikacjach pojêcie DCP (Distributed Computing Platform) jest odpowiednikiem pojêcia platforma dla systemów rozproszonych. W opracowanych dawniej dokumentach OGC odpowiednikiem kategorii platform-neutral jest okreœlenie abstrakcyjny (abstract), to znaczy niezale ny od DCP, czyli od kategorii platform. Te ró nice terminologiczne powoduj¹ pewne trudnoœci w zrozumieniu ról, jakie poszczególne dokumenty (standardy, normy i Rys Problem wyboru odpowiedniej geometrii dla okreœlonego wyró nienia przestrzennego. Hierarchia klas przestrzennych obiektów geometrycznych. Opracowane na podstawie normy ISO (ISO/TC 211, 2003) przy pomocy programu narzêdziowego Rational Rose.

89 9. NAJCZÊŒCIEJ POPE NIANE B ÊDY W MODELACH UML DLA SCHEMATÓW APLIKACYJNYCH GML 89 specyfikacje) pe³ni¹ w ca³ej strukturze dokumentacyjnej dotycz¹cej danych geoprzestrzennych. Jest to tak e przyczyn¹ wielu niepoprawnych interpretacji poszczególnych dokumentów, szczególnie gdy nie bierze siê pod uwagê, e czêsto porównuje sie dokumenty, które powsta³y w ró nych okresach, w odstêpie czêsto kilku lub nawet kilkunastu lat. Konsekwencj¹ tych niepoprawnych interpretacji jest stosowanie elementów modeli abstrakcyjnych (obecnie okreœlanych jako platform-independent) w modelach dedykowanych jêzykowi GML bez sprawdzenia, jak¹ te elementy pe³ni¹ tam rolê i w jaki sposób s¹ zaimplementowane w GML. Przyk³adem tego jest specyfikowanie atrybutu geometrycznego jako typ abstrakcyjny GM_Object najwy ej po³o ony w hierarchii typów geometrii (rys. 9.2). Pozwala to na u ycie w zapisie danych dowolnego z tej hierarchii typu od GM_Point do GM_MultiSolid dla wyró - nieñ (feature) nale ¹cych do tej samej kategorii w elementach tego samego typu. Aby model abstrakcyjny (platform-independent) z konstrukcjami lub elementami niespe³niaj¹cymi wymagañ transformacji lub pozostawiaj¹cymi niejednoznacznoœci móg³ byæ zaimplementowany, potrzebne jest dokonanie niezbêdnych zmian i przyk³ad takich zmian przedstawia rysunek 9.3. Z tego wzglêdu, jedn¹ z podstawowych zasad jest uwzglêdnianie w Asocjacja zosta³a zamieniona na atrybut Rys Fragment diagramu XSD, w którym wystêpuje atrybut multisurfacelod3, w miejscu którego w modelu UML by³a asocjacja klas¹ GM_MultiSurface i rol¹ o takiej samej nazwie jak nazwa atrybutu. Przyk³ad ze specyfikacji danych INSPIRE tematu Budynki (Buildings).

90 90 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... modelach abstrakcyjnych (PIM) w mo liwie jak najszerszym zakresie wymogów platformy, dla której ten model jest przeznaczony. Ujmuj¹c to inaczej, w miarê mo liwoœci modele niezale ne od platformy (PIM) powinny byæ jak najbardziej zbli one do modeli implementacyjnych (PSM). Inne przyk³ady niepoprawnoœci modeli dedykowanych jêzykowi GML s¹ przedstawione w rozdziale 11 poœwiêconym specyfikacjom danych dla tematów INSPIRE Wymagania dotycz¹ce modeli UML dla INSPIRE Obecnie trwaj¹ prace projektowe i specyfikacyjne nad za³o eniami technologicznymi infrastruktury INSPIRE. Istotn¹ czêœci¹ tego wieloaspektowego procesu jest opracowywanie specyfikacji danych dla poszczególnych tematów wyszczególnionych w trzech aneksach dyrektywy. W przypadku infrastruktury INSPIRE wymagania dotycz¹ce interoperacyjnoœci s¹ szczególnie wa ne, poniewa jej miêdzynarodowy charakter stwarza wiele problemów wynikaj¹cych z jednej strony z ró nic jêzykowych i kulturowych, a z drugiej z wielkiej ró norodnoœci danych przestrzennych zarówno pod wzglêdem ich treœci jak i formy. Procedura opracowywania modeli i generowania na ich podstawie schematów XSD jest w zasadzie typowa (rys. 9.4). Rys Procedura opracowywania modeli i generowania na ich podstawie schematów XSD. Najwa niejszym wynikiem koñcowym s¹ schematy XSD to one stanowi¹ podstawê zapisu danych INSPIRE. Nietypowe dla wiêkszoœci innych projektów, ale niezbêdne w takiej sytuacji jest przestrzeganie ogólnych zasad i szczegó³owych wskazówek obowi¹zuj¹cych w ka dym przypadku i w ka dym temacie dziedzinowym. Zasady te i wskazówki s¹ okreœlone w czterech dokumentach: m Ogólny Model Pojêciowy (GCM Generic Conceptual Model) dla danych INSPIRE (DT_DS, 2010a), m Metodyka opracowywania specyfikacji danych INSPIRE (DT_DS, 2008), m m Wytyczne dotycz¹ce kodowania danych przestrzennych INSPIRE (DT_DS, 2010b), Wytyczne dla stosowania w specyfikacjach danych INSPIRE tematów z aneksów II i III standardów dotycz¹cych obserwacji i pomiarów, a tak e us³ug SWE (Sensor Web Enablement) (CTWG-O&M, 2011). Nie ma mo liwoœci opisania wszystkich tych zaleceñ okreœlonych w tych dokumentach licz¹cych ponad 300 stron. W tej sytuacji mo na tu przedstawiæ jedynie kilka wybranych

91 9. NAJCZÊŒCIEJ POPE NIANE B ÊDY W MODELACH UML DLA SCHEMATÓW APLIKACYJNYCH GML 91 Rys Diagram klas przedstawiaj¹cy hierarchiê typów dla danych pokryæ (coverages) zdefiniowanych w GCM (Generic Conceptual Model) INSPIRE. najwa niejszych. Pierwszy z tych dokumentów razem z modelem UML i wygenerowanymi na jego podstawie schematami XSD stanowi fundament dla wszystkich modeli tematycznych. Miêdzy innymi zdefiniowane s¹ tam modele dla danych typu pokrycia (coverages), których ogólny model jest przedstawiony na rysunku 9.5. Uwzglêdniaj¹c fakt, e w ró nych krajach Unii Europejskiej zbiory danych dla poszczególnych tematów INSPIRE maj¹ ró n¹ zawartoœæ w zakresie szczegó³ów, wprowadzony zosta³ mechanizm pozwalaj¹cy na pominiêcie okreœlonych elementów w zapisie. W modelach danych te w³asnoœci klas (properties atrybuty lub nawigacyjne asocjacje) s¹ oznaczane stereotypem «voidable». W zapisie danych GML jest to wyra one za pomoc¹ atrybutu elementu nilreason (rys. 9.6A), który mo e przybieraæ wartoœci z listy kodowej VoidReasonValue. Lista ta ma dwa elementy: Unknown i Unpopulated, ale jako lista Rys Ró nica w zapisie danych pomiêdzy stereotypem «voidable» i licznoœci¹ [0..1] w UML. Objaœnienia w tekœcie.

92 92 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... kodowa jest rozszerzalna. Obok tego jest standardowa w UML mo liwoœæ podawania licznoœci z wartoœci¹ zero, co równie pozwala na pominiêcie takiego elementu (atrybutu lub nawigacyjnej asocjacji), jednak rezultat w zapisie danych jest inny (rys. 9.6B). W pierwszym przypadku musi istnieæ pusty element z atrybutem okreœlaj¹cym przyczynê, a w drugim ten element mo e niewystêpowaæ. Kolejna konstrukcja wymagaj¹ca szczególnej uwagi to powi¹zanie klas kompozycj¹ (siln¹ agregacj¹). Problem ten nie jest ograniczony tylko do modeli INSPIRE, ale jest istotny we wszystkich aplikacjach jêzyka GML. Powi¹zanie kompozycyjne oznacza, e obiekty nale ¹ce do klasy KlasaKomponent (rys. 9.7A) s¹ sk³adnikami obiektów klasy KlasaKompozycyjna i nie mog¹ bez nich istnieæ. Praktyczna realizacja powi¹zania kompozycyjnego w XML jest trudna, bo wszystkie powi¹zania s¹ tam realizowane w formie zwyk³ych asocjacji z nawigacj¹ przy pomocy konstrukcji xlink:ref i nie ma mechanizmu gwarantuj¹cego usuwanie elementów sk³adowych, gdy zostaje usuniêty element kompozycyjny. Znaczenie kompozycji z punktu widzenia metodyki jêzyka UML jest bardzo zbli one do znaczenia atrybutu typu innej klasy (rys. 9.7B). Czêsto spotyka siê opiniê, e obie te konstrukcje s¹ równowa ne, jednak w pewnych szczególnych implementacjach ró nica pomiêdzy nimi mo e mieæ znaczenie. Nie dotyczy to jednak implementacji bazuj¹cych na XML. W jêzyku GML przyjmuje siê, e sk³adniki klas (elementy nale ¹ce do elementu z³o onego) mog¹ byæ okreœlone jako w³asne wewnêtrzne (in-line, jako by-value lub byrepresentation) albo istnieæ na zewn¹trz, jako elementy niezale ne i jedynie przypisane do klasy macierzystej przez znajduj¹cy siê w niej odsy³acz (by-reference). Pierwszy przypadek odpowiada konstrukcji UML przedstawionej w czêœci B rysunku 9.7, a drugi nie jest realizacj¹ kompozycji, lecz raczej zwyk³ej agregacji lub zwyk³ej asocjacji. Rys Powi¹zanie kompozycyjne (z czarnym rombem) mo e byæ zast¹pione umieszczeniem w klasie nadrzêdnej (w tym przypadku KlasaZ³o ona) atrybutu typu klasy podrzêdnej (w tym przypadku KlasaAtrybutowa). Objaœnienia w tekœcie. Kolejny istotny dla danych INSPIRE problem to identyfikatory. Wystêpuj¹ tam trzy ich rodzaje: m Identyfikatory GML (przyk³ad 9.1) miêdzy innymi s³u ¹ do okreœlania nawigacyjnych powi¹zañ i w ten sposób s¹ realizacj¹ asocjacji pomiêdzy klasami w jêzyku UML. m Identyfikatory INSPIRE (przyk³ad 9.2) przeznaczone s¹ do wyszukiwania elementów danych za pomoc¹ us³ug CSW. Ka de wyró nienie (klasa ze stereotypem

93 9. NAJCZÊŒCIEJ POPE NIANE B ÊDY W MODELACH UML DLA SCHEMATÓW APLIKACYJNYCH GML 93 m «featuretype») w zbiorach danych tematów aneksu I i II dyrektywy INSPIRE musi posiadaæ taki identyfikator. Nie mo e on mieæ stereotypy «voidable», ale mo e miêæ licznoœæ [0..1]. Inne dziedzinowe identyfikatory, na przyk³ad dla czêœci wody (water body) okreœlonych dyrektyw¹ wodn¹ (WFD Water Framework Directive). Do tej grupy nale ¹ tak e ró ne identyfikatory przyjête w poszczególnych krajach cz³onkowskich. Przyk³ad 9.1. Identyfikator GML MDNL (OHPHQW! JPOLGHQWLILHUFRGH6SDFH KWWSLQVSLUHMUFHFHXURSDHX! XUQ[LQVSLUHREMHFWLG3/36+%+ JPOLGHQWLILHU! MDNL (OHPHQW! Przyk³ad 9.2. Identyfikator INSPIRE MDNL (OHPHQW! WHVWLQVSLUH,G! EDVH,GHQWLILHU! EDVHORFDO,G!EDVHORFDO,G! EDVHQDPHVSDFH!3/36+%+EDVHQDPHVSDFH! EDVH,GHQWLILHU! WHVWLQVSLUH,G! MDNL (OHPHQW! Identyfikatory GML, jak przedstawiono to wczeœniej, pozwalaj¹ realizowaæ powi¹zania nawigacyjne pomiêdzy elementami danych. Powi¹zania te mog¹ byæ lokalne, gdy jest to odwo³anie do elementu, który znajduje siê w tym samym zbiorze danych (przyk³ad 9.3) lub odleg³e, gdy element jest gdzieœ indziej (przyk³ad 9.4). Odwo³anie lokalne jest bardzo proste, poniewa wystarczy jedynie podaæ etykietê znajduj¹c¹ siê w tym samym pliku. W przypadku danych INSPIRE t¹ etykiet¹ jest identyfikator GML. Przyk³ad 9.3. Odwo³anie do elementu lokalnego (w tym samym miejscu) za pomoc¹ identyfikatora fragmentu (poprzedzony znakiem #) lub identyfikatora GML WHVWMDNL (OHPHQW[OLQNKUHI 3/36+%+! OXE WHVWMDNL (OHPHQW[OLQNKUHI XUQ[LQVSLUHREMHFWLG3/36+%+! Bardziej skomplikowanym przypadkiem jest odwo³anie do elementu odleg³ego (przyk³ad 9.4). Poniewa odwo³anie powinno zagwarantowaæ dostêp do wskazywanego elementu, w takiej sytuacji odsy³acz musi zawieraæ w sobie polecenie udostêpnienia tego elementu zgodne ze specyfikacj¹ WFS (Web Feature Service). Przyk³ad 9.4. Odwo³anie do elementu odleg³ego (w innych zasobach) za poœrednictwem WFS WHVWMDNL (OHPHQW [OLQNKUHI KWWSLQVSLUHJHRXZHGXSOWHVWEHGBZIVVHUYLFHV"6(59,&( :)6 9(56,21 5(48(67 *HW*PO2EMHFW )250$7 WH[W[POVXEW\SHJPO 75$9(56(;/,1.'(37+ *0/2%-(&7,' 3/36+%+3/36+%+!

94 94 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Przyk³ady 9.3 i 9.4 dotycz¹ realizacji asocjacji UML z nawigacj¹ jednokierunkow¹. W przypadku asocjacji z nawigacj¹ dwukierunkow¹ wystêpuj¹ dwa odwo³ania w przeciwnych kierunkach z obu elementów (rys.9.8), co w praktyce jest równowa ne dwóm przeciwstawnym asocjacjom jednokierunkowym. Bardziej restrykcyjn¹ form¹ zapisu identyfikatora INSPIRE (inspireid) jest u ycie jako identyfikatora lokalnego (element base:localid) wartoœci typu UUID (universally unique identifier) w postaci 32-cyfrowego zapisu heksadecymalnego (cyfry w zakresie 0-9 i litery w zakresie a-f) w piêciu grupach cyfr oddzielonych ³¹cznikami (rys. 9.9). Taki identyfikator powinien zawieraæ tak e oznaczenie jego wersji (versionid) w postaci daty i godziny utworzenia typu datetime (rys. 2.14). Rys. 9.8 Wzajemne wi¹zanie elementów zapisu danych w jêzyku GML jako implementacja dwukierunkowego powi¹zania asocjacyjnego w UML (Michalak i inni, 2011). Fragment przyk³adowego zapisu danych dla tematu Obszary chronione (Protected Sites) dyrektywy INSPIRE. Rys Konstrukcja identyfikatora wyró nienia geoprzestrzennego obiektu lub elementu (Michalak i inni, 2011). Konstrukcja ta jest zgodna z wymaganiami INSPIRE GCM Generic Conceptual Model (DT_DS, 2010a) i proponowana do zastosowañ w polskiej Infrastrukturze Informacji Przestrzennej (BGWM, 2009).

95 10. ZASTOSOWANIE POLSKIE METODYKI TOWARZYSTWO MDA WYBRANE ZAGADNIENIA INFORMACJI TRANSFORMACJI PRZESTRZENNEJ SCHEMATÓW... ROCZNIKI GEOMATYKI 2012 m TOM X m ZESZYT 1(51) 95 Agnieszka Zwirowicz-Rutkowska 10. Zastosowanie metodyki MDA wybrane zagadnienia transformacji schematów aplikacyjnych UML do struktur relacyjnych baz danych Jednym z zagadnieñ, pojawiaj¹cym siê w toku prac nad przygotowaniem danych, które maj¹ byæ przechowywane w bazie danych zgodnie z ustalonym schematem aplikacyjnym, jest utworzenie struktury bazy danych. Realizacja tego zadania, wymagaj¹ca wykonania odpowiednich mapowañ i transformacji, mo e odbywaæ siê manualnie, pó³automatycznie lub te automatycznie i mo e byæ przyk³adem wykorzystania metodyki MDA Transformacja w ujêciu metodyki MDA MDA (Model-Driven Architecture) wskazuje sposób projektowania produktu informatycznego (systemów informatycznych, oprogramowania lub struktur danych). Celem metodyki jest zapewnienie przenoœnoœci (przygotowane rozwi¹zanie mo e zostaæ uruchomione w ró nych systemach), interoperacyjnoœci i mo liwoœci wielokrotnego u ycia. Platforma jest to infrastruktura oprogramowania, która wymaga okreœlonej technologii (na przyk³ad CORBA, J2EE lub HTTP) i infrastruktury sprzêtowej (AB ORMSC, 2001). MDA okreœla metodykê i narzêdzia, które umo liwiaj¹: m przedstawienie systemu niezale nie od docelowych platform, m opisy platform, m wybór okreœlonej platformy dla konkretnego systemu, m przekszta³cenie specyfikacji systemu do wymagañ jednej konkretnej platformy. W metodyce tej wyró nia siê nastêpuj¹ce modele: m CIM (Computation Independent Model) model wymagañ, który okreœla dziedzinê przedmiotow¹ i funkcjonalnoœæ systemu, m PIM (Platform Independent Model) zawiera opis systemu (przyp. red. nauk.: w tym przypadku struktury i zawartoœci zbioru danych) bez podawania szczegó³ów m dotycz¹cych platform, PSM (Platform Specific Model) zawiera opis systemu z uwzglêdnieniem wymagañ dla konkretnej platformy. Model wymagañ (CIM) wykorzystywany jest do definicji modelu dziedziny (PIM). Pojedynczy model PIM mo e stanowiæ podstawê dla wielu ró nych modeli PSM, które s¹ implementowane zgodnie z wymaganiami technicznymi dla wybranych platform.

96 96 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Oddzielnie specyfikacji funkcjonalnej systemu (PIM) od specyfikacji implementacji tej funkcjonalnoœci w konkretnym œrodowisku (PSM) niesie ze sob¹ wiele zalet: m ³atwoœæ sprawdzenia poprawnoœci modelu, który nie uwzglêdnia wymagañ, typów parametrów, regu³ dla okreœlonej platformy, m ³atwoœæ przygotowania implementacji na ró nych platformach, które opieraj¹ siê o ten sam model definiuj¹cy strukturê i zachowanie systemu, m PIM pozwala okreœliæ wymagania w zakresie integracji i interoperacyjnoœci, które s¹ nastêpnie mapowane z uwzglêdnieniem mechanizmów, charakterystycznych dla danej platformy. Rysunek 10.1 przedstawia zagadnienie transformacji schematu aplikacyjnego do struktury bazy danych w kategoriach pojêæ metodyki MDA. Pod pojêciem transformacji rozumie siê konwersjê jednego modelu na drugi model (AB ORMSC, 2001). Schemat aplikacyjny jest modelem PIM, zaœ strukturê bazy danych rozpatrywaæ mo na w ujêciu logicznym (model PSM) i fizycznym (implementacja). Zarówno model PIM, jak i PSM wyra one s¹ w jêzyku UML. Aby mo liwe by³o przedstawienie za pomoc¹ UML pewnych szczegó³owych wymagañ dla konkretnego modelu PSM, nale y ustaliæ zbiór rozszerzeñ i ograniczeñ UML, miêdzy innymi stereotypy i metki stworzyæ profil UML. Rys Transformacja schematu aplikacyjnego do struktury bazy danych w kategoriach pojêæ MDA. Ogólnie metodyka MDA zak³ada nastêpuj¹ce transformacje: m PIM PIM wystêpuje w przypadku wprowadzania poprawek, tworzenia kolejnych wersji modelu. m PIM PSM transformacja w celu odwzorowania modelu na infrastrukturê wykonawcz¹, któr¹ okreœla platforma sprzêtowa i oprogramowania, w oparciu o charakterystykê danej platformy. Opis charakterystyki powinien byæ wykonany za pomoc¹ UML. m PSM PSM transformacja wykonywana w celu aktualizacji wymagañ w stosunku do m infrastruktury (przyp. red. nauk.: w tym przypadku struktury i zawartoœci zbioru danych). PSM PIM transformacja wykonywana w celu wprowadzenia uniwersalnego zapisu (pojêciowego) w oparciu o zastosowan¹ implementacjê w konkretnej technologii (tak zwana in ynieria odwrotna). Do wykonania transformacji wymagane s¹ regu³y i techniki (mapowania), które pozwalaj¹ modyfikowaæ model, w celu otrzymania innego modelu. Miejsce mapowañ w podejœciu MDA przedstawia rysunek 10.2.

97 10. ZASTOSOWANIE METODYKI MDA WYBRANE ZAGADNIENIA TRANSFORMACJI SCHEMATÓW Rys Diagram klas przedstawiaj¹cy metodykê MDA. ród³o: opracowanie w³asne na podstawie przewodnika MDA (OMG, 2003) Ogólne zasady mapowania pomiêdzy modelem obiektowym i modelem relacyjnym W tabeli 10.1 przedstawiono przyk³adowe dokumenty w zakresie mapowañ modelu obiektowego do modelu relacyjnego oraz rozwi¹zania narzêdziowe umo liwiaj¹ce wykonanie transformacji. Dokumenty wymienione w tabeli s¹ opracowaniami korporacyjnymi, które mog¹ w pewnych szczegó³ach ró niæ siê od siebie, na przyk³ad w zakresie szczegó³owoœci opisów pojêæ, ograniczeñ i tym podobnych. Natomiast mo na wskazaæ kilka ogólnych regu³ dotycz¹cych przejœcia od modelu obiektowego do modelu relacyjnego: m komponent ze stereotypem «database» odwzorowywany na bazê danych, m pakiet ze stereotypem «schema» odwzorowywany na schemat, m klasa ze stereotypem «table» odwzorowywana na tabelê, m atrybut ze stereotypem «column» odwzorowywany na kolumnê, Tabela Przyk³adowe zestawienie narzêdzi realizuj¹cych mapowanie modelu obiektowego do modelu relacyjnego Nazwa firmy IBM (dawniej: Rational Rose) Sparx Systems Cincom Systems Dokumen t UML Data Modeling Profile UML Data Modeling Profil e UML Database Modelin g Narzêdzi e IBM Rational Rose Data Modeler i Rational Rose Enterpris e Enterprise Architec t UML DB

98 98 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... m stereotyp «PK» odwzorowywany na klucz g³ówny, m stereotyp «FK» odwzorowywany na relacjê. Regu³y te przedstawiono w dalszych podrozdzia³ach. Odwzorowanie modelu obiektowego na relacyjny wymaga uwzglêdnia tak e regu³y miêdzy innymi w zakresie: m opcjonalnoœci atrybutów, nadawania statusu klucza g³ównego oraz niepowtarzalnoœci wartoœci dla poszczególnych atrybutów, m ró nych rodzajów zwi¹zków stosowanych w diagramach klas UML, na przyk³ad asocjacji i generalizacji, m prostych typów danych, m indeksów, m widoków (perspektyw). Komponent ze stereotypem «database» odwzorowywany na bazê danych W UML okreœla siê komponent ze stereotypem «database», dla którego podaje siê nazwê (rys. 10.3A). Baza danych jest to zbiór powi¹zanych danych z pewnej dziedziny, zorganizowanych w sposób dogodny do korzystania z nich, a zw³aszcza do szybkiego wyszukiwania danych potrzebnych w jednym lub wielu zastosowaniach (GaŸdzicki, 2004). Na rysunku 10.3B przedstawiono reprezentacjê bazy danych w oknie elementów modelu SZBD PostgreSQL/PostGIS. Rys A Komponent ze stereotypem «database». B Reprezentacja bazy danych w oknie elementów modelu SZBD PostgreSQL/PostGIS. Pakiet ze stereotypem «schema» odwzorowywany na schemat Pakiet ze stereotypem «schema» przedstawiono na rysunku 10.4A. Rys A Pakiet ze stereotypem «schema». B Reprezentacja schematu w oknie elementów modelu SZBD PostgreSQL/PostGIS. Schemat zawiera opis modelu danych (rys. 10.4B).

99 10. ZASTOSOWANIE METODYKI MDA WYBRANE ZAGADNIENIA TRANSFORMACJI SCHEMATÓW Klasa ze stereotypem «table» odwzorowywana na tabelê Klasê ze stereotypem «table» przedstawiono na rysunku Rys A Reprezentacja graficzna klasy ze stereotypem «table». B w³aœciwoœci klasy «table». Tabela jest podstawow¹ struktur¹ relacyjnej bazy danych (rys. 10.6). Rys Reprezentacja tabeli w oknie elementów modelu SZBD PostgreSQL/PostGIS. Atrybut ze stereotypem «column» odwzorowywany na kolumnê W klasie z stereotypem «table» poszczególne atrybuty opatrzone s¹ stereotypem «column» (rys. 10.7A). Rys A Atrybuty ze stereotypem «column» w klasie UML. B Reprezentacja kolumn w oknie elementów modelu SZBD PostgreSQL/PostGIS. Tabela sk³ada siê z kolumn (rys. 10.7B).

100 100 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Stereotyp «PK» odwzorowywany na klucz g³ówny W klasie, przed atrybutem stosowany jest zapis PK (klucz g³ówny). Ponadto w sekcji operacji stosowany jest stereotyp «PK» (rys. 10.8A). Rys A Oznaczenie klucza g³ównego w klasie UML. B Oznaczenie klucza g³ównego w oknie elementów modelu SZBD PostgreSQL/PostGIS. Klucz g³ówny w sposób jednoznaczny identyfikuje pojedynczy wiersz, natomiast klucz obcy pozwala na tworzenie relacji miêdzy tabelami (rys. 10.8B). Stereotyp «FK» odwzorowywany na relacjê Relacja jest wykazywana w postaci asocjacji ze stereotypem «FK» i kluczami: g³ównym i obcym (rys. 10.9). Rys Oznaczenie klucza obcego w klasie UML. Ka da relacja jest miêdzy tabel¹ rodzic i tabel¹ dziecko. Tabela rodzic musi mieæ zdefiniowany klucz g³ówny, który w tabeli dziecko wykazywany jest jako klucz obcy i jako operacja ze stereotypem ograniczenie FK (rys ). Rys Oznaczenie klucza obcego w oknie elementów modelu SZBD PostgreSQL/PostGIS.

101 10. ZASTOSOWANIE METODYKI MDA WYBRANE ZAGADNIENIA TRANSFORMACJI SCHEMATÓW Transformacja schematu aplikacyjnego UML do logicznej struktury relacyjnej bazy danych Realizacjê MDA i transformacjê schematu aplikacyjnego UML do logicznej struktury relacyjnej bazy dany przestrzennych przedstawiono na przyk³adzie wykonanym przy pomocy programu Enterprise Architect. Fizyczna struktura relacyjnej bazy danych zaprezentowana jest w programie MS Access oraz PostgreSQL/PostGIS. Zadanie to wykonane zosta³o w trzech krokach: 1) przygotowanie schematu aplikacyjnego UML (rys ), 2) automatyczne wykonanie transformacji PIM PSM (rys ), 3) przygotowanie fizycznej struktury bazy danych (rys ). Krok 1. Przygotowanie schematu aplikacyjnego UML Szczegó³y dotycz¹ce zasad budowy schematu zawarte s¹ w rozdziale 5. W sposób pogl¹dowy krok ten przedstawia rysunek 10.11A. Fragment schematu aplikacyjnego przedstawia rysunek 10.11B. Rys A Pogl¹dowe przedstawienie kroku 1. B Fragment schematu aplikacyjnego INSPIRE dotycz¹cego tematu dzia³ki ewidencyjne (TWG-CP, 2010). Krok 2. Automatyczne wykonanie transformacji PIM PSM W sposób pogl¹dowy krok ten przedstawia rysunek 10.12A. W analizowanym przyk³adzie wybrano i wykonano transformacjê do DDL (rys B) wykorzystuj¹c funkcjê programu Enterprise Architect.

102 102 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Rys A Pogl¹dowe przedstawienie kroku 2. B Okno wyboru transformacji. Wynik transformacji model PSM przedstawia rysunek Rys Wynik transformacji do DDL model PSM. Wa n¹ kwestiê przed wygenerowaniem skryptu DDL stanowi¹ ustalenia w zakresie docelowej bazy danych (rys ). Dziêki temu skrypt SQL bêdzie zawiera³ definicje charakterystyczne dla danej bazy (np. w zakresie typów danych).

103 10. ZASTOSOWANIE METODYKI MDA WYBRANE ZAGADNIENIA TRANSFORMACJI SCHEMATÓW Rys Wybór docelowej bazy danych lista SZBD dostêpna w programie Enterprise Architect w polu o nazwie Database. Nastêpnie istnieje mo liwoœæ wykorzystania funkcji Enterprise Architect w zakresie automatycznego generowania skryptu DDL. Okno ustawieñ w zakresie skryptu SQL przedstawia rysunek Rys Okno ustawieñ procesu generowania skryptu DDL.

104 104 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Fragment automatycznie wygenerowanego skryptu DDL dedykowanego SZBD MS Access przedstawia rysunek 10.16, a dedykowanego SZBD PostgreSQL rysunek Rys Podgl¹d automatycznie generowanego skryptu DDL dedykowanego MS Access. Rys Podgl¹d automatycznie generowanego skryptu DDL dedykowanego PostgreSQL.

105 10. ZASTOSOWANIE METODYKI MDA WYBRANE ZAGADNIENIA TRANSFORMACJI SCHEMATÓW Skrypt DDL dedykowany konkretnemu SZBD uwzglêdnia typy danych w³aœciwe dla danej bazy danych. W skrypcie dedykowanym MS Access wykorzystywany jest typ daty DateTime, natomiast w skrypcie dedykowanym PostgreSQL timestamp. Krok 3. Przygotowanie fizycznej struktury bazy danych W sposób pogl¹dowy krok ten przedstawia rysunek Rys Pogl¹dowe przedstawienie kroku 3. W przedstawianym przyk³adzie utworzenie fizycznej struktury bazy danych wi¹ e siê z wczytaniem i uruchomieniem skryptu SQL. Etap ten powinna poprzedziæ weryfikacja, korekta b¹dÿ uzupe³nienie skryptu DDL, miêdzy innymi w zakresie typów danych (na przyk³ad CharacterString, Area, GM_Object) i atrybutów (na przyk³ad geometry w przypadku systemów zarz¹dzania baz¹ danych bez odniesieñ przestrzennych), wynikaj¹ce z zastosowania na etapie schematu aplikacyjnego UML norm serii ISO w dziedzinie informacji geograficznej. Tabelê BasicPropertyUnit w MS Access przedstawia rysunek 10.19, a w Postgre- SQL/PostGIS rysunek Rys Tabela BasicPropertyUnit w MS Access.

106 106 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Rys Tabela BasicPropertyUnit w PostgreSQL/PostGIS.

107 11. SCHEMATY POLSKIE APLIKACYJNE TOWARZYSTWO TEMATÓW ANEKSÓW INFORMACJI II I III DYREKTYWY PRZESTRZENNEJ INSPIRE ROCZNIKI GEOMATYKI 2012 m TOM X m ZESZYT 1(51) 107 Janusz Michalak 11. Schematy aplikacyjne tematów aneksów II i III dyrektywy INSPIRE Okres opracowywania specyfikacji danych dla aneksów II i III obejmuje czas od listopada 2010 do maja W tym okresie w 19 tematycznych zespo³ach roboczych TWG (Thematic Working Group) prowadzono prace dotycz¹ce 24 specyfikacji danych z zakresu 25 tematów (dane dwóch tematów dotycz¹cych atmosfery s¹ ujête w jednej specyfikacji). W czerwcu 2011 zosta³y udostêpnione publiczne wstêpne robocze wersje 2.0 tych specyfikacji. Do paÿdziernika tego roku w poszczególnych krajach cz³onkowskich Unii Europejskiej zespo³y stron zainteresowanych i zarejestrowanych w INSPIRE jako LMO (Legally Mandated Organisation) lub SDIC (Spatial Data Interest Community) prowadzi³y prace z zakresu testowania i oceny zawartych w specyfikacjach modeli danych w jêzyku UML i utworzonych na ich podstawie schematów XSD. Wyniki prac testowych wykaza³y potrzebê istotnych zmian. W konsekwencji okaza³ siê potrzebny jeszcze jeden dodatkowy etap prac w zespo³ach tematycznych nad przejœciowymi wersjami oznaczonymi numerem wersji 2.9 (Michalak, 2012). Te przejœciowe wersje tak e zosta³y poddane ocenie, jednak ju w znacznie ograniczonym niepublicznym zakresie. Termin zakoñczenia prac i opublikowania koñcowych wersji 3.0 to maj Proces prac nad tematami aneksów II i III by³ bardziej z³o ony ni nad tematami aneksu I, a rezultat nie jest w pe³ni do koñca zadawalaj¹cy. Z³o y³y siê na to trzy przyczyny: 1. Problematyka tych tematów jest bardziej skomplikowana, poniewa dotyczy z³o onych zjawisk przyrodniczych i spo³ecznych. Zjawiska te s¹ bardzo czêsto dynamiczne i silnie wzajemnie powi¹zane nie tylko w obrêbie poszczególnych tematów, ale tak e pomiêdzy ró nymi tematami. Dane w wielu przypadkach nie s¹ prostymi rejestrami zbiorów jednoznacznie zdefiniowanych obiektów, jak to by³o najczêœciej w specyfikacjach danych dla tematów I aneksu. Czêsto dotycz¹ przestrzennych lub czasowych tendencji zmian okreœlonych w³aœciwoœci œrodowiska lub zachodz¹cych w nim procesów. Wymownym przyk³adem by³a koniecznoœæ zastosowania danych typu pokrycie (coverage), czego nie by³o w tematach aneksu I. 2. W przeciwieñstwie do tematów aneksu I, w tych tematach nie by³o do tego czasu takich modeli danych lub by³y to modele w bardzo wczesnym etapie opracowania by³y jeszcze dalekie od stanu dojrza³oœci. W wielu przypadkach poszczególne tematyczne zespo³y robocze (TWG) musia³y rozpoczynaæ prace nad modelami od przys³owiowego zera, gdy dla tematów aneksu I czêsto problem sprowadza³ siê do wyboru ju istniej¹cych dojrza³ych modeli opracowanych w poszczególnych krajach cz³onkowskich i po³¹czenia ich w jeden spójny model europejski.

108 108 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML Uczestnicy prac nad specyfikacjami dla tematów aneksów II i III mieli znacznie mniejsze doœwiadczenie i mniejsz¹ wiedzê z zakresu opracowywania modeli danych w jêzyku UML i ich transformacji do schematów XSD. Dotyczy to zarówno poszczególnych grup roboczych (TWD), jak i zespo³ów testuj¹cych i opiniuj¹cych w krajach cz³onkowskich (SDIC i LMO). Czêsto by³ to ich pierwszy kontakt z t¹ metodyk¹ i z tymi technologiami. Jak ju wczeœniej wspomniano wiele wskazuje na to, e ostateczne rezultaty (wersje 3.0) nie s¹ w pe³ni zadawalaj¹ce. W dalszej czêœci tego rozdzia³u przedstawione bêdzie jedynie kilka wybranych przyk³adów nie do koñca poprawnych rozwi¹zañ zawartych w wersjach 2.0 i nie wszystkie z nich zosta³y poprawione w wersjach 2.9. Pierwszy przyk³ad pochodzi z modelu danych tematu Budynki (Buildings) i dotyczy stosowania stereotypu «voidable» z licznoœci¹ zawieraj¹ca [0], co jest opisane w rozdziale 9.2 (rys. 9.6). Zastosowano ten stereotyp do atrybutu klasy RoofSurface z jednoczesnym podaniem licznoœci [0..*]. Jest to formalnie poprawne i mo na przypuszczaæ, e gdy jest podana wartoœæ atrybutu (stereotyp nie zosta³ wykorzystany do pominiêcia wartoœci atrybutu) to w przypadku licznoœci zerowej ten budynek nie ma dachu, co jest mo liwe i w konsekwencji takie dane mog¹ byæ poprawne (rys. 11.1A). W drugim jednak przypadku zastosowano ten stereotyp do elementów listy kodowej TextureTyptType (rys. 11.1B). Trudno tu jest zrozumieæ, jaki sens ma mo liwoœæ pomijania poszczególnych pozycji listy kodowej. Lista kodowa podobnie do typu wyliczeniowego (klasy ze stereotypem «enumeration») jest wyj¹tkowym typem klasy jest to klasa jednej instancji (jednego obiektu) zawieraj¹cego listê elementów, które nie s¹ oddzielnymi atrybutami, lecz pozycjami, z których mo na wybraæ tylko jedn¹ z nich. W konsekwencji wszystkie pozosta³e pozycje listy s¹ pomijane i nie s¹ potrzebne im stereotypy «voidable», a nawet nie mog¹ byæ uwzglêdnione, bo narzuca to obowi¹zek obecnoœci wszystkich pozycji listy z podaniem przyczyny, dlaczego s¹ puste (rys. 9.6). A B C Rys Przyk³ady w¹tpliwego (A) i niepoprawnego (B) u ycia stereotypu «voidable», a tak e niezbyt fortunnej nazwy klasy (C) w modelu danych tematu Budynki.

109 11. SCHEMATY APLIKACYJNE TEMATÓW ANEKSÓW II I III DYREKTYWY INSPIRE Rys Kolejne dwa przyk³ady z modelu danych tematu Budynki. Pierwszy dotyczy pustych klas bez atrybutów i powi¹zañ, a drugi asocjacyjnego przypisania geometrii do klasy ze stereotypem «featuretype». 109

110 110 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Rysunek 11.1 jest tak e przyk³adem nazwy klasy TextureTypeType, która po transformacji do XSD ma a 3 identyczne przyrostki TextureTypeTypeType. Bardzie odpowiedni¹ nazw¹ tej klasy jest TypeOfTexture, co w XSD prze³o y siê na TypeOfTextureType. Oba przypadki przedstawione na tym rysunku pochodz¹ z wersji 2.0, jednak pozosta³y w wersji 2.9 i na tej podstawie mo na przypuszczaæ, e bêd¹ tak e w wersji 3.0. Kolejne dwa przyk³ady te pochodz¹ ze specyfikacji tematu Budynki w wersji 2.0. Pierwszy dotyczy pustych klas Door i Window wyprowadzonych z klasy Opening. Klasy te, jako specjalizacje klasy Opening, nie maj¹ adnych w³asnych atrybutów ani powi¹zañ i w konsekwencji ró ni¹ sie od klasy macierzystej tylko nazw¹. W takim przypadku poprawnym rozwi¹zaniem jest dodanie do klasy Opening atrybutu w postaci typu wyliczeniowego (ze stereotypem «enumeration») zawieraj¹cego dwie pozycje: Door i Window. Rysunek 11.2 przedstawia tak e drugi inny problem, jaki wyst¹pi³ w tym modelu. Dotyczy on przypisania geometrii do klasom ze stereotypem «featuretype» za pomoc¹ jednokierunkowych asocjacji (czarna ramka na rysunku). W takich przypadkach geometria jest atrybutem klasy i w modelu tym podczas prac nad jego transformacj¹ do schematów XSD ktoœ musia³ dokonaæ poprawki, a w rezultacie w schematach asocjacja zosta³a zamieniona na atrybut. Jednak takie nieudokumentowane zmiany prowadz¹ do istotnych ró nic pomiêdzy specyfikacj¹ danych i jej modelem UML a schematami XSD, które stanowi¹ podstawê poprawnego zapisu zbiorów danych tego tematu. W wersji 2.9 ten b³¹d zosta³ poprawiony, jednak przypadek pustych klas nadal pozosta³. Kolejne dwa przyk³ady dotycz¹ce b³êdów metodyki modelowania danych w jêzyku UML pochodz¹ z tematu Zasoby mineralne (Mineral resources) i s¹ przedstawione na rysunku Pierwszy z nich (A) jest analogiczny do przypadku z tematu Budynki Rys Dwa przyk³ady niepoprawnych elementów modeli specyfikacji danych tematu Zasoby mineralne (Mineral resources).

111 11. SCHEMATY APLIKACYJNE TEMATÓW ANEKSÓW II I III DYREKTYWY INSPIRE 111 (rys. 11.2) i dotyczy przypisania geometrii przy u yciu asocjacji, jednak w tym przypadku nie zosta³o to poprawione w wersji 2.9, ale ta asocjacja przesta³a byæ widoczna na diagramach tej specyfikacji. Drugi przypadek to podwójne zdefiniowanie asocjacji pomiêdzy klasami Mine i MiningActivity. Jest to czêsty b³¹d pope³niany przez osoby niedoœwiadczone i prawdopodobnie wynika z na³o enia siê linii reprezentuj¹cych graficznie te asocjacji na pierwotnym diagramie. Na rysunku 11.3, w czêœci B linie te zosta³y specjalnie rozsuniête tak, aby wszystkie trzy by³y dobrze widoczne wraz z ich elementami tekstowymi. B³¹d ten zosta³ usuniêty w wersji 2.9. Rysunek 11.4 przedstawia czêsto powtarzaj¹cy siê b³¹d dwukrotnego dziedziczenia wystêpuj¹cy w specyfikacjach dla ró nych tematów, w których korzysta siê z bazowego modelu dotycz¹cego ró nych sieci i zdefiniowanego w GCM (Generic Conceptual Model) jako GenericNetworkModel. Wszystkie piêæ klas dotycz¹cych sieci u ytkowanych publicznie (na rysunku zaznaczone czarn¹ ramk¹) ma podwójne dziedziczenie, od klasy UtilityNetworkElement i od klas nale ¹cych do GenericNetworkModel. Z czysto pojêciowego podejœcia do modeli podwójne (wielokrotne) dziedziczenie jest dopuszczalne, co mo na zobaczyæ na rysunku Jednak w modelach przeznaczonych do transformacji do schematów XSD taka konstrukcja nie mo e wyst¹piæ i jest to kolejny przyk³ad sytuacji, w której koœ musi dokonaæ nieudokumentowanej poprawki doprowadzaj¹cej do niezgodnoœci schematów XSD ze oficjaln¹ specyfikacj¹ danych. Problem wyeliminowania wielokrotnego dziedziczenia przedstawionego powy ej (rys. 11.5A) mo na rozwi¹zaæ na trzy sposoby (przyjmuj¹c, e obie klasy bazowe w wersji pocz¹tkowej by³y abstrakcyjne) i we wszystkich tych trzech przypadkach poprawnoœæ modelu pojêciowego zostaje dostatecznie zachowana: 1. Zast¹pienie zwi¹zku dziedziczenia od klasy lokalnej nawigacyjn¹ asocjacj¹ jednokierunkow¹ do tej klasy. Asocjacja ta pozwoli na udostêpnienie atrybutów i innych asocjacji tej klasy lokalnej klasie specjalizacyjnej pozbawionej tych w³asnoœci przez usuniêcie dziedziczenia (rys. 11.5B). W tym przypadku klasa lokalna nie mo e byæ klas¹ abstrakcyjn¹. 2. Wstawienie atrybutu do klasy specjalizowanej typy klasy lokalnej (rys. 11.5C), podobnie jak to mo na zrobiæ w przypadku zast¹pienia kompozycji przez atrybut (rys. 9.7 w rozdziale 9.2). Równie w tym przypadku klasa lokalna nie mo e byæ klas¹ abstrakcyjn¹. 3. U ycie powi¹zania do kasy lokalnej typu realizacja ze stereotypem «mixin» (rys. 11.5D). Klasa lokalna ma stereotyp «trait», co zak³ada, e musi byæ abstrakcyjna. Konstrukcje ze stereotypami «mixin» (domieszka) i «trait» (cecha) nie s¹ standardowe dla jêzyka UML i w ró nych jêzykach programowania s¹ implementowane ró nie lub w nich nie wystêpuj¹. Czêsto obie te konstrukcje s¹ traktowane jako konkurencyjne, lecz o ró nych w³aœciwoœciach. W wytycznych kodowania danych przestrzennych INSPIRE (DT_DS, 2010b) problem eliminacji wielokrotnego dziedziczenia jest oparty na konstrukcji mixin, jednak bez wyjaœnienia mechanizmu zamiany klas bazowych na klasy typu domieszki i w konsekwencji model nadal zawiera wielokrotne dziedziczenie. Implementacja tego w schemacie XSD jest uzale niona od wartoœci metki (taged value) gmlmixin, która powinna byæ w takim przypadku ustawiona na true. Z za³¹czonego tam przyk³adu wynika, e przy takim ustawieniu wartoœci metki, dziedziczenie jest traktowane jak realizacja ze stereotypem «mixin». Jest to jednak zastosowanie w jêzyku GML rozwi¹zania niestandardowego dla

112 Rys Przyk³ad dwukrotnego dziedziczenia klas w modelu specyfikacji danych dla tematu Us³ugi u ytecznoœci publicznej i s³u by pañstwowej (Utility and governmental services). 112 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML...

113 11. SCHEMATY APLIKACYJNE TEMATÓW ANEKSÓW II I III DYREKTYWY INSPIRE 113 aplikacji jêzyka XML i jest obs³ugiwane jedynie przez niedostêpn¹ publicznie wersjê oprogramowania ShapeChange firmy Interactive Instruments dedykowan¹ modelom INSPIRE (Woolf, 2009). Z tego wzglêdu bezpoœrednia transformacja modeli UML tematów INSPIRE z wielokrotnym dziedziczeniem do schematu XSD za pomoc¹ innego oprogramowania (na przyk³ad oprogramowania FullMoon lub starszych publicznie dostêpnych wersji oprogramowania ShapaChange) nie jest mo liwa. Rys Trzy sposoby rozwi¹zania problemu wielekrotnego dziedziczenia w modelach UML dedykowanych schematom XSD. Objaœnienia w tekœcie.

114 Rys Dwa przypadki nietypowych list kodowych: A olbrzymia lista typów siedlisk w temacie Siedliska i obszary przyrodniczo jednorodne (Habitats and biotopes), B lista z jedn¹ pozycj¹ w temacie Obiekty rolnicze oraz akwakultury (Agricultural and aquaculture facilities). 114 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML...

115 11. SCHEMATY APLIKACYJNE TEMATÓW ANEKSÓW II I III DYREKTYWY INSPIRE 115 Inny k³opotliwy problem wystêpuj¹cy w modelach danych INSPIRE to nietypowe listy kodowe. Rysunek 11.6 przedstawia dwa skrajne przypadki. Pierwszy to olbrzymia lista kodowa HabitatTypeValue w modelu dla tematu Siedliska i obszary przyrodniczo jednorodne (Habitats and biotopes). Stosowanie takiej listy w zapisach danych jest wyj¹tkowo trudne i z tego wzglêdu tak d³ugie wyliczenia powinny mieæ budowê hierarchiczn¹, jednak taka konstrukcja w modelach INSPIRE nie jest stosowana. W wersji 2.9 tego modelu lista ta zosta³a zast¹piona trzema podzia³ami siedlisk pod wzglêdem: rodzaju pokrycia, formy wegetacji i wystêpuj¹cych tam gatunków. Drugi przypadek to potraktowanie listy kodowej jak zwyk³ej klasy z jednym atrybutem typu Code, który mo e przybieraæ wartoœci odpowiadaj¹ce poszczególnym pozycjom tej listy. Lista ta by³a zdefiniowana w modelu tematu Obiekty rolnicze oraz akwakultury (Agricultural and aquaculture facilities) i w wersji 2.9 zosta³a poprawiona Nietypowy przypadek temat Geologia Wœród wielu tematów aneksów II i III dyrektywy INSPIRE na szczególn¹ uwagê zas³uguje temat Geologia (Geology) i nie dlatego, e autor tego rozdzia³u jest geologiem, lecz z powodu du ego nagromadzenia ciekawych przypadków nieprawid³owoœci. Tematem tym, a tak e tematem Zasoby mineralne (Mineral resources) zajmowa³ siê jeden roboczy zespó³ tematyczny (TWG GE-MR) z³o ony g³ównie z osób bardzo powi¹zanych z projektami jêzyków GeoSciML i EarthResourceML. W konsekwencji tego do grupy schematów podstawowych, obok schematów ISO/TC 211, w tym GML, zosta³y wprowadzone oba te jêzyki, jako baza dla opracowywania modeli dedykowanych poszczególnym tematom (rys. 11.7A). Rys A Okno przegl¹darki projektu programu Enterprise Architect przedstawiaj¹ce pakiety UML stanowi¹ce podstawê dla modeli tematycznych, B Fragment okna przegl¹darki Firefox przedstawiaj¹cego zawartoœæ katalogu serwera z najnowsz¹ wersj¹ 3.0 jêzyka GeoSciML. Objaœnienia w tekœcie.

116 116 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... Pomys³ u ycia obu tych jêzyków, jako bazy dla modeli tematycznych, zaowocowa³ powa nym zamieszaniem. Zbudowane na tej bazie modele okaza³y siê metodycznie b³êdne, poniewa z wyj¹tkiem bardzo nielicznych klas w³asnych sk³ada³y siê z klas i innych elementów importowanych z tych jêzyków. Sytuacjê t¹ mo na rozpatrzyæ w dwóch aspektach. Pierwszy aspekt to zasadnicza ró nica pomiêdzy jêzykiem dziedzinowym, jakim jest Geo- SciML, i schematem aplikacyjnym dla okreœlonego ograniczonego zastosowania, jakim jest temat INSPIRE Geologia. Czym ró ni siê konkretna w¹ska tematyczna aplikacja od ogólnego jêzyka dziedzinowego jest opisane w rozdziale 2. Tu mo na przedstawiæ kilka szczegó³ów dotycz¹cych tego konkretnego przypadku. Rysunek 11.8 przedstawia diagram klas zawieraj¹cy podstawowe typy proste (GenericValues) zdefiniowane w GeoSciML traktowane jako elementy do ewentualnego wykorzystania w szczegó³owych schematach aplikacyjnych lub elementy pe³ni¹ce role szablonów wymagaj¹cych dostosowania do konkretnej w¹skiej dziedziny, na przyk³ad CGI_Value::CodeListValue (rys. 11.8B). Przyk³adami typów prostych s¹ typy danych wywodz¹cych siê z klasy bazowej CGI_Value::CGI_Value (rys. 11.8A). Elementy przedstawione na tym rysunku nie zosta³y zmienione w celu dostosowania ich do potrzeb tej aplikacji s¹ dok³adnie takie, jak je zdefiniowano w jêzyku bazowym. Drugi aspekt to regu³y budowania tematycznych modeli aplikacyjnych na bazie jêzyka bêd¹cego dziedzinowym rozwiniêciem jêzyka GML. W tym przypadku problem sprowadza siê do jednoznacznego okreœlenia, jakie elementy modelu s¹ zapo yczone (importowane) z jêzyka bazowego, a jakie s¹ zdefiniowane lokalnie. Diagram klas przedstawiony na rysunku 11.8 jest czêœci¹ modelu Geology GeologyMain GeologyCore (TWG GE, 2011), jednak klasy na nim przedstawione nie s¹ elementami tego modelu, poniewa nale ¹ do pakietu GeoSciML GeoSciML-Core CGI_Utilites CGI_Value, co mo na rozpoznaæ po przedrostkach nazw klas. Przyczyn¹ przedstawionych powy ej b³êdów metodycznych jest przyjêcie, e te elementy, które widaæ na diagramach modelu s¹ czêœciami tego modelu. B³¹d ten wynika z braku doœwiadczenie autora modelu, czego rezultatem jest przekonanie, e czêœæ graficzna modelu jest najwa niejsza. Zgodnie z tym, co jest opisane w rozdziale 2.6 (rys. 2.19) wiele wa nych szczegó³ów modelu nie jest widocznych na diagramach, a inne s¹ trudno zauwa alne. Edytory jêzyka UML, jak na przyk³ad Enterprise Architect, pozwalaj¹ na dostosowanie zakresu widocznych na diagramie ró nych kategorii elementów przy pomocy funkcji Feature Visibility, jednak i tak nie wszystkie mog¹ byæ tam widoczne. W takim przypadku dostêp do niewidocznych danych modelu jest realizowany przy pomocy dodatkowych okienek (rys. 2.19, 11.2 i 11.7) Na tê sytuacjê na³o y³ siê fakt, e jako j¹zyka bazowego u yto najnowszej wersji 3.0 jêzyka GeoSciML, która w tym czasie nie by³a jeszcze w pe³ni opracowana i równolegle z pracami nad modelem lokalnym tematu Geologia trwa³y nadal prace nad jêzykiem GeoSciML. Powsta³a sytuacja, w której jêzyk bazowy zmienia³ siê w czasie jednoczeœnie z opracowywaniem na jego podstawie modelu tematycznego. Ostatnia sub-wersja wersji 3.0 zosta³a opublikowana w listopadzie 2011 (rys B), gdy model tematu Geologia by³ ju ukoñczony i zakoñczy³y siê tak e prace nad jego testowaniem (Michalak, 2012). Ostateczny efekt opisanych powy ej b³êdów modelu UML uwidoczni³ siê dopiero w schematach XSD, które zosta³y wygenerowanie na tej podstawie (rys ). W schematach tych tylko dwa elementy (AnthropogenicGeomorphologicFeatureType i NaturalGeomorphologicFeature) ze stereotypem «featuretype» jako wyró nienia prze-

117 11. SCHEMATY APLIKACYJNE TEMATÓW ANEKSÓW II I III DYREKTYWY INSPIRE Rys Podstawowe elementy proste (A) i szablony (B) jêzyka GeoSciML przeznaczone do wykorzystania w aplikacjach tego jêzyka. Objaœnienia w tekœcie. 117

118 118 MODELE DANYCH PRZESTRZENNYCH W UML I ICH TRANSFORMACJA DO SCHEMATÓW GML... strzenne mog¹ byæ wykorzystane do zapisu danych podtematu GeologyMain. Wszystkie pozosta³e klasy modelu zosta³y pominiête podczas transformacji wykonanej oprogramowaniem ShapeChange, jako nie nale ¹ce do tego modelu, pomimo e s¹ w tym modelu widoczne i w konsekwencji tego szczegó³owo opisane w specyfikacji tekstowej (TWG GE, 2011). Prace testowe dotycz¹ce specyfikacji danych opisane we wstêpie do rozdzia³u 11 wykaza³y niepoprawnoœæ tego modelu i w rezultacie w kolejnej wersji 2.9 model GeologyMain zosta³ ca³kowicie zmieniony. Zmiana ta polega³a g³ównie na usuniêciu z czêœci bazowej (Foundation Schemas) obu jêzyków GeoSciML i EarthResourceML, a w zamian za to umieszczenia ich wybranych fragmentów w postaci lokalnej kopii w obrêbie modelu tematu Geologia. Rys Lista elementów schematu aplikacyjnego GeologyCore w oknie programu XML Spy. Tylko dwa elementy z tej listy mog¹ byæ u yte do zapisu danych. Objaœnienia w tekœcie. W obrêbie tematu Geologia jest tak e podtemat Hydrogeologia (Hydrogeology) i w pocz¹tkowych planach mia³ on stanowiæ jedynie rozszerzenie podtematu GeologyMain. Zamiar ten zosta³ zmieniony i w opublikowanej wersji 2.0 (TWG GE, 2011) by³ w du ym stopniu niezale ny. Pozytywn¹ cech¹ modelu podtematu Hydrogeologia jest jego rozszerzalnoœæ pozwalaj¹ca na uwzglêdnienie powi¹zañ z innymi tematami, jak na przyk³ad: Hydrografia, Obszary chronione, Gospodarowanie obszarem, strefy ograniczone i regulacyjne oraz jednostki sprawozdawcze, Urz¹dzenia do monitorowania œrodowiska i inne. Inne istotne w tym przypadku i mo liwe do realizacji rozszerzenia podtematy Hydrogeologia to powi¹zanie tych danych z innymi danymi hydrogeologicznymi o zasiêgu europejskim, jak na przyk³ad dane zwi¹zane z realizacj¹ postanowieñ Ramowej Dyrektywy Wodnej (WFD Water Framework Directive) (rys ). Dane systemu WISE bêd¹cego realizacj¹ dyrektywy WFD zawieraj¹ wiele cennych informacji (WFD-WG-GIS, 2003; EC, 2009), jednak ich przypisanie przestrzenne jest ograniczone do centroidu punktu po³o onego wewn¹trz obszaru objêtego okreœlon¹ JCWPd (Jednolite Czêœci Wód Podziemnych), którego po³o enie jest okreœlone wspó³rzêdnymi geograficznymi (uk³adu WGS84).