ICT firmy

Použití case pro řízení IS/ICT firmy Semestrální práce z předmětu 4IT450 CASE – Computer Aided Systems Engineering

Zimní semestr 2011/2012 Roman Nedzelský Václav Chromický Martin Golík Martin Fiala

Obsah 1

Úvodem ........................................................................................................................................... 3

2

CASE................................................................................................................................................. 3 2.1

Počátky .................................................................................................................................... 3

2.2

Dělení CASE nástrojů ............................................................................................................... 4

2.3

Vlastnosti CASE........................................................................................................................ 4

2.4

Techniky vhodné pro řízení IS/ICT........................................................................................... 6

3

Definice řízení IS/ICT...................................................................................................................... 10

4

Použití CASE a přínos pro firmu..................................................................................................... 11

5

6

7

4.1

Metoda vícekriteriálního rozhodování.................................................................................. 12

4.2

Dokumentace ........................................................................................................................ 13

4.3

Standardizace ........................................................................................................................ 13

Vybrané nástroje CASE .................................................................................................................. 15 5.1

EnterpriseArchitect ............................................................................................................... 15

5.2

Power designer...................................................................................................................... 16

5.3

Umbrello................................................................................................................................ 18

5.4

Oracle designer...................................................................................................................... 19

5.5

Rational Rose......................................................................................................................... 20

5.6

DIA ......................................................................................................................................... 21

Možnosti zrychlení implementace funkcionality IS....................................................................... 22 6.1

Softwarové inženýrství .......................................................................................................... 22

6.2

Podpora softwarového vývoje pomocí nástrojů CASE .......................................................... 23

6.3

Model-drivenengineering...................................................................................................... 24

Zdroje............................................................................................................................................. 29

Stránka | 2

1 Úvodem V naší práci srovnáme některé CASE nástroje (viz. 5 kapitola) vhodné pro IT modelování ve firmě. Je jasné, že podobná srovnání se dají nalézt kdekoliv. Proto nechceme srovnávat nástroje podle určitých předem daných kritérií. Myslíme, že tím se výběr nástroje zužuje na pouhou jednu skupinu cílových uživatelů. Ať už kritéria vybereme jakákoliv, vždy se zaměří na přístupnost, cenu, funkce atd. Proto zde představíme několik nástrojů, popíšeme jejich základní parametry a poté je zhodnotíme samostatně a doporučíme uživatelům, kterým budou nejvíce k užitku. Tímto se vyhneme určitému škatulkování nástrojů a každý si vybere právě ten, který se pro něj hodí nejvíce.

2 CASE CASE vychází z anglické zkratky Computer Aided Software (System) Engineering a představuje „komplex počítačových nástrojů pro podporu analýzy, návrhu a implementace IS/ICT a dalších činností souvisejících s jeho vývojem“.[1, str. 48] Nástroje CASE nám umožňují např. tyto činnosti: [2][3] -

Návrh konceptuálního a fyzického datového modelu

-

Objektové modelování – podpora objektového přístupu

-

Procesní modelování

-

Kontrolní mechanismy – kontrola integrity modelů

-

Porovnávání jednotlivých datových modelů

-

Generování výsledného kódu – např. generování skriptů pro vytvoření databáze z fyzického modelu

-

Podporu spolupráce při vývoji

-

Automatické vytváření dokumentace k modelům

2.1 Počátky První CASE nástroje vznikají pro podporu tehdy nové disciplíny Softwarového inženýrství (rozhraní 60. a 70. let)[4] a jeho metodik při vývoji IS. Tato první generace nástrojů byla zaměřena především na fázi implementace (generování kódu), tedy typ nástrojů dnes označovaný jako „Lower CASE“. Původním záměrem bylo úplné nahrazení programátorů, výstupem CASE měl být hotový a ihned použitelný programový kód (nakonec z této myšlenky sešlo). Hlavní rozvoj přichází ale až v 80. letech s rozvojem GUI (Graphical User Interface, tzn. Grafické uživatelské rozhraní), které umožnilo Stránka | 3

pokročilejší úpravy kódu. Prvním takovým nástrojem byl DesignAid od společnosti Nastec Corporation. V 90. letech se přidávají nástroje, které jsou schopny podpořit již celý životní cyklus vývoje softwaru. V současnosti jsou tyto nástroje určeny nejen pro vývoj softwaru, ale jsou užitečné např. i pro řízení firem, téma, kterým se zabývá i tato práce.[5]

2.2 Dělení CASE nástrojů CASE nástroje je možné dělit dle toho, jak pokrývají životní cyklus projektu:[6] Některé nástroje se snaží pokrýt všechny fáze životního cyklu, některé se naopak specializují pouze na jednu nebo několik fází. -

Pre CASE – nástroje pro podporu při vytváření globální strategie.

-

Upper CASE – nástroje pro podporu při fázi vytváření informační strategie a úvodní studie IS

-

Middle CASE – nástroje pro podporu analytické a logické části návrhu IS.

-

Lower CASE – nástroje pro podporu implementace výsledků analytického návrhu. Oproti předchozím dvou, jsou závislé na implementačním prostředí.

-

Post CASE – nástroje pro podporu fáze zavádění a provozu IS, jeho údržbu a reengineering

Nástroje se mohou také jednoduše členit na Upper CASE (fáze analýzy a návrhu) a Lower CASE (fáze implementace, testování).

2.3 Vlastnosti CASE Následující základní vlastnosti nástrojů CASE nám mohou posloužit jako kritéria, na které bychom se měli zaměřit při výběru nástroje dle našich požadavků a potřeb. Mohou být také vhodnými kritérii při jejich celkovém porovnávání a hodnocení. [7] Podpora technik a nástrojů Nástroj by měl nabízet širokou základnu metod a technik tak, aby byly zajištěny veškeré potřeby modelování. Mezi běžné techniky patří techniky datového modelování (např. Entity Relationship Diagram), techniky funkčního modelování a analýzy (např. Data Flow Diagram), techniky procesního modelování (např. diagramy průběhu procesů), standardizované modely UML (viz. níže) a techniky návrhu struktury komunikace. Vazba na metodiku I když většina metodik používá shodné nebo podobné techniky a metody, je dobré vědět do jaké míry je CASE nástroj svázán s podporovanou metodikou. Tato vazba může být velmi těsná, nebo se může

Stránka | 4

