Scénář: Změna návrhu pomocí vizualizace a modelování
Pomocí nástrojů pro vizualizaci a modelování v sadě Visual Studio se ujistěte, že váš softwarový systém splňuje potřeby uživatelů. Pomocí nástrojů, jako jsou mapy kódu, diagramy závislostí a diagramy tříd, můžete:
Informace o tom, které verze sady Visual Studio podporují jednotlivé nástroje, najdete v tématu Podpora verzí pro nástroje pro architekturu a modelování.
Objasnění požadavků uživatelů a obchodních procesů
Vizualizujte a prozkoumejte existující kód.
Popište změny existujícího systému.
Ověřte, že systém splňuje své požadavky.
Udržujte kód konzistentní s návrhem.
Tento návod:
Popisuje, jak můžou tyto nástroje těžit z vašeho softwarového projektu.
Ukazuje, jak můžete tyto nástroje používat bez ohledu na vývojový přístup s ukázkovým scénářem.
Další informace o těchto nástrojích a scénářích, které podporují, najdete tady:
Přehled scénáře
Tento scénář popisuje epizody z životního cyklu vývoje softwaru dvou fiktivních společností: Dinner Now a Lucerne Publishing. Večeře nyní poskytuje službu doručování jídla na webu v Seattlu. Zákazníci si mohou objednat jídlo a platit za ně na webu Dinner Now. Objednávky se pak posílají do příslušné místní restaurace pro dodání. Lucern Publishing, společnost v New Yorku, provozuje několik firem mimo i na webu. Například spustí web, kde zákazníci můžou publikovat recenze restaurace.
Lucern nedávno získal večeři nyní a chce provést následující změny:
Integrujte své weby přidáním možností kontroly restaurace do aplikace Dinner Now.
Nahradit večeře nyní platební systém lucernský systém.
Rozbalte službu Dinner Now v celé oblasti.
Večeře teď používá SCRUM a eXtreme Programming. Mají velmi vysoké pokrytí testů a velmi málo nepodporovaný kód. Minimalizují rizika vytvořením malých, ale funkčních verzí systému a následným přírůstkovým přidáním funkcí. Svůj kód vyvíjejí v krátkých a častých iteracích. Díky tomu obejdou změny s jistotou, často refaktorují kód a vyhýbají se "velkému návrhu předem".
Lucern udržuje rozsáhlou a složitou kolekci systémů, z nichž některé jsou starší než 40 let. Jsou velmi opatrní při provádění změn kvůli složitosti a rozsahu staršího kódu. Sledují přísnější proces vývoje, dávají přednost návrhu podrobných řešení a dokumentují návrh a změny, ke kterým dochází během vývoje.
Oba týmy používají diagramy modelování v sadě Visual Studio, aby jim pomohly vyvíjet systémy, které splňují potřeby uživatelů. Používají Team Foundation Server spolu s dalšími nástroji, které jim pomůžou plánovat, organizovat a spravovat svou práci.
Další informace o Team Foundation Serveru najdete tady:
Role diagramů architektury a modelování ve vývoji softwaru
Následující tabulka popisuje role, které tyto nástroje mohou hrát během několika a různých fází životního cyklu vývoje softwaru:
| Nástroj nebo role | Modelování uživatelských požadavků | Modelování obchodních procesů | Systémová architektura a návrh | Vizualizace kódu a zkoumání | Ověření |
|---|---|---|---|---|---|
| Diagram jazyka specifického pro doménu (DSL) | Ano | Ano | Yes | ||
| Diagram závislostí, ověřování vrstev | Ano | Ano | Yes | ||
| Mapa kódu | Ano | Ano | Yes | ||
| Návrhář tříd (založený na kódu) | Ano |
Pokud chcete kreslit diagramy závislostí, musíte vytvořit projekt modelování jako součást existujícího řešení nebo nového projektu. Tyto diagramy musí být vytvořeny v projektu modelování. Položky v diagramech závislostí se nacházejí v projektu modelování, ale neukládají se do společného modelu. Mapy kódu a diagramy tříd .NET vytvořené z kódu existují mimo projekt modelování.
Přečtěte si:
Poznámka:
Komponenta Transformace textové šablony se automaticky nainstaluje jako součást sady funkcí vývoje rozšíření sady Visual Studio. Můžete ho také nainstalovat z karty Jednotlivé komponenty Instalační program pro Visual Studio v kategorii sad SDK, knihoven a architektur. Nainstalujte komponentu Modeling SDK z karty Jednotlivé komponenty .
Oba týmy také používají ověřování závislostí, aby zajistily, že kód ve vývoji zůstane konzistentní s návrhem. Přečtěte si:
Poznámka:
Některé verze sady Visual Studio podporují ověřování závislostí a mapy kódu jen pro čtení pro vizualizaci a modelování. Pokud chcete zjistit, které edice sady Visual Studio tuto funkci podporují, přečtěte si téma Podpora edice pro nástroje pro architekturu a modelování.
Vysvětlení a komunikace informací o systému
Pro použití diagramů modelování sady Visual Studio neexistuje žádné předepsané pořadí, takže je můžete použít podle svých potřeb nebo přístupu. Týmy se obvykle v rámci projektu iterativním a častou způsobem revidují své modely. Každý diagram nabízí konkrétní silné stránky, které vám pomůžou pochopit, popsat a komunikovat různé aspekty systému v rámci vývoje.
Večeře a Lucern spolu komunikují a s účastníky projektu pomocí diagramů jako jejich společného jazyka. Například Večeře teď používá diagramy k provádění těchto úkolů:
Vizualizujte existující kód.
Komunikujte s Lucernem o nových nebo aktualizovaných uživatelských příbězích.
Identifikujte změny, které jsou potřeba k podpoře nových nebo aktualizovaných uživatelských scénářů.
Lucern používá diagramy k provádění těchto úloh:
Seznamte se s obchodním procesem Dinner Now.
Seznamte se s návrhem systému.
Komunikujte se službou Dinner Now o nových nebo aktualizovaných požadavcích uživatelů.
Zdokumentujte aktualizace systému.
Diagramy jsou integrované se sadou Team Foundation Server, aby týmy mohly snadněji plánovat, spravovat a sledovat svou práci. Používají například modely k identifikaci testovacích případů a vývojových úloh a k odhadu své práce. Lucern propojuje pracovní položky Team Foundation Serveru s prvky modelu, aby mohly sledovat průběh a zajistit, aby systém splňoval požadavky uživatelů. Například propojí případy použití s pracovními položkami testovacího případu, aby viděli, že případy použití jsou splněny, když všechny testy projdou.
Než týmy zkontrolují změny, ověří kód proti testům a návrhu spuštěním sestavení, která zahrnují ověřování závislostí a automatizované testy. To pomáhá zajistit, aby aktualizovaný kód nebyl v konfliktu s návrhem a přerušil dříve funkční funkce.
Identifikace změn stávajícího systému
Večeře teď musí odhadnout náklady na splnění nového požadavku. To částečně závisí na tom, kolik této změny ovlivní ostatní části systému. Aby jim to pomohli pochopit, jeden z vývojářů Večeří teď vytvoří tyto mapy a diagramy z existujícího kódu:
| Mapování nebo diagram | Ukazuje |
|---|---|
| Mapa kódu Přečtěte si: - Mapování závislostí napříč vaším řešením - Procházení a změna uspořádání map kódu - Přizpůsobení map kódu úpravou souborů DGML |
Závislosti a další relace v kódu Například večeře Nyní může začít kontrolou map kódu sestavení pro přehled sestavení a jejich závislostí. Můžou přejít k mapám a prozkoumat obory názvů a třídy v těchto sestaveních. Večeře teď může také vytvořit mapy pro prozkoumání konkrétních oblastí a dalších druhů vztahů v kódu. Používají Průzkumník řešení k vyhledání a výběru oblastí a vztahů, které je zajímají. |
| Diagram tříd založený na kódu Viz Postupy: Přidání diagramů tříd do projektů (Návrhář tříd). |
Existující třídy v kódu |
Vývojář například vytvoří mapu kódu. Upraví její rozsah tak, aby se zaměřoval na oblasti, které budou ovlivněny novým scénářem. Na mapě jsou vybrané a zvýrazněné tyto oblasti:
Mapa kódu oboru názvů
Vývojář rozbalí vybrané obory názvů a zobrazí jejich třídy, metody a relace:
Rozbalené mapování kódu oboru názvů s viditelnými odkazy na křížové skupiny
Vývojář prozkoumá kód a vyhledá ovlivněné třídy a metody. Pokud chcete vidět efekty každé změny při jejich provádění, znovu vygenerujte mapy kódu po každé změně. Viz Vizualizujte kód.
Aby bylo možné popsat změny v jiných částech systému, jako jsou komponenty nebo interakce, může tým tyto prvky nakreslit na tabuli. Můžou také nakreslit následující diagramy v sadě Visual Studio, aby bylo možné zachytit, spravovat a pochopit podrobnosti obou týmů:
| Diagramy | Popisuje |
|---|---|
| Diagram tříd založený na kódu Viz Postupy: Přidání diagramů tříd do projektů (Návrhář tříd). |
Existující třídy v kódu. |
Zachování konzistentního kódu s návrhem
Večeře teď musí zajistit, aby aktualizovaný kód zůstal konzistentní s návrhem. Vytvářejí diagramy závislostí, které popisují vrstvy funkcí v systému, určují povolené závislosti mezi nimi a přidružují artefakty řešení k těmto vrstvám.
| Diagramu | Popisuje |
|---|---|
| Diagram závislostí Přečtěte si: - Vytváření diagramů závislostí z kódu - Diagramy závislostí: Referenční dokumentace - Diagramy závislostí: Pokyny - Ověřování kódu pomocí diagramů závislostí |
Logická architektura kódu. Diagram závislostí uspořádá a mapuje artefakty v řešení sady Visual Studio na abstraktní skupiny označované jako vrstvy. Tyto vrstvy identifikují role, úlohy nebo funkce, které tyto artefakty provádějí v systému. Diagramy závislostí jsou užitečné pro popis zamýšleného návrhu systému a ověřování vyvíjejícího se kódu v tomto návrhu. Vrstvy vytvoříte přetažením položek z Průzkumník řešení, map kódu, zobrazení tříd a prohlížeče objektů. Pokud chcete nakreslit nové vrstvy, použijte panel nástrojů nebo klikněte pravým tlačítkem myši na plochu diagramu. Chcete-li zobrazit existující závislosti, klepněte pravým tlačítkem myši na plochu diagramu závislostí a potom klepněte na příkaz Generovat závislosti. Chcete-li určit zamýšlené závislosti, nakreslete nové závislosti. |
Následující diagram závislostí například popisuje závislosti mezi vrstvami a počtem artefaktů přidružených k jednotlivým vrstvám:
Diagram závislostí
Aby se zajistilo, že během vývoje kódu nedojde ke konfliktům s návrhem, týmy používají ověřování závislostí na buildech, které běží v Azure DevOps. Vytvoří také vlastní úlohu MSBuild, která v rámci operací vrácení se změnami vyžaduje ověření závislostí. Sestavy sestavení používají ke shromažďování chyb ověření.
Přečtěte si:
Obecné Tipy pro vytváření a používání modelů
Většina diagramů se skládá z uzlů, které jsou propojené spojnicemi. Pro každý typ diagramu sada nástrojů poskytuje různé druhy uzlů a čar.
Panel nástrojů otevřete tak, že v nabídce Zobrazit kliknete na Panel nástrojů.
Pokud chcete vytvořit uzel, přetáhněte ho ze sady nástrojů do diagramu. Některé druhy uzlů musí být přetaženy na existující uzly. Například v diagramu komponent musí být do existující komponenty přidán nový port.
Chcete-li vytvořit řádek nebo připojení, klikněte na příslušný nástroj na panelu nástrojů, klikněte na zdrojový uzel a potom klikněte na cílový uzel. Některé řádky je možné vytvořit pouze mezi určitými druhy uzlů. Když ukazatel přesunete na možný zdroj nebo cíl, ukazatel označuje, jestli můžete vytvořit připojení.
Plánování a sledování práce
Diagramy modelování sady Visual Studio jsou integrované se sadou Team Foundation Server, abyste mohli snadněji plánovat, spravovat a sledovat práci. Oba týmy používají modely k identifikaci testovacích případů a vývojových úkolů a k odhadu své práce. Lucern vytváří a propojuje pracovní položky Team Foundation Serveru s prvky modelu, jako jsou případy použití nebo komponenty. To jim pomůže sledovat jejich průběh a sledovat jejich práci zpět na požadavky uživatelů. To jim pomůže zajistit, aby jejich změny i nadále splňovaly tyto požadavky.
V průběhu práce týmy aktualizují své pracovní položky tak, aby odrážely čas, který strávili na svých úkolech. Stav své práce také monitorují a hlásí pomocí následujících funkcí Team Foundation Serveru:
Denní vypálení sestav , které ukazují, jestli dokončí plánovanou práci v očekávaném čase. Vygenerují z Team Foundation Serveru další podobné sestavy ke sledování průběhu chyb.
Iterační list , který používá Microsoft Excel k tomu, aby týmu pomohl monitorovat a vyrovnávat zatížení mezi členy. Tento list je propojený se sadou Team Foundation Server a poskytuje fokus na diskuzi během pravidelných schůzek průběhu.
Vývojový řídicí panel , který používá Office Project k tomu, aby byl tým informován o důležitých informacích o projektu.
Přečtěte si:
Testování, ověření a vrácení kódu se změnami
Když týmy dokončí jednotlivé úkoly, zkontrolují kód do správy zdrojového kódu a dostanou připomenutí z Team Foundation Serveru, pokud zapomenou. Než Team Foundation Server přijme vrácení se změnami, týmy spouštějí testy jednotek a ověřování závislostí, aby ověřily kód proti testovacím případům a návrhu. Používají Team Foundation Server ke pravidelnému spouštění sestavení, automatizovaných testů jednotek a ověřování závislostí. To pomáhá zajistit, aby kód splňoval následující kritéria:
Funguje to.
Neporušuje dříve funkční kód.
Není v konfliktu s návrhem.
Večeře teď má velkou kolekci automatizovaných testů, které Lucern může opakovaně používat, protože téměř všechny stále platí. Lucern může také stavět na těchto testech a přidávat nové, aby pokrývala nové funkce. Obě sady Visual Studio také používají ke spouštění ručních testů.
Aby se zajistilo, že kód odpovídá návrhu, týmy nakonfigurují sestavení v Azure DevOps tak, aby zahrnovaly ověřování závislostí. Pokud dojde ke konfliktům, vygeneruje se sestava s podrobnostmi.
Přečtěte si:
Aktualizace systému pomocí vizualizace a modelování
Lucern a Dinner Now musí integrovat své platební systémy. Následující části znázorňují diagramy modelování v sadě Visual Studio, které jim pomůžou provádět tuto úlohu:
Přečtěte si:
Vizualizace existujícího kódu: Mapy kódu
Mapy kódu zobrazují aktuální organizaci a vztahy v kódu. Položky jsou reprezentovány uzly na mapě a relace jsou reprezentovány odkazy. Mapy kódu vám můžou pomoct s prováděním následujících typů úloh:
Prozkoumejte neznámý kód.
Zjistěte, kde a jak může navrhovaná změna ovlivnit stávající kód.
Najděte oblasti složitosti, přirozené závislosti nebo vzory nebo jiné oblasti, které můžou být přínosné z vylepšení.
Například večeře Nyní musí odhadnout náklady na aktualizaci komponenty PaymentProcessing. To částečně závisí na tom, kolik této změny ovlivní ostatní části systému. Aby to pochopili, jeden z vývojářů večeří teď generuje mapy kódu z kódu a upravuje rozsah zaměření na oblasti, které by mohly být touto změnou ovlivněny.
Následující mapa znázorňuje závislosti mezi třídou PaymentProcessing a dalšími částmi systému Dinner Now, které se zobrazují jako vybrané:
Mapa kódu pro platební systém Dinner Now
Vývojář prozkoumá mapu rozšířením třídy PaymentProcessing a výběrem jejích členů zobrazí oblasti, které mohou být ovlivněny:
Metody uvnitř třídy PaymentProcessing a jejich závislosti
Vygenerují následující mapu pro systém lucernské platby, která kontroluje jeho třídy, metody a závislosti. Tým vidí, že systém Lucern může také vyžadovat práci na interakci s ostatními částmi večeře nyní:
Mapa kódu pro Lucern platební systém
Oba týmy spolupracují na určení změn, které jsou potřeba k integraci těchto dvou systémů. Rozhodnou se refaktorovat některé kódy, aby bylo snazší ho aktualizovat. Třída PaymentApprover se přesune do oboru názvů DinnerNow.Business a bude vyžadovat některé nové metody. Třídy Dinner Now, které zpracovávají transakce, budou mít svůj vlastní obor názvů. Týmy vytvářejí a používají pracovní položky k plánování, uspořádání a sledování jejich práce. Propojí pracovní položky s prvky modelu, kde jsou užitečné.
Po opětovném uspořádání kódu týmy vygenerují novou mapu kódu, aby viděly aktualizovanou strukturu a vztahy:
Mapa kódu s přeuspořádaným kódem
Tato mapa ukazuje, že třída PaymentApprover je nyní v oboru názvů DinnerNow.Business a má některé nové metody. Třídy transakcí Dinner Now nyní mají svůj vlastní obor názvů PaymentSystem, který usnadňuje pozdější zpracování kódu.
Vytvoření mapy kódu
Pokud potřebujete rychlý přehled zdrojového kódu, vygenerujte mapování kódu pomocí následujícího postupu:
V nabídce Architektura klepněte na tlačítko Generovat mapování kódu pro řešení.
Rychlý přehled zkompilovaného kódu získáte tak, že vytvoříte prázdnou mapu kódu a přetáhnete soubory sestavení nebo binární soubory na plochu mapy.
Pokud chcete prozkoumat konkrétní kód nebo položky řešení, použijte Průzkumník řešení k výběru položek a relací, které chcete vizualizovat. Pak můžete buď vygenerovat novou mapu, nebo přidat vybrané položky do existující mapy. Viz závislosti mapování napříč vašimi řešeními.
Pokud chcete mapu prozkoumat, přeuspořádejte rozložení tak, aby vyhovovalo typům úkolů, které chcete provést.
Pokud chcete například vizualizovat vrstvení v kódu, vyberte rozložení stromu. Viz Procházení a změna uspořádání map kódu.
Shrnutí: Silné stránky Mapy kódu
Mapy kódu vám pomůžou:
Seznamte se s organizací a vztahy v existujícím kódu.
Identifikujte oblasti, které by mohly být ovlivněny navrhovanými změnami.
Najděte oblasti složitosti, vzorů, vrstev nebo jiných oblastí, které byste mohli vylepšit, aby byl kód snadněji udržovat, měnit a opakovaně používat.
Vztah k jiným diagramům
| Diagramu | Popisuje |
|---|---|
| Diagram závislostí | Logická architektura systému. Pomocí ověřování závislostí se ujistěte, že kód zůstane konzistentní s návrhem. Abyste mohli identifikovat existující závislosti nebo zamýšlené závislosti, vytvořte mapování kódu a seskupte související položky. Pokud chcete vytvořit diagram závislostí, přečtěte si téma: - Vytváření diagramů závislostí z kódu - Diagramy závislostí: Pokyny |
| Diagram tříd (založený na kódu) | Existující třídy v kódu pro konkrétní projekt. K vizualizaci a úpravě existující třídy v kódu použijte Návrhář tříd. Viz Postupy: Přidání diagramů tříd do projektů (Návrhář tříd). |
Definování glosáře typů: Diagramy tříd
Diagramy tříd definují entity, termíny nebo koncepty, které se účastní systému, a jejich vztahy mezi sebou. Pomocí těchto diagramů můžete například během vývoje popsat atributy a operace pro každou třídu bez ohledu na jazyk nebo styl jejich implementace.
Chcete-li pomoct Lucernu popsat a prodiskutovat entity, které se účastní případu použití platby procesu, nakreslí následující diagram tříd:
Zpracování entit plateb v diagramu tříd
Tento diagram ukazuje, že zákazník může mít mnoho objednávek a různé způsoby platby za objednávky. BankAccount i CreditCard dědí z platby.
Během vývoje používá Lucern následující diagram tříd k popisu a diskuzi o podrobnostech jednotlivých tříd:
Zpracování podrobností o platbě v diagramu tříd
Kreslení diagramu tříd
Diagram tříd má následující hlavní funkce:
Typy, jako jsou třídy, rozhraní a výčty:
Třída je definice objektů, které sdílejí specifické strukturální nebo behaviorální charakteristiky.
Rozhraní definuje část externě viditelného chování objektu.
Výčet je klasifikátor , který obsahuje seznam hodnot literálů.
Atributy jsou hodnoty určitého typu, které popisují každou instanci klasifikátoru. Klasifikátor je obecný název pro typy, komponenty, případy použití a dokonce aktéry.
Operace jsou metody nebo funkce, které mohou provádět instance klasifikátoru.
Asociace označuje určitý druh vztahu mezi dvěma klasifikátory.
Agregace je asociace, která označuje sdílené vlastnictví mezi klasifikátory.
Složení je asociace, která označuje vztah celé části mezi klasifikátory.
Pokud chcete zobrazit agregace nebo složení, nastavte vlastnost Agregace u přidružení. Sdílené zobrazuje agregace a složené prezentace složení.
Závislost označuje, že změna definice jednoho klasifikátoru může změnit definici jiného klasifikátoru.
Generalizace označuje, že konkrétní klasifikátor dědí část jeho definice z obecného klasifikátoru. Realizace označuje, že třída implementuje operace a atributy nabízené rozhraním.
K vytvoření těchto relací použijte nástroj Dědičnost . Alternativně může být realizace reprezentována jako lízátko.
Balíčky jsou skupiny klasifikátorů, přidružení, životnosti, komponent a dalších balíčků. Relace importu označují, že jeden balíček obsahuje všechny definice jiného balíčku.
Jako výchozí bod pro zkoumání a diskuzi o existujících třídách můžete pomocí Návrháře tříd vytvářet diagramy tříd z kódu.
Shrnutí: Silné stránky diagramů tříd
Diagramy tříd vám pomůžou definovat:
Běžný glosář termínů, které se mají použít při diskuzi o potřebách uživatelů a entitách, které se účastní systému. Viz Požadavky na uživatele modelu.
Typy používané částmi systému, jako jsou komponenty, bez ohledu na jejich implementaci. Viz Modelování architektury vaší aplikace.
Relace, jako jsou závislosti, mezi typy. Můžete například zobrazit, že jeden typ může být přidružen k více instancím jiného typu.
Vztah k jiným diagramům
| Diagramu | Popis |
|---|---|
| Diagram závislostí | Definujte logickou architekturu systému, protože souvisí s třídami. Pomocí ověřování závislostí se ujistěte, že kód zůstane konzistentní s návrhem. Přečtěte si: - Vytváření diagramů závislostí z kódu - Diagramy závislostí: Referenční dokumentace - Diagramy závislostí: Pokyny - Ověřování kódu pomocí diagramů závislostí |
| Mapa kódu | Vizualizujte organizaci a vztahy v existujícím kódu. Pokud chcete identifikovat třídy, jejich relace a jejich metody, vytvořte mapu kódu, která tyto prvky zobrazuje. Přečtěte si: - Mapování závislostí napříč vaším řešením |
Popis logické architektury: diagramy závislostí
Diagramy závislostí popisují logickou architekturu systému uspořádáním artefaktů v řešení do abstraktních skupin nebo vrstev. Artefakty můžou být mnoho věcí, jako jsou obory názvů, projekty, třídy, metody atd. Vrstvy představují a popisují role nebo úlohy, které artefakty provádějí v systému. Do operací sestavení a vrácení se změnami můžete také zahrnout ověřování vrstev, abyste měli jistotu, že kód zůstane konzistentní s jeho návrhem.
Pokud chcete zachovat konzistenci kódu s návrhem, dinner Now a Lucerne, použijte následující diagram závislostí k ověření kódu, jak se vyvíjí:
Diagram závislostí pro večeři nyní integrovaný s Lucernem
Vrstvy v tomto diagramu odkazují na odpovídající artefakty řešení Dinner Now a Lucerne. Například obchodní vrstva odkazuje na obor názvů DinnerNow.Business a její členy, které teď zahrnují třídu PaymentApprover. Vrstva Přístupu k prostředkům odkazuje na obor názvů DinnerNow.Data. Šipky nebo závislosti určují, že funkce ve vrstvě Přístupu k prostředkům může používat pouze obchodní vrstva. Když týmy aktualizují svůj kód, provádí se pravidelně ověřování vrstev, aby zachytily konflikty, když k nim dojde, a pomohly týmům rychle je vyřešit.
Týmy spolupracují na přírůstkové integraci a otestování těchto dvou systémů. Nejprve se ujistěte, že PaymentApprover a zbytek večeře nyní spolu úspěšně fungují předtím, než se budou zabývat PaymentProcessing.
Následující mapa kódu zobrazuje nová volání mezi večeří a PaymentApprover:
Mapování kódu s aktualizovanými voláními metod
Jakmile potvrdí, že systém funguje podle očekávání, večeře nyní okomentuje kód PaymentProcessing. Sestavy ověřování vrstev jsou čisté a výsledná mapa kódu ukazuje, že neexistují žádné další závislosti PaymentProcessing:
Mapa kódu bez paymentprocessingu
Kreslení diagramu závislostí
Diagram závislostí má následující hlavní funkce:
Vrstvy popisují logické skupiny artefaktů.
Propojení je přidružení mezi vrstvou a artefaktem.
Pokud chcete vytvářet vrstvy z artefaktů, přetáhněte položky z Průzkumník řešení, map kódu, zobrazení tříd nebo prohlížeče objektů. Pokud chcete nakreslit nové vrstvy a pak je propojit s artefakty, použijte panel nástrojů nebo klikněte pravým tlačítkem myši na plochu diagramu a vytvořte vrstvy a přetáhněte položky do těchto vrstev.
Číslo na vrstvě zobrazuje počet artefaktů, které jsou propojeny s vrstvou. Těmito artefakty mohou být obory názvů, projekty, třídy, metody atd. Při interpretaci počtu artefaktů ve vrstvě mějte na paměti následující:
Pokud vrstva odkazuje na artefakt, který obsahuje jiné artefakty, ale vrstva není propojena přímo s jiným artefaktem, pak číslo obsahuje pouze propojené artefakty. Jiné artefakty jsou však zahrnuty do analýzy během ověřování vrstvy.
Pokud je vrstva například spojena s jedním oborem názvů, pak počet propojených artefaktů je 1, přestože obor názvů obsahuje třídy. Pokud vrstva obsahuje rovněž propojení s jednotlivými třídami v oboru názvů, bude počet zahrnovat propojené třídy.
Pokud například vrstva obsahuje jiné vrstvy, které jsou spojeny s artefakty, pak je vrstva kontejneru také propojena s těmito artefakty, i když číslo vrstvy kontejneru tyto artefakty neobsahuje.
Pokud chcete zobrazit artefakty propojené s vrstvou, klikněte pravým tlačítkem myši na závislost a potom kliknutím na zobrazit odkazy otevřete Průzkumníka vrstev.
Závislost označuje, že jedna vrstva může používat funkce v jiné vrstvě, ale ne naopak. Obousměrná závislost označuje, že jedna vrstva může používat funkce v jiné vrstvě a naopak.
Pokud chcete zobrazit existující závislosti na diagramu závislostí, klikněte pravým tlačítkem myši na plochu diagramu a potom klikněte na Generovat závislosti. Chcete-li popsat zamýšlené závislosti, nakreslete nové závislosti.
Přečtěte si:
Shrnutí: Silné stránky diagramů závislostí
Diagramy závislostí vám pomůžou:
Popsat logickou architekturu systému podle funkčnosti jeho artefaktů.
Ujistěte se, že kód ve vývoji odpovídá zadanému návrhu.
Vztah k jiným diagramům
| Diagramu | Popis |
|---|---|
| Mapa kódu | Vizualizujte organizaci a vztahy v existujícím kódu. Pokud chcete vytvořit vrstvy, vygenerujte mapu kódu a potom položky na mapě seskupte jako potenciální vrstvy. Přetáhněte skupiny z mapy do diagramu závislostí. Přečtěte si: - Mapování závislostí napříč vaším řešením - Procházení a změna uspořádání map kódu |
Externí zdroje
| Kategorie | Odkazy |
|---|---|
| Fóra | - Visual Studio Visualization &Modeling Tools - Visual Studio Visualization & Modeling SDK (NÁSTROJE DSL) |