Od začátku devadesátých let se situace na poli prostředků objektové analýzy a designu stávala dosti nepřehlednou. Existovalo množství metodik, z nichž každá doporučovala mírně odlišné metody, nástroje a definovala svůj vlastní proces tvorby IS/SW. Z praktických důvodů musely být dříve nebo později vyslyšeny hlasy volající po jistém stupni konvergence, což se týkalo zejména notace vytvářených modelů. Navzdory nasazení odlišných metodik a používání neslučitelných nástrojů spolu pochopitelně chtěli objektoví vývojáři navzájem komunikovat.
V poslední době se pozornost obrací především k metodikám a metodám postaveným na doporučené notaci UML (Unified Modeling Language), která slouží jako sjednocující standard mezi analytiky, návrháři a programátory používajícími objektové technologie. Bezezbytku všechny ze soudobých metodik a metod objektové analýzy a designu se honosí oním označením "UML compliant", které je (a nebo velice brzy bude), téměř nezbytné. Ač se to mnohým z nás nemusí líbit, nabývá tento standard na důležitosti a vše nasvědčuje tomu, že se jedná o trend a nikoliv pouze o dočasnou pomíjivou záležitost. Zkrátka, v moderním procesu tvorby IS má UML již své pevné místo a buďme připraveni na to, že o něm uslyšíme čím dál víc.
Historie
Nejzažší historie UML sahá do listopadu 1994, kdy své síly spojili dva tehdejší objektoví guru Grady Booch a James Rumbaugh. Sloučením dvou nejvíce používaných metodik, Booch, silné především ve fázích designu a implementace a OMT měl vzniknout nový de facto standard mezi prostředky objektové analýzy a designu. Na konferenci OOPSLA`95 (Object-Oriented Programming Systems, Languages and Applications) byl široké odborné veřejnosti poprvé představen výsledek jejich společného úsilí, tehdy ještě pod názvem Unified Method v. 0.8. V roce 1995 se k oběma tvůrcům připojila další výrazná osobnost, Ivar Jacobson, autor vcelku úspěšné metodiky Objectory/OOSE. Rychle po sobě následovaly verze 0.9 a 0.91 a nakonec i zcela zásadní verze 1.0, která později sehrála klíčovou roli. Bleskovým přejmenováním Unified Method na Unified Modeling Language byla definitivně stvrzena úloha UML jakožto prostředku pro grafickou tvorbu objektových modelů a nikoli jako ucelené metodiky definující i odpovídající proces tvorby IS. Notace UML v. 1.0 byla rovněž předložena konsorciu OMG, které ji ještě téhož roku adoptovalo jako svůj doporučený standard. Cesta k akceptování UML širokou odbornou veřejností se tímto zdála býti otevřena.
Dnes je UML nejrozšířenější používanou objektovou notací, na jejíž základech stojí většina nabízených CASE systémů. Za pár měsíců své existence doznalo UML několik rozšíření a modifikací jako například zavedení OCL (Object Constraint Language) a prostředků pro business modelování. Zatím poslední oficiální verzí je OMG UML 1.3 z léta roku 1999.
Prostředky UML
Jak již bylo patřičně zdůrazněno, UML není ucelená metodika definující i nezbytný proces tvorby IS, ale pouhá množina nástrojů, které se v tomto procesu používají. Teprve nasazením odpovídající objektové metodiky, která definuje kdy, kým a jak jednotlivé nástroje používat, můžeme vytěžit z UML maximum. Z objektových metodik vytvořených přímo nad nástroji UML jmenujme například Unified Process či Catalysis, vhodnou pro tvorbu systémů stojících na principech CBD (Component-Based Development). Tento text by měl sloužit jako stručný průvodce objektovým modelováním za použití nástrojů UML, nikoliv jako detailní průvodce UML samotným. Bližší informace nalezne čtenář na vybraných stránkách věnovaných UML (viz. příloha článku), případně na adrese autora.
Jak je vcelku zaběhnutým zvykem (otázkou je jestli dobrým či nikoliv), odlišuje UML nástroje pro modelování statické a dynamické stránky systému. Zjednodušeně řečeno, statický pohled ukazuje jak systém vypadá, zatímco dynamický definuje, jak se systém chová v čase a jak reaguje na nejrůznější podněty. Souhrnně hovoříme o architektuře systému. Jednotlivé nástroje a prostředky obsažené v UML nám při respektování tohoto pravidla dovolí modelovat vytvářený systém ze všech možných stran a na všech možných úrovních. Vhodnou kombinací těchto nástrojů, a to je na zvládnutí objektového modelování to nejtěžší, lze dosáhnout vcelku přehledných modelů dílčí i celkové architektury systému.
Začneme-li etapou analýzy, o jejíž nutnosti soudný člověk nemůže pochybovat, pak je prvním z úkolů vymezení hranic modelovaného systému. Tento postup je samozřejmě analogický s procesem zkoumání jakéhokoliv předmětu. Zpravidla první a určující činností je vždy tento zkoumaný předmět poznat, čímž se zabývá obecně analýza, a následně se dají na základě těchto poznatků dělat další rozhodnutí, která mohou mít naopak povahu syntézy (etapy designu a implementace).
Po úspěšném vymezení hranic systému se již víceméně pouštíme do obtížného úkolu nalezení vhodných objektů a vztahů mezi nimi, které tvoří danou oblast. Takto vytvořený objektový model je poté různě zpracováván až do podoby předloh pro implementaci, kterou nám může automatickým generováním kódu usnadnit použitý CASE nástroj. V následujících odstavcích se pokusíme objasnit, jak nám může UML pomoci při naplňování tohoto zjednodušeného schématu.
Diagram případů užití (use case diagram)
První úkol, tj. vymezení hranic systému, je v UML podpořeno dynamickým pohledem modelovaným prostřednictvím diagramů případů užití, který je znám pod celou řadou dalších názvů jako například diagram typových čiností, jednání atp. Tento diagram, obecně model, zobrazuje základní vztah systému k jeho okolí, tzv. aktorům. Aktory jsou nejčastěji samotní uživatelé systému, nicméně mohou jimi býti obecně libovolní externí činitelé stojící mimo modelovaný systém. Může se tedy jednat například o další HW s SW prostředky, jiné IS, s kterými má nový IS spolupracovat, instituce, které se systémem komunikují atd. Každý případ užití pak představuje jeden z možných způsobů použití systému, jednu z možných cest komunikace aktor - systém. Konkrétním případem užití může být například použití systému za účelem zjištění aktuálního stavu skladových zásob, zpracování faktury atp. Jednoduše řečeno, případy užití simulují použití reálného systému externími aktory. V rámci tvorby těchto diagramů modelujeme vztah systému a jeho okolí, nikoliv vzájemnou interakci, tj. způsob, jakými jsou jednotlivé případy užití zajištěny interními funkcemi systému.
Největší úskalí při používání tohoto prostředku spočívá v odhadnutí "správné úrovni abstrakce". Občas se může stát, že jsou případy užití moc obecné a nelze s nimi bez patřičného zpodrobnění efektivně pracovat. Na druhou stranu je nutné vyvarovat se druhého extrému, kterým je zneužívání tohoto nástroje pro funkcionální rozklad, který nemá s "Use Case modelováním" nic společného! Historie praví, že systém postavený na funkcích, jež má zajišťovat, spíše než na objektech, které jej tvoří, je mnohdy nestabilní z hlediska měnících se uživatelských požadavků. Ačkoliv toto riziko a problémy s ním spojené objektový přístup neeliminuje bezezbytku, je přeci jenom možné nežádoucí efekty vyplývající ze změny požadavků částečně potlačit. V ideálním případě se změna promítne v místě, kterého se bezprostředně týká, v horším případě ovlivní dílčí změna mnoho součástí systému. S rostoucím počtem následných úprav pak logicky roste i riziko z nejnepříjemnějších – nekonzistence modelů.
Praxe ukazuje, že z hlediska používání UML je zvládnutí tvorby těchto modelů jedním z nejobtížnějších úkolů, který navíc díky své povaze výraznou měrou ovlivňuje podobu výsledného produktu. Přestože je pomocí tohoto prostředku možné rozdělit systém na dílčí oblasti, není tento prostředek určený na komplexní modelování architektury. Snad více než kde jinde je v tomto typu modelu nutno zvolit správný konsenzus mezi úplností a přehledností. Nepříliš adekvátním použitím mohou diagramy případů užití velice rychle nabobtnat a stanou se z nich nezvladatelná monstra, která již neslouží svému původnímu účelu, tj. pro vytvoření prvních "nástřelů" a pro základní členění systému.
Ve spojení s dalšími prostředky pro dynamické modelování je tvorba diagramů případů užití fundamentálním prostředkem pro nalezení objektů participujících v modelovaném systému. Rozdělení celého systému na jednotlivé případy užití přináší kromě vymezení hranic systému i možnost zpracovávat jednotlivé případy užití odděleně a částečně tak realizovat iterativní přírůstkový životní cyklus. Skrze tvorbu případů užití jsou samozřejmě definovány i základní uživatelské požadavky.
Sekvenční diagram (sequence diagram)
Sekvenční diagramy se vytvářejí většinou přímo z diagramů případů užití. K jednomu případu užití může existovat několik sekvenčních diagramů, které modelují interakci objektů v rámci komunikace aktora se systémem.
Jak je docela zřejmé, sekvenční diagramy jsou zaměřeny výhradně na dynamickou stránku systému. Jsou vhodné pro nalezení jednotlivých objektů a zobrazení komunikace mezi nimi. S tvorbou sekvenčního diagramů se postupně vynořují jednotlivé objekty (resp. kandidáti na objekty), které jsou rovnou zapracovávány do diagramů tříd. Je vhodné zdůraznit, že objekty nalezené v počátečních fázích modelování systému se zřídkakdy v původní podobě uplatní též jako softwarové objekty implementované v cílovém prostředí. Zprvu se jedná spíše o koncepty, pojmy, které se postupem času, zejména ve fázi designu, vyhodnocují a dochází zpravidla k částečné redukci a konsolidaci objektových modelů.
Výsledný systém může mít nakonec podobu logické třívrstvé architektury, kdy jsou od sebe odděleny objekty prezentační vrstvy, objekty samotné problémové oblasti nalezené v analýze a rozpracované v designu a nakonec například objekty zajišťující funkce perzistentní vrtsvy. Ignorujeme-li analýzu problémové oblasti (což může být například důsledkem používání "výkonného RAD nástroje x-té generace"), můžeme ve výsledném systému nakonec onu prostřední vrstvu představující tzv. obchodní logiku úplně postrádat (kolik znáte seriózních aplikací, kde jsou objekty GUI přímo provázány s databázovým systémem ?). Jsme-li prozřetelnější, snažíme se obchodní logiku systému navrhovat přímo z analytických modelů, což nám mimojiné pomůže zajistit lépší návaznost s uživatelskými požadavky.
Sekvenční diagram obsahuje dvě dimenze. V horizontální rovině se zobrazují jednotlivé objekty, zatímco vertikální rovina představuje tok času. Zprávy posílané mezi jednotlivými identifikovanými objekty mohou být různého druhu. Záleží-li na jejich bližším odlišení, lze klasifikovat zprávy asynchronní, vnořené, zprávy představující návratové hodnoty apod. Ve prvotních fázích pochopitelně ještě nemají jednotlivé zprávy podobu metod objektů včetně počtu a typu parametrů, ve skutečnosti by tyto informace zatím neměly v modelu co dělat. Na takováto "low - level" rozhodnutí přichází čas až v etapách designu, kdy to má smysl. V analýze nás zajímá především obecná komunikace, jejíž jednotlivé detaily (právě např. parametry metod, návratové hodnoty, ...) rozpracováváme až po ustálení objektového modelu. V případě nutnosti jsou v sekvenčních diagramech používány cykly a větvení, která jsou užitečná hlavně ve spojení s textovým popisem zpráv, jež se nejčastěji nachází v levé části diagramu.
S rozpracováváním sekvenčního diagramu může poměrně rychle vzrůstat jeho celková komplexnost, což je vcelku spolehlivým příznakem příliš obecného případu užití, ke kterému je sekvenční diagram vytvářen. Namísto tohoto prostředku je někdy možno zvolit prostředek jemu významově velice blízký – diagram spolupráce.
Diagram spolupráce (collaboration diagram)
Chceme-li v jednom diagramu znázornit jak strukturu objektů (například skládání objektů) tak i jejich dynamické chování, použijeme s výhodou diagramů spolupráce, které jsou vedle sekvenčních diagramů dalším prostředkem, jehož těžiště tkví v modelování dynamiky. Na rozdíl od sekvenčních diagramů je však znatelně obtížnější vysledovat návaznost jednotlivých posílaných zpráv zajišťujících samotnou funkcionalitu systému. Zatímco v sekvenčních diagramech je tato návaznost zřejmá z vertikálního uspořádání celého diagramu, v diagramech spolupráce je následnost zobrazena pořadovým číslem, kterým jsou zprávy uvozeny.
Tvorba diagramu spolupráce by měla být v souladu s diagramem tříd. Pro zachování vzájemné konzistence modelů je nezbytné dodržovat základní pravidla, která mezi těmito modely platí. Komunikace mezi objekty musí být například podmíněna existencí odpovídající vazby mezi jejich třídami, o existenci patřičných tříd nemluvě. Nemusíme asi ani zdůrazňovat, jak nevděčnou prací je "ruční" kontrolování obdobných pravidel. Je jasné, že zde mohou opět pomoci CASE nástroje. Docela seriózně lze prohlásit, že právě zde existuje hranice mezi skutečnými CASE systémy a pouhými kreslícími programy.
Stávají-li se sekvenční diagramy občas nepřehlednými, pak to u diagramů spolupráce platí dvojnásob. Na druhou stranu vzhledem k tomu, že se pořadí zasílání zpráv určuje pořadovým číslem, dá se lépe modelovat komlexní chování včetně větvení a cyklů.
Diagram tříd (class diagram)
Diagramy tříd patří bezesporu k nejčastěji používaným nástrojům UML a tvoří vůbec jakýsi základ všech prostředků objektové analýzy a designu . Tyto diagramy jsou většinou vytvářeny již ve fázi analýzy často jako pojmové modely, jejichž úkolem je formálněji definovat jednotlivé termíny používané ve studované problémové oblasti. Takové modely jsou maximálně přínosné a užitečné v okamžiku, kdy je nutno zpětně vstřebat terminologii oboru. S postupným přibližováním k fázi implementace jsou diagramy tříd poměrně zásadně přehodnocovány a v ideálním případě zpracovávány až do podoby grafického modelu ekvivalentního zdrojovému kódu.
Diagramy tříd zobrazují statickou stránku systému, především vztahy mezi třídami. UML explicitně rozlišuje několik druhů tříd (parametrizovatelné třídy, …), stejně jako rozličné množství vztahů, které jednotlivé třídy navzájem pojí (asociace, agregace, kompozice, specializace/generalizace, ...).
Tvorba diagramů tříd patří mezi klíčové problémy a zcela vážně lze prohlásit, že zvládnout objektový přístup často znamená správně využívat právě tento typ diagramů používaný průběžně napříč celým životním cyklem tvorby IS. Zvláště při tvorbě těchto diagramů se doporučuje dodržovat nepsané pravidlo 7 + 2, které říká, že v jednom diagramu je vhodné zobrazit 7, maximálně až 9 tříd. Při respektování tohoto doporučení se většinou výraznou měrou zpřehlední výsledné modely, nicméně na druhou stranu vyvstává problém vhodného rozdělení systému na dílčí oblasti (v terminologii UML jsou jimi tzv. packages). Asi nejčastěji "páchanými" chybami při tvorbě diagramů tříd (a celkově při objektovém modelování) je zaměňování pojmů objekt a třída, čímž může dojít k zavlečení poměrně závažných nekonzistencí do vytvářeného modelu. Ač se to zprvu nemusí zdát zřejmé, hierarchie dědičnosti Automobil <- Osobní automobil <- Škoda 120 je chybná.
Značně ovlivněna svými přímými předchůdci je notace diagramu tříd v UML vzdáleně podobná klasickým ER diagramům obohaceným o některé objektové rysy. Atributy tříd jsou zobrazeny ve střední části prvku třídy, metody pak v části spodní. Podle specifikace UML mohou být atributy pouze základních typů (integer, real, ...), všechny ostatní by měly být zobrazeny jako vztahy k patřičným třídám. Je zde jasně vidět polovičatost s jakou se UML staví k objektovému přístupu. Ve skutečnosti samozřejmě neexistuje objektivní důvod pro odlišování jednotlivých atributů podle typu, v čistě objektových jazycích jsou i základní typy reprezentovány prostřednictvím patřičných tříd. To ovšem zdaleka není případ klasického C++, jímž je UML nejvíce ovlivněn. Rozlišování způsobu notace atributů podle typu se může zezačátku zdát velice matoucí a nelogické. V podobném duchu je možné určit pro jednotlivé složky (atributy, metody) tříd jejich viditelnost vzhledem k ostatním třídám atd.
Bohužel značná orientace na jedno konkrétní prostředí je jednou z méně šťastných vlastností UML. Na druhou stranu je nutné si opět uvědomit (pokolikáté už), že tyto prostředky spadají až do pozdního designu a dříve než v designu o nich nemá smysl uvažovat. Možná, že se naše neustálé upozorňování na toto základní pravidlo jeví jako dosti zbytečné a samoúčelné, ovšem věřte nám, že výsledné modely mohou být tímto zpravidla silně poznamenány. Naposledy tedy: "drívě než v detailním designu nemá diskuse o pointerech" při tvorbě IS své místo.
Vzhledem k velkému množství modelovacích prvků použitelných v tomto typu diagramu může být poměrně lehké "sklouznout" k tvorbě sice formálně přesných, ale těžko srozumitelných modelů, což se opět negativně projeví při snaze diskutovat řešení s člověkem, který se objektovým modelováním neživí.
Jak již bylo řečeno, objekty jsou nejčastěji "nalézány" při tvorbě dynamických modelů simulujících použití systému (typicky sekvenční diagramy) uživatelem, obecně při realizaci jednotlivých případů užití. Na druhou stranu nic nebrání použití odlišných metod pro nalezení objektů, jakými mohou být například analýza chování objektů (Object Behavioral Analysis), případně nejjednodušší (a nejméně spolehlivá – udává se míra úspěšnosti asi 20 %) lexikální analýza.
Stavový diagram (state transition diagram)
Stavový diagram patří mezi klasické a osvědčené nástroje objektového modelování. V UML je tento prostředek přítomen v lehce modifikované podobě Harelových diagramů. Diagram stavů a přechodů, jak je někdy tento prostředek nazýván, slouží pro modelování životního cyklu části systému svým rozsahem odpovídající jednomu objektu. Přechod mezi jednotlivými stavy bývá vyvolán podnětem z vnějšího okolí, nejčastěji ve formě zprávy zaslané příslušnému objektu nebo jinou externí událostí. Validní stav objektu je zjednodušeně řečeno definován přípustnými hodnotami jeho atributů, přechod mezi stavy je pak vlastně vyjádřením změny hodnot těchto atributů.
Jak je asi každému zřejmé, životní cyklus objektu nějak začíná a zpravidla i nějak končí (v případě, že se nejedná o objekt perzistentní, který je například uchováván v objektové databázi). Ovšem nemusí být již zcela samozřejmé, že tzv. start stav by měl být v diagramu vždy pouze jeden, zatímco stop stavů, tj. stavů ukončujících životní cyklus sledovaného objektu může být více, pochopitelně většinou alespoň jeden. Z implementačního hlediska je start stav ekvivalentní alokaci paměti, resp. zavolání kontruktoru třídy, naopak stop stav je realizován vykonáním destruktoru, v lepším případě prostředky automatické správy paměti (garbage collector).
Obdobně jako mnohé jiné notace umožňuje UML definovat v těle stavu jednoduchou exekutivu vykonávanou v rámci uvažovaného stavu. V neposlední řadě je možné specifikovat podmínky, které musí platit při přechodu do stavu a při odchodu z něho. Tak je možné zachytit důležitá pravidla hlídající konzistenci a validitu celého modelu.
Diagramy aktivit (activity diagram)
Jako jistou obdobu stavových diagramů můžeme chápat i diagramy aktivit, kde jednotlivými stavy rozumíme aktivity a přechod mezi aktivitami je vyvolán dokončením aktivity stávající. Diagram aktivit se zpravidla vztahuje k jednomu případu užití, případně k jedné metodě objektu. Pomocí diagramu aktivit modelujeme tentokrát dynamický tok řízený nikoliv vnějšími událostmi ale interními podněty. Při troše dobré vůle lze tento nástroj používat i pro modelování procesů a pracovních toků (work-flow), kdy se nezřídka využívá možnosti modelovat paralelismus a větvení v rámci konkrétního zpracovávaného procesu.
Poměrně elegantním způsobem je možné přiřazovat k jednotlivým aktivitám osoby (resp. aktory), které jsou za provedení patřičné aktivity zodpovědné. Stejně dobře jako pro procesní modelování je možné používat diagramy aktivit i pro základní schematickou tvorbu grafického uživatelského prostředí, což může pomoci odhalit případná nedorozumění ohledně návaznosti jednotlivých obrazovek GUI.
Diagram komponent (component diagram)
Zatím jsme celou dobu hovořili o diagramech intenzivně využívaných především ve fázích analýzy a designu, nyní naopak zaměříme naši pozornost směrem ke zbývajícím dvěma nástrojům, jejichž hlavní přínos můžeme ocenit zejména při použití ve fázích implementace a nasazení SW/IS.
Prvním a zřejmě asi častěji používaným nástrojem je diagram komponent, jehož název mluví za vše. Jeho pomocí se visualizují vztahy mezi jednotlivými SW komponentami, které mohou být ve formě zdrojových souborů, hotových spustitelných částí nebo pouze hlavičkových souborů. Mezi jednotlivými komponetami může existovat pouze jeden druh vazby a tou je závislost. Je možné zobrazovat například návaznost zdrojových a hlavičkových souborů nebo zdrojových souborů tvořící knihovnu tříd. Můžeme také explicitně vyjádřit nutnost používat komponentu prostřednictvím pevně definovaného rozhraní, které můžeme definovat v diagramu tříd.
Komponentou ve smyslu UML je určitá množina tříd, které spolu realizují požadovanou funkčnost. Diagramy tříd je tak možné "rozsekat" na abstraktnější celky, s kterými můžeme následně pracovat jako se základními stavebními kameny. CASE nástroje by pochopitelně měly umožňovat integraci takto vzniklých komponent se standardy pro distribuované objektové systémy – především s řešeními postavenými na standardu OMG CORBA, případně s více proprietálním DCOM.
Diagram nasazení (deployment diagram)
Diagram nasazení je druhým typem diagramů určených pro implementační fáze. Jeho úkolem je především zobrazit vztahy mezi částmi systému tak, jak vypadají v době samotného vykonávání. Diagramy nasazení zobrazují rozložení jednotlivých SW komponent na HW zdrojích a jejich spolupráci, rozmístění HW a SW prostředků v lokalitách, topologie používaných sítí, druhy a využití komunikačních prostředků atp.
Rozšíření UML: Object Constraint Language
Samotné výrazové prostředky UML nejsou dostatečně silné na to, aby bylo možné s jejich pomocí zachytit zásadní vztahy a především pravidla, která jsou nezbytnou součástí modelovaného systému. Diagramy tříd například nenesou informace o pravidlech, které musí platit pro zajištění konzistence celkového modelu.
Představme si například následující situaci. V objektovém modelu máme dvě třídy, majitel účtu a účet samotný. Jakým způsobem namodelujeme v diagramech UML fakt, že majitel nesmí při vybírání z bankomatu překročit svůj denní limit, případně celkový zůstatek na účtu ? Anebo příklad programátorský. Jak v UML definovat podmínku, že musí být při operaci pop v zásobníku uložen alespoň jeden prvek (jinými slovy že nelze vyvolat metodu pop nad prázdným zásobníkem ...)? Při hlubším zamyšlení zjistíme, že se vždy jedná o obdobné případy, pro které ovšem dříve UML nenabízelo vhodné modelovací prostředky. Ze všech myslitelných řešení bylo většinou nejlepší použít v modelech všudypřítomnou textovou poznámku, která toto dokázala alespoň trochu ošetřit. Nevýhodou tohoto řešení je pochopitelně menší úroveň formálnosti, než by bylo žádoucí.
Společností IBM byl proto předložen návrh rozšíření UML právě o prostředek pro zachycení těchto důležitých údajů. Tímto prostředkem je Object Constraint Language (OCL). Jedná se o popisný pseudojazyk stojící na základech vybraných mechanismů predikátové logiky (kvantifikátory, ...), pomocí kterého můžeme popsat jak libovolné obecné podmínky, tak i validní stavy objektů. Bezezbytku tedy můžeme popsat podmínky a pravidla, která jsou integrální součástí popisované problémové oblasti. Tyto popisy jsou vytvářeny především v etapách designu a implementace, i když v omezené míře je vhodné je používat i ve fázi analýzy.
Bohužel dnes je situace poměrně tristní co se týče podpory podobné filosofie za strany vývojových nástrojů a cílových prostředí. Je sice pěkné, že můžeme výhodně použít OCL v grafických modelech, ovšem co je nám to platné, když nemůžeme stejná pravidla "přenést" i do prostředí programovacích jazyků, v kterých jsou výsledné objektové modely realizovány. Situace se v tomto směru již naštěstí pohnula kupředu a kromě čistě objektových jazyků, které adekvátní prostředky obsahují od nepaměti (Eiffel, Sather, ...) se pomalu ale jistě začínají zabydlovat obdobné mechanismy i v jiných prostředích (Smalltalk, Java, ...).
Aplikace UML při tvorbě IS
Nástroje UML pokrývají většinu ze základních činností prováděných v rámci modelování IS. Začali jsme povídáním o use case modelování, které je základním nástrojem analytika a skončili jsme poměrně dost "nízkoúrovňovými" nástroji, které jsou naopak zajímavé především pro designéry a implementátory. Je samozřejmě více než vhodné, aby měli jednotliví účastníci procesu tvorby IS přehled o charakteru práce ostatních kolegů. Odvažujeme se tvrdit, že UML tento požadavek splňuje.
Snad nic není zhoubnějšího než velká propast mezi členy dvou táborů, analytiky, kteří bývají někdy nezřízeně pyšni na svou "vysoce intelektuální a náročnou činnost" a "opravdovými můži činů" - programátory, kteří mívají někdy tendenci pohlížet na "analytické mozky" jako na partu individuíí neschopných reálného uchopení problému. Jako kdybychom některé slyšeli říkat: "vždyť jde nakonec stejně jenom o kód, tak jakápak analýza..."
Ztroskotá-li tvorba IS, je to zpravidla zapříčiněno nikoliv špatným použítím metodik, metod nebo nástrojů, ale především nedostatečnou vůlí k týmové spolupráci. Špatná úroveň mezilidské komunikace v rámci řešitelského týmu, kterého se nezřídka účastní i členové z řad zadavetele se zcela zásadně projeví do podoby výsledného produktu. Tento problém samozřejmě UML nevyřeší nikdy.
Závěr
Největší koncepční výtkou na adresu UML je přílišná orientace na použití při tvorbě SW, což se někomu může sice zdát jako logický důsledek předešlého vývoje, někomu jinému však jako poměrně výrazná slabina a nevýhoda. Tvorba IS není zdaleka jenom tvorba SW.
Při prvním seznámení může UML působit vcelku kompaktním dojmem, ovšem při hlubším studiu a především dlouhodobějším používání narazí jeho uživatel na pár nekonzistencí. Na některé jsme již poukázali, plno ostatních jsme pominuli. Na druhou stranu nesporně platí, že UML hraje roli sjednocujícího komunikačního prostředku mezi objektovými modeláři, kde sehrává opravdu zásadní úlohu. Nástroje obsažené v balíku UML tvoří vcelku ucelenou množinu efektivních prostředků dobře sloužících svému účelu, jejichž zvládnutí však vyžaduje dostatek snahy a trpělivosti. Po úspěšném osvojení však může UML dobře posloužit jako balík základních nástrojů pro tvorbu IS.
Objektové metodiky jsou účinnými zbraněmi především proti nadměrné komplexnosti a jejím důsledkům. Bohužel, samotné UML jako notace pro tvorbu a dokumentaci objektových modelů má občas s komplexností problémy. Je to dáno především přístupem jeho tvůrců, který je někdy zbytečně maximalistický, což je mnohdy spíše ku škodě věci. Na druhou stranu poslední instancí je uživatel UML (analytik, návrhář, ...), který by se měl rozhodnout jaké nástroje a k čemu používat. Tím vzrůstá i důležitost role firemního metodika, který by měl být zodpovědný za nasazení, používání a rozvoj zvolené metodiky. Patřičné erudice je samozřejmě nezbytná.
Mezi nejvýznamnější trendy v souvislosti s UML patří podle našeho názoru směřování k určitému stupni formalizace ať už v podobě nástrojů typu OCL nebo přímo formálních popisů využívajících aparát predikátové logiky. Na druhou stranu víme, jak těžko se používání takových prostředků prosazuje v praxi.
Asi vůbec nejdůležitějším trendem je používání objektových technologií jak pro tvorbu IS, tak i pro aktivity spojené s BPR. Informační technologie dnes sehrávají v podnikovém prostředí zásadní roli a je více než zřejmé, že nelze tvorbu IS od Business Process Reengineeringu absolutně oddělit. Naskýtá se zde pak aktuální otázka, proč nepoužívat jednotný nástroj, který by byl schopen vhodně podpořit oba dva pohledy na stejný problém. Tímto nástrojem se však sotva stane UML v dnešní podobě tak, jak ho známe. Pravděpodobně by bylo nutné přehodnotit směr, kterým se standard UML před pár lety vydal. Jedno je však přesto jisté, objektové modelování zaujímá v informačních technologiích a informačních systémech své pevné místo a jen težko, opravdu těžko, lze proti tomu něco namítat.