Grafické modelování aneb Výhody i meze jazyka UML

Situace okolo průběhu většiny vývojových projektů nebývá většinou k smíchu a nezřídka se může manažerům i pr...


Situace okolo průběhu většiny vývojových projektů nebývá většinou k smíchu a
nezřídka se může manažerům i programátorům velmi rychle vymknout z rukou.
Softwarové produkty sestávají z ohromného množství programového kódu a není
těžké ztratit po čase orientaci, pokud se například na projektu vystřídá více
vývojářů. Východisko z mizérie může nabídnout grafické modelování pomocí jazyka
Unified Modeling Language (UML) alespoň pokud jsou respektována určitá pravidla.
Mnozí z IT profesionálů a vývojářů mají osobní zkušenost s projekty
organizovanými podle hesla "inteligent chaos zvládne" nebo s takovými, které
zkrátka nesplnily obchodní požadavky zákazníků. Jinými slovy s projekty, které
výrazně překročily časový plán či rozpočet, respektive obě kritéria, případně
jejichž plánovaný produkt nakonec ani nikdy nespatřil světlo světa. Proč se tak
málo učíme z chyb minulosti? Podstatný důvod jistě spočívá v samotném typu
produktu. Software se v posledku skládá z ohromného množství řádek programového
kódu. Tato forma popisu aplikace může být dostatečná pro menší projekty,
situace se ale stává obtížnější, pokud už je program velmi rozsáhlý. Nejsou zde
totiž k dispozici žádné abstraktnější mezistupně, které by umožnily dívat se na
aplikaci s různými stupni přiblížení.
Neexistuje tedy podpora pro pohled do systému z různých zorných úhlů a na
různých úrovních abstrakce. Ještě komplikovanější je, když program ošetřují a
upravují v průběhu delší doby různí vývojáři. Údržba a rozšiřování softwaru
výrazně narušují jeho strukturální kvalitu. Potom je takřka nemožné získat z
desetitisíců řádek kódu přehled o struktuře aplikace a v ní vytvořených
vztazích. Textové popisy či komentáře v programovém kódu jsou tedy krajně
nevhodným pracovním podkladem pro efektivní práci se softwarovou aplikací v
rámci vývojového projektu.

Tlumočení zdrojem chyb
Ten, kdo je za aplikaci odborně odpovědný, ovládá jen vzácně jazyky jako Java
nebo C++. Nemá tím pádem žádnou reálnou šanci, proniknout sám do aplikačního
systému nebo získat přehled o jeho aktuálním stavu. Potřebuje vývojáře coby
tlumočníka a je odkázán na jeho vědomosti a schopnosti. Tlumočení však bývá
častým zdrojem chyb a při překladu může občas dojít dokonce i k překroucení
smyslu. Hlavní výzvou softwarového vývoje je proto zvládnout nebo obejít s tím
spojené složitosti a komplikace.
Podívejme se, jak to chodí v podobné oblasti: kupříkladu strojírenský design
byl značně zjednodušen díky uvedení CAD systémů, které umožnily tvorbu jedno-,
dvoja trojdimenzionálních nákresů. Výsledkem je urychlení práce, lepší řešení a
nižší náklady na vývoj. Rozhodující posun spočíval v možnosti značně lepšího
zvládnutí komplexity. Ani při softwarovém vývoji nelze grafické modelování
neustále obcházet. První krok v tomto směru byl učiněn sestavením specifikace
modelovacího jazyka Unified Modeling Language (UML) "grafickým modelováním"
budeme nadále rozumět postupy podporované UML, jejichž realizace zahrnuje také
použití odpovídajících modelovacích nástrojů.
UML je jazyk, jehož slovník se skládá z grafických elementů. Díky tomu umožňuje
velmi efektivně abstrahovat z UML grafů strukturu a funkci různých částí či
aspektů aplikace. Grafické znázornění modelů poskytuje také rychlý přehled
jednotlivých komponent programu a jejich struktury. Takto kupříkladu modelování
diagramů tříd umožňuje jednoduše srozumitelné znázornění obchodních tříd a
jejich vzájemných závislostí.
UML mimoto představuje abstraktnější formu "popisu aplikace" než samotný
programový kód, protože třídy se znázorňují jen se signaturami metod.
Implementace metod, které jsou pro vytvoření základního přehledu systému
irelevantní, zobrazena není. To navíc napomáhá snaze překlenout jazykové
bariéry mezi odborným/obchodním oddělením a vývojáři, neboť osvojit si grafický
modelovací jazyk je pro odborné specialisty či obchodníky podstatně jednodušší
než učit se tradičnímu programovacímu jazyku. Snadná a dobře zapamatovatelná
symbolika jim pak umožňuje pochopení jednotlivých modelů aplikací.

