В настоящее время пытаюсь определиться с собственной политикой описания поведения пользовательских интерфейсов в UML.

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

В связи с чем позвольте несколько вопросов к многоуважаемому сообществу:

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

Что, с вашей точки зрения, более эффективно для этой цели, и почему, – диаграммы деятельности, State Machine или взаимодействия?

Если можно, приведите конкретные примеры ваших моделей GUI в каких-либо видах диаграмм.

Все таки диаграммы состояний более подходят для этого.
То что ДД и ДС путают - нормально, ДД в UML 1.x подмножество ДС, но картина именилась в UML 2.0
Сейчас ДД имеют семантику сетей Петри, это ближе к системам массового обслуживания.

ДС ориентировано на объект, пользовательский ГУИ - формы и элементы - это объекты.

В настоящее время пытаюсь определиться с собственной политикой описания поведения пользовательских интерфейсов в UML.

Попробуйте посмотреть в сторону диаграммы последовательности. По моему очень удобно и наглядно можно описать поведение GUI. Личных примеров привести не могу, т.к. не делаю, но чувствую что уже пора начинать

Попробуйте посмотреть в сторону диаграммы последовательности. По моему очень удобно и наглядно можно описать поведение GUI. Личных примеров привести не могу, т.к. не делаю, но чувствую что уже пора начинать

Что-то у меня есть некоторое сомнение. Раз Вы чувствует, что пришло время, может и сделаете пример ДП хотя бы для примера топикстартера?

Тоже по совету небезызвестного товарища использую Диаграмму состояний,
Но есть проблема.

Возьмём типичный интернет сайт, у которого 5 разделов. На сайтах мы обычно можем переходить из любого раздела в любой раздел.

На вложенном рисунке представлена диаграмма состояний, которая из этого получается, выглядит не очень.(смущает количество связей). А если таких разделов на сайте 10?

Или делать так много разделов у сайта это идеологическая ошибка?

Вы получили полносвязный граф. Такое возможно. Для улучшения наглядности можно ввести промежуточное псевдосостояние. Или соединитель - join

Особенность ООП - "массовое" использование различных дихотомий.
При моделировании интерфейса (если это нужно в проекте, и если в этом проекте начальное представление интерфейса - обязанность системного аналитика) я использую дихотомию "статика/динамика".
В RUP определен профиль UML для модели анализа. Этот профиль получил широкое распространение вне RUP. Там есть стереотип "граничный класс". По сути - это класс, представляющий элемент GUI (окно, форма, область формы, кнопка и т.д.).

GUI обеспечивает возможность взаимодействия пользователя с системой. Это взаимодействие описывается в UC (я описываю с использованием диаграммы последовательности). В тексте, документирующем действия, уже упоминаю, м.б., неявно, элементы интерфейса.

По мере рисования и описания деятельности я создаю граничные классы в модели анализа (это статическая модель интерфейса). Я использую классы для представления форм и областей форм, если есть, атрибуты для обозначения полей и операции для обозначения кнопок.
Прошу обратить внимание, что это УПРОЩЕННОЕ ОПИСАНИЕ способа. На самом деле есть много нюансов. Например, атрибуты формы представляют и области, которыми владеет форма, и т.д.
Если объекты интерфейса на диаграмме деятельности показаны явно, то этим объектам присваивается тип - соответствующий граничный класс.

В принципе, на этом ответственность системного аналитика заканчивается. Но много где ответственность системного аналитика распространяется и на модель анализа. Если нет - это должен делать проектировщик (анализа, т.е. модели, не определенной для конкретной платформы разработки).

Для каждого UC в модели анализа создается кооперация со стереотипом UCRealization. И рисуется диаграмма последовательности (полная или набор сценариев). В этой диаграмме показывается динамика: граничный класс получил сообщение пользователя, преобразовал и отправил контроллеру и т.д.

Но поведение, описанное в UCR, относится только к этому UC. А некоторые граничные классы участвуют в реализации различных UC!

