Методы и средства инженерии программного обеспечения

       

Метод инженерии требований А Джекобсона


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

Автор назвал  свой метод как базирующийся на вариантах (примерах или сценариях –use case driven) системы, которую требуется построить. В дальнейшем термин сценарий используется для обозначения  варианта представления  системы.

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

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

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

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


Таким образом, производится  последовательная декомпозиция сложности проблемы в виде совокупности целей, каждая из которых  трансформируется в совокупность возможных вариантов использования системы, которые  трансформируются в процессе их анализа в совокупность взаимодействующих объектов.

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

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

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

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

В роли актера может выступать и  программная система, если она инициирует выполнение определенных работ данной системы. Таким образом, актер – это абстракция внешнего объекта, экземпляр которого может быть человеком или внешней системой.  В модели актер  представляется  классом, а пользователь – экземпляром класса. Одно лицо может быть экземпляром нескольких актеров.

Лицо в роли (экземпляр актера) запускает операции в системе, соотнесенные с поведением последовательности транзакций системы и  называется сценарием.




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

Экземпляр сценария существует, пока он выполняется и его можно считать экземпляром класса,  в  роли  которого  выступает описание транзакции.

Сценарий определяет протекание событий в  системе  и обладает состоянием и поведением. Каждое взаимодействие между актером и системой это новый сценарий или объект. Если несколько сценариев системы имеют одинаковое поведение, то их можно рассматривать как класс сценариев. Вызов сценария – это порождение экземпляра класса. Таким образом, сценарии – это транзакции с внутренним состоянием.

Модель системы по данному методу основывается  на сценариях и внесение в нее изменений должно осуществляться повторным моделированием актеров и запускаемых ими сценариев. Такая модель отражает требования пользователей и легко изменяется по их предложению. Сценарий – это полная цепочка событий, инициированных актером, и спецификация реакции на них. Совокупность сценариев определяет все возможные варианты использования системы. Каждого актера обслуживает своя совокупность сценариев.

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

Для задания модели сценариев используется  специальная графическая нотация, со следующими основными правилами:

– актер обозначается иконой человека, под которой указывается  название;

– сценарий изображается овалом, в середине которого указывается  название иконы; 

– актер связывается   стрелкой   с   каждым запускаемым им сценарием.

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



 



                                   Рис.3.2. Пример диаграммы сценариев для клиента банка

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

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

Для сценариев определены два типа отношений:

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

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

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

 

Оба отношения – инструменты определения наследования, если сценарии считать объектами. Отличие  между ними состоит в том, что при расширении  функция рассматривается как дополнение к основной  функции и может быть понятной только в паре с ней, тогда как в отношении "использует " дополнительная функция имеет самостоятельное определение и может быть использована всюду.



                                  Рис.3.3. Примеры расширения сценариев

На рис. 3.4. показано, что сценарий "сортировать" связан отношением "использует" с несколькими сценариями.





                              Рис.3.4. Пример отношения "использует "

Таким образом, продуктом первой стадии инженерии требований (сбора требований) является  модель требований, которая состоит с трех частей:

1) онтология домена;

2) модель сценариев, называемая диаграммой сценариев;

3) описание интерфейсов сценариев.

Модель сценариев сопровождается неформальным описанием каждого из сценариев. Нотация такого описания не регламентируется. Как один из вариантов, описание сценария может быть представлено последовательностью элементов:

– название, которое помечает сценарий на диаграммах модели требований и служит средством ссылки на сценарий;

– аннотация (краткое содержание в неформальном представлении);

– актеры, которые могут запускать сценарий;

– определение всех аспектов взаимодействия системы с актерами (возможные действия актера и их возможные последствия), а также запрещенных действий актера;

– предусловия, которые определяют начальное состояние на момент запуска сценария, необходимое для  успешного выполнения;

– функции, которые реализуются при выполнении сценария и определяют порядок, содержание и альтернативу действий, выполняемых в сценарии;

– исключительные или нестандартные ситуации, которые могут появиться при  выполнении  сценария  и потребовать специальных действий для их устранения (например, ошибка в действиях актера, которую способна распознать система);

– реакции на предвиденные нестандартные ситуации;

– условия завершения сценария;

– постусловия, которые определяют конечное состояние сценария при его завершении.

 

На дальнейших стадиях  сценарий трансформируется в сценарий поведения системы, т.е. к приведенным элементам модели добавляются элементы, связанные с конструированием решения  проблемы и нефункциональными требованиями:

– механизмы запуска сценария (позиции меню);

– механизмы ввода данных;

– поведение при возникновении чрезвычайных ситуаций.

 

Следующим шагом процесса проектирования является преобразование сценария в описание компонентов системы и проверка их правильности.

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

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


Содержание раздела