Типи моделей

Правильно поставлене запитання швидко призводить до правильної відповіді. Нещодавно мене запитали: «Чому стандарти бізнес-аналізу сконцентровані на виявленні вимог, але нічого не говорять про перетворення цих вимог на рішення?» На самому початку своєї кар'єри аналітика я шукав відповідь на питання: як аналізувати предметну область і як перетворювати результат аналізу на структуру моделі: звідки брати класи, атрибути і методи? Тоді я знайшов один більш-менш зрозумілий метод, описаний у книзі Крега Лармана Застосування UML 2.0 і шаблонів проектування. Введення в об'єктно-орієнтований аналіз, проектування та ітеративну розробку. Аналітику пропонувалося проходження по тексту з маркерами різних кольорів: Червоний виділяє існуючі і є підставою для створення класів, зелений - прикметники, причастя тощо - основа для створення атрибутів цих класів. І дієслова виділяється синім - основа для створення методів.

Однак, в реальності цей метод не працював. Один і той же факт я міг змоделювати за допомогою класу, значення атрибуту або методу залежно від свого бажання. Про це написано детально у Крісса Партріджа в книзі Business Objects: Re-Engineering for Re-Use.

Він наводить приклад з Коллі. Це може бути клас об'єктів, це може бути значення атрибута «Порода» з типом значення або рядкове, або посилання на об'єкт довідника «Породи», або - значення «так» булевського атрибута «Коллі».

У прикладі Крісса Партріджа ми вибираємо між класом і атрибутом. Але є альтернатива, при якій можна змоделювати один і той же факт за допомогою класу або методу.

Наприклад, можна уявити собі ситуацію, що позолоту можна змоделювати за допомогою класу об'єктів, за допомогою значення атрибута, а, можливо, і методу.

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

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

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

Про все це я писав раніше. Але є ще одне важливе питання, яке ми повинні собі поставити перш, ніж почнемо моделювання. Треба з'ясувати, якого типу модель ми збираємося будувати. Нещодавно я почув тезу: модель моделі - теж модель (було згадано властивість транзитивності моделей). Наприклад, якщо у вас є документ «Договір», який є модель домовленості, то вордовський файл, що моделює цей договір - теж модель домовленості. Фокус в тому, що ця теза вірна тільки для одного типу моделей - для моделей об'єктів. Для іншого типу моделей - концептуальних моделей, - ця теза неправильна. Мало, хто робить відмінність між ними. Тому я вирішив трохи відійти від головної лінії викладу і розповісти про типи моделей, з якими працюють аналітики.

Класифікація моделей

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

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

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

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

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

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

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

Концепт конструкції складається з безлічі концептів - концептів об'єктів - елементів конструкції і концептів зв'язків між цими елементами. Для концепту конструкції тепловоза буде вірним наступне затвердження: для кожного елемента в концепті конструкції існує один і тільки один елемент в реальному тепловозі. Інакше можна це переформулювати так: «арність» зв'язків у моделі концепту конструкції тепловоза завжди «один-к-одному».

Але в загальному випадку це невірно. Часто можна зустріти концептуальні моделі, в яких «арність» зв'язків відрізняється від «один-до-одного».

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

Щоб краще уявити собі такого роду моделі, можна подивитися на будь-яку ER модель. На них ми бачимо концепти об'єктів і концепти зв'язків. Чи можна на основі ER моделі відновити модель концепту конструкції? На жаль, не можна. А отже, не можна відновити і модель конструкції.

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

Приклади

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

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

Питання: якого типу модель створюється за допомогою нотації BPMN? Я не буду відповідати на це питання, сподіваючись, що ви самі здатні відповісти на нього.

Питання: якого типу модель створюється за допомогою нотації IDEF0? Також сподіваюся, що ви самі відповісте на це питання.