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

Question

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

Этот вопрос возник в результате открытия, что UML и его диаграммы не в состоянии описать сложную функциональность пользовательского интерфейса с управляемым событиями потоком выполнения (то есть большие проекты javascript / jQuery)

EDIT: Я думал об использовании BPMN , но он не был создан для этой цели.

Answer 1

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

Answer 2

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

Answer 3

Вы можете использовать традиционные нотации моделирования для моделирования пользовательского интерфейса, но вскоре это заканчивается беспорядочными и бесполезными моделями. Вам следует подумать о предметно-ориентированных моделях, таких как WebML (скоро они станут стандартом OMG под названием IFML ). В этом случае вы также получаете бесплатный инструмент моделирования под названием WebRatio , который обеспечивает быстрое создание прототипов и интеграцию со спецификациями BPMN.

[Отказ от ответственности: я из Политехнического университета Милана и WebRatio, а также среди изобретателей WebML / IFML]

Answer 4

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

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

Answer 5

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

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

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

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

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