Nástroje pro vývoj aplikací v závislosti na platformě a jejich vazba na

Fakulta informatiky a statistiky
Informační systémy a technologie
NÁSTROJE PRO VÝVOJ APLIKACÍ
V ZÁVISLOSTI NA PLATFORMĚ A JEJICH
VAZBA NA CASE
Členové týmu:
2
xname
Jméno a příjmení
xpucv02
Vladimír Pucholt
xtump13
Pavel Tůma
xdrad07
Dušan Drábik
xhano06
Ondřej Hanák
xsrnm03
Srnský Martin
3
OBSAH
1
2
3
Úvod.......................................................................................................................................... 6
1.1
Cíl práce ............................................................................................................................. 6
1.2
Charakter práce ................................................................................................................. 6
1.3
Přístup ke zpracování práce ................................................................................................ 6
Definice základních pojmů ......................................................................................................... 7
2.1
IDE ..................................................................................................................................... 7
2.2
CASE .................................................................................................................................. 7
2.3
Platforma ........................................................................................................................... 7
Teoretická úvaha o spolupráci IDE a CASE .................................................................................. 8
3.1
3.1.1
Tvorba modelu a jeho implementace.......................................................................... 8
3.1.2
Prostředek komunikace ............................................................................................ 10
3.2
4
Jak by měla spolupráce fungovat? .................................................................................... 12
Nástroje pro vývoj aplikací v závislosti na platformě................................................................. 15
4.1
5
Proč BY IDE a CASE vůbec měly spolupracovat? .................................................................. 8
Java.................................................................................................................................. 15
4.1.1
Netbeans .................................................................................................................. 15
4.1.2
Eclipse ...................................................................................................................... 17
4.1.3
Rational Requirements Composer ............................................................................ 18
4.1.4
Rational Team Concert ............................................................................................. 22
.NET Framework ...................................................................................................................... 34
5.1
Architektura .NET Framework .......................................................................................... 34
5.2
Common Language Runtime (CLR).................................................................................... 35
5.3
Řízený a neřízený kód ....................................................................................................... 35
5.4
Intermediate language (IL) ............................................................................................... 35
5.5
Typový systém (CTS)......................................................................................................... 35
4
6
7
5.6
Automatická správa paměti .............................................................................................. 35
5.7
Knihovny .......................................................................................................................... 36
5.8
Události ........................................................................................................................... 36
5.9
NET Compact Framework ................................................................................................. 36
5.10
Shrnutí ............................................................................................................................. 37
Visual Studio ............................................................................................................................ 38
6.1
Projekty ........................................................................................................................... 38
6.2
Editace ............................................................................................................................. 39
6.3
Nástroje ........................................................................................................................... 40
6.4
Nápověda a dokumentace................................................................................................ 41
6.5
Visual Studio Express........................................................................................................ 42
6.6
Visual Web Developer ...................................................................................................... 44
6.7
Shrnutí ............................................................................................................................. 44
Visual Studio a vazba na CASE nástroje .................................................................................... 45
7.1
Možnosti integrace Visual Studia a CASE nástrojů............................................................. 45
7.2
Visual Studio a UML ......................................................................................................... 47
7.3
Visual Studio a vybrané CASE nástroje .............................................................................. 48
7.3.1
Microsoft Visio ......................................................................................................... 49
7.3.2
SyBase(SAP) Power Designer .................................................................................... 51
7.3.3
Altova UModel ......................................................................................................... 53
7.4
Shrnutí ............................................................................................................................. 55
8
Závěr ....................................................................................................................................... 56
9
Zdroje ...................................................................................................................................... 57
5
1
ÚVOD
V dnešní době si již neumíme představit vývoj softwaru bez použití nástrojů. Nástroje
používáme od plánování softwaru, návrhu a kreslení diagramů až po programování, testování a
kontrolu [BECK, 2003]. S používáním nástrojů je také spojena úspěšnost projektů vývoje softwaru.
Má-li být projekt vývoje softwaru úspěšný, nestačí jen nástroj, ale zaleží na mnoha dalších faktorech.
1.1
CÍL PRÁCE
Cílem této práce je popsat vybrané nástroje pro vývoj softwarových aplikací v závislosti na
platformě. Dalším cílem, který si náš tým vytyčil, je prozkoumat u těchto nástrojů vazbu na CASE.
Čtenář se díky této práci seznámí s některými CASE nástroji daných platforem a zjistí, jak se od sebe
liší a jakým způsobem napomáhají vývoji softwaru.
1.2
CHARAKTER PRÁCE
Práce je rozdělena do několika částí. V úvodu vysvětlujeme základní pojmy důležité pro
charakter této práce.
1.3
PŘÍSTUP KE ZPRACOVÁNÍ PRÁCE
Při psaní této práce jsme se snažili, aby co nejlépe korespondovala s pracemi již vytvořenými.
Vzhledem k tomu, že tyto práce jsou k dispozici na http://www.panrepa.org/CASE/, předpokládáme,
že čtenář, který čte naši práci, má přístup i k pracím předešlým. Pokud tedy například usoudíme, že
nějaký pojem, který by měl být podrobně vysvětlen, už popsán byl, vysvětlíme ho jen velmi stručně a
případně odkážeme na některou z minulých prací. Podrobněji bychom se chtěli věnovat především
věcem, které zatím příliš vysvětleny nebyly.
6
2
DEFINICE ZÁKLADNÍCH POJMŮ
Definovat pojmy týkající se dané problematiky není primární cíl této práce, ovšem samotný
název naší práce „Nástroje pro vývoj aplikací a jejich vazba na CASE v závislosti na platformě“
obsahuje 3 základní pojmy, které je třeba vymezit. Proto je zde tato kapitola věnována definici
důležitých pojmů.
2.1
IDE
IDE znamená „Integrated Development Environment“, což by bylo možné přeložit jako
integrované vývojové prostředí. Jednoduše bychom mohli IDE definovat jako software, pomocí
kterého lze napsat zdrojový kód mnohem jednoduššeji než pokud je kód psaný v poznámkovém
bloku. Podrobnější informace o tom, k čemu všemu lze IDE využít, se objevily například v pracích
„Nástroje pro vývoj aplikací v závislosti na platformě a jejich vazba na CASE“ ze zimního semestru
2009 nebo „Nástroje pro vývoj aplikací a jejich vazba na CASE“ z jara 2010.
2.2
CASE
CASE neboli „Computer Aided Software Engineering“ jsou nástroje, které mají pomáhat při
vývoji aplikací, a to zejména tvorbou různých modelů a UML diagramů. Tvorba modelů je hlavním
účelem většiny CASE nástrojů, ale pomoci vývoji aplikací lze i jinými způsoby, což je předvedeno
zejména v kapitole týkající se Javy. Opět nebudeme uvádět podrobnější popis toho, co CASE vlastně
je, neboť to už mnohokrát bylo řečeno – například v obou pracích zmíněných v odstavci „IDE“, ale
také ve spoustě dalších prací, neboť CASE je ústřední téma celého předmětu.
2.3
PLATFORMA
Tento pojem nemůžeme přejít pouhým odkazem na předchozí práce. Není to z toho důvodu,
že by v předchozích pracích vysvětlen nebyl, ale protože tento pojem lze chápat různě. Wikipedie
definuje platformu jako „skupinu technických prostředků v informatice a výpočetní technice, které
mluvčí (obecně producent softwarových řešení) používá nebo nabízí jako základ pro další vývoj“. To
ovšem znamená, že platforma může být operační systém nebo například programovací jazyk. Díky
těmto rozdílným pojetím jsou předchozí práce na toto téma poměrně pestré a nám se nabízelo
mnoho možností, jak je nějak doplnit. Nakonec jsme se zaměřili na platformy Java a .NET. Tyto
platformy se sice již v předchozích pracích objevily, ale žádná z nich se nezaměřila přímo na tyto dvě,
7
proto si myslíme, že přehled IDE a CASE nástrojů srovnaný podle těchto dvou velmi populárních
platforem může být přínosný.
3
TEORETICKÁ ÚVAHA O SPOLUPRÁCI IDE A CASE
3.1
PROČ BY IDE A CASE VŮBEC MĚLY SP OLUPRACOVAT?
V předchozích pracích se mnohokrát objevily definice CASE, IDE a základní způsoby jejich
spolupráce. V žádné z nich jsme však nenarazili na odpověď na otázku „proč vůbec spolupracovat?“
Že je tato spolupráce velmi užitečná, si už uvědomilo jistě mnoho lidí, jak je patrné z toho, kolik CASE
a IDE tuto spolupráci podporuje. Tato práce se pokusí předvést, jak může konkrétně funkcionalita
CASE nástrojů týkající se modelování pomoci při vývoji aplikací.
3.1.1 TVORBA MODELU A JEHO IMPLEMENTACE
Case nástroje se zabývají především vytvářením různých modelů. IDE se zabývají především
tvorbou zdrojového kódu. Vytvoření modelu je práce analytika a jeho implementace práce
programátora. CASE nástroje a IDE tedy podporují rozdílné činnosti, které u větších projektů ani
nemusí mít na starost jeden člověk. Avšak tyto činnosti spolu velmi úzce souvisí, a proto by měly
CASE nástroje a IDE být nějakým způsobem propojeny. Zvlášť u menších projektů může být
modelování vnímáno jako něco navíc, něco co zdržuje programátory od toho, aby konečně začali
tvořit něco hmatatelného, ne jenom pěkné barevné obrázky. Avšak i aplikace, jejichž
naprogramování vypadá poměrně nenáročně, může být nakonec velmi komplikovaná, pokud se
začne programovat bez zamyšlení, jak by měla fungovat a jaké funkce obsahovat. K zjištění toho
všeho modelování dobře poslouží a pro vývojáře bude jedině dobře, pokud nástroje použité pro
vytvoření modelu a pro jeho implementaci nebudou fungovat nezávisle na sobě, ale budou se
různými funkcemi podporovat.
Důležitost propojení modelu a vývoje aplikace je možno vypozorovat i z různých metodik pro
vyvíjení softwaru. V prakticky každé má model své pevné místo. Jako příklad lze uvést třeba
metodiku MMDIS [VOŘÍŠEK,1997], která se zabývá vývojem a provozem informačních systémů.
Metodika se skládá ze šesti fází:

Úvodní studie

