Abstract
В этой статье описывается архитектура универсального редактора визуальных моделей.
Проект
Это проект я делал когда работал в InLine Software. Наш продукт был плагином к нескольким интегрированным средам разработки (Visual Cafe, JBuilder, NetBeans), который добавлял поддержку J2EE, баз данных, веб-разработки и шаблонов дезайна.
Задача
Я отвечал за несколько ключевых частей архитектуры продукта. Я также взял на себя разработку и кодирование некоторых важных возможностей. Одной из этих возможностей была синхронизация между исходным кодом и моделью в обоих направлениях: мы хотели, чтобы визуальная модель мгновенно отражала изменения в исходном коде. Мы также хотели, чтобы всякий раз, когда пользователь изменял модель, это изменение синхронно отражалось в исходном коде.
Сложности
С этой задачей было связано несколько проблем:
- Модель была неоднородной: в J2EE часть информации находится в исходном коде Java, часть - в скомпилированных файлах классов и JAR-файлах, а часть - в дескрипторах XML. Мы хотели представить объединенную картину все этих деталей.
- Нам нужно было поддерживать множество различных моделей: классы Java, JavaBeans, EJB 1.0, EJB 2.0 и т. д. Все эти модели существенно различались друг от друга.
- Мы хотели, чтобы модель легко расширялась плагинами. Например, кто-то может захотеть написать плагин к нашему инструменту, который будет моделировать шаблон абстрактной фабрики в терминах домашних функций EJB.
- Естественным представлением модели J2EE является граф, но наш инструмент должен был отображать модель в виде дерева.
- Одну и ту же модель необходимо было отображать с использованием разных пользовательских интерфейсов (например, автономного модуля, плагина в ИСР, а также с использованием Swing и SWT). Из-за этого разнообразия, механизмы пользовательского интерфейса необходимо было отделить от основной функциональности.
- Модель была потенциально очень большой. Мы не хотели строить ее целиком каждый раз, когда пользователь открывал проект. Мы хотели создавать только те части модели, над которыми работал пользователь.
Все эти требования нужно было согласовать друг с другом.
Решение
Решением стала модификация трехуровневой архитектуры. Я добавил дополнительный уровень контроллеров, состоящий из Feature (Характеристикa) и DisplayProperties (Свойствa изображения) .
Формально говоря, Feature и другие классы платформы реализуют метамета-модель, что означает, что ее можно использовать для описания произвольных мета-моделей, таких как классы Java, JavaBeans, сборка EJB 1.1, подсистема EDOC и т. д. Если термин "мета-модель" немного сбивает с толку, рассмотрим такой пример:
- Модель: "Дмитрий Плотников водит Ладу Номер 12112..." Это конкретно.
- Мета-модель: "Человек водит машину." Это можно использовать для описания целой категории конкретных моделей. "Катя водит Москвич", "Энрике водит Феррари"
- Мета-мета-модель: "Субъект-Глагол-Объект". Ее можно использовать для описания семейства подобных мета-моделей, например "Человек водит машину", "Машина выполняет программу".
Платформа Feature - это мета-мета-модель. Она позволяет давать определения произвольных мета-моделей, а затем читать, изменять, отображать их и проверять их на правильность.
Характеристики реализуют интерфейс Displayable (Отображаемое). DisplayProperties (Свойства отображения) - это объект, описывающий, как объект реализующий интерфейс Displayable должен отображаться в пользовательских интерфейсах.
По своей сути, платформа Feature оперирует деревом, в котором все части: корень, узлы и списки дочерних узлов представлены интерфейсами и реализованы по-разному для разных типов мета-моделей.
В контексте модели класса Java будет класс, реализующий интерфейс Feature, ответственный за понятие поля в Java. Кроме того, будет класс, реализующий интерфейс FeatureSet (набор характеристик) отвечающий за набор полей в классе Java. Задача этого класса - извлекать поля из дерева синтаксического разбора Java а также вставлять в него новые поля.
Другой пример - характеристика для названия JNDI для дома EJB в модели EJB 2.0. В отличие от характерстики для поля в Java, описанной выше, эта характеристика работает с дескриптором развертывания EJB, извлекает из него необходимый элемент данных и / или вставляет или изменяет этот элемент данных.
Существует иерархия абстрактных фабрик , которые управляют всей моделью. Все начинается с FeatureModelFactory , который создает экземпляр FeatureModel для желаемого типа модели. FeatureModel - это центр всех операций. Она управляет ресурсами (например, исходным кодом Java) через адаптеры ресурсов, элементами пользовательского интерфейса через DisplayPropertyFactories и характеристиками через FeatureFactories .
Feature и FeatureSet участвуют в обеих фазах цикла моделирования. Они несут ответственность за анализ базовой модели (например, исходного кода) на начальном этапе, а потом за ее изменения. Они также несут ответственность за исполнения операций пользователя на базовой модели. Для этого существуют FeatureAction (операции на характеристиках) (представьте себе кнопки в меню для узловой Feature в дереве), FeatureConstructors (для создания новых экземпляров характеристики ...) и FeatureEditors , задача которых - предоставить пользовательский интерфейс для изменения свойств характеристики.
Существуют также FeatureModelConfigurator, задача которых заключается в разрешении конфликтов между характеристиками, предоставляемыми разными плагинами.
Платформа Feature по своей природе очень абстрактна, что позволяет адаптировать ее ко всем сортам систем для моделирования. Некоторые критики говорят, что столь абстрактные вещи не бывают практически полезным. Платформа Feature доказывает обратное: у нас была команда из нескольких разработчиков, создающих реализации различных моделей. Все элементы этих моделий работали друг с другом, не будучи напрямую взаимозависимым.
Дополнительные детали можно найти в документации API.
Также есть презентация полноценной среды разработки, основанной на платформе Feature, JFX Studio. Продукт был переименован в ObjectAssembler перед выпуском.
InLine Software, компания также известная как JFX или ObjectVenture, может быть и потерпела неудачу как бизнес, но платформа Feature была бесспорным техническим успехом. Я лично считаю ее наивысшим достижением в своей карьере на сегодняшний день.
[ПОПРАВКА: Сейчас, в феврале 2021 года, я так больше не считаю. Несколько проектов в Google, такие как Android Contacts, Core Framework Google+ для Android и YouTube Music для Android, были гораздо более важны.]