Sdílet prostřednictvím

Přehled scénáře: Změna návrhu pomocí vizualizace a modelování

  • Článek

Chcete-li zajistit, že softwarový systém vyhovuje potřebám svých uživatelů, použijte vizualizaci a nástroje modelování v Visual Studio Ultimate k aktualizaci nebo změně návrhu systému.Mezi tyto nástroje patří diagramy jazyka UML (Unified Modeling), diagramy s vrstvou, grafy závislosti založené na kódu, sekvenční diagramy a diagramy tříd.Například můžete použít tyto nástroje k provádění těchto úkolů:

  • Vyjasněte požadavky uživatelů a obchodních procesů.

  • Vizualizujte a zkoumejte existující kód.

  • Popište změny stávajícího systému.

  • Ověřte, že systém splňuje požadavky.

  • Udržujte kód v souladu s návrhem.

Tento návod používá příklad scénáře pro dosažení těchto cílů:

  • Poskytuje podrobný přehled nástrojů a jejich výhody pro softwarový projekt.

  • Zobrazení jako dva týmy může použít tyto nástroje ve scénáři příkladu, bez ohledu na jejich rozvoj přístupů.

Další informace o těchto nástrojích a scénářích, které podporují, naleznete v tématu:

V tomto tématu

Oddíl

Description

Přehled scénáře

Popisuje vzorový scénář a jeho účastníky.

Role architektury a modelování diagramů při vývoji softwaru

Popisuje role, které tyto nástroje mohou hrát během životního cyklu vývoje softwaru.

Pochopení a sdělování informací o systému

Obsahuje podrobný přehled, jak účastníci používají nástroje v tomto scénáři.

Aktualizace systému pomocí vizualizace a modelování

Poskytuje podrobnější informace o jednotlivých nástrojích a jejich způsobu použití v tomto scénáři.

Přehled scénáře

Tento scénář popisuje epizody z životního cyklu vývoje softwaru dvou fiktivních společností: Večeře nyní a Lucerne Publishing.Společnost Dinner Now poskytuje webovou službu pro doručování pokrmů v Seattlu.Zákazníci mohou objednat jídlo a zaplatit za ně na webu Dinner Now.Objednávky jsou potom odeslány příslušné místní restauraci pro dodání.Lucerne Publishing, společnost se sídlem v New Yorku, provozuje několik podniků na webu i mimo něj.Například využívají web, kde mohou zákazníci prezentovat své recenze na restauraci.

Společnost Lucerne nedávno odkoupila web Dinner Now a chce provést následující změny:

  • Integrace webových stránek přidáním funkce recenzování restaurací na web Dinner Now.

  • Nahraďte platební systém společnosti Dinner Now systémem společnosti Lucerne.

  • Rozbalte službu Dinner Now v rámci celé oblasti.

Společnost Dinner Now používá programování SCRUM a eXtreme.Mají velmi vysoké testovací pokrytí a velmi málo nepodporovaného kódu.Minimalizují riziko vytvářením malých, ale funkčních verzí systému a pak postupně přidávají funkce.Vyvíjejí svůj kód v krátkých a častých iteracích.Díky tomu mohou podpořit změnu s jistotou, často refaktorovat kód a vyhnout se "rovnou velkému návrhu".

Společnost Lucerne udržuje výrazně větší a složitější kolekci systémů, z nichž některé jsou více než 40 let staré.Jsou velmi opatrní při provádění změn z důvodu složitosti a rozsahu staršího kódu.Následují přísnější vývojový proces, preferují návrh podrobných řešení a dokumentaci návrhu a změn, které nastanou během vývoje.

Oba týmy používají diagramy modelování v aplikaci Visual Studio Ultimate k usnadnění vývoje systémů, které vyhovují potřebám uživatelů.Používají Team Foundation Server spolu s dalšími nástroji, které jim pomáhají plánovat, organizovat a spravovat jejich práci.

Další informace o Team Foundation Server naleznete v tématu:

  • Plánování a sledování práce

  • Testování, ověřování a vrácení kódu se změnami

Role architektury a modelování diagramů při vývoji softwaru

Následující tabulka popisuje role, které tyto nástroje mohou hrát při více a v různých fázích životního cyklu vývoje softwaru:

Modelování požadavků uživatelů

Modelování obchodních procesů

Architektura systému a návrh

Vizualizace & průzkum kódu

Ověření

Použijte diagram případu (UML)

√

√

√

Diagram činnosti (UML)

√

√

√

√

Diagram tříd (UML)

√

√

√

√

Diagram součásti (UML)

√

√

√

√

Sekvenční diagram (UML)

√

√

√

√

Diagram DSL (Domain-Specific Language)

√

√

√

Diagram vrstvy, ověřování vrstvy

√

√

√

Graf závislosti (založený na kódu)

√

√

√

Sekvenční diagram (založeno na kódu)

√

√

Návrhář tříd (založený na kódu)

√

Průzkumník architektury

√

Chcete-li nakreslit diagramy UML a diagramy vrstvy, musíte vytvořit projekt modelování jako součást existujícího nebo nového řešení.Tyto diagramy musí být vytvořeny v projektu modelování.Položky v diagramech UML jsou součástí společného modelu a diagramy UML jsou zobrazením tohoto modelu.Položky v diagramech vrstev se nacházejí v projektu modelování, ale nejsou uloženy ve společném modelu.Grafy závislosti založené na kódu, sekvenční diagramy a diagramy třídy obvykle existují mimo projekt modelování.

Viz:

Chcete-li zobrazit alternativním zobrazení architektury, můžete použít některé prvky ze stejného modelu na několika nebo různých diagramech.Například můžete přetáhnout komponentu do jiného diagramu komponent nebo do sekvenčního diagramu tak, aby ji bylo možné používat jako prvek „actor“.Viz téma Úpravy modelů a diagramů UML.

Oba týmy používají také vrstvu ověřování k ujištění, že kód ve vývoji zůstává konzistentní s návrhem.

Viz:

  • Udržování kódu v souladu s návrhem

  • Popište logickou architekturu: diagramy vrstvy

  • Ověřování kódu pomocí diagramů vrstev

    [!POZNÁMKA]

    Visual Studio Premium podporuje ověřování vrstev a verze jen pro čtení těchto grafů a diagramů pro vizualizaci a modelování.

Pochopení a sdělování informací o systému

Neexistuje žádné předepsané pořadí pro použití diagramů modelování Visual Studio Ultimate, takže je lze využít, jak se hodí vašim potřebám a přístupu.Obvykle týmy opravují své modely opakovaně a často v průběhu projektu.Každý diagram nabízí určité výhody, které na vám pomohou porozumět, popsat a sdělit různé aspekty vyvíjeného systému.

