В текущей статье я определю следующие термины: объект, состояние, событие, операция, функция. Я расскажу о том, как можно представить себе их. В качестве мета-метамодели для моделирования мы возьмем теорию множеств, а не MOF. Почему именно ее? Потому что это единственный на сегодняшний день известный способ моделирования, который имеет математическую основу, границы применимости которого нам хорошо известны, достаточно широки и обоснованы.


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

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


Все модели, которые мы строим, должны так или иначе моделировать 4-х мерное пространство-время, потому что именно так мы представляем себе окружающий нас мир. Об этом рассказано в книге Криса Партриджа. Даже то, что кажется, не имеет отношения к 4-пространству, при внимательном рассмотрении оказывается оным. Правда, не всегда существующим в реальности, иногда — это воображаемый нами мир. Всем, кому интересно, как это происходит, рекомендую внимательно прочитать эту книгу. Однако, советую не обращать внимания на определение события в этой книге, — оно дано неверно.

Например, что такое болт? Это 4-х мерный объект, который ограничен в пространстве-времени определенными границами. Для моделирования болта существуют нотации, которые моделируют эти границы. Например, чертеж болта моделирует поверхность, которая ограничивает 3-х мерный объем. Добавив к этому чертежу еще 6 координат, зависящих от времени, мы получим модель поверхности 4-Д пространства — времени, которая моделирует болт.

Однако, что такое операция? Это — тоже 4-х мерный объект, который также, как и болт ограничен определенными границами в пространстве и во времени. Правда, представить себе операцию как 4-объект намного сложнее. Существуют три причины, по которым нам сложно это сделать.

Модели создаются аналитиком с целью сделать понятным ту или иную часть предметной области. Модель строится при помощи объектов учета и отношений между ними. Под объектом учета понимается все, что мы назвали: активы, процессы, события, структуры, множества и т.д. При этом кажется, что мы все знаем, что такое «понимание», однако, стоит поговорить об этом чуть подробнее.

В результате обучения человек привыкает к тому, что есть некоторые паттерны, повторяющиеся из раза в раз. Например, если поднять камень и отпустить его, он упадет на землю. И так будет всякий раз, когда повторится этот паттерн. Знание о том, что предмет падает на землю является эмпирическим опытом, не требующим объяснения. Всем, кто живет на Земле, этот факт кажется очевидным, не требует ни объяснения, ни доказательства, то есть, он понятен. Выглядит это знание как:

1. Эмпирический опыт – это множество (класс) ситуаций, которые расцениваются данным субъектом, как похожие друг на друга (субъект ронял предметы). Новые ситуации классифицируются субъектом как похожие на предыдущие и пополняют класс однотипных ситуаций.
2. Паттерн ситуаций (тип ситуаций, или модель ситуаций), который присутствует в сознании у субъекта и в котором записано, что всякий раз, когда случится подобное, тело падает на землю. Паттерн связан с эмпирическим опытом, или с классом ситуаций.

Итого: есть ситуации, модели которых хранятся в сознании у субъекта, есть модель этих моделей – паттерн, который тоже хранится в сознании у субъекта. Все вместе это дает человеку чувство понимания.

Однако, для человека, родившегося в космосе и всю жизнь проведшего в невесомости, факт того, что камень падает на землю, не будет являться очевидным, и потребует объяснения.

Для создания модели предметной области сначала строится модель наших представлений. Описание наших представлений содержится в метамодели (например, в нотации BPMN). Метамодели, в свою очередь, строятся на основе мета-метамодели. Однако, наши представления имеют очень непростую структуру, которая до сих пор не имеет формального описания. Поэтому построение метамодели и мета-метамодели сильно затруднено. Попытку описать эту структуру предприняли греки, когда придумали основы логики. Способы нашего мышления изучали математики, когда столкнулись с парадоксами, пытаясь построить основы своей науки. Казалось бы, прогресс есть, но по какой-то причине, остановившись на формальном описании инструментов логического вывода, математики не сделали попытку применить полученные наработки к моделированию нашего мира (наверно, потому что для них – это прикладная задача, не вызывающая интереса).



