🗊Презентация Прецеденты. Вопросы, возникающие при определении исполнителей и задач. (Лекция 3)

Прецеденты Часть 2

Рамки В этом разделе определяются границы разрабатываемой системы. Обычно прецедент описывает использование одного программного (или программно-аппаратного) продукта. В этом случае прецедент называется системным (system use case). В более общем случае он описывает выполнение некоторой операции на уровне предприятия с использованием нескольких программных систем.

Уровень Обычно прецеденты разделяют на пользовательские и вспомогательные. Пользовательский прецедент (user-goal level use case) описывает сценарии достижения цели главного исполнителя. Вспомогательный прецедент (subfunction-evel user case) описывает вспомогательные действия, необходимые для достижения цели исполнителя.

Главный исполнитель Основной исполнитель, вызывающий системные службы для достижения цели.

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

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

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

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

Расширения Этот раздел очень важен. Здесь указываются все остальные сценарии или ветви, приводящие к успешному или неудачному завершению прецедента. Обратите внимание, что этот раздел больше и сложнее предыдущего. Так и должно быть. При описании прецедента основной успешный сценарий и его расширения должны охватывать почти все интересы заинтересованных лиц. Некоторые интересы лучше выразить в виде нефункциональных требований в дополнительной спецификации, а не в описании прецедента. Расширения — это ответвления от основного сценария.

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

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

Список технологий и типов данных Зачастую при реализации проекта важно не что сделать, а как. Перечень используемых технологий тоже приводится в описании прецедента. Типичным примером такой ситуации являются технические ограничения, выдвигаемые заинтересованными лицами для технологий ввода и вывода. Например, заказчик может потребовать, чтобы POS-система поддерживала ввод данных кредитной карточки с клавиатуры и с помощью считывающего устройства. Заметим, что здесь приводятся лишь примеры проектных решений и ограничений, появляющихся на ранней стадии реализации проекта. В целом, такой конкретизации следует избегать, однако иногда она бывает неизбежна, особенно в отношении технологий ввода-вывода.

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

Шаг 1. Определение рамок системы Для данного прецедента разрабатываемой системой является сама POS-система. Все, что находится за ее пределами, включая кассира, службу авторизации платежей и т.д., в эти рамки не включается. Для определения рамок системы следует, в первую очередь, указать, что к ней не относится, т.е. определить внешних основных и вспомогательных исполнителей. После идентификации внешних исполнителей рамки системы очерчиваются более четко. Например, возлагается ли на систему полная ответственность за авторизацию платежей? Нет, эту задачу выполняет внешний исполнитель — служба авторизации платежей.

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

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

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

Прецеденты и задачи Исполнители имеют свои задачи (или потребности), для решения которых они используют систему. Поэтому при описании прецедентов необходимо идентифицировать исполнителей и их задачи, которые должны быть решены в результате создания системы. При таком подходе несколько смещаются акценты аналитиков. Вместо вопроса “Каковы задачи системы?” возникает вопрос “Кто является исполнителем и каковы их задачи?”. Чтобы отобразить эту взаимосвязь, имя прецедента должно соответствовать названию задачи.

Кто является основным исполнителем: кассир или покупатель Почему основным исполнителем для прецедента Оформление продажи является кассир, а не покупатель? Ответ определяется рамками разрабатываемой системы, как показано на рисунке ниже. Если предприятие или торговую организацию рассматривать как агрегатную систему, то для нее основным исполнителем должен являться покупатель, задача которого - приобретение товаров или услуг. Однако с точки зрения самой POS-системы (которая определяет рамки системы для данного прецедента), основным исполнителем является кассир, задача которого — обслуживание продаж. Покупатель тоже является исполнителем, но в контексте POS-системы NextGen он не относится к основным исполнителям. Главным исполнителем является кассир, поскольку система предназначена для автоматизации его функциональных обязанностей. Интерфейс пользователя системы не предназначен для покупателя, а оптимизирован с учетом задач кассира. Покупатель не знает, как пользоваться этой системой. Другими словами, система разрабатывается для кассира, а не для покупателя.

Кто является основным исполнителем: кассир или покупатель

Шаг 4. Определение прецедентов Как правило, каждой задаче пользователя соответствует один прецедент. Его имя должно соответствовать названию задачи, например, задаче оформления продажи должен соответствовать прецедент Оформление продажи. Типичным исключением из правила соответствия задач и прецедентов является прецедент, решающий четыре задачи — создание, восстановление, обновление и удаление. Обычно такой прецедент называется Управление <чем-либо>. Например, задачи “изменение информации о пользователях”, “удаление пользователей” и т.д. решаются в рамках прецедента Управление пользователями.