Файл: Лаб. занятие № 4+.doc
ВУЗ: Пермская государственная сельскохозяйственная академия имени академика Д. Н. Прянишникова
Категория: Методичка
Дисциплина: Проектирование информационных систем
Добавлена: 18.10.2018
Просмотров: 1138
Скачиваний: 6
СОДЕРЖАНИЕ
ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ
Вопрос 2. Типы и форматы прецедентов
Прецеденты типа "черный ящик" и системные обязанности
Прецедент П 1. Оформление продажи
Основной успешный сценарий (или основной процесс)
Расширения (или альтернативные потоки)
Список технологий и типов данных
Частота использования: почти постоянно.
Открытые вопросы
-
Изучить законодательство по налогообложению.
-
Исследовать вопрос восстановления удаленных служб.
-
Какая настройка потребуется для различных типов магазинов.
-
Должен ли кассир снимать кассу при выходе из системы.
-
Может ли пользователь сам использовать устройство считывания данных с карточки или это должен делать кассир.
Этот прецедент скорее является иллюстративным, чем исчерпывающим (хотя и основывается на реальных требованиях к POS-системе). Тем не менее, он описан достаточно подробно и позволяет составить реалистичное представление о развернутом формате описания прецедентов и их сложности.
Этот пример может служить моделью для многих других прецедентов.
Пояснения к примеру
Вводные элементы
В описание прецедента можно добавлять различные вводные элементы. Те из них, которые важны для изложения последующего сценария, следует помещать в начало описания. Второстепенный материал можно располагать в конце сценария. Например, в описание можно добавить следующий вводный элемент:
Главный исполнитель. Основной исполнитель, вызывающий системные службы для достижения цели.
Заинтересованные лица и их потребности
Этот список играет важную роль. С его помощью можно понять, что должна делать система. Приведем цитату: "Система реализует соглашение между заинтересованными лицами. Поведение системы описывается с помощью прецедентов... Прецедент, как соглашение о поведении, включает все возможные аспекты поведения, связанные с удовлетворением запросов заинтересованных лиц".
Эта цитата дает ответ на вопрос, что нужно описывать в прецеденте. Там нужно описывать все, что служит удовлетворению запросов заинтересованных лиц. Кроме того, начиная описание прецедента с перечня заинтересованных лиц и их интересов, можно более точно определить функции системы.
Предусловия и постусловия
Предусловия (preconditions) – это перечень предпосылок, которые всегда должны выполняться до начала сценария прецедента. Предусловия не проверяются при реализации прецедента. То есть это условия, которые считаются истинными. Обычно в качестве предусловия выступает успешный результат выполнения другого сценария, например, загрузки или авторизации. В качестве предусловий перечисляются не все возможные истинные условия. Например, никто не упоминает в предусловиях наличие напряжения в электросети. Предусловия – это те предпосылки, на выполнение которых разработчик прецедента хочет обратить особое внимание.
Результаты или постусловия (postconditions) – описывают, какие условия обязательно должны выполняться в случае успешного завершения сценария. Эти результаты должны удовлетворять интересам всех заинтересованных лиц.
Основной успешный сценарий (или основной процесс)
В нем описывается типичная последовательность действий, приводящая к успешному завершению сценария и удовлетворяющая потребности всех заинтересованных лиц.
Чаще всего в этом разделе нет никаких условий или ветвей. И хотя вводить какие-либо условия не запрещается, их обычно выносят в раздел расширений.
В разделе основного сценария описываются три вида действий:
-
Взаимодействие между исполнителями.2
-
Верификация (обычно со стороны системы).
-
Изменение состояния системы (например, запись или модификация некоторых сущностей).
Первый шаг прецедента не всегда подпадает под эту классификацию. Он служит триггером события начала сценария.
Имена исполнителей принято начинать с заглавной буквы для облегчения их идентификации. Повторяющиеся действия выделяются курсивом.
Расширения (или альтернативные потоки)
В этом разделе указываются все остальные сценарии или ветви, приводящие к успешному или неудачному завершению прецедента.
При описании прецедента основной успешный сценарий и его расширения должны охватывать почти все интересы заинтересованных лиц. Некоторые интересы лучше выразить в виде нефункциональных требований в дополнительной спецификации, а не в описании прецедента. Расширения – это ответвления от основного сценария.
Специальные требования
В этот раздел заносятся нефункциональные требования, атрибуты качества или ограничения, связанные с данным прецедентом. Сюда относятся характеристики производительности, надежности, удобства использования и конструктивные ограничения (например, на устройства ввода-вывода).
Запись этих условий при описании прецедента – классический совет разработчиков унифицированного процесса. Однако на практике многие специалисты помещают эти требования в едином общем документе, например в дополнительной спецификации. Тогда их удобнее читать и осмысливать, поскольку обычно они рассматриваются в общем контексте в процессе анализа архитектуры.
Список технологий и типов данных
Зачастую при реализации проекта важно не что сделать, а как. Перечень используемых технологий тоже приводится в описании прецедента. Типичным примером такой ситуации являются технические ограничения, выдвигаемые заинтересованными лицами для технологий ввода и вывода.
Например, заказчик может потребовать, чтобы POS-система поддерживала ввод данных кредитной карточки с клавиатуры и с помощью считывающего устройства.
В этом разделе приводятся лишь примеры проектных решений и ограничений, появляющихся на ранней стадии реализации проекта. В целом, такой конкретизации следует избегать, однако иногда она бывает неизбежна, особенно в отношении технологий ввода/вывода. Нужно также указать возможные варианты типов данных, например, различные кодировки идентификаторов товаров.
Вопрос 3. Задачи и рамки прецедента
Как выделить прецедент?
Зачастую определить правильный (а точнее, полезный) прецедент очень сложно. Каждую задачу можно рассматривать на разных уровнях детализации, начиная от конкретных простых действий и заканчивая деятельностью на уровне предприятия.
На каком же уровне детализации следует формулировать прецеденты?
В процессе анализа требований к компьютерному приложению следует сосредоточить внимание на уровне элементарных бизнес-процессов (ЕВР – Elementary Business Processes).
Термин ЕВР заимствован из области исследования бизнес-процессов3 и определяется следующим образом.
"Элементарный бизнес-процесс – это задача, выполняемая одним человеком в одном месте в одно время в ответ на некоторое бизнес-событие, добавляющая измеряемое бизнес-значение и переводящая данные в некоторое устойчивое состояние, например, подтверждение платежа по кредитной карточке или распоряжение брокеру при изменении цен" (источник неизвестен).
Прецедент – это не один маленький шаг, такой, например, как удаление товара или печать документа. Основной сценарий прецедента обычно включает пять-десять шагов. Описываемый сценарий выполняется не в течение нескольких дней или сеансов, как, например, переговоры с поставщиками. Это задача, выполняемая в течение одного сеанса. Реализация прецедента может длиться от нескольких минут до нескольких дней. Как и при определении унифицированного процесса, основное внимание уделяется получению ощутимого (измеримого) результата и переходу системы и данных в устойчивое состояние.
Обоснованные отклонения от элементарного бизнес-процесса
Несмотря на то, что основные прецеденты приложения должны соответствовать элементарным бизнес-процессам, зачастую полезно создавать отдельные прецеденты более низкого уровня, представляющие подзадачи или подпоследовательности действий в рамках основного прецедента. То есть могут существовать прецеденты, не соответствующие элементарным бизнес-процессам, а функционирующие на более низком уровне. Общая рекомендация позволяет выявить только основные прецеденты в процессе анализа требований к приложению и сконцентрировать внимание на их написании.
Например, подзадача или расширение "Оплата по кредитной карточке" может быть представлена в нескольких основных прецедентах. Поэтому ее желательно выделить в отдельный прецедент (не удовлетворяющий условиям элементарного бизнес-процесса) и связать с несколькими основными прецедентами, чтобы избежать дублирования информации.
Прецеденты и задачи
Исполнители имеют свои задачи (или потребности), для решения которых они используют систему. Поэтому прецеденты уровня EBF еще называют прецедентами уровня задач пользователя (user goal). Это делается для того, чтобы обратить внимание на реализацию потребностей пользователей системы или основного исполнителя.
Отсюда следует алгоритм выделения прецедентов:
-
Выделить задачи (цели) пользователей.
-
Определить для каждой из них отдельный прецедент.
При таком подходе несколько смещаются акценты аналитиков. Вместо вопроса "Каковы прецеденты для данной системы?" возникает вопрос: "Каковы задачи исполнителей?". Чтобы отобразить эту взаимосвязь, имя прецедента должно соответствовать названию задачи. Например, задаче электронного оформления продажи должен соответствовать прецедент Оформление продажи.
Такая симметрия позволяет оценить адекватность уровня выделения прецедентов и задач пользователя в соответствии с правилом выделения элементарных бизнес-процессов.
Таким образом, ключевая идея состоит в том, чтобы для выделения прецедентов исследовать задачи исполнителей.
Пример: использование рекомендаций в соответствии с EBF
Допустим, вы являетесь системным аналитиком и отвечаете за формулировку требований к системе ТТ. Для этого вам нужно исследовать задачи пользователей. На семинаре по формулировке требований может состояться такой диалог.
Системный аналитик: "Каковы ваши задачи в контексте использования POS-системы?"
Кассир: "Во-первых, быстро зарегистрироваться. Во-вторых, оформлять продажи".
Системный аналитик: "Какая задача более высокого уровня приводит, на ваш взгляд, к необходимости выделения отдельной задачи регистрации?"
Кассир: "Мне необходимо "представиться" системе, а она должна проверить, имею ли я право ею пользоваться".
Системный аналитик: "Какова еще более глобальная задача?"
Кассир: "Предотвратить утечку или повреждение данных".
Обратите внимание на стратегию аналитика выстроить иерархию целей и выявить таким образом нужный уровень для элементарного бизнес-процесса. Это позволяет лучше понять мотивацию действий исполнителей и их задачи.
Предотвращение утечки данных – это цель более высокого уровня, чем задача пользователя. Поэтому пока мы ее рассматривать не будем, хотя она является чрезвычайно важной для данной системы. (Самым кардинальным решением этой задачи является полный отказ от POS-системы и услуг кассира.)
Цель следующего уровня иерархии ("представиться" системе и выполнить аутентификацию) несколько ближе к задачам пользователя. Но относится ли она к уровню элементарных бизнес-процессов? Ее решение не добавляет ощутимого результата или измеримого бизнес-значения. Если на вопрос о том, чем кассир занимался сегодня на работе, прозвучит ответ: "Я 20 раз зарегистрировался!", то вряд ли такой ответ устроит начальника. Значит, это второстепенная задача, которая служит достижению важной цели, но не относится к уровню ЕВР. Уровню ЕВР точнее всего соответствует задача оформления продажи.
В качестве другого примера можно рассмотреть процесс регистрации выручки, когда кассир задвигает ящик с наличностью и закрывает его в системе, регистрируется и вводит в систему сумму выручки. Регистрация выручки – это прецедент уровня ЕВР (или уровня задач пользователя), а регистрация в системе – это один из его шагов, выполняющий вспомогательную задачу, а не отдельный прецедент.
Вспомогательные задачи и прецеденты
Несмотря на то, что задача "представиться" системе и выполнить аутентификацию (или задача регистрации) не была отнесена к уровню задач пользователя, она все же является целью, но на более низком уровне.
Такие задачи называют вспомогательными (subfunctional goal), поскольку они призваны обеспечивать выполнение задач пользователя. Для вспомогательных задач отдельные прецеденты создаются очень редко, хотя специалисты по написанию прецедентов зачастую рекомендуют улучшать (обычно упрощать) набор прецедентов.
Для вспомогательных задач писать прецеденты не запрещается, однако это не всегда нужно, поскольку при этом усложняется модель прецедентов. Количество вспомогательных задач для системы может исчисляться сотнями, но стоит ли создавать так много прецедентов?
Важно понимать, что с увеличением числа прецедентов возрастает сложность задачи формулировки и управления требованиями, а значит, увеличивается также время решения этой задачи.
Основным мотивом написания прецедента для вспомогательной задачи должна служить повторяемость этой задачи или ее важное значение как предусловия для множества других прецедентов. Этому принципу удовлетворяет задача авторизации, которая обеспечивает предусловие для большинства, если не всех остальных прецедентов уровня задач пользователя.
Таким образом, вполне логично создать прецедент Аутентификация пользователя.
Составные задачи и прецеденты
Задачи могут принадлежать к различным уровням сложности и являться составными, начиная от уровня предприятия ("быть прибыльным"), до задач среднего уровня ("регистрация торговых операций") и вспомогательных задач в рамках приложения ("проверка правильности ввода").
Аналогично, и прецеденты могут относиться к различным уровням сложности и состоять из прецедентов более низкого уровня.
Наличие нескольких уровней сложности задач и прецедентов может ввести в заблуждение при определении соответствующего уровня для основных прецедентов. Для отсеивания слишком детальной информации следует использовать принцип нахождения элементарных бизнес-процессов.
Задание на самостоятельную работу (для выбранной темы индивидуального проекта):
-
Описать все прецеденты в сжатом формате.
-
Выбрать один прецедент (на примере которого будет выполнено объектно-ориентированное проектирование) и составить для него развернутое описание.
1 Термин "прецедент" (use case) появился в Швеции и в переводе означал "случай использования" (usage case).
2 Заметим, что описываемая система сама является исполнителем, если рассматривается аспект ее взаимодействия с другими системами.
3 Термин EBF аналогичен термину пользовательская задача (user task), применяемому в области изучения удобства использования. Однако в той предметной области его значение является менее жестким.