|obsah| |index autorů | | index názvů | | index témat | | archiv |
Knihovna plus
2009, číslo 1
David Konopáč
Tento text vznikl zkrácením mé absolventské práce na Vyšší odborné škole informačních služeb (VOŠIS) na téma "Využití nástroje WebRatio k návrhu webové aplikace".
Během své odborné praxe v rámci studia na VOŠIS jsem pracoval v Knihovně společenských věd T. G. Masaryka, která se nachází v areálu Univerzity Karlovy v Praze – Jinonicích. Při této praxi jsem se setkal se systémem evidence těchto prací přístupným pomocí webové aplikace.
Ve své absolventské práci jsem se pokusil zjistit, zda by podobný systém pro správu knihovnické databáze bylo možné vytvořit pomocí nástroje WebRatio, do jaké míry je tento nástroj pro úkol vhodný, v čem jsou jeho přednosti a jaké jsou jeho slabiny.
Web Modeling Language (WebML) je metodologie pro vytváření webových aplikací (jinými slovy dynamických webových stránek) – od jejich návrhu, přes testování až po údržbu. Metodologie obsahuje vlastní grafický jazyk a pro textové vyjádření používá jazyk XML.
WebML je teoretický model, zatímco WebRatio je jeho praktická implementace (v současné době jediná, která existuje). WebRatio obsahuje editor modelů WebML a generátor webových aplikací, které vytváří na jejich základě. Tvůrce webové aplikace tedy nejprve pomocí CASE nástrojů WebRatia vytvoří modely WebML a poté z nich nechá vygenerovat webovou aplikaci.
Modely metodologie WebML
WebML zahrnuje následující čtyři modely: Datový model, Hypertextový model, Prezentační model a Uživatelský model. V tomto článku se budu zabývat pouze prvními dvěma. Popíšu je velmi stručně, více informací je možné získat v níže uvedených zdrojích – viz literatura [1], [2] a [3].
Příklad datového modelu vytvořeného CASE nástrojem je vidět na obrázku 1, na obrázcích 2 a 3 jsou vidět modely hypertextové.
Datový model
Datový model používaný v jazyce WebML je podobný modelu používanému při tvorbě ERA diagramů – také zde je datový model tvořen množinou entit provázaných mezi sebou relacemi (viz např. obrázek 1).
Budu dále předpokládat, že čtenář je seznámen s termíny entita, instance entity, atribut entity, relace, role relace, kardinalita relace.
Hypertextový model
Hypertextový model zahrnuje dva modely – kompoziční a navigační. Oba modely však spolu úzce souvisí: v kompozičním modelu navrhujeme umístění jednotlivých prvků do vypracovávaných stránek tak, aby byla zajištěna správná funkčnost celého projektu. V navigačním modelu přidáváme navigaci, tj. odkazy mezi jednotlivými stránkami či mezi prvky stránek.
Základními prvky, ze kterých je budován hypertextový model, jsou stránky, jednotky a linky. Stránka (Page) hypertextového modelu je abstraktní představa webové stránky; na rozdíl od skutečné webové stránky neřeší, jak je stránka graficky provedena a jak jsou rozmístěny její prvky.
Jednotka (Unit) v systému WebML představuje nějakou činnost. Činností může být vytvoření formuláře pro vstup dat (jednotka Entry Unit), výpis instancí jedné entity (Index Unit, Multi Data Unit), manipulace s databází (např. Modify Unit mění instanci entity) a další.
Link propojuje dvě jednotky mezi sebou, dvě stránky mezi sebou nebo jednotku se stránkou. Úkolem linku je předat řízení, data (ve WebML se jim říká parametry) nebo obojí.
V souvislosti s linkem bych rád učinil malou poznámku k terminologii. V textu používám výraz "link" pro odkaz ve smyslu jazyka WebML, a výraz "odkaz" pro odkaz ve smyslu jazyka html, tj. odkaz, na který může uživatel kliknout ve webovém prohlížeči.
Budu opět předpokládat, že čtenář zná následující pojmy metodologie WebML: operační a obsahová jednotka; normální, automatický a transportní link, KO a OK link, kontextuální a nekontextuální link; parametry, vstupní a výstupní parametry. Dále termíny používané ve WebRatiu – párování parametrů (Parameters Coupling) a procházení parametrů (Passing).
Mým úkolem bylo vytvořit webovou aplikaci, která umožní spravovat agendu vysokoškolských prací. Omezil jsem se na část, která pracovníkům knihovny poskytne rozhraní za účelem spravování databáze spojené s agendou. Vynechal jsem část, jež by zajišťovala přístup čtenářů knihovny k databázi; tato část by ovšem byla obdobná, jenom by neumožňovala modifikaci dat. Uživatelem webové aplikace bude dále v tomto textu tedy míněn vždy pracovník knihovny.
Webová aplikace se bude zabývat pouze evidencí titulů uchovávaných v knihovním fondu, nikoli evidencí jednotlivých exemplářů.
Webové rozhraní umožní zobrazovat a modifikovat seznam autorů, seznam prací a informace o jednotlivých autorech a seznam všech fakult (a jim podřízených institucí), na nichž tito studovali.
Datový model je znázorněn na obrázku výše. Obsahuje čtyři entity: AutorE, PraceE, PodinstituceE a InstituceE. Každá entita má primární klíč, na obrázku nazvaný oid.
Entita AutorE představuje soubor autorů kvalifikačních prací. Autora charakterizují dva atributy: jméno a příjmení.
Entita PraceE představuje soubor kvalifikačních prací. Práci charakterizuje název, druh práce (ta může být bakalářská, diplomová, disertační, postupová nebo rigorózní), stručná anotace a rok, kdy student práci obhájil.
Entita InstituceE představuje fakulty UK; obdobně entita Podinstituce představuje podřízené instituce k těmto fakultám (většinou institut nebo katedru, v rámci níž psali studenti své práce). Relace typu 1-N umožňuje vyjádřit hierarchický vztah mezi fakultami a jejich podřízenými institucemi.
(Ve skutečnosti jsem byl nucen výše uvedený datový model částečně upravit z důvodu, že WebRatio neumí zobrazit data ze dvou tabulek propojených relací v jednom seznamu (úpravu v tomto článku však popisovat nebudu).
Názvy entit, relací a rolí
"E" jsem do názvů entit připsal proto, aby se tyto prvky WebRatia nepletly čtenáři s jinými objekty téhož názvu (např. kromě entity AutorE existuje jednotka Autor a stránka Autor).
Následující poznámka má pomoci čtenáři, aby se lépe orientoval v dalším textu v názvech relací a rolí: relace AutorE_PraceE má role JeAutoremPráce, JeNapsánaAutorem; relace PraceE_PodinstituceE má role BylaNapsánaVPodinstituci, VyprodukovalaPráci; relace InstituceE_PodinstituceE má role MáZaPodinstituci, JePodinstitucíInstituce.
Mnou navržené webové rozhraní bude obsahovat čtyři základní, navzájem propojené webové stránky: stránku zobrazující seznam evidovaných prací (nazvu ji Díla), stránku s autory kvalifikačních prací (Autoři), stránku jednoho konkrétního autora (Autor), stránku s fakultami, na nichž autoři studovali, včetně jim podřízených institucí.
V tomto článku popíši pouze postup při vytváření stránek Autoři, Díla a Autor, a to v jejich jednodušší formě.
U stránek Autoři a Díla budu usilovat o to, aby bylo možné jednoduchým způsobem zobrazit buď seznam všech prací, resp. Autorů nebo pouze omezený seznam vyfiltrovaný zadáním části hledaného textu uživatelem, a to pomocí vyhledávacích formulářů.
Stránka Autor bude obsahovat jak informace přímo referující o jednom konkrétním autorovi kvalifikační práce, tak i o všech jeho pracích. Dostaneme se na ni buď ze stránky Autoři (kliknutím na daného autora) nebo ze stránky Díla (kliknutím na titul, který příslušný autor napsal). Se stránkou Autor budou propojeny pomocné stránky pro zobrazení anotací, pro úpravu práce a pro přidání nové práce.
Kromě zobrazování informací budou stránky zajišťovat i přidávání informací nových, jejich úpravu a mazání.
V dalším textu budu vysvětlovat vytváření modelu tak, jak je zobrazen na obr. 2.
Stránka Autoři
Jako Domovskou stránku aplikace jsem zvolil stránku Autoři, tedy stránku, která se bude vztahovat k seznamu autorů, a tedy k entitě AutorE. Její základní funkcí bude zobrazit seznam všech autorů; WebRatio nabízí tři způsoby, jak toto provést: jednotky Index Unit, Power Index Unit a Multi Data Unit. Všechny tři jednotky jsou schopné zobrazit seznam obsahující více instancí příslušné entity. Jednotka Multi Data Unit je z nich nejjednodušší a entitu pouze zobrazí (instance jako řádky, atributy jako sloupce). Index Unit navíc umožňuje výběr každého autora, tj. do každé řádky umístit jeden nebo více odkazů. Power Index Unit ještě k tomu přidává možnost zobrazovat názvy atributů jako odkazy: kliknutím na tento odkaz umožňuje instance seřadit podle vybraného atributu.
Jednotku Multi Data Unit jsem tedy musel vyloučit, protože by uživatel nemohl volit jednotlivé autory a zobrazovat jejich detaily na stránce Autor. Zvolil jsem jednotku Power Index Unit, protože možnost třídění podle atributů je užitečná. Nazval jsem ji SeznamAutorů, určil jsem, že bude zobrazovat entitu AutorE (pomocí vlastnosti Entity), pomocí vlastnosti Display Attributes jsem určil, že bude zobrazovat atributy jmeno, prijmeni a oid (oid jsem nechával zobrazovat vždy, když to bylo možné: jednak kvůli ladění, dalším důvodem je, že čtenář tohoto článku tak lépe pochopí některé z obrázků), a že se podle obou atributů bude moci třídit (vlastnost Default Sort Attributes).
Dále jsem potřeboval, aby bylo možné do entity AutorE přidávat autory. Toto zajišťuje operační jednotka Create Unit; je však třeba k ní linkem dopravit příslušná data, tedy jméno a příjmení. Pro vkládání dat má WebRatio připravenu jednotku Entry Unit, která představuje formulář a je možné do ní vkládat textová pole a vysouvací seznamy: vytvořil jsem proto Entry Unit s názvem NovýAutor a vložil jsem dvě textová pole (Field) pro jméno a příjmení autora. Mimo stránku Autor jsem vložil Create Unit s názvem VytvořeníAutora a poslal do ní jméno i příjmení normálním linkem – Normálním linkem proto, že je třeba, aby uživatel mohl kliknutím potvrdit vložené jméno a příjmení. KO link vrací uživatele zpět na stránku Chyba, OK link na stránku Autoři.
Stránka Autor
Další navrhovanou stránkou je stránka Autor, která se bude vztahovat k vybranému autorovi. Nejdříve jsem potřeboval zobrazit jméno a příjmení vybraného autora. Zde jsem měl na výběr mezi dvěma možnostmi: vložit do této stránky jednotku Data Unit nebo jednotku Index Unit.
Nakonec jsem se rozhodl pro jednotku Data Unit, neboť mi v tomto
případě připadala vhodnější: zobrazuje atributy (v našem případě jméno a
příjmení) nad sebou. Pod nimi umožňuje zobrazit vedle sebe všechny
potřebné odkazy.
Druhá zmíněná jednotka – jednotka Index Unit – mi připadala méně vhodná
z toho důvodu, že umísťuje jak jméno a příjmení, tak i všechny odkazy
vztahující se ke konkrétnímu autorovi na jednu řádku vedle sebe. Je to
kvůli účelu za nímž tato jednotka vznikla – vznikla pro přehledný soupis
všech instancí jedné entity v jednom seznamu. Pro náš účel jsou však
zobrazované informace zbytečně nahuštěné.
Jednotku jsem nazval Autor, určil jako její entitu AutorE a určil, že bude zobrazovat atributy jmeno a prijmeni.
V minulém odstavci jsem mluvil o "vybraném autorovi". Zatím jsem však neřekl, jakým způsobem bude výběr zajištěn. K tomu je potřeba vést normální link z jednotky SeznamAutorů na stránce Autoři do jednotky Autor na stránce Autor a transportovat jím oid autora, na kterého uživatel kliknul. Vzhledem k tomu, že SeznamAutorů je jednotka typu Power Index Unit, zobrazí se ve webovém prohlížeči uživateli odkaz na každém řádku seznamu.
Na stránce Autor by uživatel měl být schopen změnit jméno a příjmení autora. To jsem zajistil tak, že jsem do stránky Autor vložil Entry Unit se dvěma textovými poli jméno a příjmení, kterou jsem nazval ÚpravaAutora (způsob použití Entry Unit je popsán dříve v této kapitole). Na rozdíl od minulé situace však chceme do formuláře předem dopravit stávající jméno a příjmení, které chce uživatel upravovat. K tomu, abychom mohli linkem poslat do Entry Unit parametry, musíme u obou jejích polí zaškrtnout vlastnost Preloaded. Při zobrazení jednotky na stránce budou tyto parametry zobrazeny jako úvodní hodnota, a proto je uživatel může pohodlně upravit.
Upravení instance v databázi umožňuje jednotka Modify Unit, to samotná Entry Unit neumí – nemá žádný vztah k databázi: jednotku Modify Unit jsem vložil, pojmenoval ji ZměnaAutora, ve vlastnostech určil její entitu AutorE a poslal jí normálním linkem uživatelem upravené jméno a příjmení jako parametry. K přepsání záznamu v databázi však samotné parametry jméno a příjmení nestačí, protože Modify Unit neví, ke které instanci v entitě AutorE tyto parametry patří; to zajistí až transportní link, který přináší parametr oid z jednotky Autor. OK link vrací uživatele zpět na stránku Autor, KO link na stránku Chyba.
Nyní model odpovídá obr. 2, v dalším textu jej rozšířím do stavu na obr. 3.
Dalším mým požadavkem na stránku Autor bylo, aby zobrazila seznam
všech prací autora, k němuž se stránka vztahuje. K tomu jsem vybral
Index Unit; řazení podle atributů (což umí jednotka Power Index Unit)
jsem zde nepotřeboval, neboť málokterý autor napsal více než dvě práce.
Jednotku jsem nazval SeznamJehoPrací, přiřadil jí entitu PraceE, nechal
jsem zobrazit atributy oid, nazev, druh, rok a anotace, a vybral jsem
řazení podle atributu rok, protože mi tento výběr připadal nejvhodnější.
Tato jednotka ke svému správnému chodu potřebuje poslat jako vstupní
parametr atribut oid autora; jak a kde ho získá, bude popsáno níže.
Selektor
Selektor (v originále Selector) zajišťuje výběr některých instancí z populace dané entity (v databázové terminologii zajišťuje výběr záznamů, tj. řádků tabulky). Selektor je tvořen jednou nebo více podmínkami. Selektor podmínky vyhodnotí a vybere vyhovující instance.
Každá podmínka očekává vstupní parametr. Například podmínce, která má vybrat všechny autory s daným příjmením, musíme příjmení zaslat jako vstupní parametr.
Můžeme použít tři typy podmínek: podmínku klíče (Key Condition), atributovou podmínku (Attributes Condition) a relační podmínku (Relationship Role Condition). Co jednotlivé typy znamenají?
Podmínka klíče stanoví podmínku pro oid. Například podmínka "oid=?" (otazník odpovídá vstupnímu parametru), vybere ty instance, jejichž oid se rovná zaslanému parametru.
Atributová podmínka vybere ty instance, pro které platí, že zaslaný atribut splňuje danou podmínku. Například podmínka "název Begins With ?" vybere ty instance, jejichž název práce začíná zadaným slovem nebo souslovím.
Relační podmínka vybere jen ty instance entity, které jsou v relaci k instanci jiné entity. Například podmínka "AutorEToPraceE", vybere ty instance, které jsou spojeny relací AutorE_PraceE s tou instancí entity PraceE, jejíž oid bylo podmínce zasláno jako vstupní parametr.
Použití selektoru v jednotce SeznamJehoPrací
Abychom mohli v jednotce SeznamJehoPrací zobrazit práce konkrétního autora, na něhož jsme klikli v jednotce SeznamAutorů (na stránce Autoři), potřebujeme použít selektor: selektor má vybrat práce, které byly napsány daným autorem; jinými slovy má platit, že autor je s vybranými pracemi v relaci JeAutoremPráce: použijeme tedy relační podmínku s relační rolí JeAutoremPráce.
Tomuto selektoru potřebujeme dodat oid autora, na kterého jsme klikli v jednotce SeznamAutorů. Problém je v tom, že totéž oid však potřebujeme z jednotky SeznamAutorů poslat i jednotce Autor, a normální link nemůže vést na dvě místa současně.
Selector Unit RozesíláníOidAutora
Z tohoto důvodu do stránky Autor vložíme Selector Unit RozesláníOidAutora, který oid ze stránky Autoři přijme a bude jej dále rozesílat na všechna potřebná místa.
Selector unit je jednotka, která je tvořena pouze selektorem. V praxi to znamená, že umí vybrat instance entity a poslat je dál (přesněji poslat dál jednotlivé atributy vybraných instancí) jako parametry. V případě jednotky RozesláníOidAutora však k žádnému výběru nedochází, do jednotky vstoupí oid autora, které není nijak zpracováváno a je pouze rozesíláno dále transportními linky.
Vložení nové práce
Nyní potřebujeme, aby stránka Autor umožňovala vložení nové práce autora, k němuž se tato stránka vztahuje. Postup je zpočátku obdobný, jako byl při vkládání nového autora na stránce Autoři pomocí jednotek NovýAutor a VytvořeníAutora: i zde vložíme jednotku Entry Unit (zde se bude jmenovat NováPráce) a Create Unit (bude se jmenovat PřidáníPráce), spojíme je normálním linkem, do jednotky NováPráce vložíme textová pole (pole druh, název a rok budou typu string, zatímco pole anotace bude typu text: typy polí tak budou odpovídat typům příslušných atributů entity PraceE), určíme, že jednotka PřidáníPráce bude pracovat s entitou PraceE, přidáme OK link a KO link.
To však ještě k úspěšnému přidání práce na stránku Autor nestačí; každá práce má konkrétního autora, a proto jednotka PřidáníPráce potřebuje dostat oid autora. Zašleme jej transportním linkem z jednotky Autor.
Dalším požadavkem (viz kap. 3.3) bylo vytvoření stránky díla, která bude zobrazovat seznam obsahující všechny VŠ kvalifikační práce všech jejích autorů. Stránka bude podobná jako stránka Autoři, ale bez možnosti vkládání nových děl (ta se vkládají přes stránku Autor) . Z obdobných důvodů jako u stránky Autoři jsem pro výpis seznamu prací použil Power Index Unit, nazval ji SeznamPrací, určil její entitu – PraceE a nechal zobrazit atributy nazev, druh, rok, anotace a vybral možnost řazení podle všech atributů kromě anotace.
Zjištění autora práce
Nyní bych chtěl umožnit kliknutím ze stránky Díla, přesněji z odkazu u jedné položky seznamu, se dostat na stránku vybraného konkrétního autora, obdobně, jako tomu je ze stránky Autoři. U stránky Autoři jsem situaci vyřešil tím, že jsem do jednotky RozesíláníOidAutora zaslal oid autora. Na stránce Díla však oid autora jako výstupní parametr k dispozici není, místo něj máme oid vybrané práce. V datovém modelu však můžeme z oid práce zjistit oid jejího autora pomocí relační role JeNapsánaAutorem, v hypertextovém modelu nám to zajistí selektor s relační podmínkou.
Na stránku Autor jsem proto přidal jednotku Selector Unit, která ze vstupního parametru oid práce zjistí výstupní parametr oid autora. Nazval jsem ji ZjištěníAutoraPráce a určil jako její entitu AutorE. Do ní jsem vložil selektor s relační podmínkou definovanou rolí JeNapsánaAutorem. Tak jsem zajistil, aby jednotka ZjištěníAutoraPráce byla schopna odeslat oid autora do jednotky RozesíláníOidAutora, jejíž funkce je popsána v předešlých odstavcích.
Nyní je model podle obrázku 3 hotov, podívejme se, jak aplikace funguje. Následující obrázek zobrazuje úvodní stránku aplikace (Autoři):
Pokud uživatel klikne na odkaz detaily u Davida Čtvrtníka, zobrazí se následující stránka:
Stránka Díla vypadá podobně jako stránka Autoři, neobsahuje však žádný formulář pro přidání nového díla.
V tomto okamžiku se objevil zásadní problém: stránka Autor se zobrazovala správně, pokud jsem se na ni dostal ze stránky Autoři, avšak pokud jsem se na ni dostal ze stránky Díla, zobrazila se bez obsahu (v dalším textu budu tento problém nazývat "Problém s karambolem").
Začal jsem zkoumat, v čem je chyba. Zaměřme se nyní na následující obrázek :
Transportní linky "Link2" a "Link2a" přenášejí oid autora a jediný důvod, proč se jednotky Autor a SeznamJehoPrací nezobrazily, může být ten, že oid autora neobdržely. Pro zjednodušení budu v dalších úvahách uvažovat pouze jednotku Autor (úvahy o jednotce SeznamJehoPrací by proběhly úplně stejně).
Přemýšlejme, co se stane, klikneme-li na odkaz "detaily autora". Normální link "detaily autora" pošle oid práce, na které bylo kliknuto, jednotce ZjištěníAutoraPráce. Jednotka ZjištěníAutoraPráce zjistí, který autor práci napsal a pošle linkem "Link1" oid autora jednotce RozesíláníOidAutora. Ta by měla linkem "Link2" předat oid autora jednotce Autor. To se však zřejmě nestane a jednotka Autor se nezobrazí.
Jedinou překážkou na cestě od jednotky SeznamPrací k jednotce Autor může být link "detaily", který přichází z jednotky SeznamAutorů. Do jednotky RozesíláníOidAutora tak vstupují dva linky, oba přinášejí oid autora jako parametr. Pouze "Link1" přináší skutečný parametr, link "detaily" přináší parametr prázdný (na SeznamAutorů nebylo kliknuto), přesto zřejmě dochází k tomu, že jednotka RozesíláníOidAutora si vybere prázdný parametr a pak nemá, co by poslala jednotce Autor.
Proč ale při vstupu do jednotky RozesíláníOidAutora dostal přednost prázdný parametr na úkor skutečného parametru přicházejícího linkem "Link1"? Vše zprvu nasvědčovalo tomu, že normální link má přednost před linkem transportním. (Takové chování WebRatia mi připadalo nedomyšlené: je nesmyslné, aby link "detaily" hrál aktivní úlohu při sestavování stránky, jestliže na něj vůbec nebylo kliknuto.)
Skutečná funkce normálního linku
Nakonec se však ukázalo, že věci se mají jinak: zjistil jsem, že intuitivní a přirozená představa, že normální link vždy předává cílové jednotce parametry a řízení, je mylná. Toto platí pouze, pokud cílová jednotka patří do kategorie Operation Unit. Je-li však cílová jednotka z kategorie Content Unit, předává každý normální link cílové jednotce pouze parametry (zastává tedy funkci transportního linku), avšak řízení předává stránce, ve které se cílová jednotka nachází (zastává tedy funkci nekontextuálního linku). Stránka pak může zahájit výpočet svého obsahu předáním řízení úplně jiné jednotce, než do které normální link vstoupil.
Popišme si situaci na našem konkrétním příkladě: do stránky Autor vedou tři normální linky: link "upravit" je vnitřní (vede ze stránky do stejné stránky), linky "detaily autora" a "detaily" vedou z cizích stránek. Jaká je jejich skutečná funkce názorně zobrazuje obr. 7. Například link "detaily autora" nejprve pošle oid díla jednotce ZjištěníAutoraPráce, potom jí však nepředá řízení, nýbrž ho předá stránce jako celku. A takto se chovají všechny tři linky: nejprve předají parametry cílové jednotce, pak předají řízení stránce Autor.
(Oproti tomu link "přidat práci", který směřuje do jednotky kategorie Operation Unit, se chová tak, jak od něj intuitivně očekáváme a předává cílové jednotce parametry i řízení.)
Výchozí sekvence
Jak jsem přišel na to, že normální linky fungují dle obrázku 7? Pro WebRatio je totiž jedno, jakým způsobem a kam se na stránku dostaneme: ať link vstupuje do určité jednotky (normálním linkem) nebo přichází na stránku jako celek (OK linkem nebo nekontextuálním linkem), stránka vždy bude vypočtena jednotným způsobem: pro každou stránku je WebRatiem vytvořena tzv. Výchozí sekvence (v originále Default Sequence), která určuje způsob předávání řízení na stránce a tedy její výpočet. Sekvence definuje pořadí, v jakém transportní linky uvnitř stránky předávají parametry mezi jednotkami. Toto pořadí určuje WebRatio při generování projektu podle vlastního algoritmu, který bohužel není publikován ani v helpu WebRatia ani na webových stránkách www.webratio.com.
Pravidla pro předávání řízení
Výchozí sekvence sama o sobě nevysvětluje, v jakém pořadí získávají jednotky řízení (a proč vlastně došlo k problému s karambolem). Pravidla, která určují, jakým způsobem je na základě Výchozí sekvence předáváno řízení mezi jednotkami, se mi podařilo objevit teprve po delším bádání, částečně pomocí literatury [4], částečně pomocí metody reverzního inženýrství.
Teprve na základě těchto vědomostí jsem mohl zjistit, proč došlo k problému na stránce Autor: ukázalo se, že nejde o "karambol" dvou linků vcházejících do jednotky RozesíláníOidAutora, ale o to, že WebRatio vytvořilo Výchozí sekvenci pro stránku Autor nepřirozeným způsobem, jinými slovy tak, že Výchozí sekvence nezačíná linkem Link1 (viz obr. 6). Toto způsobilo, že řízení mezi jednotkami na této stránce je předáváno nesprávným způsobem. (Související úvahy jsou detailněji rozebrány v mé absolventské práci.)
Řešení Problému s karambolem
Naštěstí WebRatio obsahuje nástroje, které umožňují Problém s karambolem vyřešit: pro každou stránku projektu je totiž možné vytvářet vlastní sekvence linků a pro každý link, který vstupuje do stránky (v našem případě to jsou "detaily autora", "detaily", "upravit", "OKLink1" a "OKLink2" – viz obr. 6), je možné určit, jaká sekvence má být provedena místo Výchozí sekvence.
Pro případ přístupu na stránku Autor pomocí linku "detaily autora" jsem Výchozí sekvenci nahradil vlastní sekvencí, která začíná linkem Link1. Tím se mi podařilo WebRatio přimět, aby webová aplikace zobrazovala stránku Autor správně.
CASE nástroj
S CASE nástrojem se pracuje velmi příjemně. Objekty jsou zobrazeny přehledně a názorně, manipulace s nimi je rychlá a intuitivní.
Následovat bude už jenom popis nedostatků WebRatia, přesto má moje pochvala v minulém odstavci velkou váhu a vyvažuje dále uváděné problémy.
Nepředvídatelnost chování webové aplikace
Zásadním problémem hypertextového modelu je nepředvídatelnost chování webové aplikace: v některých situacích lze těžko na základě modelu usuzovat, jak bude vygenerovaná aplikace fungovat.
Nepředvídatelnost chování aplikace se projevuje mimo jiné tím, že po uživatelově kliknutí na odkaz (tj. po aktivování normálního linku) není jasné, kdy jednotky své parametry nebo hodnoty v polích uchovávají a kdy nikoli, a příslušná pravidla jsou komplikovaná a navíc nejsou nikde dokumentovaná.
Chování aplikace se špatně předvídá i proto, že v některých případech při běhu aplikace probíhá předávání řízení mezi jednotkami zcela jinak, než jak naznačuje hypertextový model. Tyto problémy jsou detailně popsány v kapitole 3.3.5.
Dokumentace
Na nedostatečnou dokumentaci uživatel narazí nejenom v situacích popsaných v minulých odstavcích. V zásadě lze říci, že help WebRatia je velmi podrobný, ale pouze v popisném smyslu: help podrobně vysvětluje jednotlivé prvky WebRatia a jak se s nimi pracuje, avšak někdy zapomíná vysvětlovat jejich principy.
Pomocí nástroje WebRatio se mi podařilo vyrobit jednoduchou, ale plně funkční webovou aplikaci pro evidenci vysokoškolských prací, a splňující požadavky, které jsem si předem stanovil. Stránky mají primitivní vzhled, avšak s tím jsem počítal od začátku, nezabýval jsem se totiž prezentačním modelem, pomocí kterého je možné ve WebRatiu vzhled řídit.
Co se týká vhodnosti použití WebRatia pro tvorbu aplikací podobného typu, je třeba rozlišit, kdo bude s WebRatiem pracovat:
Běžný uživatel, který neovládá programovací jazyk Java a s WebRatiem pracuje poprvé, ocení velmi příjemný a názorný CASE nástroj – ve většině ohledů intuitivní. Narazí na některé dětské nemoci WebRatia, které jsou však relativně snadno překonatelné a nakonec může mít radost z toho, že poměrně snadno vytvořil aplikaci založenou na Javě, ačkoli Javu neumí. Může však mít smůlu a dostat se do situace, kdy se WebRatio vůbec nebude chovat intuitivně, on bude muset pracovat metodou pokus–omyl, bude si stěžovat na nedostatečnou dokumentaci a bude muset věnovat spoustu energie na proniknutí do tajů systému.
Z hlediska zkušeného uživatele WebRatia, který zná nedostatky WebRatia a ví, jak jim čelit, dokáže z modelu určit, jak se bude výsledná aplikace chovat, je práce s WebRatiem velmi rychlá a efektivní. Přesto bude někdy litovat, že neovládá Javu a nemůže si vytvářet vlastní jednotky na míru (například v situaci, kdy potřebuje zobrazit dvě entity propojené relací v jediné tabulce).
Pro programátora, který ovládá webové technologie zabudované ve WebRatiu (Java, Ajax), padají všechna omezení WebRatia a může využít jeho potenciál naplno. Otázka je, zda WebRatio pro něj bude znamenat opravdový přínos a zda nebude litovat energie, kterou musel vynaložit na pronikání do tajů WebRatia.
Literatura
[1]ZELENKA, Petr. WebML – Web Modeling Language [série www dokumentů]. Interval.cz [online]. 2003-2005 [cit. 8.10.2008]. Dostupný z WWW: <http://interval.cz/serialy/webml-web-modeling-language/>. ISSN 1212-8651.
[2] MOLHANEC, Martin. WebML – Objektově orientovaná metodologie pro tvorbu webových sídel. In Objekty 2003. Ostrava : Technická universita Ostrava - Vysoká škola báňská, 2003, s. 32-43. ISBN 80-248-0274-0. [Dokument ve formátu PDF] dostupný též z WWW: <http://objekty.pef.czu.cz/2003/sbornik/Molhanec2003.pdf>.
[3] Webml.org : Web modeling language [web site]. Milano :
Politecnico di Milano, Dipartimento di Elettronica e Informazione, 2006,
aktualizace 14.7.2006 [cit. 8.10.2008].
Dostupný z WWW: <http://www.webml.org/webml/page1.do>.
[4]CERI, Stefano. Designing Data-Intensive Web Applications
[Návrhy datově náročných webových aplikací]. San Francisco : Morgan
Kaufmann Publishers, 2003. 562 s.
ISBN 1-55860-843-5.
[5] KONOPÁČ, David. Využití nástroje WebRatio k návrhu webové prezentace. Absolventská práce. Praha, 2009. 40 s., příl : obr., + 1 CD. Vyšší odborná škola informačních služeb. Vedoucí práce Helena Kučerová.
CITACE:
Konopáč, David. Využití nástroje WebRatio k návrhu webové aplikace.
Knihovna plus [online]. 2009, č. 1 . Dostupný z WWW: <http://knihovna.nkp.cz/knihovnaplus91/konopac.htm>.
ISSN 1801-5948.
| nahoru | |obsah| | archiv | | domů |
| index autorů | | index názvů | | index témat |