Úrovně abstrakce

Úvod

Tato kapitola zavádí Úrovně abstrakce jako osu, na které se popis informačního systému liší mírou detailu implementace, a její tři hodnoty: Analytický model IS, Technologický návrh IS a Kód IS.

Osa odpovídá na jedinou otázku: jak moc je popis systému poplatný cílové technologii? Neodpovídá na otázku, co se popisuje. Předmět popisu je u všech tří hodnot týž.

Kapitola je zároveň domovem hranice, podle které se rozhoduje všude tam, kde se posuzuje, zda popis ještě patří do logiky, nebo je to už technologický návrh řešení.

Úrovně abstrakce

Úrovně abstrakce jsou osa se třemi hodnotami. Rámec přebírá AAF z OMG MDA (Model Driven Architecture).

Hodnoty se liší mírou detailu implementace, tedy tím, jak je popis systému poplatný cílové technologii. Míra roste od nuly u Analytického modelu IS po sto procent u Kódu IS.

Všechny tři hodnoty 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 hodnotami 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 upraví tak, aby zůstala zachována hodnota užitku a současně bylo mapování únosné. Analytický model IS je tedy ve svém vyjádření na technologii nezávislý, ale ve své tvorbě s ní vede dialog.

V AAF se na rozdíl od metodiky Waterfall průchod těmito úrovněmi provádí agilním způsobem. Osa není fázový postup, ve kterém se jedna úroveň dokončí a teprve pak začne druhá.

Rozlišující znaky

• Osa, ne seznam etap. Hodnoty jsou tři stavy téhož popisu, ne tři po sobě jdoucí činnosti. Činnosti, které mezi nimi vedou, mají vlastní jména.
• Týž předmět. Co se popisuje, se po ose nemění. Mění se jen míra detailu implementace.
• Jediné kritérium. Zařazení rozhoduje míra detailu implementace, nic jiného. Ani rozsah, ani podrobnost, ani to, kdo popis vytvořil.
• Plný název včetně dovětku. Hodnoty se jmenují Analytický model IS, Technologický návrh IS a Kód IS, vždy s dovětkem IS. Dovětek je součástí názvu, ne upřesnění pro jistotu.

Co na ose nemá místo

Na ose leží jen popisy informačního systému. Okolí systému na ní místo nemá, protože není informačním systémem.

Týká se to zejména BPM (Business Process Modeling). BPM není hodnotou této osy, protože jeho předmětem není systém, ale okolí systému, tedy procesy podniku, ve kterých systém vystupuje jako prvek poskytující služby užitku. Hranice mezi BPM a Analytickým modelem IS je proto hranicí předmětu popisu, ne hranicí míry detailu implementace.

Ze stejného důvodu na ose neleží ani HLA, protože popisuje děj okolí.

Přechody mezi hodnotami

Hodnoty osy jsou výsledky. Činnosti, kterými se z jedné hodnoty dostaneme k druhé, jsou samostatné pojmy a jmenují se jinak:

• Analytické modelování vytváří Analytický model IS.
• Mapování je přechod z Analytického modelu IS do Technologického návrhu IS (viz dále).
• Realizace, alias implementace, je přechod z Technologického návrhu IS do Kódu IS.

Rozlišení výsledku od činnosti je podstatné. Analytický model IS je popis, analytické modelování je práce, která ho vyrábí. Zaměnit je znamená zaměnit osu za postup.

Analytický model IS

Analytický model IS je popis informačního systému s mírou detailu implementace nula procent. 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. Neodpovídá na otázku, čím to dělá.

Analytický model IS je totéž co LLA (Low Level Analysis). Jsou to dvě jména téhož; první podle pozice na ose, druhé podle pozice v Analytické dokumentaci.

Rozlišující znaky

• Nula procent implementace. V popisu není nic, co by se dalo vyměnit s technologií, aniž se změní význam.
• Otázka co. Popisuje se, co systém dělá a co eviduje.
• Přežije výměnu technologie. Formulace, která by se změnou databáze, jazyka nebo frameworku přestala platit, do Analytického modelu IS nepatří.

Technologický návrh IS

Technologický návrh IS je popis informačního systému, který už je poplatný cílové technologii, ale stále je to model, ne spustitelný kód.

Odpovídá na otázku, jak bude analyticky popsaný systém navržen pro realizaci v dané technologii. Sem patří volba databáze, jazyka, frameworku, vrstvení, způsobu nasazení a rozhraní.

