Краткое введение в метамоделирование на примере CDIF

30 Декабря 2015

В публикации на конкретном примере описывается идея метамоделирования в контексте представления знаний. Данная статья не имеет ничего общего с метамоделями НЛП.

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

В общем случае модели можно разделить на следующие виды: статические, описывающие структурные свойства систем; динамические, представляющие поведенческие свойства систем; функциональные, описывающие функциональные свойства систем. Статическая модель описывает составные части системы, их структуру, атрибуты, взаимосвязи между ними и операции, которые они могут выполнять. Операции статической модели являются событиями динамической и функциями функциональной моделей. Динамическая модель описывает последовательность выполнения операций в процессе функционирования системы. Функциональная модель описывает преобразования, осуществляемые системой. Она раскрывает содержание операций статической модели и событий динамической.

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

Модели создаются на основе метамоделей. Метамоделирование лучше всего рассматривать на примере архитектуры стандарта EIA/CDIF. CDIF – это акроним для «CASE Data Interchange Format». Этот стандарт был создан в конце XX века и предназначен для стандартизации передачи данных моделирования между CASE-средствами различных производителей. Основная цель метамоделирования – описать данные настолько глубоко, чтобы они были самодостаточными и допускали расширение и модификацию своей структуры.

Архитектура CDIF имеет четырехуровневую схему:

Таблица. Уровни модели CDIF


М3

мета метамодель

CDIF мета метамодель

М2

метамодель

Концепции определенной системы моделирования (например, UML); описание видов сущностей и отношений предметной области

М1

модель

Пользовательские концепции, конкретная модель предметной области: система, процесс в системе, класс нежилых объектов, состояние объекта и т.д.

М0

Данные пользователя

Чек № «2345», завод «Станколит», покупатель «Миша Иванов»

Уровни информации
Рис. Уровни информации

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

При решении задачи моделирования систем на уровне М0 находятся данные, описывающие конкретные системы и объекты. Уровень М1 является моделью для уровня М0 и содержит модель системы и объектов. Уровень М2 определяет метамодель для уровней М1 и М0, на этом уровне находится модель языка моделирования, с которым работают аналитики, строящие модеди систем. Самый верхний уровень (М3) определяет язык, на котором описываются метамодели уровня М2.

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

 

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

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

 

Мета метамодель

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

Мета метамодель CDIF
Рис. Мета метамодель CDIF

Дерево классификации мета мета-сущностей:

MetaObject
SubjectArea
CollectableMetaObject
AttributableMetaObject
MetaEntity
MetaRelationship
MetaAttribute

Если мета мета-сущность субклассируется, подобно тому как MetaObject субтипируется мета мета-сущностями SubjectArea и CollectableMetaObject, иерархия обозначается идущими вниз линиями без стрелок от MetaObject к соответствующим субклассам.

Бинарные отношения между мета мета-сущностями обозначается линиями со стрелками.

Мета мета-отношения:

AttributableMetaObject.HasSubtype.AttributableMetaObject
CollectableMetaObject.IsUsedIn.SubjectArea
MetaAttribute.IsLocalMetaAttributeOf.AttributableMetaObject
MetaRelationship.HasDestination.MetaEntity
MetaRelationship.HasSource.MetaEntity

Мета мета-сущность MetaObject является корнем иерархии и определяет все общие атрибуты всех субтипов, такие как уникальный идентификатор, имя, синонимы, описание, объяснение использования и др.

Мета мета-сущность SubjectArea позволяет определять, какая из сущностей CollectableMetaObjects используется в той или иной метамодели (предметной области). У нее имеется один атрибут «Номер версии».

Мета мета-сущность CollectableMetaObject служит абстрактным типом и не имеет никаких атрибутов. Она необходима для отражения мета мета-отношения IsUsedIn (используется в), связывающего предметную оласть с входящими в нее сущностями, субклассированных от CollectableMetaObject.

Мета мета-сущность MetaAttribute определяет четыре атрибута: DataType (тип данных), Domain (домен), IsOptional (опциональность) и Length (длинна). DataType определяет возможные типы данных: Identifier, Integer, String, Text, Boolean, Date, Time, BitMap, Float, Enumerated и др.

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

