Sdílet prostřednictvím


Modelování architektury aplikace

Chcete-li zajistit, aby váš softwarový systém nebo aplikace splňovaly potřeby uživatelů, můžete v sadě Visual Studio vytvářet modely jako součást popisu celkové struktury a chování softwarového systému nebo aplikace. Pomocí modelů můžete také popsat vzory, které se používají v celém návrhu. Tyto modely vám pomůžou porozumět stávající architektuře, diskutovat o změnách a jasně informovat o vašich záměrech.

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í.

Účelem modelu je snížit nejednoznačnosti, ke kterým dochází v popisech přirozeného jazyka, a pomoci vám a vašim kolegům vizualizovat návrh a diskutovat o alternativních návrzích. Model by se měl používat společně s dalšími dokumenty nebo diskuzemi. Model sám o sobě nepředstavuje úplnou specifikaci architektury.

Poznámka:

V tomto tématu "systém" znamená software, který vyvíjíte. Může se jednat o velkou kolekci mnoha softwarových a hardwarových komponent, nebo o jednu aplikaci nebo o část aplikace.

Architekturu systému lze rozdělit do dvou oblastí:

  • Návrh vysoké úrovně. Popisuje hlavní komponenty a jejich interakci s ostatními, aby splnily jednotlivé požadavky. Pokud je systém velký, může mít každá komponenta svůj vlastní návrh vysoké úrovně, který ukazuje, jak se skládá z menších komponent.

  • Vzory a konvence návrhu používané v rámci návrhů komponent. Model popisuje konkrétní přístup k dosažení programovacího cíle. Díky použití stejných vzorů v celém návrhu může váš tým snížit náklady na provádění změn a vývoj nového softwaru.

Návrh vysoké úrovně

Návrh vysoké úrovně popisuje hlavní komponenty systému a jejich interakci s ostatními, aby dosáhli cílů návrhu. Aktivity v následujícím seznamu jsou zapojeny do vývoje návrhu vysoké úrovně, i když nemusí nutně v určité sekvenci.

Pokud aktualizujete existující kód, můžete začít popisem hlavních komponent. Ujistěte se, že rozumíte všem změnám uživatelských požadavků, a pak přidejte nebo upravte interakce mezi komponentami. Pokud vyvíjíte nový systém, začněte pochopením hlavních funkcí potřeb uživatelů. Pak můžete prozkoumat posloupnosti interakcí pro hlavní případy použití a potom sloučit sekvence do návrhu komponenty.

V každém případě je užitečné vyvíjet různé aktivity paralelně a vyvíjet kód a testy v rané fázi. Než začnete s jiným, snažte se některé z těchto aspektů dokončit. Při psaní a testování kódu se obvykle mění požadavky i pochopení nejlepšího způsobu návrhu systému. Proto byste měli začít pochopením a kódováním hlavních funkcí požadavků a návrhu. Vyplňte podrobnosti v pozdějších iteracích projektu.

  • Vysvětlení požadavků Výchozím bodem jakéhokoli návrhu je jasné pochopení potřeb uživatelů.

  • Architektonické vzory Volby týkající se základních technologií a architektonických prvků systému.

  • Datový model komponent a rozhraní Můžete nakreslit diagramy tříd, které popisují informace předávané mezi komponentami a uložené uvnitř komponent.

Vysvětlení požadavků

Návrh kompletní aplikace na vysoké úrovni je nejvýkonněji vyvinut společně s modelem požadavků nebo jiným popisem potřeb uživatelů. Další informace o modelech požadavků najdete v tématu Požadavky na uživatele modelu.

Pokud je systém, který vyvíjíte, součástí většího systému, část nebo všechny požadavky vtělené do programových rozhraní.

