Comments 5
Посмотрите Sirius, на нём делать подобные редакторы проще, чем с нуля: введение, продолжение.
Спасибо за ссылку. Ну да, для некоторого класса задач, в некоторой среде, конечно проще. Но эта статья скорее не о Java, а об ООП, как при помощи ООП в любой подходящей среде делать подобные вещи.
Кстати, будет ли Sirius рисовать диаграммы в веб-браузере, на HTML Canvas?
И ещё: исторически мы с помощью такого решения делали не редакторы (редактор взят для примера для статьи), а что-то вроде такого:
Кстати, будет ли Sirius рисовать диаграммы в веб-браузере, на HTML Canvas?
И ещё: исторически мы с помощью такого решения делали не редакторы (редактор взят для примера для статьи), а что-то вроде такого:
Sirius — это надстройка над GMF. GMF отвечает за отрисовку объектов, их перетаскивание, всякие панели инструментов и т.п.
В Sirius разработчик 1) обычно берет готовое (или создает новое) декларативное описание языка моделирования в виде Ecore-модели. Эта Ecore-модель содержит описание видов сущностей, видов отношений, которые есть в языке (например, роли, варианты использования, наследование и т.п.) Для UML, BPMN и т.п. уже есть готовые Ecore-вские модели. Для своего языка моделирования такую модель сделать достаточно просто.
Затем разработчик уже с помощью непосредственно Sirius также в декларативном виде описывает как эти элементы языка моделирования должны отрисовываться, какие для них возможны действия (создание, удаление, перетаскивание). И всё. Дальше под два этих декларативных описания частично вручную, частично на лету генерится Java-код редактора диаграмм.
При этом редактор диаграмм получается внешне и функционально практически не отличим от редакторов того же Rational Software Architect, потому что последний того же основан на GMF.
В принципе, в будущем вместо GMF может использоваться какой-то другой фреймвок для отрисовки, в том числе и на основе HTML Canvas. Eclipse активно движется в этом направлении. При этом разработчику вообще ничего не нужно будет переделывать. Потому что сам язык моделирования и редактор диаграмм описаны декларативно. Сегодня для этих декларативных описаний генерится Java-код, заточенный под GMF. Завтра может генериться JavaScript-код, заточенный под HTML Canvas.
Ну т.е. Sirius — это тоже не про Eclipse и не про Java, а про модельно-ориентированный подход к разработке редакторов диаграмм. При котором всё по возможности описывается декларативно и потом уже генерится код, под конкретную платформу и фреймвок.
Вы упомянули в статье Rational Rose (сейчас он эволюционировал в Rational Software Architect). А для последнего используется ровно такой модельно-ориентированный подход, который я описал выше. На голом ООП в RSA и подобных инструментах это не делается. Хотя это безусловно не умоляет достоинств статьи :)
В Sirius разработчик 1) обычно берет готовое (или создает новое) декларативное описание языка моделирования в виде Ecore-модели. Эта Ecore-модель содержит описание видов сущностей, видов отношений, которые есть в языке (например, роли, варианты использования, наследование и т.п.) Для UML, BPMN и т.п. уже есть готовые Ecore-вские модели. Для своего языка моделирования такую модель сделать достаточно просто.
Затем разработчик уже с помощью непосредственно Sirius также в декларативном виде описывает как эти элементы языка моделирования должны отрисовываться, какие для них возможны действия (создание, удаление, перетаскивание). И всё. Дальше под два этих декларативных описания частично вручную, частично на лету генерится Java-код редактора диаграмм.
При этом редактор диаграмм получается внешне и функционально практически не отличим от редакторов того же Rational Software Architect, потому что последний того же основан на GMF.
В принципе, в будущем вместо GMF может использоваться какой-то другой фреймвок для отрисовки, в том числе и на основе HTML Canvas. Eclipse активно движется в этом направлении. При этом разработчику вообще ничего не нужно будет переделывать. Потому что сам язык моделирования и редактор диаграмм описаны декларативно. Сегодня для этих декларативных описаний генерится Java-код, заточенный под GMF. Завтра может генериться JavaScript-код, заточенный под HTML Canvas.
Ну т.е. Sirius — это тоже не про Eclipse и не про Java, а про модельно-ориентированный подход к разработке редакторов диаграмм. При котором всё по возможности описывается декларативно и потом уже генерится код, под конкретную платформу и фреймвок.
Вы упомянули в статье Rational Rose (сейчас он эволюционировал в Rational Software Architect). А для последнего используется ровно такой модельно-ориентированный подход, который я описал выше. На голом ООП в RSA и подобных инструментах это не делается. Хотя это безусловно не умоляет достоинств статьи :)
Ещё библиотека-фреймворк (LGPL) на тему диаграмм: http://www.adaptagrams.org/ (пример интеграции в Swing приложение: http://mbeddr.com/2015/03/05/graphicalSM.html)
Да много их, много. И главное, уже очень много таких, которые действительно красиво решают задачу раскладки графа на плоскости.
Однако довольно часто на практике сделать своё маленькое, но идеально решающее твою задачу решение бывает лучше, чем использовать готовый большой фреймворк, который всё равно тебе подойдёт неидеально. Я пару раз встречался с таким, когда деньги тратились, чтобы купить лицензии на готовые граф-библиотеки, потом писался монструозный код-обвеска, а потом оказывалось, что нужного поведения всё равно не получается )) да плюс чужие баги))
Ещё при решении этой задачи красиво применяются паттерны ООП: композиция и делегирование.
Однако довольно часто на практике сделать своё маленькое, но идеально решающее твою задачу решение бывает лучше, чем использовать готовый большой фреймворк, который всё равно тебе подойдёт неидеально. Я пару раз встречался с таким, когда деньги тратились, чтобы купить лицензии на готовые граф-библиотеки, потом писался монструозный код-обвеска, а потом оказывалось, что нужного поведения всё равно не получается )) да плюс чужие баги))
Ещё при решении этой задачи красиво применяются паттерны ООП: композиция и делегирование.
Sign up to leave a comment.
Реализация интерактивных диаграмм с помощью ООП на примере прототипа редактора UML-диаграмм. Часть 2