Kolaborativní aplikace

Transkript

1 Kolaborativní aplikace Michal Máčel Vema, a. s. Okružní 3a, Brno - Lesná, macel@vema.cz Tomáš Hruška Fakulta informačních technologií Vysokého učení technického v Brně, Ústav informačních systémů, Božetěchova 2, Brno Královo Pole hruska@fit.vutbr.cz Klíčová slova: univerzální model aplikačního prostředí, technologie IS, aplikační jazyk Abstrakt: V tomto článku je diskutován datový model pokrývající dostupnou škálu aplikačních prostředí. Je založen na grafovém modelu z využitím základních koncepcí kompozice a agregace. K tomuto modelu je navrženo aplikační rozhraní a navržen jazyk pro přímý vývoj kolaborativních aplikací nad navrženým modelem. 1. Koncepce technologické platformy pro kolaborativní aplikace V průběhu svého vývoje za posledních 15 let používala firma Vema, a.s. pro realizaci svých produktů v oblasti informačních systémů značnou škálu technologií. V databázové technologii prošla od síťového modelu přes relační až k nynějšímu objektově orientovanému přístupu. Současně s tím se měnilo okolí systémů od striktně souborového přístupu k současným webovým sémantickým sítím směřujícím většinou k technologii jazyka XML a jeho prostředí. Starší technologie u zákazníků dosud přežívají a jsou stále nezanedbatelným obchodním artiklem a novější jsou průběžně zařazovány do používaného prostředí. Pro všechny použité technologie jsou vyvíjeny aplikace, které psány v rozdílných vývojových systémech a používající různé modely svou různorodostí neúnosně rozšiřují množství prostředí, které je nutné zvládnout. Je proto jednou z hlavních snah sjednotit model dat tak, aby pokud možno pokryl uvažovaná datová prostředí a následně vyvinout či použít manipulační jazyk nad takovým modelem. Základní vlastnosti technologické platformy pro uvažované kolaborativní aplikace jsou tedy následující: jednotný model pokrývající používaná prostředí pro navigaci (Internet a jeho adresovací mechanizmus, souborové systémy, relační model, objektově orientovaný model, XML, paměť procesů, případně další), zobecněná reference používaná pro navigaci v tomto modelu, rozčlenění modelu na jmenné prostory, manipulační jazyk nad modelem Přínosem popisované aktivity není momentálně ani tak vývoj nového manipulačního jazyka, jehož širší použití může být otázkou diskuze, nýbrž návrh technologické platformy a modelu, jako základu pro možný jednotný vývoj spolupracujících aplikací. 2. Používané modely a jejich zhodnocení Předmětem modelů, jimiž se zabýváme, jsou různě strukturovaná data. V [1] jsou uvedeny dva základní principy vytváření strukturovaných dat: kompoziční (pevný počet obecně různých součástí), SYSTEMS INTEGRATION

