Trendy v modelování aplikací

V současné době modelování aplikací dominuje standard UML. Zdá se, že bude převládat i v blízké budoucnosti. Ned...


V současné době modelování aplikací dominuje standard UML. Zdá se, že bude
převládat i v blízké budoucnosti.
Nedávno byla oficiálně schválena verze 2.0 standardu UML (Unified Modeling
Language). Ta přináší výraznější změny především do způsobu modelování
interakcí, aktivit a komponent. Ovšem i v UML 2.0 zůstává trochu "nešikovný"
mix notace pro tvorbu podnikových a real-time systémů, což může být pro
vývojáře podnikových aplikací matoucí.

MDA
Konsorcium OMG (www.omg.org), jež standard UML vyvíjí, stojí také za novějším
konceptem, nazvaným Model Driven Architecture (MDA, modelem řízená
architektura). Ten standardizuje dvě oblasti modelování: členění modelů v
průběhu vývoje a obecné principy transformací jednoho modelu v druhý.

MDA definuje tři typy modelů:
lCIM (Computation Independent Model) model nezávislý na počítačovém zpracování
lPIM (Platform Independent Model) model nezávislý na implementační platformě
lPSM (Platform Specific Model) model řešení pro specifickou platformu
Každý z výše uvedených modelů má z hlediska modelování aplikací svá specifika.
Na ně a na trendy v jejich aplikaci se dále zaměříme.

Počítačově nezávislý
Pro tvorbu modelu nezávislého na počítačovém zpracování bylo důležitým impulzem
začlenění standardizační iniciativy BPMI (Business Process Modeling Initiative)
pod křídla konsorcia OMG. BPMI vytvořilo standard BPMN (Business Process
Modeling Notation) využitelný v modelování podnikových procesů. Tento standard
integruje dosud roztříštěné notace a s ohledem na sílu konsorcia OMG lze
předpokládat, že bude především v podnikové sféře přijat. V ní je totiž
modelování procesů výchozím krokem pro následnou IT podporu těchto procesů. OMG
začleněním BPMN letos v létě v podstatě vyřešilo podivnou situaci, která
nastala po zveřejnění konceptu MDA, kdy OMG sice vymezilo obsah modelu CIM, ale
oproti dalším MDA modelům pro něj nenabízelo standardizovanou notaci.
Při sestavování standardu BPMN byl kladen důraz nejen na standardizaci
vizualizace procesu, ale BPMI též nadefinovalo mapování BPMN symbolů do jazyka
BPEL (Business Process Execution Language). Tento krok by měl usnadnit
automatizaci procesu modelování v systémech
workflow, případně v jejich simulaci.
Dle dosavadních vyjádření OMG to zatím nevypadá, že by byla BPMN začleněna
přímo do UML. Na druhou stranu je prezentována jako rozšiřující standard k UML
pro oblast modelování podnikových procesů.

Platformově nezávislý
Ve fázi analýzy, kdy je vytvářen platformově nezávislý model, v současné době
rovněž dominuje UML. Očekává se, že posun ve vývoji přinesou změny notací
modelování interakcí v UML 2.0, které umožňují přehledněji členit a provazovat
jednotlivé diagramy. To by ve svém důsledku mělo více zpřístupnit diagram
interakcí i pro analytické účely.
Co však chybí i UML 2.0, je formální specifikační jazyk vhodný i pro analytické
účely. Teoreticky lze sice použít OCL (Object Constraint Language) doplňující
specifikační jazyk UML, ale ten pro analytické účely nepředstavuje vhodnou
volbu, neboť je zcela nečitelný pro běžného uživatele aplikací a spíše se blíží
soudobým objektově orientovaným programovacím jazykům. Neexistence široce
používaného formálního jazyka způsobuje, že po vizuální stránce jsou sice
analytické modely standardizovány, což zvyšuje jejich pochopitelnost, ale
vlastní popisy prvků modelu jsou zcela individuální.
Opakování v analýze: Vhledem k tomu, že při vývoji softwaru se stále více
prosazuje opakované využívání existujících komponent nebo služeb, stává se
otázka iterace také záležitostí analýzy. Ve své podstatě se jedná o důležitou
změnu nejen ve vlastním modelování, ale také v přístupu analytika, který
platformově nezávislý model vytváří. Oproti dřívějšku, kdy se jednalo především
o opakované využívání technických prvků a iterace byla spíše záležitostí
návrhu, je při opakovaném využívání celých části řešení klíčová úloha analytika.
Rozhodnutí o začlenění opakovaně použitelné části má samozřejmě zásadní dopad
na náklady projektu, řízení kvality a postup projektových prací.
Zde přichází ke slovu otázka použité metodiky vývoje, protože obecný rámec
postupu MDA tyto činnosti nevymezuje a ani nedefinuje, co přesně by měl
platformově nezávislý model pro identifikaci opakovaně použitelných služeb
obsahovat.