В итоге те принципы, на основе которых создаются нотации и языки моделирования предметных областей, выбираются разработчиками относительно произвольно. Понятно, что созданные таким образом языки моделирования имеют достаточно ограниченную область применения. Эту область должны были бы описать создатели языка, но разработчики, как правило, это требование игнорируют.

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

Известная модель Захмана пытается ответить на вопрос, что такое архитектура предприятия, и рассказывает о том, как она должна моделироваться. Основой этой модели являются вопросы, на которые предлагается ответить: кто, когда, где, почему и как совершает что-то над чем-то. Кажется, что это логичный фреймворк для описания архитектуры предприятия, и многие думают, что так оно и есть.

Однако, даже беглый взгляд на этот фреймворк оставляет чувство неудовлетворенности, потому что не понятно, как ответить на вопрос: кто и почему выточил деталь? Кто: Иван Иванович, или токарь, роль которого исполнял Иван Иванович? Почему: потому что токарь получил задание, или потому что Иван Иванович заключил контракт, в соответствии с которым он обязуется выполнять роль токаря в обмен на еду? Почему: потому что Иван Иванович хочет покушать, или затем, что деталь нужна в сборочном цехе?



Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!

Эта статья будет простой и короткой. Однако, на мой взгляд, она будет очень важна для аналитиков, которые занимаются описанием активностей. При этом не важно каких — будь то процессы, происходящие в ядерном реакторе, или процессы, происходящие на предприятии, — все они моделируются единообразно. Я попытаюсь в очередной раз об этом поговорить, но на сей раз — без сложных теоретических отступлений.



Итак, есть некая активность. В мифологическом сознании первобытного человека за каждым действием стоит сознательное существо. Например, если течет, то делает это живое существо — река, если светит, то делает это живое существо Солнце. Поэтому в мифологическом сознании у каждого действия есть сознающий себя актор, который это действие выполняет. И мы можем сказать, что назначение (функция) этого актора — делать это действие. Я специально говорю о том, что все это происходит только в рамках мифологического сознания. Например, машина едет по дороге только в рамках мифологического сознания, потому что на самом деле машина не обладает волей и не может куда-то ехать. Наш язык настроен на отражение мифологического сознания, поэтому нам так сложно мыслить иначе. Например, можно было бы сказать, что участником активности является машина и дорога, в результате этой активности машина постоянно перемещается по дороге, но мы, одушевляя машину, говорим о том, что это делает именно машина. Таким образом, назначение машины в рамках мифологического сознания — ехать, или в рамках мифологического мышления функция машины — ехать. (хотя мы могли бы с тем же успехом одушевить колесную пару и сказать, что ехать — это функция колесной пары, а не машины). Замечу, что назначение как и функция — не имеет начала и конца в рамках существующего контекста.

Можно ли войти в одну реку дважды?

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

Работая инженером — онтологом, я занимаюсь созданием информационных моделей для информационных систем.

В этой статье я хочу рассказать о практике применения стандарта ИСО 15926 к моделированию активов предприятия, и о том, к каким результатам это привело нас в итоге. Те, кто незнаком со стандартом, могут не расстраиваться — чтение статьи будет полезно независимо от знания стандарта.

В предыдущей статье «Зачем нужно моделировать индивидуальные и типовые сценарии?» я рассказал про необходимость моделирования как типовых, так и индивидуальных сценариев в тех случаях, когда заказчик хочет автоматизировать три функции:

1. Моделирование операций и сценариев на основе типовых схем.
2. Сравнение полученных результатов с планируемыми.
3. Корректировка планов.

Теперь я сконцентрирую свое внимание на разнице в моделировании предстоящих работ и свершившихся действий.

Постановка задачи

