Введение

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

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

Моделирование состава леса

Начнем с моделирования привычного нам объекта — попробуем смоделировать лес. Есть 4-Д объем, который Иванов трактует как объект типа лес. Для моделирования этого факта создается информационный объект (ИО), моделирующий этот 4-Д объем. Далее создается ИО, моделирующий представление Иванова об этом 4-Д объеме. Этот объект связан с моделью 4-Д объема связью «что представляет», с моделью Иванова «кто представляет» и с моделью типа объектов – лес «как представляет».



Как бы вы поступили, если бы я попросил вас смоделировать состав леса? Возможно, вы предложите смоделировать каждое дерево этого леса. Тогда у меня к вам вопрос: есть ли описание более подробное, чем первое, и менее подробное, чем второе?

Такое описание есть. Его можно услышать, когда детям объясняют, что такое лес. Им говорят, что лес состоит из деревьев. Попробуем описать это формально. Пусть нам известно, что конкретный лес состоит на 30 процентов из осин и на 70 процентов из берез. Для моделирования этого факта нам нужны: два ИО, моделирующие типы деревьев: берез и осин (в ООП – это классы), один ИО, моделирующий представление Ивановым 4-Д объема в виде кучи и один ИО, моделирующий состав кучи. Далее свяжем ИО, моделирующий состав, с типом берез связью «состоит на 70 процентов» и с типом осин связью «состоит на 30 процентов» (в ООП это сделать невозможно).



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



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

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

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

Моделирование функций

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

С функциями возникла довольно курьезная ситуация, когда невозможность моделирования множеств привела к невозможности корректно сформулировать определение функции. А, поскольку нет определения функции, аналитики вообще не могут ни представить ее, ни смоделировать!

При помощи проекционного моделирования задача определения и моделирования функции решается точно так же, как моделирование леса.

Пусть есть предприятие по выпуску паровозов. Допустим, что эта трактовка 4-Д объема выполнена Ивановым. Предприятие можно пощупать, увидеть, услышать и локализовать в пространстве.

Иванов, может сделать другую трактовку того же самого 4-Д объема. Он может трактовать его как функцию по выпуску паровозов (одна точка зрения не противоречит другой). Для тех, кто читает меня впервые, я скажу, что эту функцию, как и предприятие, можно пощупать, увидеть, услышать и локализовать в пространстве. Если я попрошу вас описать эту функцию, то вам, скорее всего, будет затруднительно это сделать. Те же, кто попытается это сделать, скорее всего, сделают следующие ошибки:

1. Вместо описания функции попробуют описать конструкцию этой функции. Например, скажут, что функция по выпуску паровозов состоит из производства паровозов и продажи паровозов.
2. Вместо описания функции попробуют описать конструкцию, в которую эта функция включена: производство паровозов включено в состав производства запчастей для паровозов и потребления паровозов. Такая ошибка возникает, когда говорят, что функция — это преобразование.
3. Вместо описания функции заявят, что функция – абстракция и ее нельзя ни пощупать, ни описать.
4. Ближе всего окажутся те, кто попробуют смоделировать потоки, входящие в функцию и выходящие из нее. Такая точка зрения на функцию была навязана стандартом IDEF0, и с тех пор целесообразность такого рода описания не подвергалась сомнению. Однако, она вызывает определенного рода коллизии, о которых я неоднократно писал раньше.

Функция – это куча, только не объектов, а событий (операций), функций или элементарных конструкций из этих элементов.

Допустим, что Иванов решил описать функцию по выпуску паровозов. Для этого он может поступить тремя способами.

Первый способ

Иванов может выделить класс событий (операций) «выпуск паровоза». Тогда функция по выпуску паровозов может быть представлена в виде класса событий «выпуск паровоза». Функция в таком случае моделируется классом событий. Эти события можно увидеть на диаграмме в нотации IDEF0 в виде выходящей из квадрата стрелки.

Второй способ

Иванов может выделить класс функций «выпуск паровозов». От первого кейса отличие в том, что в подфункциях много выпусков паровозов (сколько – неизвестно). Функция в таком случае моделируется классом функций. Для поддержки такого рода моделирования пока нет инструмента, хотя именно так можно моделировать непрерывные функции типа вращение вала двигателя.

Третий способ

Иванов может выделить цепочки событий (операций): закупка запчастей, производство паровоза и отгрузка паровоза. Функция в таком случае будет описана в виде класса элементарных конструкций – сценариев. Этот способ описания функции реализован в программных продуктах по моделированию деятельности предприятия в виде «декомпозиции» функции, смоделированной в нотации IDEF0, в типовой сценарий, смоделированный в нотации IDEF3, EPC, или BPMN.

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

Стандарты моделирования функций

Теперь, после того, как я рассказал, что такое функция и как она моделируется, вы сможете ответить на вопрос, какая связь между функцией в нотации IDEF0 и ее «декомпозицией» в нотации IDEF3, EPC или BPMN. Эта связь реализована в программных продуктах по моделированию деятельности предприятий: AllFusion ERwin Data Modeler и Business studio. Связь эта такая: 4-Д объем, смоделированный как функция виде кучи операций, соответствующих потокам в нотации IDEF0, может быть представлен как функция в виде кучи однотипных сценариев, описанных в нотации IDEF3, EPC или BPMN.

Трудности в понимании текста

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

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

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