jednat o nástroje nezávislé, použitelné při různých postupech. Při výběru CASE nástroje je vhodné zohlednit, jakou metodiku máme v plánu použít. Kvalita CASE repository Repository, neboli systémová encyklopedie (slovník dat) by měla zajistit možnost popisu jakéhokoli objektu, vyhledávání objektů dle libovolných kritérií, ochranu dat uložených v repositury, možnost verzování (návratu ke starším verzím, porovnávání verzí) a také možnost přizpůsobení repositury pro požadavky uživatele. Podpora týmové práce Důležitá je možnost koordinace práce v týmu – identifikování řešitelů, přidělování práv apod. Podpora síťové spolupráce, pro spolupráci více uživatelů na jednom projektu. A také integraci všech výsledku do jednoho smysluplného celku. Dokumentace Software musí být schopen snadno vytvářet dokumentaci vyvíjeného IS, tak ať je udržován přehled co a jak je implementováno. Často je to řešeno rozhraním ne běžně dostupné grafické a textové editory. Vhodnější je ale integrované řešení tak, aby nevznikala s vyvíjeným systémem nekonzistentní dokumentace. Nástroj by tedy měl nejen vygenerovat dokumentaci, ale také ji udržovat aktuální v závislosti na provedených změnách. Uživatelské rozhraní Jednoduchost a přehlednost je podstatnou vlastností CASE nástroje, tak jako u jakéhokoli jiného softwarového programu. Rozhraní by mělo být intuitivní a nabízet rychlou práci (sledovaným hlediskem může být počet kliků pro provedení operace). Podpora jazykového prostředí Základem je možnost popisu ve vlastním národním jazyce, ale také respektování gramatických pravidel jazyka při vyhledávání či třídění. Softwarová a hardwarová náročnost Každý nástroj má své nároky pro spuštění a optimální běh.

Stránka | 5

Export/import dat Umožnění práce s vytvořenými modely v jiných nástrojích. Např. exportem dat do XMI (SML metadata interchange) nebo CDIF (CASE data interchange format).

2.4 Techniky vhodné pro řízení IS/ICT 2.4.1 UML „Jazyk UML (Unified Modeling Language) je grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů“

1

. UML představuje souhrn „best practises“ pro oblast

modelování informačních systémů. Skládá se z řady diagramů, které umožňují zachytit vyvíjený SW z různých pohledů a úrovně abstrakce. Jedná se o modelovací jazyk, který je podporován většinou CASE nástrojů a je v podstatě pro tuto oblast standardem. Jeho předností je nezávislost na konkrétní metodice, na konkrétním programovacím jazyce a procesu vývoje. Je také vhodný pro popis podnikových procesů, a tedy vhodný pro řízení podniku. [7] Aktuálně je jazyk ve verzi 2.3 (2.4 ve fázi beta) a nabízí 14 typů diagramů rozdělených do tří skupin: • diagramy chování – zobrazují dynamicky stav systému a procesu o diagramy interakcí – spadá pod diagram chování a vyjadřují interakce objektů v čase • diagramy struktury – zobrazují staticky pohled na systém

Obrázek 1 - Přehled diagramů UML.

1

„The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting the artifacts of a software-intensive system.“ [8, str. 1]

Stránka | 6

Popis diagramů UML:[9][10][11] Diagramy struktury •

Diagram tříd (Class diagram) - statický pohled na modelovaný systém prostřednictvím tříd a vztahů mezi nimi. Třídy představují objekty (prvky modelované reality), které mají společné vlastnosti a chování.

•

Digram komponent (Component diagram) – Zobrazuje jednotlivé softwarové komponenty systému a jejich vzájemné vazby. Komponenty jsou samostatné části systému, které mezi sebou komunikují pomocí přesně definovaného rozhraní. Používá se k určení architektury projektovaného systému.

•

Objektový diagram (Object diagram) – diagram zachycuje objekty (instance tříd) a jejich vazby v určitém čase. Pomáhá tak pochopit vývoj tříd, jejich atributů a vazeb v čase.

•

Diagram profilů (Profile diagram) – Je určen pro popis rozšíření UML pomocí profilů. Profil je kolekcí stereotypů, značených hodnot a omezení, které přizpůsobují UML k využití pro specifickou platformu, metodu či doménu. [12]

•

Diagram vnitřní struktury (Composite structure diagram) – Diagram popisuje vnitřní strukturu klasifikátoru (což může být třída, komponenta, use case, interface) a interakční body s ostatními částmi systému (tedy spolupráci s okolím).

•

Diagram nasazení (Deployment diagram) – pomocí diagramu je poskytován pohled na fyzické rozmístění systému. Prvky diagramu jsou nazývány uzly, tedy komponenty systému, a jejich spojení v diagramu ukazuje jejich komunikační cestu.

•

Diagram balíčků (Package diagram) – diagram je užíván na seskupení vzájemně souvisejících komponent a závislostí mezi nimi. Užitečný je především pro získání přehledu o závislostech a případně snížení závislostí mezi komponentami v rozsáhlých systémech.

Diagramy chování •

Diagram aktivit (aktivity diagram) – diagram určený pro popis dynamického chování systému. Zobrazuje posloupnost aktivit v procesu a přechody mezi těmito aktivitami. Je tím poskytnut náhled pro pochopení průběhu komplexních činností, a je tak vhodný pro modelování business procesů a workflow.

•

Diagram případů užití (Use case diagram) – definuje případy (neboli scénáře) použití systému z pohledu uživatele. Definuje aktéry (typy uživatelů) a scénáře použití (v podstatě posloupnost událostí při užívání systému). Je tak zobrazena interakce mezi uživatelem budoucího systému a samotným systémem.

Stránka | 7

•

Stavový diagram (State machine diagram) – slouží pro popis chování jediného objektu v rámci jeho životního cyklu. U objektu jsou sledovány stavy, kterých nabývá v průběhu cyklu, přechody mezi těmito stavy a události (které mohou být důvodem pro přechod do stavu).

Diagramy interakcí •

Diagram sekvencí (Sequence diagram) – slouží pro popis interakce skupiny objektů v rámci jednoho scénáře. To znamená zachycení komunikace mezi objekty a co tuto komunikaci spouští (triggers). Je tak popsáno chování jednolitých objektů, jaké zprávy si mezi sebou posílají.

•

Diagram komunikace (Communication diagram) – interakční diagram, který tak jako diagram sekvencí popisuje objekty a jejich vzájemnou komunikaci. Na rozdíl od diagramu sekvencí se ale především zaměřuje na vztahy mezi objekty. Oba diagramy jsou mezi sebou převoditelné.

