Особенности диаграмм Use Case

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

В течение достаточно длительного периода времени в процессе как объектно-ориентированного, так и традиционного структурного про­ектирования разработчики использовали типичные сценарии, помога­ющие лучше понять требования к системе. Эти сценарии трактовались весьма неформально — они почти всегда использовались и крайне ред­ко документировались. Ивар Якобсон впервые ввел понятие "вариант использования" (Use Case) и придал ему такую значимость, что он пре­вратился в основной элемент разработки и планирования проекта.

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

Когда Якобсон в 1994 г. предложил варианты использования в качестве основных элементов процесса разработки ПО, он также предложил применять для их наглядного представления диаграммы вариантов использования

В состав диаграмм Use Case прежде всего входят:

• элементы Use Case ;

• актеры;

• отношения - зависимости, обобщения и ассоциации.

Как и другие диаграммы, диаграммы Use Case могут включать примечания и ограничения. Кроме того, диаграммы Use Case могут содержать пакеты, используемые для группировки элементов модели в круп­ные фрагменты.

Актеры и элементы Use Case

Вершинами в диаграмме Use Case являются актеры и элементы Use Case . Актеры представляют внешний мир, нуждающийся в работе системы. Элементы Use Case представляют действия, выполняемые системой в интересах актеров.

Актер — это роль объекта вне системы, который прямо взаимодействует с ее час­тью — конкретным элементом (элементом Use Case ). Различают актеров и пользо­вателей. Пользователь — это физический объект, который использует систему. Он может играть несколько ролей и поэтому может моделироваться несколькими ак­терами. Справедливо и обратное — актером могут быть разные пользователи. Например, для коммерческого летательного аппарата можно выделить двух акте­ров: пилота и кассира. Сидоров — пользователь, который иногда действует как пилот, а иногда — как кассир.

Элемент Use Case — это описание последовательности действий (или нескольких последовательностей), которые выполняются системой и производят для отдель­ного актера видимый результат.

Один актер может использовать несколько элементов Use Case и наоборот, один элемент Use Case может иметь несколько актеров, использующих его. Каждый эле­мент Use Case задает определенный путь использования системы. Набор всех эле­ментов Use Case определяет полные функциональные возможности системы.

Варианты использования являются необходимым средством на стадии формирования требований к ПО. Каждый вариант использования — это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию.

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

Различные разработчики подходят к описанию вариантов исполь­зования с разной степенью детализации. Например, Ивар Якобсон ут­верждает, что для проекта с трудоемкостью в 10 человеко-лет количе­ство вариантов использования может составлять около 20 (не считая связей «использование» и «расширение»). Следует предпочитать неболь­шие и детализированные варианты использования, поскольку они об­легчают составление и реализацию согласованного плана проекта.