JAK skloubit nasazení UML s rychlými agilními technikami?

autor: RNDr. Ilja Kraval, září 2011

Object Consulting s.r.o.

Server objektových technologií

http://www.objects.cz

Při rozhovorech s vývojáři navrhujícími IS jsem občas zaslechl tuto připomínku: „UML je sice pěkná věc, ale hrozně zpomaluje vývoj. Kdybychom měli navrhovat IS pomocí UML, tak nás buď konkurence předběhne anebo zákazník od nás uteče. Jsme si to vyzkoušeli a víme, o čem mluvíme…“

Je pravdou, že nasazení UML v sobě skrývá různá úskalí spočívající v možném zpomalení vývoje a těmto úskalím je třeba se vyhnout. Pokud tak neučiníme, můžeme se dostat do problémů, o kterých se zmiňuje předešlý odstavec. Jako zkušenost mohu uvést, že když jsem si s těmito vývojáři následně prošel jejich modely v UML, které zpomalily vývoj, tak jsem musel konstatovat, že „takto se UML nemá používat a že v tom je jádro pudla zpomalení vývoje.“

Problém zpomalení vývoje není v samotném UML, ale ve způsobu jeho nasazení.

Jednou z obrovských výhod nasazení UML při návrhu IS je vyřešení základní a principielní otázky návrhu IS, kterou je tzv. „zohlednění úrovní abstrakce“. (viz například kniha Analytické modelování pomocí UML v praxi, ke stažení zde). Tento problém se považuje za původce kritických a fatálních problémů vývoje SW.

Uvedený jev se také nazývá tak trochu akademicky jako „problém překlenutí sémantické mezery“. Sémantická mezera (tj. jinak řečeno „mezera ve vyjadřování“) spočívá v tom, že zákazník a ostatní účastníci projektu vidí IS v jeho analyticky čisté sémantice, ale (bohužel) tato čistá logika se následně v designu a následně v kódu doslova rozplyne, rozpustí a ztratí. Překlenutí sémantické mezery není nic jiného, než průchod úrovněmi abstrakce od čistého logického analytického modelování přes méně přehledný design až po složitý kód.

Hlavními důvody ztráty čisté logické transparence v designu a kódu jsou tyto:

·        Jsou zavedeny nutné a technologií vynucené kroky jdoucí proti principu re-use, těmi jsou různé optimalizace pro získání rychlosti apod. (například rozpuštění entit, přidání pomocných atributů pro urychlení výpočtů apod.). Tyto kroky vedou k tomu, že některé původní entity v designu zmizí, resp. objevují se jiné, nové, které nepocházejí ze samotné logiky, ale z nutnosti použité technologie.

·        Nasazení samotné technologie je složité, stejně tak kód, musí se zavést pomocné služební objekty, atd. To vše zakrývá čistou logickou esenci, protože již není patrné, co pochází z designu a co z čisté logiky problému.

·        Je zřejmé, že začíná platit úplně jiná sémantika na úrovni logiky analytického modelu, na úrovni designu a na úrovni kódování.    

Měl jsem možnost projít desítky firem v ČR a v SK a statistika je neúprosná:

Firmy, které nedbají na dodržení úrovní abstrakce, mají neskonalé problémy jak s návrhem IS, tak ještě více následně s jeho údržbou.   

Řešení spočívá v efektivním nasazení modelovacích technik pomocí UML.  

Nejprve se zavedou „logické entity“ ve fázi analytického modelování, které se následně stávají zadáním pro design. Dodržení této zásady splňuje zásadu postupu Domain Driven Development, tedy zásadu, že nejprve zavádíme „analytické doménové entity“ a teprve poté navrhujeme technologický návrh.

Je vcelku pochopitelné, že zavedení kroku analytického modelování je oproti samotnému kódování nebo návrhu technologie krokem navíc a je otázkou, do jaké míry takovýto „nutný krok navíc“ zpomalí vývoj. 

Zde bych se zmínil o první a zásadní chybě, kterou můžeme při nasazení UML ve firmě tak říkajíc spáchat:

Zásadní chybou návrhu IS pomocí UML je tvorba zbytečností v diagramu (lidově řečeno „tvorba nepotřebných serepetiček“) nebo dokonce tvorba zbytečných modelů. Obecně řečeno dochází k „modelování balastu“. Nad takovýmto modely programátor jenom skřípe zuby, protože mu nic nepřinášejí.

