Мастерская бизнес-анализа

Варианты использования вариантов использования

25.12.2009 at 16:12 2 комментария

Григорий Грин, декабрь 2009

Статья размещена на блоге автора.

Каждый проектировщик информационных систем рано или поздно сталкивается с вариантами использования (ВИ, англ. — use cases). Но в результате часто случается так, что эта полезная техника используется не по назначению и не приносит ожидаемой пользы. В чём же дело, и как писать варианты использования эффективно?

Алистэр Коуберн [1] еще пять лет назад всё сказал в своей статье «Варинаты использования, десять лет спустя» [2]. Я же здесь попытаюсь лишь добавить несколько практических аспектов из своего личного опыта. Я исхожу из того, что читатель знаком с ВИ (если нет – рекомендую книгу того же Алистэра Коуберна «Writing Effective Use Cases» [3]).

С помощью ВИ можно описать взаимодействие системы с окружающим миром и, таким образом, лучше понять систему. Т.е. ВИ можно рассматривать как один из способов описания требований к системе (система должна быть такой, чтобы поведение, видимое снаружи, было таким, как описано в ВИ). В предыдущем предложении ключевыми словами являются «один из». Существует огромное количество способов записать различные требования к системе, и ВИ – лишь один из них,  подходящий лишь для определённого типа требований в определённых условиях. Использованные удачно, ВИ компактно и понятно опишут систему. Использованные вне области применимости, ВИ отнимут время как у автора, так и у читателя и не привнесут большей ясности.

Пример: Описываем задачу поиска

Мой любимый пример – задача поиска (для определённости – пусть будет поиск на веб-сайте). Попробуем записать ВИ для поиска:

ВИ 1 (простой): Поиск

Пользователь предъявляет слово для поиска.
Система находит документы, содержащие данное слово, и выдает их пользователю в виде списка.

Всё ясно? В сущности мы описали повведение любой поисковой в системы. Достаточно нашего ВИ чтобы реализовать Google? Увы, нет. Означает это, что наш ВИ неправильный? Тоже нет. ВИ мы написали хороший. Краткий и понятный. Так всё и работает. Просто далеко не все аспекты поисковой системы можно описать с помощью ВИ. Некоторые начинают «улучшать» ВИ, добавляя в него всевозможные подробности:

ВИ 2 (подробный): Поиск

1.  Пользователь переходит на страницу поиска.

2.  Система предъявляет страницу поиска, содержащую как минимум поле для ввода слова для поиска и кнопку «Искать»

3.  Пользователь предъявляет слово для поиска.

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

5.  Пользователь выбирает документ.

6.  Система открываетвыбранный документ.

Альтернативы

4a. Искомое слово не найдено.

1. Система выдаёт сообщение об ошибке «Не найдено ни одного документа, соответствующего запросу».

Стало лучше? Нет! Данных для реализации всё равно недостаточно. Текста стало больше. Читать его надо дольше и внимательней, чтобы извлечь нужную информацию. Вместе с тем, ту же самую информацию можно было сообщить более эффективно. К примеру, так:

Рис. 1 Результаты поиска в Google.ru

Более точное описание различных требований потребует и разных форм, не имеющих ничего общего с ВИ.

Для описания синтаксиса языка запросов можно использовать формальную нотацию, к примеру форму Бэкуса-Наура [4].

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

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

Чтобы продемонстрировать элементы пользовательского интерфейса, включая переходы между состояниями, можно сделать прототип, например, с помощью HTML (так называемый click-dummy) или нарисовать просто пару картинок в Visio.

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

Что же касается ВИ, я бы вернулся к первой – простой – версии. Или же выбросил этот ВИ из-за его тривиальности.  Это важный принцип: чем писать тривиальные ВИ, лучше не пишите их вовсе. Каждое написанное предложение должно нести смысловую нагрузку, а не просто заполнять определённый шаблон.

Стоит взвесить, не будет ли обычное описание функции поиска «в прозе» более полезным, чем ВИ:

Функция: Поиск

Сайт предлагает пользователю возможность поиска. Слово для поиска задаётся в следующем формате (<ссылка на описание формата>). Поиск производится в названии и в тексте документа. Результаты (см. рис.1) выдаются упорядоченными по релевантности. В следующей версии системы планируется ввести также расширенный поиск.

Когда нужны варианты использования

Зачем вообще нужны ВИ, если есть столько других удобных способов записи требований? В ряде случаев они просто более удобны. В этом разделе приводится несколько таких примеров.

Незнакомая предметная область

Если ваши проекты постоянно вращаются в одной и той же предметной области и варьируются лишь по ряду параметров, ВИ, скорее всего, ничего полезного не принесут. Если же вы столкнулись с незнакомой предметной областью, то вы начинаете с классического обследования и пытаетесь понять, что же тут к чему. Это исследовательская работа, в результате которой вы постепенно открываете для себя новых действующих лиц, их цели и способы использования системы. Вот это как раз удобно записывать в виде ВИ. Ваш документ с ВИ будет постоянно расти, развиваться, уточняться и, что немаловажно, влиять на другие документы – такие как модель данных и прототип пользовательского интерфейса, которые создаются параллельно с ВИ.

Сложные взаимодействия

Если вы имеете дело с большим и сложным бизнесс-процессом, то вполне возможно, что его запись в виде ВИ упростит дело (или хотя бы позволит подступиться к сложному процессу, даст возможность разным людям говорить о нём в единых терминах).

С высоты птичьего полёта

Цели пользователей часто выстраиваются в иерархию. Вот пример из уже упомянутой статьи[2]:

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

