wiki:ru/AMF

Version 1 (modified by vadim.godunko, 11 years ago) ( diff )

--

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

API библиотеки моделирования

На сегодняшний день имеется три варианта API библиотеки моделирования. Далее приводятся все три варианта.

Классический

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

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

Классический объектно-ориентированный (Ada2012)

Второй классический вариант API требует поддержки компилятором стандарта Ada2012, в противном случае все интерфейсные типы придётся описать в одном пакете из-за слишком большого числа перекрёстных связей.

Для каждого класса объявляется интерфейсный и ссылочный типы, причём для исключения шансов ошибочного использования пользователем освобождения памяти ссылочный тип объявляется как неосвобождаемый.

with CMOF.Classifiers;
with CMOF.Elements;

package CMOF.Classes is

   type CMOF_Class is limited interface
     and CMOF.Classifiers.CMOF_Classifier;

   type CMOF_Class_Access is access all CMOF_Class'Access;
   for CMOF_Class_Access'Storage_Size use 0;

   function Get_Owner
    (Self : not null access CMOF_Class) return CMOF.Elements.CMOF_Element_Access;

Можно предложить и альтернативную схему именования, например:

with CMOF.Classifiers;
with CMOF.Elements;

package CMOF.Classes is

   type CMOF_Class_Interface is limited interface
     and CMOF.Classifiers.CMOF_Classifier_Interface;

   type CMOF_Class is access all CMOF_Class_Interface'Access;
   for CMOF_Class'Storage_Size use 0;

   function Get_Owner
    (Self : not null access CMOF_Class_Interface) return CMOF.Elements.CMOF_Element;

Второй вариант уменьшает количество кода при использовании и в то же время немного "скрывает" факт использования ссылочного типа; поскольку это не является важным с точки зрения управления памятью.

with CMOF.Classifiers;
with CMOF.Elements;

package CMOF.Classes is

   type CMOF_Class is interface
     and CMOF.Classifiers.CMOF_Classifier;

   function Get_Owner
    (Self : CMOF_Class) return CMOF.Elements.CMOF_Element'Class;

Объектно-ориентированный надклассовый

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

Управление структурами данных

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

Поддержка нескольких extent-ов

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

Поддержка валидации/транзакций

Валидация модели может выполняться вспомогательными компонентами (например, модулем OCL), поэтому может полезным иметь механизм транзакций с пвалидачией при фиксации изменений.

Поддержка версий

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

Поддержка хранения данных в реляционных базах данных

Использование базы данных как локального хранилища (да и глобального тоже) может быть полезно для функций отката/наката, слияния моделей.

Поддержка отката/наката

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

Note: See TracWiki for help on using the wiki.