Посібник з інструментів архітектури Visual Studio
Visual Studio Ultimate допоможе вам шляхом успішної побудови нової системи. Поєднання інструментів Unified Model Language (UML) та ітеративний підхід може допомогти вам поступово:
- Визначити вимоги
- Створити багаторівневу архітектуру з придатною абстракцією для об'єктно-орієнтованого підходу
- Розробити потоки команд управління між компонентами та класами
Вимоги нової системи визначають, що має бути розроблено. Набір вимог допоможе нам визначити архітектуру системи. Форма слідує за функцією. Як тільки ми маємо форму або архітектуру системи, ми можемо задовольнити кожну з вимог шляхом побудови потоків між різними компонентами та класами.
Прозора архітектура є критичною для розширюваної і простої підтримки системи. Visual Studio Ultimate дозволить висвітлити архітектуру, тому всі в команді зможуть побачити її елегантність. Це критично для великих систем, але так само важливо для проектів з одним або двома людьми.
Робочий процес сценарію створення нової системи
Чи розробляє ваш проект три людини чи триста потік інформації через підсистеми, компоненти чи класи важливий для інтеграції системи. Потоки можуть використовуватися для зв'язування моделей протоколів між системами, контрактів між інтерфейсами або послідовності повідомлень.
Рекомендується використовувати ітеративний підхід і уникати спроб моделювати всю систему за один раз (абсолютний великий дизайн). Створіть начерки моделі в перших ітераціях і потім у кожній наступній ітерації, деталізуйте функціональніможливості, які будуть розглянуті у цій ітерації. Розробляйте тести, які відображають модель максимально близько та перевіряйте код на основі цих тестів. Вийміть уроки під час кодування та відображайте їх назад у моделі. Таким чином, процес моделювання та процес розробки синхронізуються за допомогою ітеративного підходу.
Робочий процес
Існує п'ять основних робочих потоків для сценарію нової системи, які відображені на малюнку:
Ці п'ять робочих потоків забезпечують повний процес моделювання нової системи. Оскільки кожен з них спирається на інші і забезпечує зворотний зв'язок, помилки можуть бути легко виявлені потоком і виправлені. Зв'язування робочих елементів дозволяє створити завдання розробки та тестові сценарії з моделі та зв'язати для забезпечення відстеження походження. Зверніть увагу, що робочі потоки можуть працювати одночасно – вам не потрібно завершувати один, перш ніж почати інші.
Визначення архітектури
Багато типів програм слідують встановленим архітектурним шаблонам. Ці шаблони надають вам стандартні рішення, які мають хороші інженерні характеристики, такі як прозорий поділ проблем. Використання знайомих шаблонів спрощує розробникам розуміння програм та дозволяє знайти різні частини функціональності. Наприклад, діаграма шарів на малюнку нижче може застосовуватися для будь-якої веб-програми. Однак, застосовуючи цей шаблон до Pet Shop sample application тримає нашу архітектуру прозорою, принаймні на найвищому рівні.
Архітектура шарів високого рівня для Online Pet Shop
Коли використовується цей шаблон, можна розбити вашу систему на підсистеми. Для великих систем підсистеми може призначити групичи відділ. У невеликих системах підсистема може мати чи двох власників. Звичайно, при використанні процесу розробки програмного забезпечення із загальним володінням коду, підсистеми можуть бути створені для ідентифікації та збереження бази коду в порядку. Підсистеми часто використовують для формування нашого рішення Visual Studio.
Деталізована діаграма архітектури шарів
Можна додати більш детальну діаграму шарів у вигляді розгорнутих шарів та застосування шаблонів нижнього рівня. На низькому рівні можна призначити класи кожної підсистеми, які реалізувати необхідні функції. Ви можете навіть піти до рівня методів – так що це буде найнижчий рівень, наприклад, справді складний клас обробки замовлення з 30 методами може вимагати свою власну схему шару при спробі відокремити різні варіанти поведінки.
Ви повинні шанувати залежність: стрілки між підсистемами вказують шаблон одностороннього використання між шарами. Декілька шарів дозволяють вивчити архітектурні точки зору і можуть використовуватися для призначення робочих елементів (завдань та помилок) або пов'язати інші документи з шарами, щоб конкретна проблемна область була повністю представлена шаром. Наприклад, помилки зазвичай класифікуються їх компонентами або архітектурними зонами і призначаються необхідному розробнику.
Ключовий аспект деяких з цих діаграм тримати їх максимально простими, щоб не завантажити користувача. Діаграма, яка використовується для зв'язування елементів, для інших членів команди може бути абстрактнішою, а для одного, який використовує її для створення або перевірки коду, може бути більш докладною.
Визначення суб'єктів, варіантів використання та бізнес концепції
Суб'єкт — це тип зовнішньої сутності, така як користувач або інша система, яка взаємодіє з вашою системою. Деякі приклади суб'єктів для веб-зоомагазину є «Online Customer» і «PayPal». Оскільки програма Pet Shop орієнтована на Інтернет-комерцію, «Online Customer» є кращим найменуванням суб'єкта, ніж просто «Customer».
Часткова діаграма варіантів використання для програми Online Pet Shop
Визначте цілі кожного суб'єкта. Уявіть кожну мету як варіант використання. Наприклад, багато клієнтів хочуть просто подивитися на фотографії собак і кішок, перш ніж отримати одного з них. Їхня мета – Перегляд товару (або може бути «Огляд домашніх тварин» звучить краще) доти, доки вони не знаходять потрібного. Як тільки вони знаходять, що вони хотіли, вони, можливо, забажають додати в кошик і купити цього вихованця.
Гарний ресурс, котрий ви можете розглянути “Agile Modeling”, Scott Ambler.
Дивіться Modeling User Requirements для більш детальної інформації.
Визначення бізнес концепції
Діаграма класів бізнес-концепції описує сутності та відносини, які становлять інтерес у розробці. Ключовим завданням є забезпечення розуміння командою бізнес-вимог, узгодженості та використання загальної термінології (глосарія термінів) і що команда фактично будує правильну систему.
Ці класи представляють умови та відносини, які визначені та застосовні користувачами. Діаграма бізнес концепції відповідає на запитання щодо вимог замовника, наприклад «Товари це список видів тварин або список окремих тварин?» або «Кожна тварина оцінюється індивідуально чи оцінюються на вигляд?»
Діаграма бізнес концепції не є(обов'язково) діаграмою класів програмного забезпечення, так що вам не потрібно зв'язувати операцій із цими класами. Натомість мета схеми полягає в тому, щоб допомогти уникнути непорозуміння у ключових термінах, які часто заважають дискусії між командами розробників, клієнтами та тестувальниками.
Діаграма класів для бізнес-концепції
Схема варіантів використання та бізнес-концепції разом описують «загально вживану мову» вашого проекту: терміни, які використовуються під час обговорення вимог з користувачами, найменування важливих класів та компонентів у вашому дизайні та терміни, які використовуються для визначення системних тестів.
Корисно описати результати кожного варіанта використання у термінах сутностей та зв'язків у схемі бізнес-концепції. Наприклад:
Переконайтеся, що ви можете описати важливі результати кожного варіанта використання з погляду зв'язків та атрибутів бізнес-концепції, припущень, загального високого рівня потоку вимог, критеріїв успіху та варіацій, що часто зустрічаються. Наприклад, щоб описати Огляд, потрібні тільки класи Pet та Inventory. Щоб описати покупку, потрібно додати Shopping Cart. Необхідний також атрибут Price, який породжує питання покласти його на Pet або Pet Type. Це питання, яке може знадобитися обговорити із замовником, власником зоомагазину.
Переконайтеся, що ви розумієте, що варіант використання створює і видаляє всі зв'язки. Наприклад, який варіант використання видаляє зв'язок між Pet та Inventory? Pet видаляється з Inventory як тільки він додається у Shopping Cart? Ми повинні додати до опису Purchase Pet(s) «…і ці тварини видаляються зі списку товарів»? Як інший приклад, які варіанти використання додають чи видаляти Pet Type із Catalog?
Дивіться UML Use Case Diagrams: Guidelines для отримання додаткової інформації та прикладів.
Ці питання дуже корисні для обговорення з вашими замовниками. Вони виникають з ваших спроб зробити опис варіантів використання та бізнес-концепції відповідно один з одним; це робить модель UML набагато більшою, ніж пасивний набір діаграм. Натомість вони є потужним інструментом, який допомагає вам сформувати чітке розуміння потреб ваших замовників на ранньому етапі у проекті.
Міцну основу для функціональних тестів системи забезпечує «загально уживаний мову» діаграм бізнес концепції та варіантів використання та опису цілей варіантів використання. Незважаючи на те, що модель на цьому рівні є набагато простішою, ніж надалі буде реалізація, і нічого не говорить про те, як будуть реалізовуватися класи, зв'язки та варіанти використання, описи, проте однозначні з точки зору підсумків кожного варіанту використання .
Крім того, діаграми бізнес-концепцій забезпечують основу, на якій виражають інваріантні бізнес-правила, як відносини між повною вартістю кошика та ціни його вкладених елементів.
Визначення поведінки
Для моделювання динамічної поведінки бізнесу чи системи можна використовувати різні типи поведінкових діаграм.
Діаграми активності використовуються для опису потоку подій на бізнес-рівні у варіанті використання та особливо корисні, щоб допомогти вам описати паралельні активності. Варіанти використання часто "конкретизуються" за допомогою діаграм активності.
UML діаграми послідовностей особливо хороші для демонстрації, як робота розподіляється між різними суб'єктами та компонентами системи. Для кожного варіантаВи можете намалювати діаграму послідовностей, в якому лінії життя є суб'єктом і системою або її основними компонентами, і яка показує, як вони взаємодіють для досягнення мети варіанта використання.
При розробці компонента як композиції з кількох частин можна створити діаграми послідовностей, в яких кожна частина є лінією життя. Для кожного виклику зовнішніх інтерфейсів компонента можна показати, як частини взаємодіють для досягнення результату, необхідного для виклику. По ходу того як ваш проект розвивається через розробку різних частин системи, ви поступово вводите нові діаграми для опису нових компонентів.
Ви часто маєте оновлювати ці діаграми під час розробки. Під час кодування, діаграми допомагають команді обговорити та відкривати нові шляхи та оптимізувати методи та класи.
У Visual Studio Ultimate підтримуються два типи діаграм послідовностей. UML-діаграми послідовностей є частиною моделі UML.
Діаграми послідовності .NET генеруються з коду програми, використовують загальні нотації UML і є частиною UML-модели. Поки ви розробляєте певний код, можна створити діаграму послідовностей, щоб переглянути його структуру, порівняти його з дизайном, що спочатку створювався, та обговорити альтернативні розподіли відповідальності.
Діаграма послідовностей .Net згенерована з ProcessOrder програми Pet Shop
Рецензування моделей
Кожна модель забезпечує уявлення системи з іншого боку. Повна картина системи виходить, коли всі моделі зібрані та розглянуті. Постійне рецензування моделей є чудовим методом для прийняття припущень тарозуміння точки зору один одного. У рецензуванні робота для реалізації моделі коду може бути призначена за допомогою робочих елементів. TFS може використовуватися для співробітництва з розширення моделі та моделі можуть бути пов'язані з робочими елементами.
| РЕКОМЕНДАЦІЇ Дивіться Visual Studio 2012 Architecture Guidance – New System HOL для покрокової інструкції щодо цього сценарію. |
Автор статті: Олександр Шамрай.