Розділ «18. Технології моделювання бізнес-процесів. Мова UML»

Більшість об'єктно-орієнтованих методів не характеризуються строгістю: їх нотації радше спрямовані на інтуїтивне розуміння, аніж на формальне визначення. Розробники об'єктно-орієнтованих методів шукають способи досягти більшої строгості методів без втрати практичності моделі.

Один з таких способів полягає у визначенні деякої метамоделі: діаграми (як правило, діаграми класів), яка визначає нотацію. Метамодель допомагає визначити, чи побудована модель є синтаксично правильною, проте для практичного застосування нотації ЦМЬ глибоке розуміння метамоделей не є обов'язковим. Вимога вільного оперування метамоделями висувається лише для спеціалістів, що мають високу кваліфікацію в області моделювання.

18.4. Задачі аналізу і проектування

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

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

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

1. одним з найкращих способів вивчення об'єктно-орієнтованих методів є CRC-картки. Вони не входять до засобів UML, проте можуть використовуватись разом із універсальною мовою моделювання. CRC-картки були створені, головним чином, для навчання роботі з об'єктами (рис.18.6).

2. діаграми взаємодії дозволяють наочно представити структуру повідомлення і тим самим виявити надмірно централізовані проекти, в яких один об'єкт виконує всю роботу;

3. діаграми класів використовуються для ілюстрації моделей класів та характеризуються як перевагами, так і недоліками. Моделі класів є зручними, за аналогією з моделями даних - принципи побудови якісної моделі даних практично співпадають із принципами побудови якісної моделі класів. Основна проблема при використанні діаграм класів полягає в тому, що можна розробити модель класів, що буде орієнтованою на дані, а не на класи, з якими необхідно кооперуватись для реалізації (відповідальність);

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

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

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

Рис.18.6. Структура CRC-картки

Найпоширенішим методом, що застосовується для досягнення цієї мети, є варіанти використання (Use Cases). Варіант використання представляє собою деякий моментальний відбиток одного з аспектів системи, що моделюється, наприклад про здійснення клієнтом операції замовлення товару (рис.18.7)

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

Рис.18.7. Приклад діаграми використання

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

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

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

Рис.18.8. Приклад діаграми класів