Electric Café

Ещё немного вдохновения по мотивам чтения McCarthy Modality, si! Modal logic, no!.

1. Такие разные качества.

Если взять качество автомобиля серийный_номер_двигателя, то на первый взгляд оно как-то онтологически связано с наличием самого двигателя в автомобиле и качества серийный_номер у него. В реальности прямой связи нет.

Наличие значения серийный_номер_двигателя для данного автомобиля в момент времени T не означает существования двигателя с данным номером в автомобиле, его существования вообще, и даже существования автомобиля как завершённой сборки.

Есть виды деятельности, в ходе которых по наличию двигателя может устанавливаться серийный_номер_двигателя (в документах/базе), или по наличию серийника устанавливаться двигатель в машину (физически). Модальность для серийный_номер_двигателя при этом может быть requirement, promise, какая либо ещё, но даже при этом нет чётких определений, promise чего и кем. Качества не взаимозаменяемы, и даже не являются разными view, это просто разные ситуации.

2. Сферическая модальность в вакууме или...

Модальности не возникают сами по себе, ими кто-то наделяет. Возможны: "требуется стандартом $(name)". "гарантируется производителем", "предлагается компанией $(name)", etc. Часто это упрощают и остаётся лишь requirement. Если в системе только один агент может наделять модальностями, то такое упрощение будет работать (и для кодирования модальности достаточно Status из ISO 15926-2). Но при появлении второго агента всё сломается. Нужны средства для полноценного кодирования модальностей.

3. Каталоги.

Ещё одна интересная точка соприкосновения модальностей - каталоги оборудования, запчастей и иных предметов/сервисов. Что из указываемого в них относится к модальности promise от производителя (диапазон рабочих температур), а что к offer от поставщика (цена) - требует отдельного рассмотрения. Однако, заведомо известно, что декларируемые производителем качества не эквивалентны реальным. Срок годности и те же диапазоны рабочих температур принято ставить меньше (что в ряде случаев регулируется отдельными стандартами/регламентами), а другие харатеристики наоборот могут быть завышены недобросовестными маркетологами.

Как следствие - нельзя моделировать каталоги с использованием стандартных шаблонов ISO 15926-7 (PropertyRangeMagnitudeRestrictionOfClass, ...). Помимо этого, понадобится упомянутая ранее многоагентность.

1. История

Несколько лет назад я был очарован архитектурой Alias Maya (ныне Autodesk Maya). Идеальных редакторов нет, и частные решения были где-то лучше в Maya, где-то лучше в 3ds Max, где-то в других продуктах. Но один момент зацепил очень сильно.

При обработке сложных структур данных в ОО языках со статической типизацией (C++, Java, C#, ...) часто появляются ситуации, когда есть несколько интерфейсов работы с объектом, причём их доступность может быть определена только в runtime. Типичное решение:

MyInterface* interface = node->GetMyInterface();
if(interface) interface->DoSomething();

Решение в стиле Maya:

MObject node = objects[0];
MFnDAGNode dag_node(node);
MBoundingBox box = dag_node.boundingBox();

Теперь node может быть чем угодно, не указателем, а любым идентификатором, скрытым в MObject. Более того, в Maya есть способ спросить MObject о поддержке какого-либо стандартного MFn*, но ничего не мешает сделать свой MFnMyInterface, о котором MObject не знает, но который сам знает, операции с какими из MObject он поддерживает.

Далее я много работал с языками и нотациями. Знакомство с Gellish и ORM (Object Role Modelling) привело к мысли, что разделение identity какой-либо сущности и её свойств может быть очень полезным в общем случае. Негибкий комплект object+attributes создаёт слишком много проблем.

А чтение http://plato.stanford.edu/entries/temporal-parts/ привело к следующей. Любые свойства сущности зависят от точки зрения. Вчера была глина, сегодня она превратилась в скульптуру. У нас есть разные точки зрения, для вчера и сегодня. Вопрос идентичности той глины и сегодняшней скульптуры это только наш выбор.

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

Сейчас я немного вернулся к теме редакторов и их представления информации. Это возвращение породило новый дизайн.

2. Решение

Все (пока "все редактируемые", дальше не забираюсь) сущности в системе представлены каким-то уникальным набором identity. Они относятся к типу ID, который может быть:

1) Уникальным целым числом.
2) Указателем на некую структуру в памяти.
3) GUID.
4) Индексом для базы данных.
5) Чем угодно. Важна только уникальность.

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

Представим ситуацию с редактором, в котором открыта 3D сцена с анимацией. В сцене есть некий автомобиль, и в рассматриваемом коде он уже доступен через переменную car. Так может выглядеть получение свойства position этого автомобиля в традиционных решениях:

car.position()
// (0, 0, 10)

Достаточно просто. Но ведь у нас есть ещё и анимация. И если нужна позиция машинки в какой-то момент времени, то либо придётся вручную дотягиваться до треков анимации и доставать её оттуда, либо глобально запускать анимацию на всю сцену, проматывать её, а уже потом брать car.position(). Слишком грубо. Но если работать со свойствами-в-контексте, то можно проще:

document (car).position()
// (0, 0, 10)

animator = document.makeanimator()
animator.select("moving_animation1")
animator.def_time(14)

animator (car).position()
// (75.10, 12.43, 10)
document (car).position()
// (0, 0, 10)
animator.time(15) (car).position()
// (76.34, 9.07, 10)

Более того, в анимации могут легко создаваться новые сущности или меняться существующая иерархия сцены, не затрагивая статичное состояние сцены в документе:

document (car).parent()
// id131
animator (car).parent()
// id258

И вот, у нас есть контекст документа и контекст анимация+время. История изменений документа - тоже хороший контекст. Что ещё является контекстами? Точка зрения... point of view. И наши вьюхи для документов это тоже контексты.

view1 (car).uibox_color()
// "red"
view2 (car).uibox_color()
// "purple"
view1 (car).uibox_color("green")
view1 (car).uibox_color()
// "green"
view2 (car).uibox_color()
// "purple"

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

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

Для обработки сложной информации с разных точек зрения - включая 4D (рекомендуемое чтение: http://tedsider.org/papers/4d.pdf) - такое архитектурное решение оказывается наиболее удобным. И просто красивым. :)