Семантика слияния пакетов с вложенными пакетами и импортом пакетов

Question

Семантика слияния пакетов с вложенными пакетами и импортом пакетов

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

Механизм расширения пакетов UML — более подробное рассмотрение слияния пакетов

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

Фон

Ссылаясь на эти спецификации:

Возьмем в качестве примера пакет MOF «Reflection», где он является принимающим пакетом, а весь UML представляет собой объединенный пакет:<mergedPackage href="http://www.omg.org/spec/UML/20131001/UML.xmi#_0"/>.

Я знаю из документа спецификации MOF, чтоElementиTypeклассы будут объединены со своими аналогами UML в результирующем пакете MOF Reflection, но я не могу найти конкретные семантические правила того, как возникает этот результат.

Следуя правилам преобразования, результирующий пакет MOF Reflection будет выглядеть примерно так (многие элементы удалены для ясности):

имя = "Отражение"
1. name="Factory" (без изменений в MOF)
2. name="Тип" (объединено с UML CommonStructure "Тип")
3. name="Объект" (без изменений в MOF)
4. name="Элемент" (объединенный с UML CommonStructure "Элемент")
5. name="Activities" (вложенный пакет будет глубоко скопирован из UML, поскольку при получении отражения MOF нет соответствующего вложенного пакета)
6. name="Values" (вложенный пакет будет глубоко скопирован...)
7. Packagename="CommonStructure" (вложенный пакет будет глубоко скопирован...)
  1. Classname="Element" (здесь неоднозначность - см. ниже)
8. ... и т. д.

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

Неоднозначность №1 — Импорт пакетов и сопоставление имен

Я предполагаю, что, поскольку пакет UML импортирует все свои вложенные пакеты в свой корневой пакет, слияние будет соответствовать именам MOF-Relection-Element с UML-CommonStructure-Element (и то же самое для Type), хотя определения не находятся в одной области действия пакета во время слияния?
1. Таким образом, слияние эффективно выполняется для Namespace.member (который включает в себя импортированные элементы), а не для Package.packagedElement?
2. Примеры, которые я видел, показывают, что импорт пакетов и элементов объединен в результирующий пакет, но включение имен импортированных элементов в сопоставление имен не описано.

Неоднозначность № 2. Обновление ссылок на результирующий элемент за пределами пакета

Каково правило преобразования, когда результирующий вложенный пакет имеет элемент с тем же именем, что и элемент в его внешнем содержащем пакете, как в случае результирующего элемента Reflection-CommonStructure-Element (и типа)?
1. В документе спецификации MOF указано, что целью использования слияния пакетов является добавление Object в качестве супертипа всех элементов и расширение Element дополнительными возможностями.
2. Это говорит о том, что «Элемент» в результирующем пакете Reflection должен заменить все ссылки на класс с именем «Элемент» даже во вложенных пакетах.
3. Я не могу найти никаких правил, описывающих это
4. Предполагаем ли мы, что все вложенные элементы пакета с тем же именем, что и внешний пакет, представляют собой одно и то же и заменяются во время слияния? Или Reflection-CommonStructure-Element удаляется во время слияния, потому что он неотличим от внешнего принимающего и результирующего элемента?

Большое спасибо

Выводы

Я награждаю ответ Акселя за помощь, а также поднимаю проблему с OMG. Также спасибо @querty_so за щедрость.

Я просмотрел все опубликованные документы по слиянию пакетов, все проблемы OMG (закрытые и открытые, в MOF и UML) и много раз просматривал спецификацию UML 2.5.1 в поисках какой-либо подсказки и просто не могу найти ни одного правила, которое делает результат Правильное слияние MOF::Reflection UML.

Я должен заключить, что файл MOF.xmi искажен.

Я считаю, что MOF::Reflection::Element и MOF::Reflection::Type должны были быть определены во вложенном пакете 'MOF::CommonStructure', а не в корне пакета MOF::Reflection. Если я понимаю семантику слияния пакетов, это правильно объединит их с UML, когда два вложенных пакета «CommonStructure» совпадают по имени, а импорт пакета UML в его корневом пакете будет перенесен в MOF::Reflection. Таким образом, все результирующие объединенные элементы UML во вложенных пакетах будут видны с неполными именами в результирующем MOF::Reflection, а Элемент и Тип будут объединены без двусмысленности или конфликтов имен.

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

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

6

uml meta-object-facility

Источник

Paul 02 окт '22 в 15:07

1 ответ

Другие вопросы по тегам uml meta-object-facility

user9430250 07 окт '22 в 13:09 2022-10-07 13:09 · Answer 1 · 2022-10-07 13:09

Обновление 10.10.22: Я получил ответ от председателя рабочей группы MOF. Он говорит, что члены совпадают и, следовательно, ошибки нет. Я думаю, по крайней мере, спецификация оставляет место для интерпретации здесь.

В свете этого объяснения я должен пересмотреть свой ответ:

Здесь нет двусмысленности: MOF::Reflection::Element отличается от MOF::Reflection:CommonStructure::Element. Это не представляет проблемы. У них разные квалифицированные имена, и совершенно ясно, что вы получаете. Последнее относится к неслитной исходной версии.

В спецификации есть пример, иллюстрирующий это (рисунок 12.2). Если вы объединяете класс A из пакета P1 с пакетом P2, то P1::A по-прежнему будет ссылаться на исходную версию.

А во втором примере у вас есть две версии Comment: одна наследуется от MOF::Reflection::CommonStructure::Element, а другая — от MOF::Reflection::Element. PackageImport не вызывает конфликтов, так как конфликтующие элементы просто не будут импортированы:

Если неразличимые Элементы будут импортированы в Пространство имен как следствие ElementImports или PackageImports, Элементы не добавляются в импортирующее Пространство имен.

Итак, опять же, никакой двусмысленности.

Предыдущий устаревший ответ

(не удалял, чтобы дискуссия еще имела смысл)

Я думаю, вы нашли ошибку в спецификации MOF. Я сообщил об этом omg: https://issues.omg.org/browse/INBOX-1518

В спецификации четко указано:

UML 2.5.1, стр. 245: импортированные элементы не объединяются (если только не существует PackageMerge для пакета, которому принадлежит импортированный элемент).

update: это относится к elementImport принимающего пакета. Поэтому здесь это не применимо. Я ошибся, процитировав его здесь.

Причина, по которой в более ранних версиях MOF не было этой проблемы, заключается в том, что рабочая группа UML хотела избежать отношения слияния в определении UML. В UML 2.4 все подпакеты были объединены в пакет UML. В UML 2.5 все подпакеты только импортируются. Похоже, это изменение было проигнорировано оперативной группой Минфина.

Итак, чтобы было совершенно ясно: элементы объединяются только в том случае, если и объединенный пакет, и принимающий пакет владеют объединяемым элементом с тем же именем и метатипом. Если оба пакета владеют соответствующими подпакетами, это правило применяется рекурсивно.

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