avlasov (avlasov) wrote in dot15926,
avlasov
avlasov
dot15926

Category:

Фреймовые vs. факт-ориентированные нотации

На тему отображение ОО структур во фреймовых/атрибутных нотациях супротив факт-ориентированных/предикатных.

Допустим есть у нас пара классов из 24744, в java-подобной нотации:

WorkUnitKind {
  String getPurpose();
  int getMinCapLevel();
  Outcome[] getResult();
  TaskKind[] getComponent();
}

ProcessKind extends WorkUnitKind {
  ProcessKind[] getChild();
  ProcessKind getParent();
  StageWithDurationKind[] getTemporalContext();
}


Но жаба-подобная нотация не совсем онтологическая, я использовал ее чтобы задать исходные данные, посему перепишем ее в Темплейтной нотации 15926:7 и в F-logic. Первая будет примером факт-ориентированной нотации, вторая - фреймовой соответственно (F - означает frame).

Задача состоит в том, чтобы закодировать следующие понятия:
1. специализация - ProcessKind есть подкласс WorkUnitKind
2. атрибуты - записать, какие атрибуты есть у каких классов, атрибутами в данном случае считаем data property типа String getPurpose
3. отношения - то же самое для отношений, хотя в данном случае можно считать, что отношение задаются одним или двумя свойствами, только они ссылаются на Entity, а не на data, к примеру StageWithDurationKind[] getTemporalContext().
Вобщем, будем следовать OWL традиции, и считать что есть data property и object property.
4. cardinality для отношений
5. задать инстансы и их свойства

Темплейтная нотация

Чисто для наследования запись выполняется просто:
Specialization(ProcessKind, WorkUnit Kind).

Для свойств тоже все просто, нужно задать по темплейту для каждой свойства:
StringProperty(WorkUnitKind, Purpose)
IntProperty(WorkUnitKind, MinCapLevel)
ObjectProperty(WorkUnitKind, Result, Outcome)
ObjectProperty(WorkUnitKind, Component, TaskKind)

ObjectProperty(ProcessKind, TemporalContext, StageWithDurationKind)
ObjectProperty(ProcessKind, Child, ProcessKind)
ObjectProperty(ProcessKind, Parent, ProcessKind)


Также имеет смысл указать, что Child и Process - это два стороны одной медали два конца одного и того же отношения, т.е. Parent есть инверсия Child. Это можно делать разными способами, например просто указать на инверсию:
InvertedProperty(Parent, Child)

Либо задавать отношение темплейтом, в котором в качестве параметра передавать имена для обоих концов, но сие есть не очень гибко:
Relationship(ProcessKind, ProcessKind, Child, Parent).
Также в данном темплейте можно указать и кардиналити:
Relationship(ProcessKind, ProcessKind, Child, 0, *, Parent, 0, 1).

Более гибко однако задавать и свойства и кардиналити отдельными фактами:
т.е. добавить еще
Cardinality(Child, 0, *).
Cardinality(Parent, 0, 1)


Инстантиация тоже выполняется прямолинейно:
Classification(RequirementEngineering, ProcessKind)

Хотя в случае 24744 нам нужно инстанциировать RequirementEngineering как Clabject, т.е. использовать специальный темплейт, который добавит специализацию для RequirementEngineering как подкласс Process связаны:
Clabject(RequirementEngineering, ProcessKind)

Для того, чтобы Clabject знал что RequirementEngineering должен быть именно подклассом Process, нужно связать последний с ProcessKind отношением Power/PartType, например с помощью такого темплейта:
Powertype(Process, ProcessKind)

Инстантиация свойств тоже делается несложно, нужно только придумать немного другие имена для темплейтов, нежели в случае определения пропертей:
StringPropertyInst(RequirementEngineering, Purpose, 'blah-blah-blah')
IntPropertyInst(RequrementEngineering, MinCapLevel, 1)
ObjectPropertyInst(RequrementEngineering, TemporalContext, DesignPhase)


Хотя имеет смысл определить специальные темплейты для каждого класса, чтобы было удобнее инстанциировать свойства:
WorkUnitKind_Purpose(RequirementEngineering, 'blah-blah-blah')
WorkUnitKind_MinCapLevel(RequirementEngineering, 1)
ProcessKind_TemporalContext(RequrementEngineering, DesignPhase)


Здесь есть некоторый недостаток, что имя темплейта должно включать имя класса, для которого определяется атрибут, ибо атрибуты могут дублироваться. В контексте ОО, нужно помнить, что Purpose задан именно в WorkUnitKind, а TemporalContext - в ProcessKind, хотя и тот и другой есть у ProcessKind. Но наследование атрибутов в Темплейтной нотации не выразить.

Этот недостаток исправляет

Нотация F-logic

Насколько я знаю, фреймовые нотации являются предшественниками ОО, т.е. они как раз удобнее в нашем случае:
WorkUnitKind [
    Purpose{1:1}*=>_string,
    MinCapabilityLevel{1:1}*=>_integer,
    Result{0:*}*=>Outcome,
    Component*=>TaskKind].
ProcessKind :: WorkUnitKind[
    Child*=>ProcessKind,
    Parent{0:1}*=>ProcessKind,
    TemporalContext*=>StageWithDurationKind].


Как видно, сия запись практически не отличается от Джавовской.
Единственно, что сюда надо добавить описание того, что Child и Parent - инвертированные отношения:
inverted(ProcessKind, Child, ProcessKind, Parent).

F-logic позволяет задавать сии свойства и по частям, в виде отдельных утверждений, что фактически делает ее факт-ориентированной нотацией:
ProcessKind :: WorkUnitKind.
ProcessKind[Child*=>ProcessKind].
ProcessKind[Parent{0:1}*=>ProcessKind].
ProcessKind[TemporalContext*=>StageWithDurationKind].


Инстантиация тоже выполняется прямолинейно:
RequirementsEngineering:ProcessKind[
  Purpose->'blah-blah-blah',
  MinCapLevel->1,
  TemporalContext->{DesignPhase}
].


Специально задавать инстанциацию как Clabject не нужно, ибо в F-logic это можно выразить на уровне аксиом, нужно лишь указать, какие классы связаны Power/PartType отношением:
powertype(WorkUnit, WorkUnitKind).
powertype(Process, ProcessKind).


Можно также инстанциировать по частям:
RequirementsEngineering:ProcessKind.
RequirementsEngineering[Purpose->'blah-blah-blah'].
RequirementsEngineering[MinCapLevel->1].
RequirementsEngineering[TemporalContext->{DesignPhase}].


Также отмечу что нет нужды помнить какой атрибут из какого класса - атрибуты наследуются.


В целом можно сделать вывод, что оба варианты нотаций вполне себе прямолинейны, только F-logic более компактна. Тем не менее внутри она преобразуется в примерно такие же предикаты, как и в Темплейтной нотации, только по другому именованные.
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 17 comments