Analytické modelování — LLA

Úvod

Tato kapitola zavádí pojem analytického modelování (dále také AM) v rámci AAF jako logický celek tří souvisejících pojmů: Analytické modelování jako disciplína samotná, Tři pracovní vrstvy systému jako rámec, ve kterém AM žije, a Mapování jako mechanika přechodu z AM do nižších vrstev. Účelem kapitoly je vymezit, čeho se AM týká, čeho se netýká a jakou roli zastává v celém vývojovém řetězci informačního systému.

Tyto tři pojmy spolu úzce souvisí — nelze pochopit AM bez znalosti tří vrstev, ve kterých je nejvyšší, a nelze pochopit hodnotu AM bez znalosti, jak se z něj přechází níž (mapování). Proto jsou v této kapitole zavedeny pod společnou střechou.

Kapitola dále vymezuje AM proti dvěma sousedním oblastem:

• proti Designu — od něj se AM odděluje mírou detailu implementace; přechod z AM do Designu se v AAF nazývá mapování a provádí se agilně,
• proti BPM — proti BPM se AM odděluje předmětem popisu; AM popisuje systém sám, BPM popisuje jeho okolí.

Tři pracovní vrstvy systému

Pojem analytického modelování je v AAF zasazen do širšího rámce tří pracovních vrstev vývoje informačního systému. Tento rámec přebírá AAF z OMG MDA (Model Driven Architecture). V souladu s touto technologií AAF zavádí tři úrovně abstrakce a tedy tři pracovní vrstvy, které se liší mírou detailu implementace — tedy tím, jak je popis systému poplatný cílové technologii. V AAF na rozdíl od metodiky Waterfall se průchod těmito úrovněmi provádí agilním způsobem.

Tyto tři vrstvy jsou:

1. Analytické modelování (AM) — nejvyšší vrstva, míra detailu implementace 0 %. Popis systému je výrazově nezávislý na technologii. Odpovídá na otázku co systém eviduje, co dělá a jak se chovají výskyty informací v něm. Je předmětem této kapitoly.

2. Design (D) — střední vrstva. Popis systému už je poplatný cílové technologii (RDB, OOP jazyk, framework, GUI), ale stále se jedná o model, ne o spustitelný kód. Odpovídá na otázku jak bude analyticky popsaný systém navržen pro realizaci v dané technologii. Přechod z AM do Designu se v AAF nazývá mapování.

3. Kódování (K) — nejnižší vrstva, míra detailu implementace 100 %. Chápána jako vrstva fyzické realizace. Popisem systému jsou samotné zdrojové soubory, SQL skripty, zkompilované balíčky a další artefakty fyzicky realizující systém. Přechod z Designu do Kódování se nazývá realizace nebo implementace.

Všechny tři vrstvy mají jako předmět popisu týž informační systém. Neliší se tím, co popisují, ale s jakou mírou detailu implementace a jakou syntaxí. Mezi vrstvami funguje obousměrná zpětná vazba — analytický návrh, který by byl v cílové technologii neschůdný nebo nepřiměřeně složitý, se v AM upravuje tak, aby zůstala zachována hodnota užitku a současně bylo mapování únosné. AM je tedy ve svém vyjádření na technologii nezávislé, ale ve své tvorbě s ní vede dialog.

Rozlišující znaky

Vedle těchto tří pracovních vrstev systému stojí ještě BPM (Business Process Modeling). BPM není pracovní vrstvou systému ve smyslu MDA resp. AAF, protože jeho předmětem není systém, ale okolí systému — procesy podniku, ve kterých systém vystupuje jako prvek poskytující služby užitku. Hranice mezi BPM a AM je proto hranicí předmětu popisu, ne hranicí míry detailu implementace, kterou se vymezují tři pracovní vrstvy mezi sebou.

Analytické modelování

Analytické modelování (dále také AM) je v AAF disciplína, jejímž předmětem je informační systém samotný a jejímž výstupem je popis tohoto systému s nulovou mírou detailu implementace. AM neodpovídá na otázku, v čem bude systém realizován, ani na otázku, jak bude technologicky uspořádán. AM odpovídá výhradně na otázku, jaké funkcionality systém nabízí svému okolí (podniku), co eviduje, co dělá a jak se chovají výskyty informací, které v něm žijí.