Společnosti Dinner Now a Lucerne komunikují vzájemně a se zúčastněnými stranami pro projekt pomocí diagramů, které slouží jako jejich společný jazyk.Společnost Dinner Now například používá diagramy pro provádění těchto úkolů:

  • Vizualizujte existující kód.

  • Komunikujte se společností Lucerne o nových nebo aktualizovaných uživatelských scénářích.

  • Určete změny, které jsou nutné pro podporu nového nebo aktualizovaného uživatelského scénáře.

Společnost Lucerne používá diagramy k provádění těchto úkolů:

  • Získejte informace o obchodním procesu webu Dinner Now.

  • Pochopte návrh systému.

  • Komunikujte se společností Dinner Now o nových nebo aktualizovaných uživatelských požadavcích.

  • Aktualizace dokumentu v systému.

Diagramy jsou integrovány se serverem Team Foundation Server, takže týmy plánují, řídí a sledují svou práci snadněji.Například mohou používat modely k identifikaci testových případů a vývojářských úloh a k odhadu hotové práce.Společnost Lucerne propojí pracovní položky sady Team Foundation Server s prvky modelů, aby mohly sledovat průběh a ujistěte se, že systém splňuje požadavky uživatelů.Například mohou propojit případy použití s pracovními položkami testového případu, aby bylo patrné, že jsou případy použití splněny, pokud budou všechny testy úspěšné.

Než týmy vrátí změny, ověří kód proti testům a návrhu spuštěním sestavení, která obsahují vrstvu ověřování a automatizované testy.To pomáhá se ujistit, že aktualizovaný kód není v rozporu s návrhem a nezruší dříve fungující funkce.

Viz:

  • Principy role systému v obchodním procesu

  • Popisuje nové nebo aktualizované uživatelské požadavky

  • Vytváření testů z modelů

  • Určení změn ve stávajícím systému

  • Udržování kódu v souladu s návrhem

  • Obecné tipy pro vytváření a použití modelů

  • Plánování a sledování práce

  • Testování, ověřování a vrácení kódu se změnami

Principy role systému v obchodním procesu

Společnost Lucerne se chce dozvědět více o obchodním procesu webu Dinner Now.Vytvářejí následující diagramy ke snazšímu vyjasnění svého pochopení systému Dinner Now:

Diagram

Popisuje

Použijte diagram případu (UML)

Viz:

  • Aktivity, které podporuje systém Dinner Now

  • Osoby a externí systémy, které provádějí činnosti

  • Hlavní součásti systému, které podporují jednotlivé aktivity

  • Části obchodního procesu, které jsou mimo rozsah aktuálního systému, například dodávky potravin

Diagram činnosti (UML)

Viz:

Kroky toku, které nastanou, když zákazník vytvoří objednávku

Diagram tříd (UML)

Viz:

Obchodní entity a termíny, které se používají v diskusi a vztazích mezi těmito entitami.Například Objednávka a Položka nabídky jsou součástí slovníku v tomto scénáři.

Společnost Lucerne například vytvoří následující diagram případu, který použije k porozumění úloh prováděných na webu Dinner Now a tomu, kdo je provádí:

Diagram případu použití UML

Diagram případu použití UML

Následující diagram činnosti popisuje průběh kroků, když zákazník vytvoří objednávku na webu Dinner Now.V tomto vydání prvky komentářů identifikují role a řádky vytvářejí plavecké dráhy, které organizují kroky podle rolí:

Diagram činností UML

Diagram činnosti UML

Následující diagram tříd popisuje entity, které se účastní procesu objednávání:

Diagram tříd UML

Diagram tříd UML

Popisuje nové nebo aktualizované uživatelské požadavky

Společnost Lucerne chce přidat funkce do systému Dinner Now, aby mohli zákazníci číst a přidávat recenze restaurací.Aktualizují následující diagramy, takže mohou popsat a diskutovat o tomto novém požadavku s aplikací Večeře nyní:

Diagram

Popisuje

Použijte diagram případu (UML)

Viz:

Nový případ použití pro "Napsat recenzi restaurace"

Diagram činnosti (UML)

Viz:

Kroky, které nastanou v případě, že zákazník chce napsat recenzi restaurace

Diagram tříd (UML)

Viz:

Data, která jsou třeba k uložení recenze

Například následující diagram případu použití zahrnuje nový případ použití „Napsat recenzi“ a zastupuje tak nový požadavek.V diagramu je pro snazší identifikaci zvýrazněn oranžově:

Diagram případu použití UML

Diagram případu použití UML

Následující diagram činností zahrnuje nové prvky zobrazené oranžově pro popis toku kroků postupu v novém případu použití:

Diagram činností UML

Diagram činnosti UML

Následující diagram tříd obsahuje novou třídu revize a její vztahy k jiným třídám, takže týmy mohou diskutovat o podrobnostech.Všimněte si, že zákazník a restaurace mohou mít více recenzí:

Diagram tříd UML

Diagram tříd UML

Vytváření testů z modelů

Oba týmy se dohodly, že potřebují úplnou sadu testů pro systému a jeho komponenty předtím, než provedou jakékoli změny.Společnost Lucerne má specializovaný tým, který provádí testování na úrovni systému a komponent.Znovu použijí testy vytvořené aplikací Večeře nyní a strukturují tyto testy pomocí UML diagramů:

  • Každý případ použití je reprezentován jedním nebo více testy.Prvky na odkazu diagramu použití případu pro testovací případ pracovních položek v serveru Team Foundation Server.

  • Každý tok v diagramu činnosti nebo sekvenčního diagramu na úrovni systému je propojen s přinejmenším jedním testem.Testovací tým systematicky zajišťuje testování všech možných cest pomocí diagramu činnosti.

  • Termíny používané k popisu testů jsou založeny na termínech definovaných diagramy případu, tříd a aktivit.

Jak se mění požadavky a diagramy se aktualizují, aby odrážely změny, jsou aktualizovány také testy.Požadavek je považován za splněný pouze v případě, že test proběhne úspěšně.Pokud je to možné nebo praktické, testy jsou definovány a založeny na diagramech UML před zahájením implementace.

Viz:

Určení změn ve stávajícím systému

Společnost Dinner Now musí odhadnout náklady na splnění nového požadavku.To zčásti závisí na tom, jak moc tato změna ovlivní ostatní části systému.Aby to pomohl ostatním pochopit, jeden z vývojářů aplikace Večeře nyní z existujícího kódu vytvoří následující grafy a diagramy:

Graf nebo diagram

Zobrazuje

Graf závislostí

Viz:

Závislosti a jiné vztahy v kódu.

