WebML – proces vývoje webové aplikace (návrh aplikace)

18. ledna 2005

•

Po úspěšném dokončení specifikace požadavků můžeme začít s návrhem webové aplikace. WebML development process se podrobně věnuje především postupům při návrhu datové struktury a tvorbě hypertextového modelu aplikace. Tyto dva kroky budou hlavním tématem tohoto článku o metodologii WebML.

Datová struktura je základ

WebML začíná při návrhu aplikace její datovou strukturou, stejně jako velké množství ostatních metodologií. K navržení vhodné datové struktury potřebujeme mít kvalitně provedenou a ukončenou fázi sběru a analýzy požadavků a samozřejmě také určité zkušenosti s tvorbou webových aplikací. Při návrhu datové struktury můžeme být postaveni před dva zcela odlišné úkoly:

navrhnout datovou strukturu na zelené louce
postavit webovou aplikaci nad existujícím datovým zdrojem

Nedá se s určitostí říci, který z úkolů je náročnější, ale dle mých zkušeností je složitější stavět aplikaci nad již existující datovou strukturou, kterou nemáme možnost ovlivnit. Často musíme překousnout nedostatky existujícího datového modelu, při jehož vzniku vývojáři netušili, že se jednou stane nosným pro webovou aplikaci.

V podstatě se nám nabízí dva způsoby řešení této situace:

Navrhnout novou datovou strukturu a provést převod dat z existující do nově navržené datové struktury, což nemusí být triviální záležitost, zejména pokud se převod dat musí provést za chodu původní aplikace. V tomto případě získáme především možnost přizpůsobit datovou strukturu potřebám nově vznikající webové aplikace.
Postavit aplikaci na původní datové struktuře bez jakýchkoli změn, případně tuto strukturu pouze rozšířit na základě požadavků webové aplikace. Jedná se v podstatě o jediné možné řešení, pokud nad původní datovou strukturou funguje jiná aplikace a naše webová aplikace je pouze rozšířením původního systému. V tomto případě můžeme fázi datového modelování přeskočit. Samozřejmě musíme promyslet a navrhnout, jaké části z původní datové struktury bude naše aplikace využívat.

Vstupy a výstupy pro návrh datové struktury

Základním vstupem pro návrh datové struktury by se měla stát především specifikace a analýza uživatelských požadavků. Konkrétně se jedná o:

datový slovník
funkční a uživatelské požadavky
mapa budovaného webu
již existující datové zdroje

Výstupem návrhu datové struktury je datové schéma. WebML používá pro toto schéma notaci velice podobnou klasickým konceptuálním ER diagramům. Jedná se o logické datové schéma nezávislé na implementačních detailech, které je převoditelné na libovolnou relační databázi. Jakým způsobem se tvoří datové schéma dle notace WebML se dočtete v článku o datovém modelování.

Návrh datové struktury

Datový model WebML se skládá z množiny entit později nejčastěji realizovaných jako tabulka relační databáze, které jsou provázány vazbami s příslušnou násobností (kardinalitou). Při návrhu datové struktury webové aplikace rozlišuje WebML tři druhy entit (objektů):

Základní entity (core objects): Tyto entity představují hlavní datové položky zpracovávané a prezentované aplikací. Například v datové struktuře e-shopu takovou entitou nepochybně bude zboží nebo objednávka. Zdrojem pro identifikaci těchto entit je nejčastěji datový slovník vytvořený ve fázi specifikace požadavků.
Pomocné upřesňující entity: Jedná se o entity, které určitým způsobem upřesňují nebo kategorizují hlavní entity. Takovou entitou může být například v již zmiňovaném e-shopu kategorie zboží a ostatní číselníky. Nejsou to tedy entity, které vyplývají ze samé podstaty vyvíjené aplikace, ale jsou naprosto nezbytné pro správné fungovaní aplikace. Jsou identifikovány na základě popisů hlavních entit v rámci datového slovníku.
Personalizační entity: Zde se jedná o všechny entity, které souvisí s uživatelskými účty, skupinami a přístupovými právy. V e-shopu je to například entita registrovaného uživatele nebo správce obsahu a jejich role případně skupiny. Zdrojem informací pro modelování těchto entit jsou nejčastěji UseCase diagramy, kde můžeme identifikovat jednotlivé uživatele aplikace, jejich typy a do určité míry také přístupová práva.

Při návrhu datové struktury se postupuje stejně jako v jiných metodologiích od identifikace entit, přes následnou identifikaci vazeb mezi entitami, až po detailní návrh, ve kterém doplníme do jednotlivých entit jejich atributy včetně datových typů.

Doporučuje se zpočátku vytvořit dvě oddělená subschémata pro hlavní aplikační a pomocné entity a personalizační entity. V těchto subschématech identifikovat vazby a následně je propojit ve výsledné datové schéma. Teprve potom bychom měli doplňovat atributy jednotlivých entit. Při identifikaci atributů musíme vycházet ze specifikace požadavků, především z datového slovníku. Entita by neměla mít žádné atributy, pro které nemáme rozumné vysvětlení a jejichž použití nevychází ze zadání.

Velkou roli při návrhu datové struktury hraje také zkušenost vývojářů. Pro opakované problémy můžeme s úspěchem používat ověřené návrhové vzory. Například ukázek toho, jak správně namodelovat vztah mezi zbožím, zákazníkem, objednávkou a fakturou, můžeme nalézt na internetu poměrně velké množství.

