Завдання

1. Вивчити теоретичний| матеріал|, щодо| теми лабораторної| роботи|.

2. Відповісти на контрольні| запитання|.

3. В середовищі Rose створити діаграми Варіантів використання до своєї курсової роботи |.

4. Додати до діаграм потрібні спеціфікації |.

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

1. У чому сенс варіанту використання?

2. Яке призначення діаграм варіантів використання?

3. Назвіть основні властивості варіантів використання.

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

5. Що таке «дійова особа»?

6. Яку роль можуть грати дійові особи по відношенню до варіанту використання?

7. Яким чином аналіз зовнішніх подій дозволяє визначити варіанти використання системи?

Література: [1,2,11–13].

Лабораторная работа 3-4

Тема: Діаграми класів. Класи, об'єкти, відносини асоціацій

Мета роботи: Угрупувати класи до пакетів, побудувати декілька діаграм

Класів і відобразити на цих діаграмах класи і пакети системи.

Короткі теоретичні відомості

У Логічне уявлення моделі Rose входять:

• Класи

• Діаграми Класів

• Діаграми Варіантів Використання

• Атрибути і операції

• Асоціації

• Діаграми Станів

На діаграмах Класів відображаються деякі класи і пакети системи. Це статичні картини фрагментів системи і зв'язків між ними.

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

За умовчанням існує одна діаграма Класів, назва якої Головна (Main) і яка розташована безпосередньо під Логічним уявленням в браузере. На цій діаграмі відображують пакети класів моделі. Щоб відкрити Головну діаграму цього пакету виберіть її у пакеті діаграми Класів в середовищі Rose.

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

На мові UML класи зображають за допомогою наступної нотації:

Виявлення класів можна почати з вивчення потоку подій сценарію. Іменники в описі цього потоку дасть зрозуміти, що може бути класом. У загальному випадку іменники можуть відповідати наступним елементам:

• Дійова особа

• Клас

• Атрибут класу

• Вираз, що не є дійовою особою, класом або атрибутом.

Іншим способом є аналіз діаграм Послідовності і Кооперативних діаграм.

Кожен об'єкт діаграм Послідовності і Кооперативних діаграм повинен бути співвіднесений з відповідним класом. При виявленні класів слід розглянути три можливі стереотипи: суть (entity), межу (boundary) і управління (control).