•

Diagram přehledu interakcí (Interaction overview diagram) – slouží k pochopení interakcí v systému. Je v podstatě variantou diagramu aktivit. Což je myšleno tak, že jednotlivé aktivity jsou v diagramu aktivit zaznamenány pomocí sekvenčního diagramu.

•

Diagram časování (Timing diagram) – je alternativou k sekvenčnímu diagramu, zaznamenává časová omezení spojená se změnou stavu a hodnot jednotlivých objektů (změny stavu v čase).

2.4.2 Notace BPMN Grafická notace, která slouží přímo pro modelování podnikových procesů. Cílem BPMN je poskytnout notaci, která je dostatečná pro popis komplexních procesů, přesto srozumitelná pro všechny zainteresované uživatele. Ať už se jedná o programátory zodpovědné za jejich implementaci, nebo manažery v podniku. Je tak jazykem, který vyplňuje komunikační mezeru mezi návrhem podnikových procesů a jejich implementací. Základem jsou grafické objekty (události, aktivity…viz. Obrázek 3) a jejich posloupnost, což lze vidět na následujícím příkladu (Obrázek 2):

Obrázek 2 - Ukázka modelu BPMN

Stránka | 8

Obrázek 3 - Přehled prvků BPMN notace.

2.4.3 ErikssonPenker notace Notace, která je využívána pro statický a globální přehled procesů podniku. Grafický model ukazuje klíčové a podpůrné podnikové procesy, jejich vzájemné závislosti a jednotlivé atributy (startovací událost, vstupy, výstupy a cíle).

Obrázek 4 - Ukázka modelu dle E-P notace.

Stránka | 9

3 Definice řízení IS/ICT Následující kapitola je shrnutím zdrojů: [13][14][15][16][17] Definice řízení firmy byla popsána kolegy ve stejnojmenné práci z roku 2006[13]. Řízení lze rozdělit na několik druhů (respektive ho považovat za následující činnosti): -

Strategické řízení - zde se jedná o jakousi množinu činností, které jsou prováděny ve vrcholovém managementu. Tyto činnosti se obvykle věnují jakémusi business plánu celé firmy a jsou tudíž svázány s dlouhodobější vizí firmy a také s větším množstvím dokumentů, které slouží jako podklady pro business plán a záměr. Dále tyto činnosti mohou popisovat jednotlivá základní pravidla, postupy, eskalační procesy apod. Veškeré tyto body by es poté měli projevit na vedení a realizaci jednotlivých projektů, zaměřených především na IS/ICT. Je tedy možné se ptát na otázky jako jaké jsou cíle a priority? Jaké produkty, potažmo služby bude podnik vlastně nabízet svým potencionálním zákazníkům a jaký to bude okruh lidí? Jak budou definovány finanční vztahy? Jaké

a

jak

budou

nastaveny

diagnostické

nástroje

a

jejich

metriky?

Budou

pravidelně aktualizovány? Pokud by se toto mělo vyjádřit v nějakých skupinách, jednalo by se zejména o:

-

o

Informační strategii

o

Bezpečnostní strategii a management

o

Organizaci řízení IS/ICT

Taktické řízení je orientováno více konkrétně, než strategické. Zahrnuje množinu činností, která by měla popisovat spíše vývoj a implementaci / integraci nových prostředků (výrobků, služeb atd.) v oblasti IS/ICT. To znamená, že by se měla zabývat:

-

o

Řízením služeb

o

Plánováním projektů

o

Řízením ekonomiky a nastavováním metrik

o

Případně řízením personálních a datových zdrojů

Operativní řízení je doslova přezdívkou pro každodenní běh firmy jako takové a to především pro projektového manažera, který by každý den měl kontrolovat jednotlivé projekty, sledovat jejich průběh a aktualizovat data v oblasti řízení rizik, případně dokumenty, jako je status review apod. Měl by zkoumat závislosti jednotlivých projektů (především jejich ovlivňování při nenadálých konfliktech, zpoždění dílčích úkolů a alokaci zdrojů).

Stránka | 10

Obrázek 5 - Schéma řízení informatiky, zdroj itg.cz.

4 Použití CASE a přínos pro firmu V dnešní době je řízení podniku velmi závislé na podpoře ze strany IS/ICT. Je neustále zapotřebí vykonávat nějakou činnost na počítačích (vzhledem k množství dat a datových zdrojů, efektivní elektronické komunikaci i přesunu do „cloudového“ prostředí) a informační struktura je tedy doslova "prorostlá" celým podnikem. Je tedy jasné, že s růstem podniku je zapotřebí i nastavit souběžně růst IS/ICT infrastruktury a to bez ohledu na stále rostoucí požadavky na informační technologie ze strany zákazníků / uživatelů. S přibývajícími změnami v informačních systémech se systémy stávají více komplexní a jejich dodávka a upgrade se stává obchodním artiklem mnoha dodavatelů. Neustále se zvětšující infrastruktura se stává náročnější na její správu a řízení především z hlediska objemu informací a ukazatelů, které je neustále zapotřebí kontrolovat a dle nich poté odhadovat náklady a rizika spojené s dodávkou a IS/ICT. Systém se tak může stát jen těžce ovladatelným prvkem s možnými fatálními riziky pro podnik jako takový.

Stránka | 11

