Презентация Интеграция технико-экономических моделей

Слайд 1

Работа, промежуточные итоги которой содержатся в данном докладе, была задумана и начата как оценка технологий и инструментов, доступных сегодня для работы по моделированию в области инженерии требований. Постепенно полученные результаты позволили приступить к разработке определённой методологии работы с моделями требований и технико-экономическими моделями. В настоящий момент на ряде тестовых и реальных примеров методология доведена до возможности практического применения, и уже видны направления ее дальнейшего развития. Элементы докладываемой работы могут послужить иллюстрацией тех концепций, которые обсуждаются в рамках этой конференции. В докладе могут быть отмечены многочисленные пересечения с иными докладами, в особенности с докладом Яна Александера (Ian Alexander) «Моделеориентированное нахождение требований».

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

Слайд 2

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

Если речь идёт об «однократном» (долгосрочном или краткосрочном) создании некой системы «с нуля», к нему, скорее всего, применим обобщенный жизненный цикл, являющийся предметом рассмотрения в стандарте ISO 15288 – стадии замысла, разработки, производства, использования, вывода из эксплуатации. Однако если мы имеем дело с системами, имеющими какие-то особенности, их жизненный цикл должен быть обдуман более тщательно.

В моём докладе речь пойдёт о примере типового проекта, лежащего в основе некой технологической платформы, и многократно реализующегося с определёнными модификациями (это может быть атомная или тепловая электростанция, типовой корабль или автомобиль, даже типовое бытовое изделие). При этом мы должны рассматривать специальную форму жизненного цикла, которая может напомнить вам доклад Тайсона Браунинга (Tyson Browning) «Проблемы и инструменты для интеграционного моделирования всего жизненного цикла системы». Там было продемонстрировано, в частности, как функционирующая система со временем теряет свою ценность для заинтересованного в ней лица, далее в результате модернизации вновь приближается к желательному уровню ценности, и вновь теряет ценность до момента неизбежного принятия решения о выводе её из эксплуатации.

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

Типовой проект при этом существует как совокупность информационных объектов. Раньше это был набор чертежей, а теперь это множество компьютерных информационных моделей, и именно об их жизненном цикле и пойдёт речь.

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

Слайд 3

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

Чтобы увидеть этот жизненный цикл, саму стадию модернизации надо в свою очередь рассмотреть по иному – как проект. Стандарт системной инженерии ISO 15288 предписывает подходить к реализации жизненного цикла системы как к последовательности отдельных проектов, отвечающих классическому определению проекта из теории проектного управления, по стандарту PMBoK – имеющих своих заинтересованных лиц, бюджет и ресурсы, ограниченное время, и, главное, определённые достижимые  цели. Именно наличие этих признаков и отличает проект от полного жизненного цикла.

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

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

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

Необходимо остановиться подробнее на разделении целей и технических предложений. Это разделение – очень характерная черта для того типа проектов, о которых говорилось выше – для модернизации существующей технологической платформы. Так как типовой проект уже неоднократно воплощён, эксплуатируется в нескольких конкретных вариантах – существует множество идей его развития и заинтересованных в реализации этих идей лиц. Поэтому требуется очень тщательно анализировать то, что эти лица заявляют в качестве требований на данном этапе. Под видом целей заинтересованные лица часто предлагают готовые решения, которые они считали бы необходимым внести в проект. Как объяснялось в докладе Яна Александера, требуется как можно подробнее и глубже прорабатывать предложения заинтересованных лиц в такой форме, которая не зависит от реализации,  выявлять их цели, и только когда этот процесс логически завершается – начинать работу с носящими специфичные черты реализации конкретными предложениями, то есть с техническими решениями.

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

Про эти две модели далее будет рассказано подробнее.

Слайд 4

Понятие «мегамодель», которое уже звучало в докладе Анатолия Левенчука  «Проблемы системной инженерии. Русский взгляд», вводится для объединения всех появляющихся в жизненном цикле проекта моделей, а также их метамоделей, то есть тех формальных описаний, в соответствии с которым модели составляются. Применяемые в проекте метамодели и, частично, построенные на их основе модели – должны быть стандартизированы в рамках системы стандартов проекта. О моделировании необходимо договориться заранее, перед началом реализации проекта, и оформить эти договорённости стандартом, наряду с иными определяемыми PMBoK документами проекта – например, уставом проекта, миссией проекта.

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

Слайд 5

Стандарт моделирования проекта позволяет достичь унификации по ряду вопросов,  и в то же время оставляет для участников проекта необходимую свободу. Стандарт вводит единую систему понятий и их связей, то есть тот самый словарь, о котором говорилось в докладе Яна Александера. Стандарт  обеспечивает возможность сотрудничества при создании  моделей разными командами, и даёт возможность сопоставлять результаты моделирования разных команд. Очень важно понимать, что при работе разных команд возникают неизбежные конфликты. Необходимо контролировать, что именно стандарт предписывает делать людям, и где он оставляет им свободу для использования их знаний предметной области, их навыков, привычных им инструментов и методик.

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

