CC BY
18
4
4. Веселов, А.О. Автоматизация тестирования в 5. Recommendation ITU-T Z.120. Message Sequence
области телекоммуникаций [Текст] / А.О. Веселов, В.П. Chart (MSC), 11/2000 [Электронный ресурс]. Котляров// Научно-технические ведомости СПбГПУ 6. [Электронный русурс] / Режим доступа: http://
-2010. -№4(103). -С. 180-185. www.uml.org/
УДК 004.415
И.В. Никифоров, А.В. Петров, Ю.В. Юсупов, В.П. Котляров ПРИМЕНЕНИЕ МЕТОДИК ФОРМАЛИЗАцИИ
для построения верификационных моделей систем
по ucm-спецификациям
Современные тенденции в создании качественного программного обеспечения (ПО) заключаются в более детальном анализе исходных требований и применении высокоуровневого дизайна системы на ранних этапах разработки. Это связано с тем, что наиболее дорогостоящими являются ошибки этапов анализа требований и дизайна, поэтому актуальна идея выявления и исправления ошибок на ранних стадиях процесса создания ПО.
Проектирование требований связано с выделением целей, функций и ограничений на систему. В нем выделяются задачи сбора и формализации требований, согласования формализации с заказчиком, моделирования проблемы, проверки полноты и непротиворечивости требований. Известен ряд промышленных инструментов [6, 9], позволяющих частично решать перечисленные выше задачи, основной недостаток которых -ориентация либо на прозрачную для пользователя формализацию, либо на доказательство корректности требований, сформулированных в алгебраической нотации.
Наиболее удачное решение перечисленных задач найдено в интеграции инструментов формализации (jUCMNav [7]), верификации (VRS [1]) и транслятора нотаций формализации в нотацию верификации (UCM2BP [3]).
Нотация формализации Use Case Map (UCM) [5] позволяет структурно изображать сценарии поведения разрабатываемой системы в удобной и понятной пользователю и заказчику графической форме. Исследуя модель системы в нотации UCM, разработчик может определить визуально
проблемные места в архитектуре, обнаружить ошибки и внести соответствующие изменения, разрешающие выявленные проблемы как в исходных требованиях, так и в рассматриваемой модели.
Ручной анализ модели по сравнению с автоматическим для реальных проектов, как правило, неприемлем, поэтому в статье приведено решение задачи преобразования модели системы в нотации UCM в модель, пригодную для автоматической верификации и тестирования (модель VRS - проект из базовых протоколов [2]).
Use Case Map - язык формализации
Нотация UCM [8] достаточно проста и содержит ограниченный набор элементов, предназначенных для спецификации поведенческих сценариев разрабатываемых систем. К элементам UCM-диаграмм относятся: компоненты Team, задающие на диаграмме объект исследования или наблюдения; элементы Responsibility, отображающие выполнение каких-либо действий; StartPoint и WaitingPlace, используемые для задания начальной точки сценария и точки ожидания соответственно, когда дальнейшее исполнение возможно после наступления некоторого события или выполнения условия, и др. Используя элементы UCM-нотации можно задавать линейные или параллельные сценарии (AndFork) поведения с последующей их синхронизацией (AndJoin). Элемент FailurePoint участвует в описании механизма генерации и обработки исключений. Элемент Timer используется для задания системного таймера как для случаев простой временной задерж-
Рис. 1. Высокоуровневая UCM-диаграмма обработки заявок в телекоммуникационной системе
ки, так и для задержки, определяемой сложным логическим поведением.
Особо стоит отметить структурный элемент (Stub - ромб на диаграмме), позволяющий представлять иерархическую структуру системы и вести разработку покомпонентно от диаграммы самого верхнего уровня до детального описания низкоуровневых диаграмм.
На рис. 1 представлен фрагмент высокоуровневой UCM-модели, описывающей обработку заявок в телекоммуникационной системе. Диаграмма содержит несколько станций обработки, изображенных элементами Stub. Анализ системы можно проводить, начиная с верхнего уровня. После того, как корректность верхнего уровня доказана, можно детализировать функциональность каждой станции, рассматривая ее отдельно от всей системы, а затем объединять результаты и проводить интегральный анализ поведения всей системы.
Использование нотации UCM значительно облегчает разработку телекоммуникационных систем и бизнес-процессов. Кроме того, упрощается процесс общения заказчика с разработчиками, т. к. UCM-диаграммы интуитивно понятны для человека, являющегося специалистом в предметной области.
Применение инструмента jUCMNav на ранних стадиях разработки - важный этап в рамках технологической цепочки создания качественного программного продукта (ПП).
Язык верификации
Совместно с высокоуровневым моделированием системы на ранних этапах разработки активно применяются формальные методы для
доказательства корректности разрабатываемой системы. Формальные методы используют формальные языки. В настоящее время существует множество формальных языков, основная задача которых - описание и доказательство корректности процессов, структур данных и архитектуры программных систем, а также повышение качества за счет поиска и исправления ошибок на моделях. Здесь стоит упомянуть такие языки, как UML, SDL, LOTOS, RSL, ML, MSC, Estelle, CASL, SMV и др. Такое разнообразие связано с тем, что каждый из перечисленных языков создавался для решения задач в определенной области производства ПП.
Для дальнейшей работы была выбрана нотация базовых протоколов, являющаяся довольно простым формализмом с сильным математическим аппаратом, используемым в теории инсерцион-ного программирования для описания взаимодействующих в среде агентов [2]. Базовые протоколы используются как исходные данные в интегрированной технологии VRS/TAT. Инструмент верификации VRS [1] и инструмент автоматизации тестирования TAT [l] составляют мощную пару для выявления ошибок и дефектов в разрабатываемом ПП, позволяя использовать результаты верификации для создания тестовых наборов.
Задача данной работы - создание транслятора UCM2BP для преобразования UCM-моделей в модели из базовых протоколов. Внедрение такого транслятора в технологическую цепочку способствует автоматизации построения формальной модели, пригодной для поиска и исправления ошибок в требованиях до начала этапа генерации целевого кода.
4
Методы генерации формальной модели
Язык базовых протоколов достаточно гибок и позволяет, используя различные методики формализации, изобразить одно и то же поведение системы по-разному. В трансляторе UCM2BP [3] предложено и реализовано четыре метода формализации: «цветок», «дерево» со статическими агентами, «дерево» с динамическими агентами и смешанный метод.
Метод «цветок». Метод предполагает, что очередность применения базовых протоколов базируется на значениях управляющей переменной. При этом состояния у всех агентов одинаковые (idle). Моделирование параллельных потоков внутри одного агента происходит также на основе управляющих переменных, отвечающих за последовательность вызова базовых протоколов в каждом из потоков. На рис. 2 изображен простой граф переходов для модели, состоящей из шести базовых протоколов (A, B, C, D, E и F). В построении графа используются только состояния агента, что не позволяет судить о реальном поведении модели, в котором участвуют управляющие переменные и логические выражения над другими переменными модели. Построение «точного» графа осуществляется в процессе проверки на модели (model checking, deductive checking), когда происходит обход дерева поведения модели с постоянным вычислением состояний, следующих за текущим узлом.
Преимущество данного подхода - возможность описания объекта моделирования с помощью только одного агента, используя управляющие переменные для кодирования необходимого количества параллельных потоков и их синхронизации. К недостаткам этого метода следует отнести большие временные и ресурсные затраты, необходимые на вычисление и хранение состояний дерева поведения модели. Поскольку состояние агента во всех базовых протоколах одинаковое, то на каждом шаге приходится вычислять значения всех переменных, находящихся в ПРЕД-условии базового протокола, что напрямую отражается на времени работы верификатора и объемах затрачиваемой для вычислений памяти.
Метод «цветок» демонстрирует простоту в интерпретации, но не позволяет работать с моделями крупных размеров (более 500 базовых протоколов) из-за огромных временных затрат.
Метод «дерево». В данном методе поток управления сохраняется за счет состояний аген-
та, что дает значительное сокращение времени на вычисление следующих за текущим узлом состояний по сравнению с методом «цветок». Это преимущество напрямую отражается в сокращении времени обхода дерева поведения модели.
После проведенных экспериментов было установлено, что метод «дерево» в 6 раз превосходит метод «цветок» по времени проверки модели. Помимо скорости обхода дерева поведения к преимуществу стоит также отнести свойство наглядности, т. к. уже по «грубому» графу переходов можно судить о реальном поведении агента, характеризующего весь процесс целиком или один из его параллельных потоков (рис. 3). Построение «точного» графа осуществляется во время проведения проверки на модели и представляет собой параллельную композицию всех агентов анализируемой системы, погруженных в верификационную среду.
Недостатком данного подхода является то, что пользователь вынужден использовать дополнительные агенты для моделирования параллельных потоков внутри одного процесса. Это приводит к усложнению структуры модели, ее читаемости и анализа. Однако если в системе отсутствуют фрагменты с таким поведением, то использование метода «дерево» всегда будет иметь преимущество по сравнению с методом «цветок».
Метод «дерево» можно разделить на два отдельных метода в зависимости от используемого типа агента: статический или динамический. Различие между статическими и динамическими агентами заключается в том, что статические агенты создаются в самом начале функционирования модели и живут вплоть до ее смерти. При этом верификатор вынужден анализировать все агенты модели на каждом шагу, что не всегда необходимо (возможны ситуации, когда отработавший агент больше никогда не будет задействован в текущем
Рис. 3. Граф состояний агента (метод «дерево»)
режиме модели). Это приводит к огромному числу переборов состояний, а, следовательно, и к увеличению времени проверки модели. Использование динамических агентов [4] позволяет ограничивать время анализа, исключая более не используемые агенты. При этом удаляются все переменные исключенного агента, что дает выигрыш по ресурсным затратам верификации.
Смешанный метод. Совместное использование метода «цветок» и метода «дерево» позволяет объединить преимущества обоих методов: сократить время проверки на модели, повысить читаемость модели и упростить ее структуру. Первое достигается использованием метода «дерево» на
линейных участках поведения, а второе и третье -за счет использования метода «цветок» на параллельных потоках в рамках одного процесса. Это дает возможность при моделировании параллелизма вместо введения дополнительных агентов ограничиться управляющими переменными. Однако для этого формализатор должен на иСМ-диаграмме пометить линейные участки путей, где будет применяться метод «дерево». К таким участкам принадлежат параллельные потоки, которые не содержат операций над общими переменными, и порядок их выполнения не влияет на поведение модели. Недостаток метода - дополнительные ручные трудозатраты на разметку.
Использование на этапе дизайна иСМ-нота-ции, инструментария верификации и тестирования VRS/TAT и транслятора иСМ2ВР позволяет создать адекватные требованиям архитектурные модели разрабатываемых систем, проводить их покомпонентный анализ в процессе верификации и генерировать тестовые наборы.
В результате получено снижение конечной стоимости ПП и увеличение его надежности за счет выявления ошибок на ранних стадиях разработки, доказательства корректности разрабатываемой системы и автоматической генерации программного продукта и тестов.
Применение различных методов формализации, удовлетворяя исходным требованиям, сокращает время верификации и упрощает архитектуру разрабатываемой системы.
Транслятор иСМ2ВР успешно внедрен в технологическую цепочку VRS/TAT и внес заметный вклад в уменьшение трудоемкости разработки ПП.
Работа частично поддержана грантом РФФИ 11-07-90412-Укр_ф_а.
список литературы
1. Веселов, А.О. Автоматизация тестирования в области телекоммуникаций [Текст]/ А.О. Веселов, В.П. Котляров // Научно-технические ведомости СПбГПУ. -2010. -№4(103). -C. 180-185.
2. Летичевский, А.А. Спецификация систем с помощью базовых протоколов [Текст] / А.А. Летичевский, Ю.В. Капитонова, А.А. Летичевский (мл.) [и др.] // Кибернетика и системный анализ. -2005. -№4. -С. 3-21.
3. Никифоров, И.В. Генерация формальной модели системы по требованиям, заданным в нотации USE CASE MAP [Текст] / И.В. Никифоров, А.В. Пе-
тров, Ю.В. Юсупов // Научно-технические ведомости СПбГПУ -2010. -№ 4(103). -C. 191-195.
4. Никифоров, И.В. Использование динамических агентов при построении формальной модели по высокоуровневым UCM спецификациям [Текст] / И.В. Никифоров, Ю.В. Юсупов// Технологии Microsoft в теории и практике программирования. Матер. межвуз. конкурса-конф. студентов, аспирантов и молодых ученых Северо-Запада. 23.03.2011. -СПб.: Изд-во Политехнического ун-та, 2011. -С. 108-109.
5. Buhr, R.J.A. Use Case Maps for Object-Ori-
4
ented Systems [Текст] / R.J.A. Buhr, R.S. Casselman. -Prentice Hall, 1995.
6. IBM Rational RequisitePro [Электронный ресурс] / Режим доступа: http://www-01.ibm.com/ software/rational/
7. jUCMNav [Электронный ресурс] / Режим доступа: http://jucmnav.softwareengineering.ca
8. Recommendation ITU-T Z.151. User requirements notation (URN), 11/2008 [Электронный ресурс].
9. Sybase PowerDesigner [Электронный ресурс] / Режим доступа: http://www.sybase.com/
