Použití modelů v procesu vývoje

Článek
06/10/2015

V Visual Studio Ultimate, můžete model vám pomůže pochopit a změnit systém, aplikace nebo komponenty.Model můžete vizualizovat světa, ve kterém pracuje systém, vyjasnění potřeb uživatelů, definovat architekturu systému, analyzovat kód a ujistěte se, že váš kód splňuje požadavky.

Viz videa kanálu 9: zlepšení architektury prostřednictvím modelování.

Jak používat modely

Modely můžete několika způsoby:

Kreslení diagramů modelování pomůže objasnit s koncepty týkajícími se požadavky, architektura a návrhu vysoké úrovně.Další informace naleznete v tématu Modelování uživatelských požadavků.
Práce s modely můžete vystavit nekonzistence v požadavcích.
Umožňuje komunikaci s modely sdělit důležité pojmy méně ambiguously než v přirozeném jazyce.Další informace naleznete v tématu Modelování architektury softwarového systému.
Někdy můžete modely pro generování kódu nebo jiné artefakty jako databázových schémat nebo dokumenty.Například modelování součástí Visual Studio Ultimate jsou generovány z modelu.Další informace naleznete v tématu Generování a konfigurování aplikace z modelů.

Můžete použít modely v celé řadě procesů v extreme agilní vysoká obřadu.

Pomocí modelů zmenšíte dvojznačnosti

Modelovací jazyk je jednoznačnější než přirozené jazykové a je určena pro vyjádření myšlenek, obvykle vyžadují během vývoje softwaru.

Pokud projekt obsahuje malý tým agilní praxí, můžete pomoci objasnit příběhy uživatelů modely.Jednání se zákazníky o jejich potřebách vytváření modelu můžete generovat užitečné dotazy mnohem rychleji a v širší oblasti produktu, než psát kód v zásobníku nebo prototypu.

Je-li váš projekt je velký a obsahuje týmy v různých částech zeměkoule, můžete použít modely umožňující komunikaci požadavky a architektura mnohem efektivněji než ve formátu prostého textu.

V obou případech vytváření modelu téměř vždy vede k významnému snížení nekonzistence a nejasnosti.Různé zúčastněné strany mají často různé ujednání o zrychleném světě, ve kterém pracuje systém a různí vývojáři často mají odlišné ujednání o fungování systému.Použití modelu jako aktivní diskusi obvykle zpřístupňuje tyto rozdíly.Další informace o tom, jak používat model snížit nekonzistence, viz Modelování uživatelských požadavků.

Používat modely s jinými artefakty

Model není sám o sobě, specifikace požadavků nebo architektura.Jedná se o nástroj pro vyjádření některé aspekty tyto věci jasněji, ale ne všechny pojmy, které jsou potřebné při návrhu softwaru lze vyjádřit.Modely je proto třeba použít společně s jinými prostředky komunikace, například stránek aplikace OneNote nebo odstavců, dokumenty Microsoft Office, pracovních položek v Team Foundation, nebo poznámek sticky notes na zdi místnosti projektu.Kromě poslední položky všechny tyto typy objektů lze propojit s částí prvky modelu.

Dalšími aspekty specifikace, které jsou obvykle používány spolu s modely jsou následující.V závislosti na rozsahu a stylu vašeho projektu můžete použít některé z těchto hledisek nebo používat žádné vůbec:

Příběhy uživatelů.Příběh uživatele je krátký popis projednán s uživateli a dalšími zúčastněnými stranami aspektu chování v systému, které budou dodány v jednom projektu iterací.Běžný uživatel článek začíná "zákazník bude moci..." Příběh uživatele může přinést skupině případů použití nebo definovat rozšíření případy použití, které jste dříve vytvořili.Definování nebo rozšíření případy použití díky příběhu uživatele srozumitelnější.
Požadavky na změnu.Požadavek na změnu v formálnější projektu je velmi podobný příběh uživatele agilní projektu.Agilní přístup považovány všechny požadavky na změny na co byl vyvinut v předchozí iterace.
Použíjte popis případu.Případ použití představuje jeden ze způsobů, v němž uživatel pracuje v systému k dosažení určitého cíle.Úplný popis obsahuje cíle, hlavní a alternativní sekvence událostí a výjimečných výsledků.Diagram případu použití pomáhá sumarizovat a poskytují přehled o případy použití.
Scénáře.Scénář je poměrně podrobný popis posloupnost událostí ukazující, jak systém, uživatelů a dalších systémech společně poskytují hodnoty zainteresovaných stran.To může mít formu slide show uživatelského rozhraní nebo prototyp uživatelského rozhraní.Můžete popsat, jednoho případu použití nebo posloupnost případy použití.
Glosář.Projektu požadavky glosáři slova, které zákazníci diskutovat o jejich světa.Uživatelské rozhraní a požadavky modely by měly také používat tyto podmínky.Diagram tříd mohou pomoci objasnit vztahy mezi většinu těchto termínů.Vytváření diagramů a glosář nejen snižuje nedorozuměním mezi uživateli a vývojáři, ale také téměř vždy poskytuje nedorozuměním mezi zúčastněnými stranami podniková.
Obchodní pravidla.Mnoho obchodních pravidel lze vyjádřit jako invariantní omezení na sdružení a atributů v modelu požadavky třídy a jako omezení u sekvenční diagramy.
Návrhu vysoké úrovně.Popisuje hlavní části a o sobě.Součást sekvence a rozhraní diagramy jsou hlavní část návrhu vysoké úrovně.
Návrhové vzory.Popis pravidel návrhu, které jsou sdíleny v rámci různých částí systému.
Testování specifikace.Test skripty a návrhy pro testovací kód mohl využít dobré činnosti a sekvence diagramy k popisu sekvence kroků testu.Testy systému by měly být vyjádřeny ve smyslu požadavků modelu tak, že je lze snadno měnit při změně požadavky.
Plán projektu.Plán projektu nebo nevyřízené položky definuje, kdy budou doručeny jednotlivé funkce.Můžete definovat jednotlivé funkce uvádí, co použít případy a obchodní pravidla, která implementuje, a rozšiřuje.Buď může odkazovat 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ů v plánování iterace

Ačkoli všechny projekty se liší v jejich rozsahu a organizace, typické projektu je plánováno jako série iterace mezi dva až šest týdnů.Je důležité naplánovat dostatek iterací, chcete-li povolit zpětné vazby z rané iterací, chcete-li použít ke změně oboru a plány pro vyšší počet iterací.

Mohou být užitečné následující návrhy pomoci poznali výhody modelování v iterační projektu.

Zostření fokus jako každé iteraci přístupy

Blíží každé iteraci pomocí modelů definovat, co má být dodána na konci iterace.

Model není vše podrobně v raném iterací.V první iteraci vytvořit diagram tříd pro hlavní položky uživatelského glosáře, nakreslete diagram případů použití hlavních a nakreslete schéma hlavní součásti.Popisují tyto jemné podrobně, protože detaily se změní v projektu.Chcete-li vytvořit seznam funkcí nebo hlavní uživatelské články pomocí podmínky definované v tomto modelu.Přiřazení funkcí iterací tak, aby přibližně vyrovnat předpokládané zatížení v celém projektu.Tato přiřazení se změní v projektu.
Došlo k pokusu o provedení zjednodušená verze všech nejdůležitějších případy použití v raném opakování.Rozšířit ty případy použití v novější iterací.Tento přístup snižuje riziko zjištění chyba požadavky nebo architektura příliš pozdě v projektu nic dělat jej.
Téměř na konci každé iteraci držte dílny požadavky podrobně definovat požadavky nebo s příběhy uživatelů, které budou vyvinuty v další iteraci.Pozvěte uživatele a obchodní účastníků, kteří se mohou rozhodnout, priority, jakož i vývojáři a testeři systému.Umožňuje definovat požadavky na dvoutýdenní iterace po dobu tří hodin.
Cílem semináře je všem dohodnout, co bude dosaženo do konce roku další iterace.Pomocí modelů jako jeden z nástrojů vyjasnit požadavky.Výstup semináře je nevyřízených položek iterací: to znamená seznam vývojové úkoly v Team Foundation a testovací sady v Microsoft Test Manager.
Workshop požadavky projedná návrh jen tehdy, pokud je nutné určit odhady pro vývojářské úlohy.Jinak vést diskusi k chování systému, který uživatelé mohou zaznamenat přímo.Požadavky na model oddělte od Architektonický model.
Pro běžné uživatele zúčastněné strany mají obvykle žádné problémy s principy diagramů UML, přičemž některé pokyny od vás.

Odkaz modelu do pracovní položky

Po dílny požadavky vypracovala podrobnosti o modelu požadavků a propojení modelu vývojářské úlohy.Toho dosáhnete propojením pracovních položek v Team Foundation na prvky modelu.Chcete-li zjistit, jak to provést, naleznete v Propojení prvků modelu a pracovních položek.

Můžete připojit libovolný prvek pracovní položky, ale jsou velmi užitečné prvky takto:

