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

Термин "моделирование" используют для обозначения отношения модели к тому объекту, который является целью моделирования (индивиду или классу).

Различения Коржибски (Korzybsky) между картой и территорией: “идти по карте” это совсем не то, что “идти по территории”. Карта абстрагирует (моделирует) территорию. Более того, у карты есть “легенда”, которая абстрагирует карту. Надписи в легенде сделаны алфавитом, который абстрагирует надписи.

Моделирование в широком смысле – это эффективное по затратам использование чего-то одного вместо чего-то другого для мыслительных целей. Это позволяет нам использовать вместо реальности что-то такое, что проще, безопаснее или дешевле чем реальность для заданной цели; модель является абстракцией реальности в том смысле, что она не может представить все аспекты реальности. Это позволяет нам иметь дело с миром упрощённым способом, обходя сложность, опасность и необратимость реальности. Формальную модель можно подвергнуть оптимизации (в том числе компьютерной).

В системной инженерии использование моделей настолько важно, что будущая системная инженерия называется Model-Based Systems Engineering (MBSE), прежде всего речь идёт о моделях требований и архитектурных моделях. В менеджменте тоже начало использоваться моделирование: архитектурные модели предприятия, модели бизнеса, модели рабочих процессов, финансовые модели.

Мета-моделирование

Мета-моделирование - отношения между уровнями языков моделирования.

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

Объект-атрибутное моделирование

Мета-модель "объект-атрибут" - наиболее распространённый формализм описания данных. Однако именно атрибуты (а не отношения!) являются в объект-атрибутной модели способом выделить объект из класса ему подобных. Отношения могут возникать, изменяться и исчезать (для учёта этого могут использоваться атрибуты отношений), а вот изменения атрибутов объектов мета-моделью, как правило, вообще не предусмотрены. Точнее говоря, в каждый момент времени у объекта есть только одно значение атрибута, и сохранение истории его изменений мета-модель не предполагает. Атрибутный формализм критикуют вовсе не за отсутствие формальности, тут всё в порядке, математическое обоснование у него есть. Критикуют именно неудобство моделирования мира, низкую вероятность того, что два независимых модельера без предварительных консультаций сделают одинаковые модели, пригодные к непосредственному объединению.

Факт-ориентированное моделирование

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

Самым распространённым формализмом для факт-ориентированного моделирования стали ориентированные графы. Каждый факт может быть представлен как упорядоченная тройка (triple) <субъект, предикат, объект>.

Пример факт-ориентированного описания языка архитектуры предприятия OpenGroup Archimate 2.1.

Виды моделирования

• Статическое моделирование: рассматривается ряд наиболее часто встречающихся статических представлений, применяемых при разработке систем. Многими из них системные инженеры могут воспользоваться непосредственно, особенно на стадии разработки концепции.
• Имитационное моделирование: рассматривается несколько типов динамических представлений системы, используемых на разных стадиях ее разработки.
• Анализ компромиссов (Trade-Off Analysis): описывается подход к анализу альтернатив на основе моделирования.

Уровни обобщения

Логические уровни — уровни обобщения мышления для разных дисциплин или даже для групп дисциплин. Если нас интересует мультидисциплинарность (например, мы хотим обсуждать множество инженерных дисциплин, или инженерные и менеджерские дисциплины вместе, или мы хотим включить обсуждение ещё и научных исследований), то нам приходится для качественного обсуждения подниматься выше по лестнице логических уровней. Важность обобщения мышления состоит в возможности абстрагироваться от содержания нижележащих уровней. Объекты с этих уровней рассматриваются не как полноценные сущности со своими многочисленными особенностями, а как типизированные сущности, с которыми можно выполнять базовые типичные операции.

В книге "Системноинженерное мышление" используются следующие уровни обсуждения (сверху вниз):

1. Философско-логический: выбрать предельные онтологии (об общей природе мира, природе описаний, природе интерпретирующего эти описания сознания).
2. Формально-математический: выбрать математический аппарат теории множеств, математической логики, теории графов, теории категорий, или какой-то ещё. К этому же уровню относится выбор того или иного языка программирования или языка моделирования.
3. Онтологический: договориться, что мы видим в мире, какие индивиды, классы и отношения (А ещё мы можем видеть объекты и атрибуты, трансформации, прототипы, или теории — в зависимости от решений, принятых на предыдущих уровнях.) Это уже не предельная онтология с первого уровня, тут нам надо договориться о том, что нужно именно для нашей деятельности. Именно на этом уровне определяется системное мышление, выясняется, в чём суть системного подхода, определяется, что такое “система” или “процесс”. Онтологический уровень тесно связан с уровнем математического формализма, но отличается от него. Если в мире есть “системы”, то на более высоком уровне можно использовать теории категорий (и записывать знание теоркатегорными уравнениями) или теорию множеств (и записывать логические предикаты). Примером совместной работы специалистов одновременно на формально-математическом и онтологическом уровнях являются различные стандарты представления данных, такие, как ISO 15926.
4. Деятельностный: научиться описывать человеческую деятельность, описывать дисциплины с их основными понятиями. Для этого нужно задать язык описания практик работы, язык планирования и организации работы, междисциплинарного взаимодействия, работы конкретного предприятия. На этом уровне определяются стандарты ситуационной инженерии методов, архитектуры предприятия, описания бизнес-процессов, органиграмм и т.д. С использованием понятий онтологического уровня на языке математического аппарата описываются стандартные классы и отношения, создаются справочные данные, специфичные для деятельности.
5. Профессиональный: на этом уровне описываются конкретные виды менеджмента, инженерии, научных исследований и прочих профессиональных видов деятельности. Иногда этот уровень называют “методологическим” — на нём описываются методы профессиональной работы, достаточные для решения каких-то узких классов задач. Именно тут задаются основные понятия разных менеджерских и инженерных дисциплин (например, “value proposition” для менеджмента, “архитектура” для системной инженерии, "здание" для гражданского строительства). Занимаются этим профессиональные методологи и “рефлексирующие” инженеры и менеджеры, и делают они это в организациях по стандартизации, профессиональных ассоциациях, университетах. На этом уровне продолжается развитие стандартных справочных данных, уже для отдельных специальностей и профессий.
6. Предпринятия: на этом уровне описывается происходящее в конкретном предпринятии. (Это не опечатка: “предпринятие” — от слова “предпринять”, но вовсе не “предприятие” как юридическое лицо. “Проект” в смысле проектного управления – это тоже ”предпринятие”). Тут с использованием профессиональных понятий моделируется (уже не мета-моделируется!) то, что происходит “в жизни”, в привязке к конкретным условиям работы в ООО “Незабудка” по проекту ремонта лифта "к празднику". Занимаются этими описаниями люди конкретного предпринятия, используя понятия и методы, созданные на всех верхних уровнях.

