Na rozhodnutí záleží
Jaký používat jazyk pro analýzu? Pokud chceme dělat analýzu správně se záměrem, aby nám sloužila jako dlouhodobý popis stavu firmy, informačních systémů a všeho, co s tím souvisí, je zřejmé, že každé rozhodnutí o formě analýzy je důležité. Modely a dokumentace, které vytvoříme, budou ve firmě řadu let, a pokud by se ukázalo, že jsme zvolili nevhodné nástroje a jazyky, zaděláme si na těžko řešitelné problémy.
Jaké jazyky se používají nejčastěji?
- ArchiMate – pokrývá celou enterprise architekturu, ale není stvořen pro velké detaily
- BPMN – procesy do posledního „šroubku“, ale nic víc
- UML – objektové modelování dokonale, architektura systémů dobře, všechno ostatní minimálně
- Hodnocení jazyků na předchozích řádcích je tak jednoduché, jak jen je na jednom řádku možné. Podívejme se tedy na 2 hlavní „konkurenty“ podrobněji. Cílem dalších oddílů není představit jazyky, ale upozornit na hlavní rozdíly.
UML
Business analýza
UML nemá pro business analýzu mnoho nástrojů, v podstatě počítá pouze s UseCase požadavky od aktérů.
UseCase, které mají blízko k Stories v agilním vývoji, jsou fakticky uživatelské potřeby, nebo také uživatelské požadavky. UML nemá žádné nástroje pro modelování businessu jako celku, v rámci business analýzy se zaměřuje na popis toho, co business chce od informačního systému.
Výhody UML v business analýze:
- Pro agilní vývoj jde o vhodný model, protože přímo přenáší požadavky uživatelů do aplikace
Softwarová analýza
UML má ústřední entitu třídu (class) a kolem ní se v jazyce všechno točí. Třída „zná a umí“: uchovává informace a vykonává operace.
Typickou business třídou bude např. faktura
Třída v sobě nese informace, které k faktuře patří a činnosti, které třída umí, tedy činnosti, které je možné s informace třídy dělat. Některé z těchto činností k faktuře patří, jiné ale analytici v praxi připravují zcela jinde. Typicky funkce Proplať a Vytiskni se sice k faktuře vztahují, ale jde o funkce, které nejsou modelovány ani vyvíjeny ve stejném modulu. Vytištění bude připravená tisková sestava, proplacení součást dávky chystající denní platby. Analytikovi tak vyvstává otázka, zda skutečně má použít metody třídy Faktura nebo modelovat funkcionalitu jinde. Ale kde? V UML je všechna funkcionalita ve třídách a jinde nemá co dělat.
Detailnější popis v UML má možnost modelovat vnitřní dynamiku chování modulů pomocí objektových modulů a jejich vazeb. Detailní modely chování používají diagramy spolupráce
V čem jsou výhody UML:
- Pokud se skutečně podle návrhu má vytvořit objektová aplikace, je objektový návrh ideální volbou, protože bude přesně zobrazovat, jaká je struktura aplikace
- Technický popis objektově vyvíjené aplikace nemůže být přesnější. Je tak velmi snadné udržovat přímou provázanost mezi kódem a návrhem
ArchiMate
Business analýza
ArchiMate je určen pro modelování businessu jakožto celého komplexu souvisejících služeb, činností a aktérů. Business model v ArchiMate tak nepracuje s pojmem požadavku / UseCase, ale s pojmy činnost businessu. Činnosti jsou standardně součástí procesů.
Schéma vyjadřuje, že fakturantka z fakturačního oddělení odpovídá ze procesy, který jsou realizovány služby daného oddělní. Model popisuje, jak funguje business a bez dalších podrobností vůbec neobsahuje požadavky na aplikace. Ty vzniknou ve chvíli, kdy model doplníme o popis, co který krok procesu požaduje od aplikací za služby.
Softwarová analýza
Model faktury v ArchiMate bude vypadat velmi odlišně:
Faktura je v pojetí ArchiMate datová entita, se kterou pracují funkce a pro kterou jsou poskytovány služby. ArchiMate v principu není objektový. Data, funkcionalita i dostupné služby jsou samostatné objekty, ke kterým se bude při analýze vztahovat popis.
Na schématu je také vidět rozdělení služeb, které moduly poskytují businessu a funkcí, které popisují, co modul uvnitř dělá. ArchiMate tak podporuje zapouzdřování (encapsulation). Zapouzdření je ovšem na úrovni modulu systému, nikoli na úroveň třídy, jak to dělá UML.
ArchiMate pro detailní analýzu používá popisy dynamického chování, nepracuje ale s instancí žádných tříd (s objekty), a dynamické modely používají tytéž elementy, jako modely strukturální. Jsou díky tomu jednodušší na pochopení
V čem je ArchiMate výhodnější:
- Pro zadání toho, co moduly nebo celé aplikace dělají, poskytuje ArchiMate jednodušší model. Nevyžaduje modelování vnitřní struktury aplikace.
- Aplikace budované nad relačními databázemi se nutně dívají na data a funkčnost odděleně. Tomu logika ArchiMate odpovídá.
- Logika ArchiMate více odpovídá tomu, jak se analýza i na úrovní zadání řešení, skutečně dělá: popisují se data a funkčnost, ale zadání nedefinuje třídy a jejich metody
- Tím, že ArchiMate pro aplikační vrstvu používá stejné prvky, jako pro business architekturu, je celý model srozumitelný i business analytikům.
Podle čeho se rozhodovat
Z ukázek je patrné, že každý jazyk směřuje na jinou oblast analýzy.
ArchiMate je vhodný pro komplexní enterprise architekturu, protože umožňuje rovnocenný popis businessu i aplikací. Nejde do detailů, jak je business nebo aplikace implementována a tak není ani závislý na konkrétní používané architektuře
UML z business analýzy podporuje pouze popis požadavků na software. V rámci analýzy aplikací je optimálním při návrhu objektových aplikací, kterém umožňuje skutečně věrně modelovat. Pokud ale smyslem softwarové analýzy je připravit zadání a nikoli vyvíjet objektovou aplikaci, poslouží ArchiMate pravděpodobně lépe, než objektový model systému.