Případy použití.Propojíte-li případ použití vývojářské úlohy, které provede.
Pomocí rozšíření případu.Pokud pouze jeden aspekt případu použití bude implementován v iteraci, můžete je rozdělte do případu základní použití spolu s jedním nebo více přípon.Případy použití propojen základní případem "rozšířit" vztahu jsou rozšíření.Další informace o rozšíření případu použití, viz Diagramy případů použití UML: Referenční dokumentace.
Komentář popisující obchodní pravidla nebo jakostních požadavků na služby.Další informace naleznete v tématu Modelování uživatelských požadavků.

Model odkaz na zkoušky

Pomocí modelu požadavky návrhu přejímacích zkoušek.Vytvořte tyto testy souběžně s vývojové práce.

Další informace o této techniky, naleznete v Vývoj testů z modelu.

Odhad zbývající práce

Požadavky na model může pomoci odhadnout celkovou velikost projektu ve vztahu k velikosti každé iteraci.Stanovení počtu a složitosti případy použití a třídy vám pomohou při odhadu vývojové práce, které budou požadovány.Při dokončili první několik iterací, porovnání požadavků, které se vztahují požadavky stále ke krytí můžete umožňují přibližné míra nákladů a oblast působnosti zbytek projektu.

Téměř na konci každé iteraci zkontrolujte přiřazení požadavky na budoucí iterací.Může být užitečné ke znázornění stavu software na konci každé iteraci jako podsystém v diagramu případu použití.V diskusích můžete přesunout případy použití a používat velká rozšíření z jedné z těchto subsystémů do druhého.

Úroveň abstrakce

Modely mají rozsah abstrakce ve vztahu k softwaru.Nejvíce konkrétních modelů přímo představují programový kód a nejvíce abstraktní modely představují obchodní principy, které mohou nebo nemusí být zastoupeny v kódu.

Model lze zobrazit pomocí několika druhů diagramů.Informace o modelech a diagramy, viz Vývoj modelů pro návrh softwaru.

Různé druhy diagramu jsou užitečné pro popis návrhu na různé úrovni abstrakce.Mnoho typů diagramů jsou užitečné při více než jednu úroveň.Tato tabulka zobrazuje, jak lze každý typ diagramu.

Úroveň návrhu	Typy diagramů
Obchodní proces Principy kontext, ve kterém bude použit systém pomáhá pochopit, uživatelé potřebují z něj.	Diagram činnosti popisují tok práce mezi lidmi a systémy pro dosažení obchodních cílů. Třídy konceptuální diagramy popisují koncepty business, které jsou používané v rámci obchodních procesů.
Požadavky uživatelů Definice uživatelé potřebují ze systému.	Diagramy případu použití shrnout interakce, které uživatelé a další externí systémy mají systém, který vyvíjíte.Pro každý případ použití popisující podrobně lze připojit další dokumenty. Diagramy tříd jazyka UML jsou popsány typy informací, které uživatele a systému komunikovat o. Obchodní pravidla a jakostní požadavky služby mohou být popsány v samostatných dokumentech.
Vysoká úroveň návrhu Celková struktura systému: hlavní součásti a jak se spojit dohromady.	Diagramy vrstvy popisu struktury systému do vzájemně závislých částí.Můžete ověřit kód programu proti diagramech vrstev, aby bylo zajištěno, že dodržuje architektury. Diagramy komponent zobrazit rozhraní částí zpráv a služby, které jsou k dispozici a vyžadované všemi součástmi. Sekvenční diagramy zobrazit způsob komunikace komponent k provedení každého případu použití. Diagramy tříd jazyka UML popisují rozhraní komponenty a typy dat předávaných mezi součástmi.
Návrhové vzory Konvence a postupů pro řešení problémů s návrhem, které se používají ve všech částech návrhu	Diagramy tříd jazyka UML popisu struktury vzorek Sekvence nebo aktivity diagramy zobrazují interakce a algoritmy
Analýza kódu Několik typů diagramu lze vygenerovat z kódu.	Sekvenční diagramy zobrazit interakce mezi objekty v kódu. Diagramy vrstvy zobrazit závislosti mezi třídami.Aktualizovaným kódem může být ověřena diagramu vrstvy. Diagramy tříd zobrazit třídy v kódu.

Externí zdroje

Kategorie	Odkazy
Videa
Fóra	Visual Studio vizualizace & Modelování nástroje Visual Studio vizualizace & Modelování SDK (DSL nástroje)
Blogy	Visual Studio ALM + Team Foundation Server blogu
Technické články a deníky	Deník architektura - problém 23: Modelování architektury a procesy
Jiné weby	Středisko MSDN architektura Pokyny k nástrojům architektury Visual Studio