Строге визначення понять: об'єкт, стан, подія, бізнес-операція і бізнес - функція

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



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

Читати далі →

Труднощі в моделюванні операцій стандартними способами. Моделювання 4-об'єктів, постановка завдання

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



Всі моделі, які ми будуємо, повинні так чи інакше моделювати 4-х мірний простір-час, тому що саме так ми уявляємо собі навколишній світ. Про це розказано в книзі Кріса Партріджа. Навіть те, що здається, не має відношення до 4-простору, при уважному розгляді виявляється оним. Правда, не завжди існують в реальності, іноді — це уявний нами світ. Всім, кому цікаво, як це відбувається, рекомендую уважно прочитати цю книгу. Проте, раджу не звертати уваги на визначення події в цій книзі, — воно дано невірно.
Наприклад, що таке болт? Це 4-х мірний об'єкт, обмежений у просторі-часі визначеними кордонами. Для моделювання болта існують нотації, які моделюють ці межі. Наприклад, креслення болта моделює поверхня, яка обмежує 3-х мірний об'єм. Додавши до цього кресленням ще 6 координат, залежних від часу, ми отримаємо модель поверхні 4-Д простору — часу, яка моделює болт.

Однак, що таке операція? Це — теж 4-х мірний об'єкт, який також, як і болт обмежений певними межами в просторі і в часі. Правда, уявити собі операцію як 4-об'єкт набагато складніше. Існують три причини, по яким нам складно це зробити.

Читати далі →

Труднощі на шляху створення «універсальної» метамоделі для моделювання предметних областей

Для створення моделі предметної області спочатку будується модель наших уявлень. Опис наших уявлень міститься в метамоделі (наприклад, в нотації BPMN). Метамоделі, в свою чергу, будуються на основі мета-метамоделі. Однак, наші уявлення мають дуже складну структуру, яка досі не має формального опису. Тому побудова метамоделі і мета-метамоделі сильно утруднено. Спробу описати цю структуру зробили греки, коли придумали основи логіки. Способи нашого мислення вивчали математику, коли зіткнулися з парадоксами, намагаючись побудувати основи своєї науки. Здавалося б, прогрес є, але з якоїсь причини, зупинившись на формальному описі інструментів логічного висновку, математики не зробили спробу застосувати отримані напрацювання до моделювання нашого світу (напевно, тому що для них – це прикладна задача, що не викликає інтересу).



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

Читати далі →

Моделювання активів підприємства: сучасні стандарти і практика


Можна увійти в одну річку двічі?

Дана стаття написана за результатами доповіді на конференції Нефтегазстандарт – 2016, зроблена мною від імені компанії ТриниДата.

Працюючи інженером — онтологом, я займаюся створенням інформаційних моделей для інформаційних систем.

У цій статті я хочу розповісти про практику застосування стандарту ISO 15926 до моделювання активів підприємства, і про те, до яких наслідків це призвело в підсумку. Ті, хто незнайомий зі стандартом, можуть не засмучуватися — читання статті буде корисно незалежно від знання стандарту.