На слайде можно видеть перечень стандартов моделирования (то есть стандартов метамодели, мета-стандартов), на которых можно основывать описываемую методологию.

Слайд 6

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

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

Слайд 7

Рассмотрим пример применения описываемой методологии. Первый этап – это переход от пожеланий, или, как их иногда называют неформально, «хотелок» заинтересованных сторон к формальной модели, которая разделяет цели и технические предложения.

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

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

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

Проектирование модели целей начато в табличной форме в ПО Microsoft Excel, которое может довольно долго применяться в проекте, может быть даже до перехода к более поздним стадиям жизненного цикла, ибо на стадиях архитектурного проектирования мощности Excel может оказаться вполне достаточно. При выборе на следующих стадиях жизненного цикла следующего поколения программ следует уже внимательнее относиться к масштабируемости и промышленной устойчивости выбираемого программного обеспечения. Не все из них позволяют создавать интегрируемые модели в единой методологии. Широко известная программа Doors с трудом поддерживает связи текстовых форматов пожеланий и числовых параметров. Doors изначально гораздо лучше подходит для записи «хотелок», чем для формальных моделей, в которых надо переходить к критериям достижения целей с параметрами и их пороговым значениям. Те программы для управления требованиями, которые входят во многие линейки продуктов САПР/PLM, обеспечивают интеграцию по крайней мере с информационными моделями, создаваемыми продуктами тех же производителей.

Слайд 8

Здесь для обсуждаемой нами цели приведена упоминавшаяся в других докладах модель аргументации. Для её построения использована реализация стандарта i* на свободной платформе моделирования Eclipse, для которой можно скачать соответствующий плагин и строить такого типа модели.

Альтернативную методику построения моделей аргументации, моделей обоснований, называемых «деревья стратегии и тактики» -  предлагает Элияху Голдратт (Eliyahu Goldratt),  инструментом для создания таких деревьев является программный продукт Flying Logic.

Все модели аргументации обладают общими чертами: представлена цель, представлены предложения, направленные на достижение этой цели, представлен (в овале на диаграмме) аргумент, обоснование того, что повышение мощности паротурбинной установки и установка теплового аккумулятора имеют смысл, если  в ночные часы наша электростанция будет работать с неполной загрузкой. Вводится дополнительная цель, тут это «минимизировать капитальные затраты», и далее модель i* позволяет отражать связи. Мы видим, что одновременное повышение мощности и котельной установки, и паротурбинной установки сильно отрицательно влияет на минимизацию капитальных затрат, а повышение мощности паротурбинной установки и установка теплового аккумулятора влияют просто отрицательно, но не сильно отрицательно. Метамодель i* определяет минус с точкой как сильно отрицательное воздействие, минус – как просто отрицательное, а плюс с точкой – это сильно положительное воздействие, то есть модель показывает, что оба рассматриваемых варианта, оба технических предложения в этой развилке, позволяют одинаково хорошо достичь цели.

Слайд 9

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

Выделяемые примитивы должны быть организованы в библиотеки, и организация эта характеризуется множественностью иерархий. Для использования моделей в дальнейшем в разных контекстах необходимо помещать каждый выделяемый примитив, каждый элемент будущей модели, сразу в несколько иерархических структур. Во-первых, это иерархия типов оборудования, по которой идет наследование параметров моделирования – это логика организации каталога оборудования. Во-вторых, это иерархия функциональной организации объекта – это логика, которая лежит в основе того, что называется в системах автоматизации проектирования «структура разбиения объекта» (Plant Breakdown Structure, PBS). На дальнейших стадиях, при проектировании, появляются и многие другие иерархии – например, иерархия пространственной организации, то есть разбиение объекта по зданиям, помещениям, отметкам, но это в рассматриваемом примере находится за пределами архитектурного моделирования.

Слайд 10

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

Слайд 11

Работа по описанию примитивов и параметров может быть формализована средствами языка онтологического моделирования OWL, работа с которым поддерживается, например, свободно распространяемым редактором Protégé.

В левой панели можно видеть,  как обеспечивается классификация объектов в дереве классов.

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

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

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

Слайд 12

Описанные в соответствии с метамоделями примитивы должны быть отмоделированы для расчётов с помощью конкретных инструментов симуляционного моделирования. Здесь можно видеть модель, созданную на языке Modelica. Работа на этом языке поддерживается рядом свободных инструментов, но на слайде приведены примеры в программной оболочке Dymola, коммерческий продукт Dassault Systèmes. То же самое дерево примитивов, что и на предыдущем слайде, вы можете опять увидеть слева, оно содержит два классификатора – по типам оборудования и по функциональному разбиению проекта. Типы оборудования находятся в нижней половине дерева, где написано Equipment, а в верхней отражено функциональное разбиение объекта, показывающее, что турбогенератор находится в составе турбинного острова, а паровой котел находится в составе котельной установки. В правой панели открыт программный код примитива – модели теплового аккумулятора, и можно видеть наследование классов, которое позволит нам далее поддерживать созданные библиотеки в консистентном виде. Тут указано, что используемая нами конкретная модель теплового аккумулятора наследует свойства, общие для любого оборудования, и наследует свойства, общие для теплового аккумулятора любого типа.

