Лабораторна робота № 6. Дослідження структури та умов використання методології UML. Модель класів

Мета роботи:

Розглянути визначення бізнес-процесу та спосіб його опису за допомогою методології UML. Навчитися розробляти задачі у вигляді бізнес-процесу, описаного за методологією UML. Розглядається структурне моделювання, а саме модель та діаграма класів.

Результати навчання:

Досліджувати, розробляти і супроводжувати системи та засоби інформаційної безпеки та/або кібербезпеки на об’єктах інформаційної діяльності та критичної інфраструктури.

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

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

1.     Теоретичний матеріал

Моделювати систему краще з трьох різних точок зору, пов’язаних між собою. Кожна модель описує важливі аспекти системи, але для більш повного опису потрібно все три моделі:

– модель класів

– модель стану

– модель взаємодії

Модель класів становить статичні, структурні аспекти системи, пов’язані з даними.

Модель стану представляє тимчасові, поведінкові, управлінські аспекти системи.

Модель взаємодії представляє кооперацію окремих об’єктів, тобто всі аспекти системи, пов’язані з взаємодіями.

Розглянемо детальніше модель класів.

Класи – найбільш важливі будівельні блоки будь-якої об’єктно-орієнтованої системи.

Клас – це опис безлічі об’єктів з однаковими атрибутами, операціями, зв’язками і семантикою.

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

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

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

Один клас описується у вигляді прямокутника. Прямокутник поділено на 3 секції:

– верхня секція містить назву класу;

– середня секція описує стан, тому містить перелік полів (атрибутів) класу, імена та типи даних, разом із указанням області видимості;

– нижня секція описує поведінку, тому містить перелік методів (операцій) – імена методів, їх тип (статичні чи нестатичні), тип повернення, перелік вхідних параметрів тощо; також в цій секції указують конструктори, які прописані в явному виді у коді програми.

Наприклад:

Рисунок 6.1 – Приклади класів

У UML атрибути показуються щонайменше назвою, також може бути показано їх тип, початкове значення і інші властивості. Крім того, атрибути може бути показано з областю видимості атрибута:

– + відповідає публічним (public) атрибутам

– # відповідає захищеним (protected) атрибутам

– - відповідає приватним (private) атрибутам

Операції (методи) також показуються принаймні назвою, крім того, може бути показано їх параметри і типи значень, які буде повернуто. Операції, як і атрибути, може бути показано з областю видимості:

– + відповідає публічним (public) операціям

– # відповідає захищеним (protected) операціям

– - відповідає приватним (private) операціям

Клас може мати будь-яке число операцій або не мати жодної. Графічно операції представлені в розділі списку, наведеного під атрибутами класу. Допускається зазначення тільки імен операцій.

Щоб краще організувати довгі списки атрибутів і операцій, бажано забезпечити префіксом (ім’ям стереотипу) кожну категорію в них.

Обов’язок (responsibility) – це угода або зобов’язання класу. Коли ви створюєте клас, висувається припущення, що всі його об’єкти характеризуються однаковим станом і однаковою поведінкою.

На більш абстрактному рівні відповідні атрибути і операції є просто засобами, завдяки яким клас виконує свої обов’язки.

Наприклад, клас Wall (Стіна) відповідає за інформацію щодо висоти, ширини, товщини; клас FraudAgent (Агент За запобігання шахрайству), який можна зустріти в додатку, що обробляє кредитні карти, - за обробку запитів і визначення їх обґрунтованості, підозрілості або незаконність.

У класу може бути скільки завгодно обов’язків, хоча на практиці кожен добре структурований клас має як мінімум один обов’язок і як максимум – невеликий їх набір. Графічно обов’язки можуть бути представлені в спеціально відведеному для них розділі, в нижній частині піктограми класу.

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

При моделюванні системи необхідно не тільки ідентифікувати сутності, що формують її словник, а й змоделювати відносини один до одного. В об’єктно-орієнтованому моделюванні існують три види зв’язків між класами, які найбільш важливі: залежність, узагальнення, асоціації.

Залежність представляє зв’язки використання між класами (включаючи уточнення, трасування і зв’язування).

Узагальнення, яке пов’язує узагальнені класи з їх спеціалізаціями.