Například společnost Dinner Now může začít kontrolou grafu závislosti sestavení a získat tak přehled sestavení a jejich závislostí.Mohou se ponořit do grafů a prozkoumat obory názvů a třídy v těchto sestaveních.

Společnost Dinner Now může také vytvořit grafy a s jejich pomocí prozkoumat určité oblasti a další druhy vztahů v kódu.Používají Průzkumníka architektury nebo Průzkumníka řešení, které jim pomáhají najít a vybrat oblasti a vztahy, které je zajímají.

Diagram sekvence založený na kódu

Viz téma Vizualizace kódu u sekvenčních diagramů.

Sekvence interakcí mezi instancemi.

Sekvenční diagramy jsou generovány z definice metod a jsou užitečné pro pochopení, jak kód implementuje chování metody.

Diagram třídy založený na kódu

Viz téma Postupy: Přidání diagramů tříd do projektů (návrhář tříd).

Existující třídy v kódu

Například vývojář používá Průzkumníka architektury pro výběr oborů názvů, na které se chce zaměřit, a z kódu vytvoří graf závislosti.Nastaví oblast pro zaměření na oblasti, které jsou ovlivněny novým scénářem.Tyto oblasti jsou vybrané a zvýrazněné v grafu:

Graf závislosti oboru názvů

Graf závislosti oboru názvů

Vývojář rozbalí vybrané obory názvů, aby zobrazil jejich třídy, metody a vztahy:

Graf závislosti rozšíření oboru názvů

Graf závislosti expandovaného oboru názvů s viditelnými odkazy mezi skupinami

Vývojář kontroluje kód k nalezení příslušné tříd a metod.Generuje sekvenční diagramy a diagramy tříd z kódu k popisu a diskutování o změnách.Viz téma Vizualizace kódu.

Tip

Chcete-li vidět efekt každé změny, kterou provedete, obnovte grafy závislostí grafů a sekvenční diagramy z kódu po každé změně.

K popisu změn jiných částí systému, například součástí nebo interakcí, může tým kreslit tyto prvky na tabule.Mohou také nakreslit následující diagramy v aplikaci Visual Studio, aby mohly oba týmy zachytit, spravovat a pochopit podrobnosti:

Diagramy

Popisuje

Diagram činnosti (UML)

Viz:

Kroky toku, ke kterým dojde, pokud systém zjistí, že zákazník vytvoří v restauraci objednávku znovu, s výzvou zákazníka, aby napsal recenzi.

Diagram tříd (UML)

Viz:

Logické třídy a jejich vztahy.Například je přidána nová třída popisující Přezkoumání a jeho vztahy s ostatními entitami, jako např. Restaurace, Nabídka a Zákazník.

Pokud chcete přidružit recenze k zákazníkovi, systém musí ukládat informace o zákazníkovi.Diagram tříd UML může pomoci objasnit tyto podrobnosti.

Diagram třídy založený na kódu

Viz téma Postupy: Přidání diagramů tříd do projektů (návrhář tříd).

Existující třídy v kódu.

Diagram součásti (UML)

Viz:

Části systému vysoké úrovně, například web Dinner Now a jejich rozhraní.Tato rozhraní definují, jak komponenty interagují navzájem pomocí metod nebo služeb, které poskytují a spotřebovávají.

Sekvenční diagram (UML)

Viz:

Sekvence interakcí mezi instancemi.

Například následující diagram komponent ukazuje novou komponentu, která je součástí součásti webu Dinner Now.Komponenta ReviewProcessing zpracovává funkce vytváření recenzí a je zvýrazněna oranžově:

Diagram komponenty UML

Diagram součásti UML

Následující sekvence diagramu znázorňují posloupnost interakcí, které vzniknou, když web Dinner Now zkontroluje, zda zákazník v minulosti v restauraci prováděl objednávku.Pokud ano, požádá zákazníka o vytvoření recenze, která bude odeslána restauraci a zveřejněna na webu:

Sekvenční diagram UML

Sekvenční diagram UML

Udržování kódu v souladu s návrhem

Společnost Dinner Now musí zajistit, že aktualizovaný kód zůstane konzistentní s návrhem.Vytvářejí diagramy vrstvy, které popisují vrstvy funkčnosti v systému, určují povolené závislosti mezi nimi a přidružují artefakty řešení k těmto vrstvám.

Diagram

Popisuje

Diagram vrstvy

Viz:

Logická architektura kódu.

Vrstva diagram organizuje a mapuje artefakty v řešení Visual Studio za účelem abstrahování skupin nazvaných vrstvy.Tyto vrstvy určují role, úlohy a funkce, které tyto artefakty provádějí v systému.

Diagramy vrstev jsou užitečné pro popis zamýšleného návrhu systému a k ověřování vyvíjeného kódu ve srovnání s tímto návrhem.

Chcete-li vytvořit vrstvu, přetáhněte položky z Průzkumníku řešení, grafů závislosti nebo Průzkumníku architektury.Chcete-li nakreslit nové vrstvy, použijte panel nástrojů nebo klepněte pravým tlačítkem myši na plochu diagramu.

Chcete-li zobrazit existující závislosti, klepněte pravým tlačítkem na plochu diagramu a potom klepněte na tlačítko Generovat závislosti.K určení zamýšlených závislostí, nakreslete nové závislosti.

Například následující diagram vrstvy popisuje závislosti mezi vrstvami a počet artefaktů spojených s každou vrstvou:

Diagram vrstvy systému integrované platby

Diagram vrstvy

Aby se ujistily, že se nevyskytnou konflikty s návrhem během vývoje kódu, týmy používají ověřování vrstev na sestaveních, které běží na Team Foundation Build.Mohou také vytvořit vlastní úkol MSBuild pro vyžadování ověření vrstvy v jejich operacích vrácení se změnami.Používají zprávy sestavení ke shromažďování chyb ověřování.

Viz:

Obecné tipy pro vytváření a použití modelů

  • Většina diagramů se skládá z uzlů, které jsou spojeny čarami.Pro každý typ diagramu obsahuje panel nástrojů různé druhy uzlů a řádků.

    Chcete-li otevřít sadu nástrojů, klepněte na možnost Sada nástrojů v nabídce Zobrazení.

  • Chcete-li vytvořit uzel, přetáhněte ho z panelu nástrojů do diagramu.Některé typy uzlů musí být přetaženy do existujících uzlů.Například v diagramu komponent musí být k existující součásti přidán nový port.

  • Chcete-li vytvořit čáru nebo připojení, klepněte na příslušný nástroj v soupravě nástrojů, klikněte na zdrojový uzel a poté klepněte na cílový uzel.Některé řádky lze vytvořit pouze mezi určitými typy uzlů.Přesunete-li ukazatel přes možný zdroj nebo cíl, ukazatel myši označuje, zda lze vytvořit připojení.

  • Při vytváření položek v diagramech UML je rovněž přidáváte do společného modelu.Diagramy UML jsou při modelování projektu zobrazení tohoto modelu.Položky v diagramu vrstvy jsou součástí projektu modelování, i když nejsou uloženy ve společném modelu.

    Chcete-li zobrazit model, v nabídce Architektura přejděte na možnost Windows a potom klepněte na tlačítko Průzkumník modelů UML.

  • V některých případech můžete přetáhnout některé položky z Průzkumníka modelů UML do diagramu UML.Některé prvky v rámci stejného modelu lze použít na více nebo různé diagramy zobrazit k alternativním zobrazením architektury.Například můžete přetáhnout komponentu do jiného diagramu komponent nebo do sekvenčního diagramu tak, aby ji bylo možné použít jako prvek „actor“.

  • Visual Studio Ultimate podporuje UML 2.1.2.Tento přehled popisuje hlavní funkce diagramů UML v této verzi, ale existuje mnoho knih, které o UML a jeho použití podrobně pojednávají.

Viz téma Vývoj modelů pro návrh softwaru.

Plánování a sledování práce

Diagramy modelování Visual Studio Ultimate jsou integrovány se serverem Team Foundation Server, takže můžete plánovat, řídit a sledovat svou práci snadněji.Oba týmy používat modely k identifikaci testových případů a vývojářských úloh a k odhadu hotové práce.Společnost Lucerne vytvoří a propojí pracovní položky serveru Team Foundation Server k prvkům modelu, jako jsou případy použití nebo komponenty.Tímto způsobem lze sledovat jejich průběh a trasovat jejich práci zpět podle požadavků uživatelů.To pomáhá se ujistit, že jejich změny nadále splňují tyto požadavky.

Jak jejich práce postupuje, týmy aktualizují své pracovní položky, aby odrážely čas strávený na úkolech.Také sledují a hlásí stav své práce pomocí následujících funkcí sady Team Foundation Server:

  • Denní hlášení pracovního tempa, které uvádí, zda bude plánovaná práce dokončena v předpokládaném čase.Vytvářejí jiné podobné sestavy z Team Foundation Server, aby sledovali průběh chyb.

  • Seznam iterací, který používá aplikace Microsoft Excel k tomu, aby tým mohl sledovat a vyvážit zatížení mezi členy.Tento list je propojen se serverem Team Foundation Server a poskytuje zaměření na diskuse během pravidelných schůzky o pokroku.

  • Řídicí panel vývoje, který používá Office Project k informování týmu o důležitých informacích projektu.

Viz:

Testování, ověřování a vrácení kódu se změnami

Jak týmy dokončují jednotlivé úkoly, vraťte jejich kód do ovládacího prvku verze Team Foundation a přijměte připomenutí z Team Foundation Server v případě, že zapomenete.Než Team Foundation Server přijme jejich vrácení se změnami, týmy spustí jednotkové testy a ověření vrstvy za účelem ověření kódu proti testovacím případům a návrhu.Používají Team Foundation Server ke spouštění sestavení, automatizovaných testů jednotek a pravidelné validaci vrstev.To pomáhá zajistit, že kód splňuje následující kritéria:

  • Funguje.

  • Nedojde k poškození dříve funkčního kódu.

  • Nevznikne konflikt s návrhem.

Společnost Dinner Now má velkou kolekci automatických testů, které může společnost Lucerne znovu použít, protože téměř všechny jsou stále platné.Společnost Lucerne může také stavět na těchto testech a přidat nové, aby pokryl nové funkce.Oba také využívají Visual Studio Ultimate ke spuštění ručních testů.

Aby se ujistily, že kód odpovídá návrhu, konfigurují týmy svá sestavení v Team Foundation Build tak, aby zahrnovala ověřování vrstvy.Pokud dojde ke konfliktům, vygeneruje se sestava s podrobnostmi.

Viz:

Aktualizace systému pomocí vizualizace a modelování

Weby Lucerne a Dinner Now musí integrovat své platební systémy.Následující oddíly zobrazují že diagramy modelování v aplikaci Visual Studio Ultimate, které jim pomáhají s provedením této úlohy:

  • Pochopte požadavky uživatelů: diagramy případů použití

  • Pochopte obchodní proces: Diagramy činnosti

  • Popište strukturu systému: diagramy komponent

  • Popište interakce: sekvenční diagramy

  • Vizualizovat existující kód: Grafy závislosti

  • Definice glosáře typů: Diagramy třídy

  • Popište logickou architekturu: diagramy vrstvy

Viz:

Pochopte požadavky uživatelů: diagramy případů použití

Použijte diagramy případu pro shrnutí činností, které systém podporuje, a kdo provádí tyto činnosti.Společnost Lucerne používá diagram případu použití ke zjištění následujících informací o systému Dinner Now:

  • Zákazníci vytváří objednávky.

  • Restaurace přijímají objednávky.

  • Externí brána procesu platby, kterou používá platební systém Dinner Now ke schválení plateb, je mimo rozsah webu.

Diagram také ukazuje, jak některé z hlavních případů použití jsou rozděleny do menších případů použití.Společnost Lucerne chce používat vlastní platební systém.Zvýrazňují případ použití zpracování platby odlišnou barvou pro označení toho, že vyžaduje změny:

Zvýraznění proces platby na diagramu případu použití

Zvýraznění platby proces v diagramu případu použití

Pokud byl vývoj krátký, tým může projednat, zda chtějí zákazníkům restaurace umožnit zaplatit přímo.Aby to předvedli, nahradili by případ použití platebního procesu takovým, který je mimo hranice systému Večeře nyní.Spojí tak zákazníka přímo s restaurací, a označují tak, že Večeře nyní bude pouze zpracovávat objednávky:

Rescoping restaurace placené na diagramu případu použití

Změna oboru mzdy restaurace na diagramu případu použití

Viz:

Náčrt diagramu případu použití

Diagram případu použití má následující hlavní funkce:

  • Subjekty představují role, které hrají osoby, organizace, počítače nebo softwarové systémy.Aktéry je například Zákazník, Restaurace a Platební systém společnosti Dinner Now.

  • Případy použití představují interakce mezi objekty actor a systémem ve vývoji. Mohou představovat jakékoli měřítko interakce jediným klepnutím myši nebo zprávou transakci prodloužené na kolik dní.

  • Přidružení propojuje aktéry s případy použití.

  • Případ většího využití může zahrnovat menší případy, například vytvoření objednávky zahrnuje výběr restaurace.Můžete rozšířit případ použití, který přidá cíle a kroky k rozšířenému případu použití k označení, že k případu použití dochází pouze za určitých podmínek.Případy použití mohou také dědit od sebe navzájem.

  • Subsystém představuje softwarový systém, který je ve vývoji, nebo některou jeho součást.Jedná se o velké pole, které obsahuje případy použití.Diagram případu použití vysvětluje, co je uvnitř nebo vně hranice podsystému.Chcete-li označit, že uživatel musí dosáhnout určitých cílů jinými způsoby, nakreslete tyto případy mimo hranice podsystému.

  • Artefakty propojení prvků v diagramu s jinými diagramy nebo dokumenty.