Мета мета-сущность AttributableMetaObject служит абстрактным типом и не имеет собственных атрибутов. Она необходима для отражения мета мета-отношения HasSubtype (имеет субтип), определяющего субтипинг мета-сущностей и мета-отношений.

Мета мета-сущность MetaEntity служит для определения различных типов сущностей в предметных областях.

Мета мета-сущность MetaRelationship служит для определения различных типов отношений в предметных областях.

Из MetaEntity и MetaRelationship субтипируются все мета-сущности и мета-отношения, определяемые в метамодели уровня М2.

В стандарте CDIF определяется несколько метамоделей (предметных областей). Далее будут  описаны наиболее общие из них.

 

Метамодели предметных областей

Метамодели уровня М2 далеки от конкретных данных, в них описываются обобщенные концепции, такие как сущность, отношение, атрибут, состояние, событие, а также приводятся механизмы, как моделировать различные составные объекты.

Базовая предметная область

Базовая предметная область используется как базис для определения других предметных областей.

3

Объект самого высокого уровня абстракции – это RootObject, который  является корневым объектом для всех остальных объектов. Он является субтипом мета мета-сущности MetaEntity.

Базовая предметная область также включает две абстракции: мета-сущность RootEntity (субтип MetaEntity) и мета-отношение RootEntity.IsRelatedTo.RootEntity (субтип MetaRelationship). Именно это абстракции субтипируются для определения мета-сущностей и мета-отношений в других предметных областях. При помощью данных абстракций можно моделировать, когда не используются другие предметные области.

Общая предметная область

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

4

Область представлена двумя основными субтипами мета-сущности RootEntity: SemanticInformationObject и PresentationInformationObject.

SemanticInformationObject имеет три субтипа:

DataObject –  абстракция для описания данных
ProcessObject – абстракция для описания процессов
Derivation – описание формы наследования объекта при помощи мета-отношений UsedIn and ProducedBy.

Другие субтипы общей области:

AbstractionLevel – уровень абстракции, на котором используется создан или используется в модели. Например, концептуальный, логический или физический. Экземпляр мета-сущности может использоваться на нескольких абстрактных уровнях. Например, определение сущности Покупатель может допускаться как на коцептуальном уровне, так и абстрактном.
AlternateName – синонимы; Например для названия Vendor имеются два синонима: Supplierи Contractor
TextualConstraint –  ограничение, присоединяемое к любому семантическому объекту или набору объектов
ToolUser – для аудита данных.

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

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

5
Рис. Базовая метамодель области определения данных

6

Мета-сущности:

ComponentObject – компонета
DefinitionObject – агрегат
ReferencedElement – путь к компоненте
EquivalenceSet – класс эквивалентности
DataType – типы данных
AggregateDataType
BasicDataType
RefinedDataType
FggregateDataType

Мета-отношения:

DefinitionObject.Contains.ComponentObject
ComponentObject.References.DefinitionObject
ReferencedElement.DefinesPath.ComponentObject
EquivalenceSet.HasMember.ComponentObject.
и другие

Ясно, что все мета-сущности субтипированы из мета мета-сущности MetaEntity, а мета-отношения – из мета мета-отношения MetaRelationship.

Основная идея данной метамодели – предоставить механизм определения структурных (составных) типов данных. Этот механизм реализован на базе мета-сущностей DefinitionObject и ComponentObject.

DefinitionObject является абстрактным супертипом для всех структурных описаний. DefinitionObject представляет определение ComponentObject, используя мета-отношение ComponentObject.References.DefinitionObject. DefinitionObject может содержать компоненты, описываемые мета-сущностью ComponentObject. Включение описывается мета-отношением DefinitionObject.Contains.ComponentObjectp. Обе мета-сущности ComponentObject и DefinitionObject являются абстрактными и не могут иметь экземпляров. Экземпляры  могут иметь соответствующие их субтипы, представленные в других предметных областях.

