Еще раз об описании прецедентов

Те, кто читал предыдущие статьи, мой подход знают: "Модель первична, документ вторичен!". В этой статье я постараюсь подробно обосновать этот подход. Начну с цитирования "отцов-основателей".

"Три друга": Как описывать прецедент?[1]

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

…

Элементы Use Case можно описать и неформально – при помощи сценариев или простого текста, однако такие описания недостаточно точны и не годятся для интерпретации инструментами моделирования".

RUP: Как описывать прецедент?[2]

RUP предоставляет следующие материалы, связанные с описанием прецедентов:

• Описание артефакта "прецедент"
• Шаги задачи описания артефакта
• Рекомендации по использованию диаграммы деятельности для моделирования поведения артефакта
• Шаблон спецификации прецедента[3]
• Контрольный лист для оценки качества артефакта

Что мы описываем?

Практически все элементы UML характеризуются дихотомиями типа класс/объект, статическая структура/динамическое поведение и т.д.

Прецедент (модельный элемент Use Case) характеризуется, в частности, дихотомией внешнее поведение/реализация[4].

Говоря о прецедентах, системные аналитики имеют в виду только внешнее поведение. Такой подход имеет, как минимум, две причины:

• Только о внешнем поведении говорится в классическом определении прецедента
• Роль системного аналитика состоит в определении требований к системе, т.е. тоже к внешнему ее поведению.

И именно описанию внешнего поведения прецедентов посвящена эта статья[5]

Предпосылки

В этой статье (и во всем цикле) мы предполагаем, что системный аналитик – это единственная роль, которая определяет требования к системе. Требования сформулированы так, что:

• Проектировщикам и разработчикам не требуется никакой дополнительной информации, кроме той, которую представляет им системный аналитик
• Требования не ограничивают проектировщиков и разработчиков в выборе способов реализации этих требований

Сравнение способов моделирования

Даже, если Вы выбрали текстовое описание поведения, вряд ли этой информации будет достаточно для выполнения первого условия предыдущего раздела: достаточность информации. Текстовое описание можно рассматривать как дополнение к модели.

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

• Диаграмма состояний

Поведение прецедента естественнее всего формулировать в терминах действий, выполняемых системой в ответ на действия субъекта (Actor)[6]. А диаграмма состояний акцентируется на возможных состояниях классификатора (прецедента), и на переходах его из состояния в состояние в ответ на события. Эти события генерируются, в частности, действиями, доступными в состоянии.

На мой взгляд, диаграмма состояний неудобна для моделирования внешнего поведения прецедента.

• Диаграмма деятельности

Диаграмма деятельности – это граф действий. Она предназначена специально для моделирования рабочих потоков. Она легко понимается даже незнакомым с UML читателем.

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

Не хочется вдаваться в полемику, но задам вопрос: "Насколько структурированное текстовое описание ближе к объектно-ориентированному подходу, чем диаграмма деятельности?".

Что касается отображения элементов деятельности в элементы системы, то, наверное, этому можно посвятить отдельную статью. Пишите, если Вам это интересно!

• Диаграмма последовательности

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

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

Тем не менее, некоторые считают эту диаграмму более достойной (более правильной, т.к. она уж точно объектно-ориентированная!). Но прецедент описывает взаимодействие всего двух объектов: внешнего субъекта и системы. Некоторые не знают, но субъект (actor) в UML не может иметь операций, а значит, не может принимать сообщения (кроме возвратных)[8]. А это существенно ограничивает возможность моделирования взаимодействий.

·        Диаграмма коммуникаций

Эта разновидность диаграммы взаимодействия не имеет средств отображения логики рабочего потока.

Диаграмма деятельности – это выбор RUP. Диаграмма деятельности – это и мой выбор.

Мой опыт моделирования прецедентов

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

Строительные блоки для модели прецедентов (веб-публикация модели) представлены в приложении к первой статье.