Клас (parameterized class), що параметризується, — один із спеціальних типів класів. Він застосовується для створення сімейства інших класів. Клас, що зазвичай параметризується, є різновидом контейнера, його ще називають шаблоном. Зокрема, якщо у вас є клас List (Список), що параметризується, то за допомогою екземплярів цього класу ви можете створити такі класи, як EmployeeLisi. OrderList і AccountList (відповідні спискам співробітників, замовлень і рахунків.

На мові UML клас, що параметризується, зображається за допомогою наступної нотації:

Клас-наповнювач (instantiated class) є класом, що параметризується, аргументи якого мають фактичні значення. Зокрема, в розглянутому вище прикладі ми маємо справу із списком деяких елементів. Визначивши значення аргументу, ми отримаємо список співробітників. Відповідно до нотації UML, ім'я аргументу класу-наповнювача записується у кутових дужках (< >).

Утиліта класу (class utility) — це сукупність операцій. Наприклад, у вашій системі може бути сукупність математичних функцій (квадратний корінь, кубічний корінь і т.д.), які використовуються всією системою і не дуже добре підходять для якого-небудь конкретного класу. Ці функції можна зібрати разом і об'єднати в утиліту класу, яка використовується іншими класами системи.

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

Утиліта класу виглядає на діаграмі як клас "з тінню":

Метакласс (metaclass) — це клас, екземпляри якого є класами, а не об'єктами. До метакласів належать класи, що параметризуються, і утиліти класів, що параметризуються.

Для додавання метакласса:

Стереотип — це механізм, що дозволяє категоризувати класи. Допустимо, ви хочете знайти всі форми у вашій моделі. Для цього можна створити стереотип Form (Форма) і призначити його всім вікнам вашого застосування. Надалі при пошуку форм потрібно тільки шукати класи з цим стереотипом. На мові UML визначино три основні стереотипи: Boundary (Межа), Entity (Об'єкт) і Control (Управління).

Прикордонними класами (boundary classes) називаються такі класи, які розташовані на межі системи з рештою всього світу. Вони включають форми, звіти, інтерфейси з апаратурою (такий, як принтери або сканери) і інтерфейси з іншими системами. У UML прикордонні класи позначають таким чином:

Для виявлення прикордонних класів необхідно досліджувати діаграми Варіантів Використання. Для кожної взаємодії між дійовою особою і варіантом використання повинен існувати хоч би один прикордонний клас. Саме він дозволяє дійовій особі взаємодіяти з системою.

Класи-суть (entity classes) містять інформацію, що зберігається постійно. У нашій системі роботи з даними про співробітників хорошим прикладом такого класу є клас Employee. Класи-суть можна виявити в потоці подій і на діаграмах Взаємодії. Вони мають найбільше значення для користувача, і тому в їх назвах часто застосовують терміни з наочної області. На мові UML класи-суть представляють наступним символом:

Часто для кожного класу-суті створюють таблицю в базі даних. У цьому полягає ще одна відмінність від типового підходу до конструювання системи. Замість того щоб із самого початку задавати структуру бази даних, у нас тепер є можливість розробляти її на основі інформації, що отримується з об'єктної моделі. Це дозволяє відстежувати відповідність всіх полів бази даних і вимог до системи. Вимоги визначають потік подій. Потік подій визначає об'єкти, класи і атрибути класів. Кожен атрибут класу-суті стає полем в базі даних. Застосовуючи такий підхід, легко відстежувати відповідність між полями бази даних і вимогами до системи, що зменшує вірогідність збору непотрібної інформації.

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

У системі можуть застосовуватися і інші класи, що управляють, загальні для декількох варіантів використання. Наприклад, клас SecurityManager (Менеджер безпеки) може відповідати за контроль подій, пов'язаних з безпекою, а клас TransactionManager (Менеджер транзакцій) займатися координацією повідомлень, що відносяться до транзакцій з базою даних. Можуть бути і інші менеджери для роботи з такими елементами функціонування системи, як розділення ресурсів, розподілена обробка даних і обробка помилок.

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

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

Параметр Visibility (Видимість) показує, чи буде клас видний поза своїм пакетом. Ви можете вказати для класу одне з трьох значень:

Public (Відкритий) Цей клас видно решті всіх класів системи.

(98i) Protected, Private (Захищений, закритий) Клас може бути видний у вкладених в нього класах, "друзям" (friends) цього класу або з самого класу.

Package or Implementation (Пакет або реалізація) Клас може бути видний тільки з класів того ж пакету.

Поле Cardinality (Множинність) дозволяє вказати, скільки у даного класу повинно бути екземплярів. Наприклад, в системі обробки інформації про співробітників можна чекати наявність безлічі екземплярів у класу Employee: Джон Доу, Біл Сміт та інші. Отже, множинність цього класу потрібно визначити як п.

Множинність класу, що управляє, зазвичай дорівнює одиниці.

Будуючи модель, ви можете вказати кількість абсолютної або відносної пам'яті, яка, на вашу думку, буде потрібна для кожного об'єкту класу. Для цієї мети служить поле Space (Простір) вікна специфікації класу.

Це поле не застосовується для утиліт класів, утиліт класів-наповнювачів і утиліт класів, що параметризуються.

Кнопка	Опис	Назва
	Вибір елементу моделі	Selection Tool
	Введення тексту	Text Box
	Коментар	Note
	Зв'язок коментаря з елементом	Anchor Note to Item
	Клас	Class
	Інтерфейс	Interface
	Асоціація	Association
	Агрегація	Aggregation
	Прив'язка атрибуту	Link Attribute
	Додавання пакету	Package
	Залежність	Dependency
	Спадкоємство	Generalization
	Реалізація	Realize

У середовищі Rose на основі моделі можна генерувати DDL (Data Definition Language — Мова Опису Даних). DDL визначає структуру вашої бази даних.

При генерації DDL додаток Rose шукає стійкі (persistent) класи. Поле Persistence вікна специфікації класу застосовується для визначення цього параметра. Він может-принимать одне з наступних значень:

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

Transient (Тимчасовий) Інформація, що міститься в об'єктах класу, не зберігається після завершення роботи додатку.

Це поле не можна використовувати для утиліт класів, утиліт класів, що параметризуються, і утиліт класів-наповнювачів.

Паралелізм (concurrency) дозволяє описати, як поводитиметься клас у присутності декількох потоків управління. Для класу доступні чотири значення цього параметра:

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

Guarded (Що захищає) За наявності декількох потоків управління клас поводитиметься, як очікується, але щоб класи різних потоків не заважали один одному, вони повинні взаємодіяти один з одним.

Active (Активний) Клас матиме свій власний потік управління.

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

Абстрактним називається клас, який не наповнюється конкретним змістом (не інстанцируеться). Іншими словами, якщо клас А абстрактний, в пам'яті ніколи не буде об'єктів типу А.

Зазвичай абстрактні класи застосовують при роботі із спадкоємством. У них містяться дані і поведінка, загальні для декількох інших класів. Наприклад, у нас може бути клас Тварина з атрибутами Зростання, Колір і Різновид. Від цього класу успадковують три інших класу: Кішка, Собака і Птах. Кожен з них успадковує властивості Зростання, Колір і Різновид від класу Тварина і має свої власні унікальні атрибути і операції.

Об'єкти класу Тварина не створюються під час роботи додатку — всі об'єкти є тільки кішками, собаками і птахами. Клас Тварина є абстрактною, він описує, що загального є у кішок, собак і птахів.

На мові UML назву абстрактного класу на діаграмі пишуть курсивом:

Пакети (packages) застосовуються для групування класів, що володіють деякою спільністю. На мові UML пакет зображають наступним символом:

Об'єднувати класи можна, як завгодно, проте існує декілька найбільш поширених підходів. По-перше, можна групувати класи по стереотипу. У такому разі виходить один пакет з класами-суттю, один з прикордонними класами, один з класами, що управляють, і т.д. Цей підхід може бути корисний з погляду розміщення готової системи, оскільки прикордонні класи, ті що знаходяться на клієнтських машинах, вже опиняються в одному пакеті.

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

Інші пакети можуть називатися Employee Maintenance (Робота із співробітниками), Reporting (Підготовка звітів) і Error Handling (Обробка помилок). Перевага цього методу полягає в можливості повторного використання пакетів. Якщо уважно підійти до групування класів, можна отримати практично не залежні один від одного пакети. Наприклад, пакет Security можна використовувати і в інших додатках.

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