2 MICHAL MÁČEL, TOMÁŠ HRUŠKA agregační (předem neomezený počet vesměs stejných součástí). [1] (často též záznam, rekord, jmenný prostor) je obvyklá struktura v různých systémech a programovacích jazycích, protože modeluje běžné objekty denního života. Např. pes je kompozicí hlavy, těla, ocasu a noh nebo je kompozicí záhlaví a textu a záhlaví je kompozicí jména odesílatele, příjemce atd. Vzhledem k tomu, že počet součástí je předem omezen, mohou být snadno pojmenovány nejčastěji identifikátory. Agregace (kolekce, soubor, seznam, uspořádaná množina) je rovněž velmi frekventovanou strukturou. Město je agregací domů, les agregací stromů apod. Vzhledem k tomu, že agregace neurčuje předem budoucí počet součástí, nelze je předem pojmenovat. K adresování se používá mapování na množinu celých čísel, která je rovněž neomezená (indexování). Obvyklou otázkou je omezení či neomezení hloubky zanoření struktur a základní typy ukončující hierarchii struktur. Nejde samozřejmě o to, zda a jaký typ je povolen jako celočíselný, ale o to, je-li základním typem rovněž program, který může být v rámci aplikace vytvářen i spouštěn. Tato otázka vyvstává zejména v současnosti, kdy se stále více prosazují jazyky interpretované. Pokusme se nyní podívat na vybrané (a dle našeho názoru nejčastěji používané) datové modely z hlediska předchozího odstavce. 2.1 Relační databázový model Relační databázový model je složen z relací (tabulek). Každá z n-árních relací je vlastně agregátem kompozic, tj. každý řádek relační tabulky tvoří záznam a tabulka je kolekcí předem neomezeného počtu řádků. Mimochodem princip agregátu kompozic je jedním z nejčastěji užívaných v datovém modelování. V relačním modelu je obvykle omezena hloubka hierarchie a relace nelze do sebe zanořovat. Rovněž použití programu jako základního datového typu je řídké a aplikace stojí vesměs mimo datový model. V původním relačním modelu neexistovaly datově vyjádřené vztahy. Ty byly realizovány až v rámci dotazů. Neexistovala totiž standardní identifikace řádku relace. 2.2 Objektově orientovaný model Objektem v objektově orientovaném modelu bývá kompozice. V ní jsou jako datové typy povoleny jak typy základní, tak agregace. Tím je oddělen koncept agregace a kompozice do separátních typů. Hloubka zanoření struktur není omezena. Použití programu jako možného základního typu je v objektových modelech základním principem. Je ovšem otázkou, zda použitý manipulační jazyk umožňuje programy dosazovat a přímo provádět. U modernějších skriptovacích jazyků to možné je. Vzhledem k tomu, že každý objekt v tomto modelu unikátně identifikován, je možné datově vytvářet vztahy mezi objekty. Model je potom vlastně grafem, jehož uzly jsou objekty-kompozice a vztahy (reference) jsou orientované hrany tohoto grafu. Na rozdíl od relačního modelu, kde je základním přístupovým mechanizmem dotaz, dovoluje existence vztahů navigaci v objektovém modelu i tímto způsobem. 2.3 XML a Internet Internet a jeho webovské služby jsou v současnosti jedním z klíčových zdrojů dat. Vzhledem k jejich prvotnímu určení pro zveřejňování byť hypertextových dokumentů, je jejich použití jako primarního zdroje dat diskutabilní. Datový model tvoří orintovaný graf, kde na úrovni uzlů nelze hovořit ani o kompozici, ani agregaci, neboť jde o text proložený formátovacími značkami. Naopak mechanizmus univerzálního adresování URL tvoří velmi dobrý prostor pro realizaci vztahů. Nedostatek strukturovanosti dat v uzlech (semistrukturovaná data) je řešen dodatečnými prostředky, jako jsou různé analyzátory používající metod překladačů pro vydolování datových zdrojů z textu. Technologie XML [3] tento problém řeší. Její model umožňuje vytvářet kompozice pojmenovaných položek. Neomezená možnost opakování kompozic dovoluje vytvářet také agregáty. Vzhledem k historickému vývoji XML z původního SGML a tedy také HTML se v XML zachovaly některé rysy, které jeho čistotu mírně ruší. Jednak je to možnost, aby součástí kompozice byly úseky textu, které nejsou pojmenované a neomezená možnost opakování a stídání se různě pojmenovaných položek. Na 430 SYSTEMS INTEGRATION 2003