Platformově specifický
Současným trendem programovacích nástrojů (IDE, Integrated Development
Environment) je nabídnout vývojářům vizualizaci kódu ve formě UML modelu.
Programátor tedy vchází do bezprostředního styku s těmito platformově
specifickými modely a aktivní znalost UML se pro něj stává nezbytností. UML
modely v programovacích nástrojích mají stejnou strukturu jako příslušný
zdrojový kód, a jsou tudíž určeny pouze pro programátora nebo návrháře. Pro
analytika představuje takovýto model velmi obtížně pochopitelnou událost a pro
uživatele aplikace už není pochopitelný vůbec. Z těchto důvodů lze odvodit, že
rozšíření možností programovacích nástrojů nepokryje oblast tvorby analytických
a uživatelských modelů.
Vzhledem k současnému stavu se dá předpokládat, že otázka generování (nebo lépe
synchronizace) kódu a modelů v nástrojích CASE (Computer Aided Software
Engineering) se bude v budoucnosti posouvat směrem k synchronizaci a
transformaci UML modelů. I v této oblasti lze sledovat posun v oblasti
standardů vyvíjených seskupením OMG.
Pro přenos UML modelů mezi různými nástroji vytvořilo OMG specifikaci formátu
XMI (XML Metadata Interchange). Ten však nepokrýval oblast výměny modelů
dokonale. Problematickým se při použití XMI stal především přenos diagramů,
neboť ty jsou v různých nástrojích vytvářeny různými postupy, v různých
vrstvách a různým souřadnicovým systémem. Z tohoto důvodu vytvořilo OMG
specifikaci UML: Diagram Interchange jako rozšíření specifikace XMI formátu,
která by měla standardizovat přenos a prezentaci UML diagramů.

Automatizace modelování
Dalším trendem, který lze vysledovat v oblasti modelování, je stále širší
podpora automatické tvorby specifických částí modelů v modelovacích nástrojích.
Jedná se o řešení letitého problému souvisejícího s modelováním aplikací "Jakým
způsobem s omezenými zdroji alokovanými pro modelování vytvořit model, který je
dostatečně kompletní?"
Právě nedostatek času vede k tomu, že se vývojáři soustředí při modelování
pouze na určité části modelu (většinou se jedná o model tříd) a ostatní modely
vyvářejí jen částečně, například jen pro klíčové funkce aplikace (obvykle je
takto "postižen" především model interakcí). Takový přístup přináší vysoké
riziko chyb a nekonzistencí, neboť nelze v dostatečném rozsahu aplikovat
automatizované kontroly modelů. Na druhou stranu vytvoření kompletního modelu
bývá příliš pracnou, a nutno přiznat, že i nezáživnou záležitostí. Řešení
problému může přinést vyšší automatizace tvorby modelu, zvláště automatizace
rutinních činností tvorby částí modelu podle připravených šablon.
Automatizace modelování se dnes používá především při tvorbě platformově
specifických modelů, kdy je možné celé části modelů generovat na základě šablon
vycházejících z osvědčených návrhových vzorů. Analytické modelovací vzory
bohužel nejsou tak rozšířené a standardizované jako vzory používané při návrhu,
ale přesto se týmům, které se modelováním zabývají opakovaně, vyplatí připravit
šablony pro často používané modelové stereotypy. Tato investice se jim totiž
vrátí nejen při vlastní tvorbě systému, neboť jsou schopni skutečně důsledně
využívat automatizované kontroly konzistence modelů, ale i při údržbě aplikace,
kdy jsou v modelu podchyceny všechny závislosti.
Autor je Professional Services Director ve společnosti LBMS.









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