Kapitola 5 Hybridní datový model, objektově orientované datové modely

5.1 Hybridní model

Tento datový model vznikl z potřeby společného jednotného zpracování vektorových a rastrových dat. Tohoto cíle lze samozřejmě dosáhnout i vzájemnou konverzí dat mezi oběma základními modely (např. konverzí vektorových dat na rastrové a jejich zpracováním společně s původními rastrovými daty), ale takovéto řešení přináší celou řadu obtíží (především konverze rastrová data - vektorová data) a nevýhod. Proto je snahou výzkumných a vývojových pracovníků nalézt obecný datový model, který by ležel někde mezi oběma základními modely a který by byl vhodný pro ukládání a dat jak ve vektorové, tak i rastrové podobě. Data by tak byla uložena ve velice kompaktní formě, umožňující efektivní zpracování dat.

Deren a Jianya (1992) navrhli unifikovaný datový model, který spojuje výhody vektorvého a rastrového modelu a umožňuje tak současné ukládání a zpracování dat z GIS, DMT a DPZ. Tento model vychází z lineárního quadtree, tj. geometrický popis geoprvků je místo souřadnic \(x\) a \(y\) vyjádřen pomocí Mortonových klíčů. Pro zvýšení přesnosti reprezentace pozice bodů je základní buňka quadtree ještě rozdělena jemným gridem (opět reprezentovaným pomocí quadtree) – lokalizace bodu je pak reprezentována dvěma Mortonovými klíči –první indikuje pozici bodu v základním quadtree a druhý v jemně děleném gridu. Linie jsou zde reprezentovány množinou Mortonovýchklíčů, která obsahuje nejen pozice počátečního a koncového uzlu a všech vrcholů, ale celou cestu procházející základním quadtree. Plochy jsou kódovány obdobně – hraniční linie + buňky hraničního quadtreeležící v této ploše.

5.2 Objektově orientované datové modely

Geografické informační systémy zaznamenávají v posledních letech prudký nárůst popularity. Bylo vyvinuto velké výzkumné a vývojové úsilí zaměřené na zvýšení funkčnosti efektivnosti těchto systémů. Výsledkem byla některá významná zlepšení, ale také odhalení celé řady slabých míst.

Značně narostlo množství dostupných dat (např. díky rostoucí rozlišovací schopnosti dat z družic), což vede k problémům s ukládáním a zpracováním těchto dat. Při analýzách se těžiště zpracování postupně přesouvá od prostorově orientovaných analýz k analýzám objektově orientovaným. To vede k potřebě zavedení objektově orientované reprezentace dat. Tento požadavek otevírá zcela novou oblast vývoje technologie GISů. S tak masivními objemy dat je spojen problém, jak v kterémkoliv systému provádět analýzy a podávat výsledné zprávy. Je zde totiž nebezpečí, že uživatel bude zavalen příliš mnoha informacemi. A navíc je obtížné vědět, jakou váhu dát kterému výsledku, protože tyto výsledky nejsou zařazeny do kontextu.

Dnešní datové struktury jsou optimalizovány s ohledem na ukládání a rychlost manipulace s daty, aniž by braly v úvahu přesnou reprezentaci reálného světa. Geoprvky jsou redukovány na body, linie a plochy, případně na pixely. Datové struktury kladou důraz v prvé řadě na lokalizaci geoprvků, tematické údaje ukládají zcela odděleně, a tím podstatně stěžují provádění prostorových analýz. Ani vektorový, ani rastrový model v reálném světě neexistují - silnice není linie, města nejsou body, a pixely reprezentují zcela libovolná místa prostoru, bez vyhraněného vztahu ke konkrétnímu geoprvku.

Tyto nedostatky lze odstranit jediným možným způsobem - vytvořením a zavedením objektově-orientovaného GISu. Nezbytnost zavedení objektově orientovaného přístupu do zpracování prostorových dat lze demonstrovat na jednoduchém příkladě: Když promítneme pozorovateli snímek krajiny a zeptáme se, co vidí, pak nám určitě neodpoví, že vidí body, linie, nebo dokonce pixely, ale naopak lesy, silnice, údolí, řeky atd. A to je také výchozí platforma pro vývoj objektově-orientovaných GISů (OOGIS).

OOGISy musí pracovat s objekty, které odpovídají konkrétním reálným geoprvkům a popisují je jak po stránce prostorové, tak i tematické, časové, vztahové i funkční. Vznikají tak multidimenzionální entity, umožňující řešit i problémy, které byly při použití dřívějších datových struktur neřešitelné. Jedná se například o překrývající se geoprvky, nebo geoprvky s nejasnou prostorovou hranicí (s “fuzzy” omezením). Příkladem překrývajících se geoprvků může být řeka a údolí. Zatímco v klasických datových modelech řeka rozdělí údolí vždy na dvě části, tak v OOGISu tato situace nepředstavuje žádný problém, protože tyto objekty se sice překrývají v 2D prostoru, použitém pro zobrazování, ale v jiných dimenzích jsou zcela odlišné. Příkladem geoprvků s “fuzzy” omezením může být samo údolí a jeho přilehlý hřbet. Tyto dva geoprvky se opět mohou překrývat, neboť linie, která je odděluje, není přesně a jednoznačně definovaná.

OODBMS (objektově orientovaný databázový systém; angl. object oriented database management system) poskytuje mnohem přirozenější přístup k budování systémů, protože programové objekty odpovídají přímo objektům reálným. Objekty mohou zachycovat jakýkoliv řád komplexnosti a při použití objektově orientovaného přístupu je proto jednoduché ukládat různé datové typy a jejich komplexní vztahy.