To samé je spojené s jednotlivými procesy, které mají silné vazby na onu podnikovou informatiku. Otázkou může být proč modelovat infrastrukturu jako takovou, nebo procesy jako takové. Odpovědí na obě tyto otázky je efektivita, zlepšení, ovladatelnost, koordinace a kooperace a v poslední řadě konzistence. [13] Modelování hraje důležitou roli při řízení informatiky, v jejím provozování, udržování a rozvoji. Hraje důležitou analytickou roli při návrzích moderních informačních systémů od jejich „poskládání“ až po jejich umístění na konkrétní hardwarové prostředky. Model nám dále poskytuje kontrolu a přehled nad tím, z jakých aplikací a od jakých dodavatelů je celý systém poskládán a především jakými vazby a případně procesy jsou jednotlivé aplikace propojeny v jeden celek, který v ideálním případě i funguje. V souvislosti s IT infrastrukturou podniku je zapotřebí samozřejmě modelovat i její rozmístění. O to více, pokud je firma doopravdy velká, případně pokud má několik poboček a centrál v různých lokacích po světě. Pokud by nebyla dostatečně zmapována, nebylo by již tak snadné a především efektivní vše při případné poruše zmapovat a opravit. [17] S růstem podniku je nutné neustále rozšiřovat podnikovou informatiku a s její pomocí je vhodné i mapovat a vylepšovat jednotlivé procesy uvnitř firmy. Pokud se namodelují jednotlivé procesy, je pak o hodně snazší odhadovat a analyzovat jednotlivé možné dopady na systém a podnik jako takový. Protože modely procházejí při návrhu iterativními procesy, je více než vhodné použití nějakého z CASE nástrojů, které umožňují modelovat jak procesy, tak požadované rozložení informační infrastruktury uvnitř podniku. Co je ale důležitější, umožňují modelovat jejich vzájemné propojení, neboť většinou změny v procesech mají za příčinu změny v informační struktuře, popřípadě aplikacích informačního systému a je tak možné odhadovat důsledek a rozsah změn. Základním modelem systému z hlediska jeho struktury je model závislostí mezi jednotlivými aplikacemi a jejich rozhraním. Na jeho základě je možné provést analýzu dopadu změny na další systémy a vhodně ji tak případně ovlivnit. Tento model je základem pro komunikaci mezi systémy samotnými. [13]

4.1 Metoda vícekriteriálního rozhodování Tato metoda má za výsledek poměrně ucelený přehled variant s přihlédnutím k jedné, kterou by se tvůrce měl vydat / rozhodnout na základě parametrů. Pro standardizaci, vymezení a výběr je nutné dle [18] znát: •

V čem se má rozhodnout

•

Jaké cíle mají být splněny a v návaznosti na jaké podmínky Stránka | 12

•

Jaká jsou hlediska rozhodování? Jak se na objekty má nahlížet?

Nejdříve se vytvoří množina kritérií pro hodnocení. Musí se stanovit váha těchto kritérií, protože zajisté nenastane situace, kdy by všechny měli stejnou váhu. Poté se posuzuje riziko spojené s případnou realizací jednotlivých variant, mezi kterými je rozhodováno. Na závěr se provede určení preferenčního pořadí jednotlivých variant, které byly navrženy, a vybere se ta nejlepší z nich. [18]

4.2 Dokumentace Dokumentace a její tvorba je věc, se kterou se setkáte defakto v každé metodice, v každých bestpractice postupech apod. Vzhledem k tomu, že při jakékoliv implementaci IS vzniká potřeba dokumentovat jednotlivé zásahy, shromažďovat informace o jednotlivých částech systému pro jeho případné úpravy, změny, stává se dokumentace velmi potřebným a užitečným zdrojem informací. Jednou z hlavních vymožeností moderních modelovacích CASE nástrojů a jejich následného využití při řízení informatiky je schopnost těchto nástrojů generovat, udržovat a katalogizovat aktuální dokumenty spojené s modelováním systému, které jsou nedílnou součástí modelovaného ocelku. To vše je možné svázat s životním cyklem a jeho jednotlivými fázemi.

4.3 Standardizace Standardizace je v poslední době čím dál tím víc diskutované téma v mnohých firmách. V důsledku tohoto trendu je vyvíjen neustále větší tlak mnohými firmami na standardizaci CASE nástrojů s metodikami, jako jsou ITIL, nebo COBIT. Těmito metodikami se v dnešní společnosti řídí obrovské množství firem a jejich domácí organizace mají k vyvíjení tlaku nemalé prostředky. Mnozí zastánci této požadované standardizace argumentují především tím, že firmy disponují příslušnými normami, které jsou v souladu s procesy v jednotlivých metodikách a nebyl by tudíž velký problém celé takovéto sloučení provést. 4.3.1

ITIL

ITIL je název pro metodiku, která poskytuje procesně orientovaný přístup k řízení IT služeb (knihovna infrastruktury informačních technologií). To je asi jeho největší výhodou. Autorem této metodiky je britská organizace OGC (British Office ofGovermentCommerce). Jedná se o sadu několika knih, které popisují jednotlivé oblasti IS/ICT. Jedná se především o popis částí jako Service design, Serviceoperation, Servicetransition a Servicestrategies. [19] Výhodou ITILu je, že nahlíží na infrastrukturu jinak, než jen jako na technologickou záležitost. Mnohem více se snaží začlenit Správu služeb IT, to znamená pokrytí celého životního cyklu všech služeb. Navíc se neustále snaží vytvořit jakousi prostřední vrstvu (která doposud pořádně neexistuje) Stránka | 13

mezi oblastí IT a businessu. Je jasné, že i v budoucnu se bude vývoj ubírat právě tímto směrem, tedy snahou o zmenšení této propasti, protože obě skupiny nejsou moc schopni se domluvit, dohodnout, popřípadě shodnout na konkrétních problémech a otázkách.

Obrázek 6 - Základní schema ITIL V3 - zdroj:[19]

4.3.2 COBIT COBIT byl naopak vyvinut jako všeobecně použitelný a přijímaný přístup k řízení, kontrole a auditnímu procesu IS/ICT. Autorem je společnost ISACA ale na vývoji nyní přednostně participuje institut IT Governance. Protože je ale COBIT vnímám spíše jako auditní, popisuje stavy, ve kterých by se jednotlivé části IS/ICT měly nacházet.

Obrázek 7 - Multidimenzionální kostka COBITu, zdroj:[19]

Stránka | 14

5 Vybrané nástroje CASE 5.1 EnterpriseArchitect

Obrázek 8 - EnterpriseArchitect

5.1.1 O programu: EnterpriseArchitect [20] je velmi robustní software, který nabízí řadu funkcí a je možné se v nich ze začátku ztratit. Je pravidelně aktualizován o nejnovější verze diagramů UML a jejich notaci. Podporuje téměř celý vývoj aplikace díky možnosti vytvářet modely tříd, modely component, USE CASE modely business proces modely a spoustu dalších. Co ale z předchozího také vyplívá je, že nástroj je pro začínajícího uživatele nepřehledný. Všechny dostupné funkce není schopen uživatel při prvním použití využít a může se v nich ztratit. Proto také různé školící firmy nabízí kurzy pro zvládnutí nástroje EnterpriseArchitect. Další nevýhoda je jeho poněkud vyšší cena v řádu stovek dolarů za jednotlivé licence. Program je možno získat v několika různých verzích za cenu od 150 do 1000 dolarů. Při nákupu vyššího množství licencí je cena nižší, přesto je toto řešení pro menší firmy poměrně drahé. Pokud ovšem bude uživatel ochoten tuto cenu zaplatit, dostane perfektní CASE nástroj s aktualizovanou knihovnou modelů a podporou. Je možno získat 30-ti denní verzi zdarma. Stránka | 15

