• Meta-model
• (orto-) model aplikaèní domény

Meta-model definuje základní metatřídy jako třída, atribut, metoda, vztah, objekt, kategorie, obraz apod. Model aplikační domény reprezentuje uživatelovu (aplikační) problematiku a zahrnuje aplikační třídy typu OBČAN, ULICE, DŮM, PARCELA apod. včetně jejich atributů a vztahů mezi nimi. Tyto složky aplikačního modelu jsou definovány jako objekty meta-tříd.

Zde je třeba podtrhnout jednu skutečnost – model chápe vektorový grafický obraz objektu jako jeho strukturovaný atribut. Tzn. že principiálně nerozlišuje mezi popisnou a grafickou informací a v tomto smyslu je rovnocenně a jednotně používá pro všechny standardní operace (výběry, prezentace, relační operace apod.). Jediný rozdíl je v nástrojích, které jsou “uvnitř” i “vně” používány k manipulaci s těmito údaji a souvisejí se specifickým formátem údajů. Vlastní tvar obrazu každého objektu je uložen obecně v “databázi grafických obrazů”, ať už je implementovaná jakkoli.

Tím se vysvětluje i pozvolný ale nevyhnutelný trend v pojímání IS pro místní samosprávy a státní správu na komunální resp. zemské úrovni – splývání řešení GIS a MIS do jediného integrovaného IS. Systém Ameba přesně takto řešenou problematiku pojímá.

Objektové třídy:

Vztahy :

1.2. Implementace modelu

Způsob implementace modelu je založen především na datově orientované definici modelu, tzn. že veškeré definice tříd, atributů, metod, vztahů (orto i meta modelu) apod. jsou uloženy v databázi na rozdíl od funkcionalistických přístupů pomocí “programovaných” knihoven. Tento přístup byl zvolen právě z toho důvodu, aby v databázi uložené (persistentní) objekty byly nezávislé na jakýchkoli “standardních” knihovnách. Tyto knihovny se uplatní až na úrovni 2. vrstvy třívrstvé architektury aplikačního (programového) produktu, který z persistentních objektů z databáze vytvoří přechodné (transientní) tzv. business resp. enterprise objects.

Tento způsob implementace má ve svém důsledku další pozitivní rys – otevírá totiž prostor pro takové řešení aplikačního systému, které umožňuje definovat objektový model i oprávněnému koncovému uživateli !!! s tím, že si svou předmětnou problematiku může rozvíjet bez závislosti na vývojáři aplikace.

Toto pojetí v konečném důsledku umožnilo vytvořit jediný produkt, který není členěn na jednotlivé aplikačně zaměřené moduly (programy, aplikace, subsystémy apod.). Tyto moduly jsou nahrazeny modely jednotlivých aplikačních témat (domén), které systém “umí přečíst a interpretovat” podobně, jako se člověk orientuje v mapě.

Model aplikačních témat

1.3. Autentizace a autorizace

Pro řešení autentizace a autorizace jsou v rámci meta-modelu definovány dvě třídy – ROLE a USER. Třída USER umožňuje zavést do systému jednotlivé uživatele s jejich jménem, heslem a dalšími atributy. Samozřejmě, jako každá třída je i tato třída vybavena patřičnými metodami.

Výskyty třídy ROLE reprezentují v podstatě funkční zařazení uživatelů resp. obecněji zaměření útvaru, ve kterém uživatelé pracují. V každém případě každá role definuje oprávnění (autorizaci) přístupu k jednotlivým složkám modelu aplikační domény, tzn.

• ke kterým třídám (objektů a vztahů) má role přístup
• ke kterým atributům (popisným i obrazovým) výše uvedených tříd má role přístup
• ke kterým metodám výše uvedených tříd má role přístup

a to ve smyslu přístupu

• aktivního (možnost vytvoření, zrušení, změny)
• pasivního

Definice uživatelů a rolí je umožněna stejnými nástroji, které jsou určené koncovému uživateli pro práci v rámci aplikačních témat. Je přitom umožněno přiřazení jednoho a více uživatelů jedné roli a jednoho uživatele do více rolí. Samozřejmě v rámci každého přihlášení do systému (autentizaci) si daný uživatel musí vybrat pouze jednu z rolí, do kterých je zařazen.

2. Integrační schopnosti

Posuzování této charakteristiky systému provázel zvláštní akcent. Vyplýval zejména ze známé skutečnosti, že pokud uživatel disponuje několika subsystémy od různých dodavatelů, má zpravidla neřešitelné problémy s integritou systému jako celku. Problém integrace má různá specifika podle úrovně uplatněné technologie a zdrojů jednotlivých aplikačních komponent.