Předmětem AM je týž informační systém, který je předmětem Designu a Kódování. AM se od těchto dvou nižších vrstev neliší předmětem popisu, ale mírou detailu implementace a syntaxí, kterou tento popis používá. Dokumenty AM jsou výrazově nezávislé na technologii — neobsahují názvy databází, programovacích jazyků, knihoven ani frameworků.

Tato nezávislost AM na technologii ovšem neznamená, že se technologie při tvorbě AM zcela ignoruje. Mezi vrstvami funguje zpětná vazba: logicky čistý analytický návrh nemusí být v cílové technologii schůdný, anebo by jeho přímé mapování bylo nepřiměřeně složité. V takovém případě se nemění hodnota užitku, kterou AM popisuje, ale volí se jiná varianta mapování, případně se upraví analytický návrh tak, aby zůstala zachována hodnota a současně bylo mapování do dané technologie únosné. AM je tedy ve své vyjadřovací rovině na technologii nezávislé, ale ve své tvorbě s ní vede dialog.

Rozlišující znaky

Hranice AM proti vyšší vrstvě BPM zní: BPM popisuje okolí systému (procesy byznysu, ve kterých systém vystupuje jako prvek), zatímco AM popisuje systém sám. Případ užití (UC) celý patří do AM jako pojem analytického popisu systému; v BPM vystupuje jen jako služba užitku (analogie jako tlačítko), kterou okolí použije. Vnější pohled na UC (HLA) i vnitřní pohled (LLA) jsou obě věcí AM — liší se jen úhlem pohledu (zvenku — zevnitř), ne vrstvou.

Hranice AM proti nižší vrstvě Designu zní: AM nemá žádný technologický detail, Design už ho má. Přechod z AM do Designu se v AAF nazývá mapování a je v AAF dělán sofistikovaně a brzy — viz pojem Mapování v této kapitole.

Mapování

Přechod z AM do Designu se v AAF nazývá mapování. Mapování je krok, ve kterém se analyticky popsaný systém převádí do podoby poplatné cílové technologii — tedy z míry detailu implementace 0 % do míry detailu implementace odpovídající danému prostředí (RDB, OOP jazyk, framework, GUI, REST API a podobně).

Mapování není 1:1

Mapování není mechanický překlad jeden ku jednomu. Jedna analytická třída může v Designu vést na dvě nebo více struktur (například jedna třída se rozpadne na dvě tabulky v relační databázi), naopak se může stát, že několik analytických tříd splyne do jedné struktury v Designu. Totéž platí pro vztahy mezi třídami, pro případy užití a pro další prvky AM. Konkrétní vzory mapování (například mapování kompozice, generalizace, asociační třídy do RDB nebo do OOP) jsou rozebírány v kapitole Class Model AAF Lite Syntaxe a v kapitole Architektura BPM-UCM-CLM.

Mapování jako obousměrný dialog

Mapování není jednosměrné předání zadání z AM do Designu. Pokud cílová technologie analytický návrh neunese — buď je v ní logicky čistý návrh neschůdný, anebo by jeho přímé mapování bylo nepřiměřeně složité — pak se AM upraví. Při této úpravě se nemění hodnota užitku, kterou AM popisuje, ale volí se jiná varianta analytického návrhu, která je do dané technologie mapovatelná únosně. Mapování je tedy místem, kde mezi vrstvami probíhá zpětná vazba.

Optimalizace patří do mapování

Optimalizace je vědomý technologický krok proti opětovné použitelnosti — výměna „získám technologickou výhodu (rychlost, paměť), ztratím opětovnou použitelnost". Optimalizace v AAF patří primárně do mapování, tedy do Designu, ne do AM. AM má být ideálně bez optimalizací — popisuje systém logicky čistě, bez ohledu na technologické ústupky.