-

Současná verze - 9.1(26. 9 2011)

Funkce: -

Podpora všech diagramů z UML verze: 2.3

-

Generování kódu pro jazyky: Java, C#

-

Reverse engineer z jazyků: Java, C#, C++, Delphi a další

-

Generování XML schemat a reverse engineer

5.2 Power designer

Obrázek 9 - Power designer

5.2.1 O programu: Powerdesigner [21] je program podobně robustní jako výše zmíněný EnterpriceArchitect. Nabízí velké množství funkcí a UML diagramů. Obsahuje aktualizovanou knihovnu diagramů a je stále vyvíjen. Stejně jako nástroj EnterpriceArchitect nabízí reverse engineer databází i kódu některých programovacích jazyků. Z modelovaných diagramů dokáže generovat kód, který usnadní práci při Stránka | 16

vývoji aplikace. Přesto, že nabídka funkcí Power designeru je o něco málo menší než u EnterpriceArchitectu, je jeho uživatelské rozhraní méně přehledné a je těžší se v něm vyznat. I pro Power designer nabízí mnoho školících firem kurzy pro zvládnutí základů tohoto programu. Cena Power designeru je nižší než u výše zmíněného Enterprice architektu, ale i tak se jedná o profesionální software příliš drahý pro menší firmy. Je možné získat 15 ti denní verzi zdarma. -

Současná verze - 16.0

Funkce: -

Business Process Modeling

-

Simulace BPM

-

Generování kódu pro jazyky: Java, C#, .NET a další

-

Objektové modelování (UML 2.0)

-

Databázový reverse engineer

-

XML modelování

Stránka | 17

5.3 Umbrello

Obrázek 10 – Umbrello

5.3.1 O programu: Umbrello [22] je řešení za které nemusíte platit. Jedná se o freeware software. Čím však za toto zaplatíte, je nabídka možností a podpora, kterou tento program má. Vývoj programu byl oficiálně ukončen v roce 2008, proto je nabídka diagramů a notace, které nabízí poněkud zastaralá. Umbrello byl integrován do vývojového prostředí KDE a je jeho součástí. Ovládání tohoto nástroje je jednoduché a přehledné, také díky menší nabídce možností. Je vhodný pro začínající designéry a jako jednoduché řešení pro menší firmy či na vytváření ukázkových nebo školních projektů. -

Současná verze – 2.0 (1. 12. 2008)

Funkce: -

Podpora všech diagramů z UML verze: 2.0

-

Generování kódu pro jazyky: Java, C#, C++, PHP, SQL a další

-

Reverse engineer z jazyků: Java, Python, C++, SQL

Stránka | 18

5.4 Oracle designer

Obrázek 11 – Oracle designer

5.4.1 O programu: Oracle designer [23] je další z řady komerčních a velmi komplexních nástrojů CASE. Obsahuje celou řadu modulů a také doplňujících programů od společnosti Oracle, které z něj vytvářejí nástroj schopný zaznamenat kompletní vývoj softwaru. Funguje na principu klient-server. Tedy pro jeho instalaci je potřeba nainstalovat vlastní databázi, ke které se poté jednotlivé komponenty připojují a ukládají zde svá data. Již z tohoto faktu vyplívá, že jeho instalace je náročná na čas a hardwarové prostředky. Stejně tak není snadné proniknout do ovládání tohoto nástroje. Jeho komplexnost je vykoupena množstvím ovládacích prvků, v kterých se uživatel na první pohled ztrácí. Další nevýhodou je vysoká cena, která se pohybuje okolo 120 000 Korun na vývojáře. Z těchto důvodů se jedná o nástroj vhodný pouze pro profesionální vývojáře velkých projektů. Funkce: -

Business Process Modeling

-

Generování kódu pro jazyky: Java, C#, .NET a další

-

Objektové modelování (UML 2.3) Stránka | 19

-

Databázový reverse engineer

5.5 Rational Rose

Obrázek 12 - Rational Rose

5.5.1 O programu: Program Rational [24] Rose je Case nástroj od společnosti IBM. Jedná se o vývojovou platformu specializující se na vývoj aplikací na platformě J2EE. Je proto osekán o některé další funkce, které jsme našli u jiných nástrojů a jeho podpora pro jiné jazyky, či vývojové platformy není tak velká. Sama společnost IBM nabízí školící kurzy s tímto nástrojem pro začínající vývojáře. Díky omezení se na platformu J2EE je nástroj přehlednější na ovládání a seznámení se s ním není tak náročné. Nevýhodou tohoto nástroje je jeho vysoká cena blížící se ke 200 000 Korun. Dále jeho omezení pouze na jednu vývojovou platformu. Proto je nástroj vhodný pro specializované vývojáře, kteří se J2EE zabývají. Díky tomu ale pro tyto specialisty poskytuje širokou podporu včetně integrovaného vývojového prostředí.

Stránka | 20

Funkce: -

Podpora všech diagramů z UML verze: 2.X

-

Databázový reverse engineer

-

Generováni kódu

-

reverse engineer jazyka Java

5.6 DIA

Obrázek 13 – DIA

5.6.1 O programu: Program DIA [25] je další open source řešení pokud hledáte CASE nástroj. Jedná se o nástroj, který je neustále ve vývoji ale jeho jednotlivé verze vycházejí velmi sporadicky. Je inspirován kreslícím nástrojem Visio od Microsoftu. A jak je uvedeno na stránkách programu jedná se o nástroj pro občasné použití. Nejde tedy o nějaký profesionální nástroj, ale spíše o nástroj vhodný pro výuku, občasné namodelování jednoduchého programu a podobně. Jeho ovládání je přehledné a jednoduché proto se s ním každý může snadno naučit zacházet. Jedná se tedy o vhodný nástroj pro začínající vývojáře, nebo malé a nezávislé firmy bez velkých finančních rozpočtů. Pro časté použití jsou tu mnohem vhodnější nástroje. Stránka | 21

-

Současná verze – 0.97.1(21. 1. 2010)

Funkce: -

Podpora všech diagramů z UML verze: 1.5

-

Databázový reverse engineer

-

Generováni kódu: Python

