Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Проектування інформаційних систем.doc
Скачиваний:
158
Добавлен:
21.09.2019
Размер:
28.77 Mб
Скачать

21.1. Стан дії

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

Графічно стан дії зображується фігурою, що нагадує прямокутник, бічні сторони якого замінені опуклими дугами (рис. 21.1). Всередині цієї фігури записується вираз дії (action-expression), яка повинна бути унікальною в межах однієї діаграми діяльності.

а) Звичайна дія б) Вираз

Рис. 21.1. Графічне зображення стану дії

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

Іноді виникає необхідність представити на діаграмі діяльності деяку складну дію, яка, у свою чергу, складається з декількох простіших дій. У цьому випадку можна використовувати спеціальне позначення так званого стану піддіяльності (subactivity state). Такий стан є графом діяльності і позначається спеціальною піктограмою в правому нижньому кутку символу стану дії (рис. 21.2). Ця конструкція може застосовуватися до будь-якого елементу мови UML, яка підтримує "вкладеність" своєї структури. При цьому піктограма може бути додатково помічена типом вкладеної структури.

Рис. 21.2. Графічне зображення стану піддіяльності

Кожна діаграма діяльності повинна мати єдиний початковий і єдиний кінцевий стани. Вони мають такі ж позначення, як і на діаграмі станів (див. рис. 25.4). При цьому кожна діяльність починається в початковому стані і закінчується в кінцевому стані. Саму діаграму діяльності прийнято розташовувати так, щоб дії слідували зверху вниз. У цьому випадку початковий стан зображається у верхній частині діаграми, а кінцевий – в її нижній частині.

21.2. Переходи

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

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

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

Як приклад розглянемо фрагмент відомого алгоритму знаходження кореня квадратного рівняння. У загальному випадку після зведення рівняння другого степеня до канонічного вигляду: а*х*х + b*х + c = 0 необхідно обчислити його дискримінант. Причому, у разі від’ємного дискримінанта рівняння не має розв’язків на множині дійсних чисел, і подальші обчислення повинні бути припинені. При невід’ємному дискримінанті рівняння має розв’язки, корені якого можуть бути отримані на основі конкретної формули.

Графічно фрагмент процедури обчислення кореня квадратного рівняння може бути представлений у вигляді діаграми діяльності з трьома станами дії і розгалуженням (рис. 21.3). Кожний з переходів, що виходять із стану "Обчислити дискримінант", має сторожову умову, що визначає єдину гілку, якою може бути продовжено процес обчислення кореня залежно від знаку дискримінанта. Очевидно, що у разі його від’ємності, ми відразу потрапляємо в кінцевий стан, тим самим завершуючи виконання алгоритму в цілому.

Примітка

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

Рис. 21.3. Фрагмент діаграми діяльності для алгоритму знаходження кореня квадратного рівняння

У наступному прикладі (рис. 21.4) розраховується загальна вартість товарів, що купуються по кредитній картці в супермаркеті. Якщо ця вартість перевищує $50, то виконується аутентифікація особи власника картки. У разі позитивної перевірки (картка дійсна) або якщо вартість товарів не перевищує $50, відбувається зняття суми з рахунку і оплата вартості товарів. Якщо результат негативний (картка недійсна), оплата не відбувається, і товар залишається у продавця.

Примітка

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

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

Рис. 21.4. Різні варіанти розгалужень на діаграмі діяльності

Як правило, така риска зображується відрізком горизонтальної лінії, товщина якої декілька ширше за основні суцільні лінії діаграми діяльності. При цьому розділення (concurrent fork) має один вхідний перехід і декілька вихідних (рис. 21.5, а). Злиття (concurrent join), навпаки, має декілька вхідних переходів і один вихідний (рис. 21.5, б).

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

Рис. 21.5. Графічне зображення розділення і злиття паралельних потоків керування

Рис. 21.6. Діаграма діяльності для прикладу з приготуванням напою

Примітка

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

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

21.3. Доріжки

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

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

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

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

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

Рис. 21.7. Варіант діаграми діяльності з доріжками

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

21.4. Об'єкти

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

Рис. 21.8. Фрагмент діаграми діяльності для торгової компанії

21.4. Об'єкти

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

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

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

Повертаючись до попереднього прикладу з торговою компанією, можна відмітити, що центральним об'єктом процесу продажу є замовлення або точніше стан його виконання. Спочатку до дзвінка від клієнта, замовлення як об'єкт відсутній, і виникає лише після такого дзвінка. Проте це замовлення ще не заповнене до кінця, оскільки потрібно ще підібрати конкретний товар у відділі продажу. Після його підготовки він передається на склад, де разом з відпусткою товару замовлення остаточно дооформлюється. Нарешті, після отримання підтвердження про оплату товару ця інформація заноситься у замовлення, і воно вважається виконаним і закритим. Така інформація може бути представлена графічно у вигляді модифікованого варіанту діаграми діяльності цієї ж торгової компанії (рис. 21.9).

Примітка

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

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

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

Рис. 21.9. Фрагмент діаграми діяльності торгової компанії з об'єктом-замовленням

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

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

Рис. 21.10. Діаграма діяльності з синхронізацією паралельних дій