Архитектура за моделиране на приложения

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

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

Моделът е проектиран, за да се намали броят на неясноти, възникнали в описанието на естествен език, както и да помогне на вас и вашите колеги, за да визуализират на проекта и да се обсъдят и други опции. Моделът трябва да се използва в комбинация с други документи или дискусии. Сама по себе си, моделът не представлява пълната спецификация на архитектурата.

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

Архитектура на системата може да бъде разделена на две части:

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

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

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

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

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

Разбиране на изискванията. Отправната точка на всяко развитие е ясно разбиране на нуждите на потребителите.

Архитектурни модели. Избрани основни технологии и архитектурни елементи на системата.

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

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

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

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

модел на търсенето осигурява следната важна информация:

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

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

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

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

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

Изисквания и архитектурни модели могат да бъдат разделени в следните два начина:

Дръжте ги в едно-единствено решение, но в различни проекти. Те ще бъдат показани в браузъра UML модели като отделни модели. Различните членове могат да работят в паралелни модели. Между моделите могат да се създават ограничени видове проследяване.

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

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

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

Избор на основните технологии, като изборът между файловата система на базата данни и, а изборът между прилагането на мрежата и уеб клиента, и така нататък. Г.

Изборът на платформи, като изборът между Фондация Windows Workflow и Entity Рамката на ADO.NET.

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

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

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

По-долу са основните препоръки за този раздел.

Създаване на компоненти във веригата, за да се покаже основната част от системата.

Направи връзка между компоненти или интерфейси за структура на системата.

Използвайте интерфейси за компоненти за да се покаже на услугите, които предлага или изисква всеки компонент.

Можете да създадете отделна верига, разделяща всеки компонент на по-малки парчета, за големи системи.

Тези точки са обсъдени в останалата част от раздела.

елементи

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

Конвенционалните компоненти верига за голяма система може да включва следните компоненти:

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

компоненти на уеб услуги. Осигурява комуникация между клиенти и сървъри.

Контрольори използват случаи. Ще ви преведе през поредица от стъпки за всеки от сценариите.

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

База данни. Бизнес предмети се съхраняват.

Компоненти дърводобив и обработка на грешки.

Зависимостите между компонентите

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

Една добре проектирана архитектура осигурява добре подреден връзка, в която са изпълнени следните условия:

Цикли на код картата не.

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

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

управление на зависимостта е най-важното за развитието на софтуер поддържа. схемните елементи трябва да отразяват всички зависимости в кода. Ако вече съществува кода, уверете се, че диаграми показват зависимостите. Ако кодът е все още в процес на развитие, се уверете, че тя не включва зависимостта не е планирано в компонентите на веригата. С цел опростяване на идентифицирането на зависимости в кода си, можете да създадете една верига слоеве. За да сте сигурни, че спазвате планираните ограничения за зависимостта, можете да проверите слоеве схеми код. За подробности вижте слоя вериги :. референтни материали.

интерфейси

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

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

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

Поставете компонент в средата на изпитване, при което околните компоненти на този тест моделирани среда.

Разработване компонент независимо от другите компоненти.

Повторно използване на компоненти в друг контекст, свързвайки го допирни точки с други компоненти.

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

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

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

Разделянето на компонентите

Процедурата, описана в предишните раздели може да се прилага за всеки компонент.

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

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

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

Използвайте от следните ситуации:

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

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

Използване на отделните компоненти, които са достъпни чрез интерфейсите необходими в следните ситуации.

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

Структурата е такава, че един доставчик може лесно да бъде заменена с друга.

Използване на необходимите интерфейси обикновено са предпочитани пред частта. Въпреки, че развитието може да отнеме повече време, крайният системата ще бъде по-гъвкав. В допълнение, той е по-лесно да се тества компонентите поотделно. Това намалява броя на зависимости в планове за развитие.