Пример указаний по моделированию прецедентов – в приложении к предыдущей статье.[9]

Мы продолжим рассматривать пример модели прецедентов для проекта "Система управления оказанием услуг".

Один прецедент ("Прием заявки") мы рассмотрим более подробно. Вот как выглядит структура описания прецедента в Project Explorer рабочего окна RSA:

А вот как выглядит контекстная диаграмма для этого прецедента:

Обратите внимание: кроме привычных модельных элементов на диаграмму прецедентов помещен элемент URL. Это ссылка. Двойное нажатие откроет MS Word со спецификацией прецедента[10].

Хорошей практикой моделирование является краткое описание модельных элементов UML. Прецедент "Прием заявки имеет следующее описание:

С началом регистрации заявка устанавливается в состояние "Инициирована".

Автоматически отображаются:

- дата и время регистрации

- идентификатор регистратора

- текущее состояние заявки

При регистрации фиксируются:

- название и контактные данные клиента

- тип услуги

- название и характеристики объекта услуги

- скан-копии представленных документов

- текстовый комментарий

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

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

При успешном завершении регистрации Заявка переходит в состояние "Зарегистрирована".

Если регистратор имеет права руководителя работ, Заявка может быть сохранена в состоянии "Принята".

На следующей диаграмме представлено графическое описание рабочего потока прецедента:

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

Для всех модельных элементов диаграммы (кроме узлов управления) я печатаю описания.

• В описании начального узла я печатаю все предусловия для деятельности прецедента[11]
• В описаниях конечных узлов я печатаю описания постусловий, например (для узла "Прекращен"):

Завершение прецедента баз сохранения информации.

Отображается главное окно системы.

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

Если за узлом действия следует узел решения, я описываю возможные альтернативы в узле действия. Например (действие "Выбор продолжения"):

Регистратор использует средства управления для выбора способа продолжения:

- создание новой заявки клиента

- продолжение регистрации существующей заявки клиента в состоянии "Инициирована".

- завершение прецедента без сохранения промежуточных результатов.

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

В ином случае, делаю обычное краткое описание. Например (действие "Заполнение формы")[12]:

Вызываемое поведение.

Регистратор заполняет области и поля формы.

Заполнение формы может выполняться в нескольких сеансах. Области формы можно заполнять в произвольном порядке.

В процессе заполнения регистратор может:

- зарегистрировать отмену заявки клиентом (заявке присваивается состояние "Отклонена")

- отказать клиенту в выполнении заявки (заявке присваивается состояние "Отклонена")

- временно отложить регистрацию (состояние заявки не изменяется)

- завершить регистрацию и принять заявку клиента к исполнению (заявке присваивается состояние "Зарегистрирована")

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

При выполнении перечисленных действий информация заявки сохраняется и прецедент завершается.

Относительно узлов вызываемого поведения нужно поговорить чуть подробнее.

Вызываемое поведение в диаграммах деятельности используется в следующих целях:

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

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

Многие аналитики забывают, что прецеденты используются не только для описания требований, но и для планирования итерационного инкрементного процесса разработки проекта:

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

Рассмотрите узел "Выбор заявки". В примечании к этому узлу явно указаны условия фильтрации подмножества доступных заявок.
Соответствующий прецедент включения используется в рабочих потоках всех прецедентов, использующих сущность "Заявка".

Двойное нажатие на элемент (в RSA, и, думаю, в большинстве других инструментов моделирования) откроет следующую диаграмму:

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

Эта деятельность имеет параметры.

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

Заключение

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

Некоторые считают, что заказчики не знакомы с UML и не поймут картинки с "телепузиками". Категорически не согласен! Когда нужно объяснить что-то сложное, многие рисуют схемы, графики и т.д., и прекрасно понимают друг друга.

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

И тут мне в голову закралась крамольная мысль: "А может быть некоторые аналитики не хотят моделировать потому, что не умеют?".

Так давайте учиться!