Очень нужна помощь знатоков UML.

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

В связи с возникшей задачей, появились вопросы:
1. имеет ли место в UML сущность "Интерфейс пользователя" или "Экранная форма" (либо что-то подобное: GUI, графическое представление и т.п.)?
2. Если да, то в каких диаграммах корректно её использование?
3. С какими сущностями и каким типом отношений они связываются?

Крайне полезно было бы увидеть конкретные примеры.
Также, если вам известны инструменты, позволяющие проводить моделирование на UML и отрисовывать экранные формы - сориентируйте, пожалуйста.

Надеюсь на вашу помощь!

Что первое приходит на ум - Диаграмма Взаимодействия и Последовательности:
http://www.visual-paradigm.com/VPGallery/diagrams/Collaboration.html

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

А так, в принципе, чтобы показать, где используется экранные формы, практически во всех диаграммах с помощью связи зависимости со стереотипом <<use>>

Многие инструментальные средства UML могут использовать профиль UML Analysis. В модели анализа к классу можно присоединять стереотипы Entity, Controller и Boundary. Последний стереотип (Граничный класс) и представляет интерфейс.

Статическая диаграмма - это диаграмма граничных классов. Между классами устанавливаются отношения агрегации или композиции (чаще используют композицию, т.к. экземпляр граничного класса существует только во время выполнения).

Ну, а динамическое поведение моделируется, как и написал bas, с помощью диаграмм последовательности. Правда, я не рисую взаимодействие только граничных классов. Обычно, на диаграмме последовательности присутствуют объекты всех трех типов: граничный класс, контроллер, который обрабатывает управления граничных классов, и сущности, которые "работают" с информацией.

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

1. имеет ли место в UML сущность "Интерфейс пользователя" или "Экранная форма" (либо что-то подобное: GUI, графическое представление и т.п.)?

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

2. Если да, то в каких диаграммах корректно её использование?

Вероятно любые структурные диаграммы

3. С какими сущностями и каким типом отношений они связываются?

Они - это диаграммы? Отношения могут быть агрегации и композиции на мой взгляд, но наверное вполне допустимо внутренние классы или внутренняя структура классов (она же композиция)

Крайне полезно было бы увидеть конкретные примеры.

Посмотрите книгу, там авторы тоже пытаются найти возможность привязать UML к моделированию ЧМ интерфейсов

Также, если вам известны инструменты, позволяющие проводить моделирование на UML и отрисовывать экранные формы - сориентируйте, пожалуйста.

Visual Paradigm
Enterprise Architect
Magic Draw
Visio

Не стоит за бывать и о динамике. Поскольку GUI чаще всего ориентированы на события, то я бы активно использовал концепцию конечных автоматов.