Слайд 13

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

Слайд 14

На слайде показан  тепловой аккумулятор в том интерфейсе программного обеспечения Dymola, который поддерживает не текстовое, а графическое программирование на языке Modelica. Здесь тепловой аккумулятор представлен как графический примитив, интерфейсы которого соответствуют введённым параметрам.

Слайд 15

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

Слайд 16

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

Слайд 17

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

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

Примитивы с часами и табличкой на диаграмме – это модель графика выдачи тепла паровым котлом.

Слайд 18

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

Две новых группы примитивов с часами и табличками на диаграмме – это модели графика отбора тепла в аккумулятор (ночные часы) и графика выдачи тепла из аккумулятора (пиковые и полупиковые часы).

Слайд 19

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

Слайд 20

Чтобы связать все построенные до настоящего момента разнородные модели в одно целое, предлагается использовать стандарт интеграции данных ISO 15926. Здесь приведена одна из диаграмм данного стандарта, построенная для единообразного описания разработанных моделей, не зависящего от конкретной  реализации. Диаграмма показывает, каким образом в терминах этого стандарта отражается всё тот же механизм – механизм множественной классификации, отнесения одного и того же элемента к разным классам.

Примитивы моделирования образуют класс «Примитив_моделирования» и относятся к типу «класс_представления_информации». Для того, чтобы разбить класс на разные иерархии, на диаграмме вводится класс классов, названный «Класс_примитивов_моделирования». Его подклассами  и являются необходимые классификаторы – классы моделей функциональных элементов и классы моделей оборудования. Например, модель котельной установки, как элемент функционального разбиения (Plant Breakdown Structure), относится к классу моделей функциональных элементов, а модель теплоаккумулирующего оборудования относится к классу моделей оборудования. Конкретная модель теплового аккумулятора, участвующая в конфигурации, является экземпляром обоих классов, она относится как к каталожному классу моделей теплоаккумулирующего оборудования, так и к функциональному классу примитивов, входящих в котельную установку.

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

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

Слайд 21

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

Перечисленные инструменты, за исключением Dymola и Microsoft Excel, являются свободными программными продуктами. Dymola может быть заменена иными коммерческими программными продуктами, или открытым компилятором OpenModelica, хоть и с ущербом для красоты картинок. Excel полностью заменяется электронными таблицами OpenOffice, разумеется. Тем самым, для всех описанных на данной стадии технологий моделирования существуют доступные программные инструменты, позволяющие в достаточно полном объеме осуществлять работу по моделированию.

Слайд 22

В заключение – несколько слов о том, что можно делать дальше.

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

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

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

Первый вариант – это отказ от единого репозитория моделей. Условным репозиторием становится набор файлов под «ручным» управлением конфигурацией, обеспечивающим, чтобы модель в Excel не расходилась с программой на Modelica. К сожалению, этот подход становится невозможным при переходе к моделям с сотнями классов.

Второй вариант состоит в миграции между стандартами. Начальное проектирование моделей, например, может выполняться в Excel, продолжаться в промышленных инструментах, поддерживающих либо UML, либо OWL, а когда развитая система классов создана – работа полностью переходит в среду имитационного моделирования, например, в Dymola, связанную с системой управления конфигурацией моделей, типа SVN или GIT, отлично зарекомендовавших себя для проектов в программировании. Однако при таком подходе теряется то многообразие разных групп описаний, о котором мы говорили как о существенном достоинстве данной методологии.

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

Спасибо за внимание.

 

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

Ответ: Нет, интеграция между уровнями только становится ещё более прозрачной. Большим достоинством стандарта ISO 15926, который предлагается к использованию, является то, что в нем нет принципиальных границ между метамоделью, моделью и даже экземплярами модели. Полная структура данных, созданных в соответствии с этим стандартом - это единая информационная модель в федерации репозиториев, где границу можно проводить по границам репозиториев, библиотек справочных данных, в которых лежат элементы моделей, но не по содержательному уровню моделирования.  Отказ от моделирования на UML уже позволяет достичь в значительной степени такой логической интеграции моделей. На OWL вы еще вынуждены поддерживать мета-уровни, но попав в «счастливое светлое будущее» стандарта ISO 15926, вы можете забыть об этом. В этом смысле в «счастливом светлом будущем» мегамодель возникает естественным образом, и включает в себя модель и все уровни, соответствующие метамета- и мета-. Исключительно для удобства изучения можно представлять себе уровни: систему типов ISO 15926, под ней классы классов, под ними уровни классов и экземпляров. Но при применении про все это можно забыть и держать в голове единую структуру, если, конечно, инструменты помогают её поддерживать.