Architektura BPM-UCM-CLM¶

Úvod¶

Tato kapitola zavádí Architekturu BPM-UCM-CLM jako nosnou architekturu AAF — propojenou trojici modelových vrstev (Business Process Model, Use Case Model, Class Model), která dohromady reprezentuje analytický model informačního systému jako celku.

Historicky se v analytickém modelování pracovalo s jednotlivými modely odděleně: BPM jako procesní pohled na okolí, UCM jako pohled na užitek systému, Class Model jako pohled na evidované pojmy. AAF tyto tři modely sjednocuje do jediné architektury, jejíž zásadní vlastností je konzistence všech tří vrstev v čase.

Logická posloupnost, kterou se architektura odvíjí z axiomu Value Based Management (VBM):

Axiom VBM stanoví, že hodnota užitku systému očekávaná zákazníkem se nesmí během vývoje ztratit.
Užitek systému nese Use Case 1. druhu, tedy UCM jako primární nositel hodnoty.
Bezprostřední pracné vyhledávání Use Case bez kontextu okolí vede do pasti Waterfall — nelze najít Use Case bez znalosti dějů v okolí.
Vyhledávání Use Case ze známých dějů okolí vede k modelování okolí přes procesy — vzniká BPM. Pro zachování agility se v AAF tvoří BPM přesně definovaným postupem od prioritních procesů po tzv. tanečky okolo.
Use Case obsahuje vnitřní scénář, který používá pojmy a vztahy mezi nimi. Tyto pojmy musí být v modelu pojmů, tedy v CLM.
Vzniká architektura BPM-UCM-CLM s povinnou konzistencí všech tří vrstev v čase. Mechanismus, který tuto konzistenci udržuje při příchodu nového požadavku, je Stroj konzistence AAF (viz dále).

Architektura BPM-UCM-CLM¶

Architektura BPM-UCM-CLM je trojice modelových vrstev, které dohromady popisují analytický model informačního systému jako celku. Vrstvy jsou propojené po sousedství a v čase vzájemně konzistentní.

BPM¶

BPM (Business Process Model) je modelová vrstva, jejímž předmětem je okolí informačního systému. BPM modeluje, co se v okolí systému děje a jak se okolí chová, a kdy a kde se použije informační systém (volání UC).

BPM určuje mantinely řešení zvenku — hranice okolí v podniku, ve kterém systém působí. Není to model toho, co dělá systém, ale toho, co dělá okolí, které systém používá.

Příklad: u systému evidence faktur BPM popisuje, jak v podniku přichází faktura, kdo a kdy ji potřebuje zaevidovat, jak proces běží mezi rolemi v podniku. BPM nepopisuje, co dělá vrátný, který s evidencí faktur nesouvisí — leží mimo mantinely BPM tohoto systému.

BPM se vyjadřuje syntaxí BPMN AAF Lite (viz kapitola BPMN AAF Lite Syntaxe, viz dále).

UCM¶

UCM (Use Case Model) je modelová vrstva, jejímž předmětem je užitek systému vůči okolí. UCM popisuje, k jakému užitku se systém použije, když okolí dosáhne bodu potřebnosti použití systému (alias cinknutí systému, viz kapitola Use Case 1. druhu).

UCM je most mezi HLA a LLA. Vnější pohled na Use Case 1. druhu (užitek vůči okolí) patří do HLA a navazuje na BPM. Vnitřní pohled na Use Case 1. druhu (scénář implementace) patří do LLA a navazuje na CLM. Princip duálního pohledu vychází z Objektového paradigmatu — element viděný zvenku (jak se použije) a zevnitř (jak je realizován).

Scénář uvnitř Use Case 1. druhu popisuje logickou implementaci daného UC a používá logické pojmy a vztahy z CLM. UCM tak logickým scénářem otevírá vstup do CLM (např. Obsluze se zobrazí seznam prvků Faktura)

CLM¶

CLM (Class Model) je modelová vrstva, jejímž předmětem jsou evidované pojmy informačního systému a vztahy mezi nimi. CLM popisuje, co systém eviduje a jakou skladbu evidence má.

V AAF se používají synonyma:

CLM = Class Model = analytický Class Model — evidované pojmy (při komunikaci s PO).

CLM obsahuje pojmy, které se vyskytují v scénářích Use Case 1. druhu. S čím scénář v UCM pracuje jako s instancí (pojmem), pro to musí existovat třída v CLM. Tím je dána konzistence UCM ↔ CLM. Příklad: „Obsluze se zobrazí seznam faktur" — instance ze třídy Faktura z CLM.

Detail syntaxe CLM viz kapitola Class Model AAF Lite Syntaxe (viz dále). Pozice CLM v rámci analytického modelování viz kapitola Analytické modelování.

Konzistence vrstev v čase¶

Tři vrstvy BPM, UCM a CLM musí být v každém okamžiku vývoje vzájemně konzistentní. Konzistencí se rozumí:

BPM ↔ UCM — každý Use Case 1. druhu má v BPM identifikovaný bod, ve kterém okolí systém potřebuje použít (cinknutí systému).
UCM ↔ CLM — každý pojem nebo vztah použitý ve scénáři Use Case 1. druhu je zaveden v CLM.
V čase — při změně v kterékoli vrstvě se posoudí dopad na ostatní vrstvy a změny se promítnou před realizací.

