Create a solution architecture

Součástí procesu vytváření dobré architektura zkoumá alternativní strategie architektury. Alternativní strategie mají různé výhody, které jsou založeny na výběr platformy, technologie, které se používají a znovu použít kód. Každé strategie je určen a obtahy koncept jsou vytvořeny tak podrobněji náklady a přínosy každé strategie. Vzhledem k požadavkům na kvalitu a produktů se hodnotí strategií a nakonec je vybrán strategii, který se má použít k implementaci produktu. Na závěr zabezpečení a výkon jsou architektury připomínky, pro které je nutné provést práce přes celý produkt.

V tomto tématu

• Vytvořit alternativní Architektura vytváření oddílů vzory

• Návrh systému architektura nasazení

• Vytvořit obtahy koncepce

• Hodnocení alternativy

• Vyberte architektury

• Vývoj výkonu modelu

Vytvořit alternativní Architektura vytváření oddílů vzory

Problém je analyzována a jsou považovány za různých přístupů. Skupina požadavky jsou vybráno, které představují klíčových obchodních a technických problémů. Zkontrolujte vlastnosti těchto výzev, jako například integrace starší verze systémů a předpovědi budoucích potřeb podle potřeb aktuální opětovné použití kódu a náklady na údržbu.

Vytvoření diagramu aplikace

Pomocí modelu domény a požadavky jako vstup, vytvořte diagramu aplikace, která představuje logické prvky jádro systému. To bude později rozděleny do diagramů systému. Alternativní schématy oddílů bude považován za a vyhodnotit.

Jeden ze způsobů představují diagramu aplikace je jako diagramu případu použití modelování UML (Unified Language). Tento typ schématu můžete zobrazit hlavních subsystémů a jejich závislosti. Kromě toho můžete umístit případy použití do každého subsystému, chcete-li zobrazit, které subsystém spravuje všechny uživatele scénáře.

Navázat kritéria hodnocení

Zjistěte, která kritéria použít k identifikaci požadavky a scénáře, které představují závažné architektury úkoly. Vyhledejte existující dokumenty architektury enterprise kritéria. Zkontrolujte všechny obchodních požadavcích, technické požadavky a enterprise standardy, které musí být použity pro nové aplikace. Zachycení další kritéria, které jsou známé jako architektonicky významný, jako například integrace s starší verze systémů opětovné použití kódu, opakovaného použití existující dodavatele knihovny a platformy a řídit náklady na údržbu. Zachycení další kritéria, které představují rizika a náklady při provádění technické řešení.

Vyberte skupinu Candidate požadavků

Vyzkoušejte každý kvalitu služeb požadavek a požadavek na produkt proti kritéria hodnocení. Pokud požadavek představuje výzvu architektury, zvažte jeho kandidáta pro modelování. Můžete například požadavek, že nový produkt musí podporovat starší databáze zákazníka splňuje kritéria integrace se systémy starší verze. Tento požadavek je kandidáta pro modelování, jak by integrace pracovat.

Vyberte skupinu Candidate scénářů

Vyzkoušejte každý scénář proti kritéria hodnocení. Pokud scénáře představuje výzvu architektury, zvažte jeho kandidáta pro modelování. Můžete například scénáře, ve kterém uživatel stáhne aktualizace klienta splňuje kritéria, která se týká náklady na údržbu. Tento případ je kandidátem pro modelování, jak nejlépe pro zpracování aktualizací klienta.

Snižte navrhovanou skupinu

Seznamte se s candidate scénáře a požadavky. Odeberte scénáře a požadavky, které duplicitní kritéria hodnocení nebo jsou lépe reprezentována jiná scénáře a požadavky. Trim navrhovanou skupinu ke skupině jádro, která představuje klíčové architektury výzvy, rizika a náklady na nové aplikace. Zachovat scénáře a požadavky, které nejlépe představují kritéria hodnocení, který poskytovat většina riziko, a který nejvíce potenciální náklady při architecting technické řešení. Zachovat scénáře a požadavky, které jsou části aplikace, které se nejvíce komplexní nebo klíče.

