Диаграммы вариантов использования.
В процессе как объектно-ориентированного, так и традиционного структурного проектирования разработчики использовали типичные сценарии, помогающие им лучше понять требования к системе. Эти сценарии трактовались весьма неформально - они почти всегда использовались и крайне редко документировались. Ивар Якобсон впервые понятие ввел понятие варианта использования (use case) и придал ему такую значимость, что он превратился в основной элемент разработки и планирования проекта.
Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. Например, два типичных варианта использования обычного текстового процессора - «сделать некоторый текст полужирным» и «создать индекс». Даже на таком простом примере можно выделить ряд свойств варианта использования: он охватывает некоторую очевидную для пользователей функцию, может быть как небольшим, так и достаточно крупным и решает для пользователя некоторую дискретную задачу. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать.
Действующее лицо (actor)
Действующее лицо (actor) - это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. На диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, однако, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы. Показывать на диаграмме действующих лиц следует только в том случае, когда им действительно необходимы некоторые варианты использования.
Действующие лица делятся на три основных типа - пользователи системы, другие системы, взаимодействующие с данной, и время.
Первый тип действующих лиц - это физические личности, или пользователи системы. Они наиболее типичны и имеются практически в каждой системе. Например, к этому типу относятся клиенты и обслуживающий персонал. Называя действующих лиц, используйте их ролевые имена, а не те, что соответствуют их должности. Конкретный человек может играть множество ролей. Ролевые, а не должностные имена позволяют получить более стабильную картину действующих лиц. Должности могут меняться время от времени, при этом роли и ответственности могут перемещаться от одной должности к другой. Используя роли для названия действующих лиц, вам не придется обновлять модель каждый раз при появлении новой должности или при изменении распределения обязанностей между ними.
Вторым типом действующих лиц является другая система. Допустим, что у банка имеется кредитная система, используемая для работы с информацией о кредитных счетах клиентов. Система банка должна иметь возможность взаимодействовать с кредитной системой, в таком случае последняя становится действующим лицом.
Сделав систему действующим лицом, мы предполагаем, что она не будет изменяться вообще. Действующие лица находятся вне сферы действия того, что мы разрабатываем и, таким образом, не подлежат контролю с нашей стороны. Если мы собираемся изменять или разрабатывать также и кредитную систему, она попадает при этом в наш проект и, таким образом, не может быть показана как действующее лицо.
Третий наиболее распространенный тип действующего лица - это время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе. Система, например, может каждую полночь выполнять какие-либо служебные процедуры по настройке и согласованию своей работы. Так как время не подлежит нашему контролю, оно является действующим лицом.
Рис 1. Пример диаграммы вариантов использования (USE case diagram)
Когда Якобсон в 1994 г. предложил варианты использования в качестве основных элементов процесса разработки ПО, он также предложил использовать для их наглядного представления диаграммы вариантов использования. На Рис. 1 показан пример такой диаграммы для банковского автомата (Automated Teller Machine, ATM). На данной диаграмме человеческие фигурки обозначают действующих лиц, овалы - варианты использования, а линии и стрелки - различные связи между действующими лицами и вариантами использования.
На диаграмме показаны три действующих лица: клиент, банковский служащий и кредитная система. Описаны шесть основных действий, выполняемых системой: перевести деньги, сделать вклад, снять деньги со счета, показать баланс, изменить идентификационный номер и осуществить оплату.
На диаграмме вариантов использования показано взаимодействие между вариантами использования и действующими лицами. Она отражает требования к системе с точки зрения пользователя. Таким образом, варианты использования – это функции, выполняемые системой, а действующие лица – это заинтересованные лица (stakeholders) по отношению к создаваемой системе. Такие диаграммы показывают, какие действующие лица инициируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использования. Данная диаграмма, например, отражает взаимодействие между вариантами использования и действующими лицами системы ATM. В сущности, диаграмма вариантов использования может иллюстрировать требования к системе. В нашем примере, клиент банка инициирует большое количество различных вариантов использования: «Снять деньги со счета», «Перевести деньги», «Сделать вклад», «Показать баланс», «Изменить идентификационный номер». Некоторые из связей заслуживают более детального рассмотрения. Банковский служащий может также инициировать вариант использования «Изменить идентификационный номер». От варианта использования «Осуществить оплату» стрелка указывает на Кредитную систему. Действующими лицами могут быть внешние системы, и потому в данном случае Кредитная система показана именно как действующее лицо — она внешняя для системы ATM. Направленная от варианта использования к действующему лицу стрелка показывает, что вариант использования предоставляет некоторую информацию, используемую действующим лицом. В данном случае вариант использования «Осуществить оплату» предоставляет Кредитной системе информацию об оплате по кредитной карточке.
Все варианты использования связаны с внешними требованиями к функциональности системы. Если кредитной системе требуется файл, то это требование должно быть удовлетворено. Варианты использования всегда следует анализировать вместе с действующими лицами системы, определяя при этом реальные задачи пользователей и рассматривая альтернативные способы решения этих задач.
Действующие лица могут играть различные роли по отношению к варианту использования. Они могут пользоваться его результатами или могут сами непосредственно в нем участвовать. Значимость различных ролей действующего лица зависит от того, каким образом используются его связи.
Конкретная цель диаграмм вариантов использования - это документирование вариантов использования (всё, входящее в сферу применения системы), действующих лиц (все вне этой сферы) и связей между ними. Разрабатывая диаграммы вариантов использования, старайтесь придерживаться следующих правил:
не моделируйте связи между действующими лицами. По определению действующие лица находятся вне сферы действия системы. Это означает, что связи между ними также не относятся к ее компетенции.
не соединяйте стрелкой два варианта использования непосредственно (кроме случаев связей использования и расширения, описанных ниже). Диаграммы данного типа описывают только, какие варианты использования доступны системе, а не порядок их выполнения. Для отображения порядка выполнения вариантов использования применяют диаграммы деятельностей.
каждый вариант использования должен быть инициирован действующим лицом. Это означает, что всегда должна быть стрелка, начинающаяся на действующем лице и заканчивающаяся на варианте использования. Опять исключением являются рассматриваемые далее связи использования и расширения.
думайте о базе данных как о слое, находящемся под диаграммой. С помощью одного варианта использования можно вводить данные в базу, а получать их с помощью другого. Не надо для изображения потока информации рисовать стрелки от одного варианта использования к другому.
В начале проекта возникает естественный вопрос: как обнаружить варианты использования, Лучше всего для этого внимательно прочитать любую документацию заказчика. Часто помогает также рассмотрение области использования системы на высоком уровне и документов концептуального характера. Учтите также мнение каждого из заинтересованных лиц проекта. Спросите себя, чего они ожидают от готового продукта. Для каждого заинтересованного лица можно задать следующие вопросы:
Что он хочет делать с системой?
Нужно ли ему с ее помощью работать с информацией (вводить, получать, обновлять, удалять)?
Нужно ли ему будет информировать систему о каких-либо внешних событиях?
Должна ли система, в свою очередь, информировать его о каких-либо изменениях или событиях?
Хорошим источником для идентификации вариантов использования служат внешние события. Следует начать с перечисления всех событий, происходящие во внешнем мире, на которые система должна каким-то образом реагировать. Какое-либо конкретное событие может повлечь за собой реакцию системы, не требующую вмешательства пользователей, или, наоборот, вызвать чисто пользовательскую реакцию. Идентификация событий, на которые необходимо реагировать, помогает идентифицировать варианты использования.
Варианты использования - это не зависящее от реализации высокоуровневое представление о том, что пользователь ожидает от системы. Рассмотрим каждый фрагмент этого определения по отдельности.
Прежде всего, варианты использования не зависят от реализации. Представьте себе, что вы пишете руководство по работе с системой. Надо, чтобы ваши варианты использования можно было реализовать на языках Java, C++, Visual Basic или на бумаге. Варианты Использования заостряют внимание на том, что должна делать система, а не на том, как она должна будет делать это.
Далее, варианты использования - это высокоуровневое представление системы. Если, например, в модели содержится 3000 вариантов использования, вы потеряете преимущество простоты. Создаваемый набор вариантов использования должен дать пользователям возможность легко увидеть всю систему целиком на самом высоком уровне. Поэтому вариантов использования не должно быть слишком много, чтобы клиенту не пришлось долго блуждать по страницам документации, пытаясь понять, что будет делать система. В то же время, вариантов использования должно быть достаточно для того, чтобы полностью описать действия системы. Модель типичной системы обычно содержит от 20 до 50 вариантов использования. Для того, чтобы при необходимости разбить варианты использования на части, можно использовать связи различных типов, так называемые связи использования и расширения. Для лучшей организации системы можно также формировать группы вариантов использования, объединяя их в пакеты.
Наконец, варианты использования должны заострять внимание на том, что пользователи должны получить от системы. Каждый вариант использования должен представлять собой завершенную транзакцию между пользователем и системой, представляющую для первого некоторую ценность. Названия вариантов использования должны быть деловыми, а не техническими терминами, имеющими значение для заказчика. В рассматриваемом нами примере ATM нельзя назвать вариант использования "Интерфейс с банковской системой, осуществляющий перевод денег с кредитной карточки и наоборот". Вместо этого лучше назвать вариант использования "Оплатить по карточке" - так будет понятнее для заказчика. Варианты использования обычно называют глаголами или глагольными фразами, описывая при этом, что пользователь видит как конечный результат процесса. Его не интересует, сколько других систем задействованы в варианты использования, какие конкретные шаги надо предпринять и сколько строчек кода надо написать, чтобы заплатить по счету карточкой Visa. Для него важно только, чтобы оплата была сделана. Еще раз повторим, что нужно заострить внимание на результате, который потребитель ожидает от системы, а не на действиях, которые надо предпринять для достижения этого результата.
Но как убедиться, что обнаружены все варианты использования? Для этого следует задать себе вопросы подобные следующим:
Присутствует ли каждое функциональное требование хотя бы в одном варианте использования? Если требование не нашло отражение в варианте использования, оно не будет реализовано.
Учли ли вы, как с системой будет работать каждое заинтересованное лицо?
Какую информацию каждое заинтересованное лицо будет передавать системе?
Какую информацию каждое заинтересованное лицо будет получать от системы?
Учли ли вы проблемы, связанные с эксплуатацией?
Кто-то должен будет запускать готовую систему и выключать ее.
Учли ли вы все внешние системы, с которыми будет взаимодействовать данная?
Какой информацией каждая внешняя система будет обмениваться с данной?
Варианты использования начинают описывать, что должна будет делать система. Чтобы фактически разработать систему, однако, потребуются более конкретные детали. Эти детали описываются в документе, называемом "поток событий" (flow of events). Целью потока событий является документирование процесса обработки данных, реализуемого в рамках варианта использования. Этот документ подробно описывает, что будут делать пользователи системы, и что — сама система.
Хотя поток событий и описывается подробно, он также не должен зависеть от реализации. Цель – описать, что будет делать система, а не как она будет делать это. Обычно поток событий включает:
Краткое описание
Предусловия (pre-conditions)
Основной поток событий
Альтернативный поток событий
Постусловия (post-conditions)
Последовательно рассмотрим эти составные части.