Postup analytických prací při návrhu GIS

Jiří NOVOTNÝ


1. Úvod
2. Programové vybavení na SVSmP
2.1. GS Web
2.2. GS Průzkumník
2.3. GeoStore V6
3. Veřejné osvětlení
3.1. Terminologie a dělení VO
3.2. Údržba VO
4. Metodika návrhu systému na příkladech veřejného osvětlení
4.1. Požadavky
4.1.1. Funkční a nefunkční požadavky
4.2. Analýza a logická úroveň modelu
4.2.1. Případy užití a účastníci
4.2.2. Stavový diagram systému
4.3. Návrh a fyzická úroveň modelu
4.3.1. Diagram objektových tříd
4.3.2. Podstavy stavového diagramu systému
4.4. Implementace
4.4.1. Sekvenční diagram
4.4.2. Diagram spolupráce
4.4.3. Diagram činností
4.4.4. Diagram komponent a jejich nasazení
5. Závěr
6. Zdroj
6.1. Použitá literatura
6.2. Použité prameny

1. Úvod

Semestrální práce se zabývá problematikou zpracování a uchování informací. Její cíl je navrhnout datový model veřejného osvětlení pro uchování dat v Geografickém informačním systému města Plzně. Vývoj systému je popsán v objektově-orientovaném jazyce, především pomocí UML(Unified Modeling Language) diagramů a je prováděn na základě požadavků koncových uživatelů, kterými jsou pracovníci Správy veřejného statku města Plzně. Semestrální práce zároveň poslouží jako dokumentace systému ve všech fázích jeho vývoje.

2. Programové vybavení na SVSmP

Správa veřejného statku města Plzně (SVSmP) je jeden z hlavních poskytovatelů dat pro Geografický informační systém (GIS) města Plzně. Pro správu grafických a popisných dat je vytvořen centrální datový sklad na bázi MicroSoft SQL Server 2000, který udržuje Správa informačních technologií města Plzně (SITmP). Hlavní programy, které využívá SVSmP pro práci s daty centrálního skladu jsou produkty firmy GeoVap, spol. s r.o.:

GS Web,

GS Průzkumník,

GeoStore V6.

2.1. GS Web

GS Web je prostředek pro zobrazení grafických a popisných informací uložených v relační databázi. Jediný software nutný pro prohlížení dat je standardní www prohlížeč. GS Web spojuje výhody prostředí Intranetu/Internetu a relační databáze. Přístup k datům lze standardně určit pro různé uživatele na straně databáze. Na straně klienta se neukládají žádná data. Prostřednictvím GS Webu není možné získat zobrazovaná grafická data. GS Web je tedy jednoduchý a proti zneužití zabezpečený prostředek pro plošné šíření geografických dat [6].

Klient umožňuje:

výběr objektů z databáze,

zapínání a vypínání zobrazovaných vrstev,

zmenšování měřítka,

posun,

měření délek a ploch,

vyhledávání textů,

přehledové tisky v měřítku,

tvorba legend.

2.2. GS Průzkumník

GS Průzkumník je prostředek sloužící ke čtení a editování popisných informací uložených v relační databázi. Aplikace může pracovat samostatně nebo ve spolupráci s aplikací GS Bas běžící v prostředí MicroStation. Spolupráce s GS Bas umožňuje zobrazení grafické reprezentace prvku a obráceně nalezení popisných údajů o prvku, na jehož grafickou podobu je ukázáno v DGN výkresu [6].

2.3. GeoStore V6

GeoStore V6 je desktopový GIS a zároveň grafický editor. Touto verzí se firma GeoVap spol.s r.o. oprostila od užívání grafického editoru v prostředí MicroStation a vytvořila vlastní grafický editor. GeoStore V6 je GIS vyvinutý v technologii Microsoft .NET. GeoStore V6 v sobě spojuje nejdůležitější funkce pro tvorbu, aktualizaci a správu geografických dat s pokročilými funkcemi GIS. Může sloužit jako grafický editor s plnou škálou editačních funkcí obvyklých u CAD nástrojů nebo jako pokročilý desktopový GIS systém [6].

GeoStore V6 je programovatelný systém. Hlavní metody a datové struktury jádra systému jsou veřejné. To přináší nejvyšší stupeň otevřenosti vůči uživatelům-vývojářům. Ti mohou rozvíjet funkcionalitu systému vlastními moduly a aplikacemi vyvíjenými standardními prostředky technologie .NET [6].

3. Veřejné osvětlení

Veřejné osvětlení (VO) je technické zařízení sloužící k zajištění osvětlení komunikací, náměstí a veřejného prostranství. Za VO se může považovat i zařízení napájené na rozvod VO.