6 Možnosti zrychlení implementace funkcionality IS Informační systémy, podporující vnitropodnikové procesy, ve formě softwarových aplikací přinášejí do organizace řád a možnost aplikovat jasně vymyšlená a definovaná pravidla. Tato pravidla jsou obvykle navrhována řídícími orgány firmy. Vznikají jako myšlenky v hlavách manažerů, bohužel však k jejich realizaci v IS potřebují projít dlouhou cestu transformace. Délka převtělování těchto myšlenek do implementace v IS bývá pro mnohé organizace kritická. Firmy si nemohou dovolit nabízet zákazníkům produkt, pro nějž nemají v IS nutnou podporu a zázemí. A tak, přestože specifikace toho, co má IS podporovat, bývá zřejmá, k životu může přijít až po dlouhých týdnech nebo měsících, po které mohou ostatní firmy úspěšně čerpat konkurenční výhody. Obecně lze tedy říci, že firma je v jistých ohledech tím více efektivnější a konkurenceschopnější, čím kratší doby implementace nových funkcionalit je ve svém IS schopna dosáhnout.

6.1 Softwarové inženýrství Disciplína, která se tímto přerodem myšlenek v implementovaná řešení zabývá, se jmenuje softwarové inženýrství. Existuje mnoho metodik pro implementaci nové funkcionality. Mohou se lišit tím, jak jednotlivé kroky přesně chápat, jak je uspořádat, jak k nim přistupovat, zdali musí předchozí krok být zcela kompletní, aby se mohlo přistoupit k dalšímu, či mohou-li se překrývat. Většinou jsme však schopni identifikovat základní činnosti, které se v metodikách projevují: •

sběr požadavků,

•

design/analýza,

•

implementace,

•

nasazení a běh.

6.1.1 Volba metodiky vývoje softwaru Při naší nastolené otázce „Jak zrychlit implementaci funkcionality?“ nelze alespoň krátce nezmínit důležitost volby správné metodiky vývoje softwaru. Stránka | 22

Jen urychleně se zmiňme, že implementuje-li firma novou funkcionalitu např. vodopádovou metodou v délce trvání 9 měsíců, když každá další fáze může začít teprve po tom, co je fáze předchozí dovedena do úplného stavu, pravděpodobně nebude schopna reagovat na změny svého okolí včas a její konkurenceschopnost se velmi sníží. Po tak dlouhé době mohou být priority firmy již zcela na jiném místě, a protože v takovém vodopádovém postupu by nemusel existovat prostor pro revizi původních požadavků, výsledná implementace a nasazení se pak mohou zcela minout s dávno plánovaným účinkem. Naopak, vezmeme-li do úvahy např. jednu z moderních metodik vývoje softwaru SCRUM s 2týdenními iteracemi, významně se k sobě fáze sběr požadavků, analýza, implementace a nasazení (časově) přiblíží, a díky tomu přiblížíme i business stránku věci k implementaci její nezbytné podpory v IS.

6.2 Podpora softwarového vývoje pomocí nástrojů CASE Softwarové inženýrství lze velmi výrazně podpořit nástroji CASE. Lze identifikovat několik úrovní podpory procesu vývoje: •

vývoj softwaru bez nástrojů CASE,

•

použití nástrojů CASE pro podporu procesu vývoje softwaru (podpora zvenčí),

•

použití nástrojů CASE pro podporu architektury softwaru (podpora zevnitř).

6.2.1 Vývoj softwaru bez nástrojů CASE Zcela bez použití nástrojů CASE budou pravděpodobně pracovat jednotlivci či velmi malé týmy, popř. velmi nezkušené týmy. V takovém vývojovém procesu by např. mohla specifikace produktu vznikat za běhu v hlavě programátora, popř. být dodána či konzultována pouze např. ústně či jednoduchou komunikací (emaily). Jedinými modely v takovém systému by bylo původní zadání (ať už na jedné straně formálně sepsané, či na straně druhé např. předané pouze ústně) a výsledný naprogramovaný kód, bez jakékoliv možnosti sledovat, jak se které části specifikace do kódu transformovaly. Neexistují tedy žádná vodítka či mezistavy (myšleny ve formě abstraktnějších modelů). 6.2.2 Použití CASE nástrojů pro podporu vývoje SW Slabší, avšak velmi důležitou formou podpory CASE nástrojů je podpora samotného procesu vývoje softwaru. Lze využít minimálně dílčí podporu některých fází vývoje, ať už se jedná o využití nástroje pro verzování zdrojových kódů, bugtracking systémů, popř. integrující nástroje podporující celý vývojový proces (od počátečního impulzu pro vývoj určité funkcionality ze strany zákazníka, který do systému např. vloží nepříliš rozmyšlený nápad/požadavek, přes diskuse o tomto požadavku mezi Stránka | 23

různými stranami, až po výsledné změny v kódu, včetně následného testování, hlášení chyb a jejich opravy, a nasazení). Jedná se prakticky o podporu vývojového procesu zvenčí. CASE nástroje nezasahují doobsahu tohoto vývoje, přímo např. nenapomáhají v generování zdrojových kódů atd. Výrazně tak usnadňují samotnou manuální práci při transformaci business požadavku do jejich implementace, avšak principiálně neusnadňují implementaci samotnou. 6.2.3 Použití CASE nástrojů pro podporu architektury SW Nejvyšší možnou podporou vývojového procesu ze strany CASE nástrojů je podpora přímo zevnitř. CASE nástroje v tomto případě pouze nevytváří prostředí pro samotný vývojový proces, ale jsou přímo jeho součástí. CASE nástroje tak musí v jistém smyslu rozumět přímo obsahu vyvíjeného systému. Takovou podporou může být např. jakékoliv automatické generování či transformace prvků vznikající funkcionality z jedné formy do druhé (např. transformace konceptuálního datového diagramu přímo do SQL dotazů v dialektu konkrétního databázového stroje).

6.3 Model-drivenengineering Modelově řízené inženýrství je založeno na myšlence popsat vybranou doménu implementovaného systému jako model s určitou mírou abstrakce. [31] Modelování napomáhá jejich snadnějšímu porozumění, a celkově se tak zvyšuje produktivita práce i efektivita vývoje, mj. i díky všeobecně uznávaným standardům v této oblasti. Právě na základě těchto standardů (jako např. UML) pracují i CASE nástroje. Modely lze v těchto nástrojích navrhnout, spravovat, vizualizovat, analyzovat nebo i transformovat z jedné formy do druhé. 6.3.1 Model-driven architecture [26] MDA nabízí přístup ke strukturalizaci specifikace implementovaného systému ve formě modelů. Tento koncept z roku 2001 má původ v konsorciu Object Management Group. Model-driven architecture vyčleňuje čtyři vrstvy modelů, každou se specifickým rámcem působnosti. Celkově se snaží především oddělit na jedné straně business rozhodnutí a požadavky, a na straně druhé aplikační logiku či rozhodnutí týkající se implementace. Konkrétně se snaží: •

