Ръководство за инструменти за архитектура на Visual Studio

Visual Studio Ultimate ще ви помогне по пътя към успешното изграждане на нова система. Комбинация от инструменти на Unified Model Language (UML) и итеративен подход може да ви помогне постепенно:

Дефиниране на изискванията
Създайте слоеста архитектура с подходяща абстракция за обектно-ориентиран подход
Разработете потоци от контролни команди между компоненти и класове

Изискванията за нова система определят какво трябва да се разработи. Набор от изисквания ще ни помогне да дефинираме архитектурата на системата. Формата следва функцията. След като имаме формата или архитектурата на системата, можем да удовлетворим всяко от изискванията чрез изграждане на потоци между различни компоненти и класове.

Прозрачната архитектура е критична за система, която е мащабируема и лесна за поддръжка. Visual Studio Ultimate ви позволява да осветите архитектурата, така че всеки в екипа да може да види нейната елегантност. Това е критично за големи системи, но също толкова важно за проекти с един или двама души.

Нов работен процес на скрипт за създаване на система

Независимо дали вашият проект разработва трима души или триста, потокът от информация през подсистеми, компоненти или класове е важен за системната интеграция. Потоците могат да се използват за свързване на модели на протоколи между системи, договори между интерфейси или поредици от съобщения.

Препоръчва се да се възприеме итеративен подход и да се избягват опитите за моделиране на цялата система наведнъж („Абсолютно голям дизайн“). Скицирайте модела в първите итерации и след това във всяка следваща итерация, детайлизирайте функционалносттафункции, които ще бъдат изследвани в тази итерация. Разработете тестове, които отразяват модела възможно най-точно и валидирайте кода спрямо тези тестове. Вземете уроци, докато кодирате и ги картографирайте обратно към модела. По този начин процесът на моделиране и процесът на разработка се синхронизират с помощта на итеративен подход.

Работният процес

Има пет основни работни потоци за новия системен сценарий, които са показани на фигурата:

Тези пет работни потока предоставят пълен процес за моделиране на нова система. Тъй като всеки се основава на другите и осигурява обратна връзка, грешките могат лесно да бъдат уловени надолу по веригата и коригирани. Свързването на работни елементи ви позволява да създавате задачи за разработка и тестови случаи от модел и връзка, за да осигурите проследимост. Имайте предвид, че работните нишки могат да се изпълняват едновременно - не е нужно да завършите една, преди да стартирате останалите.

Определение на архитектурата

Много видове приложения следват установени архитектурни модели. Тези шаблони ви предоставят стандартни решения, които имат добри инженерни характеристики, като например прозрачно разделяне на концерните. Използването на познати модели улеснява разработчиците да разбират приложенията и да намират различни части от функционалността. Например, диаграмата на слоевете на фигурата по-долу може да се приложи към всяко уеб приложение. Прилагането на този модел към примерното приложение на Pet Shop обаче поддържа нашата архитектура прозрачна, поне на най-високо ниво.

Архитектура на слоеве от високо ниво за онлайн магазин за домашни любимци

Когато се приложи този модел, е възможно системата ви да бъде разделена на подсистеми. За по-големи системи подсистемите могат да присвояват групиили отдел. В по-малките системи една подсистема може да има един или двама собственици. Разбира се, когато се използва процес на разработка на софтуер със споделена собственост върху кода, могат да бъдат създадени подсистеми за целите на идентифициране и поддържане на кодовата база в ред. Подсистемите често се използват за формиране на нашето решение Visual Studio.

Подробна диаграма на архитектурата на слоя

Можете да добавите по-подробна диаграма на слоевете под формата на разширени слоеве и прилагане на шаблони от по-ниско ниво. На ниско ниво можете да присвоите класове на всяка подсистема, която ще реализира необходимата функционалност. Можете дори да слезете до нивото на методите - така че това е най-ниското ниво, например един наистина сложен клас за обработка на поръчки с 30 метода може да изисква своя собствена схема на слоеве, когато се опитва да раздели различните поведения.