Доступ к специфическому компоненту в общем определении. Если ссылаются на ComponentObject в DefinitionObject, простой ссылки может быть недостаточно, поскольку одно определение структуры может использоваться разными объектами, и не ясно, какой именно объект имеется в виду. Поэтому для однозначной идентификации экземпляра необходимо использовать полный путь для ComponentObject, включающий всю цепочку ComponentObject, ComponentObject.References.DefinitionObject, DefinitionObject, DefinitionObject.Contains.ComponentObject. Этот путь оформляется с помощью ассоциативного мета-отношения ReferencedElement.DefinesPath.ComponentObject. ReferencedElement – это ComponentObject, который ссылается на специфический ComponentObject, содержащийся общем определении DefinitionObject. Мета-отношение ReferencedElement.DefinesPath.ComponentObject содержит мета-атрибут SequenceNumber, который описывает последовательность, в которой обходится путь.

Пример:
typedef struct {integer com1, integer com2} complex
typedef struct { complex x, complex y} foo
foo a
foo b

Необходимо использовать полный путь:
a.x.com1
a.y.com1

Одинаковые экземпляры в общем определении. Когда два или боле компонента идентичны, они представляются с помощью механизма мета-сущности EquivalenceSet и мета-отношения EquivalenceSet.HasMember.ComponentObject. Мета-отношение EquivalenceSet.HasMember.ComponentObject группирует все компоненты, которые представлены одним и тем же экземпляром (хотя они могут быть представлены разными экземплярами потенциально разных субтипов ComponentObject). EquivalenceSet может также включать элементы ReferencedElement. Это позволяет специфическим компонентам в ситуации повторного использования общего определения быть эквивалентными.

Область моделей данных

Область моделей данных предназначена для определения мета-объектов, используемых для построения моделей данных (хорошо известных моделей сущность-связь, отрисовываемых посредством ER-диаграмм).

Область моделей данных представлена следующими мета-сущностями, которые являются подклассами мета-сущности SemanticInformationObject:

ComponentObject
Attribute – содержимое данных в DefinitionObject
ProjectedAttribute – «виртуальная» сущность, построенная и одной или нескольких «базовых» сущностей
DataModel  – модель данных, состоящая из сущностей и отношений
DataModelObject
Cluster
InheritableDataModelObject
Entity
Relationship
DataModelSubset
DefinitionObject
Cluster – высокоуровневый взгляд на модель, скрывающий детали низкого уровня
Entity – моделируемый объект
Relationship – отношение между двумя DataModelObject
Role – роль, которую играет объект в отношении
RolePlayer – несколько разных типов объектов могут играть одну роль в отношении

Атрибут представляет факт об объекте. Это самый низкоуровневый компонент данных, описывающих объект. Значение, которое он содержит, может быть не типизированным. Тип атрибута определяется посредством наследуемого мета-отношения ComponentObject.References.DefinitionObject.

7

 

8
Рис. Связь между областью моделей данных и областью определения данных

Область состояний и событий

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

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

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

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

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

Модели состояний/переходов. Модель состояний/переходов (state/event) – базовый контекст для набора состояний, переходов, событий, условий, атрибутов и действий. Определения состояний, атрибутов и действий могут совместно использоваться в разных моделях. Поэтому разные модели состояний/переходов могут иметь одинаковую декомпозицию или модель состояний/переходов может использовать другую модель состояний/переходов в качестве субмодели.

9

 

10

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

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

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

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

Состояние определяет реакцию объекта на поступающее в него событие (в том, что реакция различна нетрудно убедиться с помощью банковской карточки: в зависимости от состояния банка обслуживание (реакция банка на предъявление карточки) будет разным). Реакция объекта на событие может включать некоторое действие и/или перевод объекта в новое состояние.

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

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

В предметной области состояния представляются мета-сущностью State.Связанное с ним определение состояния представляется мета-сущностью StateDefinition.

События и условия. В любой момент времени определенное событие может произойти или не произойти. Например, в любой момент времени может случиться событие «температура становится ниже 0». Напротив, условия представляют булевы значения, которые не меняются со временем. Например, «температура выше 0 градусов» будет условием.

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

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

Одно из событий может логически предшествовать другому, либо следовать за другим, либо они могут быть независимыми; примерами логически (причинно) связанных событий являются старт и финиш одного забега, начало проводки и выдача денег клиенту (в результате этой проводки), примерами независимых событий – старт ракеты и финиш забега, проводки, запущенные с разных ATM, и т.п. Если события не имеют причинной связи (т.е. они логически независимы), они называются независимыми (concurrent); такие события не влияют друг на друга. Независимые события не имеет смысла упорядочивать, так как они могут происходить в произвольном порядке. Модель распределенной системы обязательно должна содержать независимые события и активности.

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

