Имеется объектная модель(набор объектов и связей между ними) описывающая некоторую систему (например, электрическую схему но в принципе не обязательно именно ее),
в процессе работы приложения необходимо преобразовать ее в другую объектную модель удобную для моделирования (например распространения сигналов в эл. схеме).
Задача сделать такую систему максимально удобной для расширения, то есть хотелось бы иметь возможность в процессе эволюции приложения достаточно безболезненно добавлять новые объекты и правила, по которым производится преобразование из первой модели во вторую.
Помогите формализовать такое преобразование и правила по которым оно будет производиться ?
Извините если не понятно формулирую вопрос. И заранее благодарен за любую помощь
Здравствуйте, DarkGray, Вы писали:
DG>Можно взять за основу xml + xslt.
DG>На xml-е описываются модели, а xslt используется для описания правил преобразования.
Я об этом уже думал, но слишком медлено получается
DG>>Можно взять за основу xml + xslt.
DG>>На xml-е описываются модели, а xslt используется для описания правил преобразования.
LV>Я об этом уже думал, но слишком медлено получается
Какой примерно объем модели, и какой объем правил?
Здравствуйте, DarkGray, Вы писали:
DG>Какой примерно объем модели, и какой объем правил?
Объектов может бытьдо нескольких тысяч (типов объектов где то 10 — 20), причем нужно обеспечить возможность добавления новых типов в процессе эволюции системы... между объектами довольно сложные связи.
В качестве примера я рисунок нарисовал с маленьким графом исходной модели и граф в который это надо преобразовать.... но что то я не знаю как его сюда вставить
LV>Объектов может бытьдо нескольких тысяч (типов объектов где то 10 — 20), причем нужно обеспечить возможность добавления новых типов в процессе эволюции системы... между объектами довольно сложные связи.
На такое кол-во производительности xml-преобразований должно хватать. Тем более можно попытаться оптимизовать часто встречающиеся запросы.
Здравствуйте, DarkGray, Вы писали:
DG>На такое кол-во производительности xml-преобразований должно хватать. Тем более можно попытаться оптимизовать часто встречающиеся запросы.
то есть должно хватать? возможно ли документ приблизительно такого объема преобразовать с помощью xslt.. ну скажем за время < 1 секунды ?
и как при таком подходе обстоя дела с расширяемостью? (к сожалению я c xslt почти не знаком) например что мне необходимо будет сделать для того что бы добавить в модель объект нового типа?
LV>Имеется объектная модель(набор объектов и связей между ними) описывающая некоторую систему (например, электрическую схему но в принципе не обязательно именно ее), LV>в процессе работы приложения необходимо преобразовать ее в другую объектную модель удобную для моделирования (например распространения сигналов в эл. схеме).
LV>Задача сделать такую систему максимально удобной для расширения, то есть хотелось бы иметь возможность в процессе эволюции приложения достаточно безболезненно добавлять новые объекты и правила, по которым производится преобразование из первой модели во вторую.
LV>Помогите формализовать такое преобразование и правила по которым оно будет производиться ?
LV>Извините если не понятно формулирую вопрос. И заранее благодарен за любую помощь
Простейший transformation engine:
Все трансформации организуем в группы. Группа может содеражать другие группы или трансформации.
Каждая группа и трансформация имеют атрибут Enabled, показывающий включена ли данная сущаность. (Если у группы Enabled == false, то все трансформации и подгруппы в ней также считаются выключенными).
Каждая группы и трансфомация имеют имя. Это позволяет ссылаться на эти сущности по имени и хранить где-нибудь правила конфигурирования, например в таком виде:
Каждая трансформация имеет приоритет, трансформации применяются к модели в порядке увелечения приоритета.
Применение трансформаций: собираем все включенные в данный момент трансформации с данным приоритетом, обходим модель и применяем трансформации к каждому элементу.
Тут возникает проблема если трансформации удаляет элемент, на котором она была вызвана, или меняет модель так, что наш Visitor начинает работать неправильно. Это можно решить либо путем "не написания" таких трансформаций либо путем системы observer-ов, которые позволят всегда сохранять состояние Visitor-а корректным.
Если у нас есть метамодель, то каждую трансформацию можно прицепить к метаклассу, чтоб на данном элементе вызывались не все трансформации, а только те, которые приаттачены к метаклассу данного элемента.
Можно предусмотреть возможность динамического конфигурирования трансформаций, чтоб была возможность в процессе обхода модели динамически включать/отключать трансформации и группы на основании текущего элемента. Скажем мы должны отключать некоторые трансформации, когда обходим элемент данного метакласса.
Формализация всего этого хозяйства: ищите в инете статьи на тему graph transformation.
Здравствуйте, lesha-v, Вы писали:
DG>>На такое кол-во производительности xml-преобразований должно хватать. Тем более можно попытаться оптимизовать часто встречающиеся запросы.
LV>то есть должно хватать? возможно ли документ приблизительно такого объема преобразовать с помощью xslt.. ну скажем за время < 1 секунды ?
Неясно конечно что у тебя за компьютер, но несколько тысяч наверняка будут преобразовываться за куда меньшее время.
LV>и как при таком подходе обстоя дела с расширяемостью?
Зависит от xslt-процессора. Например для дотнетовского дела обстоят очено хорошо. Если же речь идет о расширяемости правил и входных/выходных данных то дело обстоит просто превосходно.
LV> (к сожалению я c xslt почти не знаком) например что мне необходимо будет сделать для того что бы добавить в модель объект нового типа?