Трябва да спазвате зависимостите: стрелките между подсистемите показват еднопосочен модел между слоевете. Множеството слоеве позволяват да се изследват архитектурни перспективи и могат да се използват за присвояване на работни елементи (задачи и грешки) или за свързване на други документи със слоеве, така че определена проблемна област да бъде напълно представена от слой. Например грешките обикновено се класифицират по техните компоненти или архитектурни зони и се присвояват на правилния разработчик.

Ключов аспект на някои от тези диаграми е те да бъдат възможно най-прости, за да не претоварват потребителя. Диаграма, която се използва за свързване на елементи, може да бъде по-абстрактна за други членове на екипа и по-подробна за този, който я използва за създаване или преглед на код.

Дефиниране на актьори, случаи на използване и бизнес концепции

Субект - Тип външен обект като потребител или друга система, която взаимодейства с вашата система. Някои примери за теми за приложение за уеб магазин за домашни любимци са „Онлайн клиент“ и „PayPal“. Тъй като приложението Pet Shop е фокусирано върху електронната търговия, „Онлайн клиент“ е по-добро име на тема, отколкото просто „Клиент“.

Диаграма на случай на частична употреба за приложението Online Pet Shop

Определете целите на всеки предмет. Мислете за всяка цел като за случай на употреба. Например, много клиенти просто искат да разгледат снимки на кучета и котки, преди да получат. Тяхната цел е да разглеждат стоките (или може би „Ревю на домашни любимци“ звучи по-добре), докато намерят правилния. След като намерят това, което искат, може да пожелаят да добавят към пазарската си количка и да купят този домашен любимец.

Добър ресурс, който бихте могли да разгледате, е Agile Modeling от Скот Амблер.

Вижте Моделиране на потребителски изисквания за повече подробности.

Дефиниция на бизнес концепция

Класовата диаграма на бизнес концепцията описва субектите и взаимоотношенията, които представляват интерес за разработване. Ключът е да се гарантира, че екипът разбира бизнес изискванията, е последователен и използва обща терминология (речник на термините) и че екипът действително изгражда правилната система.

Тези класове представляват условия и взаимоотношения, които се дефинират и налагат от потребителите. Диаграмата на бизнес концепцията отговаря на въпроси относно изискванията на клиентите, като например „Продуктът списък с животински видове ли е или списък с отделни животни?“ или „Всяко животно ли се оценява индивидуално или се оценяват по видове?“

Диаграмата на бизнес концепцията не е такава(задължителна) диаграма на софтуерни класове, така че не е необходимо да свързвате операции с тези класове. Вместо това целта на схемата е да помогне за избягване на недоразумения относно ключови термини, които често пречат на дискусиите между екипи за разработка, клиенти и тестери.

Диаграма на класове за бизнес концепция

Диаграмата на случая на използване и бизнес концепциите заедно описват „общия език“ на вашия проект: термините, използвани при обсъждане на изискванията с потребителите, имената на важни класове и компоненти във вашия дизайн и термините, използвани за дефиниране на системни тестове.

Полезно е да се опишат резултатите от всеки случай на употреба по отношение на обекти и взаимоотношения в диаграма на бизнес концепция. Например:

Уверете се, че можете да опишете важните резултати от всеки случай на употреба по отношение на връзките и атрибутите на бизнес концепцията, предположенията, цялостния поток от изисквания на високо ниво, критерии за успех и вариации, които често се срещат. Например, за да се опише Обзор, са необходими само класовете Домашни любимци и Инвентар. За да опишете покупка, трябва да добавите пазарска количка. Атрибутът Price също е необходим, което повдига въпроса дали да го поставите на Pet или Pet Type. Това е въпрос, който може би трябва да се обсъди с клиента, собственика на зоомагазина.