Pozor na pořadí slov v názvu. Je to technologický návrh, tedy návrh systému vyjádřený v technologii. Není to návrh technologie, tedy práce, jejímž předmětem by byla technologie sama.

Rozlišující znaky

• Model, ne kód. Popis je stále model. Nedá se spustit ani zkompilovat.
• Otázka jak a v čem. Popisuje se, čím se to postaví a v jakém prostředí to poběží.
• Výměna technologie ho zneplatní. To je právě ten rozdíl proti Analytickému modelu IS.

Kód IS

Kód IS je popis informačního systému s mírou detailu implementace sto procent. Je to vrstva fyzické realizace.

Popisem systému jsou zde samotné zdrojové soubory, SQL skripty, zkompilované balíčky a další artefakty, které systém fyzicky realizují.

Rozlišující znaky

• Sto procent implementace. Nic už není otevřené k rozhodnutí o technologii.
• Spustitelnost. Ze všech tří hodnot je jediná, kterou lze zkompilovat a spustit.

Mapování

Mapování je přechod z Analytického modelu IS do Technologického návrhu IS. Je to krok, ve kterém se analyticky popsaný systém převádí do podoby poplatné cílové technologii, tedy z míry detailu implementace nula procent do míry 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 Technologickém návrhu IS 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. Totéž platí pro vztahy mezi třídami, pro případy užití a pro další prvky Analytického modelu IS. Konkrétní vzory mapování (například mapování kompozice, generalizace nebo asociační třídy do RDB či do OOP) rozebírá Slovník evidovaných pojmů a Architektura BPM-UCM-CLM.

Mapování jako obousměrný dialog

Mapování není jednosměrné předání zadání směrem dolů. Pokud cílová technologie analytický návrh neunese, tedy je v ní logicky čistý návrh neschůdný nebo by jeho přímé mapování bylo nepřiměřeně složité, pak se Analytický model IS upraví. Při té úpravě se nemění hodnota užitku, kterou model 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 hodnotami osy probíhá zpětná vazba.

Optimalizace patří do mapování

Optimalizace je vědomý technologický krok proti opětovné použitelnosti, tedy výměna získám technologickou výhodu (rychlost, paměť), ztratím opětovnou použitelnost. Optimalizace patří primárně do mapování, tedy do Technologického návrhu IS, ne do Analytického modelu IS. Ten má být ideálně bez optimalizací a popisovat systém logicky čistě, bez ohledu na technologické ústupky.

Pokud se přesto optimalizace výjimečně objeví už v Analytickém modelu IS, musí být v dokumentaci výslovně označena jako optimalizace. Neoznačená optimalizace skrytá v analytickém modelu je chyba, protože znehodnocuje model.

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

Pro reverzní analýzu platí výjimka. V Brownfieldu, kde se Analytický model IS rekonstruuje zpětně z existujícího nasazeného systému, se doporučuje provést zpětné mapování 1:1, tedy zachytit model 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 modelu se neprovádí během reverzního mapování, ale až poté, na úrovni Analytického modelu IS, formou refaktoringu.

Mapování 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ě Analytického modelu IS tedy ví, do čeho jeho návrh povede.

Nejčastější chyby

