О строении визуальных языков

Конкретный синтаксис (сoncrete syntax), другими словами, графическая нотация или просто нотация, - это правила изображения конструкций языка на диаграммах.

На рис. 11.4 показан пример - фрагмент диаграммы компонент UML с описанием используемых элементов UML-нотации.

Рис. 11.4. Пример неформального описания нотации

Ниже представлены различные средства описания конкретного синтаксиса.

1. Использование "графических" грамматик позволяет определить графические символы и связать их с абстрактным синтаксисом. Но тогда "за бортом" оказываются детали графического расположения конструкций друг относительно друга. Данный способ иногда используется в формальных документах, описывающих какой-либо визуальный язык. Детально графические грамматики будут обсуждаться в следующей лекции.
2. Создание формального описания конкретного синтаксиса для автоматической генерации графического редактора. Так, в среде Microsoft DSL Tools конкретный синтаксис определяется прямо вместе с абстрактным синтаксисом, в одной метамодели. Это дает возможность связать элементы нотации с конструкциями абстрактного синтаксиса, т. е. диаграммы с графом модели. Аналогично, в Eclipse/GMF для задания нотации языка используется отдельная модель (графическая модель), которая потом, в модели соответствия, связывается с доменной и моделью инструментов.
3. Визордово-скриптовый способ задания конкретного синтаксиса, реализованный, например, в пакете Visio. C помощью мастера (wizard) из обычных линий и фигур можно сконструировать произвольный графический элемент и поместить его на палитру нового редактора. Далее с помощью специального встроенного в Visio скриптового языка можно задать его поведение - точки соединения с линиями-связями, расположение текста внутри, правила перерисовки, возможности соединяться/несоединяться с различными типами линий и пр. Это удобно для необычных, но несложных фигур. Задать сложную, составную фигуру часто оказывается непросто - не хватает "мощности" встроенного языка поведения фигур.
4. Можно описывать конкретный синтаксис неформально, пользуясь рисунками с примерами и комментариями (устными или письменными) подобно тому, как это показано на рис. 11.4. Этот способ годится в случае, когда по описаниям языка не генерируется автоматически графический редактор.

При создании DSL важно понимать, что хочется делать с формальной спецификацией нотации - как в Microsoft DSL Tools генерировать целевой редактор? Или "штоб было"^{2Примерно так мне ответил один аспирант нашего факультета, когда я спросил его, зачем он использовал графические грамматики для определения конкретного синтаксиса своего несложного DSL} ? В последнем случае вполне можно ограничиться "объяснениями на примерах". В частности, UML не содержит формального определения конкретного синтаксиса.

Если обратиться к языкам программирования, то там в качестве конкретного синтаксиса выступает внешний вид текста программ. Этот внешний вид отчасти задается ключевыми словами языка (их определение включают в грамматики Бэкуса-Наура), а также структурой текста. Кроме того, большое значение на внешний вид текстов оказывают стили оформления программ - правила именования идентификаторов, правила выравнивания строк текста, наличие и формат комментариев и т. д. Стили оформления программ тщательно специфицируются в большинстве крупных проектов. Для их формализации используют обычные текстовые документы.

Служебный синтаксис (serialization syntax) - это формат хранения визуальных спецификаций, выполненных с помощью данного языка. В настоящее время для этих целей применяется, как правило, XML. Этот формат является текстовым - тексты, созданные с его помощью, можно читать "глазами", в отличие от бинарного формата (например, Microsoft Visio 2003 использует бинарный формат хранения визуальных моделей - vsd-файл). Также эти тексты можно обрабатывать различными сторонними средствами, а бинарный формат - весьма затруднительно. Ниже представлен пример XML-документа, где записан фрагмент UML-модели с рис. 11.3:

<?xml version="1.0" encoding="UTF-8"?<
<model<
	<component name="Оборудование"<
		<port name=""/<
			<interface name=""/<
	</component<

В этом примере представлен фрагмент графа модели - единственная компонента с именем "Оборудование", имеющая один порт и один интерфейс. Приведенный XML-фрагмент - это тот вид, в котором информация об этой модели будет сохранена на диске.

В случае с текстовыми языками служебный и конкретный синтаксис совпадают - как пишется, так и хранится. В настоящее время, в связи с развитием компьютерных форм представления информации, уровень представления часто отделяется от уровня хранения и передачи. Например, HTML-страницы выглядят одним образом, но хранятся совсем в другом виде.

Напомним, что визуальная спецификация разделяется на граф модели и диаграммы. И та и другая информация должна как-то храниться, и хранится она как правило, раздельно.

Формат хранения графа модели обычно является открытым, поскольку у этой информации много "пользователей":

• прежде всего, сам графический редактор или CASE-пакет;
• различные "надстройки", создаваемые пользователями CASE-пакетов; как уже рассказывалось прежде, современные CASE-пакеты имеют хорошие программные интерфейсы для создания таких "надстроек", так вот, эти интерфейсы прежде всего обеспечивают доступ к графу модели; все чаще, кроме доступа через программный интерфейс, граф модели можно "прочитать" в XML-формате, что расширяет возможности создания дополнительных "надстроек" и "мостов";
• другие графические редакторы и средства разработки ПО и пр. пакеты, которые выполняют импорт/экспорт графа модели в данный редактор.

Для универсального представления UML-моделей используется специальный XML-стандарт, независимый от производителей средств визуального моделирования. Такой формат позволяет обмен UML-моделями между разными программными средствами, реализующими UML. Стандарт носит название XMI^{3XML Metadata Interchange. Этот стандарт создан комитетом OMG [11.13]} и поддерживается многими промышленными CASE-пакетами.

Диаграммная же информация, как правило, нигде, кроме самого графического редактора, не используется и поэтому является его внутренней информацией.