Проблеми моделювання активів
  1. Побудова моделі активів підприємства досі є складним і нетривіальним завданням. На мій погляд, ця складність обумовлена розривом між методиками моделювання і звичайним людським мисленням. Наприклад, ні в логіці Арістотеля ні в матлогике ви не знайдете нічого схожого на термін «інстанси». Проте програмісти і аналітики дуже часто вживають це слово, не докладаючи зусиль, щоб пояснити його сенс. Особисто я ніде не знайшов визначення цього терміна.
  2. Однією з найбільш вдалих методик моделювання активів можна назвати стандарт ISO 15926. В ньому зроблено революційне припущення, що для моделювання підприємства можна користуватися часом як четвертою координатою нарівні із звичайними просторовими координатами. Цей підхід дозволив моделювати повний життєвий цикл активів. Однак з допомогою даного стандарту поки не вдалося створити універсальну метамодель для опису діяльності підприємства. Власне творці цього стандарту не ставили перед собою завдання.
  3. Для моделювання діяльності підприємства запропоновано безліч стандартів, наприклад, стандарт ArchiMate. За заявами його розробників цей стандарт дружній стандарту ISO 15926 і методології моделювання архітектури підприємств TOGAF. Незважаючи на заявлені можливості, цей стандарт не цілком впорався з поставленими завданнями. Одна з причин цього – відсутність розмежування між понять «діяльність» і «активність» (діяльність передбачає цілеспрямовані зусилля по досягненню результату. Активність же трактується як те, що відбувається, яке незалежно від волі суб'єкта). Щоб краще зрозуміти виникає трудність, згадайте, як стародавні греки трактували «а» в квадраті? Вони не мислили інакше це площа квадрата зі сторонами довжиною а. Те ж можна сказати про куб – об'єм куба зі сторонами довжиною «а» записувався як «а» в кубі. Але, оскільки не можна придумати фізичний аналог «а» четвертого ступеня, рівняння вище кубічних в Стародавній Греції не розглядалися. І так було до тих пір, поки в середні століття алгебраїстів не відірвали рівняння від фізичного сенсу. Почалася ера чистої математики не шукала фізичних аналогів рівнянь. Рівно те ж відбувається в бізнес-аналізі. Розгляд відбувається тільки під одним кутом зору (як діяльність), сильно обмежує наші аналітичні можливості.
  4. У стандарті ISO 15926 також є цінна можливість моделювати об'єкти різних типів (наприклад, функціональні та фізичні), а також перетину цих об'єктів у часі. Однак набір можливих типів об'єктів жорстко визначений стандартом, і в деяких практичних випадках його виявляється недостатньо для створення моделі, що адекватно відбиває уявлення про об'єкт, подію або процес. Наприклад, в стандарті немає об'єктів типу «виробничий ресурс».
Постановка завдання
Остання моя робота була пов'язана з Самарським заводом нафтового резервуарного обладнання.

Замовник побажав створити інформаційну систему, яка допомагала б менеджеру з продажу взаємодіяти з клієнтом найбільш ефективним способом. Для цього менеджер повинен бути забезпечений всією необхідною інформацією, яка включає в себе:
  • Модель функціональних вимог (що потрібно клієнту?)
  • Моделі можливих рішень (як можуть бути задоволені функціональні вимоги?)
  • Модель собівартості виконання замовлення
  • Модель ризиків
  • Модель відносин з клієнтом
Для вирішення поставленого завдання фактично знадобилося створити модель всього підприємства, починаючи від моделі активів, закінчуючи моделлю діяльності.

В якості ідеологічної основи для створення моделі було взято стандарт ISO 15926.



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

Для опису діяльності підприємства можна було взяти позначення ArchiMate.



Але вона не підійшла з причин, сказаним раніше – в ній немає диференціації між моделлю діяльності та моделлю активності. Крім того в ній немає точного опису того, що таке бізнес-функція, як вона пов'язана з операціями і процесами. Для вирішення цього завдання у стандарті слід було б розділити два значення одного і того ж питання: «Це один і той же об'єкт?» в сенсі той же самий об'єкт? або це схожі об'єкти? На жаль, у стандарті не робиться розходження між цими двома різними значеннями цього питання, тому немає можливості побудувати модель діяльності коректно: дві бізнес-операції визнаються одним об'єктом в сенсі схожі один на одного, але дві бізнес-функції визнаються одним об'єктом, якщо вони реально співпадають. Не можна в одній моделі плутати ці питання.
Далі ми продовжили вже самостійно працювати над створенням моделі діяльності. В процесі цієї роботи ми з подивом виявили єдиний шаблон, який дозволяє нам моделювати не тільки діяльність, але і вартістю, функціональні та фізичні об'єкти. Причому спосіб моделювання цих сутностей виявився універсальним. Цей спосіб можна було використовувати де завгодно!
Далі я розповім про цей спосіб більш докладно.

Рішення
Нове поняття, яке нам знадобилося, — це точка зору. Розглянемо насос в якості прикладу активу.



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



Друге поняття, яке нам знадобилося, — це конструкція. Розглянемо конструкцію людського організму.



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



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



Для моделювання такого розмаїття поняття «конструкція» нам необхідно нарівні з поняттям «об'єкт».



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



Після цього можна рухатися від одного представлення до іншого, змінюючи точки зору. Це дозволяє в одному інформаційному сховищі зберігати інформацію про моделі, які створені різними людьми з різними цілями.
У стандарті ISO 15926 описаний спосіб побудови сховища даних, в якому враховані тільки дві точки зору: точка зору на фізичний світ і точка зору на функціональні об'єкти. У ньому також описаний спосіб переходу від одного представлення до іншого через темпоральні частини. Тобто можна одержати відповідь на питання: які фізичні об'єкти виконували роль даного функціонального і коли? Можна отримати відповідь і на зворотне питання: які функціональні об'єкти виконував той чи інший фізичний об'єкт? Відповідь на ці питання і є спосіб переходу від одного представлення до іншого. Однак, ввівши поняття «точка зору» ми тепер не обмежені лише двома точками зору. Тепер ми можемо створювати стільки точок зору, скільки нам треба для наших цілей моделювання.
Максимальну вигоду від такого підходу до моделювання можна отримати, розглянувши і саму діяльність підприємства як об'єкт, що має конструкцію.



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



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

Підсумки:
Отримана метамодель володіє наступними перевагами:
  1. Метамодель наближена до нашого природного мислення, що дозволяє у разі потреби легко її розширити, наприклад, ввівши в неї ймовірності.
  2. Метамодель володіє універсальністю. Все, що нам потрібно було змоделювати, ми змогли описати, використовуючи дану методику.
  3. Додатковим бонусом виникла можливість опису діяльностей різного типу в одному фреймворку. Наприклад, звичайна виробнича діяльність та діяльність по саботажу виробничої діяльності описується єдиним способом в одній моделі.
  4. Ми змогли розірвати зв'язок між моделлю і методологією її застосування. Розробник моделі тепер не зобов'язаний знати цілі, з якими буде застосовуватися та чи інша модель. Він фіксує факти, а їх інтерпретацією займаються інші суб'єкти. Це дозволяє створювати моделі з необхідним рівнем секретності.
  5. Метамодель передбачає таку точку зору на предметну область, яка не вимагає введення встановленим типів об'єктів: наприклад, функціональних або фізичних. Подібні типи вводяться в міру необхідності і кількість таких типів може бути будь-яким.
  6. Метамодель дозволяє переходити від одного представлення об'єкта до іншого його поданням, використовуючи при цьому одну інформаційну модель.
  7. Метамодель дозволяє створювати інформаційну модель, яка здатна необмежено розширюватися. Її розширення обмежена лише обсягом збереженої інформації, але не логічними суперечностями, які могли б виникнути через неузгодженість даних.
Труднощі в реалізації моделі:
  1. Труднощі в реалізації даної моделі у тому, що отримана в результаті модель має велику ступінь складності і тому висуває високі вимоги до програмної реалізації.
  2. Для створення такого моделей такого рівня складності потрібне додаткове навчання фахівців.
Джерело: Хабрахабр

Кінцеві автомати в середовищі динамічного моделювання SimInTech. Частина 3. Переходимо до коду Сі

першою і другий частини було розглянуто приклад створення системи управління на основі логіки «кінцевих автоматів» та створена модель регулятора нагрівача.

В цій частині буде показано як з SimInTech згенерувати код Сі, що реалізує програму управління на основі логіки «кінцевих автоматів», а потім віддалити в MS Visual Studio 2015 спільно з моделлю об'єкта в SimInTech.

Читати далі →

Діаграма циклічної причинності як інструмент моделювання складних систем



Антон Антипин
Генеральний директор компанії «Business Set»
«Якщо ви хочете зрозуміти систему і бути в змозі передбачити її поведінку, необхідно вивчити її в цілому. При поділі її на частини можуть зруйнуватися зв'язку і, отже, сама система».
Денис Шервуд


Читати далі →

Моделювання функціональних і фізичних подій в логічній парадигмі

Добрий день, колеги!

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



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

Читати далі →

Імітаційна модель логістичного центру

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

Постановка завдання (опис процесу)

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

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

Комплектувальники за допомогою навантажувального обладнання (електричний навантажувач) комплектують в зоні відвантаження постачання в роздрібну точку продажу. Комплектація проводиться при досягненні залишку товару в роздрібній точці продажу точки поповнення запасу (точки перезаказа).

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

Читати далі →

На тему моделювання предметної області в термінах ООП

Привіт.

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

Кожен раз при моделюванні предметної області, оперуючи термінами ООП (зараз говоримо не про етапі бізнес-аналізу, а про подальшому етапі реалізації моделі в коді), для всіх сутностей предметної області доводиться реалізовувати в коді і схемою БД наступний паттерн, який складається їх «подсущностей», пов'язаних між собою:
  • клас/таблицю «Машини» (тут і далі клас вживаю в термінах ООП);
  • клас/таблицю виду «Список машин»;
  • клас/таблицю виду «Машина».
Далі з допомогою механізмів ООП та реляційної моделі «подсущности зв'язуються між собою.

Причому терміни „сутність“ і „подсущность“ застосовні саме до моделі предметної області в термінах теорії множин,
а в термінах ООП/реляційної моделі доречні терміни „метасущность“ і „сутність“ відповідно.
Сподіваюся, зрозуміло, чому? — ООП/реляційна модель є більш низькорівневими механізмами, і сутність предметної області доводиться конструювати, немає в них коштів, які нативними чином дозволили б відобразити сутність предметної області.

А далі йдуть очікувані проблеми:


Читати далі →

BPMN: Моделювання фізичних подій

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



Визначення події
Для початку згадаємо, що таке фізичне і функціональне подія в предметної області.
Подія — це экстент плюс суб'єктивна точка зору на нього.

  1. Экстент — це будь 4-Д область з 4-Д простору-часу. Справа в тому, що наш простір четырехмерно. Просто одне з вимірювань ми переживаємо специфічним чином — як щось, що розгортається перед нами в одному напрямку. Але для моделювання така особливість нашого сприйняття не має значення.
  2. Вважається, що экстент, який ми вважаємо подією, з точки зору оповідача має нульову тимчасову ширину. Тобто з точки зору оповідача подія — це мить. Однак, завжди існує точка зору, в якій шириною події вже не можна знехтувати і нам знадобиться розглянути тимчасову ширину цього экстента.
  3. Подія має фізичний сенс — це факти і нічого крім фактів. Ми розглядаємо таку подію як набір фактів без їх трактувань. Наприклад, у прикладі з маяком є подія доглядач сидить на дровне і відпочиває. Таку подію ми будемо називати фізична подія.
  4. Крім фізичного події існує безліч трактувань цього фізичного події різними суб'єктами. Наприклад, при описі маяка одне і те ж фізичне подія «Доглядач відпочиває» може бути описано як: «Розпал закінчений» і «Гасіння розпочато». Таку подію ми будемо називати функціональне подія.
В результаті ми маємо таку ієрархію об'єктів:



Читати далі →