Лабораторна робота 7 на тему Діаграми класів з курсу Управління вимогами в ІТ проектах

Лабораторна робота №7

• вивчення діаграм класів,

• вивчення їх застосування у процесі проектування.

1. Діаграми класів (class diagrams)

Діаграми класів є центральною ланкою методології об'єктно-орієнтованого аналізу і проектування.

Діаграма класів показує класи і їхні відносини, тим самим представляючи логічний аспект проекту. Окрема діаграма класів становить певний ракурс структури класів. На стадії аналізу, діаграми класів використовуються, щоб виділити загальні ролі і обов'язки сутностей, що забезпечують необхідну поведінку системи. На стадії проектування, діаграми класів використовуються, щоб передати структуру класів, формують архітектуру системи.

Кожен клас повинен мати ім'я; якщо ім'я занадто довге, його можна скоротити або збільшити сам значок на діаграмі. Ім'я кожного класу повинно бути унікальним, проекті, що його містить.

Діаграма класів визначає типи об'єктів системи і різного роду статичні зв'язки, які існують між ними. Є два основних види статичних зв'язків:

• асоціації (наприклад, менеджер може вести кілька проектів),

• підтипи (працівник є різновидом особистості).

На діаграмах класів зображуються також атрибути класів, операції та обмеження, які накладаються на зв'язку між об'єктами. На рис. 1 зображена типова діаграма класів. Далі будуть розглянуті різні фрагменти діаграми. 

Асоціації

Асоціації представляють собою зв'язки між екземплярами класів (особистість працює в компанії, компанія має ряд офісів).

Будь-яка асоціація володіє двома ролями; кожна роль представляє собою напрямок асоціації. Таким чином, асоціація між «Виконавцем» і «Звітом» містить дві ролі: одна від «Виконавця» до «Звіту», інша – від «Звіту» до «Виконавця». Роль може бути явно поіменована за допомогою мітки. Якщо ця позначка відсутня, ролі присвоюється ім'я класу-мети; таким чином, роль асоціації від «Виконавця» до «Звіту» може бути названа «Звітом».

Роль також володіє множинністю, яка показує, скільки об'єктів може брати участь у даному зв'язку. На рис. 11.1 символ «0..*» над асоціацією між «Менеджером» і «Контрактом» показує, що з одним «Менеджером» може бути пов'язано багато «Контрактів», символ «1» показує, що будь-який «Контракт» управляється одним «Менеджером» .

У загальному випадку множинність показує нижню і верхню межі кількості об'єктів, які можуть брати участь у зв'язку. Для цього може використовуватися єдине число, діапазон або дискретна комбінація з чисел і діапазонів.

Для асоціації може бути вказаний напрямок навігації. Якщо навігація вказана тільки в одному напрямку, то така асоціація називається односпрямованою (асоціація між «Менеджером» і «Звітом» на рис. 11.1). У двобічній асоціації навігація вказана в обох напрямках. В UML відсутність стрілок у асоціації трактується наступним чином: напрям навігації невідомий чи асоціація у двох напрямках.

Атрибути

Атрибути багато в чому подібні асоціаціям. Різниця між ними полягає в тому, що атрибути припускають єдиний напрям навігації – від типу до атрибуту.

На рис. 11.1 атрибути вказані для класів «Контракт» і «Звіт». У залежності від ступеня деталізації діаграми, позначення атрибута може включати ім'я атрибута, тип і значення, що привласнюється за замовчуванням. У синтаксисі UML це виглядає наступним чином: <ознака видимості> <ім'я>: <тип> = <значення за замовчуванням >, де ознака видимості може приймати одне з наступних чотирьох значень:

• загальний (public) – атрибут доступний для всіх клієнтів класу,

• захищений (protected) – атрибут доступний тільки для підкласів та друзів класу,

• секретний (private) – атрибут доступний тільки для друзів класу,

• реалізація (implementation) – атрибут доступний тільки всередині обрамляємого пакета.

Операції

Операції представляють собою процеси, що реалізуються класом. Найбільш очевидна відповідність існує між операціями і методами над класом.

Повний синтаксис UML для операцій виглядає наступним чином: <ознака видимості> <ім'я> (<список-параметрів>): <тип-вираз-повертаючого-значення> = <рядок-властивостей>, де

• ознака видимості може приймати ті ж значення, що і для атрибутів;

