Даже такой крошечный язык, как Sequence, требует тщательного и итеративного процесса, вам нужно учитывать как семантику, так и синатакс.

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

Начнем с семантики

Когда я работал над языком последовательностей, я сел и попытался выразить диаграммы последовательностей настолько естественно, насколько мог. Я очень старался полностью игнорировать технические аспекты, такие как сложность парсинга или «правильность». Поскольку это небольшой язык и одним из вариантов использования является описание процесса, в котором он был разработан, я старался не переосмысливать и не перерабатывать язык.

Я знал, что хочу:

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

Это был один из первых набросков, которые я придумал:

Actor Alice:
    Alices description in plain text
System Acme
Sequence Login:
    Alice -> Acme: Make me a sandwich
    Acme -> Acme: Housekeeping work
         Indentend block under a single interaction
         becomes a description for that interaction.

Во-первых, я хотел иметь глобальное определение субъектов и систем, четко определяющее любого участника, имеющего место в предстоящем обмене сообщениями. У участников должно быть необязательное описание, чтобы можно было использовать более короткие имена, но все же позволять подробное описание в документе.

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

Затем каждая последовательность должна определять список сообщений, содержащий источник, назначение и фактическое сообщение.

Слова важнее символов

Мне показалось, что это неплохо, это позволяет мне описывать акторов и системы по отдельности, где актер - это человек, а система - это система. И ясно, что Алиса отправляет сообщение в Acme. Обозначение стрелок тоже было тем, к чему я привык на сайте websequencediagrams.com.

Затем я быстро понял, что использование разных символов для типа сообщения проблематично. Могу ли я отобразить асинхронное сообщение как ~>, а ответ как <-? Я пришел к выводу, что использовать слова лучше, чем символы.

Символы имеют значение только в том случае, если пользователь уже знаком с ними. Что в моем случае потребовало бы, чтобы символы были установлены в домене диаграмм последовательности. Это хорошо известный факт среди экспертов по юзабилити, который говорит, что иконке нужна метка, а отдельные иконки могут быть проблематичными.

Поэтому я заменил стрелки формулировкой спросить или сказать, чтобы лучше передать характер сообщения (асинхронный или синхронный). Я также изменил Систему на Объект, так как считал, что Система немного сужен.

Моя следующая итерация языкового черновика теперь выглядела так:

Actor Alice
    Alices description in plain text
Actor Bob
Object Acme
Sequence Hello
    Alice tell Bob
        | Sync call to Bob
    Alice ask Bob
        | Async call to Bob

Поговорите со своими пользователями

Когда я показал это своему коллеге (@provegard), он сразу указал, что я поменял местами семантическое значение tell и ask - по крайней мере, по сравнению с тем, как их определяет Akka (реализация актора JVM).

Это привело к интересному обсуждению семантики как ask, так и tell и было очень ценным и сделало очевидным, что я перепутал вещи.

  • Сообщите - должно быть асинхронным, поскольку, когда вы говорите кому-то что-то, вы не ожидаете ответа.
  • Спросить - должен быть синхронным, поскольку когда вы кого-то спрашиваете, вы ждете ответа.

Усвоенный урок состоит в том, что легко не замечать недостатков, если язык пользуется только вами. Это, однако, не означает, что несколько человек должны определять язык. Я твердо уверен, что в языке должен быть доброжелательный диктатор.

Я также удалил текст в свободной форме как из описаний, так и из текста сообщения. Причина заключалась в сочетании моего знакомства со строками и боязни синтаксического анализа фрагментов встроенного текста.

Эти изменения привели к появлению последней и нынешней версии Sequence:

Name "Sequence demo"
Actor User
Object Alpha
Object Bravo
Sequence Test
    User ask Alpha "A synchronous message"
    Alpha tell Bravo "An asynchronous message"
    Bravo replies Alpha "A response message"
    Alpha replies User """
        This is a multi-line
        message text!
        """

Мои основные выводы из определения языка Sequence до сих пор:

  • Начните с семантики. Начните с того, что вы хотите выразить, а затем переходите к грамматике и синтаксису.
  • Слова вместо символов. Значки и символы имеют ценность только в том случае, если они установлены в домене.
  • Поговорите со своими пользователями. Избегайте эгоистичного языка, разделяют ли ваши выбранные слова ваши пользователи?

Далее мы погрузимся в технические аспекты определения и анализа языка. Я покажу, как создать синтаксический анализатор для языка Sequence и как вы можете использовать TDD по-своему через определение грамматики.

Первоначально опубликовано на markuseliasson.se.