Extrémně Efektivní Modelování (EFEM)

RNDr. Ilja Kraval, Object Consulting, http://www.objects.cz
publikováno na konferenci OBJEKTY 2002, Praha

Abstract. Příspěvek pojednává o novém přístupu k modelování a vývoji IS nazvaném “Extremely Effective Modeling” (tj. „Extrémně efektivní modelování“) se zkratkou EFEM. Tato technologie modelování je vytvořena na základě dlouholetých zkušeností autora v oboru konzultace a tvorby IS v oblasti OOP a UML. Hlavní smysl této technologie je výrazné urychlení a zprůhlednění tvorby SW při zachování požadovaných výstupů z projektu. Technologie se vyznačuje značnou jednoduchostí a snadnou dostupností spolu s maximální efektivitou vývoje. Příspěvek je výjimečný tím, že se jedná o první zmínku o této technologii tvorby SW v rámci dané problematiky. 

Co je Extrémně efektivní modelování (EFEM)?

Dva extrémní přístupy tvorby SW

Při konzultacích a při externí spolupráci s firmami, které zavádějí anebo chtějí zavádět OOP a UML, jsem se setkal se dvěma  extrémy, které se týkaly způsobu tvorby  SW.

První z přístupů je charakterizován tím, že na počátku projektu se vstupuje do černého tunelu, kterým se prochází „poslepu“ od stěny ke stěně, až se (možná) nalezne odpovídající světélko na jeho konci a možná se projekt zdárně ukončí. Charakteristiky tohoto přístupu jsou následující: 

 

·     chybí koncepce vývoje a není možná opakovatelnost dobrých výsledků

·     nemožná jakákoliv predikce v projektu

·     neexistence opakovatelných postupů (tj. obecná neznalost kdy má co kdo dělat)

·     nízká transparence výsledků (nelogičnosti, chyby, nepřehlednost)

·     vysoký stupeň chaosu ve vývoji

·     vznik softwarových slepenců, nedodělků    

·     vysoké nároky na operativní řízení

·     vysoká hektičnost prací (předělávky, zbytečná práce apod.) včetně nároků na volný čas apod.

·     nízká kvalita softwaru

·     nespokojenost zákazníka

·     špatné vztahy na pracovišti

 

Druhým extrémem je snaha zbavit se předešlých nedostatků přehnaně „perfekcionalistickým“ a současně netrpělivým způsobem. Tento opačný extrémní přístup je charakterizován následujícími body:

 

·     přehnaný optimismus ve změnách metodického řízení

·     snaha o zavedení postupů bez zkušeností s nimi, předjímání postupů

·     snaha o revoluční skoky ve změnách způsobů práce s následnými krachy při zavádění těchto postupů

·     zavádění byrokratických mašinérií do vývoje

·     tvorba zbytečných anebo zbytečně složitých dokumentů vývoje, zbytečná práce v dokumentaci (dokumentace pro dokumentaci)

·     pomalý vývoj a následná netrpělivost zákazníka

·     pomalá zpětná vazba ve výsledcích

·     nespokojený zákazník

·     špatné vztahy na pracovišti

Rational Unified Process (RUP) a Extrémně Efektivní Modelování (EFEM)