3.1. Terminologie a dělení VO

VO se dělí na:

• Světelné místo. Světelné místo může tvořit:

- Lampa na stožáru.

- Lampa na objektu.

- Lampa na převěsu.

• Speciální světelná místa. Speciální světelná místa mohou být:

- Veřejné telefonní automaty.

- Označníky MHD.

- Výstražné majáky MHD.

- Přístřešky MHD s vitrínou.

- Informační panely.

- Dopravní značky.

- Parkovací automaty.

- Hodiny.

- Mapy MIOS.

- Vánoční převěsy.

- Radary.

3.2. Údržba VO

Údržba VO je podle [7] činnost spravující a řídící nebo činnost provádějící. Činnost spravující a řídící může být:

• Vlastnictví a správa zařízení VO.

• Činnost správce při výstavbě a obnově VO.

• Činnost správce při provozu VO.

• Vedení pasportizace.

Činnost prováděcí tvoří:

• Běžná údržba.

• Preventivní údržba.

• Škody a havárie na VO.

• Pohotovostní služba.

• Revize VO.

• Likvidace odpadu z provozu VO.

4. Metodika návrhu systému na příkladech veřejného osvětlení

Většina aplikací je dnes psána v objektově-orientovaných jazycích. Objekty popisují komplexní realitu, dovolují urychlit vývoj aplikace a zjednodušit jej díky polymorfismu a dědičnosti. Čím složitější je modelovaná skutečnost, tím spíše se ukáže, že ji lze popsat pouze objektově, nebo že entitně-relační model by byl tak složitý, až by se stal v praxi nepoužitelný. Objekty mají oproti relačním strukturám jednu zásadní nevýhodu. Na rozdíl od entitně-relačního modelu neexistuje ucelená teorie a metodika, která říká jak objektový model navrhnout. Metodika představuje strukturu a charakter kroků vývoje systému. Metodika obsahuje pět základních pracovních postupů jež určují, co je třeba udělat, a způsob, jakým toho dosáhneme. Tyto pracovní postupy se však mohou navzájem prolínat, čím dosáhneme vylepšování jednotlivých pracovních postupů.

1. Požadavky. Zachycují to, co by měl systém dělat.

2. Analýza. Vybroušení požadavků a jejich strukturování.

3. Návrh. Realizace požadavků v architektuře systému.

4. Implementace. Tvorba fyzického modelu.

5. Testování. Ověřování, zda implementace funguje tak, jak se od ní očekává.

Pracovní postupy jsou chápány tak, že než se začne programovat musí vývojáři znát strukturu požadavků. Tato struktura požadavků tvoří ve vývoji systému konceptuální úroveň modelu, která může být reprezentována:

Diagramem případu užití (Use Cases).

Stavovým diagramem systému.

Díky těmto modelům můžeme provést návrh požadavků, který ve vývoji systému tvoří logickou úroveň modelu. Logická úroveň může být reprezentována:

Stavovým diagramem systému.

Diagramem objektových tříd.

Převedením návrhu požadavků do implementace, získáme fyzickou úroveň modelu. Fyzická úroveň může být reprezentována:

Sekvenčním diagramem.

Diagramem spolupráce.

Diagramem činností.

Diagramem komponent.

Diagram objektových tříd přizpůsobený softwaru.

Kódem

Fyzickým uložením v databázi

Výsledek se po otestování a nasazení aplikace stane funkčním systémem.

Zavedeným standardem pro dokumentování systému ve všech fázích jeho vývoje je jazyk UML. Unifikovaný modelovací jazyk UML plně podporuje objektový přístup. „Model má při tvorbě softwaru stejný význam jako výkres při realizaci stavby“[4]. Pomocí grafických symbolů umožňuje přehledně a srozumitelně dokumentovat problém a usnadňuje tak komunikaci mezi programátory a zákazníky.

4.1. Požadavky

Požadavky lze rozdělit na funkční (functional requirements) a nefunkční (non-functional requirements). Jejich grafické vyjádření provedeme v analýze pomocí diagramu případu užití (use case) s podrobným popisem účastníků (actors) a pomocí stavového diagramu.

4.1.1. Funkční a nefunkční požadavky

Funkční požadavky popisují požadovanou funkci systému. Je to formulace toho, co by měl systém dělat. Tuto formulaci aplikujeme konkrétně na systém VO:

Systém bude ověřovat uživatele.

Systém bude ukládat do databáze hodnoty k VO:

Číslo VO (2-5 míst), které je umístěno fyzicky na objektu v podobě kovového štítku – id_místo.

