CC BY
24
Перспективность описанных методов заключается в том, что оценка качества изображений позволяет формировать рекомендации оператору и администратору СРТМРВ. Например, при некорректно установленных и настроенных СФИ определенные характеристики изображений будут значительно хуже оптимальных значений. На основе этого си-
стема может информировать о необходимости подстройки определенных параметров вручную.
Предложенная методика автоматического управления параметрами СФИ в СРТМРВ позволяет значительно повысить эффективность подобных систем и упростить их установку, настройку и использование.
СПИСОК ЛИТЕРАТУРЫ
1. Воскресенский, Е.М. Метод оценки эффективности систем распознавания текстовых меток на сложном фоне с использованием дерева вероятностных характеристик [Текст] / Е.М. Воскресенский, В.А. Царев // Компьютерная оптика. -2008. -Т. 32. -№ 3. -С. 283-290.
2. Дорф, Р. Современные системы управления [Текст] / Р. Дорф, Р. Бишоп; Пер. с англ. Б.И. Копылова. -М.: Лаборатория Базовых Знаний, 2002. -832 с.
3. Шапиро, Л. Компьютерное зрение [Текст] / Л. Шапиро, Дж. Стокман; Пер. с англ. -М.: БИНОМ. Лаборатория знаний, 2006. -752 с.
4. Vesnin, E.N. The «Smart Camera» Adaptive Optoelectronic Complex [Text]/ E.N. Vesnin, A.E. Mikhailov, V.A. Tsarev, PS. Cherkas // Pattern Recognition and Image Analysis. -Pleiades Publishing, Ltd. -2011. -Vol. 21. -№ 2. -P. 354-356.
5. ProSystem CCTV: первый и единственный журнал в России по системам видеонаблюдения: профессиональное издание для экспертов и специалистов по охранному телевидению и видеонаблюдению [Текст] -М.: Немецкая Фабрика Печати. -2010. -№ 42-43.
6. Smart Cameras [Text] / Ed. A.N. Belbachir.-XX. -2010. -404 p.
УДК 004.415
А.С. Иванов, В.П. Котляров, А.А. Летичевский СТАТИЧЕСКИЙ АНАЛИЗ ТРЕБОВАНИЙ РЕАКТИВНЫХ СИСТЕМ
Требования к надежности телекоммуникационного оборудования высоки, что требует применения самых современных методов разработки и контроля качества. Описанные в данной статье подходы проверялись на приложениях телекоммуникационных систем, но они могут распространяться и на приложения многокомпонентных реактивных систем. Начальный этап разработки системы -формулировка требований. В документах, описывающих требования, часто содержится большое количество ошибок, среди которых встречаются ошибки неполноты и несоответствия начальным требованиям заказчика. Согласно исследованию Джонса [5] и Шалла [6] самыми действенными методами поиска ошибок в требованиях являются формальные инспекции кода, верификация и статический анализ моделей. Эффективность инспекций оценивается в 55 %, а эффективность остальных методов - в 65 %. Автоматизация инспекций - сложный и плохо формализуемый процесс,
в то время как автоматизация статического анализа и верификации обеспечены богатым набор методик и инструментов ведущих разработчиков программного обеспечения [7].
Статический анализ реактивных систем начинается после перевода системы с естественного языка на язык формальных спецификаций. В качестве языка спецификаций может использоваться нотация базовых протоколов [2], иСМ [8], различные расширения UML [7] , Spec# и AsmL [6]. По формальному описанию строится модель программы, позволяющая проводить статический анализ и верификацию. На основе модели нередко автоматически формируются тесты.
Реализация статического анализа системой VRS
Одной из эффективных систем статического анализа многокомпонентных систем является статический анализатор требований верифика-
4
тора VRS [3]. В данной системе для анализа используется модель, описанная в языке базовых протоколов [2]. Модель состоит из среды и погруженных в нее агентов, взаимодействующих между собой посредством чтения и изменения атрибутов. Агенты, работающие параллельно и асинхронно, могут быть представлены в виде автоматов. Состоянием в данном случае является множество всех состояний атрибутов. Переходы задаются базовыми протоколами. Базовый протокол представляет собой тройку Хоара [1] Ух(а(г, х) Р(г, х) > в(г, х)) и описывает тот факт, что если в какой-то момент времени истинно предусловие а, то выполняется процесс Р и состояние агента изменяется согласно постусловию Р (в котором допустимо изменение состояний и других агентов) [2]. Пред- и постусловия являются формулами многосортной логики первого порядка, интерпретированной на некоторых областях данных. В постусловии атрибуты могут менять свои значения. Агент, переход которого задает базовый протокол, называется ключевым для этого протокола.
Статическая верификация подобных моделей опирается на анализ наборов базовых протоколов, фактически без построения полного пространства состояний и поиска в нем. В частности, применяя базовые протоколы к заданным условиям, можно проверять инвариантность этих условий. Статический анализ может показать детерминированность поведения системы и отсутствие тупиков [3].
Состояние 5 какого-либо агента а называется недетерминированным, если из него существует более одного перехода, т. е. применимо более одного протокола с ключевым агентом а.
Введем понятие непротиворечивости для систем базовых протоколов. Оно определяется отсутствием пересечений предусловий базовых протоколов для одного ключевого агента. Пусть а(а, х, г) и а'(а, х, г) - предусловия двух различных базовых протоколов Ь и V с ключевыми агентами одного и того же типа, конкретизированные одним и тем же именем ключевого агента (в случае, если это имя является параметром), х и у - списки параметров, г - список атрибутов. Протоколы Ь и V непротиворечивы, если формула
—(Зха(а, х, г) лЗуа '(а, х, г)) (1)
тождественно истинна (отрицание невыполнимо). Система базовых протоколов называется непротиворечивой, если любая пара протоколов
с однотипными ключевыми агентами непротиворечива.
Если система базовых протоколов непротиворечива, то в каждом состоянии существует не более одного применимого базового протокола, а следовательно, все агенты такой системы имеют детерминированное поведение.
К любой исследуемой системе предъявляется требование отсутствия тупиков. Введем понятие полноты для систем базовых протоколов. Оно определяется следующим условием: дизъюнкция условий применимости всех базовых протоколов
Ух1а1 (х1, г1) V Ух2 а2 (х2, г2) V... (2)
должна быть тождественно истинной. Здесь а , (х,., г) - предусловие базового протокола Ь..
Если выполняется условие полноты и в любой момент времени для каждого типа агентов в системе найдется агент этого типа, то в каждом состоянии системы найдется хотя бы один применимый протокол. Таким образом, в полной системе отсутствуют тупики.
Требования полноты и непротиворечивости проверяются для всех исследуемых систем, но существует ряд свойств, обусловленных требованиями к конкретной системе, это могут быть, например, требования живучести, надежности. Такие свойства необходимо формулировать для каждой системы индивидуально в формализме конкретной модели.
Рассмотрим свойства, которые можно записать в виде формул базового языка, и поставим требование истинности этих формул на всех состояниях системы. В [3] они названы условиями целостности. Построим алгоритм проверки условия целостности для системы базовых протоколов. Пусть Q(г) - формула базового языка, задающая условие целостности, 50(г) - формула базового языка, характеризующая начальное состояние системы, г - список атрибутов.
• В первую очередь необходимо проверить целостность начальных состояний системы: 50 (г) ^ Q(r). Эта формула должна быть общезначимой, в противном случае начальное состояние нарушает условие целостности, тогда нет смысла продолжать проверки и алгоритм должен завершить работу.
• Далее следует проверить инвариантность условия целостности. Для этого достаточно проверить для каждого протокола следующее условие: если протокол применим и условие целостности
Рис. 1. Недетерменизм в требованиях
истинно, то после применения протокола оно также будет истинным. Формально это условие выражается в виде тождественной истинности формулы Vx(pt(а(x, r) л Q(r), Р(x, r)) ^ Q(r)), где а(x, r) и P(x, r) - пред- и постусловия рассматриваемого протокола, pt - предикатный трансфор-мер, определенный как функция осуществления перехода из одного состояния системы в другое под действием заданного базового протокола.
Недостаток статического поиска недетер-менизмов, нарушений условий целостности и тупиков заключается в том, что все найденные ошибки являются всего лишь подозрениями на ошибки и их актуальность требует дополнительного уточнения.
Состояния среды с ошибками можно получить исходя из проверки формул, которые выражают заданные свойства. Достижимость этих состояний можно опровергать статическими методами, сформулировав соответствующие условия целостности, или доказывать с помощью генерации трасс и поиска в пространстве состояний.
Пример поиска ошибок в системе. Рассмотрим простейшую систему, которая проверяет баланс абонента перед совершением звонка (рис. 1). Допустим, что минимальное значение счета может принимать значение -100. Пусть при положительном балансе система переходит в состояние звонка, а при балансе от -50 до нуля сообщает об отсутствии средств.
Предусловие совершения звонка в терминах базового протокола phone(p, dial); balance >= 0;
Предусловие получения предупреждения об отсутствии средств на счету в терминах базовых протоколов
phone(p, dial);
-50 <= balance <= 0;
В приведенной спецификации специально допущено несколько ошибок. Применяя формулу (1), получаем случай, подозрительный на ошибку при balance = 0. В общем случае необходимо исследовать модель и либо исправить ее, либо пометить данную ошибку как ложное срабатывание.
Следующий шаг - проверка модели на полноту. Для этого к модели применяется формула (2). Как и в первом случае в спецификации специально допущена ошибка (рис. 2). Статический анализатор [3] определяет неполноту и строит формулу области, подозрительной на ошибку: balance < 50.
Рассмотрим более сложный пример недетерминизма в требованиях. Первый рассмотренный нами пример был тривиален и мог быть легко найден без применения статического анализа модели. Введем базовый протокол bp1_1 с предусловием TST(m.active), ((a > 0) & (b < 150)) и постусловием TST(m.idle), (a := 120). Введем базовый протокол bp2_1 с предусловием TST(m.idle), (a > 0) и постусловием TST(m.queued). Введем базовый протокол bp2_2 с предусловием TST(m. idle), (a = b + 5 ) и постусловием TST (m.queued). Применив формулу (1), в результате получаем вердикт и формулу, описывающую состояние, в котором возможно существует неопределенное поведение.
Из формулы становится очевидно, что в случае, если b равно 125, то поведение системы не определено.
Рассмотрим пример нарушения свойства безопасности в системе. Пусть описаны два базовых протокола: bp1 c предусловием phone(p, dial); balance > 0; и постусловием phone(p, dialing); balance := balance - 1; и базовый протокол bp2 с предусловием phone(p, dial); -50 <= balance <= 0 и
Î Научно-технические ведомости СПбГПУ 4' 2012 Информатика. Телекоммуникации. Управление
Рис. 2. Неполнота в требованиях
постусловием phone(p, warning). Пусть свойство безопасности задается формулой balance > 0.
В качестве результата статический анализатор вернет два вердикта:
BP1 breaks safety;
Precondition of BP2 breaks safety.
Для первого вердикта приводится контрпример: пусть balance = 1, применяется bpl, balance = 0. Второй вердикт говорит о том, что если свойство выполняется, то протокол никогда не сможет быть применен, иначе свойство безопасности сформулировано неверно и должно быть скорректировано (рис. 3).
Автоматическое построение фильтров входных параметров. Существуют ситуации, когда внесение изменений в систему не представляется возможным, но требования для нее известны и могут быть верифицированы. Для таких систем можно провести анализ достижимости «плохих» состояний из начальных состояний системы. В случае если для каких-то входных значений система переходит в состояние тупика, недетерменизма или нарушения свойства безопасности, можно построить фильтр входных значений, который будет отбрасывать и протоколировать такие воздействия на систему.
Для реализации данного подхода необходимо найти все «плохие» состояния и записать их в виде формулы безопасности. Если плохие состояния не достижимы из любого состояния системы, то можно проигнорировать такие «плохие состояния», иначе необходимо проверить, является ли состояние начальным. Если мы нашли начальное состояние из которого достижимо «плохое» со-
стояние, то статический анализатор создаст формулу, которая определит, какие входные условия необходимо отбросить. Данная формула может быть статически упрощена и скомпилирована в исполняемый модуль фильтрации, который устанавливается перед входом системы. В данный момент реализована система создания фильтров из полученных ограничений на язык Си.
Статический анализ с применением Microsoft Spec Explorer. Тема проверки моделей активно разрабатывается и компанией Microsoft в рамках Microsoft Research. Одним из инструментов, открытых для использования, является программа Spec Explorer [6]. Данный инструмент кодирует поведение системы в исполняемую форму (модель программы). Модель программы может быть менее специфицирована, чем имплемента-ция, она должна лишь адекватно отражать состояния, нуждающиеся в проверке.
Инструмент Spec Explorer вводит три различных группы требований и делит их по вопросам: что система должна делать, что система может делать, что система не должна делать. Данные требования закладываются в систему путем описания на языке Spec# и AsmL.
Модель программы подается на model checker на явных состояниях, который позволяет искать (включая бесконечное число состояний) последовательности вызовов, в которых либо выполняются пред- и постусловия и инварианты, либо выполняется пользовательский тест. Система может найти только подозрительные на ошибки состояния, но при этом сразу же может преобразовать их в тесты и запустить на имплементации
Рис. 3. Результат работы статического анализатора
программы. Ошибки, которые позволяет найти система Spec Explorer, могут относиться к одному из следующих типов: ошибка реализации (ошибка в коде программы); в модели; в спецификации; ошибка в дизайне (логическая непоследовательность в предполагаемом поведении системы).
Microsoft Spec Explorer позволяет переиспользовать результаты верификации для дальнейшего тестирования. Может одновременно проводить статический анализ модели, генерацию тестов по этой модели и анализ покрытия имплемента-ции тестами. Однако он ориентирован только на платформу - Microsoft .NET. [6] и не может быть
применен к другим популярным языкам и платформам.
Технология статического анализа требований, описанная в данной статье, была применена в нескольких телекоммуникационных проектах и доказала свою эффективность в поиске ошибок на самых ранних стадиях разработки. Ее область применимости не ограничена телекоммуникационными проектами и может распространяться на любые реактивные системы, формализуемые с помощью описанной в статье нотации.
Работа поддержана грантом РФФИ 11-07-90412-Укр_ф_а
СПИСОК ЛИТЕРАТУРЫ
1. Hoare, C.A.R. Communicating Sequential Processes ский, Ю.В. Капитонова, В.А. Волков, О.А. Летичев-[Text] / C.A.R. Hoare. -Prentice Hall, 1985. -256 p. ский, С.Н. Баранов, В.П. Котляров, Т. Вейгарт // Кибер-
2. Летичевский, А.А. Спецификация систем с нетика и системный анализ. -2005. -№ 4. помощью базовых протоколов [Текст] / А.А. Летичев- 3. Потиенко, С.В. Статическая проверка требова-
ний и подходы к решению проблемы достижимости [Текст] / С.В. Потиенко // Искусственный интеллект. -2009. -№ 1. -С. 192-197.
4. Jones, C. Software Defect-Removal Efficiency [Text] / C. Jones // IEEE Computer. -1996. -P. 94-95.
5. Shull. What We Have Learned About Fighting Defects [Text] / Shull [et al.] // IEEE Computer. -2002. -P. 78-81.
6. Veanes, M. Model-Based Testing of Object-Oriented Reactive Systems with Spec Explorer, in Formal Methods and Testing [Text] / M. Veanes, C. Campbell, W. Grieskamp [et al.]. -Springer Verlag, 2008. -Vol. 49. -P. 39-76.
7. Baranov, S. The technology of Automation Verification and Testing in Industrial Projects [Text] / S. Baranov, V. Kotlyarov, A. Letichevsky, P. Drobintsev // Proc. of SPb IEEE Chapter, International Conf., May 18-21, 2005. -P. 81-86.
8. Никифоров, И. Генерация формальной модели системы по требованиям, заданным в нотации USE CASE MAPS [Текст] / И. Никифоров, А. Петров, Ю. Юсупов // Научно-технические ведомости СПбГПУ Сер. Информатика. Телекоммуникации. Управление. -2010. -№ 4 (103). -С. 191-195.
УДК 004.415
И.В. Никифоров, А.В. Петров, В.П. Котляров
СТАТИЧЕСКИМ МЕТОД ОТЛАДКИ ТЕСТОВЫХ СЦЕНАРИЕВ, СГЕНЕРИРОВАННЫХ С ИСПОЛЬЗОВАНИЕМ ЭВРИСТИК
В современном подходе к разработке программного обеспечения активно используются модели приложений различной детальности. Они позволяют уже на ранних стадиях проектирования проводить статический анализ поведения модели, а также создавать тестовые сценарии, поэтому задача отладки моделей и автоматически генерируемых по модели тестовых сценариев на сегодняшний день является актуальной и важной для создания качественного программного продукта.
Пример современной технологии, в которой применяется модель для верификации и тестирования, - система автоматической генерации и
исполнения тестов VRS/TAT [1]. Для высокоуровневого описания модели в рассматриваемой технологической цепочке используется нотация Use Case Maps (UCM) [2, 3].
В настоящей работе стандартная нотация UCM, позволяющая в гибкой и удобной форме задавать потоки управления, расширена средствами задания потоков данных [4] с помощью механизма метаданных. Метаданные определяют условия изменения состояний приложения, реализуемые элементом UCM: описывают состояния предусловий и постусловий, взаимодействия с переменными системы, а также действия и сигналы,
Рис. 1. Использование метаданных на UCM элементе
