Po zmapování požadavků zákazníka a ujasnění detailů při tvorbě USE-CASE diagramů, Scénářů, Analytického o Business modelu přichází na řadu samotná tvorba software. Otázkami jak a čím začít se zabývá tento článek.
Úvod
Základní otázkou při tvorbě software je volba programovacího jazyka. V případě webových aplikací a systémů je to především technologie PHP + MySQL a ASP.NET. Pro návrh pomocí jazyka UML je vhodnější, když může být návrh převeden přímo do objektového návrhu. Ale ani strukturální jazyky nejsou nepoužitelné.
Technologie ASP.NET umožňuje objektové programování už od svého počátku. Jazyk PHP přichází s podporou objektového programování později. V každém případě zůstává nejobtížnější částí v procesu tvorby softwaru otázka tvalého uložení dat do relačních databází. Objekty jsou ze své podstaty obvykle vícerozměrné struktury. Tabulky v relačních databázích však umožňují ukládání dat pouze ve dvojrozměrných strukturách.
Předtím, než se začne s programováním, je třeba navrhnout analytický class model. Nejedná se o model tříd ve významu tříd objektově orientovaného programování. Třídou v analytickém modelu se rozumí evidovaný pojem. Ten nemusí být ve výsledném programu nutně realizován přímo třídou, ale například tabulkou, funkcí a podobně. Ve velké většině případů se ale programové třídy a analytické třídy překrývají.
Nesmíme zapomínat, že analytik je pouze nejvyšším bodem celého vývojového stromu, a že návrh, který vytvoří, není neměnným dokumentem. Vývoj musí probíhat za vzájmené komunikace mezi všemi zúčastněnými aktéry. Obvyklá struktura je složena z následujících prvků:
- 1 analytik
- 3 designéři
- 6 programátor
Množství jednotlivých aktérů (neplést, prosím, s pojmem ACTOR z UML) se zvyšuje podle velikosti projektu. Ve velmi malých projektech je zvykem prolínat jenotlivé role (analytik je zároveň designérem, designér je zároveň programátorem apod.). Zde je ovšem nutná velká osobní kázeň, aby se dotyčný dokázal odprostit od ostatních úloh, která má „sehrát“ a nezanášel například do analytického modelu pojmy z designérské úrovně. Nutno dodat, že tomu se dokáže v takových případech zcela vyhnout málokdo.
Analytický model
Co je tedy úkolem analytického class modelu? Jak již bylo řečeo výše, jedná se především o evidenci pojmů. Z předchozí analýzy již vyplynuly poměrně jasné obrysy budoucího systému, ale ještě nejsou ujasněny vnitřní struktury. Ty by měl představit právě analytický class model. Ten se zároveň stává jedním z hlavních dokumentů (spolu se scénářem a use – case diagramem) pro práci designéra.
Jak by mohl takový konkrétní analytický class model vypadat si ukážeme na příkladu, který by uveden v článku XXX (Registrace mimoškolních úspěchů). Dobrým pomocníkem bývá vytvoření diagramu objektů před samotným class diagramem. Ten totiž operuje s pojmy bližšími realitě, s nižší mírou abstrakce. Jak by tedy vypadal takový model ve výše uvedeném příkladu:
Zde ještě neoperujeme s pojmem třída, ale pouze s objekty. Ty jsou blíže realitě a lépe na nich vidíme vztahy, které mezi pojmy panují. Zkušený analytik si často bez takového diagramu poradí, ale zároveň je to dobrý nástroj, jak si vyjasnit situaci se zákazníkem.
Z tohoto nákresu je již jednoduchá cesta ke class modelu. Ten nebude příliš složitý a bude kopírovat strukturu objektového diagamu. Mohl by vypadat například takto:
Tento příklad byl velmi transparentní. Někdy ale nemusí být situace v podobě objektů tak jednoznačná. Klasickým případem jsou stromové struktury, které v podobě objektů vypadají složitě, ale po přepracování do diagramu tříd vyjde krásně elagantní řešení. Zkusme učebnicový příklad. Firma vyrábí mnoho výrobků, přižemž některé se skládají z jiných. Příkladem může být kuchyňské studio. Zde je příklad v podobě diagramu objektů:
Jak je vidět jednotlivé kusy na sebe navazují a některé se ještě navíc skládají z dalších součástí. Jak tedy tento problém vyřešit? Pokud se na takový model podívá zušený programátor nebo analytik, hned je mu jasné, že všechny objekty mají určité společné vlastnosti. Ty lze tedy vyjádřit v samostatné třídě a ostatní třídy tvořit jako potomky této základní třídy. Celý model by mohl vypadat následujícím způsobem:
Na úrovni analytického modelu se nezabýváme podrobnostmi jednotlivých tříd, jako jsou názvy členů, datové typy, struktury apod. Jde nám pouze o uchopení základních pojmů a jejich strukturalizace. Bližší pohled na výsledný software nám nabídne až model designérský, ale to již není téma tohoto článku.