Vytvořit vytváření oddílů kritéria

Požadavky na používání jako pracovat, analýzy prokázanou vzory architektury (například fasády nebo model-view-controller) a identifikovat případné kandidáty pro implementaci. Identifikovat trendy candidate prostřednictvím jejich pracovat a zvažte, kompromisy jejich návrh pro párování, soudržnosti, rozšiřitelnost, přizpůsobivost a flexibilitu. Vyberte sadu kandidáty pro implementaci jako alternativy pro hodnocení.

Architektura systému návrhu a nasazení

Architektura systému definuje seskupení a konfigurace elementů, které jsou určeny v diagramu aplikace. Diagramy systému jsou vytvářeny, které zachytit architektura pro každý možný architektura přístup. Diagramy nasazení zobrazují nasazení kroky, které jsou založeny na závislosti a základní funkce. Návrhář infrastruktury vytvoří diagram logického datového centra, která popisuje logickou strukturu datacenter, kam bude aplikace nasazena. Diagramy nasazení jsou ověřovány oproti diagramu logického datového centra zajistit, aby systémy mohou být nasazeny.

Vytvoření modelu systému

Architekt a hlavní vývojář diagramy systému z diagramu aplikace. Pomocí diagramů systému můžete navrhnout systémů opakovaně použitelné aplikací jako jednotky nasazení vytváření jejich z elementů diagramu aplikace. Můžete také navrhnout větší a složitější systémy, které obsahují jiných systémů, aby mohli používat ve scénářích distribuovaného systému a abstraktní podrobné informace o aplikacích v těchto systémů. Vrátit se změnami každého nového souboru diagramu do správy verzí.

Může představovat diagramů systému v Visual Studio z následujících způsobů:

• Diagramy případu použití. Hlavní uživatelské scénáře jsou vyjádřena jako případy použití a hlavními komponentami systému jsou zobrazeny jako podsystémy. Každý případ použití může být umístěn v rámci subsystému, která zpracovává problémy s ním. Další informace naleznete v tématu Diagramy případů použití UML: Pokyny.

• Diagramy komponent UML. Tyto diagramy umožňují zobrazit komunikačních kanálů mezi součástmi, kromě závislostí. Můžete také vytvářet diagramy tříd popisující typy, které jsou viditelné v rozhraních pro komponenty a můžete vytvářet diagramy sekvence zobrazíte jejich interakce. Další informace naleznete v tématu Diagramy komponent UML: Pokyny, Diagramy tříd UML: Pokyny, a Sekvenční diagramy UML: Pokyny.

• Diagramy vrstev. Diagramu vrstev popisuje strukturu bloku aplikace. Zobrazuje pouze komponenty a jejich vzájemné závislosti. Má výhodu, že jakmile je zapsán kód, můžete ověřit kód a závislosti proti diagramu. Další informace naleznete v tématu Diagramy vrstev: Pokyny.

U každého subsystému můžete vytvořit balíček, který popisuje jeho typy a chování podrobněji. Další informace naleznete v tématu Definování balíčků a oborů názvů.

Vytvořit obtahy koncepce

Po vytvoření architektury ověření koncepce lze zmírnit významná rizika do projektu. Je důležité adresa riziko co nejdříve v projektu tak, aby klíčová rozhodnutí strategickému a architektury lze provést, pokud je stále snadno upravit základní softwarové součásti architektury. Vytváření early obtahy koncept snižuje celkového rizika projektu a neznámé prvky. Nižší rizika projektů a neznámých menšího počtu vzorků provést plánování a odhadování v novější iteracích přesnější. Obtahy koncept mohou být dočasné a zrušených poté, co byly problémy vyřešeny nebo mohou být vytvořeny jako základ Architektura jádra.