3 KOLABORATIVNÍ APLIKACE druhém místě bych jmenoval duální koncepci elementů a atributů, která umožňuje návrhářům používat pro modelování těchže objektů různé prvky modelu. <kompozice> Nepojmenovaný text <agregace1>alfa</agregace1> <agregace1>beta</agregace1> <agregace1>gama</agregace1> a další kousek nepojmenovaného textu <agragace2>zelená</agregace2> <agregace1>delta</agregace1> <prvek1>auto</prvek1> a ještě kousek textu <agregace2>modrá</agregace2> </kompozice> XML je tedy grafovým modelem s možností vytváření vztahů. Umožňuje modelovat jak čisté kompozice, tak agregace. Jeho značná liberálnost však dovoluje vytvářet i kombinované struktury s obtížnou adresací. To lze ostatně zjistit při podrobnějším studiu jak modelu XML struktur DOM, tak při popisu sémantiky dotazovacího jazyka XPATH 2.4 Souborové systémy Jako poslední prostředí, jež budeme při návrhu na šeho modelu využívat jsou souborové systémy. Zde je situace poměrně jednoduchá. Souborové systémy tvoří téměř výhradně hierarchicky neomezenou vnořenou strukturu kompozic, zde nazývané obvykle adresáře. 3. Model prostředí pro vytváření aplikací Navrhovaný model si klade za cíl sjednotit aplikačně prostředí uvedená v kapitole 2 a poskytnout technologii pro jednotný zápis aplikací pro všechna tato prostředí. Co se týká XML, byl model omezen tak, že: jméno položky je v rámci kompozice jedinečné,, vyskytuje-li se v kompozici více položek stejného jména, jde o agregaci. Za těchto omezení musí syntakticky model vyjádřit v XML a naopak takto omezeno XML hodnotu lze aplikačně pokrýt navrhovaným modelem. <kompozice> <agregace1>alfa</agregace1> <agregace1>beta</agregace1> <agregace1>gama</agregace1> <agregace1>delta</agregace1> <agregace2>zelená</agregace2> <agregace2>modrá</agregace2> <prvek1>auto</prvek1> </kompozice> Kromě těchto dvou základních uzlů obsahuje model zejména atomické datové typy, uzel referenční a uzel modelující program. SYSTEMS INTEGRATION

4 MICHAL MÁČEL, TOMÁŠ HRUŠKA Jmenný prostor Boolean Agregace Číselné typy Datum a čas String Prázdný Program Reference obr.1 Typy uzlů 3.1 Jmenné prostory Navrhovaný model je grafový. Uzly grafů jsou zobrazeny na obr. 1. Každý z uzlů je v grafu adresovatelný, což umožňuje realizovat vazby směřující k tomuto uzlu. Vazby tvoří hrany grafového modelu. Všechny typy uzlů modelu jsou odvozeny ze základního uzlu nazvaného jmenný prostor. Při navigaci v modelu je vždy jeden z uzlů aktivní. Jmenný prostor uzlu tvoří jména operací, které je možné v daném uzlu provést. Výsledkem operace je vždy uzel grafu jmenný prostor. Na obr. 1 vidíme typový strom možných uzlů modelu. Na levé straně jsou základní datové typy Boolean, časová značka, číselné typy a řetězce znaků. Operace u těchto uzlů jsou standardní (logické operace u Boolean, aritmetické u číselných typů apod.). Prázdný typ naopak nemá žádnou operaci a tudíž z něho nelze přejít na jiný jmenný prostor a průchod modelem zde vždy končí. Uzel typu Program představuje prvek modelu, v němž je uložen program, který má být vyhodnocen. Operací vyhodnocením programu vznikne opět hodnota typu jmenný prostor a v průchodu modelem je možné pokračovat. Uzel typu Reference obsahuje zobecněnou referenci určující průchod modelem. Operací uzlu je přechod přes příslušnou referenci. Vyhodnocování reference popisuje kapitola 3.2. Klíčovými typy uzlů grafu jsou uzly typu Agregace a. Uzel typu Agregace představuje předem neomezený seznam nepojmenovaných položek. Vzhledem k tomu, že agregaci chápeme jako uspořádaný seznam, jsou jeho základními operacemi přechod na n-tou položku, případně zjištění momentálního počtu položek. Uzel je následníkem uzlu agregace. Lze v něm tudíž 432 SYSTEMS INTEGRATION 2003

