Proč je analytický model IS nutným předpokladem pro zabránění tvorbě molochálních systémů Část 1 autor RNDr. Ilja Kraval, http://www.objects.cz březen 2007 firma Object Consulting s.r.o.
Úvod V reakci na články o „molochálních systémech“ (viz předešlé články na našem Serveru objektových technologií) jsem obdržel tento mail: Dobrý den, pane Kraval, chtěl bych Vám moc poděkovat za seriál o molochálních systémech. Je pro mne moc užitečný! Vaše myšlenky se snažím praktikovat do praxe, ale vrtá mě hlavou, jak prolinkovat dvě komponenty (dll) v případě, že pracuju v .NETu a nastane situace, kdy komponenta č.1 využívá objekt komponenty č. 2, a komponenta č. 2 využívá komponentu č. 1. Je to cyklická reference. Musím to provést pomocí referencí na dll (assembly), protože Projektová reference .NETu mi tuto operaci neumožní. Není tato cyklická reference znakem molochu? Nebo je tato operace běžně používaná ve Vámi jmenovaném trendu "Rozděl kód na menší části a linkuj je."?
© Ilja Kraval, 2007, http://www.objects.cz
Totiž v naší firmě je zavedená štábní kultura, kdy jsou úlohy rozděleny do logických celků: personalistika, účto, mzdy, atd. Problémy si myslím skoro vždy můžou nastat například teď, když chci implementovat organizační strukturu (pomocí vzoru Composite), část objektů patří do personalistiky (organizační jednotka, pracovní místo) a část do jiného modulu. Chci se vyhnout zacyklené referenci. Zatím to řeším pomocí interface tak, že mám společný balíček, kde jsou uvedeny interfaci a pokud například v nějakém modulu chci použít třídu osoba tak nepoužívám přímo modul Personalistika ale společný balíček, kde se nachází interface s osobou (IOsoba). Nevím jestli je to čisté, navíc je problém, že pokud předělám třídu Osoba, tak musím předělávat i interface. Předem děkuji za chystaný další díl seriálu. Tento mail je natolik charakteristický, že je třeba na něj náležitě odpovědět a o tom pojednává tento článek.
strana 2
© Ilja Kraval, 2007, http://www.objects.cz
Metoda TUNEL a rozdělení prací v něm Existuje několik možných způsobů, jak tvořit SW. Mezi opravdu nedoporučované postupy patří metoda zvaná TUNEL. Podstata tvorby IS pomoci metody TUNEL je následující:
TUDY NE
ÚSPĚCH
TUDY NE
obrázek 1 Metoda tvorby IS zvaná TUNEL Na počátku projektu se vstupuje do černého tunelu (viz zelená šipka), kterým se prochází poslepu tunelem od stěny ke stěně. Cestou se díky nárazům do stěn tunelu zjišťuje, kudy cesta nevede (viz červené šipky s nápisy „TUDY NE“), tj. co se nemá dělat resp. co se nemělo udělat, když už je něco naprogramováno a špatně. Vedoucí projektu se operativními zásahy snaží projekt uřídit a najít světýlko na konci tunelu (žluté světélko s nápisem ÚSPĚCH). Mnohdy se projekt „s odřenýma ušima“ dokončí a „jakýs takýs“ informační systém se zákazníkovi nakonec odevzdá. Bohužel velmi často nastane případ, že se nadějné světélko na konci tunelu promění ve světla protijedoucího vlaku a celý projekt skončí katastrofickým scénářem, tj. krachem. Podstatou fungování metody TUNEL je velmi nevhodný a nedoporučovaný způsob průchodu fázemi tvorby IS, tj. analýzou IS, technologickým návrhem IS a kódováním.
strana 3
© Ilja Kraval, 2007, http://www.objects.cz
Při použití metody tvorby SW zvané TUNEL se pro průchod fázemi projektu použije tento postup: Mezi pracovníky (původně programátory) se rozdělí práce tak, že se jednoduše systém pomyslně rozčlení na části, nazvěme je agendy a pracovníci je dostanou na starost. Každý z nich potom provádí všechny práce od analýzy, přes design po kódování. Každý pracovník v TUNELU se stává analytikem, technologem a programátorem současně, jinak řečeno si svoji část řešení „sám zanalyzuje, sám navrhne v technologii a sám naprogramuje“. O průchod fázemi se tak stará každý pracovník sám ve své vlastí režii, tj. jinak řečeno, každý projde sám fázemi tak, jak každý z nich umí. Rozdělení rolí v projektu tedy není podle fází projektu (tj. analytik, technolog, programátor), ale je učiněno podle agend, tedy podle oblastí řešení. Vedoucí to má při takto nastaveném mechanismu jednodušší: Rozdělí práci mezi pracovníky podle agend a poté si každý tuto agendu řeší sám od A až do Z. Od vedoucího zaznívají již jenom pokyny typu „dělejte rychleji“. Zažil jsem kdysi tuto metodu několikrát na vlastní kůži jako zaměstnanec. Například dodnes si vzpomínám na vývoj rozsáhlého informačního systému pro banky, kde byly práce rozděleny přesně podle agend a nikoliv podle fází projektu, tj. každý programátor byl současně i analytikem a technologem bankovního systému. Ještě dnes po X letech se mi pod rozdělenými agendami vybavují bývalí kolegové: pokladna - to byl Martin, termínované vklady - to byl Jura, úvěry - to byl Břéťa atd.
Rozdělení prací v TUNELU Co se týče samotného SW tvořeného v TUNELU, tak i on má své charakteristické rysy. Mezi ně patří mimo jiné i tvorba molochů, tj. systémů s příliš velkými komponentami, kusisiyk kódu (detailněji „co je molochální systém“ - viz předešlé články). Naskýtá se otázka, proč je TUNEL zárukou pro vytvoření molocha? Mimochodem odpovědi na tuto otázku je skryta odpověď na otázku kolegy v mailu. Všimněme si blíže, jak vypadá rozložení prací v TUNELU:
strana 4
© Ilja Kraval, 2007, http://www.objects.cz
vedoucí
A D K
A
A
D K
D K
analytici programátoři
obrázek 2 Jak se pracuje v TUNELU Na obrázku je znázorněna „klasická situace“, kdy analytici-programátoři mají svůj „výsek“ práce a provádějí na něm práce jak analytické, tak designu a kódování. Tento způsob řízení je ve firmách bohužel velmi častý a je oblíben pro svou jednoduchost, přesněji pro jednoduchost z pozice vedoucího, nikoliv pracovníků. Stačí „prostě rozdělit“ práci a potom kontrolovat, jak se pracovníci „snaží podat výkony“. Přestože se jedná o velmi rozšířený model řízení, je vřele nedoporučován. Má totiž své natolik vážné nedostatky, že může vést k velmi špatným až fatálně chybným výsledkům zejména u větších projektů. Otázkou je, jak vlastně postupovat, abychom se těmto problémům vyhnuli? Mezi opravdu důležité znalosti, které musíme mít pro opouštění tohoto způsobu tvorby SW pomocí TUNELU a „rozdělení prací podle agend“, je znalost modelování v UML. Důvod je jasný: pracovník v roli analytik nebo designér musí výsledky své práce předat druhému pracovníkovi a k tomu potřebuje nějaký „vyjadřovací jazyk“ a tím nejlepším jazykem je opravdu modelovací jazyk UML. Poznámka: Mimochodem školení „Pobytový kurz UML a OOP“ je z toho důvodu zaměřeno nejenom na syntaxi UML, ale i na doporučené postupy prácí „jak rozsvítit v TUNELU“, což se probírá velmi detailně i to s prostorem pro dotazy účastníků strana 5
© Ilja Kraval, 2007, http://www.objects.cz
školení a konzutlacemi. Dá se říci, že to je vlastně i cíl tohoto školení - jazyk UML je pouze velmi kvalitní nástroj napomáhající tomuto „rozsvícení v TUNELU“. Vrátíme se nyní k dotazu v mailu. Evidentně je vidět, že to, co kolega nazývá „štábní kulturou ve firmě, kdy jsou úlohy rozděleny do logických celků: personalistika, účto, mzdy, atd“, tak to je charakteristické pro TUNEL a rozdělení prací v něm podle agend. A z toho plynou i následné problémy. Jako jeden z nepříjemných důsledků prací v TUNELU můžeme jmenovat na prvním místě velmi nízkou až katastroficky špatnou transparenci systému. To je sice opravdu velmi nepříjemný efekt (mimochodem kdo někdy opravoval SW ve tmě TUNELU, ví, o čem hovořím ☺). Tato metoda má však i další neméně nepříjemné důsledky, my se soustředíme na jeden z nich, který s souvisí s dotazem v mailu: Platí, že metoda TUNEL je zaručeným receptem, jak tvořit molochy. Otázkou je, proč při rozdělení prací podle agend se nakonec potýkáme s problémy molochů? Mimochodem v mailu od kolegy je velmi výstižně popsán důsledek takto navrženého systému, a to v těch odstavcích, kde popisuje práci s cirkulárními referencemi. Ukážeme si v další části článku, jak vlastně rozdělení prací v TUNELU vede nutně k návrhu molochů a jak se tomuto efektu vyvarovat správnými a doporučenými postupy. Konec 1. části článku
strana 6