Pokud se přesto optimalizace výjimečně objeví již v AM, pak musí být v dokumentaci AM explicitně označena jako optimalizace. Neoznačená optimalizace skrytá v AM je v AAF považována za chybu, protože znehodnocuje analytický model.

Výjimka: reverzní analýza (Brownfield)

Pro reverzní analýzu platí výjimka. V Brownfieldu, kde se AM rekonstruuje zpětně z existujícího nasazeného systému, se doporučuje provést zpětné mapování 1:1 — tedy zachytit AM ve stavu „jak to tam je", včetně optimalizací a technologických nečistot, které v původním systému jsou. Očista takto vzniklého nečistého AM se neprovádí během reverzního mapování, ale až poté, na úrovni AM, formou refactoringu (viz kapitola AAF Brownfield).

Mapování v AAF probíhá unifikovaně, rychle a agilním způsobem

Mapování je v AAF děláno sofistikovaně. Díky AAF Lite Syntaxi, katalogu vzorů a podpoře AI agenta probíhá unifikovaně a rychle v souladu s agilním přístupem — analytik (a v jeho roli AI asistent) má pro typické situace připravené mapovací vzory a při tvorbě AM tedy ví, do čeho jeho návrh povede.

Nejčastější chyby

Vynechání AM

Nejtěžší a současně nejhůře viditelnou chybou je vynechání AM jako celku. Vývoj přeskočí logickou rovinu popisu systému a začíná rovnou Designem, často přímo Kódováním pod záminkou, že „zadání je jasné" a „analýza by jen zdržovala". Místo AM se nasadí metodika Rychlá issue — práce se řídí přímo z konkrétních požadavků na kód, bez vrstvy, která by je posuzovala proti hodnotě užitku (viz kapitola VBM).

"Rychlá issue" se v krátkém horizontu jeví rychlejší s menšími náklady (CBM). Tým má pocit, že „už se programuje", místo aby se „ještě modelovalo". V delším horizontu ale tato úspora neexistuje — ztracený čas se vrací mnohonásobně v podobě opakovaného přepracování, pozdního odhalení logických rozporů, ztráty opětovné použitelnosti a vývoje, který se z původně přímé cesty mění v bludiště ad hoc oprav. Tento stav vývoje se v AAF nazývá Tunel (viz kapitola VBM).

Tunel je past právě proto, že vstup do něj vypadá jako zkratka. AM není zdržení; je to vrstva, která vývoj drží na cestě tam, kam má dojít.

Mísení AM s BPM

V dokumentu AM se objeví popis okolí systému — procesů podniku, rolí v podniku, věcí, které se odehrávají mimo systém. Hranice mezi AM a BPM ale nevede podle míry detailu, vede podle předmětu popisu: AM popisuje systém sám, BPM popisuje jeho okolí. Když se v AM popisuje, „jak v podniku chodí faktury", není to AM, ale BPM ve špatném souboru. Většinou se této chyby dopustí analytik chybnou analýzou děje okolí a systému, aniž by rozlišoval hranici okolí a popisoval děj jako posloupnost aktivit bez identifikace bodu potřebnosti alias cinknutí systému (viz UC 1. druhu).

Záměna stejně znějících pojmů AM a BPM

Tentýž název znamená v BPM něco jiného než v AM. Faktura v BPM je papír (nebo elektronický doklad), který přichází do podniku a putuje jím. Faktura v AM je evidovaná entita uvnitř systému — budoucí kus programu (tabulky, třídy, scénáře). Tyto dva pojmy spolu souvisí, ale nejsou totéž a chovají se odlišně (například mají různé multiplicity, různé stavy, různé životní cykly). Například faktura v BPM musí mít alespoň jeden řádek, faktura v AM má povoleno 0 řádků, protože má stav „editace". Použití pojmu faktura tak, jako by šlo o jednu věc, je hrubá chyba modelování.

Mísení AM s Designem