5 KOLABORATIVNÍ APLIKACE realizovat operace nad agregací a kromě toho základní operaci uzlu, tj. přechod na položku označenou jménem. Je jisté, že budou existovat různé systémy přístupu ke kompozicím a agregacím, vzhledem k různým pokrývaným modelů, případně i různým systémům přístupu k databázím. V tom případě bude nezbytné realizovat příslušné následníky uvedeným typů, kde budou operace implementovány podle příslušného systému. Příklad Uvažujme následující příklad. Na internetové adrese je souborový systém, kde v adresáři /databaze/relacni je v souboru zaměstnanci.db k dispozici relační databáze zaměstnanců. Zde je uživateli zpřístupněna relace obsahující jména příjmení a data narození zaměstnanců. Jeden z řádků relace obsahuje záznam o zaměstnanci Janu Novákovi narozeném na Silvestra roku 1970 v půl čtvrté odpoledne. Kromě toho existují v modelu další adresáře, databáze i řádky v tabulkách relací. Model pokrývající takto popsaný datový prostor je zobrazen na obr.2. V konkrétních uzlech je vždy uveden typ uzlu a jeho hodnota (u základních typů jde o jednoduchou hodnotu, u kompozicí a agregací jejich položky). U uzlů, které jsou součástí modelu, ale přímo nesouvisí s popsaným příkladem jsou uvedeny pouze typy uzlu bez hodnoty a kurzívou popsán komentář, co daný uzel modeluje. 3.2 Reference a navigace v modelu Referencí rozumíme posloupnost textových řetězců libovolného formátu. Interpretaci každého dílčího řetězce má na starosti správce příslušného jmenného prostoru. Ne náhodou si vybavíme velmi úspěšný model distribuované tvorby reference v Internetu a s tím spojené technologie DNS serverů. Důležitý je fakt, že obecně existuje více referencí k témuž objektu. Každá reference má podle svého charakteru různě dlouhou platnost. Kolekce referencí Svět» ČR» Firmy» IČO» , Tato-databáze» tabulka-firmy» číslo řádku XY a Proces» adresa může znamenat reference téhož objektu stejnou identitu. Liší se jen svou stabilitou. Námi navržený systém předpokládá postupný dynamický vznik alternativních referencí spolu se schopností systému vyhodnotit, která reference je nejefektivnější. Vzhledem k redundanci informací, vzniká vyšší robustnost systému. Kdykoliv není aplikovatelná určitá reference, použije se stabilnější (i když méně efektivní). Můžeme to chápat jako zobecnění principu virtuální paměti. Aplikační kód stavíme na stabilních referencích, méně stabilní reference vznikají interpretací kódu. Chceme-li vytvořit zastřešující model, musí se jednat o model jednoduchý. Proto také možnosti jeho navigace vycházejí z jednoduchých principů. Základními prostředky manipulace jsou dereference a enumerace. Dereference souvisí s referenci a jedná se o základní schopnost jmenného prostoru vyhledat prvek se zadanou identifikací. Tato vlastnost je základní a každý jmenný prostor ji musí podporovat. Druhou metodou je enumerace procházení všech prvků jmenného prostoru. Tato metoda není povinná. Např. enumerace jmenných prostorů na internetu je obtížně realizovatelná. Tím, že se musí vystačit s jednoduchými principy navigace, se může se zdát, že je to nutně musí být na úkor efektivity. V případech, kde to je odůvodněné, je možné tuto situaci vyřešit individuální implementací jmenného prostoru, která řeší implementaci základních funkcí efektivně. SYSTEMS INTEGRATION

6 MICHAL MÁČEL, TOMÁŠ HRUŠKA Reference databáze: programy: system: adresář adresář vyvoj: objektove: relacni: adresář adresář Jmenný prostor ucetnictvi.db: zaměstnanci.db:. jiná databáze záznam záznam 1: 2: 3: 4: 5: Agregace záznam záznam jmeno: prijmeni: narozeni: String Jan String Novák Datum a čas obr.2.: Příklad modelu v 15: SYSTEMS INTEGRATION 2003