Tato vlastnost je přímým důsledkem axiomu VBM. Když kterákoli vrstva přestane být konzistentní s ostatními, ztrácí se souvislosti v částech modelu systému a s nimi část očekávané hodnoty.

Mechanismus, který tuto konzistenci aktivně udržuje při příchodu nového požadavku, je Stroj konzistence AAF. Stroj konzistence AAF posoudí, jak nový požadavek zapadne do architektury BPM-UCM-CLM, a navrhne změny v jednotlivých vrstvách před tím, než se přejde k realizaci. Operativní detail popisuje samostatná kapitola Stroj konzistence AAF (viz dále).

Rozlišující znaky¶

Architektura BPM-UCM-CLM je správně zavedena, pokud splňuje následující znaky.

Obsahuje právě tři vrstvy: BPM, UCM a CLM. Žádná další vrstva (technologický návrh, kódování) do architektury BPM-UCM-CLM nepatří — leží v jiném směru, na nižších úrovních abstrakce, viz kapitola Analytické modelování.

Vrstvy jsou propojené po sousedství. BPM se napojuje na UCM přes cinknutí systému, UCM se napojuje na CLM přes scénář Use Case 1. druhu. Přímá vazba BPM ↔ CLM architekturou definovaná není — vede se vždy přes UCM. Existuje nepřímá vazba mezi evidovanými pojmy (třída Faktura jako evidovaný pojem) a prvkem v BPM (reálná faktura v okolí, papír, PDF). Toto homonymum vede k častým chybám záměnou pojmů „evidovaný pojem" uvnitř versus prvek mimo systém (viz Nejčastější chyby).

Vrstvy jsou v čase konzistentní. Při změně requirementu se konzistence aktivně udržuje Strojem konzistence AAF.

Nejčastější chyby¶

Nejčastější chybou je záměna vrstev architektury s úrovněmi abstrakce informačního systému. BPM, UCM a CLM jsou tři modelové vrstvy na téže úrovni analytického modelování. Úrovně abstrakce (analytické modelování / modelování designu / kódování) jdou kolmým směrem — od logiky k implementaci. Záměna obou os vede k pojmovému zmatku.

Druhou typickou chybou je psaní scénáře Use Case 1. druhu s pojmy, které nejsou v CLM. Scénář v UCM zavede pojem, který v Class Modelu neexistuje a nikdo neví, kde se vzal. Architektura se tím rozpadá. Pravidlo: každý pojem ve scénáři je dohledatelný v CLM.

Třetí typickou chybou je porušení konzistence vztahu BPM ↔ UCM, které vzniká ve dvou symetrických scénářích:

UCM bez BPM — vyhledávání Use Case 1. druhu bez znalosti dějů v okolí. Bez kontextu BPM nemá analytik kotvu, kde a kdy se systém použije, a vznikají Use Case typu „Klikni na tlačítko" — chyba střípkování (viz kapitola Use Case 1. druhu).
BPM bez UCM — tvorba BPM v plné šíři bez paralelně rostoucího UCM. Bez zpětné vazby z UCM se BPM tvoří „naprázdno": detaily, které UCM potřebuje, nebyly v BPM zachyceny, a detaily, které UCM nepotřebuje, jsou v BPM nadbytečně. Důsledkem je opakované předělávání BPM podle potřeb UCM. AAF tomu předchází agilním postupem — BPM a UCM rostou souběžně (viz kapitoly Agilní postup HLA, AAF agilní přístup — Increments Widening).

Čtvrtou chybou je provedení změny v jedné vrstvě bez posouzení dopadu na ostatní. Změna v BPM, která nepromítne důsledky do UCM a CLM, rozjede architekturu z konzistentního stavu. Proto existuje Stroj konzistence AAF (viz dále).

Vazby¶

Architektura BPM-UCM-CLM stojí na axiomu Value Based Management (VBM) — VBM stanoví požadavek udržení hodnoty užitku systému v čase, BPM-UCM-CLM je modelový aparát, kterým se tato hodnota udržuje.

Architektura konceptuálně vychází z Objektového paradigmatu, které zavádí duální pohled (vnější × vnitřní) na element. Duální pohled se v architektuře projevuje na úrovni UCM — Use Case 1. druhu je viděn zvenku (užitek v BPM) i zevnitř (scénář pracující s CLM).

Most mezi vrstvami HLA a LLA realizuje Use Case 1. druhu. Detail vztahu HLA a LLA viz kapitola Vrstvy HLA a LLA.

Vrstvy architektury se detailně popisují v samostatných kapitolách: BPM v BPMN AAF Lite Syntaxe (viz dále), UCM v Use Case 1. druhu a v UCM a Scenario Patterns / UC 2. druhu (viz dále), CLM v Slovník evidovaných pojmů, Class Model AAF Lite Syntaxe a Dichotomie třída-instance (viz dále). Pozice architektury v rámci analytického modelování viz kapitola Analytické modelování.

Udržení konzistence při příchodu nového požadavku popisuje samostatná kapitola Stroj konzistence AAF (viz dále).

Verze a změny¶

1.0 — Early Access.