V dokumentu AM se objeví prvky technologie — názvy tabulek, sloupců, datových typů, programovacích jazyků, knihoven, frameworků. AM má míru detailu implementace 0 %; jakmile se v něm objeví výraz poplatný cílové technologii, AM přestal být AM. Této chyby se nejčastěji dopouštějí silní technologové, kteří jsou převedeni do role analytika a v dokumentu AM přirozeně sklouzávají do jazyka, který znají z Designu.

Předčasné mapování v AM

Tato chyba je rafinovanější než předchozí. Analytik v dokumentu AM nepoužije technologické názvy (chybu Mísení AM s Designem tedy nedělá), ale přemýšlí v technologických kategoriích už při tvorbě AM. Struktura modelu pak odpovídá tomu, jak by se to programovalo v cílové technologii, ne tomu, co popisovaný systém logicky je. Symptom: AM má strukturu poplatnou cílové technologii, i když to není nikde výslovně napsané.

Neoznačená optimalizace v AM

Optimalizace, která se z technologických důvodů dostala do AM, ale není v dokumentu AM explicitně označena jako optimalizace. Tato chyba je popsána v sekci Mapování (pod-sekce Optimalizace patří do mapování) a zde se na ni jen odkazuje.

Vazby

Rozpracováno

Verze a změny

• 0.7 — restrukturalizace na novou kompozitní šablonu Definice z skills-draft-v9.md. Kapitola nově obsahuje tři pojmy (## Tři pracovní vrstvy systému, ## Analytické modelování, ## Mapování) pod společnou střechou. Sekce Poznámka k BPM a Definice AM — Hranice přesunuty do ### Rozlišující znaky u příslušných pojmů. Sekce Vztahy k jiným pojmům a Vazby na jiné kapitoly sloučeny do jedné sekce Vazby (placeholder Rozpracováno). Sekce Příklady odstraněna (v9 šablona Definice tuto sekci nemá; obsah příkladů přijde do textu jednotlivých pojmů, až bude doplněn). Forward odkaz na Tunel v sekci Nejčastější chyby zachován; čeká na zavedení pojmu v kapitole VBM (TODO 18).
• 0.6 — opraveny překlepy a gramatické chyby; v sekci Tři pracovní vrstvy zrušena duplicitní zmínka o agilním provádění mapování (zůstává v Úvodu a v sekci Mapování); upravena formulace pro Design (otázka „jak bude... navržen pro realizaci..." místo „jak bude... realizován..."); opraveno „metodiky typu Waterfall" na „metodiky Waterfall"; podsekce Mapování v AAF... přepracována; v sekci Mísení AM s BPM doplněna a upravena věta o chybné analýze hranice okolí a systému s odkazem na cinknutí systému a UC 1. druhu; v sekci Záměna stejně znějících pojmů doplněn příklad multiplicity řádků faktury.
• 0.5 — doplněna sekce Nejčastější chyby (šest chyb vázaných na hranice AM mezi vrstvami AM–Design–Kódování a hranici AM↔BPM: vynechání AM jako první, mísení AM s BPM, záměna stejně znějících pojmů, mísení AM s Designem, předčasné mapování v AM, neoznačená optimalizace v AM).
• 0.4 — doplněna sekce Mapování do nižších vrstev (pět pod-sekcí: mapování není 1:1; mapování jako obousměrný dialog; optimalizace patří do mapování; výjimka pro reverz/Brownfield; mapování v AAF probíhá unifikovaně a rychle).
• 0.3 — doplněna sekce Úvod a sekce Tři pracovní vrstvy systému (přejmenováno z původního názvu Vrstvy vývoje systému). Trojvrstvý rámec AM–Design–Kódování zaveden s odkazem na OMG MDA. BPM doplněno jako poznámka pro úplnost (vrstva popisující okolí, ne systém).
• 0.2 — odstraněna sekce Analytické modelování jako slovní programování. Pojem slovní programování bude zaveden v jiné kapitole (Scenario Patterns nebo Architektura AAF BPM-UCM-CLM, otevřený TODO bod).
• 0.1 — první draft kapitoly. Rozpracována pouze sekce Definice analytického modelování, ostatní sekce mají placeholder TBD (případně Rozpracováno u sekce Vazby na jiné kapitoly).