ТСПП - Лекция 3

Лекция 2. Диаграммы использования

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

акторами.

Диаграммы использования имеют самую простую нотацию: всего два основных типа сущностей (действующие лица и варианты использования) и три типа отношений (зависимости, ассоциации, обобщения).

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

Графически актор изображается либо " человечком " либо символом класса с соответствующим стереотипом, как показано на рис. 2.1. Обе формы представления имеют один и тот же смысл и могут использоваться в диаграммах. "Стереотипированная" форма чаще применяется для представления системных акторов или в случаях, когда актор имеет свойства и их нужно отобразить.

Рис. 2.1 Изображение актора

Прецеденты ( варианты использования)

Прецедент (use-case) или вариант использования - описание отдельного аспекта поведения системы с точки зрения пользователя.

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

Прецеденты обозначаются в виде эллипса, внутри которого указано его название (рис.2.2 ).

Рис 2.2. Изображение прецедента.

Примечания

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

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

Примечания могут иметь стереотипы. В UML определены два стандартных стереотипа для примечаний:

-«requirement» — описывает общее требование к системе;

-«responsibility» — описывает ответственность сущности (классификатора). На рис.2.3 приведен пример примечания.

Рис.2.3. Изображение примечания

Отношения на диаграммах использования

На диаграммах использования применяются следующие основные типы отношений: - ассоциация между действующим лицом и вариантом использования;

-обобщение между действующими лицами;

-обобщение между вариантами использования;

-зависимости между вариантами использования.

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

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

На рис. 2.4, в качестве примера, представлена диаграмма использования библиотечным фондом.

Рис.2.4. Диаграмма использования библиотечным фондом

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

Выводы

Основные цели создания диаграмм использования:

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

Формирование общих требований к поведению проектируемой системы.

Разработка концептуальной модели системы для ее последующей детализации.

Подготовка документации для взаимодействия с заказчиками и пользователями системы.