Většina dnešních GISů využívá pro ukládání dat relační databáze. Avšak užití relačního přístupu je v mnoha oblastech vcelku nové (uvádí se, že jen 5 % všech dat je dnes uloženo v relačních databázích). V takovém případě se nabízí otázka, zda by nebylo lepší přeskočit používání relačních databází a přejít přímo k objektově orientovaným databázím.

OODBMS nabízejí nejlepší rysy moderních technologií. Protože objekty mohou obsahovat zase objekty, lze v OODBMS postihnout prakticky jakkoliv komplexní strukturu dat. Tyto databáze nabízejí přirozený způsob ukládání a vybírání komplexních objektů, uživatelé si mohou definovat své vlastní objekty, umožňující reprezentovat v databázích GISu všechny potřebné typy geoprvků (silnice, ulice, řeky …).

Oblastí vhodných pro použití OODBMS je mnoho a jsou různé. Na úrovni veřejné správy mohou aplikace sahat od monitorování znečištění životního prostředí až po plánování výstavby. V komerční oblasti lze tyto databáze využít např. v realitních kancelářích, kdy k dané nemovitosti lze velice snadno uložit i doprovodný textový popis, fotografii nebo i videozáznam.

Popis geoprvků, reprezentovaných v databázích geografického informačního systému je relativně složitý, skládá se ze složek, reprezentovaných daty, dále složek reprezentovaných logickými vazbami a v neposlední řadě ze složek reprezentovaných programovým kódem.

Rastrový datový model neumožňuje plnou realizaci popisu geoprvků, navíc jsou zde striktně odděleny složky realizované prostřednictvím dat a složky realizované prostřednictvím programového kódu, pracujícího nad těmito daty.

Vektorový datový model umožňuje téměř úplnou realizaci popisu geoprvků, avšak tento popis je roztříštěn do relativně samostatných částí, jako je prostorová databáze, tematická databáze a programový kód. Navíc vnitřní organizace těchto relativně samostatných částí mnohdy plnou implementaci popisu geoprvků ztěžuje.

Objektově-orientovaný datový model umožňuje plnou realizaci popisu geoprvků, vyznačuje se vysokou konzistentností popisu geoprvků, jednotlivé složky popisu každého geoprvku vytvářejí organický celek - objekt. Nevýhodou objektově-orientovaného datového modelu je prozatím jeho novost, z které může pramenit jistá nevyzrálost a každopádně omezená nabídka vhodných programových produktů, umožňujících práci s tímto datovým modelem a plnou realizaci všech složek popisu geoprvků.

5.2.1 Objektově orientované modelování

OOP (Object-oriented programming) je metodika vývoje softwaru, založená na následujících myšlenkách:

• Objekty - jednotlivé prvky modelované reality (jak data, tak související funkčnost) jsou v programu seskupeny do entit, nazývaných objekty. Objekty si pamatují svùj stav a navenek poskytují operace (přístupné jako metody pro volání).
• Abstrakce - programátor, potažmo program, který vytváří, mùže abstrahovat od některých detailů práce jednotlivých objektù. Každý objekt pracuje jako černá skříňka, která dokáže provádět určené činnosti a komunikovat s okolím, aniž by vyžadovala znalost způsobu, kterým vnitřně pracuje.
• Zapouzdření - zaručuje, že objekt nemůže přímo přistupovat k “vnitřnostem” jiných objektů, což by mohlo vést k nekonzistenci. Každý objekt navenek zpřístupňuje rozhraní, pomocí kterého (a nijak jinak) se s objektem pracuje.
• Skládání - Objekt může obsahovat jiné objekty.
• Delegování - Objekt může využívat služeb jiných objektů tak, že je požádá o provedení operace.
• Dědičnost - objekty jsou organizovány stromovým zpùsobem, kdy objekty nějakého druhu mohou dědit z jiného druhu objektů, čímž přebírají jejich schopnosti, ke kterým pouze přidávají svoje vlastní rozšíření. Tato myšlenka se obvykle implementuje pomocí rozdìlení objektů do tříd, přičemž každý objekt je instancí nějaké třídy. Každá třída pak může dědit od jiné třídy (v některých programovacích jazycích i z několika jiných tříd).
• Polymorfsmus - odkazovaný objekt se chová podle toho, jaké třídy je instancí. Pokud několik objektù poskytuje stejné rozhraní, pracuje se s nimi stejným zpùsobem, ale jejich konkrétní chování se liší podle implementace. U polymorfsmu podmíněného dědičností to znamená, že na místo, kde je očekávána instance nějaké třídy, můžeme dosadit i instanci libovolné její podtřídy, neboť rozhraní třídy je podmnožinou rozhraní podtřídy. U polymorfsmu nepodmíněného dědičností je dostačující, jestliže se rozhraní (nebo jejich požadované části) u různých tříd shodují, pak jsou vzájemně polymorfní.
  

Objekt

• představuje reálnou entitu,
• obsahuje informace, které popisují jeho vlastnosti a chování,
• individuální objekt je odlišen prvky informací, kterými se liší od ostatních objektů.

Stav objektu = stav (forma) objektu, tj. hodnoty jeho vlastností v daném časovém okamžiku. Změna stavu objektu v čase se uskutečňuje prostřednictvím interní akce objektu nebo interakcí objektu s prostředím.

OOP je někdy označováno jako programátorské paradigma, neboť popisuje nejen zpùsob vývoje a zápisu programu, ale i způsob, jakým návrhář programu o problému přemýšlí.

5.2.2 Unified Modelling Language (UML)

