Метод инженерии требований А. Джекобсона
Данный метод является методом с последовательным выявлением объектов, существенных для домена проблемной области [3]. Все методы анализа предметной области в качестве первого шага выполняют выявление объектов. Правильный выбор объектов обуславливает понятность и точность требований. Рассматриваемый метод Джекобсона дает рекомендации относительно того, с чего начинать путь к пониманию проблемы и поиску существенных для нее объектов.
Автор назвал свой метод как базирующийся на вариантах (примерах или сценариях –use case driven) системы, которую требуется построить. В дальнейшем термин сценарий используется для обозначения варианта представления системы.
Сложность проблемы обычно преодолевается путем декомпозиции ее на отдельные компоненты с меньшей сложностью. Большая система может быть сложной, чтобы представить ее компоненты программными модулями. Поэтому разработка системы с помощью данного метода начинается с осмысления того, для кого и для чего создается система.
Сложность общей цели выражается через отдельные подцели, которым отвечают функциональные или нефункциональные требования и проектные решения. Цели являются источниками требований к системе и способом оценки этих требований, путем выявления противоречий между требованиями и установления зависимостей между целями.
Цели можно рассматривать, как точку зрения отдельного пользователя или заказчика или среды функционирования системы. Цели могут находиться между собою в определенных отношениях, например, конфликтовать, кооперироваться, зависеть одна от другой или быть независимыми.
Следующим шагом после выявления целей является определение носителей интересов, которым отвечает каждая цель, и возможные варианты удовлетворения составных целей в виде сценариев работы системы. Последние помогают пользователю получить представление о назначении и функциях системы. Эти действия соответствуют первой итерации определения требований к разработке.
Таким образом, производится последовательная декомпозиция сложности проблемы в виде совокупности целей, каждая из которых трансформируется в совокупность возможных вариантов использования системы, которые трансформируются в процессе их анализа в совокупность взаимодействующих объектов.
Определенная цепочка трансформации (проблема – цели – сценарии – объекты) отражает степень концептуализации в понимании проблемы, последовательного снижения сложности ее частей и повышения уровня формализации моделей ее представления.
Трансформация обычно выражается в терминах базовых понятий проблемной области, активно используется для представления актеров и сценариев, или создается в процессе построения такого представления.
Каждый сценарий инициируется определенным пользователем, являющимся носителем интересов. Абстракция определенной роли личности пользователя– инициатора запуска определенной работы в системе, представленной сценарием, и обмена информацией с системой - называется актером. Это абстрактное понятие обобщает понятие действующего лица системы. Фиксация актеров можно рассматривать, как определенный шаг выявления целей системы через роли, которые являются носителями целей и постановщиками задач, для решения которых создается система.
Aктер считается внешним фактором системы, действия которого носят недетерминированный характер. Этим подчеркивается разница между пользователем как конкретным лицом и актером–ролью, которую может играть любое лицо в системе.
В роли актера может выступать и программная система, если она инициирует выполнение определенных работ данной системы. Таким образом, актер – это абстракция внешнего объекта, экземпляр которого может быть человеком или внешней системой. В модели актер представляется классом, а пользователь – экземпляром класса. Одно лицо может быть экземпляром нескольких актеров.
Лицо в роли (экземпляр актера) запускает операции в системе, соотнесенные с поведением последовательности транзакций системы и называется сценарием. Когда пользователь, как экземпляр актера, вводит определенный символ для старта экземпляра соответствующего сценария, то это приводит к выполнению ряда действий с помощью транзакций, которые заканчиваются тогда, когда экземпляр сценария находится в состоянии ожидания входного символа.
Экземпляр сценария существует, пока он выполняется и его можно считать экземпляром класса, в роли которого выступает описание транзакции.
Сценарий определяет протекание событий в системе и обладает состоянием и поведением. Каждое взаимодействие между актером и системой это новый сценарий или объект. Если несколько сценариев системы имеют одинаковое поведение, то их можно рассматривать как класс сценариев. Вызов сценария – это порождение экземпляра класса. Таким образом, сценарии – это транзакции с внутренним состоянием.
Модель системы по данному методу основывается на сценариях и внесение в нее изменений должно осуществляться повторным моделированием актеров и запускаемых ими сценариев. Такая модель отражает требования пользователей и легко изменяется по их предложению. Сценарий – это полная цепочка событий, инициированных актером, и спецификация реакции на них. Совокупность сценариев определяет все возможные варианты использования системы. Каждого актера обслуживает своя совокупность сценариев.
Можно выделить базовую цель событий, существенную для сценария, а также альтернативные, при ошибках пользователя и др.
Для задания модели сценариев используется специальная графическая нотация, со следующими основными правилами:
– актер обозначается иконой человека, под которой указывается название;
– сценарий изображается овалом, в середине которого указывается название иконы;
– актер связывается стрелкой с каждым запускаемым им сценарием.
На рис. 3.2 представлен пример диаграммы сценариев для клиента банка, как актера, который запускает заданный сценарий. Для достижения цели актер обращается не к кассиру или клерку банка, а непосредственно к компьютеру системы.
Рис.3.2. Пример диаграммы сценариев для клиента банка
Все сценарии, которые включены в систему, обведены рамкой, определяющей границы системы, а актер находится вне рамки, являясь внешним фактором по отношению к системе.
Отношения между сценариями. Между сценариями можно задавать отношения, которые изображаются на диаграмме сценариев пунктирными стрелками с указанием названия соответствующих отношений.
Для сценариев определены два типа отношений:
Отношение "расширяет" означает, что функции одного сценария является дополнением к функциям другого, и используется когда имеется несколько вариантов одного и того же сценария. Инвариантная его часть изображается как основной сценарий, а отдельные варианты как расширения. При этом основной сценарий является устойчивым, не меняется при расширении вариантов функций и не зависит от них.
Типовой пример отношения расширения: моделирование необязательных фрагментов сценариев приведен на рис.3.3. При выполнении сценария расширение прерывает выполнение основного расширяемого сценария, причем последний не знает, будет ли расширение и какое. После завершения выполнения сценария расширение будет продолжено путем выполнения основного сценария.
Отношение "использует" означает, что некоторый сценарий может быть использован как расширение несколькими другими сценариями.
Оба отношения – инструменты определения наследования, если сценарии считать объектами. Отличие между ними состоит в том, что при расширении функция рассматривается как дополнение к основной функции и может быть понятной только в паре с ней, тогда как в отношении "использует " дополнительная функция имеет самостоятельное определение и может быть использована всюду.
Рис.3.3. Примеры расширения сценариев
На рис. 3.4. показано, что сценарий "сортировать" связан отношением "использует" с несколькими сценариями.
Рис.3.4. Пример отношения "использует "
Таким образом, продуктом первой стадии инженерии требований (сбора требований) является модель требований, которая состоит с трех частей:
1) онтология домена;
2) модель сценариев, называемая диаграммой сценариев;
3) описание интерфейсов сценариев.
Модель сценариев сопровождается неформальным описанием каждого из сценариев. Нотация такого описания не регламентируется. Как один из вариантов, описание сценария может быть представлено последовательностью элементов:
– название, которое помечает сценарий на диаграммах модели требований и служит средством ссылки на сценарий;
– аннотация (краткое содержание в неформальном представлении);
– актеры, которые могут запускать сценарий;
– определение всех аспектов взаимодействия системы с актерами (возможные действия актера и их возможные последствия), а также запрещенных действий актера;
– предусловия, которые определяют начальное состояние на момент запуска сценария, необходимое для успешного выполнения;
– функции, которые реализуются при выполнении сценария и определяют порядок, содержание и альтернативу действий, выполняемых в сценарии;
– исключительные или нестандартные ситуации, которые могут появиться при выполнении сценария и потребовать специальных действий для их устранения (например, ошибка в действиях актера, которую способна распознать система);
– реакции на предвиденные нестандартные ситуации;
– условия завершения сценария;
– постусловия, которые определяют конечное состояние сценария при его завершении.
На дальнейших стадиях сценарий трансформируется в сценарий поведения системы, т.е. к приведенным элементам модели добавляются элементы, связанные с конструированием решения проблемы и нефункциональными требованиями:
– механизмы запуска сценария (позиции меню);
– механизмы ввода данных;
– поведение при возникновении чрезвычайных ситуаций.
Следующим шагом процесса проектирования является преобразование сценария в описание компонентов системы и проверка их правильности.
Описание интерфейсов делается неформально, они определяют взгляд пользователя на систему, с которым необходимо согласовать требования, собранные на этапе анализа системы и определения требований. Все вопросы взаимодействия отмечаются на панели экрана для каждого из актеров и их элементы (меню, окна ввода, кнопки - индикаторы и т.п.).
Построение прототипа системы, моделирующего действия актера, помогает отработать детали и устранить недоразумения между заказчиком и разработчиком.