CC BY
57
СПИСОК ЛИТЕРАТУРЫ
1. Котляров, В. Основы современного тестирования программного обеспечения, разработанного на C# [Текст]/В. Котляров, Т. Коликова.
2. UML Distilled Second Edition A Brief Guide to the Standard Object Modeling Language [Электронный ресурс].
3. ITU Recommendation Z.120. Message Sequence Charts (MSC), 11/99 [Электронный ресурс].
4. Telelogic Tau TTCN Suite [Электронный ресурс] http://www.telelogic.com/products/tau/ttcn/ index.cfm
5. T-VEC Technologies [Электронный ресурс] http://www.t-vec.com/Home.asp
6. ISP RAS Red Verst [Электронный ресурс] http://www.ispras.ru/~RedVerst
7. Conformiq Software Ltd. [Электронный ресурс] http://www.conformiq.com/products.html
8. Веселов, А.О. Автоматизация тестирования телекоммуникационных приложений [Текст]/А.О. Веселов, А.С. Иванов, Б.В. Тютин, В.П. Котляров//Научно-технические ведомости СПбГПУ.-2009.-№ 3.
УДК 004.415
И.В. Никифоров, А.В. Петров, Ю.В. Юсупов
генерация формальной модели системы
ПО ТРЕБОВАНИЯМ, ЗАДАННЫМ В НОТАцИИ USE CASE MAP
Разработка программного продукта начинается с анализа требований, которым должна удовлетворять система, поскольку они разрабатываются вручную и им свойственны противоречивость, неполнота, недостаточная детальность и т. п. Для того чтобы на этапе проектирования требований более точно понять, как должна работать система, необходимо использовать описание архитектуры и поведения системы через диаграммы вариантов использования (UCM - Use Case Maps).
Формализуя высокоуровневый дизайн программной системы в нотации UCM, в результате получаем ее модель на формальном языке. Формальная модель позволяет применить математический аппарат верификации, получить спектр моделей различной детальности в процессе уточнений, а также имеется возможность автоматической генерации исполняемого кода из модели.
Верификация позволяет осуществить проверку корректности, полноты и непротиворечивости требований до этапа автоматической кодогенера-ции, что существенно снижает стоимость создания корректной исполнимой модели проектируемой системы.
В качестве языка описания формальной модели была выбрана нотация базовых протоколов,
используемая в теории взаимодействующих агентов и сред [1] для спецификации их поведения с помощью элементарных MSC диаграмм.
В статье описаны особенности использования языка UCM на этапе архитектурного описания проектируемой системы, автоматический переход от нотации UCM к формальной модели в виде базовых протоколов, средства проверки простых ошибок и описок ручной формализации, а также результаты применения разработанного подхода к разработке реальных проектов.
Use Case Maps
Варианты использования - это описание последовательности действий, которые может производить система в ответ на внешние воздействия пользователей или программных систем (компонентов). Варианты использования отражают функциональность системы с точки зрения описания архитектуры системы. Их применение привносит важные составляющие в процесс разработки программных систем [2]:
заполняет промежуток между словесным описанием требований и детальным дизайном системы;
позволяет разработать архитектуру системы на высоком уровне абстракции, а также за-
Рис. 1. UCM диаграмма
дать поведение системы, когда архитектура уже определена;
помогает разработчику предсказывать поведение сложных систем;
предоставляет удобную нотацию, позволяющую изображать на диаграмме параллельные структуры, таймера, точки прерывания, использовать аспекты.
Дизайн системы в нотации UCM представляет набор взаимодействующих между собой диаграмм. В свою очередь каждая из диаграмм сосредоточена на описании взаимодействия компонентов (агентов, процессов системы), объектов, наблюдателей и подсистем. Каждый компонент и подсистема содержит в себе элементы ответственности (Responsibilities), соответствующие некоторым событиям в системе, а также строгую последовательность их возникновения. Таким образом, совокупность компонентов и диаграмм дает пользователю наглядное представление о поведении системы и взаимодействии между ее компонентами.
Разработка UCM диаграмм осуществляется с использованием графического редактора UCM Navigator [3]. На рис. 1 приведен фрагмент UCM диаграммы для реального проекта из области телекоммуникаций, на котором показано взаимодействие четырех компонентов, изображенных прямоугольниками. Сценарий взаимодействия обозначен линиями и различными элементами (например, Responsibility, Timer), порядок следования которых определен направленностью линий.
Когда диаграмма, изображающая поведение системы или ее фрагмента, становится сложной для понимания, используется механизм структурирования диаграмм с помощью элементов Stub (контейнер). Верхний уровень UCM рассматривается как корневая диаграмма, которая может содержать контейнеры для поддиаграмм (plugins). Элемент Stub изображается на диаграмме ромбом, который может иметь несколько входов (линий, входящих в Stub) и выходов (линий, выходящих из Stub). На рис. 2 приведена UCM диаграмма с элементом Stub (имя «voice 2»), имеющим один вход и два выхода.
Использование элемента Stub - это способ добавления различных уровней абстракции в модели, что позволяет при необходимости изучать систему на высоком уровне абстракции, не вдаваясь в детальное описание ее компонентов.
[Not voice]
MmHHIRaTj
Рис. 2. UCM диаграмма с элементом Stub
Рис. 3. Метаданные для UCM элемента
Разработанный подход к формализации поведения систем основан на использовании метаданных, которые могут быть добавлены практически на все элементы проекта (Responsibility, Timer, Start Point, End Point, Map и т. д.). Использование этих полей позволяет перенести всю необходимую информацию из требований в UCM дизайн. В метаданные можно помещать дополнительную информацию о самом элементе, его описание, характеристики и маркированный текст, необходимый для процесса формализации.
Метаданные представляют собой неограниченный набор данных формата: «Имя переменной» -«Значение переменной», где каждое имя соответствует определенному типу информации. Например, имя «SI» соответствует описанию сигнала, имя «АС» соответствует описанию действия.
Формализация
Для автоматического перехода от высокоуровневого дизайна, заданного в нотации UCM, к формальному описанию в виде базовых протоколов, используется инструмент UCM2BP [4]. Инструмент поддерживает несколько форматов экспорта, позволяя гибко управлять этим процессом: базовые протоколы [1], MSC диаграммы и табличное представление.
Базовые протоколы. В этом режиме кроме множества базовых протоколов осуществляется генерация трех конфигурационных файлов:
файл окружения, содержащий описание агентов и атрибутов с указанием их начальных значений, а также процессов, участвующих в системе; файл описания сигналов системы; файл с описанием фильтров, задающих параметры по умолчанию для верификации.
Модель на основе базовых протоколов или VRS проект - исходные данные для верификации -загружается в VRS Client [5]. VRS Client является графическим средством для работы с базовыми протоколами и конфигурационными файлами. Он также обеспечивает запуск и управление системой автоматизированной верификации.
Для больших проектов, описываемых множеством UCM файлов, существует возможность генерации единого структурированного множества базовых протоколов и объединенных конфигурационных файлов.
MSC диаграммы. MSC диаграммы, получаемые по UCM проекту, используются для генерации эвристик (правил генерации сценариев). Автоматически сгенерированные эвристики используются VRS в процессе генерации поведенческих сценариев или трасс. Поскольку процесс генерации трасс связан с взрывом вариантов и может даже для систем среднего размера занимать десятки часов, применение эвристик сокращает время генерации на порядки.
Табличное представление. Этот выходной формат является табличным представлением основных частей базового протокола, используемого в метаданных. Набор специальных маркеров используется в метаданных для выделения пред- и постусловий, сообщений, действий и т. д. Данное табличное представление множества базовых протоколов используется инструментом ARF Tool [6], позволяющим провести ряд проверок формализации. Результатом проведения проверок является обнаружение и исправление простых ошибок и описок, внесенных в ходе создания формальной модели по текстовому описанию требований. Например, таким способом
можно определить дублирование описаний, нехватку информации в описании объекта, использование разных имен для описания одного и того же объекта и т. п.
Важно отметить, что при переходе от высокоуровневого дизайна в нотации UCM к формальному описанию в виде базовых протоколов, вся информация из метаданных и комментариев, помещенных на элементы диаграмм, используется при построении соответствующих частей базовых протоколов. Таким образом, в формальной модели системы в виде VRS проекта сохраняются все ее свойства, заданные разработчиком на этапе создания UCM проекта.
Проверки
Система ARF Tool осуществляет проверки по табличному представлению UCM проекта, содержащее описание требований в виде таблицы, где компоненты требований классифицированы. Таблица (рис. 4) имеет относительно свободный формат, однако, в ней выделены специальные (обязательные) колонки, в которые заносится информация, извлекаемая из текста требований или UCM проекта. В колонках табличного представления формализуемого требования выделяются используемые переменные состояния, описание которых содержится в таблице специального формата - онтологии (словаре переменных).
Документы, содержащие требования к проекту, могут быть достаточно объемными и со-
держать тысячи, а иногда и десятки тысяч требований. В таких случаях анализ и формализация требований осуществляется по частям (разделам) разными группами инженеров. Табличное представление позволяет проводить объединение результатов без особых проблем. Однако важной задачей при этом становится проверка общего документа на наличие в нем ошибок следующих видов: одинаковые имена базовых протоколов и переменных или наоборот, различные имена переменных, формализующих одни и те же параметры и т. п. Такого рода ошибки необходимо выявлять и исправлять на ранних стадиях проектирования, поскольку от их наличия зависят крайне важные свойства модели, такие, как корректность, полнота и адекватность.
Результаты
Приведенный в данной статье подход к автоматической формализации требований, заданных в нотации иСМ, был успешно применен в трех проектах из области телекоммуникации.
Результаты, полученные на основе пилотирования, позволили сократить время формализации требований в два раза по сравнению с ручным подходом.
Использование на фазе дизайна иСМ нотации позволяет создать адекватные требованиям архитектурные модели разрабатываемых систем, а затем, на основе полученных моделей, сгенери-
ID Identifier Requirements Scenario of requirements Scenario ID Traceabilit References T«. Order SFReq FRe q Name PRE ACT SI POST DIR Comment Error
5 RAD.02 Pressing the button Off turns radio off 1. Press OS btiaon 2. СГм-dc ïâ Raüö s now ятъ&кйгоЯ scresoî ÎÎAD-OÎ SBP Rea_RadOff SAGRad, Radio SPRIdle SVR{power="on") SSfTurnOff, UsnPUser, Radio SPOOffOn
S SBPRadOff SAGRad, Radio SPROffOn SAC Radio Off SPOOffO SVO{pOAer:=^fr);{memory:symb:="Oir);{autosearch:symb:="ofr}
7 SBPRes_RadOff SAG Rad, Radio SPROffO SVR{(X№er="ofr) SSfConf1rm_TurnOff, Radio, UsisUser SPOOff Volume min_vol_lev = 0 max_vol_tev = 20 vol_ch_val = 1
RAD.03 The minimal volume level is 0 units. The maximal volume level is 20 units. The minimal stride for changing the volume level is 1 unit.
RAD.04 After the radio is switched on, the volume level is 5 units inrt_vol_lev = 5
9 RAD.05 When the volume decrease button is pressed, the volume level is decreased at the minimal striie for changing the volume level. 1- Chsdt res ÏK «Яга SMieossa к Тл кгеОЗ ÄAO.OS Req_Vo£>3wn SBP Rea_VolDown SAG Rad, Radio SPRIdle SSfVolume_Down, Usrsllser, Radio SPOVolDown
10 SBPVolDmraCh SAG Rad, Radio SPRVolDcwn SVR{vol:int>min_vol_lev:int} SA С Volume: down SPOVolD SVOivol:=vol-vol ch val:int>
11 SBPRes_VolDo.vn SAGRad, Radio SPRVolD SSfConfirm_Volume_Down, Radio, Usi#User SPOIdle
Рис. 4. Пример табличного формата представления требований
ровать спектр более детализированных моделей, на основе которого сгенерировать исполняемые модели и прототипы реальных систем телекоммуникационных приложений.
Предлагаемый подход позволяет также выявить и исправить некоторые классы ошибок, недостатков и некорректностей в исходных требованиях.
СПИСОК ЛИТЕРАТУРЫ
1. Летичевский, А.А. Спецификация систем с помощью базовых протоколов [Текст]/А.А. Летичевский, Ю.В. Капитонова, А.А. Летичевский (мл.) [и др.]//Кибернетика и системный ана-лиз.-2005.-№ 4.-С. 3-21
2. Buhr, R.J.A. Use Case Maps for Object-Oriented Sytems [Текст]/Ю.А. Buhr, R.S. Casselman. -Prentice Hall, 1995.
3. Use Case Map Navigator [Электронный ресурс] http://jucmnav.softwareengineering.ca
4. Никифоров, И.В. Использование Use Case Map в современной технологической цепочке разработки программного обеспечения [Текст]/ И.В. Никифоров, Ю.В. Юсупов//ХХХУШ Неделя
науки СПбГПУ. Матер. межвуз. науч.-техн. конф. СПб.: Изд-во Политехнического ун-та.-2009. -С. 92-93.
5. Letichevsky, A. Basic Protocols, Message Sequence Charts, and the Verification of Requirements Specifications [Текст]/А. Letichevsky, J. Kapitonova,
A.(Jr). Letichevsky [et al.]//ISSRE 2004, Workshop on Integrated reliability with Telecommunications and UML Languages, Rennes. -4 Nov. 2005. -P. 30-38.
6. Котляров, В.П. Автоматизация формализации требований программного проекта [Текст]/
B.П. Котляров, А.В. Петров//Научно-технические ведомости СПбГПУ.-2009.-№ 3.-C. 236-241.
УДК 004.415
М.Ш. Даишев, Л.П. Котлярова
МЕТОДИКА ОТЛАДКИ НА ОСНОВЕ ВОСПРОИЗВЕДЕНИЯ ТРАССЫ ИСПОЛНЕНИЯ ПРИЛОЖЕНИЯ НА ЯЗЫКЕ JAVA
Разработчики программного обеспечения тратят много времени, пытаясь воспроизвести дефекты, возникающие в ходе нефункционального тестирования, тестирования в реальном окружении или в уже изданном программном продукте. Основная сложность отладки таких дефектов заключается в необходимости воспроизведения дефекта в окружении разработчика. В нефункциональном тестировании часто возникает ситуация, когда дефект возникает только после нескольких дней устойчивой работы приложения. Обычно такие проблемы принято решать добавлением многоуровневого логирования, которое позволяет получить некоторую информацию о сбое. Однако часто подобная схема не срабатывает по причине недостатка отладочной информации, или из-за прекращения воспроизводимости дефекта, или из-за существенного увеличения времени до по-
явления дефекта. Во встроенном программном обеспечении с ограниченными ресурсами исправление подобных дефектов может растягиваться на недели.
Большинство известных систем отладки базируется на сохранении содержимого оперативной памяти (core dump) [1, 2], представляющего собой финальное состоянии системы перед сбоем. К сожалению, подобного решения недостаточно, поскольку сложно определить основную причину дефекта.
Одно из решений данной проблемы - создание системы, которая позволит сохранять поток управления приложения (трассу) в условиях, где дефект повторяется, и впоследствии восстанавливать состояние системы, на момент появления дефекта в окружении разработчика.
