Seminární práce. Použití CASE pro řízení IS/ICT firmy

Seminární práce Použití CASE pro řízení IS/ICT firmy Vypracovali: Jiří Beran Jakub Erlebach Jan Kapčiar Petr Pobuda Tomáš Šafařík Petr Šťastný Jan Zubíček Předmět: 4IT450 - CASE - Computer Aided Systems Engineering Datum: prosinec 2006

Obsah 1 Úvod...3 1.1 Co jsou CASE nástroje...3 1.2 Řízení IS/ICT...3 2 Teoretická část...4 2.1 Definice řízení IS/ICT...4 2.2 Proč řídit IS/ICT...4 2.3 Proč využívat CASE nástroje při řízení IS/ICT...5 2.4 Výsledný přínos pro organizaci...6 3 Unified Modelling Language (UML)...7 3.1 Historie UML...7 3.2 Způsoby použití UML...7 3.3 UML jako programovací jazyk...8 3.4 UML v řízení IS/ICT...9 3.5 Softwarové produkty pro modelování v UML...13 4 Rational Unified Process (RUP)...14 4.1 Šest nejlepších praktik...14 4.2 Základní model RUP...17 4.3 Vývoj softwaru...18 5 Model Driven Architecture (MDA)...21 5.1 Princip MDA...21 5.2 Standardy MDA...21 5.3 Modely dle MDA...21 5.4 Nač tolik modelů?...23 5.5 Transformace aneb snadno z modelu do modelu...23 5.6 K čemu tedy MDA slouží?...24 5.7 Silné stránky MDA...24 5.8 CASE podporující MDA...25 6 Další přístupy k řízení IS/ICT...32 6.1 ITIL...32 6.2 COBIT...33 6.3 Srovnání ITIL a COBIT...36 7 Případová studie...37 7.1 Představení firmy...37 7.2 Něco z historie...37 7.3 Vývoj IS/ICT...38 7.4 Provoz IS/ICT...40 7.5 Řízení služeb IS/ICT...40 7.6 Plánování projektu IS/ICT...40 7.7 Řízení ekonomiky IS/ICT a metrik...41 7.8 Řízení personálních a datových zdrojů...41 7.9 Informační strategie...41 7.10 Bezpečnostní strategie a politika...41 7.11 Organizace řízení IS/ICT...41 7.12 Tvorba, správa a řízení dokumentace IS/ICT...41 8 Závěr...42 9 Zdroje...43

1 Úvod Tato práce se zabývá možnostmi použití nástrojů CASE pro řízení IS/ICT firmy. Snaží se předložit teoretická východiska, jednotlivé způsoby a přístupy použití CASE pro takovýto účel. Dále také ukázat konkrétní nástroje a ukázku možného použití. Tato práce vychází, rozšiřuje a navazuje na seminární práci na toto téma z letního semestru roku 2006. Z původní práce byla převzata osnova. Obsah jednotlivých kapitol byl přepracován nebo doplněn tak, aby ukazoval více konkrétních příkladů i s použitím ilustrací a aby podrobněji rozepsal jednotlivé teorie, kterých CASE využívá. Kapitola 2 o teorii je převzata z minulé práce a na ní následně navazuje kapitola o UML, která ji vhodně rozšiřuje. Kapitola o MDA obsahuje také část práce převzaté z minulého semestru (podkapitoly 1 až 6). V původní práci z minulého semestru je velmi dobře uvedena charakteristika MDA, jaký je princip MDA a co je její podstatou. Bylo by tedy zbytečné kapitoly celé přepisovat a proto byly doplněny o obrázky, které podtrhují jejich přehlednost a pochopitelnost. Nyní předložíme rychlé shrnutí oblastí, které dále budou podrobně zpracovány v jednotlivých kapitolách. 1.1 Co jsou CASE nástroje Computer-aided software engineering (CASE) se obecně označuje použití softwarových nástrojů pro vývoj a údržbu. Původně pouze vývoj software, nyní i různé jiné oblasti, ve kterých je možné využít výhod jenž CASE nástroje přinášejí. Těmi jsou zejména: generování kódu datové modelování refaktorace kódu transformace modelů správa konfigurací a další 1.2 Řízení IS/ICT Pod pojmem řízení IS/ICT jsou následující činnosti: strategické řízení taktické řízení operativní řízení tvorba, správa a řízení dokumentace IS/ICT Detailnější popis je možno najít v následující kapitole zabývající se teorií. CASE nástroje usnadňují práci na jednotlivých úrovních řízení ve firmě, neboť dokáží flexibilně reflektovat změny a potřeby podniku. Samozřejmostí jsou správně zvolené postupy, nástroje a jejich provázání. Při řízení IS/ICT ve firmě je možnost využití CASE nástrojů pro modelování jednotlivých procesů firmy, tvorby individuálního software pro firmu, který přesně reflektuje procesy firmy, nebo třeba pouze správu hardware, software, konfigurace atd. Nedílnou součástí je správa a údržba dokumentace jednotlivých součástí (aplikací) IS/ICT ve firmě, udržování informací o jejich konfiguraci, datových rozhraních atd. V následujících kapitolách práce budou rozebrány jednotlivé v současnosti pro tyto účely používané nástroje, metodiky a konkrétní software. A předvedeny jejich praktické ukázky a ilustrace.

2 Teoretická část 2.1 Definice řízení IS/ICT Pod řízením IS a ICT budeme v rámci této práce považovat zejména následující činnosti: 2.1.1 Strategické řízení IS/ICT Oblast činností, které jsou realizovány především na úrovni managementu společnosti. Obvykle se jedná o soubor dokumentů, příp. vizí, který definuje dlouhodobější budování IS/ICT ve firmě, základní pravidla, principy a cíle. Tyto aspekty by se pak měli promítnout a realizovat v rámci jednotlivých IS/ICT projektů. Jedná se zejména o: Informační strategie Bezpečnostní strategie a politika Organizace řízení IS/ICT 2.1.2 Taktické řízení IS/ICT Zahrnuje činnosti, které souvisí přímo s vývojem a zaváděním nových prostředků IS/ICT. Jedná se zejména o: Řízení služeb IS/ICT Plánování projektu Řízení ekonomiky IS/ICT a metrik Řízení personálních a datových zdrojů 2.1.3 Operativní řízení IS/ICT Do této oblasti patří jednak běžný provoz a podpora IS/ICT v každodenním běhu firmy. Za druhé se pak jedná o řízení jednotlivých projektů, jejich vzájemných závislostí, kontrola jejich průběhů a plnění cílů. 2.1.4 Tvorba, správa a řízení dokumentace IS a ICT Jako specifickou oblast, která se prolíná všemi jednotlivými typy a úrovněmi řízení pak považujeme dokumentaci všech aspektů IS/ICT a to zejména s důrazem na její tvorbu, správu, persistenci a dostupnost. Další text dokumentu je veden zejména s ohledem na uvedené typy řízení a to v kontextu, jak daný typ je (či není) podporován dostupnými CASE nástroji event. metodikami. 2.2 Proč řídit IS/ICT V současné době je činnost podniků stále více závislá na IS/ICT podniku. Jde tedy o podporu hlavních (core) podnikových procesů procesy informatiky podniku. Důsledkem tedy je, že flexibilita organizace je přímo závislá právě na flexibilitě podnikové informatiky. S rostoucím rozsahem IT podpory pro různé oblasti činnosti organizace zároveň roste množství vazeb a závislostí mezi jednotlivými částmi IS/ICT podniku. Současně neustále rostou požadavky uživatelů podnikových systémů na rychlost implementace změn a nové funkcionality. S přibývajícími změnami v informačních systémech roste komplexita těchto systémů. Postupem času se vedle sebe kupí mnoho dílčích částí informačního systému od různých dodavatelů. Čím větší je komplexita těchto systémů, tím náročnější je IS řídit a tím vyšší a hůře odhadnutelné jsou náklady na integraci jednotlivých částí do správně jednotně pracujícího systému, na údržbu IS