Viz:

Shrnutí: Silné stránky diagramů případů používání

Použijte diagramy případu pro lepší vizualizaci:

  • Činnosti, které systém podporuje nebo nepodporuje

  • Osoby a externí systémy, které provádějí tyto činnosti

  • Hlavní součásti systému, které podporují jednotlivé aktivity, které mohou představovat jako podsystémy vnořené uvnitř nadřazeného systému

  • Jak může být případ použití rozdělen do menších případů nebo jejich variant

Vztah k jiným diagramům

Diagram

Popisuje

Diagram činnosti

Tok kroků případu použití a těch, kteří vykonávají tyto kroky v případu použití.

Názvy použití případů často zrcadlí kroky v diagramu činnosti.Diagramy činnosti podporují prvky, jako jsou rozhodnutí, sloučení, vstupy a výstupy, souběžné toků a tak dále.

Viz:

Sekvenční diagram

Sekvence interakcí mezi účastníky v případu použití.

Viz:

Diagram tříd (UML)

Subjekty nebo typy, které se účastní případu použití.

Viz:

Pochopte obchodní proces: Diagramy činnosti

Diagramy činnosti popisují tok kroků v procesu podnikání a poskytují jednoduchý způsob, jak komunikovat pracovní postup.Projekt vývoje může mít více diagramů činnosti.Činnost obvykle zahrnuje všechny akce, které vyplývají z jedné externí akce, například objednávka pokrmu, aktualizace menu nebo přidání nové restaurace do podnikání.Aktivita může také popisovat podrobnosti složité akce.

Společnost Lucerne aktualizuje následující diagram činnosti aby znázornila, že zpracuje platbu a zaplatí restauraci.Nahradí platební systém Lucerne platebním systémem Večeře nyní, jak je zvýrazněno:

Systém platby Lucerne na diagram aktivity

Nahradí platební systém společnosti Dinner Now v diagramu činnosti

Aktualizovaný diagram pomůže aplikacím Lucerne a Večeře nyní vizualizovat, kde systém platby Lucerne zapadá do obchodního procesu.V tomto vydání komentáře slouží k identifikaci rolí, které provádějí postupy.Řádky slouží k vytvoření plaveckých drah, které organizují kroky podle rolí.

Týmy mohou také zvážit diskuzi o alternativním článku, kde zákazník zaplatí restauraci místo, aby platil po dodání objednávky.To by vedlo k různým požadavkům na software systému.

Dříve v Dinner Now byly tyto diagramy kresleny na tabuli nebo v aplikaci PowerPoint.Také teď kreslí tyto diagramy v aplikaci Visual Studio, aby mohly oba týmy zachytit, spravovat a pochopit podrobnosti:

Viz:

Náčrt diagramu aktivit

Diagram aktivity má následující hlavní funkce:

  • Počáteční uzel, který označuje první akci aktivity.

    Diagram by měl vždy obsahovat jeden z těchto uzlů.

  • Akce, které popisují kroky, pokud uživatel nebo program provede úlohu.

  • Řízení toků, které znázorňuje tok mezi akcemi.

  • Uzly pro rozhodnutí představující podmíněné větvení v toku.

  • Uzly rozvětvení, které dělí jeden tok do souběžných toků.

  • Konečné uzly aktivity, které ukazují ukončení aktivity.

    Přestože jsou tyto uzly volitelné, je vhodné je zahrnout do diagramu a zobrazit, kde končí činnost.

Viz:

Shrnutí: Silné stránky diagramů činností

Diagramy aktivit pomáhají vizualizovat a popisovat tok řízení a informací mezi akcemi obchodu, systému nebo programu.Toto je jednoduchý a užitečný způsob popisu pracovního postupu při komunikaci s jinými uživateli.

Vztah k jiným diagramům

Diagram

Description

Použijte diagram případu

Souhrn činností, které provádí každý objekt actor.

Viz:

Diagram součásti

Vizualizujte systém jako kolekci znovu použitelných částí, které poskytují nebo využívají chování prostřednictvím kvalitně definované sady rozhraní.

Viz:

Popište strukturu systému: diagramy komponent

Diagramy součástí popisují systém jako kolekci oddělitelných částí, které poskytují nebo využívají chování prostřednictvím kvalitně definované sady rozhraní.Části mohou být v libovolném měřítku a lze je připojit libovolným způsobem.

Aby pomohli aplikacím Lucerne a Večeře nyní vizualizovat a projednat systémové součásti a jejich rozhraní, vytvářejí následující diagramy komponent:

Externí komponenty v systému platby

Součásti systému platby ve společnosti Dinner Now

Tento diagram znázorňuje různé typy komponent a jejich závislosti.Například web společnosti Dinner Now i platební systém Lucerne vyžadují, aby platby ověřila externí brána pro zpracování platby.Šipky mezi komponentami představují závislosti, které označují součásti, které vyžadují funkci jiných komponent.

Pro použití platebního systému Lucerne web Večeře nyní musí být aktualizován na použití rozhraní PaymentApproval a PayableInsertion v platebním systému Lucerne.

Následující diagram ukazuje určitou konfiguraci součástí pro web Dinner Now.Tato konfigurace určuje, že všechny instance webového serveru se skládají ze čtyř částí:

  • CustomerProcessing

  • OrderProcessing

  • ReviewProcessing

  • PaymentProcessing

Tyto části jsou instancemi určitých typů součástí a jsou propojeny takto:

Součásti v rámci večeři nyní webového serveru

Součásti ve webu společnosti Dinner Now

Web Dinner Now deleguje své chování na ty části, které zpracovávají funkce webového serveru.Šipky mezi nadřízenou součástí a jejími součástmi členů zobrazují delegace označující části, které zpracovávají zprávy, které nadřízený přijímá nebo odesílá prostřednictvím svých rozhraní.

V této konfiguraci komponenta PaymentProcessing zpracovává platby zákazníků.Proto musí být aktualizováno pro integraci s platebním systému společnosti Lucerne.V jiných scénářích může existovat více instancí typu komponenty ve stejné nadřazené komponentě.

