Použití modelů ve vývojových procesech
V sadě Visual Studio můžete použít model, který vám pomůže pochopit a změnit systém, aplikaci nebo komponentu. Model vám může pomoct vizualizovat svět, ve kterém váš systém funguje, objasnit potřeby uživatelů, definovat architekturu systému, analyzovat kód a zajistit, aby váš kód splňoval požadavky.
Pokud chcete zjistit, které verze sady Visual Studio podporují jednotlivé typy modelů, přečtěte si téma Podpora verzí pro nástroje pro architekturu a modelování.
Modely vám můžou pomoct několika způsoby:
Diagramy modelování výkresů pomáhají objasnit koncepty, které jsou součástí požadavků, architektury a návrhu vysoké úrovně. Další informace najdete v tématu Požadavky na uživatele modelu.
Práce s modely vám může pomoct odhalit nekonzistence v požadavcích.
Komunikace s modely pomáhá komunikovat důležité koncepty méně nejednoznačně než s přirozeným jazykem. Další informace najdete v tématu Modelování architektury vaší aplikace.
Modely můžete někdy použít ke generování kódu nebo jiných artefaktů, jako jsou schémata databáze nebo dokumenty. Například komponenty modelování sady Visual Studio se generují z modelu. Další informace najdete v tématu Generování a konfigurace aplikace z modelů.
Modely můžete používat v nejrůznějších procesech, od extrémních agilních až po vysoký obřad.
Použití modelů ke snížení nejednoznačnosti
Jazyk modelování je méně nejednoznačný než přirozený jazyk a je navržený tak, aby vyjadřoval myšlenky, které se obvykle vyžadují při vývoji softwaru.
Pokud má váš projekt malý tým, který sleduje agilní postupy, můžete použít modely, které vám pomůžou objasnit uživatelské scénáře. V diskusích se zákazníkem o svých potřebách může vytvoření modelu generovat užitečné otázky mnohem rychleji a v širší oblasti produktu než psaní kódu špičky nebo prototypu.
Pokud je váš projekt velký a zahrnuje týmy v různých částech světa, můžete pomocí modelů lépe sdělit požadavky a architekturu, než v prostém textu.
V obou případech vytvoření modelu téměř vždy vede k významnému snížení nekonzistence a nejednoznačností. Různé zúčastněné strany často mají různé znalosti obchodního světa, ve kterém systém funguje, a různí vývojáři často mají různé znalosti o tom, jak systém funguje. Použití modelu jako zaměření diskuze obvykle zveřejňuje tyto rozdíly. Další informace o tom, jak pomocí modelu snížit nekonzistence, najdete v tématu Požadavky uživatelů modelu.
Použití modelů s jinými artefakty
Model sám o sobě nepředstavuje specifikaci požadavků ani architekturu. Je to nástroj pro vyjádření některých aspektů těchto věcí jasněji, ale ne všechny koncepty potřebné při návrhu softwaru se dají vyjádřit. Modely by se proto měly používat společně s jinými způsoby komunikace, jako jsou stránky nebo odstavce OneNotu, systém Microsoft Office dokumenty, pracovní položky v Team Foundation nebo rychlé poznámky na stěně projektové místnosti. Kromě poslední položky mohou být všechny tyto typy objektů propojeny s prvky modelu.
Mezi další aspekty specifikace, které se běžně používají společně s modely, patří následující. V závislosti na rozsahu a stylu projektu můžete použít několik z těchto aspektů nebo vůbec žádné z těchto aspektů:
Uživatelské scénáře. Uživatelský příběh je krátký popis, probíraný s uživateli a dalšími účastníky, o aspektu chování systému, který se doručí v některé iteraci projektu. Typický uživatelský příběh začíná "Zákazník bude moci...". Uživatelský příběh může představovat skupinu případů použití nebo může definovat rozšíření případů použití, které byly dříve vyvinuty. Definování nebo rozšíření případů použití pomáhá usnadnit uživatelský příběh.
Žádosti o změnu Žádost o změnu v formálním projektu je velmi podobná uživatelskému scénáři v agilním projektu. Agilní přístup považuje všechny požadavky za změny toho, co bylo vyvinuto v předchozích iteracích.
Popis případu použití Případ použití představuje jeden ze způsobů, jak uživatel komunikuje se systémem, aby dosáhl konkrétního cíle. Úplný popis zahrnuje cíl, hlavní a alternativní posloupnosti událostí a výjimečných výsledků. Diagram případů použití pomáhá shrnout a poskytnout přehled případů použití.
Scénáře. Scénář je poměrně podrobný popis posloupnosti událostí, které ukazují, jak systém, uživatelé a další systémy spolupracují a poskytují hodnotu zúčastněným stranám. Může mít podobu prezentace uživatelského rozhraní nebo prototypu uživatelského rozhraní. Může popsat jeden případ použití nebo posloupnost případů použití.
Glosář. Glosář požadavků projektu popisuje slova, se kterými zákazníci diskutují o svém světě. Uživatelské rozhraní a modely požadavků by také měly používat tyto termíny. Diagram tříd může pomoct objasnit vztahy mezi většinou těchto termínů. Vytváření diagramů a glosáře nejen snižuje nedorozumění mezi uživateli a vývojáři, ale také téměř vždy zveřejňuje nedorozumění mezi různými obchodními účastníky.
Obchodní pravidla. Mnoho obchodních pravidel se dá vyjádřit jako neutrální omezení přidružení a atributů v modelu tříd požadavků a jako omezení sekvenčních diagramů.
Návrh vysoké úrovně. Popisuje hlavní části a jejich spojení. Diagramy komponent, sekvence a rozhraní jsou hlavní součástí návrhu vysoké úrovně.
Vzory návrhu Popište pravidla návrhu, která jsou sdílena v různých částech systému.
Specifikace testů. Testovací skripty a návrhy testovacího kódu můžou dobře využít diagramy aktivit a sekvencí k popisu sekvencí testovacích kroků. Systémové testy by měly být vyjádřeny z hlediska modelu požadavků, aby bylo možné je snadno změnit při změně požadavků.
Plán projektu. Plán projektu nebo backlog definuje, kdy se každá funkce doručí. Jednotlivé funkce můžete definovat tak, že uvedete, jaké případy použití a obchodní pravidla implementuje nebo rozšiřuje. Můžete se podívat na případy použití a obchodní pravidla přímo v plánu, nebo můžete definovat sadu funkcí v samostatném dokumentu a použít názvy funkcí v plánu.
Použití modelů při plánování iterace
I když se všechny projekty v jejich měřítku a organizaci liší, typický projekt se plánuje jako řada iterací mezi dvěma a šesti týdny. Je důležité naplánovat dostatek iterací, aby bylo možné zpětnou vazbu z počátečních iterací použít k úpravě rozsahu a plánů pro pozdější iterace.
Následující návrhy vám můžou pomoct při realizaci výhod modelování v iterativním projektu.
Zaostřit se při každém přístupu k iteraci
Jak se jednotlivé iterace blíží, použijte modely, které vám pomůžou definovat, co se má dodat na konci iterace.
Nemodelujte vše podrobně v počátečních iteracích. V první iteraci vytvořte diagram tříd pro hlavní položky v uživatelském glosáři, nakreslete diagram hlavních případů použití a nakreslete diagram hlavních součástí. Nepopisujte žádné z těchto podrobností, protože podrobnosti se později v projektu změní. Pomocí termínů definovaných v tomto modelu vytvořte seznam funkcí nebo hlavních uživatelských scénářů. Přiřaďte funkce iteracím, aby bylo možné přibližně vyvážit odhadované úlohy v celém projektu. Tato přiřazení se později v projektu změní.
Pokuste se implementovat zjednodušené verze všech nejdůležitějších případů použití v rané iteraci. Tyto případy použití můžete rozšířit v pozdějších iteracích. Tento přístup pomáhá snížit riziko zjištění chyb v požadavcích nebo příliš pozdě v projektu, aby s ním něco udělal.
Na konci každé iterace podržte workshop s požadavky, který podrobně definuje požadavky nebo uživatelské scénáře, které se budou vyvíjet v další iteraci. Pozvěte uživatele a obchodní účastníky, kteří můžou rozhodnout o prioritách a také vývojáři a testery systému. Povolte tři hodiny definování požadavků pro 2týdenní iteraci.
Cílem workshopu je, aby všichni souhlasili s tím, co bude dosaženo na konci další iterace. Modely můžete použít jako jeden z nástrojů, které vám pomůžou objasnit požadavky. Výstupem workshopu je backlog iterace: to znamená seznam vývojových úloh v Team Foundation a testovacích sadách v Microsoft Test Manageru.
V workshopu o požadavcích proberte návrh pouze v případě, že potřebujete určit odhady pro úkoly vývoje. V opačném případě pokračujte v diskuzi o chování systému, které můžou uživatelé zaznamenat přímo. Udržujte model požadavků odděleně od modelu architektury.
Netechnické zúčastněné strany obvykle nemají žádné problémy s pochopením diagramů UML s některými pokyny od vás.
Propojení modelu s pracovními položkami
Po workshopu s požadavky propracujte podrobnosti o modelu požadavků a propojte model s úlohami vývoje. Můžete to provést propojením pracovních položek v Team Foundation s prvky v modelu.
S pracovními položkami můžete propojit libovolný prvek, ale nejužitečnější prvky jsou následující:
- Komentáře popisující obchodní pravidla nebo požadavky na kvalitu služeb Další informace najdete v tématu Požadavky na uživatele modelu.
Propojení modelu s testy
Pomocí modelu požadavků můžete řídit návrh akceptačních testů. Vytvářejte tyto testy souběžně s vývojovou prací.
Další informace o této technice najdete v tématu Vývoj testů z modelu.
Odhad zbývající práce
Model požadavků může pomoct odhadnout celkovou velikost projektu vzhledem k velikosti každé iterace. Posouzení počtu a složitosti případů použití a tříd vám může pomoct odhadnout potřebnou vývojovou práci. Po dokončení prvních několika iterací může porovnání požadavků, na které se vztahuje, a požadavky, které se mají pokrýt, poskytnout přibližnou míru nákladů a rozsahu zbytku projektu.
Na konci každé iterace zkontrolujte přiřazení požadavků k budoucím iteracím. Může být užitečné znázorňovat stav vašeho softwaru na konci každé iterace jako subsystém v diagramu případů použití. V diskuzích můžete přesunout případy použití a rozšíření případů použití z jednoho z těchto subsystémů do jiného.
Úrovně abstrakce
Modely mají řadu abstrakcí ve vztahu k softwaru. Nejbetonnější modely přímo představují programový kód a nejobtraktnější modely představují obchodní koncepty, které můžou nebo nemusí být v kódu reprezentovány.
Model lze zobrazit prostřednictvím několika druhů diagramů. Informace o modelech a diagramech najdete v tématu Vytváření modelů pro vaši aplikaci.
Různé druhy diagramů jsou užitečné pro popis návrhu na různých úrovních abstrakce. Mnoho typů diagramů je užitečné na více než jedné úrovni. Tato tabulka ukazuje, jak lze každý typ diagramu použít.
| Úroveň návrhu | Typy diagramů |
|---|---|
| Obchodní proces Pochopení kontextu, ve kterém se bude váš systém používat, vám pomůže pochopit, co z něj uživatelé potřebují. |
– Koncepční diagramy tříd popisují obchodní koncepty používané v rámci obchodního procesu. |
| Požadavky uživatele Definice toho, co uživatelé potřebují z vašeho systému |
- Obchodní pravidla a požadavky na kvalitu služeb je možné popsat v samostatných dokumentech. |
| Návrh vysoké úrovně Celková struktura systému: hlavní komponenty a jejich spojení. |
- Diagramy závislostí popisují, jak je systém strukturován do vzájemně závislých částí. Kód programu můžete ověřit na diagramech závislostí, abyste měli jistotu, že dodržuje architekturu. |
| Analýza kódu Diagramy lze vygenerovat z kódu. |
– Diagramy závislostí znázorňují závislosti mezi třídami. Aktualizovaný kód lze ověřit v diagramu závislostí. – Diagramy tříd znázorňují třídy v kódu. |
Externí zdroje
Související obsah
- Použití modelů v agilním vývoji
- Vytváření modelů pro aplikaci
- Modelování uživatelských požadavků
- Modelování architektury aplikace
- Vývoj testů z modelu
- Strukturování řešení modelování
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 .