Concept of unified use case model for software requirements specification.pdf Предложенная Иваром Якобсоном (Ivar Jacobson) в конце 90-х годов прошлого века концепция определения требований к программным системам в виде вариантов использования [1] на сегодняшний день является основой рабочего потока определения требований в большинстве процессов разработки программного обеспечения, в основе которых лежит объектно-ориентированная парадигма. Согласно стандарту унифицированного языка моделирования (UML) вариант использования - спецификация множества действий, выполняемых системой, имеющего значимый результат для одного или нескольких актеров (пользователей или других систем) [2]. С помощью модели вариантов использования в современных процессах разработки фиксируются две важнейшие составляющие модели требований: структурная (в виде диаграмм вариантов использования) и динамическая (в виде спецификаций сценариев вариантов использования). К сожалению, ориентированный прежде всего на разработку графических моделей артефактов программных систем UML предлагает для описания сценариев вариантов использования формат графических диаграмм состояний и практически не рассматривает инструменты для работы с текстовыми спецификациями сценариев вариантов использования. Отсутствие принятого, удобного для всех участников процесса разработки и заинтересованных сторон стандарта описания функциональных требований приводит к широкому разнообразию форматов текстовых спецификаций, например, в [4] рассматривается порядок сорока различных способов описания сценариев вариантов использования. Несмотря на большое число предлагаемых форматов, разнообразные представления вариантов использования можно разбить на два принципиально различных вида: 1. Текстовое представление - описывают последовательность действий на естественном языке, с той или иной степенью формализма. 2. Графическое представление - описывают последовательность действий при помощи диаграмм, как правило, имеющих формальную модель. Необходимо отметить еще тот факт, что различные участники процесса разработки, задействованные в работе с вариантами использования, очень часто предпочитают применять разные формы представления функциональных требований. Заказчики предпочитают текстовые описания на естественном языке, поскольку для применения диаграмм необходимо знание модели и графической нотации, более того, наличие такого текстового представления является одним из достоинств подхода, основанного на применении вариантов использования. С другой стороны, разработчики предпочитают графические представления в виде диаграмм, поскольку такие представления имеют формальную модель, которая может использоваться для дальнейших преобразований в другие необходимые артефакты процесса разработки. В результате в больших проектах со сложной структурой модели вариантов использования, когда они необходимы в различных форматах, нужно вручную создавать все необходимые представления и впоследствии выполнять синхронизацию изменений. Для больших программных систем как само такое преобразование, так и поддержка различных представлений вариантов использования в актуальном состоянии ведут к достаточно серьезным издержкам. Для решения данной проблемы в настоящей работе предлагается применять разработанную унифицированную модель вариантов использования, которая поддерживает различные способы представления. В качестве примера поддерживаемых представлений в настоящей работе рассматриваются диаграммы деятельности UML (Activity Diagram) [2], текстовые спецификации, которые разработал A. Cockburn [3] и двухколоночный табличный формат текстовых спецификаций, разработанный R. Wirfs-Brock [5]. Рис. 1. Модель «полосатых брюк» сХ - условие gX - цел ь S- успех F - неудача Как уже упоминалось выше, в процессе разработки программного обеспечения варианты использования применяются (могут использоваться) для фиксирования функциональных требований к разрабатываемому продукту. Часто при этом их необходимо представлять заказчику (или иным заинтересо- 1. Представления сценариев варианта использования Для классификации различных определений вариантов использования можно применять следующие критерии, предлагаемые Alistair Cockburn в [3]: 1. Цель: является ли целью сбор пользовательских историй или описание требований. 2. Содержимое: является ли содержимое варианта использования согласованным или оно может быть противоречивым. Если содержимое согласованно, то является ли оно при этом формальным. 3. Множественность: является ли вариант использования представлением одного или множества сценариев. 4. Структура: образует ли множество вариантов использования формальную (или полуформальную) структуру. И Якобсон [1], и Коберн [3] определяют вариант использования согласно данной классификации как требование, имеющее согласованное содержимое, представляющее множество сценариев и образующее полуформальную структуру. Для представления структуры варианта использования Коберн [1] предложил модель «полосатых брюк» (рис. 1). «Ремень брюк» - цель варианта использования, которая «держит» все сценарии. «Полосы» - индивидуальные сценарии, характеризуемые условием их наступления и результатом. Множество «Полос» разделено на две группы: достигающие цели и не достигающие цели. Основным сценарием в данной модели является наиболее простой, в котором все промежуточные цели достигаются. Все остальные сценарии являются альтернативными. Альтернативные сценарии делятся на восстанавливаемые (если одна или несколько промежуточных целей не были достигнуты, но итоговая цель была достигнута) и неудачные (итоговая цель не была достигнута). ванным лицам, не занимающимся напрямую разработкой), который может не знать специализированных нотаций (например, UML). В таком случае единственным способом представления варианта использования для заказчика является текстовое описание на естественном языке, для применения которого не требуется знаний специализированных нотаций. С другой стороны, на основании вариантов использования происходят дальнейшие этапы разработки программного обеспечения (анализ, проектирование, тестирования). В таком случае для возможности автоматизированной обработки вариантов использования необходима формальная модель, которая, как правило, отсутствует у текстовых представлений, но присутствует у графических. Таким образом, при необходимости применения различных представлений варианта использования возможны следующие варианты: 1. Вариант использования специфицируется в различных его представлениях вручную. В таком случае спецификатору ВИ необходимо проделывать фактически одну и ту же работу (спецификацию одного и того же ВИ) несколько раз. В случае необходимости внесения изменений в вариант использования такие изменения должны быть отражены во всех его представлениях, что также добавляет дополнительную работу и может являться причиной возникновения ошибок (из-за расхождений между представлениями). 2. Вариант использования специфицируется в одном представлении. После этого, с помощью специализированных инструментов, выполняется его преобразование (в том числе и автоматическое) в необходимые представлениях. При внесении изменений они вносятся в первичное представление, что ограничивает возможность спецификатора вариантов использования редактировать производные представления (после повторного преобразования будут теряться изменения производных представлений вариантов использования, изменения в производных представлениях вариантов использования не будут отражены в первичном). Такая модель реализован, например, в Visual Paradigm [6]. 3. Решение, которое предлагается в настоящей работе: создание унифицированной модели вариантов использования, которая поддерживала бы необходимые форматы представления вариантов использования и не ограничивала редактирование варианта использования одной моделью (рис. 2). Рис. 2. Переход между представлениями с помощью унифицированной модели 2. Представления сценариев варианта использования Существует достаточно много способов представления вариантов использования [4]. В качестве примера в данной работе будут рассмотрены три из них. 2.1. Диаграммы деятельности UML Одним из способов графического представления вариантов использования являются диаграммы деятельности UML. Данный вид диаграмм позволяет определить поведение с помощью последовательного исполнения поведений более низкого уровня. Исполнение следующего действия может начинаться в результате наступления одного из следующих событий: завершение исполнения предыдущего действия (потоки управления), появление необходимых данных (потоки данных), наступление определенного события (потоки управления). 2.2. Текстовая спецификация А. Коберна Согласно [1] текстовая спецификация вариантов использования состоит из общей информации: названия варианта использования, контекста использования, области действия, уровня цели, основных актеров, предусловия, триггера, минимальных гарантий и успешного постусловия. Кроме общей информации о варианте использования, описываются его основной сценарий и расширения к нему. Основной сценарий представляет собой последовательность действий, при успешном выполнении которых достигается цель варианта использования. Расширения основного сценария описывают действия при возникновении исключительных ситуаций (действия, не предусмотренные основным сценарием, ошибки, внешние события). Основной сценарий описывается в виде пронумерованной последовательности шагов: . Расширения привязываются к определенным шагам основного сценария (в том числе ко всему сценарию) и описываются в виде пронумерованной последовательности шагов: . : 2.3. Двухколоночный формат Р. Вирфс-Брок В [5] Ребеккой Вирфс-Брок было предложено оформлять сценарии варианта использования в виде диалога между основным актером и системой (не предполагается участие в одном варианте использования более двух актеров). Сценарий записывается в форме таблицы, состоящей из двух колонок: действия основного актера и действия системы. 3. Основа унифицированной модели В результате анализа различных представлений вариантов использования были выделены следующие особенности: 1. Вариант использования имеет множество сценариев, завершающихся успешно или неудачно. 2. Каждый такой сценарий представляет собой последовательность действий. 3. Каждое действие исполняется определенным актером (например, пользователем, системой). 4. Множество таких сценариев может быть бесконечно (из-за возможности образования циклов) и в результате неприменимо в чистом виде на практике. Для решения данной проблемы выделим основной сценарий варианта использования (сценарий, все действия которого успешно выполняются), а остальное множество сценариев определим через расширения к отдельным действиям основного сценария (в том числе через расширения ко множеству действий и, возможно, ко всему сценарию). 4. Предлагаемая модель сценария Предлагаемая модель представляет собой расширение к модели UML (версии 2.4.1, стандартизованной ISO) [2]. Модель основана на пакетах Classes::Kernel и CommonBehaviors::BasicBehaviors. На рис. 3 показана диаграмма пакетов предлагаемой модели. «merge» Scenarios:: Partitions «merge» Scenarios:: EventTypes Рис. 3. Диаграмма пакетов предлагаемой модели Модель состоит из следующих пакетов: 1. Scenarios::Kernel содержит ядро модели, определяющее базовые элементы сценария и потоки управления для перехода между элементами. 2. Scenarios::Nodes содержит конкретные элементы сценария (например, действия, обработчики событий и т.д.). 3. Scenarios::Partitions содержит разделы, используемые для группировки элементов сценария. 4. Scenarios::EventTypes содержит типы событий. Рассмотрим каждый пакет более подробно. 4.1. Пакет Scenarios::Kernel Рис. 4. Диаграмма классов пакета Scenarios::Kernel Пакет Scenario::Kernel представляет собой ядро унифицированной модели (рис. 4). В нем определяются сценарий варианта использования, элементы сценария и потоки управления, используемые для перехода между элементами сценария. Описание классов пакета: 1. Scenario представляет собой сценарий варианта использования. «merge» 2. ScenarioNode представляет собой элемент сценария варианта использования. 3. ScenarioFlow представляет направленный поток управления, передающий исполнение от одного элемента сценария другому. Поток может иметь ассоциированное с ним условие, в таком случае передача управления выполняется, только если условие выполняется. 4.2. Пакет Scenarios::Nodes EventTrigger EventHandler 5 UML::CommonBehaviors:: BasicBehaviors::Behavior StartHandier InvokeAction Scenarios:: Kernel:: Scenario Рис. 5. Диаграмма классов пакета Scenarios::Nodes Пакет Scenarios ::Nodes содержит различные элементы сценария унифицированной модели (рис. 5). В нем определяются действия сценария, триггеры и обработчики событий и т.д. Описание классов пакета: 1. Scenario - класс сценария расширен для связи с обработчиком начала сценария. 2. Action представляет действие в сценарии. 3. InvokeAction представляет действие сценария, являющееся вызовом другого поведения (в том числе, возможно, и сценария). 4. Decision представляет элемент сценария, который выбирает один из исходящих потоков для продолжения исполнения. Для определения потока, по которому передается управление, используются условия потоков. 5. Event - абстрактный класс, представляющий событие в сценарии: элементы, вызывающие события, и элементы, обрабатывающие события. 6. EventType - абстрактный класс EventType, представляет тип события. 7. EventTrigger - абстрактный класс EventTrigger, представляет триггер события - элемент, при исполнении которого происходит определенное событие. 8. EndTrigger - класс EndTrigger, представляет завершающий сценарий элемент. При исполнении данного элемента сценарий завершается. Если с завершающим элементом ассоциирован тип события, то происходят вызов данного события и передача его в сценарий, вызвавший данный сценарий. 9. EventHandler - класс EventHandler, представляет абстрактный обработчик события. 10. StartHandler - класс StartHandler, представляет обработчик начала сценария - элемент сценария, с которого начинается его исполнение. У сценария может быть только один обработчик начала. 11. IntermediateHandler - класс IntermediateHandler, представляет промежуточный обработчик события. 12. BoundaryHandler - класс BoundaryHandler, представляет промежуточный обработчик события, который обрабатывает события в связанном с ним действии сценария. Заключение В результате была разработана унифицированная модель вариантов использования, имеющая собственную графическую нотацию. На основе предложенной модели разработан прототип инструмента для работы со сценариями варианта использования в предложенной модели. Реализация поддерживает преобразование сценариев из текстовой нотации Ребекки Вирфс-Брок (R. J. Wirfs-Brock) в графическую нотацию предложенной модели и наоборот. В дальнейшем планируется анализ возможности трассировки вариантов использования в предложенной модели в артефакты дальнейших этапов процесса разработки, например модель анализа и модель тестирования.

Скачать электронную версию публикации