- •1.1. Методологія процедурно‑ орієнтованого програмування
- •1.2. Методологія об'єктно-орієнтованого програмування
- •1.3. Методологія об'єктно-орієнтованого аналізу і проектування
- •1.4. Методологія системного аналізу і системного моделювання
- •Розділ 2
- •2.1. Передісторія. Математичні основи
- •Мал. 2.4. Приклади неорієнтованого (а) і орієнтованого (б) графів
- •Мал. 2.5. Приклади неорієнтованого (а) і орієнтованого (б) дерев
- •Мал. 2.6. Ієрархічні схеми неорієнтованого дерева (а) і орієнтованого дерева (б)
- •2.2. Діаграми структурного системного аналізу
- •I (Input) – вхід, т. Е. Все, що поступає в процес або споживається процесом.
- •2.3. Основні етапи розвитку uml
- •2. Забезпечити початкові поняття язика uml можливістю розширення і спеціалізації для більш точного представлення моделей систем в конкретній наочній області.
- •3. Опис язика uml повинен підтримувати таку специфікацію моделей, яка не залежить від конкретних язиків програмування і інструментальних засобів проектування програмних систем.
- •4. Опис язика uml повинен включати семантичний базис для розуміння загальних особливостей ооап.
- •7. Інтегрувати в себе новітні і якнайкращі досягнення практики ооап.
- •3.2. Загальна структура язика uml
- •3.3. Пакети в язиці uml
- •3.4. Основні пакети метамоделі язика uml
- •3.5. Специфіка опису метамоделі язика uml
- •3.6. Особливості зображення діаграм язика uml
- •4.1. Варіант використовування
- •4.2. Актори
- •4.3. Інтерфейси
- •4.4. Примітки
- •4.5. Відносини на діаграмі варіантів використовування
- •4.6. Приклад побудови діаграми варіантів використовування
- •4.7. Рекомендації по розробці діаграм варіантів використовування
- •5.1. Клас
- •5.2. Відносини між класами
- •5.5. Шаблони або класи, що параметризуються
- •5.6. Рекомендації по побудові діаграм класів
- •6.1. Автомати
- •Include – ця мітка використовується для звернення до підавтомата, при цьому наступний за нею вираз дії містить ім'я цього підавтомата.
- •6.3. Перехід
- •6.4. Складовий стан і підстан
- •6.5. Історичний стан
- •Мал. 6.10. Графічне зображення недавнього (а) і давнього (б) історичного стану
- •6.6. Складні переходи
- •Мал. 6.11. Графічне зображення паралельного переходу з паралельних станів (а) і паралельного переходу в паралельні стани (б)
- •6.7. Заключні рекомендації по побудові діаграм станів
- •7.1. Стан дії
- •7.2. Переходи
- •7.5. Рекомендації по побудові діаграм діяльності
- •8.2. Повідомлення
- •Мал. 8.7. Діаграма послідовності із стереотипними значеннями повідомлень
- •8.3. Приклад побудови діаграми послідовності
- •8.4. Заключні рекомендації по побудові діаграм послідовності
- •9.1. Кооперація
- •9.3. Зв'язки
- •9.4. Повідомлення
- •9.6. Заключні рекомендації по побудові діаграм кооперації
- •10.1. Компоненти
- •10.2. Інтерфейси
- •10.3. Залежність
- •10.4. Рекомендації по побудові діаграми компонентів
- •11.1. Вузол
- •11.2. З'єднання
- •Мал. 11.4. Фрагмент діаграми розгортання із з'єднаннями меходу вузлами
- •11.3. Рекомендації по побудові діаграми розгортання
- •12.1. Загальна характеристика case‑ засобу Rational Rose 98/2000
- •12.2. Особливості робочого інтерфейсу Rational Rose
- •12.3. Початок роботи над проектом в середовищі Rational Rose
- •12.4. Розробка діаграми варіантів використовування в середовищі Rational Rose
- •12.5. Розробка діаграми класів в середовищі Rational Rose
- •12.6. Розробка діаграми станів в середовищі Rational Rose
- •12.7. Розробка діаграми послідовності в середовищі Rational Rose
- •12.8. Розробка діаграми кооперації в середовищі Rational Rose
- •12.9. Розробка діаграми компонентів в середовищі Rational Rose
- •12.10. Розробка діаграми розгортання в середовищі Rational Rose
7.1. Стан дії
Стан дії (асtion state) є спеціальним випадком стану з деякою вхідною дією і принаймні одним переходом, що виходить із стану. Цей перехід неявно припускає, що вхідна дія вже завершилася. Стан дії не може мати внутрішніх переходів, оскільки воно є елементарним. Звичайне використовування стану дії полягає в моделюванні одного кроку виконання алгоритму (процедури) або потоку управління.
Графічно стан дії зображається фігурою, що нагадує прямокутник, бічні сторони якого замінені опуклими дугами (мал. 7.1). Усередині цієї фігури записується вираз дії (асtion‑ expression), яка повинна бути унікальною в межах однієї діаграми діяльності.
Мал. 7.1. Графічне зображення стану дії
Дія може бути записане на природному язиці, деякому псевдокоді або язиці програмування. Ніяких додаткових або неявних обмежень при записі дій не накладається. Рекомендується як ім'я простої дії використовувати дієслово із словами пояснень (мал. 7.1, а). Якщо ж дія може бути представлене в деякому формальному вигляді, то доцільно записати його на тому язиці програмування, на якому передбачається реалізовувати конкретний проект (мал. 7.1, би).
Іноді виникає необхідність представити на діаграмі діяльності деяку складну дію, яка, у свою чергу, складається з декількох більш простих дій. В цьому випадку можна використовувати спеціальне позначення так званого стану черінь‑ діяльності (subactivity state). Такий стан є графом діяльності і позначається спеціальною піктограмою в правому нижньому кутку символу стану дії (мал. 7.2). Ця конструкція може застосовуватися до будь-якого елемента язика UML, який підтримує «вкладеність» своєї структури. При цьому піктограма може бути додатково помічена типом вкладеної структури.
Мал. 7.2. Графічне зображення стану черінь‑ діяльності
Кожна діаграма діяльності повинна мати єдине початкове і єдине кінцеве стани. Вони мають такі ж позначення, як і на діаграмі станів (див. мал. 6.4). При цьому кожна діяльність починається в початковому стані і закінчується в кінцевому стані. Саму діаграму діяльності прийнято розташовувати так, щоб дії слідували зверху вниз. В цьому випадку початковий стан зображатиметься у верхній частині діаграми, а кінцеве – в її нижній частині.
7.2. Переходи
Перехід як елемент язика UML був розглянутий на чолі 6. При побудові діаграми діяльності використовуються тільки переходи нетрігерів, т. е. такі, які спрацьовують відразу після завершення діяльності або виконання відповідної дії. Цей перехід переводить діяльність в подальший стан відразу, як тільки закінчиться дія в попередньому стані. На діаграмі такий перехід зображається суцільною лінією із стрілкою.
Якщо із стану дії виходить єдиний перехід, то він може не бути ніяк помічений. Якщо ж таких переходів дещо, то спрацювати може тільки один з них. Саме в цьому випадку для кожного з таких переходів повинно бути явно записано сторожову умову в прямих дужках (див. розділ 6). При цьому для всіх переходів, що виходять з деякого стану, повинна виконуватися вимога істинності тільки одного з них. Подібний випадок зустрічається тоді, коли послідовно виконувана діяльність повинна розділитися на альтернативні гілки залежно від значення деякого проміжного результату. Така ситуація одержала назву галуження, а для її позначення застосовується спеціальний символ.
Графічно галуження на діаграмі діяльності позначається невеликим ромбом, усередині якого немає ніякого тексту (мал. 7.3). В цей ромб може входити тільки одна стрілка від того стану дії, після виконання якої потік управління повинен бути продовжений по одній з гілок, що взаємно виключають. Прийнято вхідну стрілку приєднувати до верхньої або лівої вершини символу галуження. Стрілок, що виходять, може бути дві або більш, але для кожної з них явно указується відповідна сторожова умова у формі булевого виразу.
Як приклад розглянемо фрагмент відомого алгоритму знаходження коренів квадратного рівняння. В загальному випадку після приведення рівняння другого ступеня до канонічного вигляду: а*х*х + Ь*х + з = 0 необхідно обчислити його дискримінант. Причому, у разі негативного дискримінанта рівняння не має рішення на безлічі дійсних чисел, і подальші обчислення повинні бути припинені. При ненегативному дискримінанті рівняння має рішення, корені якого можуть бути одержані на основі конкретної розрахункової формули..
Графічно фрагмент процедури обчислення коренів квадратного рівняння може бути представлений у вигляді діаграми діяльності з трьома станами дії і галуженням (мал. 7.3). Кожний з переходів, що виходять із стану «Обчислити дискримінант», має сторожову умову, що визначає єдину гілку, по якій може бути продовжений процес обчислення коренів залежно від знака дискримінанта. Очевидно, що у разі нього отрицательности, ми відразу потрапляємо в кінцевий стан, тим самим завершуючи виконання алгоритму в цілому.
Примітка
Строго кажучи, перший із станів даного алгоритму виходить вважати станом черінь‑ діяльності, оскільки приведення квадратного рівняння до канонічного вигляду може зажадати декілька елементарних дій (приведення подібних і перенесення окремих членів рівняння з правої його частини в ліву). Тому для даного стану доцільно додати відповідну піктограму (як на мал. 7.2).
Мал. 7.3. Фрагмент діаграми діяльності для алгоритму знаходження коренів квадратного рівняння
В розглянутому прикладі, як видно з мал. 7.3, виконувані дії з'єднуються в кінцевому стані. Проте це зовсім не є обов'язковим. Можна зобразити ще один символ галуження, який матиме дещо вхідних переходів і що один виходить.
В наступному прикладі (мал. 7.4) розраховується загальна вартість товарів, що купуються по кредитній картці в супермаркеті. Якщо ця вартість перевищує $50, то виконується аутентифікація особи власника картки. У разі позитивної перевірки (картка дійсна) або якщо вартість товарів не перевищує $50, відбувається зняття суми з рахунку і оплата вартості товарів. При негативному результаті (картка недійсна) оплати не відбувається, і товар залишається у продавця.
Примітка
Як видно з цього ж малюнка, допускається використовувати замість сторожової умови слово «інакше», вказуюче на той перехід, який повинен спрацювати у разі невиконання сторожової умови галуження.
Мал. 7.4. Різні варіанти галужень на діаграмі діяльності
Один з найзначущіших недоліків звичайних блок-схем або структурних схем алгоритмів пов'язаний з проблемою зображення паралельних гілок окремих обчислень. Оскільки розпаралелювання обчислень істотно підвищує загальну швидкодію програмних систем, необхідні графічні примітиви для представлення паралельних процесів. В язиці UML для цієї мети використовується спеціальний символ для розділення і злиття паралельних обчислень або потоків управління. Таким символом є пряма риска, аналогічно позначенню переходу у формалізмі мереж Петрі.
Як правило, така риска зображається відрізком горизонтальної лінії, товщина якої дещо ширше за основні суцільні лінії діаграми діяльності. При цьому розділення (concurrent fork) має один вхідний перехід і що декілька виходять (мал. 7.5, а). Злиття (concurrent join), навпаки, має дещо вхідних переходів і що один виходить (мал. 7.5, би).
Для ілюстрації особливостей паралельних процесів виконання дій розглянемо той, що став вже класичним приклад з приготуванням напою. Гідність цього прикладу полягає в тому, що він практично не вимагає ніяких додаткових пояснень через свою очевидність (мал. 7.6).
Мал. 7.5. Графічне зображення розділення і злиття паралельних потоків управління
Мал. 7.6. Діаграма діяльності для прикладу з приготуванням напою
Примітка
Наявність паралелі виявляється в тому, що ми можемо зайнятися пошуками чашки під час приготування кави. Втім, оскільки вибір конкретних напоїв залишається за читачем, розробка відповідної діаграми діяльності може бути запропонована як вправа.
Таким чином, діаграма діяльності є не що інше, як спеціальний випадок діаграми станів, в якій все або більшість станів є діями або станами черінь‑ діяльності. А все або більшість переходів є нетригтерными переходами, які спрацьовують після закінчення дій або под‑ деятельностей в станах‑ джерелах.
7.3. Доріжки
Діаграми діяльності можуть бути використані не тільки для специфікації алгоритмів обчислень або потоків управління в програмних системах. Не менше важлива область їх вживання пов'язана з моделюванням бізнес‑ процесів. Дійсно, діяльність будь-якої компанії (фірми) також є не що інше, як сукупність окремих дій, направлених на досягнення необхідного результату. Проте стосовно бізнес‑ процесів бажане виконання кожної дії асоціювати з конкретним підрозділом компанії. В цьому випадку підрозділ несе відповідальність за реалізацію окремих дій, а сам бізнес‑ процес представляється у вигляді переходів дій з одного підрозділу до іншого.
Для моделювання цих особливостей в язиці UML використовується спеціальна конструкція, що одержало назву доріжки (swimlanes). Мається на увазі візуальна аналогія з плавальними доріжками в басейні, якщо дивитися на відповідну діаграму. При цьому всі стани дії на діаграмі діяльності діляться на окремі групи, які відділяються один від одного вертикальними лініями. Дві сусідні лінії і утворюють доріжку, а група станів між цими лініями виконується окремим підрозділом (відділом, групою, відділенням, філіалом) компанії (мал. 7.7).
Назви підрозділів явно указуються у верхній частині доріжки. Перетинати лінію доріжки можуть тільки переходи, які в цьому випадку позначають вихід або вхід потоку управління у відповідний підрозділ компанії. Порядок проходження доріжок не несе какой‑ либо семантичної інформації і визначається міркуваннями зручності.
Як приклад розглянемо фрагмент діаграми діяльності торгової компанії, обслуговуючої клієнтів по телефону. Підрозділами компанії є відділ прийому і оформлення замовлень, відділ продажів і склад.
Цим підрозділам відповідатимуть три доріжки на діаграмі діяльності, кожна з яких специфікує зону відповідальності підрозділу. В даному випадку діаграма діяльності містить в собі не тільки інформацію про послідовність виконання робочих дій, але і про те, який з підрозділів торгової компанії повинен виконувати ту або іншу дію (мал. 7.8).
Мал. 7.7. Варіант діаграми діяльності з доріжками
Мал. 7.8. Фрагмент діаграми діяльності для торгової компанії
З вказаної діаграми діяльності відразу видно, що після ухвалення замовлення від клієнта відділом прийому і оформлення замовлень здійснюється розпаралелювання діяльності на два потоки (перехід‑ розділення). Перший з них залишається в цьому ж відділі і пов'язаний з отриманням оплати від клієнта за замовлений товар. Другою ініціює виконання дії по підбору товару у відділі продажів (модель товару, розміри, колір, рік випуску і ін.). Після закінчення цієї роботи ініціюється дія по відпустці товару з складу. Проте підготовка товару до відправки в торговому відділі починається тільки після того, як буде одержана оплата за товар від клієнта і товар буде відпущений з складу (перехід‑ з'єднання). Тільки після цього товар відправляється клієнту, переходячи в його власність.
7.4. Об'єкти
В загальному випадку дії на діаграмі діяльності виконуються над тими або іншими об'єктами. Ці об'єкти або ініціюють виконання дій, або визначають деякий результат цих дій. При цьому дії специфікують виклики, які передаються від одного об'єкту графа діяльності до іншого. Оскільки в такому ракурсі об'єкти грають певну роль в розумінні процесу діяльності, іноді виникає необхідність явно вказати їх на діаграмі діяльності.
Для графічного представлення об'єктів, як вже згадувалося на чолі 5, використовуються прямокутник класу, з тією відмінністю, що ім'я об'єкту підкреслюється. Далі після імені може указуватися характеристика стану об'єкту в прямих дужках. Такі прямокутники об'єктів приєднуються до станів дії відношенням залежності пунктирною лінією із стрілкою. Відповідна залежність визначає стан конкретного об'єкту після виконання попередньої дії.
На діаграмі діяльності з доріжками той, що розташовує об'єкту, може мати деякий додатковий сенс. А саме, якщо об'єкт розташований на межі двох доріжок, то це може означати, що перехід до наступного стану дії в сусідній доріжці асоційований з готовністю деякого документа (об'єкт в деякому стані). Якщо ж об'єкт цілком розташований усередині доріжки, то і стан цього об'єкту цілком визначається діями даної доріжки.
Повертаючись до попереднього прикладу з торговою компанією, можна помітити, що центральним об'єктом процесу продажу є замовлення або вірніше стан його виконання. Спочатку до дзвінка від клієнта замовлення як об'єкт відсутнє і виникає лише після такого дзвінка. Проте це замовлення ще не заповнено до кінця, оскільки вимагається ще підібрати конкретний товар у відділі продажів. Після його підготовки він передається на склад, де разом з відпусткою товару замовлення остаточне дооформляется. Нарешті, після отримання підтвердження про оплату товару ця інформація заноситься в замовлення, і він вважається виконаним і закритим. Дана інформація може бути представлена графічно у вигляді модифікованого варіанту діаграми діяльності цієї ж торгової компанії (мал. 7.9).
Примітка
Більш докладно правила іменує об'єктів і їх використовування будуть розглянуті при побудові діаграми кооперації на чолі 9. Що стосується діаграм діяльності, то стосовно них об'єкти грають допоміжну роль і тому тут детально не розглядаються. Слід також пам'ятати, що на діаграмі діяльності один і той же об'єкт може бути зображений кілька разів, що не повинне вносити невизначеність в специфікацію станів дії.
Мал. 7.9. Фрагмент діаграми діяльності торгової компанії з об'єктом‑ замовленням
На закінчення слід зупинитися на необхідності синхронізації окремих дій на діаграмі діяльності. Така необхідність виникає всякий раз, коли паралельно виконувані дії роблять вплив на один на одного. Якщо пригадати матеріал розділу 6, то стосовно діаграми станів для цієї мети застосовувався спеціальний псевдостан – синхронізуюче стан. На діаграмі діяльності ніяких додаткових позначень не використовується, оскільки синхронізація паралельних процесів може бути реалізована за допомогою переходів «розділення‑ злиття».
Як приклад розглянемо спрощену ситуацію з моделюванням процесу споруди удома (див. розділ 6). Нагадаємо, що в даному прикладі споруда удома включає будівельні роботи (зведення фундаменту і стін, зведення даху і обробні роботи) і роботи по електрифікації удома (підведення електричної лінії, прокладка прихованої електропроводки і установка освітлювальних ламп). Синхронізація паралельного виконання цього комплексу робіт може бути явно вказана на діаграмі діяльності (мал. 7.10).
Мал. 7.10. Діаграма діяльності з синхронізацією паралельних дій
В розглянутому прикладі всі стани є станами черінь‑ діяльності. Це означає, що кожне з них можна деталізувати у вигляді окремого графа діяльності з відповідною діаграмою. Дійсно, стан черінь‑ діяльності «Підготовка ділянки» може включати такі дії, як очищення ділянки від дерев, вивіз цих дерев за межі ділянки, риття котловану під фундамент, установка тимчасових будов для складування будівельних матеріалів і інші роботи.
Втім, деякі із станів можуть бути і простими станами дії, у випадку якщо відповідна робота перетворюється на виконання елементарної дії, нерозкладної на окремі операції або прийоми.