• ім'я являє собою символьний рядок;

• список-параметрів містить додаткові аргументи, синтаксис яких збігається з синтаксисом атрибутів;

• тип-вираз-повертаючого-значення є необов'язковою специфікацією і залежить від конкретної мови програмування;

• рядок-властивостей показує значення властивостей, які застосовуються до такої операції. Прикладом операції на рис. 11.1 є операція закрити () класу «Контракт».

Узагальнення

Типовий приклад узагальнення включає «Команду проекту» і «Субпідрядника» (див. рис. 11.1). Вони володіють деякими відмінностями, однак у них також багато спільного. Однакові характеристики можна помістити в узагальнений клас «Виконавець» (супертип), при цьому «Команда проекту» і «Субпідрядник» будуть виступати в якості підтипів.

Сенс узагальнення полягає в тому, що інтерфейс підтипу повинен включати всі елементи інтерфейсу супертипа. Інша сторона узагальнення пов'язана з принципом шаблона. Субпідрядника можна підставити в будь-який код, де потрібно «Виконавець», і при цьому все повинно нормально працювати. Це означає, що, розробивши код, який передбачає використання «Виконавця», можна вільно вживати примірник будь-якого підтипу «Виконавця». Субпідрядник може реагувати на деякі команди відмінні від інших «Виконавця чином» (відповідно до принципу поліморфізму), але ця відмінність не повинна турбувати зухвалий об'єкт.

Узагальнення з точки зору реалізації пов'язано з поняттям наслідування в мовах програмування. Підклас успадковує всі методи і поля суперкласу і може перевизначати успадковані методи. Підтип можна також реалізувати, використовуючи механізм делегування.

Обмеження

При будівлі діаграм класів основним заняттям є відображення різних обмежень. На рис. 11.1 показано, що «Контракт» може управлятися лише одним «Менеджером».

За допомогою конструкцій асоціації, атрибута і узагальнення можна специфікувати найбільш важливі обмеження, але неможливо висловити їх усі.

У UML відсутній суворий синтаксис опису обмежень, за винятком поміщення їх у фігурні дужки {}. 

Таблиця 11.1

Опис кнопок панелі інструментів діаграм класів Rational Rose

2. Приклад

На рис. 11.2 та 11.3 наведено дві діаграми класів, що реалізують один і той самий фрагмент підсистеми «Служба зайнятості в рамках вузу»: взаємодія користувача з БД, яка містить персональні відомості.

Проведемо розрахунок оцінки для кожної з діаграм.

Діаграма 1

Атрибути і операції на діаграмі не вказані, тому відразу розрахуємо повне значення для діаграми.

Діаграма 2 

Відповідно значення для діаграми 2 знаходиться в допустимих межах, значення для діаграми 1 перевищує допустиму величину. Такий результат можна пояснити двома причинами.

1. На діаграмі 1 відображений клас «Викладач», який хоч і є нащадком класу «Користувач системи», але не бере участі у взаємодії з БД. Відповідно він ускладнює модель, не вносячи при цьому корисної інформації.

2. На діаграмі 1 інтерфейс «Особисті дані» зображений в розгорнутій формі (як клас, позначений стереотипом), а на діаграмі 2 він зображений значком інтерфейсу. Остання форма відображення більш краща, коли не вказуються операції інтерфейсу.

3. Завдання

1. Виділити основні класи об'єктів у проектованій системі.

2. Побудувати діаграму класів, яка в загальному вигляді демонструє архітектуру системи.

3. Побудувати одну-дві діаграми класів, деталізуючи окремі підсистеми. Вказати для класів основні атрибути та операції, вказати вид і напрямок асоціацій.

4. Контрольні питання

1. Яке призначення діаграм класів?

2. Для чого використовується діаграма класів на стадії аналізу?

3. Для чого використовується діаграма класів на стадії проектування?

4. Назвіть основні компоненти діаграм класів.

5. Назвіть основні типи статичних зв'язків між класами.

6. Що являє собою асоціація?

7. У чому сенс множинності асоціацій?

8. У чому відмінність атрибутів від асоціацій?

9. Що таке ознака видимості?

10. Що являє собою операція класу?

11. У чому сенс узагальнення?

12. Яке призначення обмежень на діаграмах класів?

З повагою ІЦ "KURSOVIKS"!