Уверете се, че разбирате, че случаят на използване създава и премахва всички връзки. Например кой случай на употреба премахва връзката между домашен любимец и инвентар? Премахва ли се домашен любимец от инвентара веднага щом бъде добавен в количката за пазаруване? Трябва ли да добавим към описанието на Purchase Pet(s) „... и тези домашни любимци са премахнати от списъка с продукти“? Като друг пример, какви случаи на употреба са добавяне или премахване на тип домашен любимец от каталога?

Вижте Диаграми на случаи на използване на UML: Насоки за повече информация и примери.

Тези въпроси са много полезни за обсъждане с вашите клиенти. Те възникват от вашите опити да направите описанието на случаите на употреба и бизнес концепцията съвместими помежду си; това прави UML модела много повече от пасивен набор от диаграми. Вместо това те са мощен инструмент, който ви помага да развиете ясно разбиране за нуждите на вашите клиенти в началото на проекта.

Солидна основа за системни функционални тестове се осигурява от „общия език“ на бизнес концепцията и диаграмите на случаите на употреба и описанията на целта на случаите на употреба. Въпреки че моделът на това ниво е много по-опростен от внедряването, което ще бъде по-късно, и не казва нищо за това как ще бъдат внедрени класовете, връзките и случаите на използване, описанията все пак са недвусмислени по отношение на резултата от всеки случай на употреба.

В допълнение, диаграмите на бизнес концепцията осигуряват рамка, върху която да се изразят неизменни бизнес правила като връзката между общата цена на количка и цените на вложените в нея артикули.

Определяне на поведението

За моделиране на динамичното поведение на бизнес или система могат да се използват различни видове диаграми на поведение.

Диаграмите на дейности се използват за описание на потока от събития на бизнес слоя в случай на употреба и са особено полезни, за да ви помогнат да опишете едновременни дейности. Случаите на използване често се „уточняват“ с помощта на диаграми на активност.

UML диаграмите на последователности са особено добри за показване на това как работата се разпределя между различните участници и компоненти на системата. За всеки вариантслучай на употреба, можете да начертаете диаграма на последователност, в която жизнените линии са субектът и системата или нейните основни компоненти и която показва как те взаимодействат, за да постигнат целта на случая на употреба.

Когато проектирате компонент като композиция от множество части, можете да създадете диаграми на последователност, където всяка част е спасителна линия. За всяко извикване към външни интерфейси на компонент можете да покажете как частите си взаимодействат, за да постигнат резултата, изискван от извикването. Докато вашият проект напредва чрез разработването на различните части на системата, вие постепенно въвеждате нови диаграми, за да опишете новите компоненти.

Трябва често да актуализирате тези диаграми по време на разработката. По време на кодирането диаграмите помагат на екипа да обсъжда и открива нови пътища и да оптимизира методи и класове.

Visual Studio Ultimate поддържа два типа диаграми на последователности. Диаграмите на UML последователности са част от UML модела.

Диаграмите на .NET последователности се генерират от програмен код, използват общи UML нотации и не са част от UML модела. Докато разработвате код, можете да създадете диаграма на последователност, за да прегледате структурата му, да го сравните с първоначално създадения дизайн и да обсъдите алтернативно разпределение на отговорността.

.Net последователна диаграма, генерирана от ProcessOrder на приложението Pet Shop

Преглед на модела

Всеки модел предоставя поглед върху системата от различна гледна точка. Пълна картина на системата се получава, когато се съберат и разгледат всички модели. Непрекъснатият преглед на моделите е отличен метод за правене на предположения иразбиране на гледната точка на другия. При преглед работата по внедряване на модела в код може да бъде присвоена с помощта на работни елементи. TFS може да се използва за сътрудничество при разширения на модели и моделите могат да бъдат свързани с работни елементи.

ПРЕПОРЪКИ Вижте Visual Studio 2012 Architecture Guidance - New System HOL за инструкции стъпка по стъпка относно този сценарий.

Автор на статията: Александър Шамрай.