Transformace až k řešení
Pro efektivní nasazení modelování je rozumné využívat jej plošně ve všech
fázích vývoje. Ten začíná analýzou a pokračuje přes design programu až po
implementaci. Grafické modelování, jež přesahuje jednotlivé fáze, je například
základem technologie Model Driven Architecture (MDA), která umožňuje
transformaci modelu na programový kód. Tento proces vychází z počátečního, na
platformě nezávislého modelu, z něhož jsou následně prostřednictvím postupné
modifikace vytvořeny modely specifické pro určité platformy. Konečný model už
odráží implementované řešení.
Pro konkrétní formy modelování v jednotlivých fázích čili podle toho, který
aspekt se formuluje jakými jazykovými prostředky ale dosud neexistují žádné
standardy. V analýze mohou být odborné požadavky modelovány mimo jiné ve formě
případů použití (Use Cases), diagramů tříd a diagramů aktivit. Bohužel není k
dispozici žádná vhodná výrazová forma pro popis grafického uživatelského
rozhraní. A to i přesto, že právě GUI je důležitým prostředkem k tomu, aby bylo
možné přiblížit odbornému uživateli specifikované řešení.
Při návrhu se grafické modelování využívá v různém rozsahu. Existují metody pro
kompletní modelování vrstev architektury Model View Controller i přístupy pro
modelování výhradně na úrovni obchodní logiky. Model vs. kód
Rozhodování, zda modelovat vrstvy View a Controller, bývá často závislé na dvou
otázkách:
Je cílem vývoje produkt, nebo individuální řešení?
Jsou pro řešení využívány různé cílové GUI platformy?
UML model je užitečný jen tehdy, když odráží aktuální stav implementace. V
počátcích grafického modelování tomu tak nicméně často nebylo. Byl navržen UML
model a odděleně od něj byla programována odpovídající aplikace, čímž bylo
většinou předurčeno, že dojde k odchýlení napsaného kódu od původního
grafického modelu. To ovšem pochopitelně vedlo ke ztrátě výhod grafického
modelu, který tak byl v podstatě zcela odložen stranou, aniž by mu nadále byla
věnována pozornost. Příčina spočívala v tom, že nástroje pro modelování v UML
ještě nedospěly na dostatečnou úroveň a neposkytovaly ani možnost exportu, ani
potřebná API rozhraní. Z těchto důvodů byla tehdy cesta ke vzájemnému propojení
modelu a programového kódu uzavřena. To se mezitím nicméně změnilo: Různí
výrobci nabízejí modelovací nástroje, které se hodí pro různé požadavky.

