«Один день із життя білки» або від моделювання процесів до проектування автоматизованої системи обліку матеріальних цінностей «Білка-1.0» (Частина 2)
Короткий зміст попередньої серії
В ми використовували «казкову» предметну область, надихнуту прикладами вивчення діаграм UML з опорою на сюжети казок (див., наприклад, [1]). До початку моделювання ми домовилися щодо використання деяких елементів діаграми Activity та почали формувати угоду щодо моделювання. З урахуванням цих домовленостей ми на 1-му етапі описали процес у вигляді діаграм Activity, а на 2-му етапі виділили кроки процесу, для яких потрібна (і можлива) автоматизація.
Нагадаю, що автоматизувати ми збираємося діяльність з обліку матеріальних цінностей, що виникає у цих процесах.
...
Острів на морі лежить, (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)
...
(А.С.Пушкіна «Казка про царя Салтана, про сина його славного і могутнього богатиря князя Гвідона Салтановича і про прекрасну царівну Лебеді», )
У цьому прикладі я використовую середовище Enterprise Architect від австралійської компанії [2], а в рамках навчальних занять застосовую [3].
Нагадаю, що процеси бувають різні, ознайомитись можна, наприклад, [4] та [5].
Докладніше про застосовувані підходи до моделювання та проектування див. [6, 7].
Повну специфікацію UML див. [8].
Тепер ми готові перейти до наступних етапів та розпочати проектування функцій системи та її внутрішньої організації. Нумерацію малюнків буде продовжено.
Етап 3. Автоматизованого кроку потрібно поставити у відповідність функцію або функції системи
Розроблена автоматизована система (АС) призначена для ведення суворого обліку горіхів, пам'ятаєте? Для кожного виділеного кроку (див. Рисунок 3, Малюнок 4 ), який автоматизуватимемо, запишемо функціональну вимогу, застосовуючи приблизно таку конструкцію «У системі має бути реалізована можливість …» і розробимо діаграму Use-case. Зараз ми фактично доповнюємо нашу угоду щодо моделювання новими правилами. Поясню, які елементи будемо використовувати.
Між "Ролью користувача" та "Функцією" будемо використовувати зв'язок "Асоціація" (Малюнок 5), це означає, що для користувача з цією роллю доступне виконання цієї функції.
Малюнок 5. Використання зв'язку типу «Асоціація»
Від «Функції» до «Вимоги» проведемо зв'язок «Реалізація» (Малюнок 6), щоб показати, що ця вимога буде реалізована ось цими функціями, ставлення може бути і «багатьом до багатьох», тобто. одна функція може брати участь у реалізації кількох вимог, а реалізації вимоги може знадобитися більше однієї функції.
Малюнок 6. Використання зв'язку типу «Реалізація»
Якщо одна функція вимагає для свого виконання, щоб була виконана ще якась функція, причому обов'язково використовуватимемо зв'язок «Залежність» зі стереотипом «Include» — включення (Малюнок 7). Якщо виконання додаткової функції потрібно за певних умов, то будемо використовувати зв'язок «Залежність» зі стереотипом «Extend» — розширення. Все дуже легко запам'ятати: Include - ЗАВЖДИ, а Extend - Іноді.
Малюнок 7. Використання зв'язку типу «Залежність (увімкнення)»
У результаті наша діаграма виглядатиме приблизно так (Малюнок 8).
Рисунок 8. Діаграма Use-case (функціональна модель АС)
З іншого боку, діаграма Use-case використовується для моделювання ролей користувачів (Малюнок 9).
Рисунок 9. Діаграма Use-case (ролі користувачів АС)
Етап 4. Опишемо внутрішню організацію АС за допомогою діаграми класів
Використовуючи інформацію про вхідні та вихідні артефакти нашого процесу (див. діаграми Activity — Малюнок 2, Малюнок 3, Малюнок 4), розробимо діаграму класів. Будемо використовувати моделюючий елементи «Клас» та різні види зв'язків між ними.
Щоб показати ставлення ціле-частина будемо використовувати зв'язок типу Агрегація (Малюнок 10): горіх - це ціле, а шкаралупи і ядро - це частини.
Малюнок 10. Відношення «ціле-частина»
У результаті фрагмент нашої діаграми виглядатиме приблизно так (Малюнок 11). Кольором відзначені класи, які ми виділили у текстовому описі процесу.
Малюнок 11. Діаграма класів
Діаграма класів використовувалася також для моделювання інших артефактів – не лише тих, які матимуть відношення до концептуальної моделі автоматизованого процесу обліку матеріальних цінностей, але мають відношення до середовища виконання – оточення (Малюнок 12) та «сусідних» процесів (Малюнок 13), які можуть впливати на процес, що автоматизується, але поки не знаходяться у фокусі нашої уваги (припускаємо, що система буде розвиватися, і ця інформація виявиться корисною).
Малюнок 12. Діаграма класів (оточення)
Зв'язок успадкування показує узагальнення різних будівель, «дочірні» класи, під узагальнюючим «батьківським» класом «Будова».
Малюнок 13. Діаграма класів (додаткова інформація про артефакти)
«Реакція на ситуацію» залежить від «Даних візуального контролю». Для декількох зв'язків залежності використовується стереотип trace, щоб показати трасування класів, явно не позначених в описі процесу, але які необхідні для його автоматизації, до класів, на екземпляри яких є точна вказівка в нашому описі.
Етап 5. Проаналізуємо нотатки на доріжці «Бізнес-правила»
Як правила були вказані (див. малюнок 2 ):
- необхідність розбиття одного з кроків на 2 частини, друга частина починає виконуватися лише за певних умов;
- призначення на виконання обліку горіхів певної посадової особи;
- технічний прийом (білий колір елементів), який вказує на те, що елемент явно не був вказаний в описі процесу.
Слід зазначити, що всі ці правила ми використовували при розробці діаграм.
заключні зауваження
Отже, ми пройшли 5 етапів та побудували 3 види діаграм. Додам ще невеликий коментар про організацію наших моделей у середовищі моделювання. Існує велика кількість фреймворків, які допомагають структурувати моделі, що розробляються, але це не предмет цієї статті, тому ми обмежимося наступним простим набором пакетів для впорядкованого ведення нашого проекту: Бізнес-процес, Функціональна модель, Артефакти, Учасники та Оточення (Малюнок 14).
Малюнок 14. Структура пакетів проекту
Таким чином, ми розробили узгоджені моделі, що описують систему обліку матеріальних цінностей з різних сторін: модель бізнес-процесу, що автоматизується, функціональну модель і модель внутрішньої організації системи на концептуальному рівні.
Список джерел
- Сайт "UML2.ru". Форум Співтовариства аналітиків. Спільний розділ. приклади. Приклади казок оформлені у вигляді UML діаграм. [Електронний ресурс] Режим доступу: Веб:
- Сайт Sparx Systems. [Електронний ресурс] Режим доступу: Веб:
- Сайт Modelio. [Електронний ресурс] Режим доступу: Веб:
- Великий словник енциклопедії. Процес (тлумачення). [Електронний ресурс] Режим доступу: Веб:
- Сайт "Організація ефективного управління". Блог. Рубрика «Управління бізнес-процесами». Визначення бізнес-процесу. [Електронний ресурс] Режим доступу: Веб:
- Свідоцтво № 18249 про реєстрацію та депонування твору результату інтелектуальної діяльності. Алфімов Р.В., Золотухіна Є.Б., Краснікова С.А. Рукопис навчально-методичного посібника під назвою «Моделювання предметної галузі з використанням Enterprise Architect» // 2011р.
- Золотухіна Є.Б., Вишня А.С., Краснікова С.А. Моделювання бізнес-процесів. - М.: КУРС, НІЦ ІНФРА-М, ЕБС Znanium.com. - 2017.
- OMG Unified Modeling Language (OMG UML) Спеціалізація. Version 2.5.1. [Електронний ресурс] Режим доступу: Веб:
Джерело: habr.com