a na drobné změny za provozu. V důsledku komplexity se IS/ICT může snadno stát neovladatelným a nepředvídatelným systémem s fatálními riziky pro chod podniku. Takové změny a rozvoj informačních systémů je nutné nějakým způsobem řídit. Pokud rozvoj podnikových systémů není řízen, dochází k neustálému zvyšování nákladů na IS/ICT, neboť špatně řízené promítání změn do informačních systémů je ve výsledku velmi nákladné. Prvotní promítnutí změny nebo přidání funkcionality se sice zpočátku při takovémto přístupu jako příliš nákladné nejeví, ale velmi záhy se bohužel ukáže potřeba provést ještě další změny, na které se původně zapomnělo, což ve výsledku znamená další úsilí a další náklady. 2.3 Proč využívat CASE nástroje při řízení IS/ICT Spíše než proč využívat CASE nástroje při řízení IS/ICT by na úvod byla vhodnější otázka proč modelovat podnikové IS/ICT. Odpověď je nasnadě. Modelování IS nemá své opodstatnění pouze při vytváření a implementaci těchto systémů. Modely hrají důležitou roli i v případě řízení informatiky, tedy jejím provozu a rozvoji. Jak již bylo uvedeno výše, v dnešní době se díky vývoji IT technologií nesetkáme v případě rozsáhlejších IS se systémem, který by sestával pouze z jedné aplikace od jednoho dodavatele. Současné systémy v sobě zahrnují několik dílčích aplikací od různých dodavatelů, a tak je nutné toto nějakým způsobem řídit. Významným podkladem proto jsou modely informačních systémů. Důležitým faktorem, proč modelování využívat je také další rozvoj a změny IS. Abychom mohli mluvit o řízeném promítání změn do IS, musíme mít jasno, jaké jsou dopady těchto změn. Pokud však máme podnikové systémy "namodelovány" pouze v podobě zdrojového kódu, je taková analýza dopadů velmi obtížná a nespolehlivá. Protože modely procházejí při iterativním návrhu IS a při jeho následném řízení úpravami, je vhodné je vytvářet a upravovat pomocí CASE nástrojů, které je umožňují udržovat v aktuálním stavu. Tyto modely dokumentují stav návrhu v příslušném stádiu a po dokončení systému se stávají součástí finální dokumentace. Vidíme tedy, že řada zdrojů pro dokumentaci je uložena právě v CASE nástrojích. Modelování IS může probíhat na různých úrovních detailnosti, přičemž úplně na vrchol bychom mohli postavit modelování procesů. 2.3.1 BPM (Bussines Process Modeling) Pro celkový pohled na podnikový IS z hlediska dynamiky slouží procesní model. V tomto modelu je především zachycena vazba mezi firemními procesy a aplikacemi, které je podporují. Většina změn v systémech je totiž vyvolána změnami firemních procesů, takže model procesů je výchozím místem zkoumání při analýze dopadů změn. Na základě tohoto modelu jsme tak schopni odvozovat, které systémy budou změnou ovlivněny a v jakém rozsahu. 2.3.2 Model závislostí mezi jednotlivými aplikacemi (moduly, subsystémy) a jejich rozhraní Vzhledem k tomu, že většina podnikových systémů je složena z jednotlivých vzájemně provázaných aplikací od různých dodavatelů, jsou pro údržbu celého systému klíčovými informace o rozhraních aplikací. Základním modelem systému z hlediska jeho struktury je tedy model závislostí mezi jednotlivými aplikacemi (moduly, subsystémy) a jejich rozhraní. Model rozhraní umožňuje provádět analýzu dopadů toho, jak změna jednoho systému ovlivní další systémy. Závislosti mezi aplikacemi podnikového IS jsou na tomto modelu zobecněním komunikace, která probíhá na úrovni rozhraní systémů. 2.3.3 Detailní modely aplikací Jednotlivé systémy je pak možné detailněji modelovat pomocí tradičních UML modelů, jako je

model tříd nebo model interakcí. Vytvoření a údržba těchto detailních modelů je samozřejmě podstatně nákladnější a vyplatí se u systémů, které jsou buď intenzivně rozvíjeny nebo při novém vývoji. 2.3.4 Dokumentace Dokumentace hraje důležitou roli již v procesu vývoje programového systému. Jednotlivé fáze vývoje je třeba dokumentovat a každá fáze má většinou definovány určité výstupní dokumenty (záleží na zvolené metodice vývoje IS). Díky dokumentaci tak máme dokonalý přehled o tom, kde, co a jak je implementováno. Právě zde se naskytuje možnost využití dokumentačních nástrojů zvoleného CASE nástroje. Jednou z hlavních předností modelování IS/ICT pomocí CASE nástrojů a jejich následného využití při řízení informatiky, je schopnost těchto nástrojů generovat a udržovat aktuální dokumentace systému, které jsou vždy (nebo by tomu tak alespoň mělo být) nedílnou součástí aplikací. Nejen že tyto systémy jsou schopné dokumentaci jednorázově vygenerovat, ale jsou ji rovněž schopny udržovat v aktuálním stavu dle provedených změn v modelech systému. Většina současných strukturovaných i objektově orientovaných CASE prostředků má v sobě totiž integrované prostředky pro tvorbu všech typů dokumentace vznikající v různých fázích životního cyklu. Nejedná se zpravidla jen o pouhý tisk diagramů vyskytujících se na obrazovce, nýbrž o dokonale hierarchicky zpracovanou dokumentaci ve formě přehledových sestav, detailních popisů entit, atributů, relačních a dědičných vztahů a toto vše teprve doplněno jednotlivými diagramy. 2.3.5 Model jako komunikační nástroj Protože na vývoji i na následném řízení IS pracuje několik lidí, jsou modely nezbytné i jako komunikační prostředek mezi nimi. Jednak jsou součástí finální dokumentace systému a jednak jsou přístupné pomocí CASE nástrojů. Celkový model podnikového IS je také velmi užitečným podkladem pro komunikaci s dodavateli jednotlivých aplikací při zadávání požadavků na funkcionalitu dodávaných aplikací. 2.3.6 Audit IS/IT CASE nástroje, potažmo dokumentace a vytvořené modely jsou také důležitým podkladem pro audit informačních systémů. 2.4 Výsledný přínos pro organizaci Nasazení systematičtějšího přístupu nastíněného výše, který je navíc podpořen nástrojem CASE usnadňujícím vytváření a údržbu příslušných modelů, vede zpravidla ke znatelným úsporám nákladů na rozvoj a údržbu podnikového IS/ICT. Tyto úspory jsou však nejen finančního charakteru, který vyplývá z toho, že změny se daří úspěšně realizovat na první pokus, ale i charakteru praktického, neboť používání CASE nástrojů a modelování všeobecně vede k přehlednosti a transparentnosti informačního systému.