Zkontrolujte riziko

Pochopení elementy, které vést k určení rizika nebo architektury rozhodnutí. Zkontrolujte související scénáře a kvalitu požadavků na služby. Zkontrolujte, zda cílový důsledky prostředí.

Plán přístup

Určení formě doklad o konceptu, který je vyžadován. Pomocí diagramů aplikací a systému plánu. Pouze architektury identifikovanou identifikátorem riziko problém vyřešit. Vyhledejte nejjednodušší řešení.

Vytvoření a spuštění doklad o – koncepce

Vytvářejte ověření koncepce. Můžete používat ověření koncepce z diagramu aplikace. Udržujte se soustředí na problém vyřešit. Nasaďte ověření koncepce fyzické prostředí, které je shodný s diagram logického datového centra. Fyzický prostředí, by měl co nejvíce shoduje s nastavením diagram logického datového centra. Test ověření koncepce před rizikem vyhodnocené tímto problémy.

Hodnocení alternativy

Lightweight architektura alternativu analýzy metoda (LAAAM) se používá k určení mezi různé strategie architektury pro vytváření aplikací. LAAAM obvykle trvá jeden den k dokončení. Začněte vytvářet strom nástroj, který popisuje klíče kvality a funkční ovladače aplikace, které jsou založeny na požadavky. Každý ovladač zapisuje jako scénáře, který má formu příkaz, který je zapsán jako kontextu, podnětů a odpovědi. Hodnocení matice slouží k vyhodnocení, jak moc každé strategie řeší každý scénář.

Vytvoření utilita stromové struktury

Zkontrolujte kvalitu služeb požadavky a požadavky produktu k určení klíče ovladače kvality a funkce v aplikaci. Vytvořte strom nástroj, který představuje celkovou kvalitu aplikace. Kořenový uzel ve stromu, který je označeno nástroje. Následné uzly jsou obvykle označena jako standardní kvalitu podmínky, jako je například modifiability, dostupnost a zabezpečení. Stromu, který by měl představují hierarchické povahu vlastností a jako základ pro stanovení priorit. Každou úroveň ve stromu, který je další upřesnění vlastností. Nakonec tyto vlastnosti stát scénářů.

Vytvořit testu matice

Pro každou listu ve stromové struktuře nástroje zapisovat scénáře. Scénář je ve formuláři kontextu, podnětů a odpovědi (například "v rámci typické operaci provést databázových transakcí v milisekundách méně než 100").

Vytvořit tabulku nebo tabulky a zadejte jednotlivé scénáře jako řádek v této matici hodnocení. Zadejte každé strategie architektury jako sloupec. Na každý průnik strategií a scénáře zadejte hodnocení v rozsahu od 1 do 4.

Hodnocení měli vzít v úvahu následující faktory:

• Náklady na vývoj je toto řešení snadno nebo obtížné k implementaci? Co je jeho dopad na ostatní oblasti?

• Provozní náklady běhu, bude fungovat toto řešení snadno nebo negativně ovlivní to použitelnost, výkonu a tak dále?

• Riziko je toto řešení určité, chcete-li vyřešit scénář dobře nebo existují Neznámý nákladů? By mohly toto řešení mít negativní dopad na schopnost týmu budoucí rozšířeným v požadavcích?

Pokud ověření koncepce byla vytvořena pro strategii, použijte informace z tohoto ověření koncepce sloužící k určení hodnoty.

V dolní části tabulky součet hodnot z scénářů. Pomocí těchto údajů jako vstup do diskuse, který vede k rozhodnutí o alternativní architektur.

Nahrajte matice dokončeného testu k portálu projektu.

Vyberte architektury