Typ objektu VO – rc.

Identifikuje rozvaděč, ze kterého je světelné místo napájeno - id_roz.

Celkový příkon VO – prikon.

Adresa nebo popis umístění VO – lokalita.

Číselník materiálů v případě podpěry stožár - cc_sloup.

Výška podpěry - vys_podp.

Rok osazení podpěry - dat_podp.

Číselník materiálů patice v případě podpěry stožár - cc_patice.

Číselník odstínů nátěru v případě podpěry stožáru - cc_nater.

Rok nátěru podpěry - dat_nater.

Počet výložníků podpěry – vyloz.

Číselník materiálů výložníků - cc_vyloz.

Číslo zakázky označuje podklad pro přesné umístění grafického prvku do databáze – zakazka.

Číselně označuje majitele VO – majitel.

Systém bude ukládat do databáze hodnoty k svítidlu:

Identifikační číslo svítidla - id_svit.

Číselník názvů svítidla podle katalogu: Svítidla používána k veřejnému osvětlení města Plzně - cc_svit.

Číselník označení typů svítidla dle katalogu: Svítidla používaná k veřejnému osvětlení města Plzně - cc_typ.

Rok osazení svítidla - dat_osaz.

Velikost ramena - ram_vel.

Číselník typů ramen - cc_rameno.

Příkon svítidla – prikon.

Číselník zdrojů svítidel - cc_zdroj.

Rok osazení zdroje svítidla - dat_zdroj.

Požadavek nefunkční formuluje omezení kladená na systém nebo proces vývoje. Je to omezující podmínka uvalená na daný systém.

Založení nového objektu VO bude v programu GeoStore V6.

Aktualizace objektu VO bude v programu GS Průzkumník.

Vizualizace dat bude v programu GS Web.

4.2. Analýza a logická úroveň modelu

Analýza spočívá v tvorbě modelů, jež zachycuje podstatné požadavky a charakteristické rysy požadovaného systému. Modelování analýzy je strategickou aktivitou, neboť se během ní snažíme o modelování základního chování systému. Záměrem analýzy z pohledu objektově orientovaného analytika je tvorba analytického modelu. Tento model se zaměřuje na to, co systém musí udělat, avšak nezabývá se detaily týkající se způsobu, jakým to udělá. Tuto otázku přenecháme pracovnímu postupu návrh.

Analytický model:

Je v jazyce daného odvětví.

Zachycuje problém z určité perspektivy.

Obsahuje analytické třídy a realizace případů užití, jež modelují problémovou doménu.

Vypráví příběh o požadovaném systému.

Je užitečný pro maximální počet uživatelů a zúčastněných osob.

Logická úroveň je nezávislá na implementaci a pracuje s pojmy:

Entita. Entita je určité seskupení dat.

Atribut. Atribut je položka dané entity.

Vazba. Vazba určuje vztahy mezi entitami.

4.2.1. Případy užití a účastníci

Případy užití zachycují přesně funkčnost, která bude budoucím informačním systémem pokryta a vymezují tak jednoznačně rozsah práce [1]. Modelování případů užití je způsob vybroušení požadavků a zároveň konstrukt popisující, jak se bude systém jevit potenciálním uživatelům. Modelování případů užití se skládá z následujících aktivit:

Nalezení hranic systému.

Vyhledání účastníků.

Nalezení případů užití.

Specifikace případů užití.

Tvorba detailu případů užití.

Výstupem aktivit je model případů užití. Tento model obsahuje komponenty:

Účastníci (actors). Účastníci jsou vyjádřením rolí přidělených předmětům, které bezprostředně používají daný systém. Účastníci jsou vůči systému externími entitami.

Hranice systému (system boundary). Hranice určuje co je součástí systému a co naopak není. Hranici systému definuje ten, kdo systém používá, a to, co specifikuje je přínos systému účastníkům.

Relace include (relationships include). Tato relace vyčleňuje kroky společné několika případů užití do samostatného případu užití, který je do příslušných případů užití následně zahrnut.

Obr.3.1: Případ užití systému VO

Popis účastníků- aktéři systému užití klienta GIS jsou:

Zamestnanec1 je uživatel, který zadává do databáze světelné místa. V případu užití mu je přiřazena možnost spouštět dva případy užití.

Technik je uživatel, který aktualizuje již v databázi existující data. V případu užití mu je přiřazena možnost spouštět dva případy užití.

Zamestnanec2 je uživatel, který zadává do databáze speciální světelné místa. V případu užití mu je přiřazena možnost spouštět dva případy užití.

UzivatelGIS má možnost zobrazit data v GS Webu a tedy možnost spouštět jeden případ užití.