UML (Unified Modeling Language) je v softwarovém inženýrství grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů. UML nabízí standardní způsob zápisu jak návrhů systému včetně konceptuálních prvků jako jsou business procesy a systémové funkce, tak konkrétních prvků jako jsou příkazy programovacího jazyka, databázová schémata a znovupoužitelné programové komponenty.

UML podporuje objektově orientovaný přístup k analýze, návrhu a popisu programových systémů. UML neobsahuje způsob, jak se má používat, ani neobsahuje metodiku(y), jak analyzovat, specifikovat či navrhovat programové systémy.

Standard UML definuje standardizační skupina Object Management Group (OMG).

5.2.2.1 Způsoby použití UML

• Kreslení konceptu - při tomto použití je UML podpůrným nástrojem pro komunikaci mezi vývojáři a pro zaznamenání myšlenek a návrhů. Do diagramů se kreslí pouze věci podstatné pro grafické vyjádření návrhu, části návrhu před tím, než se začne programovat. Důležitá je srozumitelnost, rychlost nakreslení a snadnost změny či navržení alternativ řešení.
• Kreslení detailních návrhů - cílem je zaznamenat kompletní návrh či kompletní realizaci. Při kreslení návrhu by měl analytik obsáhnout všechny prvky tak, aby programátor byl schopen vytvořit program bez velkého přemýšlení nad věcnou oblastí (pro programátora by neměla vzniknout potřeba konzultace s uživatelem). Při kreslení detailních návrhů se obvykle používají specializované programy (CASE), které jsou schopny sdílet informace mezi jednotlivými modely a kontrolovat konzistenci návrhu. Při dokumentaci programu se často používají nástroje pro generování diagramů z vlastního kódu aplikace.
• UML jako programovací jazyk - při tomto použití vývojář nakreslí UML diagramy, ze kterých se vygeneruje přímo spustitelný kód. Toto vyžaduje specializované nástroje a velmi přesné vyjadřování v UML diagramech. V této souvislosti se velmi často používá pojem Model Driven Architecture (MDA), což je další standard skupiny OMG, který se snaží standardizovat použití UML jako programovacího jazyka.
• Metamodel - tento pohled používají autoři UML a autoři CASE nástrojů - nedívají se na UML jako na diagramy, pro ně je základem UML metamodel (diagramy jsou pouze grafickou reprezentací metamodelu). Při tomto přístupu se často používá pojem model místo pojmu diagram, např. místo diagramu tříd se používá pojem model tříd. Metamodel se popisuje pomocí Meta-Object-Facility (MOF) - abstraktního jazyka pro specifikaci, vytváření a správu metamodelů (další standard OMG). Pro výměnu metamodelů se používá XMI - na XML založený standard (součást standardu UML).
  

5.2.2.2 Konceptuální modelování

Konceptuální modelování informací využívá především strukturální diagramy, zejména diagramy balíčků a diagramy tříd, které využívají prvky pocházející z jádra (jadrového balíčku) UML.

Balíček (package) identifikuje prostor pro skupinu prvků obsažených v balíčku. V UML diagramu je zobrazen jako obdélník s menším obdélníkem v levém horním rohu (obrázek 1). Prvky obsažené v balíčku zobrazujeme uvnitř obdélníku, název balíčku umístěné na kartě. Pokud nejsou prvky obsažené v balíčku konkrétně zobrazeny, je název balíčku umístěn ve větším obdélníku.

5.2.2.2.1 Klasifikátor (Classifier)

Základním prvkem diagramu třídy UML je klasifikátor (classifier). Klasifikátor představuje koncept modelovaný uvnitř systému. Popisuje sadu objektů které mají společné vlastnosti. Každý takový objekt je instance třídy. Klasifikátor je reprezentován plným obdélníkem obsahujícím jméno klasifikátoru a, s výjimkou třídy podtypu, „klíčové slovo“, které identifikuje jeho podtyp. Obdélník může být rozdělen vodorovnými čarami do oddílů, které obsahují funkce klasifikátoru. Existuje několik typů klasifikátorů:

• Třída (Class)

Třída UML je typ klasifikátoru, který má atributy a operace. Třída představuje množinu objektů, jež sdílejí stejnou množinu specifikací sémantiky, vlastností a omezení. Třída může reprezentovat jakoukoliv sadu objektů, fyzicky existujících či nikoliv. V GIS jsou třídy využívány pro vyjádření běžně používaných typů prvků, ale mohou reprezentovat i jejich vlastnosti.

Třída je chápána jako objekt, tj. jako sada hodnot atributů a operací, které popisují konkrétní instance třídy. Třída může představovat lampy nebo celá města (typy funkcí). Může také představovat vlastnictví pozemků nebo ohrožení určitých druhů (charakteristické vlastnosti).

Obrázek 2: Třída UML (zdroj: Kresse, Danko, 2012)

Obdélník představující třídu (obrázek 2) je rozdělen na tři “přihrádky”. Horní přihrádka obsahuje název třídy a další obecné vlastnosti třídy; prostřední část obsahuje seznam atributů; spodní oddíl obsahuje seznam operací. Atribut a operační prostory mohou být potlačeny za účelem zjednodušení diagramu. Potlačení však neznamená, že neexistují žádné atributy nebo operace.

• Rozhraní (Interface)

Rozhraní popisuje službu nabízenou instancemi jakékoliv třídy, která toto rozhraní implementuje. Rozhraní není instancí samo o sobě, ani nespecifikuje, jak má být implementováno do třídy, která jej realizuje. Spíše popisuje veřejné chování třídy, která jej implementuje. Rozhraní může být implementováno několika třídami, a třída může implementovat více než jedno rozhraní.

