Скачиваний:
69
Добавлен:
14.04.2015
Размер:
28.87 Кб
Скачать

Use Case

Что такое Вариант Использования (прецедент или Use Case)?

Вариант Использования (ВИ, прецедент или Use Case) - это последовательность некоторых событий, показывающих как Система должна взаимодействовать с Пользователями (называющимися актером или actor) для достижения какой-то цели. Различают два вида ВИ – это бизнес ВИ (БВИ) и системный ВИ (СВИ). 

Чем отличаются диаграммы Бизнес ВИ и Системных ВИ?

На Бизнес Диаграмме ВИ (БДВИ) отображается, как взаимодействуют внешние пользователи с вашей организацией для достижения бизнес целей. На ней обычно показывают внешних по отношению к вашей организации актеров, например, клиентов и  внешние организации. Старайтесь на этом этапе избегать связей <include> и <extend>. Данная диаграмма используется на этапе Бизнес Моделирования. Очень важно на этом этапе показать диаграмму Бизнес Объектов, которая отображает основные бизнес-сущности (и их свойства) и взаимосвязи между ними.

На Системной Диаграмме ВИ (СВИ) отображается, как взаимодействуют ваши внутренние Пользователи с вашей автоматизированной Системой, т.е. отображаются пользовательские функциональные требования к ПО. Данная диаграмма используется на этапе Системного Анализа и формализации требований к ПО.

Что такое актер (actor)?

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

Что необходимо сделать, чтобы правильно построить ДВИ?

Общая схема: 1.   Выделить действующих лиц (ДЛ). Если это СДВИ, то нужно выделить внутренних Пользователей Системы и внешнее (другое) ПО. Если это БДВИ, то нужно понять – кто может являться Клиентом вашей организации, и с какими другими организациями взаимодействует ваша компания, например, налоговая или РАО ЕЭС. 2.   Для каждого выделенного ДЛ написать свои цели, которые он пытается достичь, используя ваше ПО (СДВИ) или вашу организацию (БДВИ). Ранжировать эти цели для каждого ДЛ и попытаться выделить основные цели, если другие цели являются подцелями или задачами. Понять какие другие ДЛ могут участвовать при достижении этой цели. Попробовать объединить цели нескольких ДЛ, если они несут некую одну пользу. 3.   Нанести на диаграмму ДЛ, которые будут являться актерами, и основные цели, которые будут являться ВИ. Причем основным словом в названии ВИ должно являться глагол, например, «Принять товар». Нанести на диаграмму связи (в виде однонаправленных ассоциаций) между ДЛ и целями, в соответствии с п. 2. Если другое ДЛ участвует в достижении цели основного ДЛ, то этот ВИ надо также связать с первым ДЛ. 4.   Для каждого ВИ необходимо написать сценарий – последовательность действий внутри этого ВИ. БВИ лучше описывать в виде прозрачного ящика, а СВИ лучше описывать в виде черного ящика.

Коберн в книге "Writing Effective Use Cases" предлагает следующее: 1    Обозначить масштаб/уровень Системы 2    Мозговой штурм и выявление списока основных ДЛ Найти всех людей и внешние системы в течение всей жизни Системы. 3    Мозговой штурм и выявление полного списка целей Пользователей Системы 4    Выделить один ВИ для расширения Надо начать писать повествование, чтобы узнать Систему 5    Напишите основный успешный сценарий (ОУС) 6    Мозговой штурм и выявление полного списка расширяемых условий Включить все, что Система может обнаружить и должна обрабатывать 7    Написать все шаги для обработки расширений Каждый из них должен заканчиваться в ОУС, в отдельном успешном или неуспешное окончании. 8    Выделить сложные потоки в подВИ (sub UC), обеденить одинаковые подВИ Выделить подВИ – это легко, но это добавит больше ценности проекту 9    Заново переопределите ВИ и сценарии: добавьте, урежьте, или слейте что-то, если надо

Что такое сценарий ВИ?

Сценарий или спецификация ВИ (use case scenario or specification) – текстовое формальное описание последовательности действий, которые происходят внутри ВИ для достижения некой цели актера.

Принята следующая структура описания спецификации ВИ:

1.   Название Это уникальное название ВИ. Оно должно быть написано в виде глагол-существительное, например «Получить книги», «Снять наличные».Лучше написать «Регистрировать пользователя», чем «Регистрация пользователя».  Оно должно описывать конечную цель актера и чтобы было понятно – о чем данный ВИ. Оптимально название из 2 или 3 слов.

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

3.   Описание Обеспечивает краткое описание ВИ, чтобы понять суть ВИ и не углубляться в полное описание. Часто используется на первых стадиях, когда полный процесс еще не ясен, но хочется описать основные моменты. Может быть пропущено.

4.   Предусловия Данная секция используется для описания любых условий, которые необходимо соблюсти, когда пользователь начинает выполнение данного ВИ. Данные условия могут непосредственно не инициировать данный ВИ.

5.   Триггер Описывает начальное условие, при котором начинается данный ВИ. Это может быть внешним, временным или внутренним условием.