Detail případu užití- vstupní podmínky jsou kritéria, která musí být splněna ještě předtím, než je možné spustit případ užití. Toky událostí jsou jednotlivé kroky v případu užití. Následující podmínky jsou kritéria, jež musí být splněny na konci případu užití.

Obr.3.2: Detaily případů užití systému VO

4.2.2. Stavový diagram systému

Systém je převážně tvořen grafickým uživatelským rozhraním (GUI). Stavový diagram reprezentuje všechny stavy, do nichž se může účastník případu užití v GUI dostat, a také podmínky přechodů mezi jednotlivými stavy. Systémové změny v tomto diagramu jsou popsány, tak že požadavky na systém mění v čase svůj stav.

Obr.3.4: Stavy a přechody grafického uživatelského rozhraní

Výsledkem akcí provedených ve stavu Inicializace je, že GUI přejde do stavu Práce. Rozhodne-li se uživatel svůj počítač vypnout, spustí událost, která způsobí přechod GUI ze stavu Práce do stavu Ukončování a počítač se vypne.

4.3. Návrh a fyzická úroveň modelu

Dalším krokem je návrh datového modelu na fyzické úrovni. Fyzická datová úroveň již zohledňuje zvolenou relační databázi, v našem případě MS SQL Server 2000 a pracuje s pojmy:

Databáze- organizovaná struktura dat uspořádaná do tabulek.

Tabulka- datová struktura organizovaná do řádků a sloupců. Z logické úrovně převedený typ entity.

Řádek- informace o jedné entitě uložené v databázi.

Sloupec- totéž co v logickém datové úrovně atribut.

4.3.1. Diagram objektových tříd

Diagram objektových tříd je strukturní diagram. Třídy a objekty jsou základními stavebními bloky všech objektově orientovaných systémů. Objekt kombinuje data a funkce do jedné soudržné jednotky. Objekt se vyznačuje:

identitou,

stavem,

chováním.

Každý objekt je instancí třídy. Třídy popisují charakteristické rysy určité množiny objektů, které spojuje určitá relace. Pro návrh objektových systémů se předpokládá, že je třeba navrhnout model tříd objektů. Třída objektů je definována svými atributy a metodami. Atributy třídy objektu reprezentují stav objektu a metody jeho chování.

Obr.3.3: Diagram objektových tříd systému VO

4.3.2. Podstavy stavového diagramu systému

Stav objektu ve stavovém diagramu se může skládat z více podstavů, jako je to v stavu Práce. Podstavy stavového diagramu jsou procesní diagramy a mohou být dvojího druhu: sekvenční nebo souběžné. V našem případě se jedná o podstavy sekvenční.

Obr.3.5: Sekvenční podstavy ve stavu Práce objektu GUI

4.4. Implementace

4.4.1. Sekvenční diagram

„Sekvenční diagram jazyka UML doplňuje přehled interakcí mezi objekty o rozměr času“ [4]. Sekvenční diagram je procesní diagram, je dvourozměrný a popisuje jak spolu objekty v čase komunikují. Ubíhající čas se zobrazuje vertikálně směrem dolů. Objekty jsou zakresleny vedle sebe zleva doprava. Sekvenční diagram popíše interakci GUI s dalšími objekty, kde klade důraz především na pořadí jednotlivých událostí.

Obr.3.6: Sekvenční diagram zachycující stav objektu

Popis sekvencí:

GeoStore předá MS SQL Serveru 2000 zprávu o uložení zadaných dat.

MS SQL Server 2000 o tom informuje GS Web zprávou o zobrazení.

GeoStore obdrží vizuální zpětnou vazbu a uložená data zobrazí.

GS Web zobrazí příslušné data.

4.4.2. Diagram spolupráce

Diagram spolupráce stejně jako sekvenční diagram je procesní diagram a zobrazuje interakci mezi objekty. Zobrazuje jednotlivé objekty spolu se zprávami, které zasílají ostatním objektům. Diagram spolupráce zdůrazňuje spíše kontext a uspořádání spolupracujících objektů.

Obr.3.7: Diagram spolupráce pro GUI

Popis spolupráce:

GeoStore předá MS SQL Serveru 2000 zprávu o uložení zadaných dat.

MS SQL Server 2000 o tom informuje GS Web zprávou o zobrazení.

GeoStore obdrží vizuální zpětnou vazbu a uložená data zobrazí.

GS Web zobrazí příslušné data.

Diagram sekvencí a diagram spolupráce jsou sémanticky ekvivalentní, ale při vytváření modelu systému je vhodné použít oba typy. Zatímco sekvenční diagram je organizován v závislosti na čase. Diagram spolupráce je organizován v závislosti na prostoru.