• Zkratka AM bez dovětku. Zkratka AM má dva různé významy. Široce znamená práci analytika, úzce jednu hodnotu této osy. Je to nosič záměny a nemá se používat. Píše se plný název Analytický model IS.
• Záměna výsledku za činnost. Hodnota osy se pojmenuje činností, tedy analytické modelování místo Analytický model IS nebo kódování místo Kód IS. Osa pak vypadá jako sled prací a s ní se vrací představa fázového postupu.
• Návrh technologie místo technologického návrhu. Přehození slov mění význam. Předmětem není technologie, ale systém.
• Okolí jako čtvrtá hodnota. BPM nebo HLA se zařadí na osu jako nejvyšší úroveň nad Analytickým modelem IS. Nepatří tam, protože jejich předmětem není informační systém.
• Technicky znějící pojem vydaný za technologii. Když je předmětem systému sama technika, jsou i pojmy, které znějí technologicky, pojmy Analytického modelu IS. U telefonní ústředny je takovým pojmem hovor, u serveru front prvek fronty. Rozhoduje předmět, který systém řeší, ne zvuk slova. Technologický návrh IS je u nich něco úplně jiného, například třídy v Javě a tabulky v Oracle. Chyba spočívá v tom, že se takový pojem odsune do Technologického návrhu IS jen proto, jak zní, a v Analytickém modelu IS pak chybí to, o čem systém ve skutečnosti je.
• Vynechání Analytického modelu IS. Nejtěžší a současně nejhůře viditelná chyba. Vývoj přeskočí logickou rovinu popisu a začíná rovnou Technologickým návrhem IS, často přímo Kódem IS, pod záminkou, že zadání je jasné a analýza by jen zdržovala. V krátkém horizontu to vypadá rychleji a levněji, v delším se čas vrací mnohonásobně v podobě přepracování, pozdního odhalení logických rozporů a ztráty opětovné použitelnosti. Podrobně viz Axiom Value Based Management, kde jsou popsány pojmy Rychlá issue a Tunel.
• Míšení Analytického modelu IS s popisem okolí. V dokumentu se objeví popis okolí systému, tedy procesů podniku, rolí a věcí, které se odehrávají mimo systém. Hranice nevede podle míry detailu, ale podle předmětu popisu. Když se v analytickém modelu popisuje, jak v podniku chodí faktury, není to model systému, ale popis okolí ve špatném souboru. Nejčastěji vzniká tím, že analytik popisuje děj jako posloupnost aktivit, aniž určí bod použití systému.
• Míšení Analytického modelu IS s Technologickým návrhem IS. V dokumentu se objeví prvky technologie, tedy názvy tabulek, sloupců, datových typů, jazyků, knihoven nebo frameworků. Analytický model IS má míru detailu implementace nula procent; jakmile se v něm objeví výraz poplatný cílové technologii, přestal jím být. Nejčastěji se toho dopouštějí silní technologové převedení do role analytika.
• Předčasné mapování. Rafinovanější podoba předchozí chyby. Analytik technologické názvy nepoužije, ale přemýšlí v technologických kategoriích už při tvorbě modelu. Struktura pak odpovídá tomu, jak by se to programovalo, ne tomu, co popisovaný systém logicky je. Symptom: model má strukturu poplatnou cílové technologii, aniž je to kdekoli napsané.
• Neoznačená optimalizace. Optimalizace, která se z technologických důvodů dostala do Analytického modelu IS, ale není v něm výslovně označena. Viz Optimalizace patří do mapování výše.
• Záměna stejně znějících pojmů na obou stranách hranice. Týž název znamená v popisu okolí něco jiného než v Analytickém modelu IS. Podstatu popisuje Zrcadlení pojmů; uvádí se to zde proto, že právě na této hranici se ta chyba dělá nejčastěji.
• Osa jako plán projektu. Z osy se udělá postup, ve kterém se nejdřív dokončí analýza, pak návrh a pak kód. V AAF se osou prochází agilně a zpětná vazba jde oběma směry.

Vazby

Úrovně abstrakce jsou jedním ze dvou vymezení, na kterých stojí rozdělení analytické práce; druhým je Analytická dokumentace, která říká, co analytik odevzdává, kdežto tato kapitola říká, jak podrobný je popis. Hodnota Analytický model IS je totéž co LLA, viz Vrstvy HLA a LLA. Hranice mezi Analytickým modelem IS a Technologickým návrhem IS rozhoduje o řezu mezi Funkčním požadavkem a Nefunkčním a technologickým požadavkem, viz Zadávací dokumentace a její zpracování. Že doména systému může být sama technická, a že o zařazení pojmu tedy nerozhoduje zvuk slova, plyne ze Zrcadlení pojmů. Hranici vůči okolí systému drží Objektové paradigma; členění analytického modelu na vrstvy popisuje Architektura BPM-UCM-CLM.

Verze a změny

Verze	Změny
1.1	Ve Vazbách přejmenován Technologický požadavek na Nefunkční a technologický požadavek podle kapitoly Zadávací dokumentace a její zpracování ve verzi 4.0.
1.0	První verze kapitoly. Osa dostala vlastní domov; dosud byla popsána jako sekce Tři pracovní vrstvy systému uvnitř kapitoly Analytické modelování, tedy uvnitř jedné ze svých vlastních hodnot. Hodnoty přejmenovány z Analytické modelování (AM), Design (D) a Kódování (K) na Analytický model IS, Technologický návrh IS a Kód IS, tedy z činností na výsledky a s povinným dovětkem IS. Doplněno rozlišení výsledku od činnosti, pravidlo o pořadí slov v technologickém návrhu a sekce o tom, co na ose místo nemá. Mezi nejčastější chyby doplněn technicky znějící pojem vydaný za technologii. Převeden sem pojem Mapování s pěti pod-sekcemi a šest nejčastějších chyb z kapitoly Analytické modelování, vše přepsáno do nového pojmosloví.