Při zavádění UML mějme na paměti jeden z hlavních důvodů, proč UML zavádíme, a tím je usnadnění průchodu úrovněmi abstrakce. Smyslem analytického modelu je napomoci kódování a současně nám tento model poskytuje jako druhotný produkt možný pohled na systém určený pro zákazníka.

Model nemá být zbytečně „užvaněný“ a nemá sdělovat spoustu již známých, patrných a tedy nepotřebných myšlenek. Model není nic okrasného a nemá za úkol pouze zapůsobit jako obrázek na čtenáře (i když z obchodního hlediska jsou hezké obrázky předložené zákazníkovi vždy přínosem).

Držte se zásady, že návrh modelu v UML je vždy obdobou jasného a zřetelného programování, ale v jazyce UML!

Pokud se vyhneme první chybě „balastu a zbytečností v modelu“, vyvstane při průchodu úrovněmi abstrakce druhý následný problém:

Jak vlastně provést efektivní průchod úrovněmi abstrakce od modelu analytického až do kódu? Vždyť je tam spousta práce navíc!

Zde se držme druhé zásady:

Vše, co lze při průchodu úrovněmi abstrakce automatizovat, automatizujte!

V podstatě se jedná o radu, abychom používali vhodný CASE nástroj (například Enterpirse Architect) a abychom pokud možno vytvářeli co nejvíce pomocných utilit, které efektivně podporují tento průchod úrovněmi abstrakce.  

Z hlediska teorie modelování se v podstatě se jedná o nasazení technologie MDA (Model Driven Architecture), též se nazývá jako Model Driven Development (což se mi jako název líbí více), a postupů MDG (Model Driven Generation). Podstata práce těchto utilit spočívá v tom, že tyto programy jsou schopny pomocí nastavitelných a konfigurovatelných parametrů přetransformovat daný logický model přes design (MDA) až do částí požadovaného zdrojového kódu (MDG).

Daný analytický model se tak stává přímo obrazem„budoucího kódu“.