Для простоты представим, что предприятие структурно разделено на два уровня. (В общем случае уровней может быть сколько угодно).

На уровне предприятия производятся следующие работы:

• Формулируются требования к предприятию в целом и выявляются ограничения, накладываемые внешними условиями;
• Определяются производственные мощности предприятия;
• Формулируются стратегические цели предприятия и текущие планы (задания);
• Задания для предприятия декомпозируются на задания для подразделений. При этом учитываются возможности отдельных подразделений;
• Задания передаются подразделениям.

Вопрос о том, что такое класс объектов, существует ли он в природе, обсуждается мной вот уже на протяжении двух статей: Класс объектов или объекты класса? , Особенности концептуального моделирования предметной области . Я задаюсь вопросом: можно ли, описывая предметную область, связать семантической связью объект и класс объектов?

Вопрос на самом деле отнюдь не праздный. Я часто встречаю модели, которые не совсем точно передают смысл сказанного. Например, хозяин машины может сказать, что его машина содержит группу колес. Он мог бы сказать, что машина содержит колеса, и это было бы совсем другое утверждение. Меня же смущает то, что в моделях, которые я видел, не делается разница между этими двумя утверждениями. Однако, на практике между ними огромная разница. Попробуйте потренироваться в поиске этой разницы самостоятельно.

Моделирование при помощи UML подливает масла в огонь, потому что во-первых, не позволяет моделировать классы объектов (Моделирование функциональных и физических событий в логической парадигме), а во-вторых, не позволяет связать семантикой класс объектов и объект. Таким образом, в области моделирования предметных областей наблюдается пока не изученное пустое пространство. Я позволю себе немного порезвиться на этом поле, чтобы показать, как на самом деле это забавно. Сегодня я расскажу про то, как мой вопрос связан с понятием исчисляемости и неисчисляемости существительного.

Я продолжаю серию статей, посвященных особенностям концептуального моделирования предметных областей. В прошлой статье я показал. как возможно связать объект с классом объектов семантической связью. В статье я рассказал о том, что понимается под термином класс в ООП. Сегодня я расскажу, почему я предпочитаю строить концептуальные модели в виде ER диаграмм.

Пусть нам надо смоделировать тезис, о том, что на каждом автомобиле стоит по 4 колеса. Не группа из четырех колес, а именно, — 4 колеса.

В терминах ER модели принято говорить, что есть автомобиль, есть колесо и есть связь между автомобилем и колесом. Связь эта называется «колесо-автомобиль» и имеет отношение один ко четырем. Связь, читаемая от колес, называется: «стоит на», связь, читаемая от автомобиля, называется: «имеет».



В терминах ООП говорят так: есть класс ООП автомобилей и есть класс ООП колес. Между этими классами ООП есть связь один к четырем. Связь называется: «автомобиль-колесо». Связь, читаемая от колес, называется: «стоит на», связь, читаемая от автомобиля, называется: «имеет».



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

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

Я предлагаю вам прочитать статью, которая является логическим продолжением начатой мной серии статей, посвященных моделированию предметных областей.



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

Устраиваясь на новую работу, я придумал новый вопрос для собеседования. Хочу задать его и вам.

Пусть у нас есть конкретная машина. КОНКРЕТНАЯ! Не тип и не класс машин, А именно конкретная машина, на которую я указываю своим указательным пальцем. Хозяин этой машины утверждает, что его машина состоит из множества компонентов, в том числе из колес. Он говорит, что его машина состоит из пяти колес (одно запасное). Замечу сразу, что хозяин говорит: «состоит из», а не «включает в себя».

Вопрос: слушая хозяина машины, что мы себе представляем: то, что машина состоит из колес одного класса?



Или то, что машина состоит из класса колес?

Введение

