Коллеги, прошу ваших комментариев к модели, описывающей поведение простенького, но конкретного пользовательского интерфейса.

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

Поле №1 заполняется пользователем с клавиатуры. В зависимости от значения, введенного в поле №1, система формирует список возможных значений для поля №2. Пользователь заполняет поле №2 при помощи выпадающего списка. Все.

Процесс описан, как видите, с помощью Activity diagram.

Интересуют ваши мнения, целесообразно ли описывать пользовательские интерфейсы (конкретные интерфейсы, а не переходы между формами!) таким образом? Какие недостатки и ограничения вы видите у моделирования поведения интерфейсов в Activity?

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

1. как пользователь поймет, что ему нужно начинать заполнение с поля 1, а поле 2 контекстно зависит от поля 1
2. что будет делать система в ответ на попытку выполнить ввод в поле 2 сначала

А в целом - есть форма, в ней два поля.
 исходное состояние к примеру - поле 1 пустое, поле 2 пустое. Поле 2 недоступно для редактирование
событие - ввод данных в поле 1 (конкретно что смотрим выход из поля, при изменении, нужно нажать отдельную кнопку)
 состояние два - поле 1 заполнено данными, поле 2 активировано
событие - выбор данные из выпадающегося списка
 состояние 3 - поле 1 заполно данными, поле 2 отображает выбор - в том числе и пустое значение, если в поле 1 введены не корректные данные

исходное состояние к примеру - поле 1 пустое, поле 2 пустое. Поле 2 недоступно для редактирование

Это можно указать в Requirement, которые будут связаны с объектами диаграммы.

 

Это можно указать в Requirement, которые будут связаны с объектами диаграммы.

можно все описать в других местах смысл в чем?

Requirement добавляются не в другом месте, а на той же диаграмме, попадают в дерево объектов, и будут присутствовать в сгенеренном по модели ТЗ.

А в целом я поняла ваше мнение, спасибо.

Requirement добавляются не в другом месте, а на той же диаграмме, попадают в дерево объектов, и будут присутствовать в сгенеренном по модели ТЗ.

Подождите, а разве это будет ТЗ? Это, пожалуй, уже постановка задачи с учетом вопросов реализации

Требования к пользовательским интерфейсам относятся к нефункциональным, а потому, если строить ТЗ на основе известного ГОСТ, описываются в разделе 4, содержащем описание системных требований, которые, как известно, делятся на функциональные и нефункциональные. Это впрочем имхо, не настаиваю. )

Пункт 2.6.2 ГОСТ 34
В подразделе «Требование к функциям (задачам)», выполняемым системой, приводят:
1) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;

Не могу с вами согласиться.

2.6.1. В подразделе «Требования к системе в целом» указывают:
- дополнительные требования.
2.6.1.14. В дополнительные требования включают:
4) специальные требования по усмотрению разработчика или заказчика системы.

вот где-то здесь Вы можете описать требовнаия к пользовательскому интерфейсу, но самые общие - обратите внимание

детальные же требования, если уж излагать то, в области
2.6.3. В подразделе «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы.
2.6.3.2. Для информационного обеспечения системы приводят требования:
6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;

Да, наверное, 2.6.3.2 - самое подходящее.

Мерг по начертанию идентичен ветвлению?

Мерг по начертанию идентичен ветвлению?

Да, подобен ветвлению.

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

модели, описывающей поведение простенького, но конкретного пользовательского интерфейса

А зачем Вам это?

Наиболее часто activity diagrams применяются для визуализации сценариев юз кейсов, которые как мы знаем желательно отвязывать от деталей интерфейса

Поищите  старые темы (которые Вы же и создавали) , почитайте  собратьев или  здесь

Интересуют ваши мнения, целесообразно ли описывать пользовательские интерфейсы (конкретные интерфейсы, а не переходы между формами!) таким образом? Какие недостатки и ограничения вы видите у моделирования поведения интерфейсов в Activity?

Для данного конкретного примера в котором не очень большое количество активностей использование Activity и если это нужно для понимания как система взаимодействует с пользователем в общем виде, но не для подробного описания всего алгоритма работы - вполне применимо.
Предложу модернизировать данную модель разделением на swimlan'ы: "пользователь" и "система".
Не детализировать так дотошно активности, например вполне можно объединить в одну активности: "очистить поле" и "переместить фокус ввода на поле".
Те условия которые у вас в текстовом описании работs формы вполне можно обозначить на диаграмме в качестве notes.

Поддерживаю IAFedorov в рекомендациях.

Вы в ДД ограничиваете ряд аспектов реализации заранее.

Например, в соответствии с ДД невозможна дополнительная проверка данных формы на
сервере непосредственно перед  вставкой в БД, хотя такая проверка лишней не будет.
Если проверка первого поля не тяжелая, то её можно делать на лету и по другим событиям,
что вообще избавит пользователе от необходимости "куда то там переводить фокус".

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

Ещё смущает, что если данные в первом поле не валидны, то система
просто перекидывает пользователя на то же поле и никак не сообщает о причине своего поведения.
Не находите что это может быть воспринято пользователем как  "система глючит" ?
Мне видится, что д. б.  сообщение пользователю от системы что не так с данными, которые он ввел.

Сейчас логика формы определена в вашей activity.
Скорее всего, логика этой формы, хотя бы частично, уже описывается в классе, который отвечает за эту форму.
Т.е. в вашей документации есть как минимум два разных места, касающиеся поведение этой формы.
Вот вы захотите развить форму впоследствии.  Тогда придется специально отслеживать чтобы
в этих двух местах не создавалось конфликтов логики. Impact analysis никто не отменял,
но усложнять задачу заранее тоже не стоит.

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