Условия могут использоваться как ограничения на переходы: условный переход выполняется только тогда, когда и произошло соответствующее событие, и выполнено условие этого перехода (диаграмма состояний, представленная на рисунке демонстрирует это на примере автомобильного движения по магистралям «Север-Юг» и «Запад-Восток»). На диаграммах состояний условия записываются вслед за событиями в квадратных скобках.

11
Рис. Диаграмма состояний, на которой указаны условия

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

События представляются мета-сущностью Event, условия представляются мета-сущностью Condition.

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

Переходы. Переходы представляют потенциальные следы изменения состояний между состояниями. В любой момент времени переход может или не может быть совершен в модели состояний/событий.

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

В этой предметной области не поддерживается концепция декомпозиции переходов. Однако поддерживается концепция разбиения и соединения переходов.

Переходы представляются мета-сущностью Transition.

Действия. Действие – это операция или команда, выполнение которой влияет на состояние системы, и которая может выполняться как результат возникновения события, выполнения условия или производимого перехода. Например, команда «присвоить 5 атрибуту Х» будет действием.

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

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

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

В предметной области состояний и событий действия представлены мета-сущностью Action. Связанные с ними определения действия представляется мета-сущностью ActionDefinition.

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

Активностью называется операция, связанная с каким-либо состоянием объекта (она выполняется, когда объект попадает в указанное состояние); выполнение активности требует определенного времени. Примеры активностей: выдача картинки на экран телевизора, телефонный звонок, считывание порции файла в буфер и т.п.; иногда активностью бывает просто приостановка выполнения программы (пауза), чтобы обеспечить необходимое время пребывания в соответствующем состоянии (это бывает особенно важно для параллельной асинхронной программы). Активность связана с состоянием, поэтому на диаграмме состояний она обозначается через «do: имя_активности» в узле, описывающем соответствующее состояние (см. рисунок).

12
Рис. Указание активностей и действий на диаграмме состояний

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

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

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

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

13

Каждый элемент может иметь любое число допустимых состояний So, каждое из которых уникально и задается множеством So = {N, P}, где N – название состояния; P – множество состояний портов элемента в состоянии So. Состояние каждого порта задается множеством Sp = {D, S}, где D – направление работы порта («вход», «выход», «двунаправленный»); S – состояние порта («задействован», «не задействован», «неопределенное состояние»).

Порт перехода (TransitionPort) – это абстрактная мета-сущность, при помощи которой описывают вход перехода в состояние и выход перехода из состояния. Вход перехода в состояние описывается мета-сущностью TransitionEntryPort. Выход перехода из состояния описывается мета-сущностью TransitionExitPort.

Мета-атрибут IsDefault (по умолчанию) в мета-сущности TransitionEntryPort  обозначает, что один порт перехода в описании состояния (StateDefinition) играет роль порта по умолчанию.

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

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

Если происходит конфликт, переход или действие с более высоким приоритетом имеет место, а низкоприоритетные переходы и действия отменяются.

Поведение во времени. Для систем реального времени важно точное моделирование поведения во времени переходов и действий. Некоторые техники моделирования состояний/событий предполагают, что прохождение перехода или выполнение действия не требует никакого времени, другие время учитывают и позволяют его указывать. Для поддержания всех этих концепций используются мета-атрибуты ExecutionTime и ExecutionUnit в мета-сущностях ActionDefinition и Transition. Они позволяют задавать время исполнения.

 

Модели и предметные данные

Уровни М1 и М0 описывают сущности и отношения реального мира. В моделях уровня М1 описываются типы (классы) этих сущностей. а уровне М0 описываются экземпляры определенных на уровне М1 типов (классов). Эти уровни в особых комментариях не нуждаются. Пример наглядно показывает, о чем идет речь.

14 - Модель уровня М1
Рис. Модель уровня М1

 

15 - Уровень М0  пользовательских данных
Рис. Уровень М0 пользовательских данных

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