Приклад виконання лабораторної роботи

Після запуску програми VP-UML, для початку побудови діаграми варіантів використання, необхідно на стартовій сторінці обрати діаграму Use Case (рисунок 4.15).

Рисунок 4.15 - Бланк діаграми варіантів взаємодії

На панелі інструментів для даної діаграми присутні всі необхідні умовні позначення об'єктів діаграми (таблиця 4.1).

Таблиця 4.1 - Інструменти спеціальної панелі діаграми схем взаємодії.

Як приклад розглянемо побудову діаграми, показаної на рисунку 4.16. Для нанесення на діаграму дійової особи на панелі інструментів вибирається кнопка із зображенням чоловічка, для варіанту використання використовується кнопка із зображенням еліпса. Після натискання необхідної кнопки (дійової особи або варіанту використання), необхідно перемістити покажчик миші до тієї області, де буде розташовуватися новий об'єкт діаграми, і натиснути ліву кнопку миші. Тепер необхідно ввести назву нового об'єкта.

Рисунок 4.16 - Зв'язок асоціації.

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

Рисунок 4.17 - Зв'язок асоціації

Для цього необхідно встановити покажчик миші на бік лінії зв'язку асоціації, протилежну майбутньому вказівником напрямки зв'язку та викликати контекстне меню правою кнопкою миші. У меню, вибрати пункт «Navigable» і потім клацнути по пункту «Unspecified».

Після завершення всі необхідні дії, готова діаграма показана на рисунку 4.18.

Рисунок 4.18 - Діаграма варіантів використання

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

Рисунок 4.19 – Короткий опис варіанту використання

4.5.2. Лабораторна робота № 2 «Діаграми класів»

Мета роботи: освоїти прийоми розробки і побудови діаграми класів.

Зміст роботи:

1. створення і підготовка бланка діаграми;

2. виділення з виданого завдання основних класів системи;

3. співвіднесення класів системи з атрибутами і операціями;

4. розташування класів на діаграмі;

5. створення зв'язків між об'єктами діаграми;

6. додавання в класи атрибутів і операцій;

7. розстановка множинності;

8. збереження побудованої діаграми.

Теоретична частина

Діаграмою класів (Class diagram) називають діаграму, на якій показано безліч класів, інтерфейсів, кооперацій і відносин між ними. Її зображують у вигляді безлічі вершин і дуг.

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

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

Зазвичай діаграми класів використовуються для таких цілей:

• для моделювання словника системи. Моделювання словника системи передбачає прийняття рішення про те, які абстракції є частиною системи, а які - ні. За допомогою діаграм класів ви можете визначити ці абстракції та їх обов'язки;

• для моделювання простих кооперацій. Кооперація - це спільнота класів, інтерфейсів та інших елементів, що працюють спільно для забезпечення деякого кооперативного поведінки, більш значущого, ніж сума складових його елементів. Наприклад, моделюючи семантику транзакцій в розподіленій системі, ви не зможете зрозуміти процеси, що відбуваються, дивлячись на один-єдиний клас, оскільки відповідна семантика забезпечується декількома спільно працюють класами. За допомогою діаграм класів вдається візуалізувати і специфікувати ці класи і відносини між ними;

• для моделювання логічної схеми бази даних. Логічну схему можна уявляти собі як креслення концептуального проекту бази даних. У багатьох сферах діяльності потрібно зберігати стійку (persistent) інформацію в реляційної або об'єктно-орієнтованої базі даних. Моделювати схеми також можна за допомогою діаграм класів.

Стереотипи класів

Стереотипи - це механізм, що дозволяє розділяти класи на категорії. В UML визначено три основних стереотипу класів: Boundary (кордон), Entity (сутність) і Control (управління).

Граничними класами (boundary classes) називаються такі класи, які розташовані на кордоні системи і всього навколишнього середовища. Це екранні форми, звіти, інтерфейси з апаратурою (такий як принтери або сканери) та інтерфейси з іншими системами. Щоб знайти граничні класи, треба досліджувати діаграми варіантів використання. Кожному взаємодії між дійовою особою і варіантом використання повинен відповідати, принаймні, один граничний клас. Саме такий клас дозволяє чинному особі взаємодіяти з системою.

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

Керуючі класи (control classes) відповідають за координацію дій інших класів. Зазвичай у кожного варіанту використання є один керуючий клас, який контролює послідовність подій цього варіанту використання.

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

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

Крім згаданих вище стереотипів можна створювати і свої власні.

Атрибути