Почему моделирование не повсеместно

1. Полезность моделирования неочевидна. Опыт показывает, что множество решений вполне можно выполнить без моделирования. Никто не может предъявить конкретных цифр, что с моделированием эти проекты были бы выполнены быстрее (решения бы по ним принимались быстрее плюс экономия от меньшего количества ошибок). Кроме того, использование моделирования связано с затратами (закупка софта моделеров, обучение людей), и на одном проекте эти затраты могут не окупиться.
2. Существующий софт моделирования (моделеры) и поддерживаемые им языки моделирования плохи: неточно отражают моделируемые объекты. Да, каждые пять- десять лет появляются новые языки моделирования и новое поколение программного обеспечения, но по-настоящему хороших и универсальных до сих пор нет. Без языков же и софта моделировать невозможно.
3. Модели (и результаты моделирования, например, расчёт по модели) оказываются непонятными людям. Решение об использовании моделирования принимают часто не непосредственные пользователи модели, а совсем другие люди — менеджеры и финансисты, которые ничего сами в моделировании не понимают, но знают, что в моделях есть ответ на нужные им вопросы.
4. Модели являются хорошим средством накопления знаний в организации. Если никто не заинтересован в накоплении знаний, то и интерес к моделированию слабый: зачем спрашивать модель, если всегда можно спросить Иван Иваныча? Мысль же о том, что эти знания можно отделить от Ивана Ивановича в виде модели — эта мысль обычно не обсуждается. Тем не менее, если посмотреть на происходящее в менеджменте и инженерии за последние пятнадцать лет, то из состояния “почти нигде, кроме самых развитых компаний” моделирование перешло в состояние “почти везде, кроме самых отсталых компаний”.

Моделеориентированная инженерия (model-driven engineering)

Как -based, так и -driven оба переводятся как -ориентированная, но имеют разный смысл.

-Based означает, что для решения каких-то задач выполняется моделирование. Далее человек смотрит на результаты моделирования (расчёт, текст, чертёж, диаграмму) и делает очередную модель (расчёт, текст, чертёж, диаграмму). См. MBSE.

-Driven означает, что модель является основным, что работает — на неё не “глядят для осмысления, и сочиняют другую модель”, а она компьютерно преобразуется с добавлением новых данных в другую необходимую модель.

Часто про model-driven подход говорят как о преобразованиях (transformation) моделей. Десять принципов model-driven engineering, сформулированные Jean Bezivin:

1. Принцип представления: любая модель M представляет объект S.
2. Принцип множества групп описаний (view): объект S может быть представлен несколькими моделями (мульти-моделирование).
3. Принцип соответствия: любая модель соответствует мета-модели (моделирование одного логического уровня ведётся с использованием знаний, определённых на другом логическом уровне).
4. Трёхуровневая организация: любая метамодель MM соответствует общей для них метамодели MMM). Впрочем, это Jean Besivin и AtlanMod настаивают именно на 3 уровнях моделирования, в общем случае логических уровней может быть много.
5. Принцип трансформации: наиболее важная операция, применимая к модели (группа AtlanMod занимается главным образом переходом от Model-Based engineering к Model-Driven Engineering: их волнует порождение/генерирование по моделям инженерных рабочих продуктов, а не, например, имитационное моделирование или использование моделей для налаживания взаимопонимания между менеджерами, инженерами, клиентами).
6. Принцип HOT (High-Order Transformation): трансформация (код, описывающий преобразование модели) это тоже модель.
7. Принцип переплетения (weaving): отношения между несколькими моделями могут быть представлены тоже как модели.
8. Мегамодель: важна модель, чьи элементы модели и мета-модели плюс отношения между моделями. В мега-модели мы представляем информацию нескольких логических уровней.
9. Принцип унификации: все упомянутые модели специализируют общую абстрактную (математическую, алгебраическую) модель — высший уровень мета-мета-моделирования.
10. Подход технического пространства (Technical Space Framework): любая модель имеет внешнее техническое представление (больше нет ограничений на выбор одного языка моделирования для какого-то вида моделей: нотации могут быть разными, модель одна).