Viz:

Náčrt diagramu součástí

Diagram komponenty má následující hlavní funkce:

  • Součást představující oddělitelné části funkcí systému.

  • Uvedené porty rozhraní, které představující skupiny zpráv nebo volání, které implementují součásti a jsou použity jinými součástmi nebo externí systémy.

  • Požadované porty rozhraní, které představující skupiny zpráv nebo volání, které odesílají do jiných součástí nebo externích systémů.Tento druh portu popisuje operace, které komponenta alespoň očekává od jiných komponent nebo externích systémů.

  • Části jsou členy komponent a jsou obvykle instance jiných komponent.Součást je část interního návrhu nadřazené komponenty.

  • Závislosti označující součásti, které vyžadují funkce jiných komponent.

  • Delegace označující části komponent slouží ke zpracování zpráv odesílaných nebo přijímaných nadřazenou komponentou.

Viz:

Shrnutí: Silné stránky diagramů komponent

Diagramy součástí umožňují vizualizaci:

  • Systém jako kolekce oddělitelných částí bez ohledu na jejich implementaci jazyka nebo stylu.

  • Součásti s kvalitně definovanými rozhraními, které usnadní vývojářům orientaci a aktualizaci při změně požadavků.

Vztah k jiným diagramům

Diagram

Description

Graf závislostí

Vizualizujte organizaci a vztahy v existujícím kódu.

Chcete-li identifikovat kandidáty na součásti, vytvořte graf závislosti a seskupte položky podle jejich funkce v systému.

Viz:

Sekvenční diagram

Vizualizujte řadu interakcí mezi komponentami nebo částmi uvnitř komponenty.

Chcete-li vytvořit objekt životnosti v diagramu z komponentu, klepněte pravým tlačítkem myši na komponent a potom klepněte na tlačítko Vytvořit životnost.

Viz:

Diagram tříd (UML)

Definujte rozhraní poskytnutých nebo požadovaných portů a tříd, které implementují funkce součástí.

Viz:

Diagram vrstvy

Popište logickou architekturu systému v souvislosti se součástmi.Použijte ověření vrstev, abyste zajistili, že kód zůstane konzistentní s návrhem.

Viz:

Diagram činnosti

Vizualizujte vnitřní zpracování, které provedou komponenty jako odpověď na příchozí zprávy.

Viz:

Vizualizovat existující kód: Grafy závislosti

Grafy závislosti znázorňují aktuální organizaci a vztahy v kódu.Položky jsou představovány uzly na grafu a vztahy jsou reprezentovány propojeními.S grafy závislosti můžete provést následující typy úkolů:

  • Prozkoumejte neznámý kód.

  • Pochopte, jak a kde navrhované změny mohou ovlivnit existující kód.

  • Vyhledejte oblasti složitosti, přirozené vrstvy nebo vzorky a další oblasti, které by mohly mít prospěch z vylepšení.

Například společnost Dinner Now musí odhadnout náklady na aktualizaci komponenty PaymentProcessing.To zčásti závisí na tom, jak moc tato změna ovlivní ostatní části systému.Aby to pomohl ostatním pochopit, jeden z vývojářů aplikace Večeře nyní generuje grafy závislosti z kódu a upravuje rozsah zaměření na oblasti, které by mohly být ovlivněny změnou.

Následující graf ukazuje závislosti mezi třídou PaymentProcessing a jinými částí systému Dinner Now, které se zobrazí vybrané:

Graf závislosti nyní večeři platby systému

Graf závislosti pro platební systém společnosti Dinner Now

Vývojář zkoumá graf rozšiřující třídou PaymentProcessing a výběrem svých členů pro zobrazení oblastí, které jsou ovlivněny potenciálně ovlivněny:

Metody uvnitř PaymentProcessing a závislosti

Metody uvnitř třídy PaymentProcessing a jejich závislosti

Generují následující graf pro systém platby Lucerne, aby kontrolovali své třídy, metody a závislost.Tým vidí, že systém Lucerne může také vyžadovat práci kvůli interakci s ostatními částmi systému Dinner Now:

Graf závislosti pro systém Lucerne platby

Graf závislosti pro platební systém společnosti Lucerne

Oba týmy společně pracují na určení změn, které jsou nutné k integraci obou systémů.Rozhodnou se refaktorovat kód, takže se bude snadněji 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é zpracují transakce, budou mít vlastní obor názvů.Týmy vytvářejí a používají pracovní položky k naplánování, uspořádání a sledování své práce.Spojují pracovní položky s prvky modelu tam, kde je to užitečné.

Po reorganizaci kódů týmy generují nový graf závislosti za účelem zobrazení aktualizované strukturu a vztahů:

Graf závislosti s přeorganizované kódu

Graf závislosti s přeorganizovaným kódem

Tento graf 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, což usnadňuje později zacházet s tímto kódem.

Vytvoření grafu závislosti

Shrnutí: Silné stránky grafů závislostí

Grafy závislosti umožňují:

  • Získejte informace o organizaci a vztazích v existujícím kódu.

  • Určete oblasti, které mohou být postiženy navrhovanou změnou.

  • Vyhledejte oblasti složitosti, vzorky, vrstvy a další oblasti, které lze zlepšit a zjednodušit tak údržbu, úpravu a opakované využívání kódu.

Vztah k jiným diagramům

Diagram

Popisuje

Diagram vrstvy

Logická architektura systému.Použijte ověření vrstev, abyste zajistili, že kód zůstane konzistentní s návrhem.

Chcete-li usnadnit identifikaci existujících vrstev nebo zamýšlených vrstev, vytvořte graf závislosti a seskupte související položky.Chcete-li vytvořit diagram vrstvy, přetáhněte položky z grafu nebo Průzkumníka architektury.

Viz:

Diagram součásti

Součásti, jejich rozhraní a jejich vztahy.

Chcete-li usnadnit identifikaci součástí, vytvořte graf závislosti a seskupte položky podle jejich funkce v systému.

Viz:

Diagram tříd (UML)

Třídy, jejich atributy a operace a jejich vztahy.

Chcete-li usnadnit identifikaci těchto prvků, vytvořte dokument grafu, který zobrazuje tyto prvky.

Viz:

Diagram tříd (založený na kódu)

Existující třídy v kódu.

Chcete-li vizualizovat a upravit existující třídu v kódu, použijte návrhář tříd.

Viz téma Postupy: Přidání diagramů tříd do projektů (návrhář tříd).

Popište interakce: sekvenční diagramy

