Языки моделирования функциональности Пользовательского интерфейса?

Одна вещь, которая приходит в голову, - это Визуальный словарь для информационной архитектуры Джесси Джеймса Гарретта .

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

Я не думаю, что существуют какие-либо стандарты для этой конкретной цели (я думал о том же самом на днях). SysML близок, я думаю, хотя это определенно перебор.

В основном, я думал о том, что если профиль UML или метамодель определены с основными компонентами пользовательского интерфейса и событиями ("текстовое поле", "однократное нажатие" и т.д.), то различные реализации пользовательского интерфейса (HTML, Swing, AJAX) могут быть созданы с помощью преобразований XMI модели экземпляра. В противном случае, по крайней мере, появился бы более четкий и формальный способ описания функциональности данного пользовательского интерфейса.

Я только что наткнулся на ваш вопрос, и к этому вопросу я отношусь серьезно. Вот мой ответ на этот вопрос, и я использовал его в различных формах более 20 лет.

По сути, вот критерии, которые я ищу в таком описательном языке:

• Язык не должен быть разбавленным и неспособным к таким вещам, как доступ к данным или базовым примитивам потока управления, таким как IF, FOR и вызовы подпрограмм.Я добиваюсь этого, создавая язык поверх основного стандартного языка с помощью макросов и определений функций. Таким образом, он не требует синтаксического анализатора или интерпретатора, имеет прямой доступ к данным приложения и имеет примитивы потока управления базового языка (но только некоторые из них).
  Причина включения примитивов управления потоком в описательный язык заключается в их описательной полезности. Конструкция IF (test) -ELSE-END - это способ сказать, что один из двух наборов элементов управления должен отображаться в зависимости от значения (test). Конструкция FOR - END - это способ сказать, что набор элементов управления должен отображаться в множестве, например линейный массив элементов управления. При желании они могут быть вложены, чтобы получить двумерную матрицу элементов управления. Подпрограмма (с параметрами) может отображать набор элементов управления, а затем может быть вызвана в нескольких местах для многократной репликации этого набора. Без таких примитивов в DSL такие структуры сложно определить.

• Язык не должен требовать от лица, определяющего пользовательский интерфейс, иметь дело с проблемами, которые существуют только ради реализации, такими как обработка событий ввода, создание, удаление и присвоение имен элементам управления, а также перемещение данных между элементами управления и данными приложения. . Так, например, каждое редактирование, кнопка или другой элемент управления представляет собой одну строку кода. Код для обработки событий, таких как нажатие кнопки, написан непосредственно рядом со строкой кода, определяющей кнопку (не в отдельной функции или закрытии).Привязка элементов управления к данным приложения выполняется «снизу» и не является заботой программиста пользовательского интерфейса. Чтобы выполнить всю эту работу, она основана на структуре управления под названием «Дифференциальное выполнение», на которую я наткнулся в 1986 году. Она основана на инкрементном повторном выполнении программы таким образом, чтобы она могла постепенно обновлять свой вывод. В этом случае вывод представляет собой набор элементов управления на поверхности окна. Эти элементы управления автоматически создаются, удаляются, перемещаются или иным образом изменяются в ответ на изменения в состоянии приложения, при этом программисту пользовательского интерфейса не приходится думать об изменениях состояния.

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