NÁSTROJE PRO VÝVOJ APLIKACÍ V ZÁVISLOSTI NA PLATFORMĚ A JEJICH VAZBA NA CASE

Transkript

1 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

2 xname Jméno a příjmení xpucv02 xtump13 xdrad07 xhano06 xsrnm03 Vladimír Pucholt Pavel Tůma Dušan Drábik Ondřej Hanák Srnský Martin 3

3 OBSAH 1 Úvod Cíl práce Charakter práce Přístup ke zpracování práce Definice základních pojmů IDE CASE Platforma Teoretická úvaha o spolupráci IDE a CASE Proč BY IDE a CASE vůbec měly spolupracovat? Tvorba modelu a jeho implementace Prostředek komunikace Jak by měla spolupráce fungovat? Nástroje pro vývoj aplikací v závislosti na platformě Java Netbeans Eclipse Rational Requirements Composer Rational Team Concert NET Framework Architektura.NET Framework Common Language Runtime (CLR) Řízený a neřízený kód Intermediate language (IL) Typový systém (CTS)

4 5.6 Automatická správa paměti Knihovny Události NET Compact Framework Shrnutí Visual Studio Projekty Editace Nástroje Nápověda a dokumentace Visual Studio Express Visual Web Developer Shrnutí Visual Studio a vazba na CASE nástroje Možnosti integrace Visual Studia a CASE nástrojů Visual Studio a UML Visual Studio a vybrané CASE nástroje Microsoft Visio SyBase(SAP) Power Designer Altova UModel Shrnutí Závěr Zdroje

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 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

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 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

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í 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

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

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é 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

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

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

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

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

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 a 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 a 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 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

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 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

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 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 Skupina Articles & News obsahuje aktuální informace týkající se NetBeans. Jsou zde odkazy na nejnovější články na Tato skupina vyžaduje přístup k Internetu, aby mohla načíst informace o článcích 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í Zatrhávací tlačítko Show on Startup pokud je zatržené, zobrazí se Welcome obrazovka při každém spuštění NetBeans 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

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 RATIONAL REQUIREMENTS COMPOSER 18

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

19 requirements composer obsahuje editory pro případy užití, návrhy uživatelského rozhraní a storyboardy 1, 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 4-4 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ů MODELOVÁNÍ V RRC 1 Storyboard je sekvence obrázků vytvořená za účelem previzualizace výsledného díla 20

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í em č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

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 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 Poslední verzí, která se objevila na trhu v polovině dubna 2010, je RTC

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

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 messagingu 2 : 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

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 workflow 3. Kromě pracovních položek jsou důležité další vazby mezi RTC artefakty 4 (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Á, Progress bar je prvek, který se používá ke znázornění průběhu déle trvající práce. 25

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

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

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

28 a další položky důležité pro porozumění vývoje projektu. Například ve formě grafu typu burndown 6, 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

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, ové 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

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

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

32 Obrázek 4-18: Záložka Work Item 33

33 5.NET FRAMEWORK 5.1 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, Obrázek Architektura.NET Framework Dvě velmi podstatné součásti jádra jsou CLR (neboli Common Language Runtime) a BCL (Base Class Library). *Šimeček,

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, 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, AUTOMATICKÁ SPRÁVA PAMĚTI 35

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, Windows CardSpace ke správě identit na webu. 5.8 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, 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

36 zdroje nikdy by se tak nemělo stát, že Compact Framework spadne kvůli nedostatku paměti. *Šimeček, 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, Architektura.NET tak programátorům dává do ruky mocný nástroj, jak rychle a efektivně vytvářet plnohodnotné aplikace. 37

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 Ú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

38 Obrázek 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

39 Obrázek 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 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

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 Nápověda MSDN 41

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

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 Visual C# 2010 Express 43

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 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

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í: 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ů 7.1 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

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 Vytvoření modelu k již existujícímu projektu. Zdroj: *Sybase,

46 Obrázek 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

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 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

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 MICROSOFT VISIO Základní informace o produktu Aktuální verze: Microsoft Office Visio 2010 ( ) / 15 Červen 2010; Výrobce: Microsoft Cena: Standard edition: $ 49

49 Professional edition: $ Premium edition: $ 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 Podporované UML diagramy: Use case diagram Další podporované diagramy: (využitelné při analýze a návrhu IS) Možnost integrace s IDE: Týmový vývoj: Sequence diagram Collaboration diagram State chart diagram Activity diagram Structure diagram Business process diagram Data flow diagram Workflow diagram ERD MS Visual Studio 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 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

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 SYBASE(SAP) POWER DESIGNER Základní informace o produktu Aktuální verze: PowerDesigner 15.2 Výrobce: Cena: Systémové nároky: Podporované platformy: SyBase(SAP, společnost SyBase byla v květnu letošního roku odkoupena a je tak součástí společnosti SAP) 3000$ $ (neoficiální čísla, výrobce oficiální na svých stránkách neuvádí) CPU 1,5 GHz, 1 GB RAM, 500MB místa na disku Microsoft Windows Podporovaná verze UML: 2.0 Podporované UML diagramy: všechny Další podporované diagramy: (využitelné při analýze a návrhu IS) Business process diagram Data flow diagram Workflow diagram ERD Diagramy pro datové modelování (na principu tří architektur) Mnoho dalších 51

51 Možnost integrace s IDE: Týmový vývoj: MS Visual Studio, Eclipse, PowerBuilder 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 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

52 Obrázek Model propojení PowerDesigneru a Visual Studio. Zdroj: [Sybase, 2010] ALTOVA UMODEL Základní informace o produktu Aktuální verze: Výrobce: UModel v2011 Altova Cena: Edice Professional 119 Eur Edice Enterprise 199 Eur (sleva při nákupu více licencí) Systémové nároky: 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: (využitelné při analýze a návrhu IS) Business process diagram Diagram pro modelování XML 53

53 schémat Možnost integrace s IDE: Týmový vývoj: MS Visual Studio, Eclipse 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 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

54 Obrázek 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