V případě

• klasického funkcionalistického pojetí řešení je otázka integrace spojena s integritou datových modelů jednotlivých aplikačních systémů a specifické (aplikační) funkční výbavy. Tyto systémy jsou víceméně “natvrdo” naprogramované v závislosti na daném datovém modelu. Každá případná změna v datovém modelu (vyvolaná například požadavkem integrace) si vynucuje zásah mnohdy radikální (a tedy drahý) do funkčního aparátu systému. Nehledě na to, že pro jednotlivé implementace je nutno vést speciální modifikace téhož produktu a zajišťovat jejich vývoj.
• Další problémy nastávají pokud se funkcionalita jednotlivých systémů duplikuje (přirozeně jako důsledek duplicit v datovém modelu). Mnohé systémy neumí svoji výbavu “jemně” škálovat podle konkrétních implementačních potřeb. Dlužno podotknout, že zmíněné neduhy mají i systémy, pro jejichž vývoj byly použity nástroje a postupy objektové technologie (tzv. object based systems).
• objektově orientovaného řešení (object oriented systems) jsou tyto problémy v poněkud jiné poloze. Je zde přirozeně možná jemná škálovatelnost vzhledem ke komponentové struktuře a tudíž i přizpůsobivosti funkčním i datovým změnám (polymorfismy, dědění). Problém integrity je tedy posunut z jednotlivých poloh funkcionality a datového modelu do polohy integrity objektové.
• Zde je namístě zdůraznit, že objektově orientované řešení může nabídnout i neobjektová technologie (non- object based).

Naše řešení je založeno na jednoduchém principu modelu objektové třídy s možností nasměrování na zdroj hodnot atributů objektů této třídy. Totéž se týká funkční výbavy, tzn. metod (pokud je kooperující aplikační systém vůbec schopen akceptovat vzdálené volání). Obecně vzato může být každá třída nasměrovaná na zdroj v jiném systému než ostatní třídy. Samozřejmě, že náš systém disponuje svým vlastním vysoce abstraktním modelem a může tedy vést veškeré informace ve své vlastní (nativní) databázi. Zdroj hodnot třídy se však může průběžně přesměrovávat z jednoho na jiný s patřičnou úpravou modelu popisující externí model. To vše samozřejmě bez jakýchkoli programátorských zásahů. Pro úplnost MODEL je další z meta-tříd meta-modelu.

Pro vlastní implementaci objektové integrity disponuje náš systém třemi integritními modely – objekty meta-třídy INTEGRITY

• interní
• přímý
• nepřímý

Interní integritní model je uplatňován v rámci nativního modelu. Přímý integritní model zajišťuje velmi těsnou vazbu na kooperující model, vyžaduje však určitý standardní zásah do tohoto modelu. Nepřímý model je volnější, je realizován zprostředkovaným odkazem, a nevyžaduje zásah do externího modelu.

Ve výhledu je ještě zvažován externí model zachycující v podstatě nativní strukturu externího modelu bez objektové reprezentace.

3. Provozní platformy

První verze systému byla řešena jako extension k ArcView (ESRI). Tato volba byla určena následujícími cíli

• nabídnout tento produkt co nejrychleji na trh s tím, že musí disponovat plnou funkcionalitou práce s grafickou informací v rozsahu, který je nabízen v prostředí ArcView.
• umožnit přístup k rozšířené funkcionalitě prostředí pomocí extensions třetích stran v rámci jednoho integrovaného celku
• nabídnout multiplatformní řešení (Unix, Windows).

Z tohoto pohledu se jeví paradoxním, že systém umí pracovat v režimu bez použití grafické informace. To je ale dáno tím, že není principiálně řešen jako extension ArcView jak bude dále ještě vysvětleno.

Technicky jediným požadavkem na platformu datové složky ze strany našeho systému je vedení veškerých dat v databázi vyhovující normě ANSI SQL a rozhraní ODBC/JDBC (tzn. databáze typu Oracle, Informix, Sybase, MS SQL Server, …, MS Access). Samozřejmě při konkrétní implementaci je nutno přihlížet k výkonnostním parametrům jednotlivých produktů.

V současné době se již pracuje na druhé verzi systému, která je řešena pro inter/intranet (Java). Tato verze zahajuje další etapu jejíž cílem je

• dostupnost aplikací co nejširšímu okruhu uživatelů za provozně minimálně náročných podmínek,
• nezávislost na platformách podporujících práci s grafickou informací
• nezávislost na OS platformách