Seznámení se s architekturou systémů pomocí prostředí Visual Studio 2010

Většina projektů vychází z již existujícího zdrojového kódu, ať už se jedná o projekt rozšíření existující aplikace nebo o projekt přepsání či modernizace. V každém případě je velmi pravděpodobné, že dokumentace ke stávajícímu systému neexistuje, je zastaralá nebo jednoduše špatná. Nový tým již nemá šanci spolupracovat s lidmi, kteří systém napsali. Je odkázán na to, aby se vlastními silami pokusil systému porozumět, aniž by přitom měl jakýkoli výchozí bod. Takovýto bod nabízí Visual Studio 2010. Umožňuje, aby týmy začaly být produktivní již v mnohem kratší době, než to bylo dosud.

Na této stránce:


Visual Studio 2010 Ultimate zavádí nové architektonické nástroje, které pomáhají zvýšit návratnost investicí do vývoje systémů a výrazně snížit náklady na správu a aktualizace stávajících systémů. Tyto nástroje jsou zaměřeny na vizualizaci aplikace a na pochopení toku dat. Díky tomu se značně snižují náklady a úsilí vynaložené na rozšíření týmu o nové členy a na seznámení se s aplikacemi. Tým, který používá tyto nástroje, se bude moci více soustředit na nové funkce a stráví méně času opravami existujících chyb. Vaše aplikace mohou nyní přinést další příjmy při nižších nákladech, protože je bude možné déle používat a snadněji udržovat.

Snížení nákladů na údržbu již existujících systémů

Údržba již existujících systémů je nákladná. Vynaloží se na ni více peněz a úsilí, než na vývoj nových systémů. V průběhu stárnutí systémů se tyto náklady zvyšují. Dokonce i náklady na údržbu nedávno uvedené aplikace mohou být vysoké, jestliže na systému pracují noví vývojáři, kteří se musí s aplikací seznámit. A to je právě to, o čem celá údržba je, o pochopení systému a rozpoznání potenciálního vlivu určité změny. Visual Studio 2010 redukuje náklady spojené s údržbou, protože redukuje čas, který je potřeba k pochopení systému.

Když děláte údržbu systému, zvýrazní se problémy, které systémy obvykle mívají. Mnoho problémů se týká dokumentace, která je často nedostatečná. V kódu chybí komentáře, existující komentáře jsou nesrozumitelné či nepřesné. Dokumentace systému je jen zřídkakdy aktualizována, takže původní technické návrhy většinou neodpovídají konečnému produktu. A aktualizace dokumentace není součástí údržby. Někdy bývá mnohem větším problémem “špagetový” kód, který se vine mnoha částmi systému a představuje pouze chaos. Všechny tyto problémy způsobují, že vývojáři stráví celé dny či týdny tím, že se snaží uvést dokumentaci do souladu s aplikací. Časově je to pro ně velmi náročná práce. Microsoft Visual Studio 2010 Ultimate nabízí dva nástroje pro redukování času, který tato činnost zabere. Jsou to Architecture Explorer a Sequence Diagram.

Architecture Explorer

Problém se změnami existujícího systému obvykle spočívá v tom, že dopředu nevíte, co změnou pokazíte. Potom už bývá příliš pozdě. Takováto situace je časově i finančně velmi náročná a může vyústit až do stavu, kdy je potřeba ihned po uvedení nové verze opravit mnoho chyb. Tento problém pomáhá řešit Architecture Explorer, který je součástí prostředí Visual Studio 2010 Ultimate. Architecture Explorer nabízí mnoho způsobů, jak snadno a rychle zjistit, jakým způsobem aplikace vypadá, a to na libovolných úrovních (metoda, třída, jmenný prostor, assembly nebo řešení). Nabízí rovněž náhled na vztahy. Tento náhled umožňuje zjistit, které prvky jsou svázány s prvkem, jenž měníte.