specifikovat systém nezávisle na platformě, která ho bude podporovat,

•

o specifikaci platformy, Stránka | 24

•

podpořit rozhodnutí o konkrétní platformě pro systém

•

a usnadnit jednotlivé transformace od specifikace systému až po jeho konkrétní implementaci.

Základními cíli MDA jsou přenositelnost, interoperabilita a znovupoužitelnost díky architektonickému oddělení zodpovědností. 6.3.2 Úrovně modelů MDA

Obrázek 14 – zdroj: [28]

6.3.2.1 Computation Independent Model Výpočetně nezávislý model zachycuje systém v jeho přirozeném prostředí, v němž skutečně existuje. Zjednodušeně lze říci, že tomuto modelu není známo, že může být transformován do softwarové aplikace. Tento model a slovník v něm použitýzaplňují mezeru mezi experty v dané oblasti/doméně (např. řídícími pracovníky), kteří specifikují požadavky, jež má finální systém řešit, a těmi, kteří jsou schopní řešení těchto požadavků implementovat (IT analytiky/programátory). Nezachycuje strukturu systému, ale spíše to, co přesně se od systému očekává, že bude dělat. 6.3.2.2 Platform Independent Model Platformově nezávislý model se soustředí na vyřešení konkrétních požadavků. Řešení však musí být zcela nezávislé na použité platformě. Cílem je zde zachytit architektonické a technologické faktory a Stránka | 25

vazby podstatné pro vznik systému. Mohou zde být použity např. use case, class diagramy, ER diagramy a podobné. Transformace z výpočetně nezávislého modelu do platformově nezávislého modelu bývá zcela manuální. Často je používán postup vymezení akcí uživatelů nad vyvíjeným systémem pomocí use case diagramů. Takto se oddělí prostředí reálného světa od prostředí samotné aplikace. 6.3.2.3 Platform Specific Model Platformově specifický model je platformově nezávislý model uzpůsobený realizaci na určité technologické platformě. Je podkladem pro vlastní implementaci a má stejnou strukturu, jako výsledný kód. Transformace z platformově nezávislého modelu může probíhat mnoha způsoby, a to od plně manuální, až po plně automatickou. 6.3.2.4 Kód softwarové aplikace Přestože je výsledný kód aplikace chápán spíše jako výsledná spustitelná realizace předchozích modelů, sám o sobě je taktéž v určitém smyslu modelem. Transformace z platformově specifického modelu do kódu softwarové aplikace může probíhat automaticky i manuálně. 6.3.3 Možnosti transformací Jednotlivé úrovně modelů MDA architektury je třeba mezi sebou transformovat od nejvyšší po nejnižší vrstvu. Tento proces však lze do značné míry automatizovat a otevřít tak zcela nové, efektivnější možnosti implementace požadavků na software. V této oblasti existuje řada nápomocných technologií, které mohou např. modely rozšířit či doplnit, aby transformace byla snadnější, úplnější, efektivnější či automatizovatelnější. 6.3.3.1 Zcela manuální transformace Základní formou transformací jsou transformace manuální. V tomto případě nejsou CASE nástroje využity jinak, než jako nástroje pro nakreslení výchozí úrovně modelů, která pak slouží jako podkladové materiály pro tvorbu další, cílové úrovně. Sledování a zapracování změn je taktéž manuální a jakákoliv pokročilejší podpora CASE nástrojů, nežli ta kreslící (tedy např. podpora samotné transformace), zde není přítomna.

Stránka | 26

6.3.3.2 PIM + specifikace platformy = PSM Jednou z forem transformací, která je popsána i přímo v dokumentu MDA Guide, je transformace mezi PIM a PSM. Z teoretického hlediska lze všechny typy transformovatelných prvků modelu obohatit o jejich specifické rysy na zvolené platformě, a vytvořit tak specifikaci platformy. Za použití této specifikace platformy a vymodelovaného platformově nezávislého modelu lze vygenerovat platformově specifický model, který je stejně tak detailní, jako samotný PIM. 6.3.3.3 Executable UML, jazyk Alf [29][30] Executable UML je obecný název pro technologie snažící se dovést UML modely z onoho světa malovaných, lidsky čitelných diagramů, do precizních a především výpočetně úplných modelů, jež by mohl interpretovat i stroj. Na takových modelech lze testovat jejich validitu, zdali nemají chyby ve svých vazbách apod., a díky vysoké míře jejich detailnosti chování mohou být také přímo spustitelné. V roce 2008 byla vydána specifikace fUML, která dovedla podmnožinu UML na úroveň potřebnou k jejich spouštění. V tu dobu však jediným způsobem, jak specifikovat chování třídy po zavolání metody, bylo modelovat velmi detailní diagramy aktivity. Tento způsob je však velmi neefektivní a pro takovou míru detailu jednoduše nevhodný. Proto vznikl jazyk Action language for fUML, zkráceně Alf. Jazyk Alf patří do rodiny jazyků jako je C nebo Java, jelikož velmi připomíná jejich syntaxi. Tu však oprošťuje od konkrétních, platformově závislých prvků, a přináší tak nad ně určitou míru abstrakce. Chování velké množiny prvků UML diagramů tak může být mnohem šikovněji popsáno tímto textovým způsobem, a snadno být, společně se zbytkem modelu, transformováno z této úrovně platformově nezávislého modelu až na úroveň modelu platformově specifického. 6.3.3.4 PSM -> kód Z platformově specifického modelu lze generovat výsledný kód v konkrétním programovacím jazyce. Existuje zde opět více možností: Lze vygenerovat např. jen kostru programu, přičemž chování v podobě konkrétní implementace bude poté již vytvořeno ručně. Pokročilejší formou je však zcela automatická konverze, pokud byl i platformově specifický model již dostatečně detailní (např. díky zmiňovanému jazyku Alf). 6.3.3.5 Very rapid application development[27] Existují však přístupy, které jdou ještě dále. Jestliže jsme na začátku popisovali, že se proces vývoje softwaru skládá z činností sběru požadavků, designování/analýza aplikace, implementace a spuštění, některé přístupy se snaží o kategoricky vyšší provázanost mezi těmito kroky.