7 KOLABORATIVNÍ APLIKACE Kromě manipulace na úrovni dat (DML), musí mít každý systém vztah i k manipulaci s metadaty (DDL). Naše pojetí vychází z přesvědčení, že mezi oběma světy nesmí být činěn rozdíl. Je přirozené, aby definice metadat byla nadřízena definici dat, tedy jmenný prostor metadat zahrnuje i data. Proto operace vytvoření nového objektu uvnitř jmenného prostoru nebo jeho registrace v existujícím jmenném prostoru může být spojena s modifikací obsahu objektu. Jde to zobecnění tzv. dědičnosti. V okamžiku registrace objektu ve jmenném prostoru může dojít k obohacení objektu o specifické vlastnosti. Obohacení je ve skutečnosti virtuální, tj. objekt má s ohledem na svou identitu vyjádřenou kolekcí referencí takové vlastnosti, jaké implementace jmenných prostorů nabídnou. Takto pojímaný systém je slabě typovaný. Za typovou shodu je možné požadovat pouze příslušnost ke stejnému jmennému prostoru. Na druhou stranu při kvalifikaci dílčích komponent vlastností - není nutné uvádět jejich zdroj. Proto se nevyžaduje exaktní definice dvojice rozhraní-vlastnost, jak je obvyklé. Např. stačí z objektu reprezentujícího osobu žádat jméno, bez ohledu na způsob získání. Tak se otevírá prostor pro využití nových technik jako je tzv. tlumočení, tj. implicitní dynamická konverze dat. Ta se opírá o jednorozměrný slovník pojmů s jejich kontextovými významy. 4. Aplikační jazyk Výše popsané principy jsou nezávislé na použitém implementačním prostředí. Naše základní implementace rozhraní jmenných prostorů je realizována v jazyce C++ a v tomto jazyce je možné také využívat všech možností popisovaného modelu. Významným zhodnocením a zvýšením produktivity je definice aplikačního jazyka, který zapouzdřuje výše uvedené principy a vytváří komfortní vývojové prostředí. Jde o obvyklý postup (např. Visual Basic a COM, C# a DOT.NET). I když se může zdát, že vytváření účelových aplikačních jazyků je problematické, opak je pravdou. Každá společnost, která buduje rozsáhlý aplikační systém, se opírá o svůj aplikační jazyk (např. SAP a ABAP). Pokud společnost disponuje dostatečně erudovanými kapacitami a návrh aplikačního jazyka je koncipován ve stylu univerzálních jazyků, tak je investice pro vytvoření i pro naučení aplikačního jazyka efektivní. Nevytvoříme-li si totiž svůj aplikační jazyk, budeme ho násilně vkládat do využití univerzálních programovacích jazyků. Tato cesta může být u rozsáhlejších systémů velmi strastiplná. Námi navrhovaný aplikační jazyk je koncipován jako interpretační (s přihlédnutím, aby optimalizace formou předkompilace byla možná). To zvyšuje jeho robustnost a odolnost proti změnám modelu. Jak vyplývá z předchozích úvah, nemůže se jednat o silně typovaný jazyk. Proto při jeho interpretaci dochází k dynamické volbě algoritmů. Vyplývá to ze skutečnosti, že nelze předpokládat, jaké vlastnosti bude zpracovávaný objekt v mít okamžiku interpretace. Tato skutečnost nás např. nutí začlenit do jazyka obecnější přístup k ošetření výjimečných situací (libovolná referovaná vlastnost komponenta nemusí v okamžiku interpretace existovat). Otevřenost systému si dále vyžaduje možnost pracovat nejen s daty, ale také s metadaty. Např. pokud má objekt jisté vlastnosti, lze provést určitý algoritmus, jinak se pokusíme o jiný. Renesanci také zažijí techniky typu move/copy corresponding (COBOL). Jde o případ, kdy se přiřazují navzájem dvě struktury na základě shody jmen svých vlastností. 5. Závěr Tento příspěvek popisuje základní kriteria a principy technologického prostředí pro vytváření kolaborativních aplikací vhodných pro oblast tvorby informačních systémů. Snaží se nabídnout odpověď na otázku, před kterou stojí většina tvůrců informačních systémů. Jak vyvíjet informační systémy, které musí využívat na jedné straně data ze starších i nových databázových technologií a současně být otevřené k světu internetu a jeho dynamickému vývoji. SYSTEMS INTEGRATION

8 MICHAL MÁČEL, TOMÁŠ HRUŠKA Použitá litertura [1] PAGE-JONES,M.: Základy objektově orientovaného návrhu v UML, Grada 2001, 365 str. [2] MÁČEL,M.: Aplikační programování v heterogenním prostředí, In: Sborník konference DATAKON 2002, Masarykova universita Brno 2002, str [3] BRADLEY,N.: XML kompletní průvodce, Grada 2000, 536 str. Summary This paper deals with information system modeling. In the first part, the widely used models of data are discussed and classified. In the second part, the common model of data is introduced. This model is declared to be able to cover popular models and it is introduced as a possible base for collaborative manipulation with compound data structures. The model is declared as a graph model with unified node types namespaces. In the next part, a more complex example is shown and the graph model of a non trivial-data space is described. In the next part, the concept of reference and navigation in this model is described. In the last step, the model can be used as the base of new manipulation language development. 436 SYSTEMS INTEGRATION 2003