Jako příklad je možno uvést rozhraní s názvem OblastViditelnosti. OblastViditelnosti je definována jako dvourozměrný polygon, který ohraničuje oblast na zemském povrchu, z níž je daný objekt viditelný. Rozhraní může být implementováno jakoukoli třídou, která představuje fyzický objekt. Mohlo by být implementováno buď jako operace, která odvodí tvar z geometrických charakteristik objektu a okolního terénu, nebo jako atribut, který obsahuje tvar.

Obrázek 3: Třída UML (zdroj: Kresse, Danko, 2012)

Rozhraní může být reprezentováno jako diagram klasifikátoru s klíčovým slovem “rozhraní”" v horní části schématu. Diagram rozhraní mohou být připojen k diagramu představujícímu implementaci třídy realizačním symbolem, který je znázorněn přerušovanou čárou s otevřeným trojúhelníkem na konci připojeným ke schématu rozhraní (obrázek 3). Závislost implementované třídy na rozhraní, které implementuje, může být také znázorněno připojením kružnice obsahující název rozhraní k implementační třídě plnou čarou.

• Datový typ (Datatype)

Datový typ je typ klasifikátoru, který se od třídy liší pouze tím, prvky datového typu jsou identifikovány pouze jejich hodnotami. Instance datového typu nemůže existovat nezávisle na vlastností, jejíž hodnotu poskytuje. Datové typy zahrnují primitivní předdefinované typy a uživatelem definované typy. Datový typ je identifikován klíčovým slovem “DataType” v horní části diagramu. Primitivní datové typy zahrnují takové hodnoty, jako jsou celá čísla a reálná čísla. Příkladem uživatelem definovaného datového typu může být kombinace alfanumerických znaků slouží k identifikaci čísel tras v rámci dálničního systému státu.

 * **Výčet (Enumeration)** - druh datového typu, jehož instance tvoří seznam pojmenovaných kategorií. Deklarovány jsou jak název výčtu, tak i jeho konkrétní hodnoty. Výčet je krátký seznam dobře pochopitelných potenciálních hodnot uvnitř třídy. Příkladem může být seznam čtyř bodů kompasu: východ, západ, sever a jih.
 * **seznam kódů (Codelist)** - flexibilní výčet specifikovaný v ISO/TS 19103 [1.2]. Seznamy kódů jsou užitečné pro dlouhé seznamy potenciálních hodnot. Výčet by měl být použit, jestliže jsou prvky seznamu zcela známy; codelist pak, pokud je znám pouze soubor pravděpodobných hodnot prvků. Codelist může být rozšířen na aplikační schéma. The BuildingUse a LandUse codelists na obrázku 4 jsou příklady seznamů kódů. Seznam kódů může být specifikována standardem, například seznam kódů ISO 639-2 pro identifikaci jazyků.

5.2.2.2.2 Třída prvků (Class Features)

• Atribut (Attribute)

Atribut představuje charakteristiku (vlastnost) společnou pro předměty třídy. Příklady atributů mohou být půdorys a výška budovy. Atribut je popsán řetězcem složeným z prvků, které specifikují jeho vlastnosti

visibility name: prop-type[multiplicity]=default,

kde:

• visibility může být veřejná (značení +) nebo soukromá (značení -). Soukromý prvek je přístupný (viditelný) pouze z prvků v prostoru, který jej vlastní; veřejné prvky jsou viditelné pro všechny prvky které mohou přistupovat k prostoruů, který jej vlastní.
• name je řetězec znaků, který identifikuje atribut. Znak slash (/) před názvem indikuje, že je hodnota atributu odvoditelná z hodnot dalších prvků modelu.
• prop-type - datový typ atributu;
• multiplicity specifikuje počet hodnot, které může prvek třídy pro daný atribut mít. Není-li zobrazena, je její hodnota defaultně nastavena na 1.
• default - volitelný - specifikuje počáteční hodnotu atributu.
  

Operace (Operation)

Operace reprezentují činnosti, které lze s objektem provádět. Příkladem mohou být funkce čtení a zápisu, výše zmíněných hodnot atributů půdorys a výška budovy. Operace je popsána řetězcem tvořeným prvky, jež specifikují její vlastnosti.

visibility name(parameter-list): return-type{oper-property},

kde:

• visibility může být veřejná (+) nebo soukromá (-),
• name je řetězec znaků, který identifikuje operaci,
• parameter-list je seznam parametrů, každý z nich ve formě

direction parameter-name: type-expression,

kde direction může být in, out nebo inout a defaultně in, je-li pole vynecháno, parameter-name je název parametru a type-expression identifikuje datový typ parametru.

• return-type - datový typ hodnoty vrácené operací,
• {property-string} - volitelné pole obsahující seznam hodnot vlastnosti aplikované při operaci.
  

Asociace (Association)

Asociace (obrázek 5) specifikuje spojení (vztahy) mezi prvky a třídami. Asociace je zakreslována jako plná čára spojující obdélníky třídy. Asociace může mít jméno, reprezentované jako řetězec znaků blízko čáry, ale ne blízko k jednomu konci. Každý konec asociace nese informace týkající se třídy na tomto konci, včetně názvu jeho role, násobnosti (multiplicity) a navigability. Asociace mezi dvěma prvky téže třídy je vyjádřena jako linie, jež má oba konce spojené s obdélníkem téže třídy.

Obrázek 5: Příklady UML asociací (zdroj: Kresse, Danko, 2012)