Stránka | 27

Aplikace typu VRAD mají oproti klasickému MDA pojetí jednu zásadní odlišnost: Zcela se snaží odbourat implementační část. V praxi slévají podstatnou část modelů dohromady a po sběru požadavků a provedení analýzy využijí výstupy analýzy jako pasivní vstup pro tzv. VRAD engine. Jedná se v podstatě o WYSIWYG (what you see is what you get) editory na aplikace. Grafické rozhraní (vstupy, formuláře, výstupy, formátování) výsledné aplikace se tak de facto stává jen dalším modelem, který má vazby na modely ostatní. VRAD Engine se postará o jejich svázání a spuštění. V tomto druhu aplikace MDA architektury prakticky nedochází k přímým transformacím mezi jednotlivými úrovněmi modelu, ale spíše k jejich implicitnímu spojení v jeden celek. Konceptuální výhodou takového řešení je, že odpadnou veškeré principiální strasti s částmi vývojového cyklu, jejichž podstatu zaštituje VRAD engine. Výslednou aplikaci např. není potřeba testovat, jelikož výsledné chování bude vždy striktně odpovídat vytvořeným modelům.

Stránka | 28

7 Zdroje 1. GÁLA, Libor, Jan POUR a Zuzana ŠEDIVÁ. Podniková informatika. 2., přeprac. a aktualiz. vyd. Praha: Grada, 2009, 496 s. Expert (Grada). ISBN 978-80-247-2615-1. 2. KADLEC, Václav. CASE a zbytek světa III. Databázový svět [online]. 28. 6. 2002 [cit. 2012-01-05]. Dostupné z: http://www.dbsvet.cz/view.php?cisloclanku=2002062801 3. KADLEC, Václav. CASE a zbytek světa IV. Databázový svět [online]. 1. 7. 2002 [cit. 2012-01-05]. Dostupné z: http://www.dbsvet.cz/view.php?cisloclanku=2002070104 4. Software

Engineering [online].

Garmisch,

Germany,

7.-11.

10.

1968.

Dostupné

z:

http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF 5. CASE nástroje. In [online]. [s.l.] : [s.n.], 2009 [cit. 2011-11-25]. Dostupné z WWW: . 6. CASE nástroje. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : WikipediaFoundation, 2008, last modified on 2011 [cit. 2011-12-23]. Dostupné z WWW: . 7. BUCHALCEVOVÁ, Alena, Jarmila PAVLÍČKOVÁ a Luboš PAVLÍČEK. Základy softwarového inženýrství: materiály ke cvičení. Vyd. 1. Praha: Oeconomica, 2007, 221 s. ISBN 978-80-245-12709. 8. ISO/IEC 19501. Unified Modeling Language Specification. 2005. Dostupné z: http://www.omg.org/spec/UML/ISO/19501/PDF/ 9. UML 2 Tutorial. Sparx Systems [online]. [cit. 2012-01-05]. Dostupné z: http://www.sparxsystems.com.au/resources/uml2_tutorial/ 10. RICHTA, Karel. Novinky ve standardu UML 2.0. Praha, 2005. Dostupné z: http://www.ksi.mff.cuni.cz/~richta/publications/RichtaMD2005.pdf 11. Příklady použíití diagramů UML 2.0. [online]. [cit. 2012-01-06]. Dostupné z: http://uml.czweb.org/index.html 12. UML Profile Diagrams. [online]. [cit. 2012-01-06]. Dostupné z: http://www.umldiagrams.org/profile-diagrams.html 13. D. Maleček, D. Měrka a I. Gyorfy, „Prostředky CASE a jejich využití při tvorbě IS,“ 2006. 14. J. Farský, R. Kytka a M. Višňová, „Použití nástrojů CASE ve vývojářské firmě,“ 2006/2007.

Stránka | 29

15. M. Fišerová, T. Baxa , M. Hejcman, S. Ježek, L. Kapitán a P. Vaněk, „Využití nástrojů CASE pro řízení IS/ICT,“ 2010/2011. 16. L. Kulík a M. Mora, „Použití CASE pro řízení IS/ICT firmy,“ 2011. 17. R. Tomšej, P. Holubička, T. Kormaňák, Z. Prášil a I. Procházka, „POUŽITÍ CASE PRO ŘÍZENÍ IS/ICT FIRMY,“ 2009. 18. I. P. Korviny, „Teoretické základy vícekriteriálního rozhodování,“ [Online]. Available: http://korviny.cz/mca7/soubory/teorie_mca.pdf. [Přístup získán 15 Prosinec 2011]. 19. itSMF Czech Republic, o.s., „ITIL,“ itSMF Czech Republic, o.s., 2007. [Online]. Available: http://www.itil.cz/index.php?id=982. [Přístup získán 11 Prosinec 2011]. 20. Enterpricearchitect [online]. 2002 [cit. 2011-12-10]. Sparxsystems. Dostupné z WWW: 21. Power designer [online]. 2001 [cit. 2011-12-10]. Sybase. Dostupné z WWW: 22. Umbrello [online]. 2005 [cit. 2011-12-10]. Umbrello. Dostupné z WWW: 23. Oracle Designer [online]. 2003 [cit. 2011-12-10]. Oracle. Dostupné z WWW: 24. Rational Rose [online]. 2005 [cit. 2011-12-10]. IBM. Dostupné z WWW: 25. DIA [online]. 2008 [cit. 2011-12-10]. Live.gnome.org . Dostupné z WWW: 26. MDA Guide [online]. 2003. OMG. Dostupné z WWW: http://www.omg.org/cgi-bin/doc?omg/0306-01.pdf 27. Very rapid applications development [online]. Dostupné z WWW: 28. Java for web [online]. 2008. Dostupné z WWW: 29. The New Executable UML Standards: fUML and Alf [online]. 2011. Dostupné z WWW: http://modeling-languages.com/new-executable-uml-standards-fuml-and-alf/ 30. Documents Associated With Action Language For Foundational UML (ALF) [online]. 2010. Dostupné z WWW: < http://www.omg.org/spec/ALF/1.0/Beta1/ > 31. Model-driven engineering - Wikipedia, the free encyclopedia. [cit. 2011-12-15] Dostupné z WWW: http://en.wikipedia.org/wiki/Model-driven_engineering

Stránka | 30