Model požadavků poskytuje tyto základní informace:

  • Poskytnutá rozhraní. Zadané rozhraní uvádí služby nebo operace, které musí systém nebo komponenta poskytnout svým uživatelům, ať už jsou to uživatelé lidské nebo jiné softwarové komponenty.

  • Požadovaná rozhraní. Požadované rozhraní obsahuje seznam služeb nebo operací, které může systém nebo komponenta používat. V některých případech budete moci navrhnout všechny tyto služby jako součást vlastního systému. V jiných případech, zejména pokud navrhujete komponentu, která se dá kombinovat s dalšími komponentami v mnoha konfiguracích, bude požadované rozhraní nastaveno externími aspekty.

  • Požadavky na kvalitu služeb. Výkon, zabezpečení, robustnost a další cíle a omezení, které musí systém splnit.

    Model požadavků je napsán z pohledu uživatelů systému, ať už jsou to lidé nebo jiné softwarové komponenty. Neví nic o vnitřních fungováních vašeho systému. Naproti tomu vaším cílem v modelu architektury je popsat interní pracovní postupy a ukázat, jak vyhovují potřebám uživatelů.

    Zachování požadavků a modelů architektury je užitečné, protože usnadňuje diskuzi o požadavcích s uživateli. Pomůže vám také refaktorovat návrh a zvážit alternativní architektury a zároveň zachovat požadavky beze změny.

    Množství podrobností, které byste měli vložit do požadavků nebo modelu architektury, závisí na rozsahu projektu a velikosti a distribuci týmu. Malý tým na krátkém projektu nemusí jít dál než načrtnout diagram tříd obchodních konceptů a některých vzorů návrhu; Velký projekt distribuovaný ve více než jedné oblasti by potřeboval výrazně více podrobností.

Architekturální vzory

V rané fázi vývoje musíte zvolit hlavní technologie a prvky, na kterých návrh závisí. Mezi oblasti, ve kterých musí být tyto volby provedeny, patří:

  • Základní technologické volby, jako je volba mezi databází a systémem souborů, a volba mezi síťovou aplikací a webovým klientem atd.

  • Volby rozhraní, jako je volba mezi Windows Workflow Foundation nebo ADO.NET Entity Framework.

  • Možnosti metod integrace, například mezi podnikovou sběrnici service bus nebo kanálem typu point-to-point.

    Tyto volby se často určují podle požadavků na kvalitu služeb, jako je škálování a flexibilita, a je možné je provést před známými podrobnými požadavky. Ve velkém systému je konfigurace hardwaru a softwaru silně propojená.

    Výběry, které provedete, ovlivňují způsob použití a interpretaci modelu architektury. Například v systému, který používá databázi, můžou přidružení v diagramu tříd představovat vztahy nebo cizí klíče v databázi, zatímco v systému založeném na souborech XML můžou přidružení znamenat křížové odkazy, které používají XPath. V distribuovaném systému můžou zprávy v sekvenčním diagramu představovat zprávy na drátě; v samostatné aplikaci mohou představovat volání funkce.

Způsoby návrhu

Vzor návrhu je osnova návrhu konkrétního aspektu softwaru, zejména ten, který se opakuje v různých částech systému. Přijetím jednotného přístupu v rámci projektu můžete snížit náklady na návrh, zajistit konzistenci v uživatelském rozhraní a snížit náklady na pochopení a změnu kódu.

Některé obecné vzory návrhu, jako je pozorovatel, jsou dobře známé a široce použitelné. Kromě toho existují vzory, které platí jenom pro váš projekt. Například v systému webových prodejů bude v kódu několik operací, ve kterých se změny provádějí v objednávce zákazníka. Aby se zajistilo, že se stav objednávky přesně zobrazí v každé fázi, musí všechny tyto operace dodržovat konkrétní protokol pro aktualizaci databáze.

Součástí práce softwarové architektury je určení vzorů, které mají být přijaty v rámci návrhu. Obvykle se jedná o probíhající úkol, protože při pokroku projektu se zjistí nové vzory a vylepšení existujících vzorů. Je užitečné uspořádat plán vývoje tak, abyste si každou z hlavních vzorů návrhu v rané fázi procvičili.

Většina vzorů návrhu může být částečně ztělesněná v kódu architektury. Část modelu lze snížit tak, aby vývojář musel používat určité třídy nebo komponenty, jako je vrstva přístupu k databázi, která zajišťuje správné zpracování databáze.

Vzor návrhu je popsaný v dokumentu a obvykle zahrnuje tyto části:

  • Název.

  • Popis kontextu, ve kterém je použitelný. Jaká kritéria by měl vývojář zvážit použití tohoto modelu?

  • Stručné vysvětlení problému, který řeší.

  • Model hlavních částí a jejich vztahů Mohou to být třídy nebo komponenty a rozhraní s přidruženími a závislostmi mezi nimi. Prvky obvykle spadají do dvou kategorií:

  • Zásady vytváření názvů.

  • Popis způsobu řešení problému

  • Popis variant, které můžou vývojáři přijmout