3 Unified Modelling Language (UML) V této části bychom se rádi zabývali modelovacím jazykem UML. Tento grafický modelovací jazyk tvoří standardní nástroj pro specifikaci, vizualizaci, výstavbu a dokumentování částí softwarových systémů. Rozšíření jeho využití a také jeho zahrnutí do dalších metodik nás vede k tomu, věnovat mu alespoň základní popis jeho využití při řízení IS/ICT. Unified Modeling Language je v softwarovém inženýrství grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů. UML nabízí standardní způsob zápisu jak návrhů systému včetně konceptuálních prvků jako jsou business procesy a systémové funkce, tak konkrétních prvků jako jsou příkazy programovacího jazyka, databázová schémata a znovupoužitelné programové komponenty. UML podporuje objektově orientovaný přístup k analýze, návrhu a popisu programových systémů. UML neobsahuje způsob, jak se má používat, ani neobsahuje metodiku(y), jak analyzovat, specifikovat či navrhovat programové systémy. 3.1 Historie UML Vývoj UML začal v roce 1994, kdy Grady Booch a Jim Rumbaugh začali ve firmě Rational Software (nyní součást firmy IBM) spojovat své metodiky Booch a OMT (Object Modeling Technique). Na konci roku 1995 do firmy Rational Software vstoupil Ivar Jacobson se svojí metodologii OOSE (Object-Oriented Software Engineering). Výsledkem jejich práce byl návrh UML (verze 0.9) a metodika RUP (Rational Unified Process viz dále v textu). Standardizační organizace OMG v roce 1997 přijala jako standard UML verze 1.1 ve které byly začleněny prvky z dalších metodik (označení UML 1.0 se používá pro návrh, který poslala firma Rational Rose standardizační komisi). Postupně se upřesňovala specifikace a vznikaly další verze 1.2 (1998), 1.3 (1999), 1.4 (2001) a 1.5 (2002). Větší změny byly začleněny do verze 1.3. Od roku 2001 OMG připravuje verzi 2.0, která přináší podstatná rozšíření. Text první části (SuperStructure) byl schválen na podzim 2004, ale ještě není dokončena formální úprava dokumentu. Další části specifikace UML jsou připraveny k závěrečnému hlasování. 3.2 Způsoby použití UML 3.2.1 Kreslení konceptu Při tomto použití je UML podpůrným nástrojem pro komunikaci mezi vývojáři a pro zaznamenání myšlenek a návrhů. Do diagramů se kreslí pouze věci podstatné pro grafické vyjádření návrhu, části návrhu před tím, než se začne programovat. Důležitá je srozumitelnost, rychlost nakreslení a snadnost změny či navržení alternativ řešení. 3.2.2 Kreslení detailních návrhů Cílem je zaznamenat kompletní návrh či kompletní realizaci. Při kreslení návrhu by měl analytik obsáhnout všechny prvky tak, aby programátor byl schopen vytvořit program bez velkého přemýšlení nad věcnou oblastí (pro programátora by neměla vzniknout potřeba konzultace s uživatelem). Při kreslení detailních návrhů se obvykle používají specializované programy (CASE), které jsou schopny sdílet informace mezi jednotlivými modely a kontrolovat konzistenci návrhu. Při dokumentaci programu se často používání nástroje pro generování diagramů z vlastního kódu aplikace.

3.3 UML jako programovací jazyk Při tomto použití vývojář nakreslí UML diagramy, ze kterých se vygeneruje přímo spustitelný kód. Toto vyžaduje specializované nástroje a velmi přesné vyjadřování v UML diagramech. V této souvislosti se velmi často používá pojem Model Driven Architecture (MDA), což je další standard skupiny OMG, který se snaží standardizovat použití UML jako programovacího jazyka. 3.3.1 Metamodel Tento pohled používají autoři UML a autoři CASE nástrojů - nedívají se na UML jako na diagramy, pro ně je základem UML metamodel (diagramy jsou pouze grafickou reprezentací metamodelu). Při tomto přístupu se často používá pojem model místo pojmu diagram, např. místo diagramu tříd se používá pojem model tříd. Metamodel se popisuje pomocí Meta-Object-Facility (MOF) abstraktního jazyka pro specifikaci, vytváření a správu metamodelů (další standard OMG). Pro výměnu metamodelů se používá XMI - na XML založený standard (součást standardu UML). 3.3.2 Diagramy Diagramy jsou nejznámější a nejpoužívanější částí standardu. Následuje přehled diagramů v UML 2.0 včetně jejich rozčlenění do skupin: Strukturní diagramy: diagram tříd (class diagram) diagram komponent (component diagram) composite structure diagram diagram nasazení (deployment diagram) diagram balíčků (package diagram) diagram objektů (object diagram), též se nazývá diagram instancí Diagramy chování: diagram aktivit (activity diagram) diagram užití (use case diagram) stavový diagram (state machine diagram) diagramy interakce:

sekvenční diagram (sequence diagram) diagram komunikace (communication diagram, dříve collaboration diagram) interaction overview diagram diagram časování (timing diagram) Standard UML ve verzi 2.0 se skládá ze čtyř částí: UML 2.0 SuperStructure popis UML z hlediska uživatele (analytik/programátor). Tato část popisuje jednotlivé diagramy. UML 2.0 Infrastructure metamodel stojící v pozadí za UML, specifikovaný pomocí Meta-Object Facility (MOF). UML 2.0 Object Constraint Language (OCL) jazyk pro specifikaci vstupních a výstupních podmínek, invariantů v jednotlivých diagramech. UML 2.0 Diagram Interchange popis XML struktur pro výměnu konkrétních modelů mezi jednotlivými modelovacími nástroji. 3.4 UML v řízení IS/ICT V následující sekci se zaměříme na popis využití jazyka UML při řízení IS/ICT v podniku, především pak na představení jednotlivých diagramů. Přestože by tato sekce mohla popisovat všechny aspekty jazyka UML, včetně jeho využití při vývoji nových aplikací, zaměříme se spíše na ty aspekty tohoto modelovacího jazyka, které je možné využít při řízení IS/ICT ve své celistvosti, na určité globálnější úrovni. Zájemce o využití jazyka pro samostatný vývoj software odkážeme na práce zabývající se právě touto činností. Během popisu se zaměříme na aktuální verze (2.x) jazyka s vyznačením důležitých rozdílů oproti starším verzím (řady 1.x). 3.4.1 Strukturální diagramy Strukturální diagramy se logicky zabývají strukturou modelovaného objektu. Zaměřují se tedy na statické vztahy mezi jednotlivými entitami v modelovaném objektu. Z výčtu obsaženého v předchozí části se zaměříme především na tyto diagramy: diagram komponent (component diagram) diagram nasazení (deployment diagram) diagram balíků (package diagram) Diagram komponent Zatímco v UML 1.x byl komponentový diagram využíván především ve fázi implementace je v UML verze 2.0 a výše kladen důraz především na využití komponentového diagramu ve fázi modelování. Tento diagram slouží pro zachycení komponent v systému, tedy autonomních prvků, které spolu komunikují pouze pomocí svých pevně definovaných rozhraní. Tato autonomita dělá z diagramu komponent vhodný prvek pro spolupráci mezi různými týmy. Přestože hlavní význam má diagram stále pro implementátory systému, kterým usnadňuje koordinaci práce, zůstává jeho důležitost pro všechny zainteresované skupiny v celistvém pochopení kompletního systému IS/ICT a jeho organizace.