Хочу заметить, что тем, кто пользуется терминами ООП, будет очень трудно понять меня. Дело в том, что ООП подменил понятия. В ООП под классом понимается не множество, как обычно принято в математике, или лингвистике. В ООП классом называют тип объектов, как у Аристотеля. Было бы правильно в ООП вместо термина класс объектов использовать термин тип объекта. Однажды, съехав с правильной терминологии, вернуться в лоно правильных терминов оказывается очень трудно. В данной статье я попробую помочь тем, кто желает разобраться с терминологической кашей, заваренной ООП. В своих рассуждениях я буду использовать термины в их первоначальном смысле, а не в смысле ООП. Термин класс будет взят из логической парадигмы моделирования предметных областей, которая, в свою очередь, заимствовала этот термин из теории множеств. Термины тип и экземпляр будет взят из теории типов, построенной на парадигме Аристотеля о существовании типов.

Адепту ООП очень трудно понять, что термин экземпляр класса в русском языке указывает на класс объектов, а не на созвучный этому термину элемент класса – объект класса. Для многих, кто изучал ООП, термины экземпляр и элемент – неразличимы. Давайте разберемся с этими терминами внимательно.

Я нередко слышу тезис о том, что есть термины: событие и экземпляр этого события, или переменная и экземпляр этой переменной. Уважаемые аналитики, у меня убедительная просьба к тем, кто использует эти термины, прочитайте конец статьи и подумайте над тем, что там написано. Возможно, вы поймете, что так говорить нельзя.

В данной статье я продолжаю рассказ про физические и функциональные события. На этот раз я свяжу физические события с теми объектами, которые моделируют их в информационных системах. В этой статье рассказ пойдет про физические и только физические события:

Определение события

Для начала вспомним, что такое физическое и функциональное событие в предметной области.
Событие — это экстент плюс субъективная точка зрения на него.

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

В итоге мы имеем такую иерархию объектов:

Есть три способа описания процесса:







Чем они отличаются?

Описание сущего

Я продолжаю серию статей, посвященных вопросам моделирования бизнес-аналитиком предметных областей. В прошлых статьях я показал, как мы производим описание сущего. Давайте повторим это еще раз.

Природа пространства-времени

Начнем с того, что воспринимаемый нами мир – это четырехмерное пространство-время. Но не то пространство-время, которое используют математики в своих рассуждениях. Скорее это то пространство, которое используют физики. Разница в том, что в физическом мире нет точек. Есть объекты, которые с точки зрения наблюдателя можно считать точечными. Но при ближайшем рассмотрении эти точки могут рассматриваться как бесконечные пространства. Мы часто не различаем воспринимаемый нами мир и математическую абстракцию, созданную для описания этого восприятия. В абстракции, созданной для описания воспринимаемого мира, есть понятие точка. В реальном мире нет точек. В этом огромная разница между моделируемым миром и его моделью. В неразличении этих двух сущностей кроется причина части холиваров, возникших на основе предыдущей статьи. Например, мы не способны воспринять срез пространственно-временного континуума поперек временной оси, как нам предлагает поступить ИСО 15926, для определения понятия событие. Поэтому далее я продолжу рассуждения, не отвлекаясь на такие понятия как точки, срезы пространственно-временного континуума и прочие абстрактные объекты. Мы будем работать только с реально воспринимаемыми нами объектами 4-Д пространства-времени.

Петька, ну как? Сдал экзамен?
Нет, Василий Иванович! Меня попросили квадратный трехчлен разложить. А я его не то что разложить, я его представить не могу!

Постановка вопроса

При моделировании предметной области и описании реализации мы часто используем термин событие. Однако, насколько мне известно, мало кто понимает смысл этого термина и может четко дать определение этого термина. Кроме того, часто путают событие, тип событий и класс событий.

Посмотрите на диаграмму. На ней кружочками что-то изображено. В нотации BPMN это что-то называется «Событие». Но что есть само событие? И почему операция по отправке сообщения в одном случае обозначено как событие, а в другом как операция?

Чем ИСО 15926 мне не понравился