Sekvenční diagramy popisují řadu interakcí mezi částmi systému.Části mohou být z libovolného měřítka.Například se mohou lišit v rozsahu od jednotlivých objektů v programu po velké podsystémy nebo externí aktéry.Interakce může být libovolného rozsahu a typu.Například se mohou lišit v rozsahu od jednotlivých zpráv po rozšířené operace a mohou být voláním funkce nebo zprávami webové služby.

Aby pomohli aplikacím Lucerne a Večeř nyní popsat a projednat kroky v případu použití Zpracování platby, vytvářejí následující sekvenční diagram z diagramu komponent.Životnosti zrcadlení součásti webu Dinner Now a jeho částí.Zprávy, které se objeví mezi životnosti následujícího připojení v diagramech komponent:

Sekvenční diagram pro proces platby případu použití

Sekvenční diagram pro zpracování platby používá případ

Sekvenční diagram ukazuje, že pokud zákazník vytvoří objednávku, web Večeře nyní zavolá ProcessOrder v instanci OrderProcessing.Dále funkce OrderProcessing volá funkci ProcessPayment komponenty PaymentProcessing.Tento postup se opakuje, dokud brána externího zpracovatele platby platbu neověří.Teprve potom se ovládací prvek vrátí k webu Dinner Now.

Společnost Lucerne musí odhadnout náklady na aktualizaci platebního systému, aby jej bylo možné integrovat se systémem webu Dinner Now.Aby to pomohl ostatním pochopit, jeden z vývojářů z kódu generuje sekvenční diagramy, a vizualizuje tak existující interakce:

Viz:

Náčrt diagramu sekvence

Diagram sekvence má následující hlavní funkce:

  • Vertikální životnosti představují aktéry nebo instance objektů softwaru.

    Chcete-li přidat objekt actor symbol, který označuje účastníka, který je mimo systém ve vývoji, klepněte na tlačítko životnost.V okně Vlastnosti nastavte vlastnost Actor na hodnotu True.Pokud se okno Vlastnosti nezobrazí, stiskněte klávesu F4.

  • Vodorovné zprávy představují metody volání, zprávy webové služby nebo některou jinou komunikaci.Případy spouštění jsou svislé šedé obdélníky, které se zobrazí v rámci životnosti a představují období, během kterých příjmové objekty zpracovávají volání.

  • Během synchronní zprávy čeká objekt - odesílatel, než se ovládací prvek <<vrátí>> jako normální volání funkce.Během asynchronní zprávy odesílatel může pokračovat okamžitě.

  • Použijte zprávy <<vytvořit>> pro označení konstrukce objektů jinými objekty.Měla by to být první zpráva odeslaná do objektu.

Viz:

Shrnutí: Silné stránky sekvenčních diagramů

Sekvenční diagramy umožňují vizualizaci:

  • Tok řízení, který přenáší mezi objekty actor nebo objekty během zpracování případu použití.

  • Implementace metody volání nebo zprávy.

Vztah k jiným diagramům

Diagram

Description

Diagram tříd (UML)

Definujte třídy, které představují životnost a parametry a vraťte hodnoty, které jsou použity ve zprávách odesílaných v rámci životností.

Chcete-li vytvořit třídu z objektu životnosti, klepněte pravým tlačítkem myši na životnost a potom klepněte na tlačítko Vytvořit třídu nebo Vytvořit rozhraní.Chcete-li vytvořit objekt životnosti z typu v diagramu třídy, klepněte pravým tlačítkem myši na typ a potom klepněte na tlačítko Vytvořit životnost.

Viz:

Diagram součásti

Popište komponenty, které představují životnost a rozhraní, které poskytuje a využívá chování reprezentované zprávami.

Chcete-li vytvořit objekt životnosti z diagramu komponentu, klepněte pravým tlačítkem myši na komponent a potom klepněte na tlačítko Vytvořit životnost.

Viz:

Použijte diagram případu

Interakce mezi uživateli a komponenty v sekvenčním diagramu lze shrnout jako případ použití, který představuje cíl uživatele.

Viz:

Definice glosáře typů: Diagramy třídy

Diagramy tříd definují entity, podmínky nebo koncepty, které jsou součástí systému, a jejich vztahy mezi sebou.Tyto diagramy můžete použít například během vývoje pro popis atributů a operací pro každou třídu, bez ohledu na jejich jazyk nebo styl implementace.

Aby usnadnili aplikaci Lucerne popsat a diskutovat subjekty, které se účastní případu použití zpracování platby, nakreslí následující diagram třídy:

Zpracování platby entit na diagram třídy

Entity platby procesu na diagram třídy

Tento diagram znázorňuje, že zákazník může mít mnoho objednávek a různé způsoby platby za objednávky.BankAccount a CreditCard dědí z Payment.

Během vývoje používá společnost Lucerne následující diagram tříd k popisu a diskuzi o podrobnostech k jednotlivým třídám:

Zpracování platby entity podrobnosti o diagramu třídy

Detaily platby procesu na diagram třídy

Viz:

Náčrt diagramu třídy

Diagram třídy má následující hlavní funkce:

  • Typy jako třídy, rozhraní a výčty:

    • Třída je definice objektů, které sdílejí určité 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ždý výskyt třídění.Klasifikátor je obecný název pro typy, komponenty, případy použití a dokonce aktéry.

  • Operace jsou metody nebo funkce, které instance klasifikátoru mohou provádět.

  • Přidružení označuje určitý druh vztahu mezi dvěma klasifikátory.

    • Agregace je přidružení, které označuje sdílené vlastnictví mezi klasifikátory.

    • Sestavení je přidružení, které označuje vztah část-celek mezi klasifikátory.

    K zobrazení souhrnných hodnot nebo složení nastavte vlastnost Agregace na přidružení.Sdílené zobrazuje agregace a Složené zobrazuje sestavení.

  • Závislost značí, že změna definice jednoho třídění může změnit definice jiného třídění.

  • Generalizace označuje, že zvláštní třídění dědí část definice z obecného třídění.Realizace označuje, že třída implementuje operace a atributy, které nabízí rozhraní.

    Chcete-li vytvořit tyto vztahy, použijte nástroj Dědičnost.Alternativně může být realizace reprezentována jako typ Lupa.

  • Balíčky jsou skupiny klasifikátorů, přidružení, životností, komponent a dalších balíčků.Import vztahy označují, že jeden balíček obsahuje všechny definice jiného balíčku.

Jako výchozí bod pro zkoumání a probírání existujících tříd můžete použít Návrháře tříd pro vytvoření diagramů tříd z kódu.

Viz:

Shrnutí: Silné stránky diagramů tříd

