Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: базука от 28 Июля 2011, 14:53:28
-
Коллеги, прошу ваших комментариев к модели, описывающей поведение простенького, но конкретного пользовательского интерфейса.
На формочке находятся два поля. Начальная точка процесса - поля не заполнены, конечная - заполнены оба поля.
Поле №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 - самое подходящее.
-
Мерг по начертанию идентичен ветвлению?
-
Мерг по начертанию идентичен ветвлению?
Да, подобен ветвлению. (http://ooad.asf.ru/standarts/uml/spr/Merge.aspx)
Точно такой же ромб используется для изображения разветвления. Впрочем, отличить их совсем несложно - у разветвления один входящий и несколько исходящих переходов, причем у каждого из них есть сторожевое условие.
-
модели, описывающей поведение простенького, но конкретного пользовательского интерфейса
А зачем Вам это?
Наиболее часто activity diagrams применяются для визуализации сценариев юз кейсов, которые как мы знаем желательно отвязывать от деталей интерфейса
Поищите старые темы (http://www.uml2.ru/forum/index.php?topic=4376.msg30288;topicseen#msg30288) (которые Вы же и создавали) , почитайте собратьев (http://analyst.by/forum/viewtopic.php?f=6&t=1890) или здесь (http://usethics.ru/blog/lib/ui_at_spec_stage/) :)
-
Интересуют ваши мнения, целесообразно ли описывать пользовательские интерфейсы (конкретные интерфейсы, а не переходы между формами!) таким образом? Какие недостатки и ограничения вы видите у моделирования поведения интерфейсов в Activity?
Для данного конкретного примера в котором не очень большое количество активностей использование Activity и если это нужно для понимания как система взаимодействует с пользователем в общем виде, но не для подробного описания всего алгоритма работы - вполне применимо.
Предложу модернизировать данную модель разделением на swimlan'ы: "пользователь" и "система".
Не детализировать так дотошно активности, например вполне можно объединить в одну активности: "очистить поле" и "переместить фокус ввода на поле".
Те условия которые у вас в текстовом описании работs формы вполне можно обозначить на диаграмме в качестве notes.
-
Поддерживаю IAFedorov в рекомендациях.
Вы в ДД ограничиваете ряд аспектов реализации заранее.
Например, в соответствии с ДД невозможна дополнительная проверка данных формы на
сервере непосредственно перед вставкой в БД, хотя такая проверка лишней не будет.
Если проверка первого поля не тяжелая, то её можно делать на лету и по другим событиям,
что вообще избавит пользователе от необходимости "куда то там переводить фокус".
Мораль тут в том, что вы беретесь определять детали реализации и поэтому
должны обладать компетенцией не меньшей, чем у вашего ведущего разработчика.
Иначе можете навязать разработчикам не совсем удачные решения.
Ещё смущает, что если данные в первом поле не валидны, то система
просто перекидывает пользователя на то же поле и никак не сообщает о причине своего поведения.
Не находите что это может быть воспринято пользователем как "система глючит" ?
Мне видится, что д. б. сообщение пользователю от системы что не так с данными, которые он ввел.
Сейчас логика формы определена в вашей activity.
Скорее всего, логика этой формы, хотя бы частично, уже описывается в классе, который отвечает за эту форму.
Т.е. в вашей документации есть как минимум два разных места, касающиеся поведение этой формы.
Вот вы захотите развить форму впоследствии. Тогда придется специально отслеживать чтобы
в этих двух местах не создавалось конфликтов логики. Impact analysis никто не отменял,
но усложнять задачу заранее тоже не стоит.
Попробуйте отобразить в ДД ту логику, которую увидит только пользователь этой формы.
Всё остальное можно перенести в описание класса, отвечающего за эту форму.