Současně s těmito utilitami se doporučuje nasadit některou z vhodných technologií ORM (Object Relational Mapping), jako jsou například Hibernate (pro JAVU), NHibernate (pro C# - Open Source), Entity Framework (pro C# - oficiální technologie od Microsoftu) anebo Doctrine (pro PHP).     

Návrh IS tímto získává novou kvalitu: Sama čistá logická esence znázorněná v analytickém modelu se současně stává předobrazem budoucího kódu. K transformaci modelu nedochází ručním napsáním kódu, ale nastavováním parametrů v daných utilitách a vhodným označkováním prvků v modelu.

Dochází tak ke kýženému stavu návrhu: Přechod od analytického modelu je po nastavení parametrů transformace a označkování prvků v modelu deterministicky reprodukovatelný a to dokonce „pouhým jedním stiskem tlačítka“. Vzniká tak nakódované jádro aplikace, které není programováno ručně, ale je generováno včetně databáze a základních SQL příkazů.

Poznámka: Uvedený přechod od čistého analytického modelu do kódu velmi silně připomíná kompilaci kódu, která je také přechodem „napsaným zdrojovým kódem“ a „chodícím kódem“. Současně se však musí nastavit podmínky přechodu a označkovat si prvky, velmi podobně jako v programování u kompilačních direktiv („compiler directives“).

Další možné zpomalení vývoje při nasazení UML hrozí v použití nevhodných metodik, tedy v postupech prací. V mnoha firmách bývá UML chybně nasazeno pomocí metodiky zvané „Vodopád“ takto:

Metodika Vodopád: Nejprve se vytvoří analýza velké části systému, následně se tato velká část navrhne technologicky a následně nakóduje. To je samozřejmě z hlediska rychlých agilních technik úplně špatně.

Je zřejmé, že by se i při použití UML žádalo nasadit některou z agilních technik, například SCRUM. Jenomže při jejich zavedení u středních nebo větších IS musíme vyřešit tento základní problém:

Nestačí pouze zavést tzv. hromadu požadavků (tzv. BackLog ve SCRUMU), ze kterého se mají brát různé itemy k řešení, ale musíme také najít přesné pravidlo „od jakých požadavků začít a kudy poté pokračovat“.  Tato volba a tvorba požadavků je u středních a větších IS paradoxně také součástí vývoje!

Problém je v tom, že pokud nezavedeme pravidlo jak hledat tyto „hlavní funkčnosti“ a jak hledat „ty další“ a obecně „jak dále postupovat“, můžeme se u středních a velkých IS dostat do vážných problémů prostě jenom proto, že začneme řešit systém „od špatného konce“.

U větších systémů je součástí metodických postupů také i tvorba BackLogu, tj. i BackLog se stává součástí řešení a modeluje se pomocí známých technik UML, například Use Case Diagramů.

Řešení uvedeného problému spočívá v zavedení postupu BPM & UC Drive Development s metodou Nabalování (tj. „Collaring“). Postup Nabalování je následující:

Nejprve musíme rychle identifikovat tzv. zlatý proces podniku, tj. obchodně nosný proces (postup viz například metodiky KRUML). U něj zvolíme pouze základní chod zlatého procesu bez vedlejších větví a najdeme z něj volané případy užití, které stručně popíšeme. Ve spolupráci s konzultantem by měl být tento návrh zlatého procesu vytvořen řádově za hodiny, maximálně za jeden resp. dva dny.

Poznámka: Pokud není váš konzultant schopen identifikovat zlatý proces podniku, tedy proč daný podnik a v něm budoucí IS existuje, vyměňte ho, protože jako konzultant je vám na nic.

Od této základní kostry chodu procesu se pak odvíjejí další práce „nabalováním“ („collaringem“) a to několikerým směrem:  

Postup nabalování v BPM & UC Driven Development:

·        Navrhují se entity, které se objevily v nově nalezených případech užití (tj. rozšiřuje se CLASS DIAGRAM).

·        K entitám v předešlém bodě je třeba navrhnout další „podpůrné případy užití“, které tyto entity mají obsloužit (tj. rozšiřují se případy užití o nutné „tanečky okolo“ - založení daného prvku, editace tohoto prvku apod.)

·        Nalézají se další větve chodu procesu, které mohou nastat a k nim je třeba nalézt další případy užití (tj. systém se rozšiřuje o nové funkčnosti v daném chodu procesu).

·        Nalézají se další větve programu v již nalezených UC (tj. rozšiřují se další možnosti v daném již nalezeném „běžícím“ programu).

·        Nalézají se další procesy, které se spouštějí „bokem“ od zlatého procesu (tj. rozšíření o další vedlejší nutné funkčnosti).

Jednotlivé kroky tohoto nabalování se stávají zadáním pro sprinty ve SCRUMU a jsou realizovány podle jeho zásad.

Během tohoto postupu by se mělo dodržovat základní pravidlo agilních technik, že každý sprint se ukončí „minimálně prototypickým“, ale v každém případě chodícím kódem. Pro zvýšení kvality kódu je současně třeba také nasadit postupy TDD (Test Driven Development).

Zrychlení vývoje pomocí UML při současném sloučení agilních technik, například SCRUMU, je možné a to za těchto předpokladů:

1.     Modelování v UML není samoúčelné, modely jsou tvořeny co nejblíže k budoucímu kódu a mají svůj smysl pro tvorbu kódu a pro nalézání nových funkčností (případů užití) pro další sprinty.

2.     Průchod úrovněmi abstrakce je efektivní za pomoci vlastních utilit a vlastnoručně upravených postupů pomocí CASE nástroje.

3.     Použije se technika Nabalování v metodice BPM & UC Driven Development.

1.     Postupně se tvoří skripta ve formátu Wiki s pracovním názvem KRUML, blíže viz zde.

2.     Kniha Analytické modelování pomocí UML v praxi zdarma, blíže viz zde.

3.     Těmito postupy se detailněji zabývají naše pobytová školení. Pokud se chcete seznámit s těmito postupy „na vlastní oči a přímo“ a pokud je chcete také prodiskutovat, věnujte pozornost těmto pobytovým školením u nás:

a.     Pro začínající a mírně pokročilé v UML blíže viz zde

b.     Pro pokročilé blíže viz zde

Konec článku

Zajímavá nabídka pro firmy z Brna a okolí Pobytový kurz návrh IS pomocí UML a OOP jaro 2012 Kurz profesního růstu analytika AM ADVANCED, termín 12.3.2012