• Role Name (název role) - specifikuje chování třídy na daném konci s ohledem na třídu na druhém konci asociace. Je reperezentován řetězcem začínajícím malým písmenem. Na obrázku 5 název role “owner” indikuje, že případ třídy Person je vlastníkem případu House, zatímco název role “property” indikuje že případ třídy House je majetkem případu třídy Person. Při zpracování dat se název role používá k identifikaci podmnožiny případů třídy, které jsou zapojeny do asociace. Může být použit například pro výběr majitelů ze souboru instancí osob obsažené v databázi.
  

Multiplicita (Multiplicity)

Multiplicita, neboli násobnost, specifikuje počet prvků třídy, které mohou být asociovány s třídou na druhé straně asociace. Multiplicitu výše zmíněného vztahu osob a nemovitostí čteme takto: Skupina osob může mít libovolný počet členů (to poznáme podle hvězdičky u třídy Person). Osoba může vlastnit 1 až libovolný počet domů (to poznáme podle 1..* u třídy House).

Pojďme si nyní uvést jednotlivé možné zápisy multiplicity:

1. 1 (číslo) - označuje konkrétní hodnotu (zde právě 1)
2. • (hvězdička) - označuje libovolný počet (tedy i 0). Místo hvězdičky můžeme v některých materiálech nalézt symbol N.
3. 1..* (interval) - pomocí 2 teček můžeme označit interval.

Do něj vkládáme nám již známé symboly, např.: 2..6 nebo 1..* nebo 0..1.

Zápisy můžeme dokonce i slučovat, např. takto: 1, 2, 3, 7..*. Tento zápis označuje multiplicitu 1, 2, 3 nebo 7 a více. Pokud není multiplicita uvedena, označuje to výchozí hodnotu 1.

Na obrázku 5 vidíme následující příklady asociací:

• Instance třídy House může být majetkem jednoho nebo mnoha vlastníků.
• Osoba může být majitelem žádného nebo mnoha domů.
• Třída Play je tvořena nejméně jedním a potenciálně mnoho instancemi třídy Act.
• Instance třídy Act patří pouze k jedné instanci třídy Play.
• Prvek třídy Triangle sdružuje právě tři body jako vertexy.
• Prvek třídy Points slouží jako vertex žádnému nebo mnoha trojúhelníkům.

Stejné vyjádření násobnosti používáme i pro atributy.

Navigovatelnost (Navigability)

Navigovatelnost popisuje schopnost jednoho prvku využívat informace obsažených v jiném prvku. Šipka připojená ke konci asociace cesta označuje, že je v systému povolena navigace ve směru třídy připevněné na šipce. Jinak řečeno, informace obsažené v této třídě jsou přístupné ze třídy na druhém konci asociace. Například, obrázek 5 ukazuje, že je možné navigovat z instance třídy Trojúhelník (Triangle) k získání informací o prvcích třídy Bod (Point), které tvoří jeho vrcholy, ale není možná navigace z instance bodu k identifikaci instancí trojúhelníků, kterým slouží jako vrchol.

Agregace (Aggregation)

Agregace reprezentuje vztah typu celek - část. Zakreslujeme ji jako plnou čáru, zakončenou na jedné straně prázdným kosočtvercem. Ten je umístěn u té entity, která reprezentuje celek (např. trojúhelníky). Z hlediska implementace je to tak entita, která drží kolekci prvků. Entita reprezentující část může existovat sama o sobě a být součástí i jiných kolekcí.

Např. prvek třídy Triangle na obrázku 5 je souhrn (agregace) třech prvků třídy Point. Agregace je považována za slabší formu kompozice.

Kompozice (Composition)

Kompozice je podobná agregaci, avšak reprezentuje silnější vztah. Entita části nemá bez celku smysl. Pokud zanikne celek, zanikají automaticky i jeho části. Kompozici zakreslujeme stejně jako agregaci, kosočtverec je ovšem plný. U entity reprezentující celek musí být multiplicita vždy 1. Tato vazba bývá matoucí a doporučil bych se jí spíše vyhýbat a nahradit ji agregací.

Např. třída Play na obrázku 5 je tvořena jedním nebo více prvky třídy Act.

Asociační třída (Association class)

Asociační třída je třída, která zprostředkovává vztah mezi dvěma entitami. Výhodou je to, že může vztahu dodat nějaké atributy. Často se uvádí příklad tříd Osoba a Zajezd, kdy asociační třída Ucast přiřazuje osobu na zájezd a dodává čas příjezdu a odjezdu. Dalším příkladem je třeba Osoba a Hotel, kdy v hotelu není pevně stanovený čas ubytování a objednává si ho konkrétní osoba. Podobná třída by mohla ještě např. být mezi zaměstnancem a firmou, kde by definovala plat zaměstnance. Dalším využitím může být možnost takto vytvořit vazbu M:N, podobně, jako to funguje u databází. Asociační třída by tedy držela kolekci referencí. Na obrázku 6 je třída Ford modelována jako asociace mezi třídami Road a River.

Generalizace (Generalization)

Generalizace je taxonomický vztah mezi obecnějšími a specifičtějšími prvky. Specifičtější prvek je plně v souladu s obecnějším prvkem a obsahuje další informace. Instance konkrétnějšího prvku může být použita tam, kde je povolen obecnější prvek. Generalizace je zobrazena jako plná čára spojující konkrétnější prvek (např. podtřída) s obecnějším prvkem (např. nadřazená třída) velkým prázdným trojúhelníkem, kde čára splňuje obecnější prvek. Abstraktní třída, která má svůj název vyjádřen kurzívou, může být vytvořena jako instance svých podtříd. Někdy je nadtřída definována jako abstraktní třída, pokud nemá žádné atributy, ale je spíše vytvořena za účelem stanovení jasné hierarchie modelu. Výsledný dataset nemá žádné objekty, které jsou pojmenovány podle abstraktní třídy. Obrázek 7 ukazuje příklad dvou generalizačních vztahů, ve kterých má každá ze dvou podtříd třídy Vehicle třetí atribut vedle dvou atributů, které jsou zděděny od třídy Vozidlo (*Vehicle).