Атрибут - це елемент інформації, пов'язаний з класом. Наприклад, у класу Company (компанія) можуть бути атрибути Name (Назва), Address (Адреса) і NumberOfEmployees (Число службовців).

Так як атрибути містяться всередині класу, вони приховані від інших класів. У зв'язку з цим може знадобитися вказати, які класи мають право читати і змінювати атрибути. Це властивість називається видимістю атрибута (attribute visibility).

У атрибута можна визначити чотири можливі значення цього параметра. Розглянемо кожен з них в контексті приклад (малюнок 4.11). Нехай у нас є клас Employee з атрибутом Address і клас Company:

• Public (загальний, відкритий). Це значення видимості припускає, що атрибут буде видно усіма іншими класами. Будь клас може переглянути або змінити значення атрибута. В такому разі клас Company може змінити значення атрибута Address класу Employee. Відповідно до нотацією UML загальному атрибуту передує знак «+».

• Private (закритий, секретний). Відповідний атрибут не видно ніяким іншим класом. Клас Employee буде знати значення атрибута Address і зможе змінювати його, але клас Company не зможе його ні побачити, ні редагувати. Якщо це знадобиться, він повинен попросити клас Employee переглянути або змінити значення цього атрибута, що зазвичай робиться за допомогою спільних операцій. Закритий атрибут позначається знаком «-» відповідно до нотацією UML.

• Protected (захищений). Такий атрибут доступний тільки самому класу і його нащадкам. Припустимо, що у нас є два різних типи співробітників - з погодинною оплатою і на окладі. Таким чином, ми отримуємо два інших класу HourlyEmp і SalariedEmp, які є нащадками класу Employee. Захищений атрибут Address можна переглянути або змінити з класів Employee, HourlyEmp і SalariedEmp, але не з класу Company. Нотація UML для захищеного атрибута - це знак «#».

• Package or Implementation (пакетний). Припускає, що даний атрибут є загальним, але тільки в межах його пакета. Припустимо, що атрибут Address має пакетну видимість. В такому випадку він може бути змінений з класу Company, тільки якщо цей клас знаходиться в тому ж пакеті. Цей тип видимості не позначається ніяким спеціальним значком.

Рисунок 4.20 - Видимість атрибутів

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

Операції

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

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

У мові UML операції мають наступну нотацію:

Ім'я Операції (аргумент1: тип даних аргумента1, аргумент2: тип даних аргумента2, ...): тип значення, що повертається

Слід розглянути чотири різних типи операцій.

• Операції реалізації (implementer operations) реалізують деякі бізнес-функції. Такі операції можна знайти, досліджуючи діаграми взаємодії.

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

• Операції управління (manager operations) керують створенням і знищенням об'єктів. У цю категорію потрапляють конструктори і деструктори класів.

• Операції доступу (access operations) використовуються для перегляду або зміни значення закритих або захищених атрибутів. Нехай, наприклад, у нас є атрибут Salary класу Employee. Ми не хочемо, щоб всі інші класи могли змінювати цей атрибут. Замість цього до класу Employee ми додаємо дві операції доступу - GetSalary і SetSalary. До першої з них, що є загальною, можуть звертатися й інші класи. Вона просто отримує значення атрибута Salary і повертає його викликав її класу.

Операція SetSalary також є загальною, вона допомагає викликав її класу встановити нове значення атрибута Salary. Ця операція може містити будь-які правила і умови перевірки, які необхідно виконати, щоб зарплата могла бути змінена. Такий підхід дає можливість безпечно інкапсулювати атрибути всередині класу, захистивши їх від інших класів, але все ж дозволяє здійснити до них контрольований доступ. Створення операцій Get і Set (отримання і зміни значення) для кожного атрибута класу є стандартом.

• Допоміжними операціями (helper operations) називаються такі операції класу, які необхідні йому для виконання його відповідальностей, але про які інші класи не повинні нічого знати. Це закриті і захищені операції класу.

Щоб ідентифікувати операції, виконайте наступні дії:

1. вивчіть діаграми послідовності і кооперативні діаграми. Більша частина повідомлень на цих діаграмах є операціями реалізації.

Рефлексивні повідомлення будуть допоміжними операціями.

2. розгляньте керуючі операції. Може знадобитися додати конструктори і деструктори.

3. розгляньте операції доступу. Для кожного атрибута класу, з яким повинні будуть працювати інші класи, треба створити операції Get і Set.

Зв'язки

