
- •Міністерство освіти та науки України в.В. Литвин, н.Б. Шаховська Проектування інформаційних систем
- •Передмова наукового редактора серії підручників «комп’ютинґ»
- •1.1. Складність програмного забезпечення
- •1.2. Структура складних систем
- •1.2.1. Приклади складних систем
- •1.2.2. П'ять ознак складної системи
- •1.2.3. Організована і неорганізована складність
- •1.3. Методи подолання складності
- •1.3.1. Роль декомпозиції
- •1.3.3. Роль абстракції
- •1.3.4. Роль ієрархії
- •1.4. Про проектування складних систем
- •1.4.1. Інженерна справа як наука і мистецтво
- •1.4.2. Сенс проектування
- •4. Методи подолання складності.
- •2.1. Базові означення
- •2.2. Методи проектування інформаційних систем
- •2.3. Види інформаційних систем
- •2.4. Рівні моделей даних
- •3. Види інформаційних систем.
- •3.1. Методологія процедурно-орієнтованого програмування
- •3.2. Методологія об'єктно-орієнтованого програмування
- •3.3. Методологія об'єктно-орієнтованого аналізу і проектування
- •3.4. Методологія системного аналізу і системного моделювання
- •4.1. Передісторія. Математичні основи
- •4.1.1. Теорія множин
- •4.1.2. Теорія графів
- •4.1.3. Семантичні мережі
- •4.2. Діаграми структурного системного аналізу
- •4.3. Основні етапи розвитку uml
- •3. Семантичні мережі.
- •5.1. Принципи структурного підходу до проектування
- •5.2. Структурний аналіз
- •5.3. Структурне проектування
- •5.4. Методологія структурного аналізу
- •5.5. Інструментальні засоби структурного аналізу та проектування
- •6.1. Основні елементи
- •6.2. Типи зв’язків
- •6.3. Техніка побудови
- •6.4. Діаграма бізнес – функцій
- •6.4.1. Призначення діаграми бізнес-функцій
- •6.4.2. Основні елементи
- •7.1. Призначення діаграм потоків даних та основні елементи
- •7.1.1. Зовнішні сутності
- •7.1.2. Процеси
- •7.1.3. Накопичувачі даних
- •7.1.4. Потоки даних
- •7.2. Методологія побудови dfd.
- •8.1. Діаграма «сутність-зв’язок»
- •8.2. Діаграма атрибутів
- •8.3. Діаграма категоризації
- •8.4. Обмеження діаграм сутність-зв’язок
- •8.5. Методологія idef1
- •9.1. Основні елементи
- •9.2. Типи керуючих потоків
- •9.3. Принципи побудови
- •10.1. Структурні карти Константайна
- •10.2. Структурні карти Джексона
- •11.1. Призначення case-технологій
- •11.2. Інструментальний засіб bPwin
- •11.2.4. Інші діаграми bpWin
- •11.2.5. Моделі as is і to be
- •11.3.1. Основні властивості
- •11.3.2. Стандарт idef1x
- •11.4. Програмний засіб Visio
- •12.1. Системний аналіз області наукових досліджень
- •12.1.1. Аналіз предметної області
- •12.2. Системний аналіз біржі праці
- •12.2.1. Дерево цілей
- •12.2.2. Опис об’єктів предметної області
- •12.2.3. Концептуальна модель
- •14.1. Еволюція об'єктної моделі
- •14.1.1. Основні положення об'єктної моделі
- •14.2. Складові частини об'єктного підходу
- •14.2.1. Парадигми програмування
- •14.2.2. Абстрагування
- •14.2.3. Інкапсуляція
- •14.2.4. Модульність
- •14.2.5. Ієрархія
- •14.2.7. Паралелізм
- •14.2.8. Збереженість
- •14.3. Застосування об'єктної моделі
- •14.3.1. Переваги об'єктної моделі
- •14.3.2. Використання об'єктного підходу
- •14.3.3. Відкриті питання
- •15.1. Природа об'єкта
- •15.1.1. Що є й що не є об'єктом?
- •15.1.2. Стан
- •15.1.3. Поведінка
- •15.1.4. Ідентичність
- •Void drag(DisplayItem I); // Небезпечно
- •15.2. Відношення між об'єктами
- •15.2.1. Типи відношень
- •15.2.2. Зв'язки
- •15.2.3. Агрегація
- •15.3. Природа класів
- •15.3.1. Що таке клас?
- •15.3.2. Інтерфейс і реалізація
- •15.3.3. Життєвий цикл класу
- •15.4. Відношення між класами
- •15.4.1. Типи відношень
- •15.4.2. Асоціація
- •15.4.3. Успадкування
- •15.4.4. Агрегація
- •15.4.5. Використання
- •15.4.6. Інсталювання (Параметризація)
- •15.4.6. Метакласи
- •15.5. Взаємозв'язок класів і об'єктів
- •15.5.1. Відношення між класами й об'єктами
- •15.5.2. Роль класів і об'єктів в аналізі й проектуванні
- •16.1. Важливість правильної класифікації
- •16.1.1. Класифікація й об’єктно-орієнтовне проектування
- •16.1.2. Труднощі класифікації
- •16.2. Ідентифікація класів і об'єктів
- •16.2.1. Класичний і сучасний підходи
- •16.2.2. Об’єктно-орієнтований аналіз
- •16.3. Ключові абстракції й механізми
- •16.3.1. Ключові абстракції
- •16.3.2. Ідентифікація механізмів
- •17.1. Призначення мови uml
- •17.2. Загальна структура мови uml
- •17.3. Пакети в мові uml
- •17.4. Основні пакети мета-моделі мови uml
- •17.5. Специфіка опису мета-моделі мови uml
- •17.6. Особливості зображення діаграм мови uml
- •18.1. Варіант використання
- •18.2. Актори
- •18.3. Інтерфейси
- •18.4. Примітки
- •18.5. Відношення на діаграмі варіантів використання
- •18.5.1. Відношення асоціації
- •13.5.2. Відношення розширення
- •18.5.3. Відношення узагальнення
- •18.5.4. Відношення включення
- •18.6. Приклад побудови діаграми варіантів використання
- •18.7. Рекомендації з розроблення діаграм варіантів використання
- •19.1. Клас
- •19.1.1. Ім'я класу
- •19.1.2. Атрибути класу
- •19.1.3. Операція
- •19.2. Відношення між класами
- •19.2.1. Відношення залежності
- •19.2.2. Відношення асоціації
- •19.2.3. Відношення агрегації
- •19.2.4. Відношення композиції
- •19.2.5. Відношення узагальнення
- •19.3. Інтерфейси
- •19.5. Шаблони або параметризовані класи
- •19.6. Рекомендації з побудови діаграми класів
- •20.1. Автомати
- •20.2. Стан
- •20.2.1. Ім'я стану
- •20.2.2. Список внутрішніх дій
- •20.2.3. Початковий стан
- •20.2.4. Кінцевий стан
- •20.3. Перехід
- •20.3.2. Сторожова умова
- •20.3.3.Вираз дії
- •15.4. Складений стан і підстан
- •20.4.1. Послідовні підстани
- •20.4.2. Паралельні підстани
- •15.5. Історичний стан
- •20.6. Складні переходи
- •15.6.1. Переходи між паралельними станами
- •20.6.2. Переходи між складеними станами
- •20.6.3. Синхронізуючі стани
- •20.7. Рекомендації з побудови діаграм станів
- •21.1. Стан дії
- •21.2. Переходи
- •21.5. Рекомендації до побудови діаграм діяльності
- •22.1.1. Лінія життя об'єкта
- •22.1.2. Фокус керування
- •22.2. Повідомлення
- •22.2.1. Розгалуження потоку керування
- •22.2.2. Стереотипи повідомлень
- •22.2.3. Тимчасові обмеження на діаграмах послідовності
- •22.2.4. Коментарі або примітки
- •22.3. Приклад побудови діаграми послідовності
- •22.4. Рекомендації з побудови діаграм послідовності
- •23.1. Кооперація
- •23.2.1. Мультиоб'єкт
- •23.2.2. Активний об'єкт
- •23.2.3. Складений об'єкт
- •23.3. Зв'язки
- •23.3.1. Стереотипи зв'язків
- •23.4. Повідомлення
- •23.4.1. Формат запису повідомлень
- •23.5. Приклад побудови діаграми кооперації
- •23.6. Рекомендації з побудови діаграм кооперації
- •24.1. Компоненти
- •24.1.1. Ім'я компоненту
- •24.1.2. Види компонент
- •24.2. Інтерфейси
- •24.3. Залежності
- •24.4. Рекомендації з побудови діаграми компонент
- •25.1. Вузол
- •25.2. З'єднання
- •25.3. Рекомендації з побудови діаграми розгортання
- •26.1. Загальна характеристика case-засобу Rational Rose
- •26.2. Особливості робочого інтерфейсу Rational Rose
- •26.1.1. Головне меню програми
- •26.1.2. Стандартна панель інструментів
- •26.1.3. Вікно браузера
- •26.1.4. Спеціальна панель інструментів
- •26.1.5. Вікно діаграми
- •26.1.6. Вікно документації
- •26.1.7. Вікно журналу
- •26.3. Початок роботи над проектом у середовищі Rational Rose
- •26.4. Розроблення діаграми варіантів використання в середовищі Rational Rose
- •26.5. Розроблення діаграми класів у середовищі Rational Rose
- •26.6. Розроблення діаграми станів у середовищі Rational Rose
- •26.7. Розроблення діаграми послідовності в середовищі Rational Rose
- •26.8. Розроблення діаграми кооперації в середовищі Rational Rose
- •26.9. Розроблення діаграми компонентів у середовищі Rational Rose
- •26.10. Розроблення діаграми розгортання в середовищі Rational Rose
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. Діаграма діяльності з синхронізацією паралельних дій