24.5.5. Побудова діаграм класів

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

Рис. 24.7. Діаграма класів для програми landlord

24.5.6. Побудова діаграм послідовностей

Перш ніж почати писати код програми, було б логічно з'ясувати детальніше, як виконується кожен крок кожного варіанту використання. Для цього можна побудувати діаграми послідовностей UML. Це один з двох типів діаграм взаємодії UML (другий тип – сумісна діаграма). І на тій, і на іншій відображається, як події розгортаються в часі. Просто діаграма послідовностей наочніше зображає процес перебігу часу. На ній вертикальна вісь – це час. Вона "починається" вгорі і тече зверху вниз за діаграмами. Вгорі знаходяться імена об'єктів, які братимуть участь в даному варіанті використання. Дія зазвичай починається з того, що об'єкт, розташований зліва, посилає повідомлення об'єкту, розташованому справа. Зазвичай чим правіше роз­­ташований об'єкт, тим нижче його значущість для програми або більше його залеж­ність від інших.

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

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

Діаграма послідовностей для варіанту використання "Почати програму"

Звернемо Вашу увагу на деякі з діаграм послідовностей нашої програми. Почнемо з найпростішою з них. На рис. 24.8 показана діаграма для варіанту використання "Почати програму".

Під час запуску програми визначається userInterface – клас підтримки екрану інтерфейсу користувача, який ми так довго обговорювали, кажучи про варіанти використання. Припустимо, програма створює єдиний об'єкт класу під назвою theUserInterface. Саме цей об'єкт породжує всі варіанти використання. Він з'являється зліва на діаграмі послідовностей. Як бачите, ми на цьому етапі вже перейшли до нормальних імен класів, прийнятих у процесі написання коду програми.

Рис. 24.8. Діаграма послідовностей для варіанту використання "Почати програму"

Коли вступає в роботу об'єкт theUserInterface, перше, що він має виконати, то створити три основні структури даних у програмі. Це об'єкти класів tenantList, rentRecord і expenceRecord. Виходить, що вони народжуються безіменними, оскільки для їх створення використовується new. Імена мають тільки покажчики на них. Як же нам їх назвати? На щастя, як ми переконалися на прикладі об'єктних діаграм, UML надає декілька способів іменування об'єктів. Якщо справжнє ім'я невідоме, то можна використовувати замість нього двокрапку з іменем класу (:tenantList). На діаграмі підкреслення імені і двокрапка перед ним нагадує про те, що ми маємо справу з об'єктом, а не з класом.

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

Горизонтальні лінії є повідомленням (тобто виклики методів). Суцільна стрілка свідчить про нормальний синхронний виклик функції, відкрита – про асинхронну подію.

Прямокутник, розташований під theUserInterface, називається блоком активності (або центром керування). Він показує, що розташований над ним об'єкт є активним. У звичайній процедурній програмі, такій, як наша (landlord), "активний" означає, що метод даного об'єкта або виконується сам, або викликав на виконання іншу функцію, яка ще не завершила свою роботу. Три інші об'єкти на цій діаграмі не є активними, тому що theUserInterface ще не послав їм активізаційних повідомлень.

Діаграма послідовностей для варіанту використання "Виведення переліку мешканців"

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

Що ми бачимо? Об'єкт theUserInterface дає завдання об'єкту tenantList вивести себе на екран (викликом його методу display()), а той, своєю чергою, виводить всі об'єкти класу tenant. Зірочка означає, що повідомлення посилатиметься циклічно, а фраза в квадратних дужках [для усіх об'єктів tenant] повідомляє умову повторення¹.

Рис. 24.9. Діаграма послідовностей для варіанту використання "Виведення переліку мешканців"

Діаграма послідовностей для варіанту використання "Додати нового мешканця"

Нарешті, останнім прикладом діаграми послідовностей, який ми тут наводимо, є діаграма для варіанту використання "Додати нового мешканця". Вона показана на рис. 24.10. Сюди ми включили самого домовласника у вигляді об'єкта, який визначає різні дії. У нього є свій власний блок активності. За допомогою цього об'єкта можна повністю показати процес взаємодії користувача з програмою.

Рис. 24.10. Діаграма послідовностей для варіанту використання "Додати нового мешканця"

Користувач повідомляє програму про те, що він бажає додати нового мешканця. Об'єкт theUserInterface створює новий об'єкт класу tenantInputScreen. У цьому об'єкті є методи, що дають змогу отримати від користувача дані про мешканця, створити новий об'єкт типу tenant і викликати метод об'єкта класу tenantList для додавання в перелік знов створеного мешканця. Коли все це виконано, об'єкт theUserInterface віддаляється. Велика буква "X" в кінці лінії життя tenantInputScreen свідчить про те, що об'єкт видалений.

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

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