Моделювання архітектури додатку
Щоб забезпечити відповідність програмної системи або додатки потребам користувачів, в Visual Studio можна створювати моделі в рамках опису загальної структури та поведінки програмної системи або додатки. За допомогою моделей також можна описувати шаблони, які використовуються при розробці. Такі моделі допомагають зрозуміти існуючу архітектуру, обговорювати зміни і чітко формулювати свої наміри.
Щоб дізнатися, які версії Visual Studio підтримують цю функцію, див. Розділ Підтримка версій для інструментів моделювання і архітектури.
Модель призначена для зменшення числа неоднозначностей, що виникають в описах на природній мові, а також для того, щоб допомогти вам і вашим колегам візуалізувати проект і обговорити інші можливі варіанти. Модель слід використовувати спільно з іншими документами або обговореннями. Сама по собі модель не представляє повну специфікацію архітектури.
В цьому розділі поняття "система" означає розробляється вами програмне забезпечення. Це може бути велика колекція компонентів програмного та апаратного забезпечення, один додаток або частина програми.
Архітектуру системи можна розділити на дві області:
Високорівнева структура. Описує основні компоненти і їх взаємодію один з одним для виконання кожного вимоги. Якщо система має великий розмір, кожен компонент може мати власну високорівневу структуру, яка ніколи, що він складається з більш дрібних компонентів.
Конструктивні шаблони і угоди, які використовуються при розробці компонентів. Шаблон описує конкретний підхід до вирішення завдання при програмуванні. Використовуючи однакові шаблони в рамках всього процесу проектування, команда може скоротити витрати на внесення змін і розробку нового програмного забезпечення.
Високорівнева структура описує основні компоненти системи і їх взаємодію один з одним, спрямоване на досягнення цілей розробки. Дії в наступному списку пов'язані з розробкою високорівневою структури, однак їх послідовність може бути іншою.
При оновленні існуючого коду можна почати з опису основних компонентів. Переконайтеся, що розумієте всі зміни вимог користувачів, а потім додайте або змініть взаємодії між компонентами. При розробці нової системи спочатку розберіться з основними функціями в потребах користувачів. Після цього можна вивчити послідовності взаємодій для основних варіантів використання і об'єднати ці послідовності в структуру компонентів.
У будь-якому випадку корисно розробляти різні дії паралельно. а також розробляти код і тести на ранньому етапі. Чи не намагайтеся закінчити одну з цих завдань, перш ніж приступити до іншої. Як правило, вимоги і уявлення про найкращий спосіб розробки системи змінюються в міру написання та тестування коду. Таким чином, слід почати з розуміння основних можливостей структури і особливостей вимог і написання коду під них. Заповніть подробиці в наступних ітераціях проекту.
Розуміння вимог. Початковою точкою будь-якої розробки є чітке розуміння потреб користувачів.
Архітектурні шаблони. Вибрані базові технології та архітектурні елементи системи.
Компоненти і їх інтерфейси. Можна намалювати схеми компонентів, щоб показати основні частини системи і інтерфейси, за допомогою яких вони взаємодіють один з одним. Інтерфейси кожного компонента включають в себе всі повідомлення, певні в схемах послідовностей.
Взаємодія між компонентами. Для кожного варіанту використання, події або вхідного повідомлення можна намалювати схему послідовностей, яка показує, як основні компоненти системи взаємодіють для досягнення потрібного результату.
Модель даних для компонентів і інтерфейсів. Можна малювати схеми класів для опису відомостей, переданих між компонентами і зберігаються всередині компонентів.
Якщо розробляється система є компонентом більшої системи, частина вимог або всі вони можуть бути укладені в програмні інтерфейси.
Модель вимог надає таку важливу інформацію:
Надані інтерфейси. Наданий інтерфейс перераховує служби або операції, які система або компонент повинні надати своїм користувачам, чи є вони людьми або іншими програмними компонентами.
Необхідні інтерфейси. Необхідний інтерфейс перераховує служби або операції, які може використовувати система або компонент. У деяких випадках можна розробити всі ці служби в рамках власної системи. В інших випадках, особливо при розробці компонента, який можна об'єднати з іншими компонентами в різних конфігураціях, необхідний інтерфейс буде поставлено зовнішніми обмеженнями.
Вимога до якості обслуговування. Продуктивність, безпека, надійність і інші цілі і обмеження, яким система повинна відповідати.
Вимоги до моделі записуються з точки зору користувачів системи, чи є вони людьми або іншими програмними компонентами. Вони нічого не знають про внутрішні механізми роботи системи. Навпаки, в моделі архітектури завдання полягає в тому, щоб описати внутрішні механізми роботи і показати, як вони узгоджуються з вимогами користувачів.
Збереження вимог і моделей архітектури корисно, оскільки це спрощує обговорення вимог з користувачами. Це також допомагає виконати рефакторинг моделі і враховувати альтернативні варіанти архітектури без зміни вимог.
Вимоги та моделі архітектури можна розділити двома наступними способами:
Зберігайте їх в одному рішенні, але в різних проектах. Вони будуть відображаються в браузері моделей UML як окремі моделі. Різні члени команди можуть паралельно працювати над моделями. Між моделями можна створювати обмежені види трасування.
Помістіть їх в одну модель UML, але в різних пакетах. Це спрощує відстеження залежностей між моделями, але не дозволяє одночасно працювати з моделлю кільком людям. Крім того, дуже велика модель буде довше завантажуватися в Visual Studio. Тому такий підхід гірше підходить для великих проектів.
Обсяг відомостей, які слід поміщати в вимоги або модель архітектури, залежить від масштабу проекту, а також від розміру і розподілу команди. Невелика група з коротким проектом може обмежитися начерками схеми класів для бізнес-концепцій і декількома конструктивними шаблонами; великий проект, розподілений по декількох регіонах, потребують значно більшого числа подробиць.
На початку розробки необхідно вибрати базові технології і елементи, від яких залежить структура. Нижче перераховані області, в яких необхідно зробити вибір:
Вибір базових технологій, наприклад вибір між базою даних і файлової системою і вибір між мережевим додатком і веб-клієнтом і т. Д.
Вибір платформи, наприклад вибір між Windows Workflow Foundation і ADO.NET Entity Framework.
Вибір методу інтеграції, наприклад вибір між службової шиною підприємства або каналом "точка-точка".
Ці варіанти часто визначаються вимогами до якості обслуговування, такими як масштаб і гнучкість, і відповідний вибір може бути зроблений до визначення докладних вимог. У великій системі конфігурації обладнання та програмного забезпечення жорстко взаємопов'язані.
Зроблений вибір впливає на використання та інтерпретацію моделі архітектури. Наприклад, в системі, яка використовує базу даних, асоціації на схемі класів можуть представляти відносини або зовнішні ключі в базі даних, тоді як в системі, заснований на XML-файлах, асоціації можуть означати перехресні посилання, що використовують XPath. У розподіленої системі повідомлення на схемі послідовностей можуть представляти передані повідомлення; в автономному додатку вони можуть представляти виклики функцій.
Нижче наведені основні рекомендації з цього розділу.
Створіть схеми компонентів, щоб показати основні частини системи.
Намалюйте залежності між компонентами або їх інтерфейсами, щоб показати структуру системи.
Використовуйте інтерфейси для компонентів, щоб показати ті служби, які надає чи вимагає кожен компонент.
Для великих систем можна створювати окремі схеми, що розбивають кожен компонент на більш дрібні частини.
Ці моменти розглядаються в решти розділу.
компоненти
Центральними уявленнями моделі архітектури є схеми компонентів, які показують основні частини системи і їх залежності один від одного. Додаткові відомості про схеми компонентів см. В розділі Схеми компонентів UML: довідкові матеріали.
Звичайна схема компонентів для великої системи може включати в себе наступні компоненти:
Презентація. Компонент, який надає доступ для користувача, зазвичай працює в веб-браузері.
Компоненти веб-служби. Забезпечує зв'язок між клієнтами і серверами.
Контролери варіантів використання. Проводять користувача через послідовність кроків для кожного із сценаріїв.
Базова частина бізнесу. Містить класи, які засновані на класах в моделі вимог, реалізує ключові операції і накладає бізнес-обмеження.
База даних. Зберігає бізнес-об'єкти.
Компоненти ведення журналу та обробки помилок.
Залежності між компонентами
Крім самих компонентів, можна показувати залежності між ними. Стрілка залежності між двома компонентами показує, що зміни одного компонента можуть вплинути на інший. Зазвичай це відбувається тому, що один компонент використовує служби або функції, прямо або побічно надаються іншим компонентом.
Добре продумана архітектура містить чітко впорядковані залежності, в яких виконуються наступні умови:
Цикли на мапі коду відсутні.
Компоненти можуть бути організовані в шари, де будь-яка залежність йде від компонента в одному шарі до компоненту в наступному. Всі залежності між двома будь-якими шарами йдуть в одному напрямку.
Можна показати безпосередньо залежності між компонентами або залежності між необхідними і наданими інтерфейсами, приєднаними до компонентів. За допомогою інтерфейсів можна визначити операції, які використовуються в кожній залежності. Як правило, залежності між компонентами відображаються при першому малюванні схем, а потім - у міру додавання відомостей - замінюються на залежності між інтерфейсами. Обидві версії є правильним описом програмного забезпечення, однак версія з інтерфейсами надає більше інформації, ніж попередня версія.
Управління залежностями є найбільш важливим для створення підтримуваного програмного забезпечення. Схеми компонентів повинні відображати всі залежності в коді. Якщо код вже існує, переконайтеся, що на схемах показані всі залежності. Якщо код знаходиться в стадії розробки, переконайтеся, що він не включає в себе залежності, не заплановані в схемі компонентів. Щоб спростити виявлення залежностей в коді, можна створити схеми шарів. Щоб переконатися, що виконані ваші заплановані обмеження на залежності, можна перевірити код за схемами шарів. Детальніше див. У розділі Схеми шарів: довідкові матеріали.
інтерфейси
Помістивши інтерфейси на компоненти, можна розділити і назвати основні групи операцій, що надаються кожним компонентом. Наприклад, компоненти інтернет-системи продажів можуть мати інтерфейс, через який клієнти купують товари, інтерфейс, через який постачальники оновлюють свої каталоги, і третій інтерфейс, за допомогою якого здійснюється керування системою.
Компонент може мати будь-яку кількість наданих і необхідних інтерфейсів. Надані інтерфейси показують служби, що надаються даними компонентом для інших компонентів. Необхідні інтерфейси показують служби, які даний компонент використовує в інших компонентах.
Визначення як наданих, так і необхідних інтерфейсів допомагає чітко відокремити компонент від іншої частини структури, щоб можна було використовувати ці методики.
Помістіть компонент в оточення тесту, в якому навколишні компоненти моделюються цим оточенням тесту.
Розробіть компонент незалежно від інших компонентів.
Повторно використовуйте компонент в інших контекстах, пов'язуючи його інтерфейси з іншими компонентами.
Якщо ви хочете визначити список операцій в інтерфейсі, можна створити інше уявлення інтерфейсу на схемі класів UML. Для цього знайдіть інтерфейс в браузері моделей UML і перетягніть його на схему класів. Потім можна додати операції в інтерфейс.
Операція в інтерфейсі UML може представляти будь-який спосіб, за допомогою якого можна викликати поведінку компонента. Вона може представляти запит веб-служби, сигнал або взаємодія іншого типу або звичайний виклик функції в програмі.
Щоб визначити, які операції слід додати, створіть схеми послідовностей, що показують, як компоненти взаємодіють один з одним. Див. Розділ Взаємодія між компонентами. Кожна з цих схем послідовностей показує взаємодія, що має місце в різних варіантах використання. Таким чином, ви можете поступово додавати операції в інтерфейс кожного компонента в міру вивчення варіантів використання.
Поділ компонента на частини
Процедуру, описану в попередніх розділах, можна застосувати до кожного компоненту.
Усередині кожного компонента можна показати його вкладені компоненти як частини. Частина являє собою атрибут свого батьківського компонента, що є різновидом класу. Кожна частина має власний тип, який може бути компонентом. Можна помістити цей компонент на схему і показати його частини. Детальніше див. У розділі UML-схеми компонентів: правила роботи.
Корисно застосовувати цю методику для всієї системи. Намалюйте систему як один компонент і покажіть її основні компоненти як частини. Це допомагає чітко визначити інтерфейси, що зв'язують систему із зовнішнім світом.
Якщо структура для компонента використовує інший компонент, часто існує вибір, представити його як частину або як окремий компонент, доступний через необхідний інтерфейс.
Використовуйте частини в наступних ситуаціях:
Структура батьківського компонента завжди повинна використовувати тип компонента частини. Таким чином, структура частині є невід'ємною частиною структури батьківського компонента.
Батьківський компонент не має конкретного існування. Наприклад, можна мати концептуальний компонент, званий шаром представлення даних, який представляє колекцію реальних компонентів, які обробляють уявлення і взаємодії з користувачем.
Використовуйте окремі компоненти, доступ до яких здійснюється через необхідні інтерфейси, в таких ситуаціях.
За допомогою інтерфейсів необхідний компонент можна пов'язати з різними надавачами компонентами під час виконання.
Структура така, щоб одного постачальника можна було легко замінити іншим.
Використовувати необхідні інтерфейси зазвичай краще, ніж частини. Хоча розробка може зайняти більше часу, підсумкова система буде більш гнучкою. Крім того, в ній простіше тестувати компоненти окремо. Це дозволяє зменшити число взаємозалежностей в планах розробки.