Architektura systému Software pro modelování

Článek
03/04/2013

Chcete-li zajistit, aby software systému nebo aplikace vyhovuje potřebám uživatelů, můžete vytvořit modely v Visual Studio Ultimate jako součást popisu celkové struktury a chování softwaru systému nebo aplikace.Pomocí modelů, lze také popsat vzorky, které se používají v celém návrhu.Tyto modely vám pomůže pochopit stávající architektury, diskutovat o změnách a jasně komunikovat vaše záměry.

Účelem modelu je snížit nejasnosti, které se vyskytují v přirozeném jazyce popisy a vám i vašim kolegům vizualizace návrhu a diskutovat o alternativních návrhů.Model je třeba používat společně s jinými dokumenty nebo diskuse.Sama o sobě nepředstavuje model úplnou specifikaci architektury.

[!POZNÁMKA]

"Systémem" se rozumí celé toto téma software, který vyvíjíte.Může to být velké kolekce mnoho softwarových a hardwarových komponent, nebo jedna aplikace nebo součást aplikace.

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

Podrobný návrh.Popisuje hlavní součásti a jejich interakce s sebou ke splnění jednotlivých požadavků.V případě, že systém je velký, každá součást může mít vlastní vysoké úrovni návrhu, který ukazuje, jak se skládá z menších součástí.
Vzory návrhu a konvence použité v celém návrhy komponent.Vzor popisuje zvláštní přístup k dosažení programových cílů.Pomocí stejné vzory v celém návrhu vašeho týmu lze snížit náklady na změnách a vývoji nového softwaru.

Návrhu vysoké úrovně

Podrobný návrh popisuje hlavní součásti systému a způsobu jejich vzájemnou interakci k dosažení cílů návrhu.Aktivity v následujícím seznamu se účastní rozvoj vysokého design, i když ne nutně v určitém pořadí.

Pokud aktualizujete existující kód, může začít popsáním hlavní součásti.Přesvědčte se, zda pochopit změny požadavků uživatelů a potom přidáte nebo změníte interakce mezi součástmi.Pokud vyvíjíte nový systém, začněte vysvětlení hlavních funkcí potřebám uživatelů.Potom prozkoumat sekvence interakcí pro případy použití hlavních a potom slučte sekvence do návrhové součásti.

V každém případě je vhodné rozvíjet různé činnosti, paralelně a vyvinout kód a testuje v raném stadiu.Vyhněte se při pokusu o proveďte jeden z těchto hledisek před zahájením druhého.Obvykle požadavky a vaše znalosti o nejlepší způsob, jak navrhnout systém se změní při psaní a testování kódu.Proto by měl začít Pochopením a kódování hlavní charakteristické znaky požadavků a návrhu.Vyplňte údaje v pozdější iterací projektu.

Principy požadavky.Výchozí bod všech návrhů je jednoznačné pochopení potřeb uživatelů.
Architektonické vzorky.Volby provedené o základních technologiích a architektonické prvky systému.
Součásti a jejich rozhraní.Můžete kreslit diagramy komponent, chcete-li zobrazit větší část systému a zobrazí rozhraní, přes které se vzájemně ovlivňují.Rozhraní každé součásti obsahují všechny zprávy, které jste určili v sekvenční diagramy.
Interakce mezi komponentami.Pro každý případ použití, událost nebo příchozí zprávy můžete nakreslit sekvenční diagram zobrazující interakci hlavní součásti systému pro dosažení požadované odpovědi.
Datový Model komponentami a rozhraními.Můžete kreslit diagramy tříd pro tytéž informace, které je předáno mezi komponentami a uloženy uvnitř komponenty.

Principy požadavky

Podrobný návrh kompletní aplikaci je co nejefektivněji vyvinut spolu s požadavky modelu nebo jiný popis potřebám uživatelů.Další informace o modelech požadavky, viz Modelování požadavků uživatelů.

Je-li systém, který vyvíjíte je součástí většího systému, může být část nebo všechny vaše požadavky shrnuta v programového rozhraní.

Požadavky na model poskytuje tyto základní druhy údajů:

K dispozici rozhraní.Zadané rozhraní zobrazí seznam služeb nebo operací, které systém nebo komponenta musí poskytnout svým uživatelům ať už jde o lidské uživatele nebo další softwarové komponenty.
Požadovaná rozhraní.Požadované rozhraní zobrazí seznam služeb nebo operací, které mohou používat systém nebo komponenty.V některých případech budete moci navrhovat všechny tyto služby jako součást vlastního systému.V ostatních případech zejména v případě, že navrhujete komponenty, které mohou být kombinovány s dalšími komponentami v mnoha konfiguracích požadované rozhraní bude nastavena externí určována.
Jakostní požadavky na služby.Výkon, zabezpečení, odolnost a jiné cíle a omezení, které musí splňovat systému.

Model požadavky zapsána z hlediska uživatelů vašeho systému, ať už jde o osoby nebo další softwarové komponenty.Znají nic vnitřní činnost systému.Naopak v Architektonický model je k popisu vnitřního fungování a zobrazit, jak splňují uživatelů potřebuje.

Udržování samostatných požadavky a architektonické modely je užitečné, protože to usnadňuje Projednejte požadavky pro uživatele.Také pomáhá Refaktorovat návrhu a zvažte alternativní architekturou, při zachování požadavků beze změny.

Požadavky a architektonické modely lze oddělit dva alternativní způsoby:

Zachovat je ve stejném řešení, ale různé projekty.Objeví se jako samostatné modely v Průzkumníku modelů UML.Členové jiného týmu mohou pracovat souběžně na modelech.Omezené typy trasování lze vytvořit mezi modely.
Umístěte je ve stejném modelu UML, ale v různých balíčcích.To usnadňuje sledování závislostí mezi modely, ale zabrání více osob současně pracovat na modelu.Navíc velmi velké modelu bude déle načítat do aplikace Visual Studio.Tento přístup je tedy méně vhodný pro velké projekty.

Množství podrobností, které byste měli umístit do požadavky nebo Architektonický model závisí na rozsahu projektu a velikost a rozdělení týmu.Malý tým na krátké projektu by se mohly dostat dále než Navrhněte diagram tříd obchodní principy a některé návrhové vzory; velký projekt rozloženy na více než jedné oblasti by bylo nutné podstatně více podrobností.

Architektonické vzorky

V rané fázi vývoje je třeba zvolit hlavní technologií a prvky, na kterých závisí návrhu.Oblasti, ve kterých se musí provádět tyto možnosti patří následující:

Základní výběr technologie, jako je například možnost volby mezi databáze a systém souborů a volba mezi síťové aplikace a webového klienta a tak dále.
Volby rámců, jako je například možnost volby mezi Windows Workflow Foundation nebo rozhraní ADO.NET Entity Framework.
Možnosti integrace metodou například mezi enterprise service bus nebo kanál typu point-to-point.

Tyto volby jsou často stanoví jakostní požadavky na služby jako měřítko a flexibilitu a lze provést před podrobné požadavky jsou známy.Velké sady jsou silně vzájemně souvisejících konfigurace hardwaru a softwaru.

Volby, které byly vliv na způsob používání a interpretovat Architektonický model.Například v systému, který používá databázi, přidružení v diagramu třídy může představovat vztahy nebo cizí klíče v databázi, že v systému, který je založený na souborech XML, sdružení může znamenat křížových odkazů, které pomocí jazyka XPath.V distribuovaném systému může představovat zprávy v sekvenčním diagramu zprávy na drát; samostatná aplikace představují volání funkce.

Součásti a jejich rozhraní

Hlavní doporučení v této části jsou následující:

Vytvořte diagramy komponent, chcete-li zobrazit větší část systému.
Nakreslete závislosti mezi součásti a jejich rozhraní zobrazit strukturu systému.
Chcete-li zobrazit služby, že každá součást poskytuje nebo vyžaduje pomocí rozhraní na součásti.
Ve velkých návrhu můžete kreslit samostatné diagramy rozložit jednotlivé součásti na menší části.

Tyto body jsou podrobně uvedeno v zbývající části tohoto oddílu.

Komponenty

Centrální zobrazení Architektura modelu jsou diagramy komponent zobrazující hlavní částí systému a jak jsou závislé na sobě.Další informace o diagramy komponent naleznete v tématu Diagramy komponent UML: odkaz.

Zobrazení diagramu UML součásti

Diagram komponent typické pro velké systém může obsahovat součásti, například tyto:

Prezentace.Součást, která poskytuje přístup uživateli, obvykle používají ve webovém prohlížeči.
Součásti webové služby.Poskytuje připojení mezi klienty a servery.
Používejte velká řadiče.Chování uživatele provede kroky pro každý scénář.
Základní obchodní.Obsahuje třídy, které jsou založeny na třídách v modelu požadavky, implementuje klíčové operace a ukládá obchodní omezení.
Databáze.Ukládá obchodních objektů.
Protokolování a komponenty pro zpracování chyb.

Závislosti mezi komponentami

Kromě součásti sami můžete zobrazit závislosti mezi nimi.Šipky závislostí mezi dvě součásti ukazuje, že změny v návrhu jednoho by mohly ovlivnit podobu druhé.To je obvykle způsobeno jedna komponenta používá služby nebo funkce, které jsou k dispozici komponentou jiných přímo nebo nepřímo.

Strukturované architektura má jasné uspořádání závislosti, ve kterých jsou splněny tyto podmínky:

Graf závislosti neobsahuje žádné smyčky.
Komponenty lze uspořádat do vrstev, ve kterých každý závislost přechází z komponenty v jedné vrstvě na komponentu v dalším.Všechny závislosti mezi libovolných dvou vrstev přejít ve stejném směru.

Můžete zobrazit závislosti přímo mezi komponentami nebo můžete zobrazit závislosti mezi potřebné a rozhraní, které jsou připojeny k součásti k dispozici.Pomocí rozhraní můžete definovat, jaké operace jsou používány v každé závislost.Závislosti jsou obvykle zobrazeny mezi komponent jsou diagramy nejprve nakreslené a nahrazuje jak přidány další informace o závislosti mezi rozhraními.Obě verze jsou správný popis software, ale verze rozhraní poskytuje více detailů než předchozí verze.

Správa závislostí je nejdůležitější pro výrobu údržba softwaru.Diagramy komponent by měl odrážet všechny závislosti ve vašem kódu.Pokud kód již existuje, ujistěte se, že všechny závislosti jsou zobrazeny v diagramech.Kód je vyvíjen, ujistěte se, že neobsahuje závislosti, které nejsou plánovány v diagramu komponent.Chcete-li zjistit závislosti v kódu, můžete vygenerovat diagramy vrstvy.Chcete-li zajistit, aby vaše plánované závislost omezení jsou splněny, je možné ověřit kód proti diagramech vrstev.Další informace naleznete v tématu Diagramy vrstvy: odkaz.

Rozhraní

Při umístění rozhraní komponenty, můžete oddělit a pojmenovat hlavní skupiny operací, které jsou k dispozici jednotlivých součástí.Součástí prodejního systému založeného na webu může mít například rozhraní, přes který zákazníci nakupují zboží, rozhraní, přes který dodavatelů aktualizovat jejich katalogy a třetí rozhraní přes systém spravován.

Komponenta může mít libovolný počet zadaný a požadované rozhraní.K dispozici rozhraní zobrazit služby, které poskytuje součásti pro použití dalších součástí.Požadovaná rozhraní zobrazit v ostatních součástech služby, které používá komponentu.

Definujete-li oba a požadovaná rozhraní to umožňuje oddělit součásti čistě ze zbývající části návrhu, tak, aby tyto techniky můžete použít:

Umístěte komponentu do testu kabelového svazku, ve kterém jsou okolní součásti simulují kabelového svazku test.
Vývoji dané komponenty nezávisle na ostatních součástí.
Znovu použít komponentu v jiných kontextech spojovacího jeho rozhraní na jiné komponenty.

Pokud chcete definovat seznam operací v rozhraní, můžete vytvořit další zobrazení rozhraní na diagram tříd UML.Chcete-li to provést, vyhledejte rozhraní Průzkumníka modelů UML a přetáhněte jej do diagramu třídy.Potom můžete přidat operace rozhraní.

Operace v rozhraní UML může představovat jakýmkoli způsobem, ve kterém lze vyvolat chování komponenty.To může představovat požadavek webové služby, signálu nebo působení určitého druhu nebo bude voláním funkce normální program.

Chcete-li zjistit, jaké operace přidání, vytvoření sekvenční diagramy, chcete-li zobrazit, jak vzájemnou interakci komponent.Viz interakce mezi komponentami.Každý z těchto sekvenční diagramy zobrazuje interakcí, ke kterým dochází v případě jiného použití.Tímto způsobem můžete postupně přidat do seznamu operací v jednotlivých komponent rozhraní, jak prozkoumat případy použití.

