Еще раз о прецедентах

Как я уже писал в предисловии к первому выпуску, я не составлял заранее плана статей. Темы для статей я нахожу на форуме UML2, где люди, работающие аналитиками, обсуждают свои профессиональные проблемы. Иногда я высказываю свое мнение непосредственно на форуме. Но, когда обсуждаются сложные явления, "форумный стиль" не позволяет выразить мнение достаточно аргументировано и полно.

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

• Как правильно рисовать диаграмму прецедентов для проекта
• Как правильно описывать прецедент

Мое мнение по этим вопросам я постараюсь изложить в двух последовательных выпусках:

• Эта (первая) часть статьи о прецедентах будет посвящена модели прецедентов в целом: структура модели, какие диаграммы я рисую и какие отчеты генерирую
• Вторая часть (она почти написана) посвящена способу описания прецедента

Откуда берутся прецеденты?

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

RUP предлагает несколько источников для идентификации прецедентов: интервью с заинтересованными лицами, мозговой штурм потенциальных пользователей (семинар по прецедентам), описание бизнес-процесса и т.д. Лучше всего эти источники и технологии использовать комплексно исходя из обстановки.

Я не буду описывать эти приемы. Давайте лучше рассмотрим пример.

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

Каждое требование возможности из документа "Видение" должно детализироваться, по крайней мере, одним прецедентом[1].

Модель бизнес-процесса дает существенно больше информации для идентификации прецедентов.

Ниже представлена диаграмма деятельности бизнес-процесса "Оказание услуги".[2]

(нажать для увеличения)

Я использую модель бизнес-процесса следующим образом[3]:

• Каждый бизнес-субъект и каждый бизнес-работник рассматривается как кандидат в системные субъекты. Если этот участник процесса будет пользователем разрабатываемой системы, он из кандидата становится системным субъектом
• Каждое действие диаграммы деятельности, которое будет автоматизировано в разрабатываемой системе, рассматривается как кандидат в системные прецеденты
• Класс, представляющий раздел на диаграмме деятельности, идентифицируется как первичный субъект[4] для всех прецедентов, образованных из действий, принадлежащих этому разделу.

Рассмотрите следующую диаграмму прецедентов[5]. На ней представлены прецеденты, поддерживающие бизнес-процесс "Оказание услуги":

(нажать для увеличения)

Каждому автоматизируемому действию из бизнес-модели соответствует системный прецедент, имеющий то же название, что и действие. Исключение составляет действие исполнителя "Выполнение работы". Почему?

Формально, бизнес-моделирование и моделирование прецедентов выполняют разные роли, а значит – могут выполнять разные люди.

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

Исполнитель выполняет работы по наряду.

Исполнитель фиксирует в своей копии наряда фактически выполненный объем работ (название, количество, затраты).

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

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

По завершении работ по наряду исполнитель передает продукты работы (пакет документов) и свою копию наряда руководителю для проверки.

Если по заявке выполняются субподрядные работы, исполнитель контролирует количество и качество выполненных работ. (Работа по контролю субподрядных работ должна быть включена в наряд исполнителя.)

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

Системный аналитик идентифицировал два прецедента с описаниями:

·        Прецедент "Заполнение основного наряда"

Редактирование информации основного наряда в соответствии с выполненным объемом работ:

- исключение из списка работ тех работ, которые исполнитель не выполнял или не будет выполнять

- указание фактически выполненного объема работ и фактических затрат

При первом открытии исполнителем наряд переходит в состояние "В работе".

Прецедент может выполняться частями в нескольких последовательных сеансах по мере продвижения работ.

По завершении работ наряд передается на проверку. Наряд переходит в состояние "На проверке".

·        Прецедент "Заполнение дополнительного наряда"

Создание и заполнение наряда на работы, не указанные в основном наряде, необходимость которых была выяснена в процессе выполнения основного наряда.

После создания дополнительный наряд переходит в состояние "В работе".

По завершении работ наряд передается на проверку. Наряд переходит в состояние "На проверке".

Если обратиться к приведенным выше рекомендациям, налицо их нарушение: модель прецедентов не соответствует бизнес-модели. Как поступить?

К счастью, рекомендации – это не правила. Системный аналитик должен обсудить свое решение с бизнес-аналитиком. Ведь ситуация может быть намного сложнее, и системный аналитик может оказаться не прав в своем нарушении требования бизнес-модели! С другой стороны, не прав может оказаться бизнес-аналитик. Может быть, ему следует детализировать бизнес-модель. В данном случае, наверное, это не требуется. Действие бизнес-процесса имеет понятное описание, из которого следует наличие двух независимых целей пользователя.

Еще одно, важное, на мой взгляд, замечание.

Некоторые аналитики стремятся отобразить на одной диаграмме все известные им прецеденты системы, со всеми включениями и расширениями. И сразу!

Диаграммы становятся нечитабельными.

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

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

Иногда (редко) я создаю в корне модели прецедентов диаграмму "Главные прецеденты". Диаграмма имеет чисто демонстрационные цели.

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

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

Я не помещаю эти прецеденты на диаграмму прецедентов функциональной области, чтобы не перегружать ее. Зато для каждого прецедента я создаю диаграмму "Контекст прецедента <Название>".

Но об этом в следующей статье.

Не забудьте скачать приложения!