6.   Основной поток действий Каждый ВИ должен иметь по крайней мере одну секцию, описывающую основной поток действий. Обычно представлен как нумерованный список шагов:

  1. Система показывает форму вводу имени пользователя и пароля

  2. Пользователь вводит свое имя и пароль

  3. Система проверят введенные данные и подтверждает их правильность

  4. Пользователь считается авторизованным

  5. И т.д.

7.   Альтернативные потоки действий ВИ может иметь разветвления потока событий или иметь другие (альтернативные) сценарии. Все вариации описываются в данной секции. Обычно также представлен как нумерованный список шагов:

  1. Система распознала cookies на компьютере пользователя

  2. Перейти к п. 3 основного потока

Или:

  1. Система проверят введенные данные, и они являются не верными

  2. Перейти к п. 1 основного потока

8.   Постусловия Здесь указываются состояние, которые происходят после того как основной сценарий исполнился.

9.   Бизнес правила Это правила, которые определяют как организация взаимодействует внутри в соответствии с ВИ. Бизнес правила могут быть как внутри ВИ, так и затрагивать несколько ВИ, чтобы описать взаимодействия, которые выходят за рамки описания ВИ. Нужно чтобы получить более полную картину взаимодействия. Может быть пропущено.

10.   Замечания Другая информация, которая не может быть описана в рамках шаблона. Может быть пропущено. 11.   Автор и дата Должна быть показана версия документа,  его автор и дата последнего обновления.

 

Пример сценария ВИ:

1.Название ВИ01 "Добавить нового автора"

2. Главный успешный сценарий. 2.1.   Пользователь инициирует ввод нового автора. 2.2.   Система формирует диалоговое окно для ввода (коммент. – нужно отдавать отчет что это может быть ОГРАНИЧЕНИМ для разработчика … а вдруг лучше все прямо в гриде вводить) 2.3.   Пользователь вводит Информацию об авторе и подтверждает ввод (коммент. -- мы не знаем, может лучше чтобы кнопка называласть «Сохранить», а не «ОК»?). 2.4.   Система подтверждает отсутствие аналогичной записи об авторе в списке ранее сохраненных авторов и отображает введенную Пользователем информацию. 2.5.   Пользователь подтверждает правильность ввода <нажав что-то …> 2.6.   Система присваивает новому автору уникальный идентификатор и сохраняет его в списке. 3. Расширения. 2.4а. Такой автор имеется в списке. 2.4а1. Система информирует Пользователя …. 2.4а2. ….. 2.5а. Пользователь принимает решение внести изменения ... 2.5а1. …. 2.6а. В процессе сохранения произошел сбой 2.6а1. .... 4. Дополнительная информация. Информация об авторе = ФИО + Псевдоним + Дата рождения + …

(с) Пример написан Юрием Булуем.

Какие есть основные особенности ВИ?

ВИ – это цель ВИ должен иметь хотя бы одного актера ВИ – это описание (сценарий) ВИ имеет один успешный сценарий (С) ВИ имеет множество альтернативных С С ВИ должен иметь не более 10 шагов Сложный С делится на подВИ (sub use cases) ДВИ должна содержать 5-10 ВИ

Почему ВИ – это не функция?

ВИ – это не функция, это некая последовательность действий, которая приносит пользу для основного актера, инициирующего данный ВИ. ВИ – это скорее цель Пользователя, чем отдельная функция. ВИ теоретически может быть разбит на несколько функций, и как правило не является одной лишь функцией. Например, «Выдать деньги» в банкомате не является ВИ, а «Снять деньги» - это ВИ, который включает в себя некую последовательность действий по выдаче денег. Декомпозировать ВИ до функции является очень большой ошибкой.

Какие встречаются основные ошибки при работе с ВИ?

1. Отсутствие системы или действующего лица

Это одна из самых распространенных ошибок. Возможная причина невнимательность и избыточная торопливость. Однако я обнаружил и другие более глубинные причины. Даже после четкого объяснения, что вариант использования показывает возможное взаимодействие, по крайней мере, между ДВУМИ действующими лицами, где одно из них – это система по умолчанию, все равно ошибки, связанные с  отсутствием системы превалируют. Проанализировав ситуацию, я пришел к выводу, что студенты имеют либо малый навык программирования именно интерактивных систем, а отсюда подход к система как в вычислительному ресурсу, который может работать без вмешательства из вне, либо они никак не могу ассоциировать систему с объектом, имеющим поведение, т.е. реагирующего на внешние «раздражители».

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

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

2. Смешивание уровней детализации

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

3. Функциональная декомпозиция

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

4. Стремление описывать сценарии в интерфейсном стиле

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

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

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

6. Нечеткое понимание различия между «черным» и «прозрачным» ящиками

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

7. Наделение поведением бизнес-сущностей

Часто возникает у студентов при описании сценария в виде диаграммы деятельности в качестве действующего лица описывать некоторую бизнес-сущность. Например: клиент запрашивает баланс счета в задаче про банкомат, счет предоставляет ему информацию о балансе. Ошибка, надо сказать, тонкая. Особенно, когда мы говорим об операциях счета, рассматривая его как объект системы, обладающий поведением. Думаю ,здесь присутствует ошибка реализации.