Obrázek 7: Příklad generalizace (zdroj: Kresse, Danko, 2012)

Jednotlivé vztahy zobecnění (generalizace) mohou být seskupeny do generalizačních sad, z nichž každá představuje jeden z možných způsobů rozdělení nadřazené třídy. Např. nadtřída Person může být rozdělena do jedné generalizace stanovené na základě pohlaví a do dalšího zobecnění (generalizace) stanovené na základě úrovně vzdělání. Každá sada generalizace má název, který je připojen na řádky spojující podtřídy s nadtřídou.

Stereotyp (Stereotype)

Stereotypy rozšiřují sémantiku již existujících prvků, ale neovlivní jejich strukturu. Stereotyp je identifikován jménem takto:<>. Příkladem je stereotyp <>, který identifikuje klasifikátor, jehož instance jsou samy o sobě třídy. Metaclass představuje koncept vyšší úrovně abstrakce než třídy.

Poznámka (Note)

Poznámka obsahuje textové informace. Je zobrazena jako obdélník s ohnutým pravým horním rohem, připevněný na žádný nebo více prvků modelu přerušovanou čarou. Poznámky mohou být použity k uložení komentářů nebo omezení. Příklad na obrázku 7 obsahuje omezení.

Omezení (Constraint)

Omezení určuje sémantický stav nebo omezení. Ačkoli specifikace UML zahrnuje Object Constraint Language pro psaní omezení, omezení lze napsat pomocí jakéhokoli formálního zápisu nebo přirozeného jazyka. Omezení je zobrazeno jako textový řetězec v závorkách „{}“. Je obsaženo v poznámce nebo umístěné blízko prvku, ke kterému se vztahuje. Na obrázku 7 je příklad omezení hodnoty atributu numberOfAxles, který PassengerCar zdědí od vozidla.

Pokud je notace prvku textový řetězec (např. atribut), po složených závorkách obsahujících omezení může následovat textový řetězec prvku. Omezení zahrnuté jako prvek v seznamu se vztahuje na všechny následující prvky v tomto seznamu, dokud se neobjeví další omezení nebo konec seznamu.

Závislost (Dependency)

Závislost indikuje to, že implementace nebo fungování jednoho či více prvků vyžaduje existenci jednoho nebo více jiných prvků. Vytváří tak vztahy mezi prvky modelu navzájem. Je zobrazována jako přerušovaná šipka mezi prvky modelu. Prvek na konci šipky (klient) závisí na prvku na jejím začátku (poskytovatel). Druh závislosti může být označen jako klíčové slovo takto: <>, <> nebo <>. Na obrázku 8 má Package1 závislost <> na Package2, což znamená, že jeden nebo více prvků v Package1 používá prvky uvedené v Package2. Například atribut uvedený v Package1 může používat datové typy uvedené v Package2.

5.2.3 The General Feature Model (GFM)

ISO/TC 211 zavedl GFM popsaný v ISO 19109 jako metamodel pro reprezentaci prvků v aplikačním schématu. Prvky metamodelu mohou být reprezentovány jako prvky UML modelu aplikačního schématu. Ty, které nemohou být vyjádřeny graficky by měly být zahrnuty do dokumentace modelu, která může být ve formě datového slovníku aplikační schéma.

5.2.3.1 GF_FeatureType (typ prvku)

Hlavním prvkem GFM je metatřída GF_FeatureType (obrázek 9). Příkladem GF_FeatureType je třída UML pojmenovaná pro konkrétní typ prvku, jako je most, továrna nebo silnice. GF_FeatureType má tři atributy, u nichž se předpkládá, že budou zahrnuty v každém prvku:

• typeName - obsahuje název specifického typu prvků reprezentovaného vytvořenou třídou,
• definition - obsahuje definici typu prvku a je “nesena” jako atribut třídy,
• isAbstract - obsahuje booleovskou hodnotu indikující, zda je či není vytvořená třída abstraktní. Je-li je hodnota rovna TRUE, je název UML třídy zobrazen kurzívou a indikuje tak abstraktní třídu.

5.2.3.2 GF_InheritanceRelation (relace dědičnosti)

Metatřída GF_FeatureType je spojena s třídou GF_InheritanceRelation dvěma asociacemi generalizace a specializace. Tato struktura ukazuje, že mohou být dva prvky třídy GF_FeatureType ve vztahu jeden k druhému jako nadtřída a podtřída v generalizačí hierarchii.

Protože je název (name) atributu GF_GeneralizationRelation volitelný, jsou vyžadovány atributy description a uniqueInstance. Atribut uniqueInstance obsahuje binární hodnoty: TRUE … prvek nadtřídy může být prvek pouze jedné podtřídy, FALSE … prvek nadtřídy může být prvkem více než jedné podtřídy.

Prvek GF_InheritanceRelation je modelován jako generalizační vztah UML. Nepovinný atribut name může být připojen ke generalizačnímu vztahu, pokud je součástí generalizační sady, v tom případě musí mít každý člen sady stejné jméno. Jinak by tento atribut neměl být implementován. Popis atributu description je obsažen v dokumentaci modelu. Výchozí nastavení generalizační sady je vyjádřeno nastavením atributu uniqueInstance na hodnotu pravda. Je třeba použít omezení {překrývání} generalizační sady, pokud je hodnota uniqueInstance nepravda.