Decomposing komponentu do částí

Můžete použít postup popsaný v předchozích částech každou komponentu.

V rámci jednotlivých komponent můžete zobrazit její dílčí součásti jako části.Součástí je účinně atribut nadřazené komponenty, což je druh třídy.Každá část má svůj vlastní typ, který může být součástí.Můžete umístit tuto součást v diagramu a zobrazit jeho částí.Další informace naleznete v tématu Diagramy komponent UML: pokyny.

Je užitečné, chcete-li použít tuto techniku pro celý systém.Nakreslit jako samostatné součástky a zobrazit jeho hlavní součásti jako díly.Díky tomu můžete jasně identifikovat rozhraní systému s vnějšího světa.

Při návrhu pro komponenty používá jiná součást, máte často na výběr o tom, zda se k reprezentaci, jako součást nebo jako samostatnou součást, která můžete přistupovat prostřednictvím rozhraní vyžaduje.

Části použijte v následujících situacích:

Návrh nadřazená komponenta musí vždy použít typ součásti na straně.Konstrukční části je proto nedílnou součástí návrhu nadřazené komponenty.
Nadřazená komponenta má žádné konkrétní existence své vlastní.Například můžete mít koncepční komponenty s názvem prezentace vrstvy, která představuje kolekci skutečné komponenty, které zpracování zobrazení a uživatelskou interakci.

Použití jednotlivých součástí, které jsou přístupné prostřednictvím požadovaná rozhraní v těchto situacích:

Vyžadující komponenta může být spojen prostřednictvím svých rozhraních různých komponent poskytuje za běhu.
Návrh je taková, že by bylo snadné jeden zprostředkovatel nahradit jiným.

Použití požadované rozhraní je obvykle vhodnější použití dílů.Ačkoli návrh může trvat déle, je výsledný systém pružnější.Je také jednodušší test komponent odděleně.To umožňuje méně působící ve svých plánech rozvoje.

Interakce mezi komponentami

Hlavní doporučení v této části jsou následující:

Identifikujte případy použití systému.
Pro každý případ použití kreslení jeden nebo více diagramů, chcete-li zobrazit, jak součástí systému dosažení požadovaných výsledků při spolupráci s sebou a s uživateli.Obvykle se jedná, sekvenční diagramy nebo diagramy činnosti.
Rozhraní slouží k zadání zprávy přijímány jednotlivé komponenty.
Popište účinky operace v rozhraní.
Proceduru opakujte pro každou komponentu, ukazující, jak se vzájemně ovlivňují jeho částí.

Například v web-based prodejní systém model požadavky definovat nákupní zákazníka jako případ použití.Můžete vytvořit sekvenční diagram interakcí zobrazit, zda má zákazník s těmito komponentami v prezentační vrstvě a prokázat interakcí s skladu a součástí účetnictví.

Identifikace zahajující události

Práce většiny softwarových systémů lze pohodlně rozdělit podle odpovědi, které dává různé vstupy nebo události.Zahajující událost může být jedna z následujících událostí:

První akce v případu použití.V modelu požadavků se může zobrazovat jako krok v případě použití nebo akce v diagramu činnosti.Další informace Diagramy případu použití UML: pokyny a Diagramy činnosti UML: pokyny.
Zpráva na programové rozhraní.Je-li systém, který vyvíjíte je součástí většího systému, by měl být popsán jako operace v jednom z rozhraní komponenty.Viz součásti a jejich rozhraní.
Určitá podmínka, která je sledována funkcí systému nebo pravidelnou událost, jako je například denní dobu.

Popis příslušné výpočty

Nakreslete sekvenční diagramy, chcete-li zobrazit, jak reagovat na počáteční událost komponenty.

Nakreslete životnost pro každou instanci komponenty, která je součástí typické posloupnosti.V některých případech může být více než jednu instanci každého typu.Pokud je popsán celý systém jako samostatné součástky by měl být jeden životnost pro jednotlivé části, které obsahuje.

Další informace naleznete v tématu Sekvenční diagramy UML: pokyny.

Diagram činnosti jsou také užitečné v některých případech.Například pokud vaše komponenty souvislý tok dat, můžete popsat jej jako obrazec Tok objektů.Pokud vaše komponenta složitým algoritmem, můžete ji popsat jako tok řízení.Přesvědčte se, zda být zřejmé, které provádí součást každé akce, například pomocí komentáře.Další informace naleznete v tématu Diagramy činnosti UML: pokyny.

