Для того чтобы выбрать данный тип диаграмм нужно в браузере объектов выбрать раздел 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 выбрать необходимый стереотип.
Вроде бы все, что касается этой диаграммы.

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

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

Так что каждый ООП программист must have.