Если функциональные требования описаны на уровне, позволяющем программистам реализовать систему, то цели верхнего уровня легко теряются. Так в примере ваш документ будет все время говорить о пользователе, вставляющем карточку в автомат, и пытающемся добыть денег. Чтобы не потерять леса за деревьями, часто имеет смысл записать синтетический ВИ более крупного масштаба. Он может проходить через несколько модулей и даже включать несколько пользователей – главное, чтобы он показывал, как все описанные требования объединятся, чтобы наконец принести пользователю нужный результат.

Допустим, мы имеем дело с системой закупок. Наш пользователь — Покупатель — сотрудник отдела снабжения. У него есть Начальник, который должен одобрить заказы своих подчиненных, прежде чем те будут выполнены.

ВИ: Заказ товара

1.  Покупатель выбирает нужный товар (см. «Каталог») и заказывает его (см. «Процесс заказа»).

2.  Система помещает заказ в очередь и уведомляет Начальника отдела снабжения.

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

4.  Система принимает заказ и высылает подтверждение Покупателю.

Наличие такого ВИ не позволит забыть, к примеру, зачем программисты трудятся над компонентой для workflow, и какие функции в ней нужны на самом деле для самого главного ВИ. Эти четыре строки текста очень ёмкие – они проходят через всю систему и могут обеспечить многих программистов работой на месяцы. У такого ВИ больше шансов быть прочитанным и понятным пользователем и/или заказчиком, чем у длинного и детального ВИ на 3 листа.

Советы по написанию ВИ

Краткость

Пишите ВИ по возможности кратко. Всё, что можно записать в другой форме – запишите в другой форме (прежде всего, не описывайте в ВИ пользовательский интерфейс – см. ниже). Не пишите тривиальные самоочевидные вещи. Если не получается – выбросите ВИ (или ограничтесь одним названием). Ни в коем случае не пишите текст просто для того, чтобы заполнить поле в шаблоне. Лучше выбросите ненужное поле. Длинные списки полей и постоянно повторяющиеся тексты дискредитируют ВИ и приводят к тому, что люди перестают читать ВИ.

Шаблоны ВИ

Не ищите шаблоны ВИ и не используйте их. Вот, к примеру, список полей, взятый из Википедии, описывающий один (!) ВИ [5]:

• Use case name
• Version
• Goal
• Summary
• Actors
• Stakeholders
• Preconditions
• Triggers
• Basic course of events
• Alternative paths
• Postconditions
• Business rules
• Notes
• Author and Date

Из всего этого на самом деле нужно:

• Use case name
• Basic course of events

По потребности можно добавлять Alternative paths, Pre- and Postconditions.

Сами ВИ желательно сгруппировать по главному действующему лицу, а далее – по его цели, если их несколько.

Безусловно, бывают большие системы, при моделировании которых нужны сотни ВИ. В этом случае нужны все эти поля, но в таких случаях не обойтись без специальных инструментов моделирования, в которых есть встроенная поддержка для ВИ (CASE).

Диаграммы вариантов использования

Диаграммы вариантов использования входят в стандарт UML [6] и имеют специальную нотацию. Если у вас 5-10 ВИ и 2-4 действующих лица, вы можете нарисовать такую диаграмму – она хорошо проиллюстрирует ваши основные ВИ и взаимодействие действующих лиц и ВИ. Если же ваши объёмы больше, такие диаграммы уже ничем не помогут. Лучше ориентироваться на обычные списки / таблицы (действующие лица, их цели и ВИ – их названия). Следующая ступень – специальный инструментарий (CASE).

Рис. 2 Диаграмма вариантов использования (источник: http://www.visual-paradigm.com/VPGallery/img/diagrams/UseCase/Use-Case-Diagram-Sample.png)

Активный залог

Пишите всё в активном залоге («Система отсылает письмо», «Пользователь выбирает товар», но не «Письмо отсылается», «Товар выбирается»). Если формулировка не получается, это верный знак, что вы что-то забыли смоделировать.

(НЕ)следование пользовательскому интерфейсу

ВИ – это не есть текстовая документация вашего интерфейса. (Хотя и такая трактовка ВИ имеет право на существование – [7], но это тогда другие ВИ, не те, о которых мы тут говорим.) Пользовательский интерфейс часто предлагает список объектов (к примеру, товаров), который пользователь может просматривать (фильтровать, искать), выбирать отдельный объект, смотреть его, редактировать, удалять или же добавлять новые объекты. Всё это стандартные понятные функции. Нет нужды выписывать ВИ «Добавить товар», «Изменить товар», «Удалить товар» и т.д. Где-то в модели данных у вас описано что такое товар. Нарисуйте макет списка и страницы товара (хотя бы просто в Excel) – и всё. Оставьте ВИ для более интересных вещей.

Выводы

Варинаты использования принесут вам пользу, если:

• Не пытаться записать все требования в виде ВИ или разложить всю систему на ВИ
• Писать ВИ кратко и ёмко. Избегать тривиальных ВИ
• Писать ВИ уровнем выше, чем описание других функциональных требований
• Использовать ВИ для анализа незнакомой предметной области и сложных процессов.
• Не смешивать ВИ и пользовательский интерфейс
• Предварительно прочитать хорошую книжку, а также посмотреть на примеры хороших и плохих ВИ, написанных ранее вашими коллегами.

Ссылки

1. Alistair Cockburn (Алистэр Коуберн),
2. Варианты использования, десять лет спустя.  — перевод  maxkir.com, .
3. Writing Effective Use Cases, Alistair Cockburn,
4. Русский перевод: «Современные методы описания функциональных требований к системам», 2002, изд. «Лори».
5. Форма Бэкуса-Науэра
6. Шаблон ВИ
7. UML – Unified Modeling Language,
8. Простой и понятный дизайн приложений с помощью вариантов использования (use cases) по Роберту Хукману.

Entry filed under: Методы и технологии анализа.