В UML любой документ - это класс (или экземпляр).
Так или иначе, его надо создать в ProjectExplorer в соответствующем месте структуры.

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

Нужно стремиться не перегружать диаграммы: показывать только то, что необходимо для иллюстрации вашей мысли.
На диаграмме деятельности показывать узлы объектов не обязательно: если Вы используете поток объектов, то при его создании тоже в свойствах делается ссылка на класс. Т.о. само использование потока объектов иллюстрирует наличие информации, а не просто передачу управления.

Иногда на диаграмме деятельности показывают объектные узлы при создании объектов, или даже несколько раз один и тот же узел, чтобы продемонстрировать изменения состояния (описанное в прикрепленной Note). Если это очень нужно.

Чтобы "проваливаться" в поддиаграммы или даже использовать "поведение, предназначенное для многократного использования", т.е то, которое можно использовать в разных контекстах, нужно на диаграмме создавать не Action, а Call Bechavior. При создании элемента Вам будет предложено выбрать существующее поведение или создать новое.

Такое вызываемое поведение м.б. деятельность или взаимодействие.

Если есть вопросы, пишите, присылайте картинки. Постараюсь помочь (если это не огромный проект). Или пришлите модельный файл.

Подскажите по этому продукту, как на диаграммах последовательности отобразить конкретный тип при возврате управления?
(Либо выбрать из перечислимого типа, либо выбрать конкретный подкласс)

Когда Вы создаете сообщение на диаграмме последовательности, нужно выбрать название соответствующей операции целевого класса. Если нужной операции нет, будет создана новая операция с именем сообщения.

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

Когда Вы создаете сообщение на диаграмме последовательности, нужно выбрать название соответствующей операции целевого класса.

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

Небольшое замечание: аргумент сообщения д.б. доступен сообщению. В Вашем случае класс "Подчиненный" должен иметь атрибут "состояние".
Когда вы отправляете сообщение, аргументом является текущее значение этого атрибута.

Я вижу два варианта. Оба плохие.

- На линию жизни перед сообщением устанавливаете State Invariant. В качестве ограничения устанавливаете "состояние = <нужное значение>". Это значение будет действительно на линии жизни до следующего изменения.
На диаграмме видно, какое значение пересылается. Валидатор нарушений не обнаруживает, т.е. это правильно.
Что плохо? Не используется элемент перечисления (Enumeration)

- Выбираем сообщение. На закладке Arguments в правой таблице создаем новую строку и выбираем тип Literal String. В поле Value пишем значение аргумента.
Тоже не используется перечисление.

Извините, лучше придумать не могу!
Если найдете более приличный способ, сообщите пожалуйста, будьте добры!

P.S. Если это не "придуманный" пример, то, наверное, сообщение должно включать идентификатор работяги.

Спасибо за ответ!
Это не придуманный пример, максимально приближенный к существующему. Подчиненный имеет атрибут состояние верно, и идентификатор то же.
1. Используем State Invariant (вот вопрос почему я не могу использовать уже описанные состояния из диаграммы состояний ( в ЕА такая возможность есть)? приходится новые создавать - поле для ошибок в).
2. Пробовал я писать ручками значение аргумента, но вот отобразить на диаграмме почему-то это не удалось. Может подскажите как? (в  ЕА можно выбрать конкретное значение аргумента из списка. Не хочу сказать что ЕА лучше RSA ))))

Извините, я сегодня занят. При первой возможности посмотрю.

Я еще раз внимательно прочитал спецификацию UML.

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

Т.е. если между двумя точками вхождения указано {f>0}, то во всех отправляемых между этими точками сообщениях будет использовано f>0. Вместо {f>0} может быть {состояние="РАбота"}.

Или искать другое решение. Увы!

Я еще раз внимательно прочитал спецификацию UML.

Инвариант состояния к диаграмме состояний, к сожалению, отношения не имеет.

Леонид Борисович, не соглашусь с Вами.
Смотрим OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2

14.3.31 StateInvariant (from BasicInteractions)

Description
A StateInvariant is a runtime constraint on the participants of the interaction. It may be used to specify a variety of
different kinds of constraints, such as values of attributes or variables, internal or external states, and so on.
...

Presentation Options
...
The state symbol represents the equivalent of a constraint that checks the state of the object represented by the Lifeline.
...

На Figure 14.24 - Ignore, Consider, assert with State Invariants приведен пример нотации

Спасибо, Денис. Я действительно смотрел свой старый перевод спецификации, и, кроме того, не очень точно сформулировал мысль.

К сожалению, это не меняет сути. Особенно для Varg.

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

В остальном я, кажется, не "накривил".

Т.е. инвариант состояния представляет ограничение, в простейшем случае действующее как я написал в предыдущем письме. (В примере приведен более сложный случай).

И второй вывод - Rational выполнил спецификацию: есть два варианта нотации, и предлагается ввести текст ограничения и, не обязательно, название. Название может отражать состояние объекта.

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

подскажите пожалуйста, а как добавить свой стереотип в RSM?
А может можно расширить стандартными стереотипами  (сейчас в списке всего 7 стереотипов).
Пробовал создать свой профиль, там новый стереотип, но выбрать его так и не получается (профиль к модели применил).

В проекте профиля при создании стереотипа Вы должны указать, к каким элементам этот стереотип можно применять. Сделали? Проверьте, пожалуйста, что тип элемента указан правильно.
Если профиль к модели Вы применили, то других "фокусов" я не вижу.

Если будет совсем туго, присылайте Вашу рабочую область. Разберусь на месте.

спасибо, да не применил к каким элементам этот стереотип применяется.