Vezměme si příklad na obrázku 10. Typ prvku Budova (Building) má dvě podtřídy: školu (School) a nemocnici (Hospital). Typ prvku Budova má tři atributy: délka, šířka* a numberOfStories, které jsou zděděny oběma jeho podtřídami. Každá z podtříd má specifické atributy: pro školy: vzdělávací úroveň (educationalLevel) a numberOfTeachers; pro nemocnici: počet lůžek (numberOfBeds). Dva generalizační vztahy patří do generalizační množiny s názvem Function.

Obrázek 10: Příklad dědičnosti (zdroj: Kresse, Danko, 2012)

Všechny tři třídy (budovy, nemocnice, školy) jsou prvky metatřídy GF_FeaturType GFM. Hierarchický vztah, v němž jsou budovy zobecněním nemocnic a škol je výsledkem aplikace GF_InheritanceRelation na danou třídu.

5.2.3.3 GF_AssociationType (asociační typ)

Existují dva vztahy mezi GF_FeatureType a GF_AssociationType:

• Asociace nazvaná TypeAssociation na obrázku 9 indikuje, že může být prvek třídy GF_FeatureType součástí prvku GF_AssocitationType. Obecně, GF_AssociationType je implementován v aplikačním schématu jako jednoduchá UML asociace mezi dvěma třídami, které reprezentují různé typy prvků.
  
• Druhý vztah mezi GF_FeatureType a GF_AssociationType je vztah dědičnosti, který z GF_AssociationType vytváří podtřídu GF_FeatureType.

Jako podtřída GF_FeatureType zdědí GF_AssociationType tři atributy GF_FeatureType, i když je v případě GF_AssociationType název nepovinný. GF_AssociationType také zdědí asociace GF_FeatureType. To znamená, že může obsahovat vlastnosti, v tomto případě může být modelována v aplikačním schématu raději jako asociační třída UML než jako asociace UML. Dalším typickým příkladem je most, který lze modelovat jako silniční úsek nebo jako samostatný prvek se zvláštní informací o nadjezdu. V prvním případě může být most jednoduše asociován se dvěma dalšími silniční segmenty. V dalším je most instancí GF_FeatureType.

5.2.3.4 GF_Constraint (omezení)

GF_FeatureType i GF_PropertyType jsou asociovány s GF_Constraint. GF_AssociationType dědí tuto asociaci z GF_FeatureType. GF_Constraint představuje popis omezení, které může být aplikováno na případ jakékoliv asociované metatřídy. Příkladem je silnice, která na které je povolen pohyb pouze dopravním prostředkům s rychlostí vyšší než 60 km/h.

5.2.3.5 GF_PropertyType (typ vlastnosti)

Jak ukazuje asociační vztah mezi GF_FeatureType a GF_PropertyType (obrázek 9), třída typ prvku může obsahovat nulu pro mnoho instancí z GF_PropertyType. GF_PropertyType je abstraktní metatřída se třemi podtřídami: GF_AssociationRole, GF_AttributeType a GF_Operation, z nichž každá reprezentuje jiný typ vlastnosti, který může být přiřazen ke třídě typu prvku. Třída GF_PropertyType obsahuje pouze název a popis typu vlastnosti (atributy memberName a description). Všechny další podrobnosti jsou obsaženy v podtřídách.

GF_PropertyType (obrázek 11) má dva atributy, které jsou zahrnuty v každém případě:

• memberName obsahuje název typu vlastnosti představovaný instancí;
• definition obsahuje definici tohoto typu vlastnosti.

5.2.3.6 GF_AssociationRole (asociační role)

GF_AssociationRole popisuje roli, kterou instance typu prvku může mít v asociaci s jinou instancí stejného nebo jiného typu. GF_AssociationRole zdědí atributy název člena (memberName) a definice (definition) GF_PropertyType. Další atribut mohutnost (cardinality) určuje multiplicitu pro případy typu prvku působícího v dané roli. GF_AssociationRole zdědí asociaci s GF_Constraint z GF_PropertyType, ale má také asociaci z GF_AssociationType, která určuje, že je součástí instance GF_AssociationType.

V UML diagramu jsou atributy memberName a cardinality vyjádřeny rolí názvu a multiplicity na konci linie reprezentující asociaci. Atribut definition je zahrnut v dokumentaci modelu.

Uvažujme příklad na obrázku 5, kde role názvu property indikuje, že případ třídy House může být majetkem jednoho nebo více případů třídy Person s rolí owner.

5.2.3.7 GF_AttributeType (typ atributu)

Instance GF_AttributeType popisuje typ atributu, který patří k určitému typu prvku. GF_AttributeType má vedle atributů memberName a definition také atributy, které zdědí z GF_PropertyType. Atribut valueType určuje datový typ atributu. Atribut domainOfValues identifikuje sadu hodnot, které může atribut nabývat. Atributová mohutnost cardinality určuje multiplicitu atributu typu prvku.

GF_AttributeType zdědí asociaci s GF_Constraint z GF_PropertyType, ale má také asociaci k sobě samému zvanou attributeOfAttribute. To ukazuje, že atribut může mít sám atributy. V tomto případě je atribut modelován jako třída UML, která může být použita jako datový typ pro atribut nebo asociována s typem prvku.

UML reprezentace atributu zahrnuje memberName, datatype a cardinality. Definice domainOfValues musí být specifikována v datovém slovníku.

