Какая разница между alternative и exceptional Use Case flows?

Я относительно недавно зарегистрировался в сети LinkedIn (мой профайл) и стал посещать местные discussion boards. Вот на одной из таких discussion boards, я невольно стал свидетелем и участником какой-то странной дискуссии вот с таким вот вопросом: «What is the difference between a use case alternative flow and an exception flow?».

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

Собственно, почему я считаю дискуссию странной, потому что для меня как ответ на вопрос дискуссии, так и его объяснение, очевидны. Если эти вещи очевидны и для вас, то дальше можно не читать :)...

А затем, чтобы разобраться, надо просто вспомнить какие есть flows и дать определения всем видам этих самых flows внутри Use Case'а (UC). Ниже я привожу немного измененную собой вырезку из книги «Software Requirements, Second Edition» by Karl E. Wiegers:

  1. Basic Flow (aka normal course, main course, basic course, normal flow, primary scenario, main success scenario, and happy path). Basic Flow is the most normal from author's point of view sequence of steps that is required to successfully accomplish the task (UC).
  2. Alternative Flow (aka alternative courses, secondary scenarios). Alternative courses also result in successful UC completion and satisfy the use case's postconditions. However, they represent variations in the specifics of the task or in the dialog sequence used to accomplish the task.
  3. Exception Flow (aka exceptions). They are sometimes regarded as a type of alternative course, but it's useful to separate them. Exceptions actually prevent the UC from succeeding.

Итак, ответ таков:

Действительно, разница фундаментальна. Alternative flow — это всего лишь еще один способ достижения того же (т.е. положительного) результата, просто другим путём. Exception flow — это неестественное, ошибочное, неправильное поведение системы или пользователя, которое в итоге не приводит к достижению цели Use Case'а, но которое имеет право на существование. Между прочим эта разница отлично видна, если представить UC в графическом в виде, т.е. в виде диаграммы. Alternative flows будут ответвляться в разных местах, переплетаться, но в итоге будут приходить в ту же финальную точку, в которую приходит и Basic Flow. А вот Exception flows будут обрываться посреди диаграммы.

 Вот так будет примерно будет выглядеть UC «Звонок другу» с одним Basic Flow (идет поцентру), двумя Alternative Flows (идут по бокам и заканчиваются в точке «Друг вызван») и несколькими Exception Flows. По-хорошему, тут не видно, где идут действия Актера, а где ответы Системы. Я намеренно не рисовал эту диаграмму по всем правилам и канонам, чтобы не загромождать пример ненужными деталями. Цель - показать, что же является Alternative Flow, а что Exception Flow

Звонок другу

Звонок другу

 

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

  1. Exception Flow надо реализовывать всегда (в отличие от Alternative Flow), ибо это — корректное поведение системы в «нестандартном» случае. Чем раньше вы задокументируете и реализуете все такие возможные случаи, тем более устойчивой будет ваша система. Тем благодарнее вам будут QA, пользователи, разработчики, в общем все :).
  2. Если у вас есть
    • набор детализированных UC для еще нереализованной функциональности
    • для каждого UC Basic Flow и один или несколько Alternative Flows
    • ограничения по времени и/или бюджету
  3. то это значит, что у вас есть выбор :). А выбор заключается в том, что вы можете взять каждый UC, выбрать наименее трудоемкий Flow и «назначить» его Basic Flow для данного UC, а все остальные Flow для каждого UC перенести во «второй или последующие релизы»... по согласование с вашим менеджером или заказчиком, конечно :)

Ну вот, вроде, и разобрались.

А вот еще, что хотел добавить из личного опыта. В моей практике не было принято загромождать диаграмму одного UC всеми возможными Alternative flows, и потому обычно они выделялись в атомарные UC. Но вполне вероятно, что это — результат неправильного использования существующих инструментов или результат использования несовершенных инструментов :).

This entry was posted in анализ and tagged , , . Bookmark the permalink.

3 Responses to Какая разница между alternative и exceptional Use Case flows?

  1. bustor says:

    1. В приведенном примере все условия, которые соответствуют Exception Flow, можно разместить в предусловиях выполнения UC. Где та грань, которая заставляет одни условия описывать в предусловиях, а другие в Exception Flow?

    2. Часть из приведенных условий также можно рассматривать как Alternative flows, так как они могут привести к финальной точке.

    Пример. Условие: «Друга нет в записной книжке». След.шаг: «Добавить друга в записную книжку». След.шаг: «Открыть записную книгу» и т.д.

    Опять же — где та грань, с помощью которой можно определить — Alternative или Exception?

  2. Yuri Vedenin says:

    1. Пожалуй, соглашусь, что все условия можно разместить в предусловиях. Что касается вашего вопроса, думаю, что грань в том, что наступление Exception точки, т.е. точки где что-то идет не так, хоть и предсказуемо, но не может быть отнесено в разряд заранее известных условий. Т.е. если это результат какого-то события (перегорела лампочка) или значение параметра (напряжение более 220 вольт), то он становится известным только в процессе выполнения юз-кейса, но никак не до его начала.

    2. Не согласен, что их можно рассматривать как Alternative flows. Это, скорее, отдельные юз-кейсы. Это, конечно, можно рассматривать как шаги более высокоуровневого юз-кейса (т.н. бизнес юз-кейс), но вот вы даже посмотрите на предложенный вами шаг — «Добавить друга в записную книжку». Это ведь полноценный юз-кейс... согласны?

    Что касается грань между Alternative или Exception. Я повторю свою мысль из поста, но другими словами. Exception — это предсказуемый нежелательный результат. Alternative — это предсказумый желательный результат, иначе говоря, альтернативный способ достичь цели Use Case'а (той же, что и у Basic Flow).

  3. bustor says:

    п.1:

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

    Тут встает другой вопрос. Если все условия такого рода мы выносим в предусловия — где будут описаны «обработчики» этих условий? Видимо уже не в спецификации UC — это ведь не «взаимодействие Пользователя и Системы»? Или же они не нужны принципиально, потому что обрабатывать там нечего — это просто потенциальные ветки основного потока, которые при выполнении указанных в преусловии положений никогда не произойдут? Может быть, ответив на этот вопрос, мы поймем, что надо относить к предусловиям, а что — к Exception.

    п.2:

    >> «Добавить друга в записную книжку». Это ведь полноценный юз-кейс... согласны?

    Возможно. А может быть и нет. Все будет зависеть от того, какие действия надо выполнить для добавления записи друга. Шаг «Найти друга в списке и выбрать эту запись», например, в ряде случаев тоже можно рассматривать как отдельный UC. Опять же, все будет зависеть от конкретной ситуации. :)

    >> Я повторю свою мысль из поста, но другими словами. Exception – это предсказуемый нежелательный результат.

    «Список звонков пуст», «В списке звонков вызова с другом нет» и т.п. – это не «результат», это именно «условие».

    ----------

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

    Я пока для себя не сформулировал окончательного мнения по поводу:

    1. Чем в ваших примерах «Exception + его обработка» (своего рода петля, а-ля, друга нет в списке – добавить друга – продолжать работу дальше до достижения цели UC) отличается от Alternative.

    2. Чем в ваших примерах Exception отличается от предусловия.

    А может быть проблема именно в вашем примере? А сами то определения даны верно? Очень хотелось бы разобраться в этом и разложить все по полочкам у себя в голове. :)

    P.S. А можно как-то подписаться на получение комментариев к посту на указанный при комментировании e-mail?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>