Асоціації, що описують структурні зв’язки об’єктів.

Кожна з цих різновидів представляє окремий спосіб комбінування абстракцій.

Розглянемо зв’язки щодо метафори будівництва будинку. Стіни, двері, вікна, вбудовані шафи і системи освітлення формують частину словника системи. Всі ці об’єкти (стіни, двері, вікна, шафи та освітлювальні прилади) в сукупності формують більш високорівневі сутності – кімнати.

Залежність являє собою зв’язок використання. Наприклад, труби залежать від водонагрівача для підігріву води, яка по ним передається.

Асоціація – це структурний зв’язок між екземплярами. Наприклад, кімнати складаються зі стін та інших об’єктів; в стіни вмонтовані двері і, можливо, вікна; через стіни можуть тягнутися труби.

Узагальнення пов’язує узагальнені класи з більш спеціалізованими і тому відомі як зв’язки успадкування («клас-підклас», або «батько-нащадок»). Наприклад, вітраж – це вікно з дуже великими, жорстко фіксованими панелями; патіо – різновид вікна, що відкривається убік.

Залежність (dependency) – це зв’язок, який встановлює, що одна сутність, наприклад клас Window (Вікно), використовує інформацію і сервіс (операцію або послугу), що подаються іншою сутністю, наприклад класом Event (Подія), але не обов’язково – навпаки.

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

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

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

Клас, що не має батьків, але має одну або кількох нащадків, називається кореневим (root) або базовим. Клас, що не має нащадків, називається листовим (leaf).

Про клас, у якого є тільки один батько, кажуть, що він використовує одиночне спадкування, на відміну від класу, у якого більш ніж один батько – множинне спадкування.

Наприклад:

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

Цілком припустимо, щоб обидва кінці асоціації з’єднували один і той же клас – іншими словами, один об’єкт класу може зв’язуватися з іншим об’єктом того ж класу. Асоціація, що зв’язує два класи, називається бінарною. Зустрічаються так звані n-арні асоціації, які з’єднують більше двох класів. Графічно асоціація представлена суцільною лінією, два кінці якої з’єднують один або різні класи.

Асоціація може мати ім’я, яке використовується для опису природи зв’язку. Тому значення імені не повинно бути двозначним. Використовуючи стрілочку в формі трикутника, ви можете вказати напрямок, в якому слід читати це ім’я.

Коли клас бере участь в асоціації, він виконує в зв’язку з цим конкретну роль. Роль – це «обличчя» класу, яка знаходиться на дальньому кінці асоціації, представлене класу, що знаходиться на її ближньому кінці. Можна явно іменувати роль, яку виконує клас в асоціації. Роль, яку відіграє клас, що знаходиться на кінці асоціації, називається кінцевим ім’ям.

Наприклад, клас Person (Людина), який грає роль employee (працівник), асоційований з класом Company (Компанія), що грає роль employer (роботодавець).

У багатьох ситуаціях моделювання важливо знати, скільки об’єктів може бути з’єднане одним екземпляром асоціації. Цей параметр називається множинністю ролі асоціації. Множинність (multiplicity) представляє діапазон цілих чисел, який вказує можливу кількість пов’язаних об’єктів.

Множинність може бути визначена як одиниця (1), нуль або один (0..1), багато (0 .. *), один або кілька (1 .. *). Можна задавати діапазон цілих значень, наприклад 2..5, або встановлювати точне число, наприклад 3 (еквівалент записи 3..3).

Наприклад, кожна компанія може наймати одного або декількох осіб (множинність 1 .. *); кожній людині зіставлено 0 або більше компаній-роботодавців (множинність * – еквівалент записи 0 .. *).

Проста асоціація між двома класами представляє структурний зв’язок між рівноправними елементами: обидва класу концептуально знаходяться на одному рівні – жоден з них не може вважатися важливіше іншого.

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

По суті, агрегація – це особливий вид асоціації, тому зображується вона лінією простої асоціації, до якої доданий порожній ромб з боку об’єкта-цілого.

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

Наприклад:

Приклад діаграми класів (рисунок 6.1).

Рисунок 6.1 – Приклад діаграми класів

2.     Завдання до лабораторної роботи №6

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