Grafické programování
Bylo by však příliš zjednodušující připisovat dřívější nedokonalost grafického
modelování pouze na vrub nevyhovující kvality nástrojů. Pro zvýšení účinnosti
se musí UML kvalifikovat jako grafický programovací jazyk.
Tím je míněno následující: dnes v této oblasti v podstatě probíhá podobným
způsobem něco, co proběhlo zhruba před 20 lety při odklonu od programovacího
jazyka Assembler blízkého strojovému kódu směrem k C (nebo k jiným vyšším
jazykům) a později k objektově orientovaným jazykům. Z tohoto úhlu pohledu se
dnes prakticky nacházíme v momentě zlomu při přechodu od textového ke
grafickému programování.
K této změně se každopádně přidává jeden důležitý faktor. Nový "programovací
jazyk" UML nemá dostačující "slovní zásobu", aby mohl adekvátně vyjádřit
zejména implementační detaily. Ani rozšíření UML 2.0 nepřináší zcela uspokojivé
řešení. Dokud ale není k dispozici jazyk, kterým lze kompletně vyjádřit všechny
aspekty vývoje softwarových řešení, je nezbytné mluvit přinejmenším dvěma
jazyky.
Tento systémový nedostatek vede k růstu složitosti při řízení projektů. Taková
komplikace týkající se projektového managementu může zcela převážit nad
výhodami grafického modelování nebo je alespoň zčásti smazat. Jen úplný a
výrazově bohatý grafický popisný jazyk by nás mohl nepříjemného jazykového
rozštěpení zbavit.

Generování kódu
Perspektivy vyplývající z myšlenky takového grafického programovacího jazyka
jsou velmi slibné. Modelování by například mohlo být kombinováno s generováním
kódu. To znamená, že by bylo možné rozšířit grafický model o odborné a
technické atributy, jež by byly interpretovány generátorem kódu a převáděny na
kód.
Rozšíření mohou jít až tak daleko, že lze mluvit o vlastním "dialektu". Vezměme
například v úvahu sledování změn u osoby ve vztahu k jejímu bankovnímu spojení.
U každého jedince mají být sledovány časové okamžiky změn údajů a existující
nebo již neplatná zplnomocnění pro účtování na vrub. Implementace těchto
vlastností je velmi náročná. Musí být zajištěna možnost sledování změn, stejně
jako je nutné zohlednit zápis historie na různá místa. V případě přístupu
spočívajícího v modelování a generování přitom postačí například označit
příslušnou třídu jako "sledování změny". Zbytek už automaticky zvládne
generátor. Služby s přidanou hodnotou tak mohou být jednoduchým způsobem
připojovány a odpojovány.
Některé významné otázky týkající se přístupu ke grafickému modelování
vyvstávají ve vztahu k řízení projektu. Patří k nim například: Co se má
modelovat, jak probíhá modelování v týmu a které dialekty/nástroje budou
využity? Standardizovaný postup momentálně neexistuje.
Dosažené ekonomické výhody proto v rozhodující míře závisejí na třech
faktorech: za prvé na základním modelu postupu a s ním souvisejícím řízením
projektu, za druhé na využití perspektiv integrace služeb s přidanou hodnotou a
konečně na správné volbě nástrojů.

Výzva projektům
Největším kamenem úrazu při využití grafického modelování jsou systémové
nedostatky v popisu modelu. V rámci analýzy k tomu patří specifikace
uživatelských rozhraní s jejich provázáním s obchodní vrstvou. Pokud je
rozhraní popisováno ve zcela jiném prostředí, zvyšují se na jedné straně nároky
na obsluhu, na straně druhé je u takového designu prakticky vyloučeno jeho
opakované použití nebo automatická transformace.
Při návrhu je ale rozhodující efektivní a hladká integrace modelování a
programování (tvorby kódu). Zkušenost nás učí, že by ředitelé projektů měli
pečlivě zvážit témata, jako jsou tvorba balíků (buildů), generování jednotek a
s tím spojená i doba generování a v neposlední řadě kontrola verzí modelu. Pak
může grafické modelování přinést ekonomický užitek již dnes.

Pro a proti UML
+snadné zaškolení pro odborné či obchodní specialisty
+redukce složitosti
+možnost postupného přiblížení změny úhlu pohledu na vyvíjenou aplikaci
+možné redukce nákladů při volbě vhodného modelu postupu
+transparentní vývoj softwaru
+lepší dokumentace vývoje
+jednoduchá integrace služeb s přidanou hodnotou
-rozštěp v prostředí je nezbytné používat při vývoji alespoň dva jazyky pro
tvorbu modelu a kódu
-nemožnost modelování metod
-nepostačující výrazové prostředky (např. nelze popsat uživatelské rozhraní)









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.