В прошлых статьях я давал определения физического объекта.

Физический объект — это любое подмножество 4-Д пространства-времени.

Кроме того, я давал определения функционального и информационного объектов.

Физический и информационный объекты — это физические объекты в 4-Д пространстве-времени, которые с точки зрения наблюдателя выполняют определенные функции, или служат определенным целям.

Введение

Возможно, кто-то задаст вопрос, а причем тут математика? Отвечу сразу: все, что здесь изложено, относится непосредственно к математике.
Изучая литературу по теории построения моделей предметной области, я обнаружил серьезный пробел. Авторы статей и книг сразу берут одну из нотаций моделирования: ER-диаграммы, или диаграммы классов, и в быстром темпе начинают их использовать для описания предметной области. При этом описание парадигмы, в которой производится это моделирование остается вообще не раскрытым. А следовательно, не раскрытыми остаются ограничения той или иной нотации. Увы, мы все умеем строить модели, но мало кто умеет объяснить то, что он построил в одной из существующих парадигм. Поэтому я часто слышу дикие с точки зрения любой парадигмы термины: класс типов, типы классов, виды типов и так далее, но ни разу не слышал корректный термин «класс классов». Этот пробел в нашем образовании очень серьезен. И я объясню почему.

Давайте зададим аналитикам простой вопрос.

Те, кто моделировал процессы, наверно, знакомы с нотацией BPMN. Очень часто при моделировании операции по заключению договора я встречаю такой фрагмент диаграммы:



Видно, что в результате заключения договора рождается нечто, что передается в другую операцию. Но что обозначает элемент диаграммы в виде листа с загнутым уголком? Нам надо точно знать, что именно передается из одной операции в другую, иначе трудно будет объяснить другим, что от них требуется. Итак, что создается на выходе из операции «Заключить договор»?
Варианты ответов, которые я слышал, следующие:

• Бумажка с печатью
• Бумажки с печатью
• Класс бумажек с печатью
• Договор
• Договоренность
• Информация о договоренности
• Файл MS Word с названием договор
• Запись в базе данных
• Поток каких-то объектов

Пока я наблюдаю отсутствие согласия между аналитиками на предмет того, что же все-таки передается, и что значат термины «договор», «поток», «договоренность», «информация», «данные». Чтобы ответить на этот вопрос, мне пришлось копать глубоко и в сторону парадигм. Причем, ответ потребовал разбиения вопроса на два. Первый вопрос был: «Как корректно сформулировать вопрос?» А второй был: «Как на него ответить?». Для правильной формулировки нужно было выбрать подходящую парадигму. Эта статья посвящена рассказу о двух парадигмах: Аристотелевской и логической, и почему я выбрал логическую в качестве рабочей. Ответа на поставленный вопрос в этой статье я не дам. Ответ я дам в другой статье.

История создания терминов

При создании методики по имитационному моделированию мне понадобилось разобраться с терминами. Проблема была в том, что общепринятые термины не годились для описания статистических данных, собранных в процессе имитации. Термины: процесс и экземпляры процесса были неприемлемы, потому что я не мог работать в парадигме Аристотеля. Парадигма Аристотеля не стыкуется с примененным мной матаппаратом. При этом практическое применение данной методики было простое – моделирование и имитация бизнес-объектов с целью принятия управленческих решений. В программе создавался виртуальный объект, описание которого состояло из описания сценариев и их взаимодействия. Сценарии прогонялись внутри программы, а также моделировались ресурсы и их взаимодействия.

Введение

В прошлой статье мы рассмотрели понятие функциональный объект и посмотрели, как моделируются его части. Сегодня я хочу рассказать про то, как в логической парадигме трактуется информационный объект, и что из этого следует. Помимо этого, мы увидим, как родилось одно занятное заблуждение: идея о том, что термины объект и экземпляр объекта якобы указывают на разные объекты предметной области. И поймем причины этого заблуждения.