Návrh hypertextového modelu

Pokud máme vytvořený datový model, můžeme začít s návrhem hypertextového modelu. Podrobnosti o syntaxi a sémantice jednotlivých diagramů, ze kterých se hypertextový model skládá, se můžete dočíst v předchozích článcích této série. Nás nyní nebude zajímat, jak se takový diagram zakresluje, ale jak se postupuje při tvorbě hypertextového modelu jako celku.

Základním předpokladem pro vytvoření modelu je existence následujících podkladů:

datové schéma
mapa webu
uživatelské a funkční požadavky

Celý proces můžeme rozdělit na hrubý a detailní návrh.

Hrubý návrh

Při tvorbě hypertextového modelu musíme zpočátku rozčlenit aplikaci do takzvaných pohledů, které představují hlavní součásti aplikace (typicky například veřejná část webu nebo administrační rozhraní).

Jednotlivé pohledy na webovou aplikaci musíme rozčlenit do oblastí (area). Oblast představuje základní složku (modul) budované webové aplikace, která se skládá z jednotlivých typů stránek respektive obrazovek. Při identifikaci oblastí vycházíme z funkčních požadavků a mapy webu. Často platí vztah, že oblast odpovídá jednomu případu užití z UseCase diagramů. Například můžeme definovat oblast editace zboží, která odpovídá stejně pojmenovanému případu užití.

Pokud máme identifikované jednotlivé oblasti, můžeme přejít k definici viditelnosti a přístupnosti jednotlivých oblastí. Zajímá nás především, která oblast bude implicitní po vstupu do daného pohledu aplikace a které oblasti budou typu landmark, tedy stále přístupné z jakékoli jiné oblasti. Z těchto typů oblastí se obvykle generuje menu aplikace. Následuje identifikace oblastí, které nejsou označené ani jako default ani jako landmark a jsou tedy přístupné pouze prostřednictvím odkazů z jednotlivých stránek, nikoli z menu.

Detailní návrh

Náš první úkol ve fázi detailního návrhu představuje identifikace stránek, ze kterých se budou skládat nalezené oblasti. Například oblast editace zboží se může skládat ze stránky se seznamem zboží pro danou kategorii a ze stránky s vkládacím, respektive editačním formulářem, případně dalších stránek.

Potom musíme definovat typ každé stránky a určit, zda je to:

Domovská stránka: Její význam není třeba vysvětlovat. Jedná se o stránku, která se automaticky načte při zadání adresy příslušné prezentace. Takto označená může být samozřejmě pouze jedna stránka.
Implicitní stránka: Implicitní stránka je obdobou domovské stránky pro příslušnou oblast. Je to tedy stránka, která se automaticky zobrazí, pokud vstoupíme do příslušné oblasti (sekce) webu.
Stále přístupná (landmark) stránka: Stále přístupné stránky představují stránky, na které se můžeme dostat z jakékoli jiné stránky, která je obsažena ve stejné přímo nadřazené oblasti nebo pohledu na webovou prezentaci.
Klasická stránka: Všechny ostatní stránky dosažitelné přes klasický odkaz z jiné stránky.

V další fázi detailního návrhu již určujeme samotný obsah jednotlivých stránek pomocí prvků stránky (units), jejichž použití je vysvětleno v článku o kompozici webové aplikace. Současně se do hypertextového modelu přidávají samotné odkazy napříč jednotlivými oblastmi a stránkami.

Implementace a testování

Návrhem samozřejmě vývoj aplikace nekončí. Následuje fáze implementace, které se částečně věnoval článek o vývojovém prostředí WebRatio. Na tomto místě bych chtěl podotknout, že využití nástroje WebRatio je pouze jednou z možností, jak realizovat modely navržené v metodologii WebML.

Nikomu nic nebrání, aby analýzu prováděl s obyčejnou tužkou a kusem papíru a aplikaci naprogramoval v prostředí .NET, v Javě, nebo v PHP. Správná analýza není závislá na implementačních nástrojích a slouží jako závazná dokumentace a návod pro úspěšnou implementaci. Výstupem analýzy provedené v prostředí WebML je datové schéma jednoduše převoditelné do relační databáze. Podrobný popis struktury webu a jednotlivých stránek nám přináší zase hypertextový model.

Testování je natolik důležité a náročné téma, že by si vyžádalo samostatnou sérii článků. Nikdo nepochybuje o jeho významu. Již méně firem je ochotno na něj uvolnit adekvátní množství finančních prostředků. Důležité je vědět, že správné testování nepředstavuje pouze tupé proklikávání aplikací. Komu nic neříkají pojmy testovací scénář nebo zátěžové testy, měl by si své znalosti v této oblasti určitě doplnit.

Závěr

Série článků o metodologii WebML se snažila představit jeden ze způsobů, kterým lze přistupovat k analýze a návrhu webové aplikace. Není to jediný správný způsob, který máme k dispozici, ale obsahuje spoustu zajímavých a užitečných prvků, které můžeme při vývoji webových aplikací využít.

Těmito články jsem chtěl především poukázat na důležitost analýzy, která je v oblasti tvorby webu opomíjena poněkud častěji než v ostatních oblastech tvorby software.