Globální analýza a návrh
8

Detailní analýza a návrh

Implementace

Zavádění

Provoz a údržba
Za povšimnutí stojí určitě to, že zde jsou 3 fáze, které se týkají především analýz a vytváření
modelů, a teprve poté nastává samotné naťukání kódu v nějakém vývojovém prostředí. Informační
systém je samozřejmě velmi specifická aplikace, která svou složitostí mnohonásobně převyšuje
jednodušší aplikace, a je zde proto na modelování kladen větší důraz než jinde, ale i u jednodušších
aplikací je modelování důležité.
Ještě zřetelněji ilustruje důležitost modelu během vývoje aplikace tento obrázek metodiky RUP:
[RUP, 2010]
3-1 -Průběh vývoje podle metodiky RUP (zdroj: [RUP, 2010])
Na obrázku jsou znázorněny jednotlivé činnosti, kterými je třeba se během projektu zabývat
na svislé ose. Na vodorovné ose jsou potom jednotlivé fáze projektu. Při použití této metodiky
probíhá většinou modelování jeho implementace zároveň. To je především díky tzv. iterativnímu
vývoji, který se snaží o časté vydávání spustitelných verzí. Samozřejmě, první verze jsou chudé, co se
týče funkcionality, důležité je však, že to, co bylo implementováno dobře, funguje. Po vydání verze je
9
třeba vytvoření zpřesňujících modelů, jejich implementace a vydání další verze. Vyvíjení softwaru
pomocí této metodiky si přímo říká o použití CASE nástroje, který je dobře propojen s vývojovým
prostředím.
Metodika MMDIS je určena k vývoji informačních systémů, které jsou mnohem složitější, než
běžné aplikace a metodika RUP je zas určena spíše k vývoji větších aplikací. Existuje však také
spousta lehkých metodik, které se hodí k vývoji menších aplikací. U těchto metodik nebývá tak
podrobně popsáno, co přesně v jakém kroku dělat, spíše jsou to jen taková obecná doporučení, jak
postupovat během vývoje. Avšak i v těchto lehkých metodikách má modelování své místo, což
dokazuje, že není dobré ho zanedbávat ani u vývoje menších aplikací.
Například metodika Feature driven development používá doménové objektové modelování,
které zahrnuje UML class diagram, který má podchytit nejdůležitější vztahy v budoucí aplikaci.
Existuje dokonce metodika nazvaná agilní modelování, která se zabývá přímo tím, jak požívat modely
během vývoje malých aplikací tak, aby byly k užitku, a nikoli ke škodě. Při použití této metodiky by
mělo během vývoje dosaženo toho, že modely budou jednoduché, jejich tvorba nebude zabírat příliš
mnoho času a budou dostatečně podrobné na to, aby ukázaly vše podstatné.
3.1.2 PROSTŘEDEK KOMUNIKACE
U softwaru vyvíjeného na zakázku obvykle programátor nebude aplikaci, kterou vytváří,
nikdy používat. Aplikace je vyvíjena pro zákazníka, který daný software potřebuje, avšak obvykle není
schopen ho sám naprogramovat. (Pod pojmy programátor a zákazník se v tomto případě nemusí
skrývat jedna osoba. Obě strany můžou být také velká mezinárodní společnost.) Potřebuje ale
programátorovi nějakým způsobem sdělit, co od něj vlastně potřebuje a jakým způsobem by měla
výsledná aplikace fungovat. Programátor zase potřebuje nějakým způsobem komunikovat se
zákazníkem, například dodat mu nějaký zpřesňující návrh, nebo pokud si to myslí, sdělit zákazníkovi,
že by bylo vhodné přidat další funkce. Je třeba myslet na to, že i když zákazník nedokázal správně
nadefinovat funkcionalitu, kterou opravdu potřebuje, je dobré snažit se mu tuto funkcionalitu dodat.
Pokud zákazník nedostane to, co potřebuje, může se příště obrátit na někoho jiného, kdo mu dodá
užitečnou aplikaci, i pokud nedovede úplně přesně vyjádřit, co vlastně chce. Právě model je dobrým
prostředkem komunikace. Ačkoli se zákazník pravděpodobně ve zdrojovém kódu nevyzná, dobře
vytvořený model by měl pochopit. Komunikace pomocí modelu v průběhu projektu může být velmi
užitečná. Ze začátku může programátor zákazníkovi předvést, jak bude aplikace fungovat před tím,
než bude muset vůbec začít s programováním. Je tak daleko větší šance, že zákazník zjistí, že by
vlastně chtěl, aby aplikace fungovala trochu jinak, dřív, než budou v projektu utopeny velké finanční
10
prostředky. V dalších fázích potom může být pomocí modelu ukázán dopad navrhovaných změn.
Také může model posloužit třeba k tomu, aby bylo zákazníkovi vysvětleno, jak vlastně aplikace
funguje, a zákazník tak nedostal jen jakousi černou skříňku. Pochopení aplikace může pomoci
například tomu, že zákazník bude vědět, jak přesně zadat vstupy, aby nedocházelo k nesprávným
výstupům.
Pokud byl tedy vytvořen model, který měl demonstrovat nějaký aspekt aplikace, bude jedině
dobře, když bude moct být část kódu vytvořena automaticky za pomoci tohoto modelu.
Pochopitelně může nastat i opačný případ, kdy část kódu již bude hotova a bude potřeba vytvořit
nějaké grafické přehledné vyjádření tohoto kódu.
Potřeba komunikace je také mezi jednotlivými programátory projektového týmu. Tady je sice
pravděpodobné, že všichni budou rozumět všem částem kódu, ale přesto může být modelování
často užitečné. Například při tvorbě nové verze je lepší nejdřív udělat model, který může celý
projektový tým prodiskutovat, případně upravit, a až poté ho implementovat, než když budou
jednotliví členové týmu své návrhy demonstrovat přímo případnou změnou kódu. Zvlášť pokud bude
existovat způsob, jak z modelu části kódu dopsat. Nikdo pak nebude mít pocit, že tvorbou modelu se
vlastně nic nevytváří.
11
Jako příklad, kdy model může dobře posloužit jako prostředek komunikace, by se dal uvést
třeba sequence diagram.
3-2 Sequence diagram (zdroj: [BUS, 2010])
Tento diagram zachycuje, jakým způsobem si jednotlivé objekty mezi sebou vyměňují zprávy.
Například diagram nahoře ukazuje zasílání zpráv během přihlašování k webové aplikaci. To, co je
zakresleno na tomto diagramu, by šlo vyčíst i ze zdrojového kódu, pokud člověk ovládá programovací
jazyk, ve kterém je aplikace napsaná. Naproti tomu tento graf je schopen interpretovat i člověk,
který nemá s programováním zkušenosti. Pokud je aplikace vyvíjena pro programování neznalého
zákazníka, je možné mu na sekvenčním diagramu poměrně přesně ukázat, jak bude aplikace
fungovat. Poté co bude zákazník se sekvenčním diagramem spokojen, lze v případě dobré spolupráce
mezi CASE nástrojem a IDE rovnou z tohoto diagramu vytvořit základ kódu, což ušetří spoustu práce.
Stejně jako semence diagram, můžou sloužit ke komunikaci i další diagramy. Například use-case
diagram při diskuzi nad potřebnou funkcionalitou a jejími případnými změnami.
3.2
JAK BY MĚLA SPOLUPRÁCE FUNGOVAT?
12
V předchozí části byly osvětleny důvody, proč by tato spolupráce vůbec měla existovat. Další
část se bude zabývat tím, jak může tato spolupráce fungovat. Jak bylo zmíněno dříve, tvorba modelu
pomocí CASE nástroje by měla předcházet jeho implementaci v určitém vývojovém prostředí.
V ideálním případě, když je model navržen opravdu dobře, stačí programátorovi pouze mechanické
přepsání modelu do kódu. Takový ideální případ sice málokdy nastane, ale přesto ve většině případů
tráví programátor mnoho času činnostmi, které nevyžadují rozsáhlou myšlenkovou aktivitu, tedy
činnostmi, které by mohl klidně zvládnout stroj. Tady je právě prostor pro spolupráci. Pokud bude
model vytvořen dobře a podle jistých pravidel, která budou dodržována, mělo by být možné, aby byl
tento model nějakým způsobem automaticky převeden do zdrojového kódu. Tento převod může
fungovat oboustranně. To znamená, že stejně jako je možno z modelů získat zdrojový kód, tak i ze
zdrojového kódu může být získán model.
Další příklad ukáže jeden ze způsobů, jak je možno z určitého diagramu získávat kód. Na
následujícím obrázku je tzv. class diagram [BUCHALCEVOVÁ,2007+, který zachycuje strukturu tříd
v aplikaci a vztahy mezi jednotlivými třídami.
3-3 Ukázaka class diagramu
Tento class diagram ukazuje část návrhu aplikace, která bude spravovat účty jednotlivých
klientů banky. Vytvoření tohoto diagramu stálo analytiky jistě určité úsilí, které je třeba co nejlépe
zužitkovat, což znamená snažit se, aby tento digram pokud možno co nejvíc usnadnil programátorům
práci.
13
Pokud má CASE nástroj dostatečnou funkcionalitu, je možno získat z tohoto diagramu
definice jednotlivých tříd, jejich atributů a jejich metod. Také je možno rovnou vytvořit přístupové
metody k jednotlivým atributům. S implementací jednotlivých metod sice už diagram nepomůže, ale
důležité je to, že prakticky nebude nutné jednu práci dělat vícekrát.
14
4
NÁSTROJE PRO VÝVOJ A PLIKACÍ V ZÁVISLOSTI NA PLATFORMĚ
Pro naši práci jsme vybrali dvě nejpoužívanější a nejrozšířenější platformy, Javu a .Net.
4.1
JAVA
Dle [Java, 2010] je platforma Java počítačová platforma zastřešující různé varianty
použití programovacího jazyka.
Platforma Java zastřešuje následující dílčí platformy:

JavaCard – pro aplikace provozované v rámci tzv. „chytrých“ karet (např. platební a kreditní
karty atp.),

Java ME – pro aplikace provozované na mobilních zařízeních (mobilní telefony, PDA, atp.),

Java SE – aplikace provozované na stolních počítačích,

Java EE – aplikace pro podnikové a rozsáhlé informační systémy.
Jednotlivé dílčí platformy sdílejí společné koncepty, kterými jsou:

syntaxe jazyka Java,

virtuální stroj Javy – Java Virtual Machine (JVM),

obdobné API standardních knihoven funkcí.
V následujících podkapitolách popisujeme nástroje, které podporují a napomáhají vývoji
softwarových aplikací. V Kapitolách 4.1.1 a 4.1.2 okrajově zmiňujeme nástroje NetBeans a Eclipse,
protože již byly více než podrobně zmíněny v pracích předchozích. V kapitolách 4.1.3 a 4.1.4
popisujeme nástroje IBM řady Rational, protože se jedná o moderní nástroje pro podporu vývoje
aplikací, které se dají integrovat s nástroji NetBeans, Eclipse a dalšími. Popis těchto nástrojů vidíme
jako velký přínos tohoto dokumentu, jelikož nebyl ještě zpracován či popsán v předchozích pracích.
4.1.1 NETBEANS
NetBeans IDE je bezplatné, open-source vývojové prostředí pro softwarové vývojáře.
Vzhledem k tomu, že je kompletně naprogramováno pomocí programovacího jazyka Java, je
nezávislé na platformě a lze jej tedy provozovat na mnoha odlišných operačních systémech jako
15
Microsoft Windows, Linux, Solaris a MacOS. NetBeans IDE poskytuje vývojářům veškeré nástroje,
které potřebují pro tvorbu profesionálních, na platformě nezávislých aplikací.
NetBeans jsou vývojovým prostředím pro programovací jazyk Java. Vzhledem k tomu, že je
Java rozdělena do tří edic, tj. J2SE, J2ME a J2EE, lze pomocí NetBeans vytvářet aplikace desktopové,
enterprise aplikace, webové aplikace či aplikace pro mobilní zařízení. [Pitka, 2007]
Níže uvedená ukázka NetBeans, včetně popisu [Pitka, 2007], názorně ukazuje hlavní
možnosti a rozmístění komponent v tomto prostředí.
Obrázek 4-1
1. Hlavní menu aplikace – pomocí hlavního menu je možno přistupovat k veškeré funkcionalitě
aplikace. Některé nově nainstalované moduly mohou přidat další položky do menu a naopak při
odebrání modulu jsou položky menu odebrány.
2. Nástrojová lišta (toolbar) – obsahuje volby, které uživatel využívá často. Položky v nástrojové liště
je možno libovolně nastavovat pomocí menu View – Toolbars.
3. Okno pro práci se soubory – okno obsahuje tři záložky: Projects, Files a Runtime.
4. Navigátor
16
5. Output
6. Welcome obrazovka – tato obrazovka slouží jako počáteční bod při spuštění NetBeans. Obsahuje
množství voleb, které můžete po spuštění provést. Okno je rozděleno do následujících částí:
6.1. Skupina Getting started – obsahuje odkazy na nejrůznější dokumenty, které mohou pomoci
vývojářům v začátcích práce s NetBeans. Také jsou zde odkazy na dokumenty „What’s new“, tedy
novou funkcionalitu této verze NetBeans.
6.2. Skupina Sample projects – slouží k rychlému vyvolání okna New Project s výběrem tzv. sample
projects, tedy vzorových projektů. Jsou uvedeny odkazy na vytvoření vzorové obecné aplikace,
webové aplikace, enterprise aplikace, pluginu k NetBeans a odkaz na Java BluePrints Solutions.
6.3. Skupina Articles & News – obsahuje aktuální informace týkající se NetBeans. Jsou zde odkazy na
nejnovější články na www.netbeans.org. Tato skupina vyžaduje přístup k Internetu, aby mohla načíst
informace o článcích.
6.4. Skupina Blogs – obsahuje aktuální informace z vybraných blogů týkajících se NetBeans. Opět je
vyžadován přístup k Internetu pro načtení informací.
6.5. Zatrhávací tlačítko Show on Startup – pokud je zatržené, zobrazí se Welcome obrazovka při
každém spuštění NetBeans.
4.1.2 ECLIPSE
Dle [Eclipse, 2010] je Eclipse opensource vývojová platforma, která je pro většinu lidí známa
jako vývojové prostředí (IDE) určené pro programování v jazyce Java. Flexibilní návrh této platformy
dovoluje rozšířit seznam podporovaných programovacích jazyků za pomoci pluginů, například
o C++ nebo PHP. Právě pluginy umožňují toto vývojové prostředí rozšířit například o návrh UML, či
zápis HTML nebo XML.
Oproti ostatním vývojovým prostředím v Javě, jako například Netbeans, je filozofie Eclipse
úzce svázána právě s rozšiřitelností pomocí pluginů. V základní verzi obsahuje Eclipse pouze
integrované prostředky pro vývoj standardní Javy jako kompilátor, debugger atd., ale neobsahuje
například nástroj pro vizuální návrh grafických uživatelských rozhraní desktopových aplikací
nebo aplikační server – všechna taková rozšíření je potřeba dodat formou pluginů. Z tohoto důvodu
přímo pod křídly Eclipse vznikly takzvané subprojekty, které zastřešují rozšíření pro jednotlivé oblasti
softwarového vývoje v Javě. Tyto subprojekty usnadňují integraci potřebných rozšíření do
samotného vývojové ho prostředí. Eclipse je v současnosti nejpopulárnější IDE pro Javu.
17
Obrázek 4-2
Projekt Eclipse (Eclipse 1.0) vznikl uvolněním kódu IBM pod EPL licencí. Hodnota tohoto
příspěvku open source se odhaduje na 40 miliónu dolarů. Pro účely tohoto projektu byl vyvinut
grafický frameworkSWT. Výhodou SWT je nativní vzhled aplikací na každé platformě, kde je SWT
portován (SWT využívá nativního kódu operačního systému). Naproti tomu konkurenční
framework Swing využívá pouze služby JVM, což umožňuje lepší portovatelnost (omezenou pouze
dostupností Javy pro danou platformu).
Eclipse ve verzi 3.0 adaptoval na široce podporovaný standard OSGi R4 (Eclipse project
Equinox), čímž získal na atraktivnosti jako vývojová platforma. Technologie balíčků (OSGI bundle ~
Eclipse plugin) umožňuje snadnou rozšířitelnost produktů. Výhodou této architektury je dynamické
nahrávání pluginů až v okamžiku potřeby, čímž se minimalizují systémové nároky i čas potřebný pro
start aplikace.
4.1.3 RATIONAL REQUIREMENTS COMPOSER
18
Kvalitu projektu určuje úroveň splnění požadavků klienta. Rational requirements composer
umožňuje vtáhnout zainteresované strany (zákazníka) tím způsobem, že jsou součástí projektu. Díky
tomuto nástroji můžou vývojáři a zákazník vzájemně spolupracovat na definování a ověřování
správnosti požadavků. Výstupy pak budou umožňovat přesně to, co si zákazník přeje. Mnoho druhů
artefaktů je třeba vyjádřit požadavky v souvisejícím organizačním kontextu a omezeních, tyto
artefakty jsou však vytvořeny v různých nástrojích a datových formátech. Může se jednat
například o: tabulky, prezentace, grafy, nebo nahrávky z webových konferencí. Rational
requirements composer nabízí způsob, jak spojovat tyto "informace", propojovat je s odkazy a
atributy. Tento nástroj umožňuje spojit obě zainteresované strany do jednoho týmu. Na obrázku 4-3
vidíme, jakým způsobem se dají vytvářet, editovat a komentovat vytvořené use case a ostatní
artefakty.
Obrázek 4-3: Initial review of baseline use case (zdroj: [RRC, 2010])
Projektový tým definuje, čeho je potřeba dosáhnout. Rational requirements composer
pomáhá týmu se přirozeně pohybovat od nestrukturovaných myšlenek vyjádřených v prezentacích
a neoficiálních dokumentech k dokumentům strukturovaným, s přesně definovanými požadavky.
Vyjádřenými jako scénáře, případy užití, deklarativní požadavky a pracovní položky. Rational
19
requirements composer obsahuje editory pro případy užití, návrhy uživatelského rozhraní a
storyboardy1, procesy, rich text dokumenty, a integrované slovníky. Autoři dokumentů (analytici a
další) mají všechny tyto editory k dispozici, s podobnými uživatelskými rozhraními, využívající
společné úložiště.
Obrázek 4-4: Ukázka dashboardu (zdroj: [RRC, 2010])
Uživatelská rozhraní poskytují způsob, jak vyjádřit uživatelské scénáře intuitivně, stejně jako
filmoví producenti využívají storyboardy ke komunikaci. Rational requirements composer používá
webový klient, který umožňuje snadný přístup pro zainteresované strany a příležitostným uživatelům
prohlížet, hodnotit, komentovat a schvalovat požadavky artefakty a soubory artefaktů. Na obrázku 44 je vidět dashboard, který umožňuje uživateli kontrolu nad projekty, v kterých je zainteresován.
Dále má přehled o průběhu projektu, průběhu jednotlivých etap a úrovně splnění deklarovaných
požadavků.
4.1.3.1 MODELOVÁNÍ V RRC
1
Storyboard je sekvence obrázků vytvořená za účelem previzualizace výsledného díla
20
Tento nástroj umožňuje modelování různých procesů, diagramů a dalších. Za pomoci BPMN
2.0, či BPEL RRC je tak robustní nástroj, že už není potřeba ho integrovat s nástroji pro modelování,
ale pokud je potřeba integrovat z důvodů, které tento nástroj nenabízí, je naproti snadné jej
integrovat s jinými nástroji. Především však s nástroji od Rational. Je schopen ke každé činnosti, která
je v business procesu znázorněna přiřadit člena týmu, který za ni zodpovídá, a zároveň k této činnosti
přidat zdroje a dokumenty, které můžou tomuto pracovníkovi pomoci s vytvářením užitné vlastnosti.
Na obrázku 4-5 je vidět diagram s posloupnostmi jednotlivých činností. V případě, že chci
k jednotlivým činnostem přidat odkaz na vnější zdroj či chci poukázat na novou skutečnost, můžu
použít link, který pracovník uvidí okamžitě, při změně činnosti, za kterou zodpovídá, protože ho
systém upozorní e-mailem či jinak. Pokud se analytik zodpovědný za modelování rozhodne změnit
posloupnost činností, či změní nějakou entitu v diagramu, okamžitě se o ní dozvědí všichni
pracovníci, kteří mají tyto činnosti na starosti. Díky archivaci změn jsou schopni nahlédnout do
historie a tyto změny vidět.
Obrázek 4-5: BPM
Mezi další možnosti modelování v Rational Requirements Composer patří například Use Case
diagramy. Tento robustní nástroj umožňuje vytvořené modely propojovat s jinými, tak aby byla
zachována konzistence v úvodní analytické části projektu. Na obrázku 4-6 je vidět Use case diagram a
způsob, jakým je vytvářen. Tím, že se diagramy a modely vytváří přímo v tomto nástroji, není třeba,
aby byl někam ukládán a dále vkládán nějakými způsoby do RRC. Modelování mimo tento nástroj by
přineslo do projektu větší míru chaotičnosti a menší míru integrace a propojitelnosti jednotlivých
komponent mezi sebou. Kdykoliv by se změnily požadavky nebo by si analytik uvědomil chybu, bylo
21
by třeba opět vytvářet či předělávat model, diagram v externím nástroji a to by přineslo velké
zdržení a komplikace. V případě RRC je možné provést změny bez větších starostí, protože změna se
projeví ve všech komponentách napříč celým projektem. Okamžitě budou všichni účastníci
informováni a budou schopni si vyhledat předešlou verzi díky správě verzí a sledování změn.
Obrázek 4-6: Use case diagram
Rational requirements composer umožňuje spolupráci s Rational Team Concert, který si
představíme v příští kapitole. Vývojáři a testeři tak mohou využívat podobné vlastnosti, které jim
nabízí oba tyto nástroje řady Rational.
4.1.4 RATIONAL TEAM CONCERT
Rational Team Concert (dále RTC) je softwarový nástroj pro týmovou práci na projektech.
RTC je vytvořený společností IBM kategorie Rational. První verze RTC 1.0 se objevila na trhu
v polovině roku 2008. Poslední verzí, která se objevila na trhu v polovině dubna 2010, je RTC 3.0.
22
Hlavním cílem tohoto nástroje je usnadnit a zefektivnit práci na projektech, kde jsou
jednotliví členové týmu geograficky distribuováni a tudíž nemůže probíhat osobní komunikace.
Nástroj nabízí možnosti řízení a správy projektu, podporu procesů a aktivit spojených s budováním
softwaru. Dále nabízí využívání metodik, umožňuje dodržování stanovených standardů a norem.
Velkým přínosem je transparentnost a dohled nad projektem a prací v reálném čase a reporting
současného stavu projektu. [RTC, 2010]
Při podrobnějším popisu funkcionalit a vlastností vycházíme ze serveru jazz.net [Jazz, 2010].
Rozdělili jsme je tedy do pododstavců, které charakterizují RTC.
PŘIZPŮSOBITELNOST PROCESŮ
Projekty vývoje softwaru se od sebe velice liší. Způsoby, jak postupovat při vývoji, závisí na
mnoha faktorech. Z těchto důvodů není možné nalézt univerzální proces, který by fungoval na všech
projektech. Proto je důležité, aby nástroje pro vývoj softwaru umožňovaly konfiguraci a přizpůsobení
procesů pro specifické potřeby projektu. [FOWLER, 2009]
RTC přizpůsobení a konfigurací procesů dle potřeb projektu umožňuje. Dále umožňuje
vytváření, či exportování nových šablon procesů. RTC zlepšuje produktivitu týmů a kvalitu práce
(produktů) tím, že umožňuje týmům používání nejlepších praktik obsažených v metodikách. Týmy si
tyto praktiky mohou přizpůsobit svým potřebám či vytvořit nové. RTC využívá těchto informací
k automatické detekci porušení procesů a praktik ve chvíli, kdy se nedodržují.
TÝMOVÉ POVĚDOMÍ
V RTC jsou uloženy informace o projektovém týmu, jeho vnitřní organizaci a artefaktech, na
kterých pracují. To velice zjednodušuje přístup uživatelů k informacím nebo operacím spojených
s týmem. Každý projekt má definované své procesy, v jejichž rámci lze upravovat týmy a jejich práva
tak, aby odpovídaly potřebám projektu. Týmová organizace může být spravována buď
prostřednictvím webového rozhraní, nebo některého z klientů zobrazených na obrázku 4-2.
Pro každý druh projektu jsou předdefinovány určité role, které jsou přiřazovány jednotlivým
členům týmu, jak je vidět na obrázku 4-3. Podle potřeby je možné definovat nové role a přidělovat je
členům týmu. Při koordinaci práce na projektu je důležité stanovit pracovní prostředí uživatelů.
Členové týmu mohou být v různých časových pásmech, proto je důležité nastavit pracovní dobu.
Díky tomu se lépe odhaduje a plánuje práce na projektu.
23
Obrázek 4-7: Předdefinované role procesu pro OpenUP
Dalším přínosem RTC je komunikace mezi členy týmu. Je několik možností, jak může probíhat
komunikace v rámci RTC. Členové týmů mezi sebou mohou interaktivně komunikovat nebo si posílat
příspěvky a komentovat práci svého kolegy. Klient RTC pro Eclipse nabízí 3 druhy poskytovatele
instant messagingu2: Google talk, Sametime ve dvou verzích a Jabber. Na obrázku 4-4 je vidět
probíhající komunikace. Nespornou výhodou je možnost používání odkazů na pracovní položky
(obrázek 4-4).
2
"Instant messaging je internetová služba umožňující svým uživatelům sledovat, kteří jejich přátelé jsou právě
připojeni, a dle potřeb jim posílat zprávy, chatovat, přeposílat soubory mezi uživateli a i jinak komunikovat."
[PROCHAZKA, 2010]
24
Obrázek 4-8: Ukázka komunikace v Eclipse(zdroj: [Team Aware,2010])
SLEDOVÁNÍ PRACOVNÍCH POLOŽEK
Pracovní položky jsou základním mechanismem v RTC pro sledování vývoje úkolů a
workflow3. Kromě pracovních položek jsou důležité další vazby mezi RTC artefakty4 (např. buildy,
pracovní položky a změna sestavy) jako poskytování podpory pro integraci s ostatními produkty. RTC
umožňuje vytvářet nové typy pracovních položek nebo upravovat stávající typy pracovních položek
s cílem podpořit dosažení cílů, na kterých tým pracuje. Na obrázku 4-5 vidíme u každého uživatele
stav jeho práce v rámci projektu. Zelená barva znázorňuje, že je vše v pořádku a splněno.
Nepřiřazené nové pracovní položky se dají myší přesunout na ukazatel průběhu (progress bar) 5 práce
uživatelů a tím je snadno přiřadit.
3
Workflow znamená automatizaci celého podnikového procesu nebo jeho části, během kterého jsou dokumenty, informace, nebo úkoly
předávány od jednoho účastníka procesu ke druhému podle sady procedurálních pravidel tak, aby se dosáhlo nebo přispělo k plnění
celkových, resp. globálních cílů. Přeloženo z [WfMC, 1996]
4
Artefakt je výstup, který je vytvářen v průběhu procesu vývoje softwaru. *BUCHALCEVOVÁ,2009+
5
Progress bar je prvek, který se používá ke znázornění průběhu déle trvající práce.
25
Obrázek 4-9: Přehled odvedené práce v rámci týmu (zdroj: *Team aware,2010+)
AGILNÍ PLÁNOVÁNÍ
RTC komponenta agilní plánování poskytuje nástroje pro asistenci při plánování a provádění
iterací při vývoji. Poskytuje nástroje pro vytváření plánů iterace, vytváření individuálních plánů pro
vývojáře, sledování vývoje v průběhu iterace a rozložení práce pro vývojáře. Plány jsou přístupné
všem členům týmu a mohou být dynamicky pozměňovány v průběhu iterací tak, aby reflektovaly
aktuální potřeby týmů.
Plány se v RTC člení podle časových os. V RTC je možné upravit časovou osu dle potřeb
projektu nebo definovat svou vlastní osu. Struktura časové osy se liší dle použité metodiky. Na
obrázku 4-6 je znázorněna základní časová osa projektu dle metodiky OpenUP. Modrá šipka ukazuje,
která fáze projektu je aktuální.
Obrázek 4-10: Časová osa projektu dle OpenUP
Plán lze vytvořit vzhledem k celému projektu, fázi a iteraci. K tomuto plánu je pak možno
přidělit pracovní položky, které se mají vykonat. To napomáhá v přehledu o dění na projektu a jeho
26
vývoji. Na obrázku 4-7 je znázorněn plán, ve kterém vidíme pracovní položky každého uživatele,
které se mají udělat (To Do), pracovní položky, na kterých se v současnosti pracuje (In Progress) a
pracovní položky hotové (Done). Na každý plán se lze dívat pomocí několika pohledů (například
podle uživatelů, plánovaného času apod.), které jsou znázorněny v pravé části obrázku 4-7.
Obrázek 4-11: Plán iterace (zdroj:*Agile Planning,2010+)
PLYNULÉ BUILDY
Komponenta týmových buildů poskytuje informace o buildech, kontrolu a sledování pro tým
(obrázek 4-8). Členové týmu mohou sledovat vývoj buildu, různá upozornění a výsledky aktuálních
buildů, vyžadovat a sledovat buildy k dalším artefaktům, jako jsou změny sestav a pracovních
položek.
27
Obrázek 4-12: Přehled Buildů (zdroj: [Build, 2010])
Dále je možné sledovat, jaké buildy proběhly, kolik obsahovaly pracovních položek a souborů
(obrázek 4-9) a další statistiky (Například: Kolik práce odvedli jednotliví uživatelé). S buildy je spojena
změna sad (Change sets), díky které je možné ve výsledcích buildů sledovat změny, které proběhly,
kolik zahrnovaly pracovních položek apod. (obrázek 4-9).
Obrázek 4-13: Souhrn o proběhlém buildu(zdroj: *Build,2010+)
TRANSPARENTNOST
RTC komponenta týmové reporty a webové dashboardy pomáhá udržet přehled o stavu
a zdraví projektu. Dashboardy poskytují přehledný pohled na dotazy na pracovní položky, události
28
a další položky důležité pro porozumění vývoje projektu. Například ve formě grafu typu burndown6,
což je graf využívaný v metodice Scrum [LARMAN, 2004]. Na obrázku 4-10 jsou uvedeny příklady
možných pohledů (viewlet), což jsou dotazy na používané položky (Například: Pracovní položky),
které nám zobrazují různé statistiky pomocí grafů. V tomto případě ukazuje horní graf poměr
otevřených pracovních položek k/ke zavřeným a dolní koláčový graf, který ukazuje rozdělení
pracovních položek mezi uživatele.
Obrázek 4-14: Dashboard(zdroj: [Build,2010])
Reporty poskytují historický i aktuální vývoj buildů, pracovních položek a dalších položek, se
kterými tým pracuje. Reporty se dají z RTC vyexportovat, například do formátů PDF, PostScript, Excel,
Word a PowerPoint.
ADMINISTRACE
Jazz team server poskytuje webové uživatelské rozhraní pro nastavení, konfiguraci
a administraci serveru. Konfigurace serveru může být pozměněna a uložena autorizovaným
6
Burndown je graf zobrazující množství práce, které zbývá dodělat v rámci aktuální iterace. [COHN, 2004]
29
administrátorem webovým prohlížečem v mnoha instancích bez vyžadování restartu serveru.
Administrátoři mohou zobrazit klíčové statistiky a podívat se, které žádosti se v současnosti
vykonávají.
Webové rozhraní také poskytuje možnost jednoduchého nastavení serveru pomocí
průvodce, který ukáže nastavení základních konfiguračních nastavení, jako jsou konfigurace
databáze, e-mailové upozornění, uživatelské nastavení a LDAP integrace. Tohoto průvodce jsme
vyzkoušeli pro rychlé nastavení serveru a práci s RTC.
INTEGRACE
RTC je možné integrovat také s ostatními produkty řady Rational, jako jsou Rational Quality
Manager, Rational ClearQuest a Rational ClearCase. Integrace s Rational Quality Manager a Rational
ClearQuest je součástí aplikace pro spolupráci a řízení životního cyklu (C/ALM), které obsahuje také
Rational Requirements Composer. Dále spolupracuje s produkty řady IBM Lotus (Například: IBM
Lotus quickr, IBM Lotus notes a IBM Lotus Connection). Celý seznam produktů, které se s RTC dají
integrovat nebo s ním spolupracují je dostupný na webových stránkách jazz.net. [Integrations, 2010]
WEBOVÝ KLIENT
Jednou z možností, jak se připojit k RTC, je webový klient, který nabízí mnoho možností práce
s projekty, od vytváření projektu až po práci s pracovními položkami.
Webový klient umožňuje konfiguraci serveru (nastavení ukládání souborů, možnost
nastavení SMTP serveru po zasílání zpráv a další), správu uživatelů, projektů a šablon procesů,
zobrazování statistik a grafů formou dashboardů a reportů. Tyto možnosti jsou spojené pouze
s právy administrátora, který může přes webové rozhraní vytvořit projekt, týmy, uživatele, pracovní
položky, nastavit oprávnění, přidělit role a další možnosti, jejichž popsání se věnují scénáře případů
užití pro webového klienta (kapitola 3). Administrátorem vytvořený uživatel může také přistupovat
k RTC přes webové rozhraní, má však omezené možnosti dle nastavených práv a licencí pro přístup.
ECLIPSE KLIENT
Pro vývojáře je nástroj Eclipse jednou z možností, jak spolupracovat na projektu pomocí RTC.
Mezi další nástroje, se kterými RTC spolupracuje přes klienta, patří například Visual Studio. Pokud
uživatel (vývojář) nástroj Eclipse již vlastní, je možné klienta doinstalovat. V případě, že Eclipse
nevlastní, je možné si jej nainstalovat s už integrovaným klientem.
30
Klient vkládá do nástroje Eclipse nové funkcionality, které umožňují pracovat týmově
v reálném čase na projektu. Na obrázku 4-11 (vlevo: nástroj Eclipse s klientem RTC; vpravo: nástroj
Eclipse bez klienta RTC) je vidět, že klient RTC nabízí více možností pro teamovou spolupráci.
Například hlídání změn, připojení k úložišti, týmovou organizaci, týmové artefakty a další možnosti,
které klasický Eclipse neobsahuje.
Obrázek 4-15: Rozdíly nástroje Eclipse s klientem a bez klienta čeho
POHLED TEAM ARTIFACTS
Pomocí tohoto pohledu, či záložky je možné sledovat všechny artefakty, které souvisejí
s projektem, na kterém tým vývojářů pracuje. Nacházejí se zde projekty, ke kterým je uživatel
připojen, dále pracovní plocha (Repository workspace), týmové oblasti uživatele (My team areas),
jeho pracovní položky a dále (Obrázek 4-12).
31
Obrázek 4-16: Team artifacts
V tomto pohledu je možné vytvářet nové plány, pracovní položky, přiřazovat je uživatelům
a dotazovat se na ně.
POHLED PENDING CHANGES
Tento pohled je spojen se změnou sestav (Change sets), který poskytuje informace
o uskutečněných změnách. Obrázek 4-13 ukazuje změnu ve tříde Class.java. Uživatel tuto změnu
může okomentovat, přijmout, odmítnout či sdílet.
Obrázek 4-17: Změna zdrojové kódu
ZÁLOŽKA WORK ITEMS
Záložka work items zobrazuje pracovní položky, které jsou výsledkem dotazu. Obrázek 4-14
ukazuje výsledek dotazu, které pracovní položky jsou otevřené a určené přihlášenému uživateli.
Jednotlivé atributy (ID, Stav, Souhrn, Vlastník a další) pracovních položek se dají přidat či naopak
odstranit podle potřeby. Uživatel může například zobrazit, do jaké části plánu pracovní položka patří.
32
Obrázek 4-18: Záložka Work Item
33
5
5.1
.NET FRAMEWORK
ARCHITEKTURA .NET FRAMEWORK
V současné době představuje .NET Framework základ pro vývoj aplikací pro platformu Windows.
Tvoří jej, kromě velkého množství knihoven, kompletní běhové prostředí pro spouštění a provoz
aplikací. Framework poskytuje objektově orientované nástroje pro vývoj moderních, uživatelsky
orientovaných aplikací.[Wikipedie, 2010]
Integrované knihovny umožňují programátorům odklonit se od řešení stále stejných rutinních
činností a zaměřit se na funkčnost svých výtvorů. Prostředí pro běh kódu si samo spravuje paměť, je
typově bezpečné a snaží se eliminovat rozdíly mezi vývojem aplikací pracujících lokálně a třeba
webových služeb.[Šimeček, 2010+
Obrázek 5-1 - Architektura .NET Framework
Dvě velmi podstatné součásti jádra jsou CLR (neboli Common Language Runtime) a BCL (Base Class
Library). *Šimeček, 2010+
34
5.2
COMMON LANGUAGE RUNTIME (CLR)
CLR je základní běhové prostředí pro spouštění řízeného kódu. Implementuje „centrální“ typový
systém a kompletně se stará o běh programu. Mezi službami, které obsahuje, jsou: automatická
správa paměti (Garbage Collector), podsystém výjimek reagujících na chyby a pády, integrace
s Win32 a COM, JIT kompilace, podpora 64bitové architektury atp.
5.3
ŘÍZENÝ A NEŘÍZENÝ KÓD
V textu se často vyskytuje pojem řízený kód (managed code). Jedná se o zdrojový kód napsaný ve
vyšším jazyce (C#, VB.NET, C++…) a následně zkompilovaný do binárního formátu (ve formě tzv.
sestavení, anglicky assembly), který zpracovává CLR. Takový kód těží z vlastností rozhraní .NET
Framework, protože není nutné programátorsky dále řešit správu paměti nebo například typovou
bezpečnost. Opakem je pak kód neřízený (unmanaged code). (Wikimedia Foundation, 2010)
5.4
INTERMEDIATE LANGUAGE (IL)
IL (celým názvem Common Intermediate Language – CIL, dříve známý jako MSIL) je jazyk nezávislý na
procesoru a platformě, do kterého jsou kompilovány všechny řízené jazyky. CLR při spuštění
programu vezme metadata vytvořená překladačem, vyhodnotí je, vytáhne z nich IL kód a spustí jej.
Nikoliv přímo, ale po tzv. JIT (Just In Time – právě včas) kompilaci do nativního kódu architektury.
Název JIT vychází z toho, že kompilace probíhá za běhu, až ve chvíli, kdy je kód vyžadován. Zároveň je
zaručen překlad do instrukční sady stroje, na kterém běží. *Šimeček, 2010+
5.5
TYPOVÝ SYSTÉM (CTS)
V rámci CLR se jakýkoliv kód spouští v rámci pevně daného typového standardu Common Type
System (CTS). Ten představuje rozhraní mezi řízeným kódem a samotným běhovým prostředím.
Navíc předkládá sadu pravidel, která musí kód splňovat, aby byl označen za typově bezpečný (a jako
takový vyhýbající se problémům s pamětí). Díky CLR pak nezáleží na konkrétním jazyku, podstatné je,
že jakýkoliv kód je kompilován do stejné sady konstruktů.
CLR je silně typové prostředí. Bez ohledu na to, v jakém jazyce je program tvořen, zda je statický (C#,
Java, Haskell, F# apod.) či dynamický (VB, Python, Perl, Ruby a další), překladač si nakonec vždy musí
poradit s datovými typy na nejnižší úrovni. Všechny typy v .NET jsou objektové. Základem je třída
System.Object. *Šimeček, 2010+
5.6
AUTOMATICKÁ SPRÁVA PAMĚTI
35
.NET obsahuje podsystém Garbage Collector, který se stará o správu paměti programu a snaží se
chytře získávat volné místo. Pokud na objekt neexistují žádné aktivní reference, GC rozhodne, že je
bezpečné jej odstranit, provede to a v druhé fázi paměťovou haldu zkompaktní (po uvolněných
objektech totiž zůstalo nežádoucí prázdné místo uvnitř haldy). (Wikimedia Foundation, 2010)
5.7
KNIHOVNY
Posunem od Win32 vzniklo .NET API. Tvoří jej sada základních knihoven Base Class Library (BCL),
které obsahují např. třídy pro práci s kolekcemi, vstupy a výstupy, síťováním apod. Zároveň
představují základ pro další nadstavby. Mezi ty patří knihovny pro práci s daty (ADO.NET), zpracování
XML dokumentů nebo formuláře (Windows Forms).
Od verze 3.0 jsou součástí také: [MCorp, 2010]

Windows Presentation Foundation (WPF) pro vývoj uživatelského rozhraní,

Windows Communication Foundation (WCF) coby unifikovaný komunikační model mezi
programovacími rozhraními,

Workflow
Foundation
(WF)
pro
komplexní
správu
vývoje
včetně
oddělení
aplikační prezentační vrstvy,

5.8
Windows CardSpace ke správě identit na webu.
UDÁLOSTI
Většina .NET aplikací je řízená událostmi (event-driven) – aplikace tráví čas čekáním na události,
které by mohla zpracovat. Může to být vykreslení okna ve Windows Forms nebo třeba načtení
stránky v ASP.NET. Na rozdíl od procedurálních aplikací je posloupnost kódu určována až za chodu.
*Šimeček, 2010+
5.9
NET COMPACT FRAMEWORK
Compact Framework je „prostředí nezávislé na hardware, které umožňuje běh řízených aplikací na
zařízeních s omezenými zdroji.“ [MCorp, 2010] Jedná se o podmnožinu rozhraní .NET Framework,
kde každá aplikace běží uvnitř vlastní aplikační domény a spouští vlastní instanci CLR. Framework
zajišťuje, že všechny využité zdroje se po ukončení aplikace uvolní.
Technologie je optimalizována tak, že v případě nedostatku paměti odstraňuje datové struktury
nepoužívané právě běžícím programem. Pokud ani to nestačí, čistě aplikaci ukončí a uvolní všechny
36
zdroje – nikdy by se tak nemělo stát, že Compact Framework spadne kvůli nedostatku paměti.
*Šimeček, 2010+
5.10 SHRNUTÍ
Hlavní silou technologie .NET je nezávislost na programovacím jazyce. Protože všechny řízené
programy jsou překládány pro CLR do IL, mohou být zdrojové kódy jedné aplikace tvořeny různými
jazyky – není problém zvolit pro konkrétní úlohu jazyk, který nejvíce vyhovuje. Díky Garbage
Collectoru také odpadají starosti o paměť. Destruktory sice existují, ale není třeba je volat přímo.
*Šimeček, 2010+ Architektura .NET tak programátorům dává do ruky mocný nástroj, jak rychle a
efektivně vytvářet plnohodnotné aplikace.
37
6
VISUAL STUDIO
První pokus společnosti Microsoft o vytvoření jednotného prostředí pro vývoj aplikací se objevil
v roce 1997, ale až v roce 2002 (spolu s uvedením technologie .NET) vyšlo Visual Studio .NET –
předek dnešního komplexního IDE.
Obrázek 6-1 - Úvodní obrazovka MS Visual Studio 2008
V současné době Visual Studio pokrývá a zjednodušuje celý proces vývoje softwaru od návrhu až po
nasazení. Obsahuje pokročilé nástroje pro testování, tvorbu prototypů, ladění, automatizaci apod.
[Microsoft, 2010]
6.1
PROJEKTY
Základem každého projektu ve Visual Studiu je soubor řešení (solution) s příponou SLN, který
obsahuje informace o projektech a další konfigurační volby. Jednotlivé projekty jsou pak soubory
XML s informacemi o sestavení, soubory se zdrojovým kódem a případné další zdroje (obrázky,
databáze…). Výstupem řešení může být jedna nebo několik aplikací (popřípadě knihoven).
38
Obrázek 6-2 - Solution Explorer
Z hlediska kompatibility platí, že projekt vytvořený ve starší verzi Visual Studia lze otevřít v novější,
ale nikoliv naopak. [Šimeček, 2010]
6.2
EDITACE
Prostředí poskytuje vše, co vývojář potřebuje pro tvorbu aplikací a je možné jej velmi rozsáhle
přizpůsobovat.
Ve vizuálním editoru lze mimo jiné tvořit aplikace Windows Forms, WPF, Silverlight, ASP.NET, vlastní
ovládací prvky a další… Je k dispozici panel s komponentami, z něhož lze přetahovat prvky, z kterých
se aplikace sestavuje. Visual Studio automaticky na pozadí generuje patřičný kód.
V editoru kódu se upravují soubory se zdrojovým kódem všech možných typů. Obarvování syntaxe
a napovídání názvů funguje inteligentně v závislosti na právě otevřeném kódu – C#, Visual Basic .NET
nebo třeba soubory XML mají svá specifická klíčová slova a elementy. Kromě toho obsahuje Visual
Studio spoustu drobných vylepšení pro zápis programů, která vývojářům zjednodušují život.
[Šimeček, 2010]
39
Obrázek 6-3 - Editor kódu
6.3
NÁSTROJE
K odstraňování logických chyb, které se nedají odchytit při kompilaci, slouží integrovaný debugger.
Můžeme nastavit zastavení programu v konkrétním místě, krokovat jej, prohlížet aktuální obsah
paměti a paměťových registrů, měnit hodnoty proměnných, sledovat průběh volání atd.
Obrázek 6-4 - Vložený breakpoint v editoru kódu
V nejnovější verzi (2010) byla značně zjednodušena instalace rozšíření vytvořených třetími stranami.
Visual Studio obsahuje nástroj Extension Manager, který se připojuje na online galerii rozšíření
a umožňuje z ní doplňky přímo stahovat. Všechny pluginy musí projít schválením společnosti
Microsoft, než se v repositáři objeví. [Šimeček, 2010]
40
6.4
NÁPOVĚDA A DOKUMENTACE
Spolu s celým prostředím je možné nainstalovat knihovnu MSDN. Zkratka MSDN znamená Microsoft
Developer Network a neoznačuje tedy jenom knihovny nápovědy pro Visual Studio, ale také snahu
společnosti Microsoft vycházet vstříc programátorům a testerům při řešení potíží či sebevzdělávání.
[Wikipedia, 2010]
Obrázek 6-5 - Nápověda MSDN
41
6.5
VISUAL STUDIO EXPRESS
Visual Studio Express je zvláštní edice vývojářského IDE, která je na rozdíl od Visual Studia k dispozici
zdarma. Jednotlivými produkty jsou Visual Basic Express, Visual C# Express, Visual C++ Express, Visual
Web Developer Express a SQL Server Express.
42
Oproti plnému Visual Studiu chybí následující součásti: [MCorp, 2010]

oficiální dokumentace na MSDN,

podpora rozšiřitelnosti (add-inů, maker, průvodců…),

nástroj Dotfuscator pro ztížení dekompilace kódu,

nástroj Spy++ pro sledování procesů, oken, vláken a zpráv systému,

integrace Team Exploreru pro použití s Team Serverem,

nástroj Class Designer,

pokročilý refaktoring,

pokročilé nástroje pro ladění,

podpora vývoje pro mobilní zařízení (Windows Mobile),

nástroj Server Explorer,

vývoj pro Office,

nástroje pro testování jednotek.
Obrázek 6-6 - Visual C# 2010 Express
43
6.6
VISUAL WEB DEVELOPER
Tento produkt je obdobou projektu typu webové aplikace ASP.NET, který obsahuje Visual Studio.
Slouží tedy k tvorbě aplikací ASP.NET a umožňuje stránky vytvářet jak pomocí vizuálního návrháře,
tak psaním směsi HTML a ASP.NET kódu. Zároveň se dají editovat soubory s kódem na pozadí (v
jazycích Visual Basic nebo C#).
Základem je vývoj pro ASP.NET 3.5, ale nechybí možnost aplikaci zacílit na konkrétní nižší verzi.
Součástí nástroje je také integrovaný webový server, na kterém se dá právě tvořená aplikace přímo
testovat bez nutnosti mít aktivní IIS (nebo jiný plnohodnotný webový server). [Šimeček, 2010]
Obrázek 6-7 - Visual Web Developer 2010 Express
6.7
SHRNUTÍ
Visual Studio je univerzální nástroj, který pokryje kompletní vývoj softwarového produktu. Prostředí
je vybaveno spoustou detailů, které nenápadně zpříjemňují práci. Při práci s jinými IDE pak člověk
tyto drobné funkčnosti velice rychle začne postrádat.
44
Samozřejmě je vhodnější pro specifické úkoly, jako například návrh rozhraní v jazyce XAML, použít
nástroje pro ně určené. Nad rozhraním .NET Framework ovšem mnoho takových úkolů neexistuje.
[Šimeček, 2010]
7
VISUAL STUDIO A VAZBA NA CASE NÁSTROJE
V současnosti je již v podstatě nezbytností každého vývojového prostředí, aby podporoval integraci
s modelovacími nástroji. Nejinak je tomu v případě Visual Studia, které poskytuje možnost integrace
s většinou běžně používaných CASE nástrojů na trhu. To umožňuje analytikům a vývojářům
zefektivnit celý proces návrhu informačního systému a zajistit konzistenci návrhu a výsledného
řešení.
Kvalitní nástroje CASE dnes nabízí kompletní funkcionalitu k podpoře tohoto procesu. Její analýzou
se již zabývalo mnoho prací na toto téma, a proto nemá smysl zde vše uvádět znovu. Pro přehlednost
uveďme alespoň výčet jednotlivých funkcí:
7.1

tvorba konceptuálního a fyzického datového modelu

objektové modelování

procesní modelování

kontrolní mechanismy

porovnávání modelů

generování výsledného zdrojového kódu

podpora spolupráce při vývoji

automatická tvorba dokumentace

reengineering

podpora návrhu vícerozměrných schémat

vytváření datových slovníků

podpora životního cyklu návrhu

správa požadavků
MOŽNOSTI INTEGRACE VISUAL STUDIA A CASE NÁSTROJŮ
Visual Studio, jakožto hlavní IDE pro platformu .NET samozřejmě podporuje možnost integrace
s drtivou většinou běžně dostupných CASE nástrojů. Existuje několik možností, jak integraci provést.
45
První z nich je nainstalování rozšiřujícího modulu přímo do Visual Studia. Tento model integrace je
využíván hlavně v případě robustních nástrojů. Uživatel pak může vytvářet vybrané modely přímo
v rámci Studia a tyto modely jsou pak automaticky synchronizovány s navrhovaným kódem
a podobně. Využití této možnosti ilustrují následující obrázky ukazující propojení Visual Studia a
Power Designeru:
Obrázek 7-1 - Vytvoření modelu k již existujícímu projektu. Zdroj: *Sybase, 2010+
46
Obrázek 7-2 - Vytvoření nového PD modelu přímo v prostředí MS Visual Studia. Zdroj: [Sybase, 2010]
Další možností je vytvoření modelů přímo v CASE nástroji a jejich následné manuální nahrání do IDE.
Hlavní problém této varianty, časté především u méně komplexních nástrojů, je nutná manuální
synchronizace a problematická a často nemožná zpětná úprava modelů podle již existujícího kódu
(reengeneering).
7.2
VISUAL STUDIO A UML
Pro vývojáře a analytiky, kterým pro potřeby analýzy a návrhu informačního systému stačí pouze
základní modely zahrnuté v rámci notace UML, nabízí Visual Studio od verze 2010 ještě jednu
možnost, a sice přímou podporu zmíněných modelů. Vývojáři a analytici tak mají možnost vytvářet
UML modely přímo v prostředí Visual Studia. Bohužel se nejedná o plnou podporu specifikace UML
2.0, která jak známo definuje 13 diagramů. Aktuální verze Visual Studia podporuje následujících pět:

Activity diagram

Component diagram

Class diagram

Sequence diagram

Use case diagram
V novém Visual Studiu bude možné generovat jak diagramy z existujícího kódu (reverse engineering),
tak kód z diagramů (Code Generation). Nejedná se však o takzvaný Round-trip engineering, který
spočívá v tom, že kód a příslušné diagramy jsou konzistentní. Čili změny v jednom se neustále
47
promítají do druhého. Toto nebylo záměrem Microsoft vývojářů a Reverse Engineering i Code
Generation jsou spíše jednorázovou záležitostí. *Šťastný, 2010]
Z výše zmíněného je jasné, že podporou těchto diagramů nemůže Visual Studio konkurovat
komplexním CASE nástrojům. To však zjevně ani nebyl cíl, jde spíše o zjednodušení práce vývojářů,
kterým dané modely mohou ušetřit práci následným automatickým generováním kódu. Stejně tak
tato funkcionalita pomůže vývojářům ve firmách, které se z nějakého důvodu rozhodnou
neinvestovat do pořízení CASE nástrojů.
Velmi užitečným se zajisté prokáže také „Architecture Explorer“, který umožňuje vizualizovat vztahy
mezi jednotlivými třídami / jmennými prostory / assemblies a efektivně tak pomáhá proniknout do
tajů cizího kódu a rychle se v něm zorientovat. *Šťastný, 2010]
Obrázek 7-3 - Tvorba Sequence diagramu přímo v prostředí Visual Studia. Zdroj: *Šťastný, 2010]
7.3
VISUAL STUDIO A VYBRANÉ CASE NÁSTROJE
Nyní se pojďme podrobněji podívat na vybrané CASE nástroje, jejich funkcionalitu a možnosti
integrace s Visual Studiem. Vzhledem k faktu, že Visual Studio je komerční produkt, zaměříme se
v naší analýze hlavně na komerční nástroje, open-source produkty nyní (ač možná trochu
48
neoprávněně) zůstanou v pozadí. Na trhu je v současnosti celá řada komerčních CASE nástrojů, pro
naši analýzu jsme vycházeli z produktů dostupných na českém trhu, které jsou integrovatelné s MS
Visual Studiem. Vycházeli jsme rovněž z prací našich kolegů s předchozích semestrů, kteří se zabývali
právě CASE nástroji dostupnými na českém trhu. Vzhledem k počtu takových produktů
a omezenému rozsahu této práce, zmíníme jen produkty splňující následující kritéria:

Dostupnost na českém trhu

Integrovatelnost MS Visual Studiem

Existence trial verze zdarma

Produkt je běžně používaný v kombinaci s Visual Studiem a rozšířený na českém trhu (v
tomto bodě jsme vycházeli z analýz z předchozích prací)
Dle zmíněných kritérií jsme do výběru zahrnuli následující produkty, které dle našeho názoru nejlépe
odpovídají výše zmíněným kritériím:

Microsoft Visio

SyBase(SAP) Power Designer

Oracle Designer

Enterprise Architect

Rational Software Modeler

IDS Sheer Aris Design Platform

Altova UModel
S ohledem na rozsah práce jsme se rozhodli zhodnotit možnosti integrace u třech produktů. Jedná se
o Microsoft Visio, SyBase(SAP) PowerDesigner a Altova Umodel. Všechny tři si teď podrobněji
představíme a zhodnotíme jejich možnosti integrace s Visual Studiem.
7.3.1 MICROSOFT VISIO
Základní informace o produktu
Aktuální verze:
Microsoft
Office
Visio
2010
(14.0.4760.1000) / 15 Červen 2010;
Výrobce:
Microsoft
Cena:
Standard edition: 249.99$
49
Professional edition: 559.99$
Premium edition: 999.99$
Systémové nároky:
OS Windows XP with Service Pack (SP) 3
(32-bit) a novější, CPU 500MHz, 256MB
RAM, 2GB místa na disku
Podporované platformy:
Microsoft Windows
Podporovaná verze UML:
2.0

Use case diagram

Sequence diagram

Collaboration diagram

State chart diagram

Activity diagram

Structure diagram
Další podporované diagramy:

Business process diagram
(využitelné při analýze a návrhu IS)

Data flow diagram

Workflow diagram

ERD
Podporované UML diagramy:
Možnost integrace s IDE:
MS Visual Studio
Týmový vývoj:
Ne (pouze s použitím MS SharePoint)
Visio je modelovací nástroj společnosti Microsoft, která produkt získala převzetím firmy Visio
Corporation v roce 2000 a od té doby pravidelně vydává nové verze zahrnuté do balíku MS Office.
Visio podporuje celou řadu typů modelů, od modelů použitelných pro návrh IS (viz tabulka), přes
technické modely až po modely podporující řízení podniku, např. Cause-effect diagram, Audit
diagram apod. Kromě možnosti integrace s MS Visual Studiem, o které ještě bude řeč, nabízí Visio
také možnost propojení s MS SQL Serverem, konkrétně s Analysis services, které se používají pro
analýzu dat v rámci business inteligence. Ve Visiu je tak možno vytvořit dynamické modely
vybraných dat, které jsou přímo napojeny a datové kostky uložené na serveru.
7.3.1.1 INTEGRACE MS VISIO A MS VISUAL STUDIO
Ke spolupráci obou produktů není potřeba instalace žádného pluginu, stačí mít nainstalované oba
produkty. Visio podporuje reverse engineering a visual studio na oplátku umí vytvořit kód z modelů
50
vytvořených ve Visiu. V případě zpětné tvorby modelů dle již vytvořeného kódu obsahuje Visual
Studio přímo v menu, pod záložkou Project možnost zpětné analýzy ve Visual Studiu. Obdobně, jen
v opačném směru, funguje tvorba kódu z vytvořených modelů z Visia.
Spolupráce obou programů je jednoduchá a velice přehledná. Na druhou stranu vzhledem k faktu, že
se jedná o produkty jedné společnosti, bychom očekávali vyšší míru provázání obou produktů (např.
automatické aktualizace modelů dle kódu a opačně, jednotné úložiště), tak aby Visio mohlo
konkurovat dalším předním CASE nástrojům na trhu. Možná by se měl Microsoft místo na přímou
podporu UML ve Visual Studiu zaměřit spíš na možnosti integrace s MS Visio a vytvořit tak efektivní
nástroj pro analytiky a vývojáře.
7.3.2 SYBASE(SAP) POWER DESIGNER
Základní informace o produktu
Aktuální verze:
PowerDesigner 15.2
Výrobce:
SyBase(SAP, společnost SyBase byla
v květnu letošního roku odkoupena a je
tak součástí společnosti SAP)
Cena:
3000$ - 7500$ (neoficiální čísla, výrobce
oficiální na svých stránkách neuvádí)
Systémové nároky:
CPU 1,5 GHz, 1 GB RAM, 500MB místa
na disku
Podporované platformy:
Microsoft Windows
Podporovaná verze UML:
2.0
Podporované UML diagramy:

všechny
Další podporované diagramy:

Business process diagram
(využitelné při analýze a návrhu IS)

Data flow diagram

Workflow diagram

ERD

Diagramy
pro
datové
modelování (na principu tří
architektur)

Mnoho dalších
51
Možnost integrace s IDE:
MS Visual Studio, Eclipse, PowerBuilder
Týmový vývoj:
Ano
PowerDesigner je jeden z nejkomplexnějších nástrojů, který je v současnosti na trhu dostupný. Po
dlouhé roky ho vyvíjela společnost Sybase, která byla v létě letošního roku převzata další významnou
firmou na trhu, a sice firmou SAP. PowerDesigner podporuje všechny diagramy v rámci notace UML
2.0, rovněž podporuje datové modelování a princip tří architektur s možností automatického
vygenerování SQL skriptu na vytvoření namodelované databáze v příslušném databázovém systému
(podporována je drtivá většina databázových systémů na trhu). Podporuje integraci s Visual Studiem,
Eclipse a PowerBuilderem, u všech zmíněných je podporován obousměrný engineering.
7.3.2.1 INTEGRACE POWERDESIGNER A MS VISUAL STUDIO
Jak již bylo zmíněno, PowerDesigner podporuje integraci s Visual Studiem prostřednictvím
přídavného modulu, po jehož nainstalování je možné vytvářet potřebné modely a automaticky je
synchronizovat s kódem. Podpora reengineeringu již také byla zmíněna, stejně jako možnost
týmového vývoje.
Pro analytiky a vývojáře je tak dle našeho názoru PowerDesigner jedním z nejlepších nástrojů, který
umožní zefektivnit celý proces návrhu informačního systému. Dané kvalitě ovšem odpovídá i cena
licencí, která se v případě vývojářské firmy může vyšplhat i přes stovky tisíc korun.
52
Obrázek 7- 4 - Model propojení PowerDesigneru a Visual Studio. Zdroj: [Sybase, 2010]
7.3.3 ALTOVA UMODEL
Základní informace o produktu
Aktuální verze:
UModel v2011
Výrobce:
Altova
Cena:
Systémové nároky:

Edice Professional – 119 Eur

Edice Enterprise – 199 Eur

(sleva při nákupu více licencí)
CPU 800 MHz, 64 MB RAM, 50 MB
místa na disku
Podporované platformy:
Microsoft Windows
Podporovaná verze UML:
2.0
Podporované UML diagramy:

všechny
Další podporované diagramy:

Business process diagram
(využitelné při analýze a návrhu IS)

Diagram pro modelování XML
53
schémat
Možnost integrace s IDE:
MS Visual Studio, Eclipse
Týmový vývoj:
Ano
UModel je produkt společnosti Altova, známou hlavně díky svému produktu XMLSpy. UModel je
vyvíjen od roku 1998, jedná se o komplexní produkt, který je svou cenou zajímavou alternativou k
ostatním produktům s podobně obsáhlou funkcionalitou, ovšem s řádově vyšší cenou. Produkt
rovněž podporuje všechny diagramy v rámci notace UML 2.0, podporuje automatickou tvorbu kódu
z diagramů, a to pro jazyky C#, Java a Visual Basic, z těchto jazyků rovněž podporuje reverse
engineering. Příjemně překvapí i automatická tvorba dokumentace.
7.3.3.1 INTEGRACE UMODEL A MS VISUAL STUDIO
Altova UModel podporuje možnost integrace jak s Visual Studiem, tak i s Eclipse. Postup integrace je
v podstatě totožný jako v případě PowerDesigneru, po nainstalování příslušného pluginu je možné
pracovat s diagramy z UModelu přímo v rozhraní Visual studia, což zjednoduší celý postup při návrhu
a tvorbě informačního systému. Celý proces integrace je velice jednoduchý, naistalování trvá jen pár
minut. Stejně tak vlastní práce v rámci Visual Studia je pak intuitivní. Jak vypadá rozhraní po
integraci, pak ukazuje následující obrázek.
54
Obrázek 7- 5 - Rozhraní Visual Studia s integrovaným pluginem UModel. Zdroj: [Altova, 2010]
7.4
SHRNUTÍ
Visual Studio je v dnešní době suverénně nejpoužívanější IDE pro vývoj aplikací na platformě .NET.
Proto je samozřejmostí, že nabízí celou řadu možností integrace s CASE nástroji. Pokud bychom měli
hodnotit tři námi analyzované nástroje, budeme těžko hledat nějakého „vítěze“. Dle našeho názoru
je každý produkt určen pro jinou cílovou skupinu. Integrace s Visual Studiem byla ve všech případech
bezproblémová, rozdíly ovšem určitě najdeme ve funkcionalitě. Ve funkcionalitě v oblasti analýzy a
návrhu IS přeci jen Visio lehce zaostává, ať už tím, že nepodporuje veškeré diagramy v rámci UML,
nebo i forma integrace nám připadá nejméně efektivní pro spolupráci analytiků a vývojářů.
Visio tyto nedostatky řeší přítomností diagramů pro modelování i jiných oblastí, než jen návrh IS, což
je asi i hlavní důvod, proč si ho zákazníci kupují. Z čistě technického pohledu na možnosti integrace
s Visual Studiem a vůbec podpoře celého procesu analýzy, návrhu a vývoje informačního systému
pak musíme lehce vyzdvihnout PowerDesigner a Umodel.
55
8
ZÁVĚR
Cílem této práce bylo ukázat jak jsou u Javy a .NETu vývojová prostředí provázána s CASE nástroji.
Práce není vyčerpávající přehled CASE nástrojů, což by vzhledem k rozsahu ani nebylo možné. Zato
však dobře doplňuje předchozí práce a například CASE nástroje popsané v kapitole o Javě se objevují
v pracích k tomuto předmětu poprvé.
V úvodní kapitole bylo vysvětleno, že spolupráce CASE nástrojů a prostředí pro vývoj aplikací je
poměrně důležitá. Předchozí kapitoly této práce dokazují, že tvůrci softwaru o této skutečnosti
dobře vědí a snaží se, aby CASE a IDE byly dobře integrované. Je sympatické, že lze často integrovat i
IDE s CASE nástrojem od jiné společnosti, jak dokazuje třeba příklad MS Visual Studia a Power
Designeru. Samozřejmě pokud je CASE i IDE od jedné společnost,i je to jednodušší a v takovém
případě často není ani třeba instalace pluginu.
V úvodu bylo také zmíněno, že ačkoli podpora modelování a tvorby UML diagramů je většinou hlavní
funkcionalita CASE nástrojů, vývoj aplikací může být podpořen jinými způsoby. Jak je možné toho
dosáhnout, je vidět v kapitole týkající se Javy v části RRC a RTC. Tyto nástroje dobře reagují na
potřebu komunikace, která byla v úvodu zmíněna, a poskytují velmi účinné prostředky, jak ji učinit
ještě efektivnější.
56
9
ZDROJE
[Build,2010]
Jazz.net community web site. Build v RTC [Online] 2008. [Citace 22. listopad
2010]. Dostupné z
http://jazz.net/projects/rational-team-concert/features/build
[BUCHALCEVO
Buchalcevová Alena, Pavlíček Luboš, Pavlíčková Jarmila. 2007. Základy
VÁ,2007]
softwarového inženýrství: materiály ke cvičení Praha: Nakladatelství Oeconomica,
2007. ISBN: 978-80-245-1270-9.
[BUCHALCEVO
Buchalcevová, Alena. 2009. Metodiky budování informačních systémů. Praha:
VÁ,2009+
Nakladatelství Oeconomica, 2009. ISBN: 978-80-245-1540-3.
[BUS, 2010]
Modernanalytyst.com, článek Business Analyst Articles: Business Analysis &
Systems
Analysis,
[Online]
[Citace
2.
prosinec
2010]
Dostupné
z
http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/Article
View/articleId/353/Enterprise-Architect-for-Business-Analysts.aspx
[COHN, 2004]
Cohn, Mike. 2004. User stories applied: for agile software development.
Addison-Wesley, 2005. ISBN 9780321205681
[FOWLER, 2009] Fowler,
Martin.
2009.
Destilované
UML.
Grada
Publishing
a.s.
ISBN:
9788024720623.
[Jazz, 2010].
Jazz.net community web site. Funkcionality RTC [Online] 2008. [Citace 22. listopad
2010+. Dostupné z
http://jazz.net/projects/rational-team-concert/features/
[LARMAN,
Larman, Craig. 2004. Agile and iterative development: a manager's guide. Addison-
2004]
Wesley, 2004. ISBN: 9780131111554.
[Pitka, 2007]
Pitka, Lukáš. 2007. Vývojové prostředí NetBeans. Bakalářská práce Zdroj VŠE, 2007
57
[PROCHAZKA,
Procházka, David. Hledáme na internetu v rekordním čase, aneb, Jak se nebát najít
2010
na netu rychle a dobře to, co skutečně hledáte. Grada Publishing a.s., 2007. ISBN
9788024714714
[RRC, 2010]
Jazz.net community web site. Rational Requirements Composer [Online] 2008.
[Citace 22. listopad 2010+. Dostupné z
http://jazz.net/projects/rational-requirements-composer/
[RTC, 2010]
IBM Rational team concert. Popis produktu RTC. [Online] 2008. [Citace 22. listopad
2010+. Dostupné z
http://www-142.ibm.com/software/products/cz/cs/rtc-express/
[RUP, 2010]
Electronics Research Administration, Rup Fundamentals Presentation . [Online]
[Citace
02.
prosinec2010+.
Dostupné
z
http://era.nih.gov/docs/rup_fundamentals.htm
[Team
Jazz.net community web site. Týmové povědomí v RTC *Online+ 2008. *Citace 22.
aware,2010]
listopad 2010+. Dostupné z
http://jazz.net/projects/rational-team-concert/features/team-aware
[VOŘÍŠEK,1997] Voříšek, Jiří. 1997 Strategické řízení informačního systému a systémová integrace,
Management Press, 1997. ISBN 80-85943-40-9
[WfMC, 1996]
Workflow management coalition. Workflow An Introduction Rob Allen [online]
1996. [Citace 29. listopad 2010+. Dostupné z http://www.wfmc.org/Downloaddocument/Workflow-An-Introduction-Rob-Allen.html
[Java, 2010]
Platforma Java. *Online+ 2010. *Citace 1. listopad 2010+ Dostupné
z
http://cs.wikipedia.org/w/index.php?title=Platforma_Java&oldid=5887495
[Eclipse, 2010]
Platforma Eclipse. *Online+ 2010. *Citace 1. listopad 2010+ Dostupné z
http://cs.wikipedia.org/w/index.php?title=Eclipse_(v%C3%BDvojov%C3%A9_prost
%C5%99ed%C3%AD)&oldid=6115817
[Microsoft,
Micosoft .NET Framework [Online] 2010. *Citace 15. listopad 2010+ Dostupné z
2010]
58
http://www.microsoft.com/net/
[Šimeček, 2010] Šimeček Martin. 2010. Technologie společnosti Microsoft pro vývoj softwarových
aplikací. Bakalářská práce Zdroj VŠCHT
[MCorp, 2010]
Visual Studio 2008 Product Comparison [Online] 2010. [Citace 15. listopad 2010]
Dostupné
z
http://www.microsoft.com/downloads/details.aspx?FamilyID=727BCFB0-B57547AB-9FD8-4EE067BB3A37&displaylang=en
[Šťastný, 2010]
Šťastný Ondřej – blog [Online] 2010. [Citace 15. listopad 2010] dostupné z
http://www.ondrejstastny.cz/Blog/Post/Visual-Studio-2010
[Sybase, 2010]
Sybase infocenter [Online] 2010. [Citace 15. listopad 2010] dostupné z
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc3809
3.1520/doc/html/rad1232025253934.html
[Altova, 2010]
Altova Umodel integration [Online] 2010 [Citace 15. listopad 2010] dostupné z
http://www.altova.com/umodel/uml-with-visual-studio.html
[Visio, 2010]
Visio UML modely [Online] 2010 [Citace 15. listopad 2010] dostupné z
http://office.microsoft.com/cs-cz/visio-help/CH001026669.aspx
[Wikipedia,
2010]
.NET Framework [Online] 2010 [Citace 15. listopad 2010] dostupné z
http://en.wikipedia.org/wiki/.NET_Framework
59