Operace

Diagramy zobrazit operace, které provádí každá komponenta zastoupených buď jako zpráv v sekvenčním diagramu nebo akce v diagramu činnosti.

Shromážděte tyto operace společně pro jednotlivé součásti.Vytvoření rozhraní k dispozici na součásti a přidat operace rozhraní.Oddělené rozhraní se obvykle používá pro každý typ klienta.Operace se nejlépe do rozhraní v Průzkumníka modelů UML.Stejným způsobem shromažďovat operací, které používá každá součást z jiných komponent a umístit je do požadované rozhraní, připojené ke komponentě.

Je užitečné pro přidávání poznámek do diagramů aktivity nebo sekvenci, Všimněte si, co bylo dosaženo po každé operaci.Můžete také napsat účinek každé operace v jeho Místní koncová podmínka vlastnost.

Datový Model komponentami a rozhraními

Definovat parametry a návratové hodnoty každé operace v rozhraní komponenty.Kde operace představují vyvolání například žádostí webové služby, parametry jsou kusy informací, které jsou odesílány jako část žádosti.V případě, že několik hodnot jsou vráceny z operace, můžete použít parametry se směr vlastnost nastavena na hodnotu podle.

Každý parametr a vrací hodnoty s typem.Můžete definovat tyto typy použití diagramy tříd jazyka UML.Není třeba představovat implementační detail v těchto diagramech.Například pokud popisujete data, která jsou přenášena ve formátu XML, můžete pomocí přidružení představující libovolný druh křížový odkaz mezi uzly XML a použít třídy představující uzlů.

Komentáře lze použít k popisu omezení obchodních sdružení a atributy.Například pokud všechno zboží v objednávce zákazníka musí pocházet od stejného dodavatele, můžete popsat to odkazem na přidružení mezi položky objednávky a zboží v katalogu produktů a mezi položky katalogu a jeho dodavateli.

Návrhové vzory

Návrhový vzor je přehled toho, jak navrhnout jednotlivé aspekty softwaru, zvláště jeden, který se opakuje v různých částech systému.Přijetím jednotného přístupu přes projektu snížit náklady návrhu, zajistit konzistenci v uživatelském rozhraní a snížit náklady na pochopení a změna kódu.

Některé obecné návrhové vzory jako pozorovatel jsou dobře známé a široce použitelné.Kromě toho jsou vzorky, které se vztahují pouze na projektu.Například v systému prodeje Web, bude několik operací v kódu kde změny objednávky zákazníka.K zajištění, že stav objednávky je přesně zobrazen v každém stadiu, musí všechny tyto operace podle konkrétní protokol k aktualizaci databáze.

Část práce architektura softwaru je zjistit, jaké vzorky by měly být přijaty v návrhu.Obvykle se jedná průběžný úkol, protože nové vzorky a vylepšení stávajících vzorky budou zjištěny v průběhu projektu.Je vhodné uspořádat plán rozvoje tak, aby každé z hlavních návrhové vzory vykonávat v raném stadiu.

Většina vzorů návrhu lze částečně vyhlášenými v rámci kódu.Část vzorku může být snížena na nutnosti vývojáři mohou používat určité třídy nebo součásti, například vrstvu přístupu k databázi, která zajišťuje, že databáze je správně zpracovat.

Návrhový vzor je popsána v dokumentu a obvykle obsahuje následující části:

Název
Popis kontextu, ve kterém je použitelná.Jaká kritéria by měla vytvořit vývojář uvažovat o instalaci tohoto vzoru?
Stručný popis problému, který je vyřešen.
Model hlavní částí a jejich vztahy.Může se jednat o třídy nebo komponentami a rozhraními, sdružení a závislosti mezi nimi.Prvky se obvykle dělí na dvě kategorie:
- Prvky, které vývojář musí replikovat v každé části kódu, kde se používá vzorek.Typy šablon lze použít k popisu těchto.Další informace naleznete v tématu Diagramy případu použití UML: odkaz.
- Prvky s popisem framework třídy, které by měl vývojář použít.
Model interakce mezi částmi, pomocí sekvence nebo aktivity diagramy.
Zásady vytváření názvů.
Popis jak vzorek vyřešen.
Popis varianty, které vývojáři mohou být schopny přijmout.