Ilustrace 1: Diagram komponent (zdroj: http://www.agilemodeling.com/artifacts/componentdiagram.htm) Diagram nasazení Diagram nasazení slouží k zachycení statického zobrazení systémové implementace zobrazuje hardware, vyskytující se v systému, jaké softwarové komponenty na něm běží a v neposlední řadě vztahy mezi těmito prvky. Jak v UML1, tak v UML2 jsou hlavními prvky uzly, představující hardware. Avšak zatímco v UML1 jsou softwarové komponenty zakreslovány přímo do uzlů, používá UML2 navíc podřazené uzly a artefakty, které sdružují jednotlivé komponenty a představují běhové prostředí, ve kterém tyto komponenty běží (J2EE server atp.). Jak vidno, poskytují diagramy nasazení vhodný prostředek pro zachycení celkového stavu IS/ICT, jeho řízení a také řízení změn a vývoje. Ilustrace 2: Diagram nasazení (zdroj: http://en.wikipedia.org/wiki/image:uml_deployment_diag ram.gif)

Diagram balíků Diagramy balíků slouží k popisu toho, jakým způsobem jsou systémy rozděleny a organizovány do balíků vzájemně souvisejících komponent a k zachycení vztahů mezi těmito skupinami. Nejběžnější použití slouží k organizaci jednotlivých diagramů tříd či diagramů užití, z našeho pohledu je však důležitější možnost tento druh diagramu použít k abstraktnímu rozdělení systému na vzájemně co nejméně závislé, ale vnitřně co nejvíce soudržné balíky, a na základě tohoto usnadnit řízení a rozdělení zodpovědnosti za jednotlivé balíky. Ilustrace 3: Diagram balíků (zdroj: http://en.wikipedia.org/wiki/image:package_diagram.jpg) 3.4.2 Diagramy chování Zatímco první popisovaná skupina diagramů se zaměřovala na statický popis systému, zaměřují se diagramy chování dynamiku systému na to, co se v systému děje. Tato skupina obsahuje tři druhy diagramů, ze kterých se budeme věnovat těmto:: diagram aktivit (activity diagram) diagram užití (use case diagram) diagramy interakcí Diagram aktivit Diagram aktivit umožňuje zachytit pracovní postupy jako sled kroků vyvolaných určitou podmínkou a vedoucích k určitému cíli (cílům, případně žádnému cíli). Jde jim tedy o zobrazení business procesu případně pracovního postupu. Verze UML2 přinesla diagramům aktivit několik novinek: Především jde o větší možnosti v oddělení, popisu a hierarchického řazení jednotlivých oddílů diagramu.

Ilustrace 4: Diagram aktivit (zdroj: http://zubicek.eu/skola/novinky-ve-specifikaci-uml2/) Diagram užití Diagramy užití identifikuje systém jako souhrn elementů aktorů a procesů. Procesy jsou zde nazývány užití (use case). Zatímco tedy předchozí model popisoval samotné business procesy, tento diagram zachycuje systém těchto procesů a zároveň role, které v systému vystupují. Diagramy užití jsou vhodným prostředkem pro modelování systému během setkání s uživateli. Kromě toho také umožňují vytváření testů modelu. V každém případě jsou dobrým způsobem, jak zachytit procesy ve firmě jako východisko pro modelování IS/ICT. Ilustrace 5: Diagram užití (zdroj: http://en.wikipedia.org/wiki/image:restaurant-uml-uc.png)

Diagramy interakcí Diagramy interakcí jsou podskupinou diagramů chování, zaměřují se na komunikaci mezi prvky systému a také na to, jakým způsobem je předáváno řízení systému. Z našeho pohledu asi nejdůležitějším diagramem z této skupiny je sekvenční diagram. Tento diagram umožňuje zachycení procesů (přičemž souběžné procesy jsou zakresleny na vertikále) a výměnu informací mezi nimi (jako horizontální čáry). Jejich použití se týká modelování, analýzy a dokumentování následujících aspektů našeho systému: scénáře užití jakými způsoby může být náš systém užíván funkční logika systému popis služeb systému Obohacením sekvenčního diagramu, které přineslo UML2, je možnost zaznamenat varianty procesu. Ilustrace 6: Variace v sekvenčním diagramu (zdroj: http://zubicek.eu/skola/novinky-ve-specifikaci-uml2/) 3.5 Softwarové produkty pro modelování v UML Vzhledem k tomu, že UML je standardizovaný jazyk, nejsou tvůrci modelovacích nástrojů nijak omezováni v jeho implementaci. Proto je na trhu k dispozici velké množství produktů. Mnohé jsou dokonce zdarma či spadají do oblasti open-source software. U software pro modelování v UML je možné v poslední době zaznamenat příklon k využití programovacího IDE frameworku nadace Eclipse (jejími členy jsou např. IBM, Borland, Google...). Framework Eclipse využívají například nástroje Apollo for Eclipse, Borland Together nebo Rational Software Architect. Z open-source projektů můžeme jmenovat například nástroje Dia a Umbrello UML Modeller. Další komerční produkty zahrnují mimo jiné Poseidon for UML, Microsoft Visio či Sparx Enterprise Architect.

4 Rational Unified Process (RUP) Rational Unified Process je metodika pro vývoj softwarových řešení a projektů vytvořená společností Rational Software Inc. Podnětem pro vznik této metodiky byla neuspokojivá bilance úspěšností softwarových projektů. Metodika je založena na rozsáhlých praktických poznatcích byly prozkoumány a zevrubně zanalyzovány tisíce projektů renomovaných firem. Na základě výsledků analýz, zaměřených zejména na nalezení příčin neúspěšnosti zkoumaných projektů. Byly identifikovány postupy a opatření umožňující efektivně tyto příčiny eliminovat nebo alespoň omezit jejich dopad. Tato opatření byla shrnuta do šesti ucelených souborů doporučení, které se nazývají Nejlepší praktiky softwarového vývoje. RUP zahrnuje zapracování šesti nejlepších praktik do konkrétních návodů a postupů. Metodika jako taková pokrývá globálně proces softwarového vývoje a současně poskytuje návody a doporučení na detailní úrovni. Při zpracování a pro implementaci metodických postupů uživateli poskytuje i odpovídající konstrukce vycházející ze standardního jazyka pro modelování Unified Modelling Language (UML). RUP je ve své obecnosti a úplnosti ideální pro malé i velké organizace, především pro ty, které nemají zavedeny standardní mechanismy procesu vývoje. Čtyři základní role RUPu: Poskytuje návod k činnosti pracovního týmu Určuje, které artefakty a kdy mají být vytvořeny Slouží k řízení úkolů jednotlivců i týmu jako celku Nabízí kritéria pro monitorování a hodnocení činností a výsledků projektu 4.1 Šest nejlepších praktik Selhání při nasazení informačních technologií má mnoho příčin. Může to být špatné pochopení potřeb uživatelů, neschopnost vypořádat se s měnícími se požadavky, nekompatibilita modulů nebo náročná podpora a rozšiřování informačního systému. Mezi další příčiny patří pozdní rozpoznání chyb projektu, nízká kvalita a nepřijatelný výkon, nedostatečné řízení změn (informace nejsou zpětně dohledatelné) nebo nespolehlivý proces zavedení systému do provozu. Časté příčiny problémů: Nedokonalá správa požadavků a nejasná komunikace Křehkost a složitost architektury Neadekvátní testování Nepředcházení rizikům Nekontrolovatelné provádění změn Nedostatečná automatizace Většina softwarových projektů, vyvíjených na celém světě, nekončí úspěšně. Projekty jsou buď předčasně zastaveny, je přečerpán stanovený rozpočet, nejsou dodrženy termíny nasazení nebo výsledný informační systém nesplňuje požadavky zadavatele. Proto byl definován soubor principů, metod a procesů, které zvyšují kvalitu a produktivitu softwarového vývoje a zásadním způsobem ovlivňují úspěšnost projektu. Jsou to následující praktiky : Iterativní vývoj Správa požadavků Komponentová architektura Vizuální modelování Ověřování kvality Řízení změn

4.1.1 Iterativní vývoj Při vývoji velkých informačních systémů často narážíme na problémy způsobené neadekvátní délkou projektu. Značná část chyb je odhalena až v poslední fázi projektu (při nasazování systému), kdy je už většina finančních prostředků vyčerpána. Naproti tomu iterativní vývoj pomáhá identifikovat rizika v každém stádiu životního cyklu, a tím značně snižuje náklady na jejich odstranění. Celý proces je rozdělen do několika iterací, kdy každá z nich končí spustitelnou verzí. Výhody iterativního vývoje: Koncentrace na klíčové problémy Průběžné odstraňování chyb Možnost objektivního posouzení aktuálního stavu projektu Včasné odhalení nesrovnalostí mezi požadavky, návrhem a implementací Pracovní zatížení je rovnoměrné Možnost testování meziverzí, zpětná vazba od uživatelů Obrázek 1 - Vodopádový životní cyklus projektu Iterativní vývoj je následně detailně rozebrán v kapitole Vývoj Softwaru. 4.1.2 Správa požadavků Požadavek je podmínka nebo schopnost, kterou musí systém splňovat. Standardně se předpokládá, že na začátku vývoje jsou posbírány všechny požadavky, které jsou poté vyhodnoceny a zapracovány do projektové dokumentace. Další změna požadavků se zpravidla nepřipouští. Takový přístup neodráží chování reálného světa a bývá příčinou špatného hodnocení celého projektu. Proto je nutné hledat postupy, které umožní řídit změny požadavků v průběhu vývoje softwaru. Správa požadavků zahrnuje: Zjištění požadované funkčnosti a omezení systému Zpracování detailní dokumentace Vyhodnocování změn požadavků a jejich důsledků

Dokumentace jednotlivých rozhodnutí 4.1.3 Komponentová architektura Vytvoření pružné architektury je důležité především z hlediska jasného rozdělení úkolů mezi jednotlivé týmy. Spolu s iterativním vývojem softwaru přispívá komponentová architektura k postupné tvorbě systémové architektury. Tento přístup pak usnadňuje identifikaci rizik a jejich odstranění již v samotném procesu vývoje. Přínosy: Podpora vývoje založeného na komponentách Systematický přístup k definování architektury Podpora standardních komponentových infrastruktur (CORBA, COM) 4.1.4 Vizuální modelování Model je kompletní popis systému z určitého pohledu. Modelování pomáhá zpřehlednit, specifikovat, zkonstruovat a z dokumentovat strukturu a chování systémové architektury. K jednomu systému vytváříme zpravidla více modelů. Díky standardnímu modelovacímu jazyku, jako je například UML, mohou jednotliví členové týmů mezi sebou srozumitelně komunikovat a předávat si informace bez ohledu na fázi vývoje. Výhody: Zachovává strukturu a chování architektury a komponent Ukazuje, zda jsou jednotlivé prvky kompatibilní Skrývá nebo odkrývá detaily podle potřeby Podporuje konzistenci mezi návrhem a implementací 4.1.5 Ověřování kvality Po dodání softwaru je velmi obtížné a nákladné opravit dodatečně nalezenou chybu. Proto je důležité nepřetržitě hlídat kvalitu produktu, a to s ohledem na jeho funkčnost, spolehlivost, výkon aplikace a celého systému. Při kontrole kvality jsou odhaleny nesoulady mezi požadavky, návrhem a implementací. Testování a kontrola se zaměřují na oblasti s nejvyšším rizikem, což zvyšuje jejich kvalitu a efektivitu. Chyby jsou odhalovány dříve, což snižuje náklady na jejich odstranění. Obrázek 2 - Náklady na odstranění chyb v čase Přínosy: Hodnocení kvality je zabudováno do procesu, do každé činnosti Používá objektivní míry a kritéria Objektivně hodnotí stav pomocí výsledků testování

4.1.6 Řízení změn Klíčovým úkolem při vývoji softwaru je dosáhnout efektivní koordinace všech aktivit a artefaktů tak, aby bylo možné opakovaně využívat standardní pracovní metody a reagovat na změny. Tím dosáhnout lepší alokace zdrojů. Práce je řízena dle priorit a rizik. RUP popisuje jak kontrolovat, sledovat a monitorovat změny a umožnit úspěšný iterativní vývoj. Řeší také paralelní vývoj různých verzí softwaru a správu buildů. Výhody: Postup řešení požadavků na změny je definovaný a opakovatelný Požadavky na změny zajišťují bezproblémovou komunikaci Vhodná metrika pro objektivní posouzení stavu projektu Změny jsou prováděny kontrolovatelně 4.2 Základní model RUP RUP definuje kdo, jak, kdy a co dělá. K tomu používá čtyři základní prvky: Osoby Aktivity Artefakty Pracovní postupy Mezi prvky existují tyto základní vztahy Osoba definuje chování a odpovědnost jednotlivce nebo týmu Chování je vyjádřeno aktivitou, kterou osoba vykonává. Každá osoba je spojena se souborem aktivit. Odpovědnost každé osoby je vyjádřena ve spojení s artefaktem, který osoba vytváří, upravuje nebo kontroluje. 4.2.1 Osoba Osobu si můžeme představit jako roli v divadelní hře. Jeden člověk může hrát ve více rolích a naopak do jedné role může být obsazeno více lidí. Tato odlišnost je důležitá, protože je přirozené myslet osobou jednotlivce nebo tým. V RUPu osoba definuje, jak má jednotlivec (který je do ní obsazen) dělat svojí práci a jakých artefaktů je vlastníkem. Toto rozdělení má na starosti projektový manažer, který plánuje projekty a jejich personální obsazení. Příklad: Systémový analytik (řídí a koordinuje proces zpracování požadavků), Návrhář (vytváří model tříd a určuje, jak mají být zakomponovány do implementačního prostředí) 4.2.2 Aktivita Aktivita je jednotka práce, která může být osobě přidělena. Aktivita má jasný cíl, většinou se jedná o tvorbu nebo správu artefaktů. Každá aktivita je přidělena specifické osobě. Aktivita musí být použitelná jako prvek plánování. Pokud je příliš malá, může být opomenuta a pokud je naopak příliš velká, lze pokrok vyjádřit po částech aktivity. V objektově orientované terminologii je osoba aktivní objekt. Aktivity, které osoba vykonává, jsou pak operace vykonávané tímto objektem. Příklad: Plánování vývojové iterace (provádí projektový manažer), nalezení případů užití (systémový analytik) 4.2.3 Artefakt Artefakt představuje informaci, která je vytvořena, modifikována a používána v procesu vývoje. Je hmatatelným výsledkem projektu. Artefakty jsou používány jako vstup pro vykonávání aktivity určitou osobou a jsou cílem nebo výstupem takovéto aktivity. Artefakty nemusí být vždy dokumenty. Efektivnější je tvorba artefaktů vhodnými nástroji. Pokud je to nutné, lze dokumenty generovat pomocí těchto nástrojů. Takovéto dokumenty jsou pak založeny na aktuální verzi artefaktů.

Příklad: model případu užití, plán projektu, zdrojový kód. Spustitelný program, databáze požadavků 4.2.4 Pracovní postupy Pouhý výčet všech osob, aktivit a artefaktů ještě nevytváří proces. Je třeba najít způsob, jak popsat posloupnost aktivit, které produkují hodnotné výsledky a ukazují interakce mezi osobami. Pracovní postup je posloupnost aktivit, které přinášejí předem definované výstupy. Často není možné znázornit všechny závislosti mezi aktivitami, zvláště jsou-li velmi úzce propojeny a týkají-li se stejné osoby či jednotlivce. Postupy týkající se následného odvozování jednotlivých artefaktů můžeme pak popsat v detailu pracovního postupu. Příklad : Analýza architektury (Architekt) -> Analýza případu užití (Business Analytik) -> Analýza objektů (Návrhář) -> Revize analýzy (Revizor návrhů) Obrázek 3 - Příklad pracovního postupu 4.3 Vývoj softwaru Iterativní vývoj softwaru vychází z dnes běžně používaného sekvenčního procesu vývoje (tzv. vodopád). Ten funguje u malých projektů, ale způsobuje problémy u rozsáhlých řešení. Proto úlohu poněkud upravíme. Velký projekt rozdělíme na řadu malých částí (vodopádů). V každé fázi nejdříve získáme požadavky, vytipujeme rizika, navrhneme řešení, adekvátní část implementujeme a ověříme. Poté zapracujeme další požadavky, navrhneme rozšíření, zapracujeme jej a opět ověříme. To je podstata iterativního vývoje. RUP předpokládá 4 základní fáze, každá z nich je ukončena milníkem, tj. okamžikem, kdy rozhodujeme, zda ve vývoji pokračovat, změnit postup nebo jej ukončit. Fáze a jejich milníky: Počáteční fáze (milník: rozsah systému) Elaborace (milník: architektura systému) Konstrukce (milník: beta verze systému) Zavedení (milník: nasazení produktu) 4.3.1 Počáteční fáze V této fázi je založen obchodní případ a určen rozsah projektu. Je nutno identifikovat prvky, s nimiž bude systém komunikovat a definovat povahu těchto prvků, což znamená identifikovat všechny

případy užití a popsat několik nejvýznamnějších z nich. To vše se děje na základě vyhodnocování požadavků a omezení systému, stanovení kritérií, která systém musí splňovat, zvážení možných alternativ v poměru cena/termín/výkon, definování použitelných architektur a komponent a rozhodnutí, co se vyrobí/koupí/znovu použije. Výstupem této fáze je: Vize, tj. dokument obsahující vizi klíčových požadavků projektu, jeho hlavní rysy a omezení Model případů užití Počáteční obchodní případ (finanční rozpočet, kritéria úspěchu ) Počáteční ohodnocení rizik Plán projektu Na konci počáteční fáze se objevuje první milník projektu: Rozsah systému. Jeho smyslem je navodit konsenzus mezi osobami zodpovědnými za realizaci projektu a objektivně prokázat, že projekt je realizovatelný v navržené kvalitě, kvantitě, termínu a rozpočtu. 4.3.2 Elaborační fáze Cílem této fáze je analyzovat klíčové problémy, vyvinout základy architektury, vytvořit plán projektu a odhadnout nejrizikovější prvky projektu. Součástí elaborace je navržení funkčního prototypu architektury. Toto úsilí by se mělo zaměřit především na kritické případy užití, identifikované v počáteční fázi, které typicky zahrnují hlavní technická rizika projektu. Dá se říci, že tato fáze je nejrizikovější ze všech čtyř fází. Na jejím konci nastává důležitý okamžik, kdy se rozhodne o pokračování projektu. Výstupem této fáze je: Model případu užití Dodatečné požadavky Popis softwarové architektury Spustitelný prototyp architektury Revidovaný seznam rizik a revidovaný obchodní plán Vývojový plán pro celý projekt (včetně hrubého plánu s iteracemi a hodnotícími kritérii pro každou iteraci) Aktualizovaný vývojový případ s popisem procesu, který se má použít Předběžný uživatelský manuál V tomto dalším důležitém okamžiku se prověřují detailní vlastnosti systému a jeho rozsah. Klíčovými úkoly jsou výběr architektury a odstranění hlavních rizik vyřešením technologických problémů nebo zvolením alternativních postupů. 4.3.3 Konstrukční fáze Během této fáze jsou navrženy všechny zbývající komponenty a vlastnosti aplikace, jsou vyvinuty a integrovány do produktu. Všechny vlastnosti systému jsou důkladně otestovány. Konstrukční fáze je výrobním procesem, v němž se klade důraz na řízení zdrojů a kontrolu kvality, kvantity, termínu a rozpočtu. Jednou z nejdůležitějších kvalit architektury je jednoduchost její konstrukce, proto je vyzdvihován vyvážený vývoj architektury a plánu během elaborační fáze. Výstup z konstrukční fáze je připraven k předání koncovým uživatelům. Výstupem této fáze je: Softwarový produkt integrovaný na odpovídajících platformách Uživatelský manuál Popis současné verze Na konci konstrukční fáze je třetí milník projektu: Beta verze. V tomto okamžiku prověřujeme, zda software, provozní prostředí a uživatelé jsou připraveni k nasazení systému do provozu, aniž bychom zúčastněné strany vystavovali velkým rizikům. V případě, že se nepodaří dosáhnout tohoto

milníku, musí být zavedení odloženo a je naplánována náhradní verze, která odstraní rizika nasazení systému do provozu, případně musí být upraven plán nasazení. 4.3.4 Nasazení Tato fáze se zaměřuje na činnosti potřebné k předávání softwaru do provozního prostředí. Zpravidla zahrnuje několik iterací (třeba akceptační testy, pilotní provoz atp.) včetně servisních buildů, patchů či hotfixů řešících nalezené chyby. Velké úsilí je vynaloženo na přípravu uživatelské a servisní dokumentace, školení uživatelů a podporu uživatelů. Tato fáze zahrnuje: Beta testování a pilotní provoz Paralelní nasazení společně s nahrazovaným systémem Konverzi operačních databází Školení administrátorů a správců, případně též uživatelů Předání systému do rutinního provozu V tomto okamžiku se rozhodne, zda byly dosaženy stanovené cíle a zda je možno začít práci na jiném vývojovém cyklu. V některých případech se tento milník kryje s ukončením počáteční fáze dalšího cyklu. Důležitá je správná funkčnost komunikačního kanálu mezi servisním týmem a koncovými uživateli. Do servisního týmu je vhodné zařadit několik lidí z vývoje. Ti zaškolí ostatní a poté se mohou vrátit zpět do realizace.

5 Model Driven Architecture (MDA) Model Driven Architecture byla zveřejněna v roce 2001 a již nyní získala velký vliv na metody vývoje aplikací. V současné době existuje přinejmenším 40 nástrojů, které podporují alespoň jeden z hlavních aspektů MDA. Jedná se o koncept standardizující modely, které jsou v průběhu vývoje aplikace vytvářeny a definující způsoby mapování mezi nimi. Proto také název, který by se dal přeložit jako Modelem řízená architektura, zkráceně MDA. MDA není ve své podstatě převratnou novinkou, nakonec otázkou členění modelů se zabývá každý rozumná metodika softwarového vývoje, nicméně podstatné je to, že toto členění standardizuje a dále definuje způsob transformace jednoho modelu v druhý. Koncept MDA sice úzce souvisí s UML, avšak není na tento modelovací standard bezprostředně vázaný, neboť se dá aplikovat i jiným způsobem modelování než je UML. 5.1 Princip MDA Princip MDA je velmi jednoduchý, spočívá v oddělení business logiky od technologie platformy. Platformou se rozumí sada subsystémů nebo technologií, které zajišťují logickou sadu rozhraní a vzorů, které může jakákoliv aplikace využívat bez potřeby vědět, jak je která funkce, poskytována platformou, implementována. Toto umožňuje realizovat aplikace vytvořené pomocí MDA v celé řadě otevřených platforem jako např. CORBA, J2EE,.NET a jiných webových platformách. Nezávislost na platformě nabývá významu tím více, čím rychleji jsou vytvářena nové a nové technologie. 5.2 Standardy MDA Technologický základ MDA zahrnuje souhrn metodik, které umožnily modely řízený přístup. Mezi tyto metodiky patří UML, MOF, specifické modely a UML profily (např. EDOC) Všechny UML specifikace jsou dostupné na http://www.omg.org/technology/documents/index.htm. UML (Unified Modeling Language) je standardním modelovacím jazykem pro vizualizaci, specifikaci a dokumentaci softwarových systémů. UML 2 integruje sadu komponent pro kompletní specifikaci chování objektů (http://doc.omg.org/formal/03-03-0). MOF (Meta-Object Facility) technologie nabízí repozitory modelů, které mohou být využity pro specifikaci a tvorbě modelů, též k zajištění konzistence ve všech fázích MDA využití (http://doc.omg.org/formal/02-04-03). Profily UML jsou rozšířeními UML nitifikace. Vznikají přidáním nových druhů elementů jazyka za účelem určité restrikce či specifikace. Jakýkoliv model vytvořený v UML profilu je stále UML modelem. Přitom jej lze transformovat do UML. 5.3 Modely dle MDA MDA vidí modely aplikací ve čtyřech úrovních: CIM model nezávislý na počítačovém zpracování PIM platformově nezávislý model řešení PSM platformově specifický model řešení Code kód aplikace, tj. výsledná realizace řešení 5.3.1 CIM Computation Independent Model Model nezávislý na počítačovém zpracování je de facto modelem vlastního businessu, čili činností, které musí vykonávat pracovníci firmy aby tato mohla fungovat. Model CIM tedy znázorňuje tyto činnosti a obvykle se také nazývá model firemních procesů. Celkem pikantní je, že notace modelu CIM není v UML plně standardizována (a to ani v chystané verzi UML 2.0). Tento model vytvářejí buď sami uživatelé nebo business analytici. Model CIM je při vývoji a údržbě důležitý především pro to, aby vývojáři pochopili činnosti uživatele a chápali příslušné souvislosti. Navíc je to jediný model, který lze bez obav předložit

běžnému uživateli a ten je schopen ho po krátkém vysvětlení pochopit a především se k němu vyjadřovat. Další modely totiž nejsou pro uživatele snadno pochopitelné a jsou určeny především vývojářům. 5.3.2 PIM Platform Independent Model Platformově nezávislý model reprezentuje koncepci řešení dané problémové oblasti na základě konkrétních požadavků. Jeho hodnota je především ve vyřešení koncepčních otázek, jako jsou třeba algoritmy zaskladňování a vyskladňování v případě skladů, nebo způsob párování saldokontních položek v účetnictví. Tento model však neobsahuje informace spojené s konkrétní technologií realizace a vytvářejí ho IT analytici. Platformově nezávislý model umožňuje vyřešit určitou oblast na obecné úrovni a teprve pak zvažovat konkrétní technologii pro vlastní realizaci. Dalším důležitým aspektem pro vytváření PIM modelu je to, že je cca 3x jednodušší než model, který již specifické technologické informace obsahuje a tudíž se v tomto modelu snadno zorientuje analytik, který obvykle nemá (ani to není žádoucí) detailní technologické znalosti. 5.3.3 PSM Platform Specific Model Model řešení na dané platformě (např. J2EE nebo C# a ASP.NET) je podkladem pro vlastní implementaci. Z hlediska vztahu ke kódu je důležité to, že PSM má stejnou strukturu jako kód aplikace. Tento model vytvářejí návrháři. Na následujícím obrázku je zachycena hierarchie jednotlivých modelů. Samozřejmě je možné zpětné generování na úrovňově jednodušší model. Viz dále. Obrázek 4: Hierarchie modelů 5.3.4 Code Z hlediska MDA je zdrojový kód chápán také jako model konkrétní realizace na dané platformě. Konec konců určitě znáte ze svého okolí aplikace, kde jedině tento model skutečně odpovídá realitě toho, co aplikace dělá.

5.4 Nač tolik modelů? MDA tedy doporučuje při tvorbě a údržbě aplikací vytvořit a udržovat tyto čtyři modely, neboť se tím výrazně zjednoduší údržba a rozvoj aplikace. Podívejme se nyní proč. Udržování CIM modelu umožní vývojářům analyzovat dopady změn v činnostech uživatele na příslušnou aplikaci. Vezměme si jako příklad jarní změnu zákona o DPH. V tomto zákoně je například příchod platby považován za zdanitelné plnění a je nutné k ní vystavit daňový doklad. Implementovat do stávající ekonomické aplikace automatické vystavování daňového dokladu při příchodu platby se může zdát triviální záležitostí. Pokud však není jasné, kdo bude tento doklad odesílat zákazníkovi, zda ho bude odesílat vždy nebo jenom na vyžádání, může velmi snadno dojít k tomu, že změna je sice implementována zdánlivě správně, ale není možné jí použít. Proto je potřeba nejprve na modelu CIM analyzovat jak se změní, či rozšíří činnosti uživatele a pak teprve můžeme uvažovat, jak tyto změny ovlivní naší ekonomickou aplikaci. Udržování aktuálního modelu PIM je pak klíčové pro analytiky, kteří musí definovat příslušnou změnu na koncepční úrovni. Velice častým problém je, že aplikace je dokumentována pouze platformově specifickým modelem, který obsahuje množství informací souvisejících s technologickým řešením. Tyto informace však vlastní koncepční řešení značně zatemňují a výrazně ztěžují analytikovi práci. Důsledkem jsou pak časté chyby způsobené opomenutím nebo tím, že analytik zasahuje do technologických záležitostí, kterým až tak dobře nerozumí. V našem příkladu s daňovým dokladem k platbě musí analytik vyřešit především způsob jeho číslování, vazby na platby a další související doklady a v neposlední řadě například způsob archivace. Pokud se však musí probírat modely plnými session kontrolérů, object brokerů a podobných technologických objektů, jeho produktivita a kvalita práce samozřejmě značně klesá. Modely CIM a PIM tedy potřebujeme, ale na co nám je platformově specifický model PSM? Jak již bylo řečeno, PSM model znázorňuje technologický způsob řešení a má stejnou strukturu jako zdrojový kód aplikace. Právě posledně uvedené je velmi důležité PSM je totiž v podstatě vizualizací kódu. Pokud jste měli možnost programovat rozsáhlejší aplikaci, jistě jste narazili na problém jak se vyznat ve spoustě programových tříd a množství kódu. A právě k tomu slouží PSM model abychom se vyznali v kódu a to zpětně, jako forma dokumentace, ale i dopředně, jako zadání pro vytvoření kódu. Některá vývojová prostředí (Integrated Development Environment IDE) dnes již obsahují takovéto vizualizéry kódu ve formě UML modelu, obvykle však jen ve svých Enterprise verzích. 5.5 Transformace aneb snadno z modelu do modelu V čem spočívá nejdůležitější přínos MDA je to, že definuje kromě shora uvedených modelů také způsob a postup jejich transformace. Opět se však nejedná o zcela nový přístup, ale spíše o standardizovanou aplikaci osvědčených praktik, především zkušeností z použití návrhových vzorů (Design Patterns). Z praktického hlediska jsou zajímavé transformace CIM do PIM a PIM do PSM. 5.5.1 Transformace CIM <-> PSM Tato transformace vyjadřuje vztah mezi činnostmi uživatele a funkcionalitou aplikace. MDA se sice touto transformací příliš nezabývá, ale obvyklý postup je transformace firemních procesů do akcí uživatele v aplikaci (v UML tzv. Use Cases). 5.5.2 Transformace PIM <-> PSM Z hlediska MDA je nejzajímavější transformace platformově nezávislého modelu (PIM) do platformově specifického modelu (PSM). Postup transformace dle MDA je zhruba následující: 1. Návrhář doplní PIM model tzv. mapovacími značkami, které definují, jaká obecná transformační pravidla budou použita.

2. Pro PIM model (resp. jeho části) je zvolena implementační platforma. 3. Na základě mapovacích značek jsou provedeny odpovídající transformace již s ohledem na zvolenou platformu. Následující obrázek zachycuje úrovně abstrakce přechodů mezi jednotlivými modely. Obrázek 5: Úrovně abstrakce [Ele_04] 5.6 K čemu tedy MDA slouží? Přínos koncepce Model Driven Architecture je tedy především v tom, že jasně definuje, co je analytický model, co je návrhový model a jak provádět jejich transformaci. Cílem je, aby aplikace byla popsána na různých úrovních abstrakce a tím pádem je značně usnadněno konzistentní promítání změn v aplikaci. Další pozitivní důsledek je standardizace návrhu, která umožňuje zvýšit kvalitu aplikací. Důsledkem toho všeho je především snížení nákladů na údržbu aplikací, tedy peníze, o které jde jako obvykle až v první řadě. Jak již bylo zmíněno na začátku, MDA je především o zjednodušení a tím i zlevnění údržby a rozvoje aplikací. Vzhledem k tomu, že právě sem směřuje větší část investic související s vývojem softwaru (Gartner Group uvádí že až 70%), je tato koncepce nakonec zajímavá i po finanční stránce. MDA se bude zcela jistě dále rozvíjet. Budou vytvořeny mocnější nástroje, které budou tuto technologii využívat. S těmito nástroji bude zřejmě ubývat nutnost upravovat PSM a vše se již bude definovat v PIM, který bude spustitelný a testovatelný (bude tedy převládat přístup translationist). Potom budou tyto aplikace opravdu Model Driven. 5.7 Silné stránky MDA Největším přínosem MDA je, že kromě modelů definuje i způsob a postup jejich transformace. Vychází přitom ze zkušeností s použitím návrhových vzorů (Design Patterns). Transformace CIM PSM obvykle přetváří podnikové procesy do akcí uživatele v aplikaci (v UML tzv. Use Cases). Transformace PIM PSM využívá mapovacích značek, které definují použitá obecná transformační pravidla. Po zvolení platformy se na základě těchto značek provedou odpovídající transformace s ohledem na danou platformu. Ty mohou probíhat oběma směry, takže i změny na nižších úrovních se snadno promítnou do modelů vyšší úrovně. Standard MDA sestává z jazyka UML pro tvorbu vizuálních reprezentací návrhových artefaktů, standardu MOF (Meta Object Facility), popisujícího abstraktní jazyk a rámec pro správu a uchování objektů a modelů vytvořených pomocí UML v datovém skladu a konverzního prostředku XMI (XML Metadata Interchange) pro výměnu modelů mezi jednotlivými MDA nástroji.