Форум Сообщества Аналитиков

×


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

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

Поле №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) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;
« Последнее редактирование: 28 Июля 2011, 16:14:18 от базука »



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

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

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

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



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



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



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



Цитировать
модели, описывающей поведение простенького, но конкретного пользовательского интерфейса
А зачем Вам это?
Цитировать
Наиболее часто activity diagrams применяются для визуализации сценариев юз кейсов, которые как мы знаем желательно отвязывать от деталей интерфейса
Поищите  старые темы (которые Вы же и создавали) , почитайте  собратьев или  здесь :)
«Сделай первый шаг, и ты поймешь, что не все так страшно.»
-- L. A. Seneca --



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



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

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

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

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

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

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

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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19