Diagramy tříd umožňují definovat:

  • Společný glosář termínů pro použití při projednávání potřeb uživatelů a entit, které jsou součástí systému.Viz téma Modelování uživatelských požadavků.

  • Typy, které jsou používány součástmi systému, například komponenty bez ohledu na jejich implementaci.Viz téma Modelování architektury softwarového systému.

  • Vztahy, například závislosti, mezi typy.Například můžete zobrazit, že jeden typ může být přiřazen k více instancím jiného typu.

Vztah k jiným diagramům

Diagram

Description

Použijte diagram případu

Definujte typy, které se používají k popisu cílů a postupy v rámci případů použití.

Viz:

Diagram činnosti

Definujte typy dat, která prochází uzly objektu, vstupní spojky, výstupní spojky a uzly parametru činností.

Viz:

Diagram součásti

Popište komponenty, jejich rozhraní a jejich vztahy.Třída může také popisovat kompletní komponentu.

Viz:

Diagram vrstvy

Definujte logickou architekturu systému v souvislosti se třídami.

Použijte ověření vrstev, abyste zajistili, že kód zůstane konzistentní s návrhem.

Viz:

Sekvenční diagram

Definujte typy životnosti a operace, parametry a návratové hodnoty pro všechny zprávy, které lze v rámci životnosti obdržet.

Chcete-li vytvořit objekt životnosti z typu v diagramu třídy, klepněte pravým tlačítkem myši na typ a potom klepněte na tlačítko Vytvořit životnost.

Viz:

Graf závislostí

Vizualizujte organizaci a vztahy v existujícím kódu.

Pro identifikaci tříd, jejich metod a jejich vztahů vytvořte dokument grafu, který obsahuje tyto prvky.

Viz:

Popište logickou architekturu: diagramy vrstvy

Diagramy vrstev popisují logickou architekturu systému organizací artefaktů ve vašem řešení do abstraktních skupin či vrstev.Artefakty mohou být mnoho věcí, například obory názvů, projekty, třídy, metody a tak dále.Vrstvy představují a popisují role a úlohy, které tyto artefakty provádějí v systému.Můžete také zahrnout ověřování vrstvy v sestavení a vrátit operace se změnami, abyste se ujistili, že kód zůstává konzistentní s návrhem.

Aby byl kód zachován konzistentní s návrhem, aplikace Večeře nyní a Lucerne používají následující diagram vrstvy k ověřování svého kódu, jak se vyvíjí:

Diagram vrstvy systému integrované platby

Diagram vrstvy pro web Dinner Now integrovaný se systémem Lucerne

Vrstvy v tomto diagramu odkazují na odpovídající artefaktů řešení Dinner Now a Lucerne.Například, vrstva Business je propojena s oborem názvů DinnerNow.Business a jeho členovy, který nyní obsahuje třídu PaymentApprover.Vrstva Přístup k prostředkům odkazuje na obor názvů DinnerNow.Data.Šipky, nebo závislosti určují, že pouze vrstva Business může použít funkci ve vrstvě Přístup k prostředku.Jak týmy aktualizují svůj kód, vrstva ověřování je prováděna pravidelně, aby zachytila konflikty při jejich výskytu a pomohla týmům je rychle řešit.

Týmy pracují společně, a postupně se tak integrují a testují tyto dva systémy.Nejprve se ujistí, že PaymentApprover a zbytek systému Dinner Now spolupracují úspěšně, než se vypořádají s PaymentProcessing.

Následující graf závislosti zobrazuje nová volání mezi Dinner Now a PaymentApprover:

Graf aktualizované závislosti pomocí integrovaného systému

Graf závislosti s voláním aktualizované metody

Po potvrzení, že systém funguje podle očekávání, Dinner Now okomentuje kód PaymentProcessing.Zprávy ověření vrstvy jsou čisté a výsledný graf závislosti ukazuje, že neexistují žádné další závislosti PaymentProcessing:

Graf závislosti bez PaymentProcessing

Graf závislosti bez funkce PaymentProcessing

Viz:

Náčrt diagramu vrstvy

Diagram vrstvy má následující hlavní funkce:

  • Vrstvy popisují logické skupiny artefaktů.

  • Odkaz je přidružení mezi vrstvou a artefaktem.

    Chcete-li vytvořit vrstvu z artefaktů, přetáhněte položky z Průzkumníku řešení, grafů závislosti nebo Průzkumníku architektury.Chcete-li nakreslit nové vrstvy a propojit je s artefakty, použijte panel nástrojů nebo klepněte pravým tlačítkem myši na plochu diagramu pro vytvoření vrstvy a přetáhněte položky k těmto vrstvám.

    Číslo ve vrstvě zobrazuje počet artefaktů, které jsou spojeny s vrstvou.Tyto artefakty mohou být obory názvů, projekty, třídy, metody a tak dále.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.

      Například pokud je vrstva 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ěž odkazy na jednotlivé třídy 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.

    Chcete-li zobrazit artefakty, které jsou propojeny s vrstvou, klepněte pravým tlačítkem myši na vrstvu a klepněte na tlačítko Zobrazit odkazy a otevřete Průzkumník vrstev.

  • Závislost znamená, že jedna vrstva může použít funkci v jiné vrstvě, ale ne naopak.Obousměrná závislost znamená, že jedna vrstva může použít funkci v jiné vrstvě a naopak.

    Chcete-li zobrazit existující závislosti na diagramu vrstvy, klepněte pravým tlačítkem na plochu diagramu a potom klepněte na tlačítko Generovat závislosti.K popisu zamýšlených závislostí, nakreslete nové.

Viz:

Shrnutí: Silné stránky diagramů vrstev

Diagramy vrstev vám pomohou:

  • Popište logickou architekturu systému podle funkcí jeho artefaktů.

  • Ujistěte se, že kód ve vývoji odpovídá zadanému návrhu.

Vztah k jiným diagramům

Diagram

Description

Graf závislostí

Vizualizujte organizaci a vztahy v existujícím kódu.

Chcete-li vytvořit vrstvy, vygenerujte graf závislosti a potom seskupte položky v grafu jako potenciální vrstvy.Přetáhněte skupiny z grafu do diagramu vrstvy.

Viz:

Diagram součásti

Popište komponenty, jejich rozhraní a jejich vztahy.

Vizualizace vrstev, vytvoření diagramu komponent, který popisuje funkce různých složek v systému.

Viz:

Externí zdroje

Kategorie

Odkazy

Fóra

Blogy

Visual Studio ALM + blog Team Foundation Server

Technické články a deníky

Deník Architektura - problém 23: Architektura modelování a procesů

Jiné weby

MSDN Architecture Center

Viz také

Koncepty

Vizualizace kódu

Vývoj modelů pro návrh softwaru

Použití modelů v procesu vývoje

Používání modelů v agilním vývoji

Ověřování systému během vývoje

Rozšiřování modelů a diagramů UML