Для того чтобы выбрать данный тип диаграмм нужно в браузере объектов выбрать раздел Use Case View->Main.

Выбираем тип диаграмм use case

Актеры

Актеры не являются частью системы – они представляют собой кого-то или что-то, что должно взаимодействовать с системой. Актеры могут:

• Только снабжать информацией систему;
• Только получать информацию из системы;
• Снабжать информацией и получать информацию из системы;

Обычно актеры выявляются из описания задачи системы.
Для выявления актеров может быть использована следующая группа вопросов:

1. Кто заинтересован в определенном системном требовании?
2. Какую роль система будет выполнять в организации ?
3. Кто получит приимущества от использования системы?
4. Кто будет снабжать систему информацией, использовать информацию, и получать информацию из системы?
5. Кто будет осуществлять поддержку и обслуживание системы ?
6. Использует ли система внешние ресурсы?
7. Выступает ли какой-либо участник системы в нескольких ролях ?
8. Выступают ли различные участники в одной роли?
9. Будет ли новая система взаимодействовать со старой?

Актер

Актер в RR отображается в виде человечка.

В моей системе основными актерами были выбраны:

1. Гость;
2. Зарегистрированный пользователь;
3. Администратор;

Актерами могут быть не только типы людей(пользователей), но и внешние системы. Например, актер “система оплаты”, внешняя система выполняющая функции расчетов.

В случае проектирования сложных систем в модель целесообразно включать описание актеров. Для этого необходимо в окно описания, которое находится внизу дерева объектов, ввести описание требуемому актеру.

Описание актера

Прецеденты

С помощью прецедентов (Use cases) в RR моделируется взаимосвязь между системой и актерами. Прецеденты определяют возможности обеспечиваемые системой для актера. Набор всех прецедентов системы определяет ее возможности и способы использования.
Прецедент

Для того, чтобы выделить прецеденты для системы, можно использовать следующую серию вопросов:

1. Каковы задачи каждого актера ?
2. Будет ли актер создавать, хранить, изменять, удалять или получать информацию из системы?
3. Какой прецедент будет создавать, хранить, изменять, удалять или получать эту информацию?
4. Должен ли актер информировать систему о внезапных изменениях внешней среды ?
5. Должен ли актер быть информирован об изменениях состояния системы?

Диаграммы прецедентов

Диграмма прецедентов (use case diagram) это графическое представление актеров и прецедентов и их взаимодействия в системе.
Пример диаграммы прецедентов

Для создания диграммы прецедентов мы либо выносим с дерева проекта на рабочее поле уже готовые прецеденты или актеров, либо с помошью панели инструментов создаем новые.
Значки актера и прецедента на панели инструментов

Между актером и прецедентом может существовать ассоциативная связь, связь может быть как от  Актера к прецеденту так и наоборот. Направление свзяи показывает кто является ее инициатором (актер или прецедент).
Чтобы создать свзяь между актером и прецедентом необходимо щелкнуть на соответсвующую связь, это либо
Association (Ассоциативная связь), либо чаще всего это
Undirectional Association (Однонаправленная ассоциативная связь).

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

Отношение extend используется для отражения дополнительных режимов, которые запускаются при наступлении кого-либо условия, а также альтернативных потоков, которые запускаются по выбору Актера.

Для создания отношений extend и include необходимо дважды щелкнуть на линию связи, и в появившемся окне, в выпадающем списке Stereotype выбрать необходимый стереотип.
Вроде бы все, что касается этой диаграммы.