ЛАБОРАТОРНА РОБОТА №3
«АНАЛІЗ СИСТЕМНИХ ВИМОГ ТА РОЗРОБКА UML ДІАГРАМ КОНЦЕПТУАЛЬНОГО РІВНЯ МОДЕЛЮВАННЯ АРХІТЕКТУРИ ПРОГРАМНОЇ СИСТЕМИ»
МЕТА РОБОТИ: Ознайомитися із методикою побудови UML-діаграм концептуального рівня проектування програмного забезпечення.
1. ЗАГАЛЬНІ ВІДОМОСТІ
На концептуальному рівні проектування ПЗ, на основі раніше визначених та задокументованих системних вимог (див. л/р №2) визначаються найбільш загальні характеристики системи, що розробляється, до яких належать:
- основні варіанти використання функцій системи,
- типи її користувачів,
- послідовність взаємодії окремих користувачів та системи або окремих підсистем;
- основні групи програмних компонентів, що реалізують певні функції системи, із рознесенням їх по рівням логічного упорядкування та взаємодії.
При об'єктно-орієнтованому підході до проектування ПЗ із використання UML на концептуальному рівні моделювання використовуються такі діаграми як [1]
• діаграми варіантів використання (або прецедентів - use case diagram),
• діаграми послідовностей (sequence diagram),
• діаграми пакетів (package diagram).
Як додатковий засіб до діаграм прецедентів, який дозволяє розширити уявлення розробників щодо подальшої програмної реалізації системи, можуть бути використані також діаграми стійкості (robustness diagram)
1.1. Діаграми прецедентів (use case diagram)
Під прецедентом (case) треба розуміти фіксовану послідовність дій між користувачами та програмною системою або між окремими підсистемами яка забезпечує досягнення поставлених цілей. В обох випадках вони позначаються терміном "актор" (actor). Так, наприклад, процедура авторизації користувача на деякому Інтернет ресурсі є певним прецедентом. Для нього учасниками будуть система авторизації та користувач, а результатом - перевірка наявності в системі реєстраційного запису ("аккаунту") користувача.
Кожна модель відображає взаємозалежність прецедентів та акторів. Так, можливі наступні типи залежностей:
- асоціація (association)
- включення (include)
- розширення (extend)
- узагальнення (generalization).
Всі ці чотири типа залежностей показані на рис. 1
Відношення асоціації є основним типом залежностей між акторами та прецедентами, воно позначає той факт, що деякий актор відіграє певну роль у взаємодії із системою. На діаграмі асоціація позначається суцільною прямою лінією з стрілкою на кінці та може бути позначено відповідним ім'ям. На рис. 1 це відношення "realize" між актором "User" та прецедентом "Authorization"
Відношення включення дає можливість відобразити те, що деякі функції одного прецеденту А обов'язково мають бути задіяні при використанні іншого прецеденту B. На діаграмі включення позначається пунктирною прямою лінією з стрілкою на кінці, яка направлена до того прецеденту, що включає в себе деякий інший та має ім'я «include». На рис. 1 це відношення між прецедентом "Authorization" та "Login / PW".
Рис. 1 - Приклад побудови UML-діаграми прецедентів
Відношення розширення дає можливість відобразити те, що при опрацюванні системою деякого прецеденту X є можливим (але не обов'язковим!) використання функціональності іншого прецеденту Y. На діаграмі включення позначається пунктирною прямою лінією з стрілкою на кінці, яка направлена до того прецеденту, що є розширенням та має ім'я «extend». На рис. 1 це відношення між прецедентом "Authorization" та "PW Recovery".
І, нарешті, відношення узагальнення дозволяє показати певну ієрархію акторів і / або самих прецедентів, тобто позначити, який з них є супер-типом, а який - підтипом певного класу об'єктів. На діаграмі це позначається суцільною прямою лінією з трикутною стрілкою на кінці, яка направлена до прецеденту, що є супер-типом. На рис. 1 це відношення між акторами "Admin" та "User".
1.2 Діаграма стійкості (robustness diagram)
Прецеденти не можуть бути безпосередньо трансформовані в відповідні програмні об'єкти (класи). Для цього має бути використано певний проміжний рівень опису прецедентів, який дозволяє врахувати деякі особливості наступної програмної реалізації, наприклад, необхідність інтерфейсу користувача або наявність функцій бізнес-логіки. Одним з таких засобів подальшої деталізації моделі прецедентів є діаграма стійкості (ці діаграми належать до процесу проектування ПЗ за стандартом ICONIX [2].
Діаграма стійкості розробляється на базі шаблону (або патерну - pattern) проектування MVC (Model-View-Controller). Тобто в системі, що розробляється, мають бути наявні три типи програмних об'єктів:
• Model - це об'єкти, які моделюють дані предметної області,
• View - це об'єкти, які реалізують відображення даних із моделі,
• Controller - це об'єкти, які обробляють дані моделі для подальшого їх відображення.
Основна ідея шаблону MVC полягає у відокремленні даних від їх відображення. Таким чином якщо в процесі розробки виникне потреба у змінені моделі даних, це ніяк не впливає на відображення (не треба буде нічого змінювати у компонентах View).
У діаграмі стійкості є свої окремі позначки для відображення елементів моделі MVC:
На рис. 2 побудовано діаграму стійкості для прецеденту регістрації нового користувача системи, де граничним об'єктом Registration form виступає певна діалогова форма, яка з'являється у вікні браузера на комп'ютері-клієнті системи, об'єктом-контролером Add new може бути, наприклад, програмний скріпт на мові PHP, який виконується на Web-сервері Apache та який за допомогою функцій обробки SQL-запитів працює із об'єктом даних Account - це може бути таблиця БД, що знаходиться під керуванням СКБД MySQL.
Рис. 2 - Діаграма стійкості для прецеденту реєстрації нового користувача.
Декілька прецедентів можуть бути пов'язані на одній діаграмі стійкості. Так, об'єкт даних Account використовується також для прецеденту входу до системи. Також можна розширити прецедент реєстрації додавши до нього контролер пошуку вже існуючого аккаунту. Тобто при реєстрації система буде перевіряти, чи вже існує той акаунт, який хоче додати користувач. Відповідна діаграма наведена на рис. 3.
Рис. 3 - Діаграма стійкості для двох прецедентів.