Типизация Class/Relationship (Action)
Прошу продолжить обсуждение начатое Виктором http://community.livejournal.com/praxos/7175.html
Под рассмотрением 24744-Action. "An action is a usage event performed by a task upon a work product. Actions represent the fact that specific tasks use specific work products."
Было предложено два варианта типизации 24744-Action: CO Event или CO Relationship. (CO = Class of).
Для того, чтобы поддержать обсуждение выражаю эти варианты с помощью Template DSL.
CO Relationship
1. На диаграмме роли Task и WorkProduct в их отношении Action подменены именами отношений (не ролей!) между Task - Action (Causes) и Action - WorkProduct (ActsUpon). Считаю, что это некорректно. Логично было бы использовать роли User и UsedObject соотвтственно (Task uses WorkProduct). Но в ISO 24744 такие роли не определены, т.к. Action рассматривается как класс, а не отношение.
2. CO RelationshipWithSignature имеет 2 атрибута: ClassOfEnd1 и ClassOfEnd2. Это роли в отношениии. Правильно ли, что указывая на специализацию CO RelationshipWithSignature, т.е. Action, мы можем сказать, что ее атрибуты будут иметь другие имена - User и UsedObject (в приведенном примере Causes? и ActsUpon?)
3. Виктор писал ( http://community.livejournal.com/praxos/6065.html):
"Что это такое за непоименованное отношение в середине диаграммы? Может быть, это некий класс Generic_Causes, содержащий "все возможные" отношения причинности с Cause и Effect, а ниже - его подкласс, класс отношений ISO_24744_Causes, связывающих именно Task и Action метамодели?"
Мне кажется, это может быть одним из ответов на вопрос, почему в RDL типы из части 2 дублируются аналогичными типами с префиксами части 4. Попробую проиллюстрировать предположение:
"4" - это префикс, указывающий на часть 4. 2 не добавлял, голубым шрифтом по умолчанию типы второй части.
Предположение: надкласс отношения Action, типизированного как CO RelationshipWithSignature, есть CO RelationshipWithSignature, но из 4-ой части.
4. При таком варианте, на первый взгляд, не выразить роли и имена отношений Task-Action и Action-WorkProduct из 24744.
Но кажется можно прижумать обходные пути. Кроме того, это касается графического DSL. Может быть, на другом языке можно.
CO Event
1. Вопрос {2] из предыдущго списка остается в отношении к Causes и ActsUpon.
2. Не все отношения и роли именованы в ISO 24744.
Что выбрать?
Анатолий писал: "Вообще-то, сила 15926, в отличие от различных "просто логических систем" как раз в том, что предлагается онтология. В этом плане можно договориться о "чисто формальном использовании" 201 понятия, а можно считать, что это разделяемая картина мира. Если это формальное использование, то "любое отношение можно выразить классом, и наоборот. Атрибуты -- можно с ними, а можно и без". Если же речь идет о том, что все эти объекты (thing) находятся в жизни, то методически правильно будет понять онтологический статус (а он идет от деятельности! Что с этим объектом-thing собираемся делать?)..."
1. В описании нотации 24744, по поводу того, как использовать Action/*Kind, сказано следующее: "Action diagrams represent the usage that task kinds make of work product kinds. These usages are basically modelled as action kinds in 24744. Action diagrams, therefore, serve to visualise the bridge between the process and product sides of a method."
Из определения: "Actions represent the fact that specific tasks use specific work products."
Как используется такой факт? Может быть здесь стоит посмотреть на подход к фактам у Dietz'a и его модели ORM? Или это зависит от архитектуры композера?
2. Action/*Kind идентифицируется парой Task/*Kind - WorkProduct/*Kind. Виктор писал: "Action всегда связан с одним и только одним Task и с одним и только одним WorkProduct." В этом смысле отдельных классов Action/*Kind не требуется.
Замечание: Важно отметить наличие ActionType, возможно, их тоже надо учитывать для однозначной идентификации.
UPD:
На рисунке ниже попытка сформулировать отношения классификации и специализации между 24744 и 15926 при классификации/типизации Action как CO Relationship.
Есть версия:
* Классификация/типизация
Action - CORelationship
ActionKind - COCORelationship
Action instance - Relationship/ можно указать ActionKind, но мы выбираем из 201 понятия 2 части) / может быть кроме ActionKind не должно быть другой классификации? или может надо одновременно указывать тип из второй части и непосредственный Parent?
* Специализация
Action instance - Null
Action - Relationship
ActionKind - CORelationship
Замечания:
1. Классификация/типизация для наглядности показана стрелками, а не именем типа в нижней части блока.
2. CO заменено на Kind для аналогии с powertype pattern'ами 24744.
Можно увидеть два powertype pattern'а, которые связывают 15926 и 24744.
"Получается похоже на то, что Action и ActionKind это 2 клабджекта.
Получится:
Action инстанс RelationshipKind, но подкласс Relationship. Это Powertype pattern - Relationship/RelationshipKind
ActionKind инстанс RelationshipKindKind, но подкласс RelationshipKind. Это Powertype pattern - RelationshipKind/RelationshipKindKind."
Видны ли ошибки? Укажите, перерисую.
Под рассмотрением 24744-Action. "An action is a usage event performed by a task upon a work product. Actions represent the fact that specific tasks use specific work products."
Было предложено два варианта типизации 24744-Action: CO Event или CO Relationship. (CO = Class of).
Для того, чтобы поддержать обсуждение выражаю эти варианты с помощью Template DSL.
CO Relationship
1. На диаграмме роли Task и WorkProduct в их отношении Action подменены именами отношений (не ролей!) между Task - Action (Causes) и Action - WorkProduct (ActsUpon). Считаю, что это некорректно. Логично было бы использовать роли User и UsedObject соотвтственно (Task uses WorkProduct). Но в ISO 24744 такие роли не определены, т.к. Action рассматривается как класс, а не отношение.
2. CO RelationshipWithSignature имеет 2 атрибута: ClassOfEnd1 и ClassOfEnd2. Это роли в отношениии. Правильно ли, что указывая на специализацию CO RelationshipWithSignature, т.е. Action, мы можем сказать, что ее атрибуты будут иметь другие имена - User и UsedObject (в приведенном примере Causes? и ActsUpon?)
3. Виктор писал ( http://community.livejournal.com/praxos/6065.html):
"Что это такое за непоименованное отношение в середине диаграммы? Может быть, это некий класс Generic_Causes, содержащий "все возможные" отношения причинности с Cause и Effect, а ниже - его подкласс, класс отношений ISO_24744_Causes, связывающих именно Task и Action метамодели?"
Мне кажется, это может быть одним из ответов на вопрос, почему в RDL типы из части 2 дублируются аналогичными типами с префиксами части 4. Попробую проиллюстрировать предположение:
"4" - это префикс, указывающий на часть 4. 2 не добавлял, голубым шрифтом по умолчанию типы второй части.
Предположение: надкласс отношения Action, типизированного как CO RelationshipWithSignature, есть CO RelationshipWithSignature, но из 4-ой части.
4. При таком варианте, на первый взгляд, не выразить роли и имена отношений Task-Action и Action-WorkProduct из 24744.
Но кажется можно прижумать обходные пути. Кроме того, это касается графического DSL. Может быть, на другом языке можно.
CO Event
1. Вопрос {2] из предыдущго списка остается в отношении к Causes и ActsUpon.
2. Не все отношения и роли именованы в ISO 24744.
Что выбрать?
Анатолий писал: "Вообще-то, сила 15926, в отличие от различных "просто логических систем" как раз в том, что предлагается онтология. В этом плане можно договориться о "чисто формальном использовании" 201 понятия, а можно считать, что это разделяемая картина мира. Если это формальное использование, то "любое отношение можно выразить классом, и наоборот. Атрибуты -- можно с ними, а можно и без". Если же речь идет о том, что все эти объекты (thing) находятся в жизни, то методически правильно будет понять онтологический статус (а он идет от деятельности! Что с этим объектом-thing собираемся делать?)..."
1. В описании нотации 24744, по поводу того, как использовать Action/*Kind, сказано следующее: "Action diagrams represent the usage that task kinds make of work product kinds. These usages are basically modelled as action kinds in 24744. Action diagrams, therefore, serve to visualise the bridge between the process and product sides of a method."
Из определения: "Actions represent the fact that specific tasks use specific work products."
Как используется такой факт? Может быть здесь стоит посмотреть на подход к фактам у Dietz'a и его модели ORM? Или это зависит от архитектуры композера?
2. Action/*Kind идентифицируется парой Task/*Kind - WorkProduct/*Kind. Виктор писал: "Action всегда связан с одним и только одним Task и с одним и только одним WorkProduct." В этом смысле отдельных классов Action/*Kind не требуется.
Замечание: Важно отметить наличие ActionType, возможно, их тоже надо учитывать для однозначной идентификации.
UPD:
На рисунке ниже попытка сформулировать отношения классификации и специализации между 24744 и 15926 при классификации/типизации Action как CO Relationship.
Есть версия:
* Классификация/типизация
Action - CORelationship
ActionKind - COCORelationship
Action instance - Relationship/ можно указать ActionKind, но мы выбираем из 201 понятия 2 части) / может быть кроме ActionKind не должно быть другой классификации? или может надо одновременно указывать тип из второй части и непосредственный Parent?
* Специализация
Action instance - Null
Action - Relationship
ActionKind - CORelationship
Замечания:
1. Классификация/типизация для наглядности показана стрелками, а не именем типа в нижней части блока.
2. CO заменено на Kind для аналогии с powertype pattern'ами 24744.
Можно увидеть два powertype pattern'а, которые связывают 15926 и 24744.
"Получается похоже на то, что Action и ActionKind это 2 клабджекта.
Получится:
Action инстанс RelationshipKind, но подкласс Relationship. Это Powertype pattern - Relationship/RelationshipKind
ActionKind инстанс RelationshipKindKind, но подкласс RelationshipKind. Это Powertype pattern - RelationshipKind/RelationshipKindKind."
Видны ли ошибки? Укажите, перерисую.