Architectural Explorer dovoluje, aby vývojář začal s malým náhledem. Tento náhled může postupně rozšiřovat, až dokud aplikaci zcela nepochopí. Vývojář má možnost pracovat také druhým způsobem a to tak, že se hluboce vnoří do oblastí aplikace, které jej zajímají. Toto mocné vizuální řešení sděluje v grafickém formátu také rizika a možné dopady. Proces je znázorněn na obrázcích 1 až 4.

Pohled na aplikaci na vyšší úrovni-z většího nadhledu

Obrázek 1: Pohled na aplikaci na vyšší úrovni-z většího nadhledu

Obrázek 1 znázorňuje nejvyšší úroveň náhledu na aplikaci předtím, než se vývojář vnoří do dynamické knihovny BlogEngine.Core.dll. V tomto případě se vývojář chce zaměřit na jmenný prostor BlogEngine.Core. Hlubším vnořením získá náhled, který je zobrazen na obrázku 2.

Rozbalený náhled jmenného prostoru BlogEngine.Core

Obrázek 2: Rozbalený náhled jmenného prostoru BlogEngine.Core

Nyní má vývojář k dispozici třídy, které tvoří jmenný prostor. Může se vnořit do těch tříd, které hodlá změnit, a potom může analyzovat potenciální vlivy změn. Dalším vnořením získá náhled, který je znázorněn na obrázku 3.

Metoda Comment a související třídy

Obrázek 3: Metoda Comment a související třídy

Nyní se může vývojář vnořit do struktury ještě hlouběji, anebo může změnit náhled na graf vztahů tak, jak je znázorněno na obrázku 4. Tento graf dovoluje vývojáři vygenerovat mřížku vztahů k libovolnému kódu, který byl zobrazen pomocí nástroje Architecture Explorer. Graf v podstatě zobrazuje, v jaké relaci jsou další třídy (případně metody, assembly nebo jmenné prostory) k ostatním třídám. Díky tomu vidí vývojář vztahy a také vlivy případných změn již předtím, než začne jednotlivé změny realizovat. Tato funkce napomáhá ke snížení rizikovosti změn a až dosud nebyla k dispozici.

Metody, které volají metodu Comment, v náhledu na vztahy

Obrázek 4: Metody, které volají metodu Comment, v náhledu na vztahy

Sequence Diagram

Když vývojář zjistí, kde je potřeba udělat změnu, musí porozumět posloupnosti volání dané metody. Jen tak může provést příslušné změny. Před uvedením prostředí Visual Studio 2010 bylo potřeba, aby vývojář nejdříve nastavil body přerušení a spustil kód. Teprve potom mohl kód krokovat. Toto nejenom že zabralo určitý čas, ale v některých případech to bylo i náročné. Sekvenční diagram umožňuje vývojářům, aby kliknutím pravým tlačítkem na metodu vygenerovali úplný sekvenční diagram všech tříd, se kterými daná metoda interaguje. Příklad je zachycen na obrázku 5.

Vygenerovaný sekvenční diagram k objektu RewritePage (částečný)

Obrázek 5: Vygenerovaný sekvenční diagram k objektu RewritePage (částečný)

Modelování pomocí UML

Viděli jste, jakým způsobem se může vývojář vnořit do existující aplikace a seznámit se s ní, aniž by měl k dispozici dokumentaci nebo komentáře. Přitom mu to zabere mnohem méně času než dosud. Nové architektonické nástroje v první řadě minimalizují vlivy související s chybějící dokumentací. Obvykle je dokumentace oddělena od implementace a je náročné je vzájemně provázat. Z tohoto důvodu velmi často nejsou v souladu, což vede to k situaci, která je běžná pro mnoho dlouhodobě zděděných systémů (legacy). Visual Studio 2010 a Team Foundation Server 2010 společně odstraňují tento problém. Nabízí možnost přímého návrhu, kdy lze návrh přímo svázat s tvorbou dokumentace a vizuálně přejít z návrhu do dokumentace a z dokumentace do kódu. Takovýto rozsah možností dohledání zajišťuje, že investice do dokumentace nebude promarněna, ale v průběhu údržby se zúročí. Tím se sníží celkové náklady spojené s vlastnictvím systému a zvýší se její návratnost.