Je třeba podotknout, že již existuje určitý návod, jak se zbavit obou dvou extrémů, a to je zavést dobrý a kvalitní proces vývoje SW. Mezi takové kvalitní způsoby tvorby SW patří například Rational Unified Process (RUP) (viz http://www.rational.com, nebo http://www.unicorn.cz ). Zde jsou cíle přístupu RUP a Extrémně Efektivního Modelování (EFEM) totožné a znějí: Jak odstranit předešlé nedostatky obou zmíněných přístupů.

Snahou technologie Extrémně Efektivního Modelování je na základě praktických zkušeností zavést metodiky modelování a vývoje vyznačující se zejména tím, že sice stejně jako RUP odstraňují uvedené nedostatky obou chybných postupů, ale navíc se EFEM vyznačuje těmito body:

 

·     extrémně vysoká efektivita vývoje při zachování požadavků na požadovanou dokumentaci

·     mnohem vyšší jednoduchost, vyšší stupeň logiky a tedy vyšší transparence jak artefaktů vývoje, tak postupů prací

·     přenositelnost a implementační kompatibilita nejenom výsledků vývoje, ale i samotného EFEM mezi CASE nástroji, tj. implementační přenositelnost technologie

·     aplikovatelnost principů EFEM na sebe sama, tj. na samotné zavádění EFEM. Principy EFEM se nevztahují pouze na způsob tvorby SW, ale jsou aplikovány i na způsob zavádění EFEM. Tato skutečnost výrazně zjednodušuje zavedení této technologie do firmy

·     jako důsledek předešlého bodu: Snadnost zavedení EFEM ve firmách

 

Požadavek aplikovatelnosti EFEM sama na sebe má principielní charakter. Jinak složitý proces zavádění technologie podléhá v tomto případě stejným již jednou přijatým principům EFEM. Stačí jednou tyto principy přijmout obecně a uplatnit je i pro zavádění technologie. Poté se postup zavádění těchto principů také pro tvorbu SW stává jednoduchý, logicky transparentní a kvalitně řízený.

Principy Extrémně Efektivního Modelování

Jedna ze základních myšlenek technologie Extrémně Efektivního Modelování spočívá v  zavedení několika jednoduchých zásad a principů, kterými se tato technologie řídí. Tyto „axiomy“, i když na první pohled znějí teoreticky, jsou dále rozvinuty do vysoce praktických důsledků, které vedou k extrémně efektivnímu způsobu modelování a vývoje IS.

Jak bylo řečeno v předešlé kapitole, důležitou vlastností EFEM je, že principy se netýkají pouze způsobu tvorby SW, ale že jsou aplikovány i na způsob zavádění samotného EFEM. Znamená to, že samotný proces zavádění této technologie podléhá stejným zákonům a pravidlům, které stanovuje samo EFEM pro tvorbu SW.

Principy (axiomy) Extrémně Efektivního Modelování lze shrnout do těchto bodů:

 

1.   princip maximální opětovné použitelnosti

2.   princip modelování v abstraktních úrovních s notací v UML s extrémně rychlou zpětnou vazbou

3.   princip kompatibility technologie pro různá modelovací prostředí a implementační přenositelnost do jiného modelovacího prostředí (tj. nejen logická a syntaktická, ale i implementační nezávislost na vývojovém, tj. modelovacím prostředí). 

 

Praktickými důsledky těchto tří bodů jsou výhody uvedené v předešlé kapitole, zejména extrémně rychlá tvorba SW při zachování kvality.

Princip maximální opětovné použitelnosti (maximálního re-use)

Jedná se o jednoduchý základní axiom Extrémně Efektivního Modelování a jeho důsledky se linou celou technologií. Pod opětovnou použitelností, kterou budeme nazývat také jako re-use, máme na mysli následující situaci:

Představme si, že existuje výskyt nějaké (libovolné) informace A a existuje výskyt nějaké (libovolné) informace B. Zjistíme, že ve výskytu informaci A se vyskytuje prvek, který se vyskytuje i v B, označme tento opakující se prvek jako C (viz obrázek 1):

 

 

obrázek 1 Situace vedoucí k opětovné použitelnosti (re-use)

 

Vytvoří se nový prvek jako interakce mezi prvky A, B, C. Prvek C se „vytkne“ mimo oba prvky A, B a touto interakcí se prováže zpět do bodů, ze kterých byl vytknut (vznikne obdoba odkazu). Výsledkem je následující situace (viz obrázek 2):

 

obrázek 2 Situace po interakci zavádějící opětovnou použitelnost

 

Zavedení opětovné použitelnosti není v žádném případě novinkou a je obecným a dobře známým jevem v programování a obecněji v modelování SW. Můžeme namátkou jmenovat následující příklady: volání funkcí ve strukturálním programování, normalizace databáze, dědění a jiné interakce mezi třídami (např. asociace), obecně interakce mezi prvky modelu v UML, kdy jeden prvek používá druhý prvek (include a extends mezi případy užití apod.) aj.

Zavedený princip maximální opětovné použitelnosti zní v tomto případě tak, že je třeba prioritně vždy zavádět opětovnou použitelnost, tj. prvky A, B, C mohou být cokoli, čeho se může náš problém týkat. Nemusí to být pouze vývoj SW, ale například metodiky firmy, tvorba dokumentace apod. Jedná se o „návod“ aplikovatelný na vše, co je třeba řešit, včetně zavádění EFEM do firmy, tvorby dokumentace apod. Princip maximální opětovné použitelnosti doporučuje následující: „Obrázek 1 je považován za indikaci chyby. Co se opakuje, netvořte dvakrát, ale odkazujte se, a platí to pro libovolnou situaci, kterou řešíte.“

Rozdíl mezi známou opětovnou použitelností a tímto principem maximální opětovné použitelnosti je v tom, že uvedený princip něco vyžaduje a tím zavádí postupy , tj. ukazuje na to, co není provedeno a co se má provést. Samotná opětovná použitelnost nemusí být obecně vyžadována.

Prvky v interakci opětovné použitelnosti mohou být opravdu „cokoliv“, tj. vše, co vyžaduje opětovnou použitelnost. Mohou jimi být (a měly by být) samozřejmě  prvky modelu SW, tj. prvky vyvíjeného SW, a to až po kód. Navíc však tomuto principu maximální opětovné použitelnosti podléhají například také postupy ve firmě, dokumentace projektu, zavádění vzorů, opakování postupů při designu apod. Princip maximálního re-use přikazuje opakující se postupy nějak vytknout a opětovně je použít, což vede k zavedení postupek, k tvorbě návodek, k zavedení návrhových vzorů, apod. Současně se vyžaduje, aby tyto dokumenty (metodiky, vzory apod.) samy mezi sebou dodržovaly princip maximální opětovné použitelnosti, tj. aby se mezi sebou odkazovaly a propojovaly tak, aby nedocházelo k opakování částí dokumentů, ale naopak se tvořily interakce opětovné použitelnosti mezi nimi.

Nedodržení principu maximální opětovné použitelnosti vede k následujícím nepříjemným efektům:

 

·     opakování prací (při vývoji, při tvorbě dokumentace, při tvorbě  metodik apod.) a jako důsledek následuje ztráta efektivity

·     opakování oprav při změnách (což je podobné jako předešlý bod, ale v jiné fázi tvorby a údržby SW) 

·     ztráta transparence řešení, což je nejnepříjemnější důsledek. Díky nedodržení principu maximální opětovné použitelnosti se některé věci opakují několikrát a to „bůhví kde“. Věci nejsou na svých logických místech, kde by se měly nacházet. Dokumentace je obtížnější, je nelogická a navíc mnohem více pracná. Hledání všech opakujících se změn je neúnosně zdlouhavé, systém se stává zbytečně složitý a nepřehledný, v důsledku více chybový. K největší ztrátě efektivity nastává právě díky efektu ztráty transparence.

Princip modelování v abstraktních úrovních s notací v UML s extrémně rychlou zpětnou vazbou

Dalším principem Extrémně Efektivního Modelování je princip modelování v abstraktních úrovních s notací v UML s extrémně rychlou zpětnou vazbou. Technologie EFEM zavádí jako povinné tři základní úrovně abstrakce (tyto úrovně vychází z mnohem většího výčtu abstraktních úrovní definovaných normami ISO) :

 

·     analytické modelování

·     modelování návrhu

·     kód, implementace

Analytické modelování

Analytické modelování (také se nazývá analýza) v EFEM odpovídá již zmíněné definované abstraktní úrovni zavedené v normách ISO. V pohledu analýzy se vytvářejí modely IS na nejvyšší úrovni abstrakce. Modely analýzy podchycují vyvíjený systém v pohledu pouze konceptů (pojmů) a jejich spolupráce (nikoliv z pohledu technologie vývojového prostředí). Na této abstraktní úrovni se pohybují všichni členové projektu, kteří hovoří pouze o funkcionalitě systému (například uživatel, zákazník, obchodník, tester funkcionality apod.). Základní otázkami analýzy jsou „co to umí“, „co se eviduje“, „kolik bude nějakých evidovaných výskytů“, „jaká je skladba pojmů“ apod. Nehovoří se však o tom, jak konkrétně budou v dané technologii (programovacím jazyce, databázi apod.)  prvky systému navrženy.

Technologie Extrémně Efektivního Modelování doplňuje tyto známé a obecné požadavky o konkrétní syntaxi a postupy s vysoce efektivním přístupem s použitím maximální opětovné použitelnosti. Těžiště analytického modelování v EFEM spočívá následujících dvou dokumentech:

 

·     Abstract Conceptual User Guide (abstraktní pojmová příručka uživatele)

·     Abstract Conceptual Dictionary (abstraktní pojmový slovník) 

 

Dokumenty používají univerzální notaci UML, takže přebírají plně syntaxi UML s tím, že rozvíjejí některé prvky modelů pomocí extenzí, které jsou povolené v UML (stereotyp, tagged value, apod.).

Abstract Conceptual User Guide lze přirovnat k „dopředu psané příručce uživatele“ tvořené na abstraktní konceptuální úrovni. Na rozdíl od klasických postupů tvorby IS, kdy se uživatelská příručka píše až „ex post“ po programování, je tato příručka psána „ještě před realizací v kódu“. Vychází se z jednoduchého logického předpokladu, že pokud je jako výsledek analýzy známo, co se má naprogramovat, je možné již v této fázi pracovat na „knize pro uživatele“ s popisem jednotlivých funkcionalit systému, tj. vytvořit detailní pohled z hlediska užití systému.

Dokument Abstract Conceptual User Guide využívá UML syntaxi, konkrétně  USE CASE MODEL pro popis případů užití uživatelem. Na rozdíl od obecných doporučení  se však jedná o více podrobný popis systému. (Pozn.: Prvky tohoto modelu odpovídají povaze tzv. USER STORY zavedeném v extrémním programování).  Dokument může být doplněn o ACTIVITY MODEL pro nalezení dekompozice procesů podniku, ale pouze těch procesů, které jsou podporované IS.

Výhodou tohoto přístupu je zejména možnost seznámit se se  systémem velmi přehledně a podrobně ještě v době raných fází jeho realizace. Navíc tento dokument je bohatě opětovně použit i v jiných částech projektu, protože je velmi srozumitelný. Stává se zdrojem pro tvorbu dokumentů pro obchodníky, pro testery, pro přílohy smluv se zákazníkem apod.

Druhý dokument, Abstract Conceptual Dictionary, se používá pro zavedení konceptů neboli pojmů v analytickém modelování. Pojmy se chápou jako informace, které je třeba evidovat a pracovat s nimi. Informace v IS se vyskytují ve dvou meta-úrovních:

·     pojem jako třída informace (tj. typ informace)

·     výskyt pojmu, tj. výskyt informace (tj. instance typů informace). 

 

Dokument Abstract Conceptual Dictionary používá syntaxi UML v těchto modelech:

 

·     CLASS MODEL. Jednotlivé třídy modelu odpovídají abstraktním pojmům (typům informace), interakce mezi třídami v modelu odpovídají interakcím mezi pojmy.

·     INSTANCE MODEL neboli OBJECT MODEL (přesněji řečeno v UML se jedná o COLLABORATION MODEL bez zavedení zpráv). Jedná se o doplňkový a z CLASS MODELU odvoditelný model. Vyjadřuje vztahy mezi instancemi informace. Instance v OBJECT MODELU a také vztahy mezi nimi (tzv. links) v tomto modelu musí odpovídat vztahům a typům informací v CLASS MODELU.

 

Dokument Abstract Conceptual Dictionary definuje nejenom pojmy, ale i vztahy mezi nimi. Používá k tomu následující možné interakce mezi pojmy (mezi abstraktními koncepty):

 

·     kompozice (také silná agregace)

·     slabá agregace (také sdílená agregace)

·     běžná asociace

·     asociativní třída

·     generalizace – specializace

 

Názvy těchto interakcí odpovídají přesně zavedené syntaxi interakcí mezi třídami v UML (bez extenzí) s výjimkou běžné asociace. Ta sice v UML není explicitně definována, ale existuje. Jedná se o asociaci (prvek metamodelu UML Association), jejíž ani jeden konec (prvek metamodelu Association End) není označen jako celek versus část. Jinak řečeno, běžná asociace zavedená v EFEM je v UML asociací, která není agregací.

Pro tvorbu dokumentu Abstract Conceptual Dictionary je také důležitá tvorba svazků (balíků), čemuž v UML odpovídající elementy Package. Pomocí tohoto přístupu se systém vrství již na logické, tj. konceptuální úrovni, což jednak zvyšuje transparenci systému již na logické úrovni, ale stává se podkladem pro kvalitní architekturu komponentní technologie.

Kromě těchto dvou základních dokumentů lze v analytickém modelování jako doplňkové a podpůrné modely z UML použít ve standardní syntaxi: SEQUENCE MODEL, COLLABORATION MODEL, STATE CHART MODEL a ACTIVITY MODEL. Tyto modely se používají „navíc“ oproti předešlým dvěma dokumentům a to hlavně ve specifických a složitých situacích vyžadujících zvláštní pozornost. Těžiště a cíl je však v uvedených dvou dokumentech  Abstract Conceptual User Guide a Abstract Conceptual Dictionary.

Jedním z důsledků použití principu maximální opětovné použitelnosti je metoda tvorby modelů IS v analýze zásadně přes odkaz do centrálních knihoven.  Znamená to, že prvky modelů, ze kterých se skládá daný IS, nejsou komponovány přímo do tohoto dokumentu, ale zásadně se skládají (jsou odkazem vyjmuty a zpětně přeneseny) z odpovídajících prvků knihoven. To vede k re-use  i mezi projekty a vznikají tak firemní knihovny modelů.

Modelování návrhu

Přechod z abstraktní úrovně analytického modelování do úrovně designu se také nazývá mapování do designu. Na základě výsledků analytického modelování se vytváří návrh „jak bude systém konkrétně navržen“. Při tomto mapování EFEM dodržuje tyto zásady:

·     dodržuje se extrémně rychlý iterativní a inkrementální postup s velmi rychlými výstupy až do kódu (jedna iterace řádově dny, resp. týdny)

·     princip re-use vede k tvorbě designu pomocí neustále zdokonalovaného katalogu designu obsahujícím obecné vzory a obecné postupy mapování. Znamená to, že řešení pro daný projekt se tvoří zásadně způsobem odkazu „mapování řešeno podle vzoru XY s těmito rolemi vzoru“ a nikoliv jako samostatně stojící řešení (poznámka: tj. i jinak unikátní řešení je zavedeno do katalogu a je na ně proveden pouze jeden odkaz)

 

Mapování do designu v EFEM díky uvedeným bodům vykazuje několik velmi kladných rysů:

·     extrémní rychlost

·     opětovná použitelnost, jednotnost postupů mapování při opakování těchto postupů, dobrá znalost těchto postupů a jejich transparence

·     jednoduše tvořená dokumentace díky odkazům na opakované postupy v katalogu, těžiště dokumentace se provádí pouze jednou, v katalogu

Princip kompatibility technologie pro různá modelovací prostředí a implementační přenositelnost EFEM do jiného modelovacího prostředí

Jako další princip EFEM lze uvést zásadu jeho vnitřní architektury skladby všech jeho dokumentů, která vede k přenositelnosti samotného EFEM na různé nástroje (různá modelovací prostředí). Obecně se unifikace modelování softwaru projevuje ve dvou základních rysech:

 

1.        Samo UML je standard

2.        Navíc existuje standard dokumentů XML pro modely UML, tj. standardní pravidla  XML Metadata Interchange (XMI) pro UML

 

Tyto dva standardy poskytují zásadní možnost „výměny“ modelů mezi dvěma různými nástroji, pokud oba nástroje tyto dva standardy dodržují.

Myšlenka EFEM jde však trochu dále. Nejedná se již o otázku možné  technické přenositelnosti nějakého konkrétního modelu z jednoho nástroje do druhého, tj. nejedná se pouze o zavedení kompatibility mezi modelovacími nástroji. EFEM zavádí samostatnou vrstvu dat modelů IS a jeho prvků, která je oddělená od modelovacích nástrojů. Nazvěme tuto vrstvu dat jako Common EFEM Data. Tato vrstva má povahu XML dokumentů. V této vrstvě se pomocí pravidel XMI pro UML a dalších vlastních pravidel ukládají jednak artefakty vývoje jako XML dokumenty a také jiné pomocné dokumenty (vzory, návodky apod.). S touto vrstvou komunikují jak vlastní pomocné utility této vrstvy, tak přes tyto utility jednotlivé nástroje, které splňují oba zmíněné standardy. Výsledkem této architektury je situace, kdy se jednotlivé modelovací nástroje stávají „prostředníkem“ pro práci s Common EFEM Data vrstvou. Pracuje se tak nad jednou vrstvou s různými nástroji. Tuto architekturu znázorňuje následující obrázek:

 

obrázek 3 Architektura EFEM

 

Například přiložení části modelu pomocí modelovacího nástroje X může vypadat takto:

 

1.   Uživatel vytvoří část modelu v daném nástroji X

2.   Uloží vytvořenou část do XML formátu

3.   Spustí odpovídající utilitu (např. se použije XSL)

4.   Uvedená část modelu se začlení do Common EFEM Data vrstvy spolu s nutnými doprovodnými údaji

 

Soubory vzniklé při uložení modelu z daného nástroje X do XML formátu (viz bod 2 předešlého postupu) jsou pouze „mezivýsledky“, které se teprve zpracují pro začlenění do společné vrstvy. Podobným způsobem (ale v opačném pořadí) lze například provést „export dat“ do nějakého nástroje a prohlédnout si část modelu zapsaného v Common EFEM Data vrstvě. 

Výhoda tohoto přístupu je zřejmá. Již nehovoříme o pouhé „přenositelnosti“ dokumentů modelů mezi sebou. Protože dokumenty jsou „jednotně a jednou“ uloženy v Common EFEM Data vrstvě, hovoříme pouze o interpretaci této vrstvy pomocí různých modelovacích nástrojů. Navíc lze vhodně rozšířit možnosti postupů ve vývoji díky rozšíření této společné vrstvy o další velmi vhodné prvky a vazby k nim (např. vztah ke vzorům, návodkám, dokumentaci apod.) a pracovat s nimi pomocí vrstvy samostatných utilit. Modelovací nástroje se takto dostávají do stejné pozice jako například vývojová prostředí pro přenositelné jazyky (např. technologie DOT NET) s podobnou, ale nikoliv totožnou syntaxí, a které vytváří jako výsledek dohodnutý výsledný kód. V EFEM lze modelovací nástroje spolu s odpovídajícími utilitami tak trochu s nadsázkou přirovnat k „editorům a kompilátorům“ pro tvorbu prvků v Common EFEM Data vrstvě.

Závěr

Cílem příspěvku bylo předložit základní principy nově vznikající technologie tvorby IS nazvané Extrémně Efektivní Modelování (EFEM) a poukázat na její výhody.

V současné době se na vývoji dané technologii pracuje a v nejbližší době se předpokládá vydání první e-knihy na toto téma.

Současně se vyvíjejí možnosti začlenění prvních jednoduchých a hlavně cenově dostupných vývojových nástrojů do technologie EFEM tak, aby se nabídla možnost tuto technologii prakticky používat. První výstupy se předpokládají v prvním čtvrtletí příštího roku.