Po vytvoření matice hodnocení kontrolní meeting směřuje k určení, které architektura má být použita v následující iteraci. Hodnocení matice a informace, které je zjištěno od vytvoření doklad o koncept se používá k lepšímu rozhodnutí. Poté, co architektury je vybrána, diagramy pro architekturu se změnami jako odkaz na řešení a dokument zarovnání do bloku je vytvořen, zaznamená důvody za výběr.

Příprava na revizi

Architekt a hlavní vývojář identifikovat příslušné recenzenty pro kontrolu navržené architektury a rozšiřovat dokumentace architektur každému z účastníků.

Přehled architektury systému a architektura nasazení

Během kontrolní schůzky, jsou zkontrolovány diagramy systému, nasazení sestavy a diagram logického datového centra. Cílem je zvolte architekturou implementovat v následující iteraci.

Zvažte hodnocení pořadím matice pro každou architekturu k vyhodnocení vhodnosti každou architekturu. Zvažte veškeré informace, které je zjištěno z doklad o koncept například náklady nebo složitost, která souvisí s různými architekturami implementace. Pokud diagram logického datového centra představuje existující datacenter, který nelze změnit, nikoli jeho revizi. Pokud je při vytváření datacentru, zkontrolujte diagramu pro požadavky na nasazení. Vyberte architektury, který se má použít. Prohlédněte si architektury koncept před případy k ověření, aby splňovaly potřeby zákazníků řešení a je dokončena.

Vytvořit odkaz na řešení

Vytvořte dokument zarovnání do bloku, který shromažďuje rozhodnutí shromáždění. Nahrajte jej k portálu projektu. Pro vybranou architekturu zkontrolujte jako odkaz na řešení pro implementaci funkcí v další iteraci v jakékoli aplikace, systém nebo diagramy logického datového centra. Sdělovat celý tým a všechny závislé týmy rozhodnutí o jaké architektury je vybrána pro následující iteraci.

Vývoj výkonu modelu

Modelování výkonu se používá k identifikaci a vyřešit případné problémy s výkonem v aplikaci. Je využity výkonu z kvalitu služeb požadavek, který je potom rozdělená do úkoly vývoje. Každý úkol vývoj je přiřazen výkonu rozpočtu pro implementaci.

Identifikujte scénáře, které jsou propojeny ke zvýšení kvality výkonu služby požadavku. Mapování úkoly vývoje pro scénáře. Z kvalitu požadavky na seznamu služeb určete pracovního vytížení pro danou aplikaci. Pomocí pracovního vytížení odhadne a kvalitu služeb požadavky na seznamu, identifikovat výkonnostní cíle pro jednotlivé klíčové scénáře. Mezi ně patří cíle, například čas, propustnost a zdroj použití odpovědi. Označte související s výkonem prostředky, které mají byla rozpočtu ke splnění výkonnostní cíle. Některé příklady související s výkonem materiály jsou čas spuštění a šířku pásma sítě. Určete maximální povolená přidělení jednotlivých zdrojů.

Rozložit kroky zpracování pro každý scénář rozpočtu prostředků. Pokud nejste si jisti, jak se má přidělit rozpočtu, proveďte nejlepší pokusů nebo rozdělit prostředky rovnoměrně mezi kroky. Řízení rozpočtu je kontrast během ověřování. Připojit nebo zapsat přidělení na příslušný vývoj úkolu.

Najděte přidělování rozpočtu, které představovat riziko k naplnění výkonnostní cíle. Zvažte, kompromisy, které pomáhají vyhovět výkonnostní cíle, například alternativy návrhu a nasazení. V případě potřeby, přehodnocovat kvalitu požadavků na služby.

Určete scénáře, které nesplňují přidělování rozpočtu. Měření výkonu scénářů. Použijte prototypů v rané iterací, pokud kód není k dispozici. Opakováním kroků řízení rozpočtu, hodnocení a ověření podle potřeby pomocí dat, který byl získán během ověřování.

Vývoj hrozby modelu

Další informace naleznete v tématu na následující stránce webu společnosti Microsoft: Security Developer Center.