Зв'язок являє собою семантичну взаємозв'язок між класами. Вона дає класу можливість дізнаватися про атрибути, операціях і зв'язках іншого класу. Іншими словами, щоб один клас міг послати повідомлення іншому на діаграмі послідовності чи кооперативної діаграмі, між ними повинна існувати зв'язок.

Існують чотири типи зв'язків, які можуть бути встановлені між класами:

- асоціації, залежності, агрегації і узагальнення.

Асоціація (association) - це семантична зв'язок між класами. Їх малюють на діаграмі класів у вигляді звичайної лінії (рисунок 4.21).

Рисунок 4.21 – Асоціація

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

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

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

Зв'язки залежності (dependency) також відображають зв'язок між класами, але вони завжди однонаправлені і показують, що один клас залежить від визначень, зроблених в іншому. Залежності зображують у вигляді стрілки, проведеної пунктирною лінією (рисунок 4.22).

Рисунок 4.22 – Залежність

При генерації коду для цих класів до них не будуть додаватися нові атрибути.

Однак, будуть створені специфічні для мови оператори, необхідні для підтримки зв'язку. Наприклад, на мові С + + в код увійдуть необхідні оператори # include.

Агрегації (aggregations) представляють собою більш тісну форму асоціації. Агрегація - це зв'язок між цілим і його частиною. Наприклад, у вас може бути клас Автомобіль, а також класи Двигун, Покришки й класи для інших частин автомобіля. В результаті об'єкт класу Автомобіль буде складатися з об'єкта класу Двигун, чотирьох об'єктів покришок і т. д. Агрегації візуалізують у вигляді лінії з ромбиком у класу, що є цілим (рисунок 4.23).

Рисунок 4.23 – Агрегація

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

Таке каскадне видалення нерідко розглядається як частина визначення агрегації, проте воно завжди мається на увазі в тому випадку, коли множинність ролі становить 1 .. 1; наприклад, якщо потрібно видалити Клієнта, то це видалення має поширитися і на Замовлення (і, в свою чергу, на рядки замовлення).

За допомогою узагальнень (generalization) показують зв'язку спадкування між двома класами. Більшість об'єктно-орієнтованих мов безпосередньо підтримують концепцію наслідування. Вона дозволяє одному класу успадковувати всі атрибути, операції та зв'язку іншого. Мовою UML зв'язку спадкування називають узагальненнями і зображують у вигляді стрілок від класу-нащадка до класу-предка (рисунок 4.24).

Рисунок 4.24 – Узагальнення

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

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

Наприклад, при розробці системи реєстрації курсів в університеті можна визначити класи Course (курс) і Student (студент). Між ними встановлено зв'язок: у курсів можуть бути студенти, а у студентів - курси. Питання, на який повинен відповісти параметр множинності: «Скільки курсів студент може відвідувати в даний момент? Скільки студентів може за раз відвідувати один курс? »

Так як множинність дає відповідь на обидва ці питання, її індикатори встановлюються на обох кінцях лінії зв'язку. У прикладі реєстрації курсів ми вирішили, що один студент може відвідувати від нуля до чотирьох курсів, а один курс можуть слухати від 10 до 20 студентів. На діаграмі класів це можна зобразити, як показано на рисунку 4.25.

Рисунок 4.25 – Множинність

У мові UML прийняті наступні нотації для позначення множинності (таблиця 4.2).

Таблиця 4.2 - Нотації для позначення множинності.

Зв'язки можна уточнити за допомогою імен зв'язків або рольових імен. Ім'я зв'язку - це зазвичай дієслово або дієслівна фраза, що описує, навіщо вона потрібна. Наприклад, між класом Person (людина) і класом Company (компанія) може існувати асоціація. Можна задати в зв'язку з цим питання, чи є об'єкт класу Person клієнтом компанії, її співробітником або власником? Щоб визначити це, асоціацію можна назвати «employs» (наймає) (рисунок 4.26).

Рисунок 4.26 - Ім'я зв'язку

Імена у зв'язків визначати не обов'язково. Зазвичай це роблять, якщо причина створення зв'язку не очевидна. Ім'я показують біля лінії відповідної зв'язку.

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

Рольові імена - це зазвичай іменники або засновані на них фрази, їх показують на діаграмі поряд з класом, що грає відповідну роль. Як правило, користуються або рольовим ім'ям, або ім'ям зв'язку, але не обома відразу. Як і імена зв'язків, рольові імена не обов'язкові, їх дають, тільки якщо мета зв'язку не очевидна (рисунок 4.27).

Рисунок 4.27 - Рольові імена