Visual Studio 2010 zavádí modelování kompatibilní s metodologií UML 2.1 s několika funkcemi navíc. Tyto funkce existují pouze díky tomu, že byly začleněny do prostředí Visual Studio. Výchozím bodem mnoha aplikací jsou diagramy případů užití (use case). Poskytují vizuálního průvodce pro uživatele a pro jejich interakci se systémem a s funkcemi, které bude systém vykonávat. Jedním z přínosů, které získávají modely UML díky úzké integraci se serverem Team Foundation Server, je možnost přímého připojení k pracovním položkám a generování pracovní položky z artefaktu v modelu. Toto mění modely na aktivní zdroje, které nezabírají zbytečně místo na polici, ale přináší užitek.

Obrázek 6 znázorňuje diagram případů užití s případem Add Post, který je kvůli zobrazení související pracovní položky zakroužkován. Toto umožňuje vývojářům, aby z grafického rozhraní zobrazili detailní požadavky, které budou při programování realizovat. V podstatě se mohou plynule pohybovat od požadavků ke kódu a zpět. Toto hraje důležitou roli rovněž při údržbě systému. Vývojář se totiž může podívat na kód a zjistit nejenom to, proč byl kód do systému přidán, ale také to, jaké jsou vztahy tohoto kódu k jiným funkcím systému z pohledu uživatele.

Diagram případů užití se souvisejícími pracovními položkami

Obrázek 6: Diagram případů užití se souvisejícími pracovními položkami

Propojení je možné přidat rovněž k jiným diagramům návrhu, jako je například diagram komponent zobrazený na obrázku 7.

Připojení případů užití k požadavkům a návrhům

Obrázek 7: Připojení případů užití k požadavkům a návrhům

Tímto způsobem se diagramy návrhu snadno připojí k požadavkům a ke kódu, který je implementuje. Získáte tak integrované řešení, které dovoluje snadno se pohybovat mezi modely návrhu a dokumenty. Díky tomu je vše umístěno centrálně v serveru. Není potřeba vytvářet sdílené soubory v síti, které zastarávají, nebo mít starosti s dohledáním modelů či dokumentů, které je potřeba aktualizovat. Navíc je možné k modelu připojit nejenom jiný model, ale také jiné libovolné dokumenty spojené s návrhem. Stačí pouze přidat propojení k těmto dokumentům, ať už jsou na webu, nebo ve formě sdíleného souboru. Takto jsou všechny potřebné součásti k dispozici v tom kontextu, ve kterém byly vytvořeny. Zkrátí se čas, který je potřeba k seznámení se s aplikací, a členové týmu začnou v průběhu vývoje nebo údržby produkovat dříve. Snižuje se rovněž pravděpodobnost výskytu zavlečených chyb.

Začněte se seznamovat se svým systémem hned dnes

Visual Studio 2010 nabízí týmům a organizacím možnost ihned zvýšit návratnost investicí do existujících systémů, protože dovoluje do velké míry zredukovat čas potřebný k seznámení se se systémem. Díky architektonickým nástrojům se mohou vývojáři více věnovat psaní kódu a stráví méně času pokusy o odhadnutí vlivu jednotlivých změn. Týmy, které pracují na zděděném kódu, snadno a rychle porozumí dané aplikaci i jejímu kontextu. Velká většina času, kterou je potřeba věnovat zaučení nových členů nebo práci na existujících aplikacích .NET, představuje seznamování se s aplikací na technické úrovni. Díky novým nástrojům se rozsah tohoto problému výrazně zmenší a produktivita vývojářů značně stoupne.