«Один день із життя білки» або від моделювання процесів до проектування автоматизованої системи обліку матеріальних цінностей «Білка-1.0» (Частина 1)
До чого тут «білка»?
Відразу поясню, до чого тут «білка». Натрапивши в Мережі на кумедні проекти для вивчення UML з опорою на предметну область, запозичену із сюжетів казок (наприклад, [1]), я для своїх студентів теж вирішила підготувати подібний приклад, щоб можна було вивчити для початку всього три види діаграм: Activity Diagram, Use-case Diagram та Class Diagram. Навмисне не перекладаю російською мовою назви діаграм, щоб уникнути суперечок про «труднощі перекладу». Що для чого – поясню трохи згодом. У цьому прикладі я використовую середовище Enterprise Architect від австралійської компанії [2] - Хороший інструмент за розумні гроші. А в рамках навчальних занять застосовую [3], непоганий безкоштовний засіб об'єктно-орієнтованого проектування, що підтримує стандарти UML2.0 і BPMN, без зайвих наворотів у частині образотворчих можливостей, але є достатнім для вивчення основ мови.
Автоматизувати ми збираємося діяльність з обліку матеріальних цінностей, що виникає у цих процесах.
...
Острів на морі лежить, (E1, E2)
Град на острові стоїть (E3, E1)
З золотоголовими церквами, (E4)
З теремами та садами; (E5, E6)
Ялина росте перед палацом, (E7, E8)
А під нею кришталевий будинок; (E9)
Білка там живе ручна, (A1)
Та витівниця яка! (A1)
Білка пісеньки співає, (P1, A1)
Так горішки все гризе, (P2)
А горішки не прості, (C1)
Всі золоті шкаралупки, (C2)
Ядра чистий смарагд; (C3)
Слуги білку стережуть, (P3, A2)
Служать їй різною прислугою (P4)
І приставлений дяк наказний (A3)
Суворий рахунок горіхам звістка; (P5, C1)
Віддає їй військо честь; (P6, A4)
Зі шкаралупок ллють монету, (P7, C2, C4)
Так пускають у хід світом; (P8)
Девки сиплють смарагд (P9, A5, C3)
У комори, та під спуд; (E10, E11)
...
(А.С.Пушкіна "Казка про царя Салтана, про сина його славного і могутнього богатиря князя Гвідона Салтановича і про прекрасну царівну Лебеді", — 10 років від задуму до публікації, між іншим!
Трохи про коди, які написані праворуч від рядків. “A” (від “Actor”) означає, що у рядку міститься інформація про учасника процесу. “C” (від “Class”) – інформація про об'єкти класів, які обробляються під час виконання процесів. "E" (від "Environment") - інформація про об'єкти класів, які характеризують довкілля виконання процесів. "P" (від "Process") - інформація про самі процеси.
До речі, точне визначення процесу також претендує на те, щоб стати причиною методологічних суперечок, хоча б через те, що бувають різні: бізнес-, виробничі, технологічні і т.д. і т.п. (ознайомитись можна, наприклад, [4] та [5]). Щоб уникнути полеміки, домовимося, що процес нас цікавить з погляду його повторюваності у часі та потреби в автоматизації, тобто. перекладанні виконання будь-якої частини операцій процесу на автоматизовану систему.
Нотатки із застосування діаграми Activity
Приступимо до моделювання нашого процесу та скористаємося для цього діаграмою Activity. Для початку поясню, як зазначені вище коди використовуватимуться в моделі. Пояснювати простіше на графічному прикладі, а заразом розберемо деякі (майже всі необхідні нам) елементи діаграми Activity.
Проаналізуємо наступний фрагмент:
...
Білка пісеньки співає, (P1, A1)
Так горішки все гризе, (P2)
А горішки не прості, (C1)
Всі золоті шкаралупки, (C2)
Ядра чистий смарагд; (C3)
...
У нас є два кроки процесу P1 та P2, учасник A1, та об'єкти трьох різних класів: об'єкт класу С1 надходить на вхід кроку, об'єкти класів С2 та С3 виходять на виході, як результат діяльності цього кроку P2 нашого процесу. Для діаграми використовуємо такі елементи, що моделюють.
Фрагмент нашого процесу можна представити приблизно так (рисунок 1).
Рисунок 1. Фрагмент діаграми Activity
Для організації простору та структурування діаграми Activity ми застосуємо не зовсім стандартний підхід з точки зору класичного використання нотації UML. Але є кілька причин. По-перше, просто до початку моделювання ми складемо так зване, угода щодо моделювання, у якому зафіксуємо всі особливості використання нотації По-друге, цей підхід був неодноразово успішно застосований на етапі бізнес-моделювання в реальних проектах створення програмних систем, результати були зафіксовані нашим невеликим авторським колективом у відповідному об'єкті авторського права [6], а також використані в навчальному посібнику [7]. Для діаграми Activity визначимо, що поле діаграми структуруємо за допомогою «плавальних» доріжок – Swim lanes. Назва доріжки буде відповідати типу елементів діаграми, які будуть розміщені на цій доріжці.
«Вхідні та вихідні артефакти»: на цій доріжці будуть розміщені елементи Objects - об'єкти, які використовуються або є результатом виконання певного кроку процесу.
«Кроки процесу»: сюди помістимо елементи Activity – дії учасників процесу.
«Учасники»: доріжка для елементів, які позначатимуть ролі виконавців дій у нашому процесі, для них ми будемо використовувати той самий моделюючий елемент Object – об'єкт, але додамо йому стереотип «Actor».
Наступна доріжка називається «Бізнес-правила» і на цій доріжці розмістимо у текстовому вигляді правила виконання кроків процесу, а використовуватимемо для цього моделюючий елемент Note – примітку.
Ми тут зупинимося, хоча додатково можна було б ще використати доріжку "Інструменти" для збирання відомостей про рівень автоматизації процесу. Ще може стати в нагоді доріжка «Посади та підрозділи учасників», її можна використовувати для зв'язку ролей з посадами та підрозділами учасників процесу.
Все те, що я щойно описала, і є фрагментом угоди щодо моделювання, ця частина угоди стосується правил організації однієї діаграми та відповідно правил її написання та читання.
Рецепт
Тепер розглянемо варіант моделювання системи саме від діаграми Activity. Це лише один із варіантів, зазначу, що він, звичайно, не єдиний. Діаграма Activity нас цікавитиме з погляду її ролі для переходу від моделювання процесу до проектування автоматизованої системи. Для цього дотримуватимемося методичних рекомендацій – своєрідного рецепту, що складається всього з п'яти етапів і передбачає розробку всього трьох видів діаграм. Застосування цього рецепту допоможе отримати формалізований опис процесу, який хочемо автоматизувати, і зібрати дані для проектування системи. А для студентів на початку вивчення UML це своєрідне рятувальне коло, яке не дасть потонути у всьому тому різноманітті образотворчих засобів та прийомів, які є в UML та сучасних засобах моделювання.
Ось, власне, сам рецепт, а далі йдуть діаграми, побудовані для нашої «казкової» предметної галузі.
Етап 1. Описуємо процес як діаграми Activity. Для процесу, в якому виділено більше 10 кроків, є сенс застосувати принцип декомпозиції кроків процесу, щоб підвищити читабельність діаграми.
Етап 2. Виділяємо те, що можна автоматизувати (кроки можуть бути, наприклад, підсвічені на діаграмі).
Етап 3. Автоматизованого кроку потрібно поставити у відповідність функцію або функції системи (Ставлення може бути багато-багатьом), малюємо Use-case діаграму. Це функції нашої системи.
Етап 4. Опишемо внутрішню організацію АС за допомогою діаграми класів – Class. Плавальна дорога «Вхідні та вихідні об'єкти (документи)» на діаграмі Activity – це основа для побудови об'єктної моделі та моделі сутність-зв'язок.
Етап 5. Проаналізуємо нотатки на доріжці «Бізнес-правила», вони дають різного роду обмеження та умови, поступово трансформується у нефункціональні вимоги.
Отримана сукупність діаграм (Activity, Use-case, Class) дає нам формалізоване опис досить суворої нотації, тобто. має однозначне прочитання. Наразі можна розробляти технічне завдання, уточнювати специфікацію вимог тощо.
Приступимо до моделювання.
Етап 1. Описуємо процес як діаграми Activity
Нагадаю, що поле діаграми ми структурували за допомогою плавальних доріжок, на кожній доріжці розташовуються елементи одного виду (Малюнок 2). Крім описаних вище елементів діаграми використовуватимемо додаткові елементи, давайте з опишемо.
Рішення (Decision) означає на діаграмі точку розгалуження нашого процесу, а злиття потоків (Merge) – точку їх возз'єднання. У квадратних дужках на переходах записано умови переходу.
Між двома синхронізаторами (Fork) ми показуватимемо паралельні гілки процесу.
У нашого процесу може бути лише один початок – одна точка входу (Initial). А ось завершень (Final) може бути й кілька, але не для нашої конкретної діаграми.
Стрілець виходить досить багато, при великій кількості елементів і зв'язків можна виділити спочатку етапи процесу, а потім виконувати декомпозицію цих етапів. Але наш «казковий» процес мені хотілося б для наочності показати цілком на одній діаграмі, при цьому, звичайно, потрібно домагатися, щоб стрілки «не склеювалися», можна було б точно відстежити, що з чим пов'язано.
Рисунок 2. Діаграма Activity – загальний вигляд процесу
Т.к. у віршованих рядках деякі деталі процесу опущені, довелося відновити, вони показані елементами з білим тлом. Дані деталі включають крок «Передачі/приймання на зберігання та переробку» та кілька вхідних та вихідних артефактів. Цей крок теж повністю розкриває процес, т.к. нам потрібно було б окремо позначити крок передачі та крок прийому, та ще й для шкаралупок додати окремий крок, а ще домислити, що спочатку всі ці матеріальні цінності мають десь тимчасово зберігатися тощо. і т.п.
Ще звернемо увагу, що залишилося без відповіді питання про походження горіхів – звідки вони беруться і як потрапляють до білки? І це питання (воно виділено червоним кольором шрифту у примітці – елемент Note) потребує окремого опрацювання! Так і працює аналітик – по крихтах збираючи інформацію, роблячи припущення та отримуючи «окей» або «не-окей» від експертів предметної галузі – дуже важливих і просто незамінних людей на етапі бізнес-моделювання під час створення систем.
Зауважимо також, що крок процесу P5 складається з двох частин.
І кожна частина ми декомпозуємо і розглянемо докладніше (Малюнок 3, Малюнок 4), т.к. діяльність, що виконується у межах саме цих кроків, буде автоматизована.
Рисунок 3. Діаграма Activity – деталізація (частина1)
Рисунок 4. Діаграма Activity – деталізація (частина2)
Етап 2. Виділяємо те, що можна автоматизувати
Кроки, що підлягають автоматизації на діаграмах, виділені кольором (див. Рисунок 3, Малюнок 4).
Усі їх виконує один учасник процесу – Дяк наказний:
- Вносить інформацію про вагу горіха у відомість;
- Вносить інформацію про передачу горіха у відомість;
- Фіксує факт перетворення горіха на шкаралупки та ядро;
- Вносить інформацію про ядро горіха у відомість;
- Вносить інформацію про шкаралупи горіха у відомість.
Аналіз виконаної роботи. Що далі?
Отже, ми виконали велику підготовчу роботу: зібрали інформацію про процес, який маємо намір автоматизувати; почали формувати угоду щодо моделювання (поки що тільки в частині використання діаграми Activity); виконали моделювання процесу і навіть провели декомпозицію кількох його кроків; виділили кроки процесу, які автоматизуватимемо. Тепер ми готові перейти до наступних етапів та розпочати проектування функцій системи та її внутрішньої організації.
Як відомо, теорія без практики – ніщо. Потрібно обов'язково скуштувати "моделювання" своїми руками, це корисно і для усвідомлення запропонованого підходу. Наприклад, можна попрацювати у середовищі моделювання [3]. Ми декомпозували лише частину кроків діаграми загального виду процесу (див. рис. 2). Як практичне завдання може бути запропоновано повторити всі діаграми в середовищі Modelio та виконати декомпозицію кроку «Передача/прийом на зберігання та переробку».
Роботу в конкретних середовищах моделювання ми поки що не розглядаємо, але це може стати предметом самостійних статей та оглядів.
У другій частині статті ми розберемо прийоми моделювання та проектування, необхідні на 3-5 етапах, використовуватимемо UML діаграми Use-case та Class. Далі буде.
Список джерел
- Сайт "UML2.ru". Форум Співтовариства аналітиків. Спільний розділ. приклади. Приклади казок оформлені у вигляді UML діаграм. [Електронний ресурс] Режим доступу: Веб:
- Сайт Sparx Systems. [Електронний ресурс] Режим доступу: Веб:
- Сайт Modelio. [Електронний ресурс] Режим доступу: Веб:
- Великий словник енциклопедії. Процес (тлумачення). [Електронний ресурс] Режим доступу: Веб:
- Сайт "Організація ефективного управління". Блог. Рубрика «Управління бізнес-процесами». Визначення бізнес-процесу. [Електронний ресурс] Режим доступу: Веб:
- Свідоцтво № 18249 про реєстрацію та депонування твору результату інтелектуальної діяльності. Алфімов Р.В., Золотухіна Є.Б., Краснікова С.А. Рукопис навчально-методичного посібника під назвою «Моделювання предметної галузі з використанням Enterprise Architect» // 2011р.
- Золотухіна Є.Б., Вишня А.С., Краснікова С.А. Моделювання бізнес-процесів. - М.: КУРС, НІЦ ІНФРА-М, ЕБС Znanium.com. - 2017.
Джерело: habr.com