Диаграмма состояний описывает полное поведение классификатора во всех возможных контекстах. По этому нарисовать ее довольно сложно. И не нужно.

Если я отвечаю за представление интерфейса, я включаю диаграмму классов (граничных) в спецификацию UC.
Пример можно посмотреть в приложении к статье "http://lnew.ucoz.ru/load/html_publikacii_modelej_rsa/opyt_ispolzovanija_uml/povyshenie_proizvoditelnosti_analitika_06/3-1-0-6". Это не по теме статьи, я случайно забыл убрать из живого документа.

Иногда (редко) я составляю по модели карту интерфейса (таблица со множеством столбиков; если кто хочет - могу прислать пример с пояснениями).

политикой описания поведения пользовательских интерфейсов в UML

А скажите пожалуйста, часто ли Вам приходиться описывать поведение интерфейса в UML?

Сам делаю это крайне редко, именно в UML.
А прототипирование делаю чере другие прграммы, например Visio.

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

Я должен описать UC так, чтобы обеспечить разработчику всю необходимую информацию. В частности, я должен описать вводы пользователя, какую информацию должен получить (увидеть) пользователь и т.д.

Я глубоко убежден, что самый экономичный способ передачи такой информации - это моделирование на UML. Экономичный и для команды в целом.
Я все равно должен сделать соответствующее описание. Если я сделаю это в виде текста, лишнее последовательное звено (в д.с. проектировщик анализа) вынужден будет "перекладывать" мой текст на модель анализа.
С другой стороны, мне гораздо проще сделать модель и по ней сгенерировать отчет. Проектировщик получит "полуфабрикат", который ему нужно будет только дополнить, например, описанием поведения.
 
Т.о., статическую модель граничных классов и отдельных классов сущностей на UML я делаю всегда, для экономии времени и сил.
Моделирование (статическое) интерфейса и прототипирование - это, мне кажется, совершенно разные вещи.

Описание поведения класса, в т.ч. граничного, ответственность проектировщика. Я делаю это в двух случаях:
- если я выступаю в роли наставника проекта (метод "делай, как я")
- если меня наняли на совмещение аналитика и проектировщика

Спасибо , за уточнение.

Просто мне чаще приходилось делать скорее всего "описание поведения класса", наверно можно так это назвать.
И поэтому требовался документ с описанием как делать программисту  (где какие кнопки расположить , и т.п.) и практически этот же документ согласовывался с Заказчиком (в части интерфейсных форм, поведения).
Получался конечно симбиоз и наверное не совсем экономично, но вот так было.

В том проекте, который рассматривается как пример в цикле моих статей (http://lnew.ucoz.ru/news/povyshenie_proizvoditelnosti_analitika/2011-07-25-18), веб-дизайнер делал прототип интерфейса по диаграмме граничных классов, представленной в спецификации UC. Системный аналитик должен согласовать этот прототип с заказчиком.
Но разработка прототипа - не его обязанность и в классике, и в большинстве проектных групп.

Поведение интерфейса вообще согласовывать с заказчикам нет необходимости, кроме как иллюстрацию к спецификации UC.

Видимо, в своей компании Вы аналитик, проектировщик и дизайнер в одном лице. Не позавидуешь!

Что касается артефактов, то они почти одни и те же при любой организации, только распределение исполнителей разное.

Как представлять "поведение интерфейса"? А что это такое?
- Поведение отдельного граничного класса во всех возможных ситуациях всех применений этого класса?
- Поведение граничного класса в кооперации взаимодействующих классов при реализации конкретного UC? Ну, это самое простое, описано во всех книжках по проектированию: диаграмма последовательности.
- Поведение всех граничных классов системы во всех ситуациях?

Первое и третье - это многомерный кошмар! Вы, наверное, убедились в этом, когда смотрели табличку, которую я Вам прислал.
Но такая таблица все же полезна разработчику (форму можно уточнить). И это, конечно, не UML. Но первоисточником должна служить модель UML.