4.4.3. Diagram činností

Diagram činností je prostředek, který umožňuje zjednodušený přehled jednotlivých kroků operace nebo procesu. Diagram činností je procesní diagram a zachycuje kroky, rozhodování a větvení sekvencí. Diagram činností je rozšířením stavového diagramu.

Obr.3.8: Diagram činností popisující práci Zamestnance1

Popis činnosti:

Zaměstnanec otevře program GeoStore.

Zaměstnanec se připojí k databázi.

Má-li zakreslit prostorový prvek, načte grafická data z tabulky VO_VEROSV_GS a zakreslí změnu.

Má-li vložit popisné data k již existujícím grafickým datům, spustí GS Průzkumník a vybere tabulku VO_VEROSV_GS.

V obou případech vyplní popisné atributy do tabulky VO_VEROSV_GS a poté do tabulky VO_SVIT.

Zadané hodnoty se uloží a zaměstnanec program ukončí.

4.4.4. Diagram komponent a jejich nasazení

Diagram komponent je strukturní diagram, zobrazuje softwarové komponenty a jejich vztahy. Softwarové komponenty jsou uloženy v paměti počítače. „Diagram nasazení jazyka UML ukazuje, jak bude fyzický systém vypadat po sestavení“ [4].

Obr.3.9: Diagram komponent a jejich nasazení

Systém VO byl popsán pomocí objektově-orientovaného přístupu a především na diagramech v syntaxi UML. Nicméně datový sklad pracuje na relační bázi, kterému je třeba se přizpůsobit, protože organizace má všechna data uložena právě v tomto relačním datovém skladu. Pro vytvoření návrhu fyzického datového modelu podle požadavků a analýz popsaných objektově-orientovaným přístupem bude potřeba objektový model tříd z kap.3.2.1. Návrh fyzického datového modelu vytvoříme tak, aby mohl rozumně získávat data z tabulek relační databáze.

Mapování tříd na tabulky

V tomto typu mapování se atributy třídy stanou sloupci tabulky. Instance objektů se stanou odpovídající řádkem tabulky. Pomocí mapování dědičnosti zahrneme podtřídy do nadtřídy.

Obr.3.10: Mapování dědičnosti zahrnutí do nadtříd

Pomocí mapování asociace 1:N nadefinujeme cizí klíč v tabulce, který odkazuje na příslušný řádek v nadřazené tabulce.

Obr. 3.11: Mapování asociací 1:N

Obr.3.10: Výsledný relační datový model VO s číselníky

5. Závěr

Cíle semestrální práce byly splněny. Byl vytvořen datový model systému a zároveň jeho dokumentace. Výsledný relační model popisuje uchování dat v databázi prostřednictvím tabulek. Pomocí relačního modelu bude napsán kód v jazyce SQL (Structured Query Language), který bude implementován do databáze. Semestrální práce zároveň poskytuje dostatečnou dokumentaci pro případný zásah do tohoto systému.

6. Zdroj

6.1. Použitá literatura

[1] ARLOW, J.- NEUSTADT, I. UML a unifikovaný proces vývoje aplikací. Přeložil Bohdan Kostka. 1.vyd. Brno: Computer Press, 2003. ISBN 80-7226-947-X.

[2] KEOGH, J.- GIANNINI, M.OOP bez předchozích znalostí. Přeložila Matějů Veronika. 1.vyd. Brno: Computer Press, 2006. ISBN 80-251-0973-9.

[3] PAGE-JONES, M. Základy objektově orientovaného návrhu v UML. Přeložil Voráček Karel. 1.vyd. Praha: Grada, 2002. ISBN 80-247-0210-X.

[4] SCHMULLER, J. Myslíme v jazyku UML. 1.vyd. Praha: Grada, 2001. ISBN 80-247-0029-8.

[5] TUČEK, J. Geografické informační systémy- principy a praxe. Praha: Computer Press, 1998. ISBN 80-7226-091-X.

6.2. Použité prameny

[6] GEOVAP spol. s r.o. GS technologie [on-line]. c2001-2006, [cit. 2006-09-29]. URL: <http://www.geostore.cz/index.asp>

[7] Kostelníček J. Geografický informační systém jako nástroj plánování údržby veřejného osvětlení. (Diplomová práce) Ostrava: VŠB- Technická univerzita Ostrava, 2001.

[8] Správa informačních technologií města Plzně. Geografický informační systém města Plzně[on-line].c2002, [cit. 2006-09-29]. URL: <http://gis.plzen-city.cz/ogis>