Obrázek 12 znázorňuje tři způsoby, kterými může být GF_FeatureAttribute vyjádřen v aplikačním schématu. Atribut routeNumber prvku RoadSegment je specifikován v rámci atributové části třídy RoadSegment. Atribut surfaceMaterial má sám o sobě atributy; to je specifikováno v prostoru atributů diagramu třídy, ale používá jako svůj datový typ samostatně definovanou. Atribut prvku maintenanceHistory, který má také atributy, je modelován jako samostatná třída připojená k prvku asociací. Všimněte si, že název role na konci UML asociace je analogický názvu atributu pro třídu na druhém konci asociace.

5.2.3.8 GF_Operation (operace)

Instance GF_Operation popisuje spojené s typem prvku. Vedle atributů memberName a definition, které dědí z GF_PropertyType, má GF_Operation další atribut signature, který poskytuje název, argumenty a typy výstupů.

Jako příklad uvažujme operaci nazvanou trafficFlow, která slouží jako vlastnost typu prvku Highway. Taková operace může mít signaturu

trafficFlow(dayofWeek:DayName, timeofDay:Time):vehiclesPerHour:Integer.

Tato signatura indikuje, že operace akceptuje jako vstupní parametry den v týdnu a denní dobu a vrací jako výstup (celočíselný) počet vozidel za hodinu.

GF_Operation dědí asociaci s GF_Constraint z GF_PropertyType, ale má také čtyři další asociace. Tři s GF_AttributeType popisují způsob, jakým může instance GF_Operation používat jednu nebo více hodnot atributu. Role triggerdByValuesOf identifikuje typy atributů, které slouží jako spouštěče operace. Role observesValuesOf identifikuje typy atributů, které jsou použity jako vstupní parametry operace. Role affectsValuesOf identifikuje typ atributu, který je výstupním parametrem operace. Asociace s GF_AssociationType identifikuje cesty, kterými instance GF_Operation získává informace o atributech, které používá.

5.3 Ukázka aplikačního schématu

Tato část představuje příklad jednoduchého aplikačního schématu vyvinutého podle výše popsaných principů. Schéma odpovídá GFM a je popsáno v UML.

Příkladem je aplikační schéma pro popis prostorové charakteristiky jedné farmy. Zahrnuje ty funkce, které lze zobrazit na mapě (obrázek 12). Prvky jsou k dispozici s dostatečnými atributy pro odlišení jedné instance od druhé. Schéma využívá tři třídy geometrických objektů uvedené v ISO 19107 k popisu prostorové polohy a geometrie těchto typů prvků. Vybrané objekty jsou vhodné pro dvourozměrný souřadný prostor a mapu.

V tomto schématu má farma tři atributy: název, vlastník a oblast představovaná jako GM_Surface. Multiplicita (mnohočetnost) atributu land naznačuje, že farma může být složena z nesousedících pozemků. Farma sdružuje instance dvou dalších typů prvků: SubAreas a Buildings. Farma musí mít alespoň jednu SubArea, ale nemusí mít žádné budovy. Jednodušše vyjádřené omezení na farmě naznačuje, že celá plocha farmy musí být zahrnuta do agregací SubArea. Označení navigability ukazují, že je možné dotazovat objekt farmy za účelem zjištění, které instance třídy SubArea a Building se nacházejí na farmě, ale není možné se dotazovat objekty tříd Buildings nebo SubArea a určit tak, jaké instance třídy Farm k nim patří.

Obrázek 12: Jednoduché schéma farmy (zdroj: Kresse, Danko, 2012)

Typy prvků SubArea a Building mají vlastnosti, které popisují jejich umístění, geometrii a použití. Všimněte si, že žádný typ prvku nemá atribut identifikátoru; instance lze od sebe odlišit podle jejich umístění. Prostorové vztahy mezi SubAreas and Buildings nejsou popsány asociacemi, protože je lze odvodit z jejich atributů umístění.

Budova je považována za bodový objekt, tj. její umístění je popsáno jako DirectPosition. Velikost budovy je popsána třemi požadovanými atributy, které poskytují její rozměry pomocí měr délky definovaných jako datový typ v ISO/TS 19103 [1.2]. Funkce budovy je určena jednou z hodnot ze seznamu kódů BuildingUse, přičemž budova může mít více než jednu funkci.

S typem prvku SubArea je zacházeno jako s dvou-dimenzionálním objektem. Poloha i geometrie jsou popsány geometrickým objektem GM_Surface. Jeho použití je dáno jednou z hodnot ze seznamu kódů LandUse.

Asociace AccessControl ukazuje, že přístup k SubArea může být omezen množinou plotů (Fences). Násobnost (multiplicita) na uzavřeném konci asociace enclosedArea odráží skutečnost, že každá instance plotu odděluje dvě oblasti, z nichž jedna z těchto oblastí může být vyloučena ze souboru dat, protože je mimo hranice farmy. Násobnost na druhém konci asociace podporuje neoplocené instance typu SubArea, ale je neomezená, neboť každá ze sousedních instancí typu SubArea je považována za oddělenou od této instance jedinečnou instancí plotu (Fence). Tato asociace je navigovatelná v obou směrech, což znamená, že je možné určit vlastnosti jakékoli instance plotu, která ohraničuje instanci SubArea a určit charakteristiky instancí typu SubArea, které jsou ohraničeny jakoukoliv instancí typu Fence.

Plot je považován za jednorozměrný objekt, jehož geometrie je popsána GM_Curve, ale má také atribut výšky. Instance plotu může mít množinu nula k mnoha otvorům, z nichž každý je řízen instancí Gate. Každá instance brány (Gate) je asociována pouze s jednou instancí plotu. Navigovatelnost asociace znamená, že objekt Fence ví o souvisejících případech brány, ale ne naopak.

Brána (Gate) je považována za bodový objekt, takže její umístění je popsáno jako DirectPosition, ale je také dána výška a atributy její šířky.