Downloaded 33 times
![Верификация программно-конфигурируемых
сетей при помощи системы UPPAAL
Владислав Подымов, Ульяна Попеско
МГУ имени М.В. Ломоносова
valdus@yandex.ru, ulya_kiber@mail.ru
Аннотация В последние несколько лет активное развитие получили программно-конфигурируемые сети (ПКС) – особый вид компьютерных сетей, в которых все коммутирующие устройства имеют централизованное управление. В статье исследуются задачи формального описания и верификации ПКС. Для описания ПКС используется
библиотека элементов UML в редакторе диаграмм Dia. Для верификации ПКС используется программно-инструментальное средство
UPPAAL. Основной результат исследований - разработка транслятора, позволяющего по диаграмме сети получить её модель для верификации в виде сети конечных временных автоматов. Корректность
алгоритма трансляции строго обоснована. Проведен ряд экспериментов, которые показывают применимость предложенного метода верификации для проверки свойств поведения ПКС, специфицированных
посредством формул темпоральной логики реального времени.
Keywords: программно-конфигурируемая сеть, верификация, временные автоматы, темпоральная логика, UPPAAL
1
Введение
Идея программно-конфигурируемых сетей (ПКС) сформулирована специалистами университетов Стэнфорда и Беркли в 2006 году [1]. В таких сетях
уровень управления отделен от устройств передачи данных: коммутаторы
не участвуют в определении маршрутов для пакетов, а только реализуют
программу контроллера. Наиболее широко применяемым стандартом для
построения ПКС является протокол OpenFlow [2].
Сеть OpenFlow состоит из коммутаторов, управляемых централизованным контроллером. Пакет, передаваемый по сети, обрабатывается контроллером существенно медленнее, нежели коммутатором, поэтому одной из основных функций контроллера является организация работы коммутаторов
так, чтобы они обрабатывали большую часть пакетов, и лишь в исключительных случаях пакеты обрабатывались бы на контроллере.
Организация работы коммутаторов заключается в установке правил в
таблицы коммутации (flow tables), определяющих, как будут обрабатываться те или иные пакеты. Правило состоит из шаблона, идентифицирующего
вид пакетов, целочисленного приоритета, устраняющего неоднозначность в
36
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-36-320.jpg)
![4
Владислав Подымов, Ульяна Попеско
деляется политикой коммутации пакетов в сети, которая для нашего класса задач представима в виде таблицы, отображающей соответствие между
заголовком поступившего на контроллер пакета и правилом, которое необходимо установить на коммутатор, приславший этот пакет. Также отдельно
описывается множество всех возможных заголовков пакетов.
Для проверки спецификаций построенных таким образом ПКС было выбрано программно-инструментальное средство UPPAAL [3], использующее
метод проверки свойств на моделях. Данный метод предполагает наличие
модели, описывающей систему на определенном уровне абстракции, и позволяет проверить, удовлетворяет ли заданная модель системы формальным
спецификациям. В средстве верификации UPPAAL в качестве модели используются сети конечных временных автоматов (параллельные композиции временных автоматов) [4], а формальные спецификации задаются формулами темпоральной логики TCTL [3].
Временные автоматы представляют собой конечные автоматы, работающие в реальном времени и осуществляющие синхронизацию посредством передачи сигналов через каналы связи. Особенностью таких автоматов является возможность использования таймеров. Значения таймеров можно указывать во временных ограничениях условий переходов между состояниями.
Показания всех таймеров изменяются на одинаковые величины с течением
времени.
Для верификации ПКС, описанных в терминах диаграмм Dia, средством
UPPAAL, нами предложен алгоритм трансляции диаграмм в сети временных автоматов. Сеть, получаемая при трансляции, состоит из автоматов,
моделирующих коммутаторы, контроллер, внешнюю среду и каналы сети.
Таким образом, в результате трансляции диаграмм мы получаем сеть, пригодную для верификации средством UPPAAL. Подобный подход к верификации распределенных систем реального времени был применен в работе
[5].
3
Формальный синтаксис ПКС
Перед описанием алгоритма трансляции необходимо ввести формальную
модель ПКС. С учетом выбранных нами ограничений ПКС может быть описана системой (H, con, Com, Chan), где H — множество заголовков пакетов
сети, con — контроллер, Com = (com1 , . . . , comn ) — набор коммутаторов
сети и Chan = (c1 , . . . , cm ) — набор каналов сети. Заметим, что во введенной формальной модели ПКС вместо пакетов рассматриваются только их
заголовки, при этом содержащиеся в пакетах сообщения опускаются. Для
простоты восприятия далее под пакетами в формальной модели будут подразумеваться их заголовки.
Коммутатор comi включает в себя множество портов P orti , начальную
таблицу коммутации Rulei ⊆ P orti × H × Real × P orti объема tab и временimp
def
ar
con
ные характеристики Limp , Ri , Ldef , Ri , Lar , Ri , Lcon , Ri , естественi
i
i
i
ным образом соотносящиеся с характеристиками коммутатора, описанными
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
39](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-39-320.jpg)
![6
Владислав Подымов, Ульяна Попеско
коммутатора Rule — текущая таблица коммутации, t — время нахождения
в текущем управляющем состоянии, h и p — хранимые пакет и порт.
Каналы могут могут находиться в состояниях (empty), (f ull, t, o) и (sent,
o), где o — пакет для обычных и поточных каналов, шаблон для каналов
к контроллеру либо правило для каналов от контроллера. Компонента t ∈
Real — время обработки сообщения каналом.
Контроллер может находиться только в состояниях (idle) (ожидание запросов от коммутаторов) и (send, i, r) (послать i-му коммутатору новое
правило r).
Начальное состояние S0 системы строится из начальных состояний коммутаторов, контроллера и каналов. Начальное состояние i-го коммутатора
— (start, Rulei ), контроллера — (idle), каналов — (empty).
Работа ПКС характеризуется последовательностью состояний, начинающейся в S0 и строящейся по описанным далее правилам. Запись s → s
означает, что следующее состояние может быть получено из предыдущего
заменой компоненты s на s . Запись s1 , s2 → s1 , s2 означает то же самое для
пары компонент. Построение вычисления ПКС происходит по следующим
правилам.
1. Получение пакета: scom , sar = (start, Rule), (sent, h) → (select, 0, Rule,
i
i
h, p), (empty).
2. Применение активного правила r = (p, h, x, p ): scom = (select, Rule, t,
i
imp
h, p) → (hit, Rule, h, p ), если t ∈ [Limp , Ri ], r ∈ Rule.
i
3. Обработка истекшего правила r = (p, h, x, p ): scom = (select, Rule, t, h, p)
i
imp
→ (miss, Rule , h, p), если t ∈ [Limp , Ri ], r ∈ Rule и Rule = Rule {r}.
i
4. Сброс пакета: scom = (select, Rule, t, h, p) → (start, Rule), если t ∈
i
imp
[Limp , Ri ], |Rule| = tabi , все правила из Rule активны и ни одно из
i
них не имеет шаблона (p, h).
5. Несоответствие шаблонов: scom = (select, Rule, t, h, p) → (miss, Rule ,
i
h, p), где Rule получается из Rule удалением всех истекших правил.
6. Начало перезаписи таблицы: scom , sf rom con = (start, Rule), (sent, rule)
i
i
→ (mod, 0, Rule), (sent, rule).
7. Успешная перезапись таблицы: scom , sf rom con = (mod, t, Rule), (sent, (p,
i
i
def
h, x, p )) → (hit, Rule , h, p ), (empty), если t ∈ [Ldef , Ri ], |Rule| < tabi
i
и Rule = Rule ∪ {(p, h, x, p )}.
8. Неуспешная перезапись таблицы: scom , sf rom con = (mod, t, Rule), (sent,
i
i
def
rule) → (start, Rule), (empty), если t ∈ [Ldef , Ri ] и |Rule| = tab.
i
com
ch
9. Пересылка пакета коммутатору: si , sj = (hit, Rule, h, p), (empty) →
(start, Rule), (f ull, 0, h), если канал cj исходит из порта p коммутатора
i.
10. Пересылка шаблона контроллеру: scom , sto con = (miss, Rule, h, p), (empty)
i
i
→ (start, Rule), (f ull, 0, (p, h)).
11. Успешная обработка шаблона контроллером: scon , sto con = (idle), (sent,
i
(p, h)) → (send, i, r), (empty), если (i, (p, h, x, p )) ∈ con.
12. Неуспешная обработка шаблона контроллером: scon , sto con = (idle), (sent,
i
/
(p, h)) → (idle), (empty), если (i, (p, h, x, p )) ∈ con.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
41](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-41-320.jpg)
![Верификация ПКС при помощи системы UPPAAL
7
13. Пересылка правила от контроллера: scon , sf rom con = (send, i, r), (empty)
i
→ (idle), (f ull, 0, r).
14. Появление пакета в сети: sar = (empty) → (f ull, 0, h), если h ∈ H.
i
15. Сброс пакета в окружение: scom = (hit, Rule, h, p) → (start, Rule), если
i
ни один канал cj не исходит из порта p коммутатора comi .
16. Доставка в канале: (f ull, t, o) → (sent, o), если t ∈ [L, R] для характеристик L, R соответствующего канала.
17. Продвижение времени: таймеры всех коммутаторов и каналов увеличиваются на одну и ту же положительную величину d, времена жизни
правил уменьшаются на эту же величину, и при этом:
– если какой-либо канал находится в состоянии (f ull, t, o), то t + d ≤ R
для характеристики R этого канала;
imp
– если scom = (select, Rule, t, h, p), то t + d ≤ Ri ;
i
def
com
– если si
= (mod, Rule, t), то t + d ≤ Ri .
5
Алгоритм трансляции
Алгоритм Alg переводит ПКС в эквивалентную ей сеть временных автоматов. Понятие эквивалентности обсуждается в следующем разделе.
Сеть N , получаемая в результате трансляции ПКС ((com1 , . . . , comn ),
con, (c1 , . . . , cm ), H), содержит автоматы Hurry, Env, Stream, Chan, Acon
и Ai , i ∈ {1, . . . , n}.
Каждый канал ci моделируется булевыми переменными f ull[ci ] (пакет
послан), ready[ci ] (пакет доставлен), таймером t[ci ] и переменными для хранения объектов, пересылаемых через канал. Сброс пакетов в окружение моделируется с помощью особого канала cenv . Также в сеть добавляются все
каналы car , cto con , cf rom con .
i
i
i
Автомат Hurry обеспечивает срочные дуги (т.е. дуги, выполняющиеся
немедленно по выполнении их предусловий) и состоит из одной вершины
и петли, принимающей сигнал по срочному каналу hurry. К срочным дугам по умолчанию добавляется посылка сигнала по каналу hurry. Автомат Env удаляет пакеты из канала cenv и состоит из одной вершины и
срочной петли с записью в переменную f ull[cenv ] значения f alse. Автомат
Stream генерирует пакеты, состоит из одной вершины и содержит набор
срочных петель, недетерминированно засылающий пакеты в каналы car .
i
Автомат Chan обеспечивает доставку пакетов каналами, состоит из одной
вершины и содержит петлю для каждого канала c, помеченную предусловием f ull[c] && !ready[c] && (t[c] ≥ L(c)) и записью в переменную ready[c]
значения true, где L(c) — характеристика L канала c. Сама вершина автомата Chan при этом помечена инвариантом — конъюнкцией неравенств
t[c] ≤ R(c).
Автомат Acon имеет два обычных состояния — idle и send — и одно срочное состояние l. Срочная дуга idle → l записывает в локальные переменные
автомата шаблон, присланный коммутатором, и номер этого коммутатора и
в зависимости от наличия отправляемого обратно правила переходит либо
42
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-42-320.jpg)
![8
Владислав Подымов, Ульяна Попеско
обратно в idle, либо в send. Срочная дуга send → idle присваивает переменной f ull[c] значение true и записывает в переменную канала выбранное
правило.
Автомат Ai моделирует работу коммутатора comi и состоит из обычных
состояний start, select, hit, miss, mod, соединенных через срочные вершины.
Срочная дуга start → select записывает в локальные переменные автомата
доставленный через канал c пакет и порт, на который он пришел, и записывает в переменную f ull[c] значение f alse. Состояние select, помеченное
imp
инвариантом t ≤ Ri , имеет одну исходяющую дугу в срочное состояние
l, помеченную предусловием t ≥ Limp . Здесь t — локальный таймер комi
мутатора. Из состояния l в зависимости от наличия шаблона происходит
переход в состояния hit и miss с модификацией таблицы согласно правилам
2-5 семантики ПКС. Удаление многих правил из таблицы коммутации обеспечивается срочной вершиной l с петлей, удаляющей из таблицы истекшие
правила, и исходящей дугой, помеченной предусловием, утверждающим, что
из таблицы удалены все истекшие правила. Срочная дуга start → mod записывает в локальные переменные автомата правило, доставленное каналом
def
cf rom con . Состояние mod помечено инвариантом t ≤ Ri , исходящие из него
i
def
дуги — предусловием r ≥ Li . В зависимости от того, заполнена ли таблица коммутации, из состояния mod автомат может либо перейти в состояние
start, либо перейти в состояние hit с записью правила в таблицу.
6
Корректность алгоритма трансляции
Под корректностью алгоритма Alg понимается равновыполнимость формул,
используемых в средстве UPPAAL, для исходной ПКС N и результирующей
сети Alg(N ). Ключевым понятием в доказательстве корректности алгоритма Alg является эквивалентность по прореживанию (stuttering equivalence)
для систем переходов [6]. Неформально, такая эквивалентность означает,
что если в каждом вычислении двух данных систем склеить все одинаковые состояния, то мы получим одинаковые множества вычислений. Одинаковыми полагаются состояния с совпадающими множествами выполнимых
формул. В работе [7] сформулирована следующая теорема.
Теорема 1 Если системы переходов M1 , M2 эквивалентны по прореживанию и формула Φ логики LT L−X истинна для M1 , то она также истинна
для M2 .
Следующая теорема позволяет применить только что сформулированную к системам переходов, описывающим поведение ПКС N и сети Alg(N ).
Система переходов, описывающая поведение сети временных автоматов, обсуждается, например, в [4]. Пусть T SA — система переходов, описывающая
поведение системы A.
Теорема 2 Пусть N — произвольная ПКС. Тогда системы переходов T SN
и T SAlg(N ) эквивалентны по прореживанию.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
43](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-43-320.jpg)
![Верификация ПКС при помощи системы UPPAAL
9
Теорему обосновывают следующие рассуждения. Состояниям контроллера и коммутаторов ставятся в соответствие одноименные состояния получающихся из них автоматов вместе с необходимыми значениями локальных
переменных. Состояниям каналов ставятся в соответствие наборы значений переменных f ull, ready и переменных для хранения данных. Одному
применению семантических правил 1-17 соответствует последовательность
переходов в сети временных автоматов через срочные состояния, и смена
значений переменных происходит только в одном месте последовательности. В результате применения правила в ПКС и построенной по нему последовательности переходов в сети соответствующие состояния переводятся в
соответствующие.
Корректность алгоритма напрямую следует из приведенных теорем с
учетом того, что формулы, проверяемые средством UPPAAL, могут быть
переформулированы в терминах логики LT L−X .
7
Экспериментальное исследование
В приложении приведена сеть автоматов, построенная транслятором по описанию сети на рисунке 1. Ниже приведены проверенные с помощью средства
UPPAAL свойства и их запись на языке запросов UPPAAL [3].
1. В работе системы не возникает блокировки:
A[] not deadlock
2. В сеть всегда будут поступать пакеты из внешней среды:
A <> f orall(num : int[0, 2]) (channel_h[stream.align[num]])
3. Допустим сценарий работы сети, в котором коммутатор не принимает
ни одного пакета:
E[] com1.start
4. При любом сценарии работы сети контроллер обработает хотя бы один
пакет:
E <> !con.idle
5. Хотя бы один пакет будет успешно перенаправлен коммутатором (т.е.
коммутатор выполняет свою главную функцию):
E <> com1.hit
Свойства 1,2,4,5 соответствуют спецификации сетей OpenFlow, в то время как свойство 3 является недопустимым. Проверка показала, что свойства
1,2,4,5 выполняются, а свойство 3 не выполняется. Это свидетельствует о
том, что функционирование полученной сети временных автоматов соответствует нашим ожиданиям и что предложенная схема верификации ПКС
44
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-44-320.jpg)
![10
Владислав Подымов, Ульяна Попеско
с помощью средства UPPAAL позволяет проверять свойства поведения ПКС
как системы реального времени.
В ячейках таблицы 1 представлено время проверки описанных темпоральных свойств для некоторых моделей ПКС: 1 – три коммутатора в топологии кольца (рисунок 1); 2 – четыре коммутатора в топологии звезды;
3 – четыре коммутатора в произвольной топологии; 4 – два коммутатора с
изначально пустыми таблицами коммутации. Проверка проводилась на вычислительном устройстве со следующими характеристиками: INTEL Core i7
3820/1600 МГц/2Гб DDR3. Первое свойство не было проверено на моделях
1–3 в связи с нехваткой памяти.
Таблица 1. Время проверки свойств ПКС.
Модель
Модель
Модель
Модель
8
1
2
3
4
1
27 часов
1
1
1
1
2
секунда
секунда
секунда
секунда
1
1
1
1
Свойство номер:
3
4
5
секунда
7 секунд
1 секунда
секунда 1 минута 2 секунды 1 минута 25 секунд
секунда
1 минута
1 минута 19 секунд
секунда
1 секунда
1 секунда
Заключение
В результате проведенных исследований мы подтвердили практическую осуществимость подхода, предложенного в статье [5], для проверки выполнимости свойств поведения моделей программно-конфигурируемых сетей в
реальном времени. Предложенное нами средство анализа поведения ПКС
может быть использовано для наглядного описания конфигурации и коммутационной политики сети в виде диаграмм. Разработанный нами алгоритм трансляции преобразует диаграмму в сеть временных автоматов, подаваемую на вход системы верификации UPPAAL. Корректность алгоритма
трансляции строго обоснована, транслятор реализован на языке программирования Perl. Получаемая на выходе транслятора сеть временных автоматов позволяет проверять спецификации ПКС с помощью системы UPPAAL.
Особенностью такой верификации является возможность учитывать временной аспект поведения ПКС как распределённых систем реального времени.
Список литературы
1. Casado M., Garfinkel T., Akella A., Fredman M., Boneh D., McKeown N.,
Shenker S. SANE: A Protection Architecture for Enterprise Networks // 15-th
Usenix Security Symposium, Vancouver, Canada, August 2006.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
45](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-45-320.jpg)
![Верификация ПКС при помощи системы UPPAAL
11
2. McKeown N., Anderson T., Balakrishnan H., Parulkar G., Peterson L., Rexford J.,
Shenker S., Turner J. Openflow: Enabling innovation in campus network //
SIGCOMM Computer Communication Review, 2008, v.38, n.2, p.69-74.
3. Behrmann G., David A., Larsen K. A tutorial on Uppaal // Lecture Notes in
Computer Science, 2004, v.3185, p.200-236.
4. Alur R., Dill D. Automata for modeling real-time systems // Proc. of Int.
Colloquium on Algorithms, Languages, and Programming, LNCS, 1990, v.443,
p.322-335.
5. Волканов Д.Ю., Захаров В.А., Зорин Д.А., Коннов И.В., Подымов В.В. Как
разработать простое средство верификации систем реального времени // Моделирование и анализ информационных систем, 2012, Том 19, №6, с.45–56.
6. Browne M.C., Clarke E.M., Grumberg O. Characterizing finite Kripke structures
in propositional temporal logics // Theor. Comp. Sci., 1988, v.59(1-2), p.115-131.
7. Clarke E.M., Grumberg O., Peled D. Model Checking. The MIT Press. 1999.
Приложение
Сеть временных автоматов, полученная в результате трансляции из ПКС,
изображенной на рисунке 1, приведена на рисунках 2–4. В целях удобочитаемости выражения автоматов написаны в синтаксисе, отличном от синтаксиса UPPAAL и при этом более простом для восприятия.
Запись вида (i = 1..3, 5, 7) означает перебор всех i из заданного диапазона
и создание копий дуги для каждого значения i. Запись вида (i = 1..3 → Φ)
означает “для всех i из заданного диапазона верна формула Φ”.
Функция get(c) сохраняет содержимое канала c в локальные переменные
(h, p, . . .) и выполняет присваивание c = f alse. Функция send(c, o) копирует o в содержимое канала и выполняет присваивания c = true, c_ready =
f alse, c_t = 0. Функция set_rule(i) копирует локальные переменные коммутатора, отвечающие компонентам правила, в i-ю позицию таблицы.
Предикат to_deliver(c) описывается как c && !c_ready && (c_t ≥ c_L).
Предикат ok(c) описывается как !c || c_ready || (c_t ≤ c_R).
Канал c[0] выделен под окружение, каналы c[1], c[2], c[3] — под потоки, прикрепленные к соответствующим коммутаторам. Автоматы A2 , A3
отличаются от автомата A1 только номерами задействованных каналов и
константами, определяемыми количеством портов и объемом таблицы, и по
этой причие опущены.
46
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-46-320.jpg)
![12
Владислав Подымов, Ульяна Попеско
(i = 0..2)
hurry!
idle
to_con_ready[i]
get(to_con[i]), c = i
i = 0..2 -> !hit(rule[i], (c, p, h))
!con_in[c]
hurry!
send(from_con[c],
rule[r])
(i = 0..2)
hit(r[i], (c, p, h))
r=i
s1
send
(i = 1..3, num = 1..3)
!c[num]
hurry!
send(c[num], i)
Рис. 2. Автоматы Acon (слева), Stream (справа).
from_con[0]
hurry!
get(from_con[0]),
t=0
(i = 0..3)
(t >= 2) && !active[i]
set_rule(i)
rewrite
t <= 3
i = 1..3 -> active[i]
!c[r]
hurry!
send(c[r], h)
hit
start
t >= 3
(i = 1,4,5)
select
c_ready[i]
t <= 5
hurry!
get(c[i]), p = i, t = 0
(i = 0..3)
hit(rule[i])
r=i
rule_t[r] < rule_max[r]
rule_t[r] >= rule_max[r]
active[r] = false
miss
i = 0..3 -> !hit(rule[i])
i = 0..3 -> !active[i]
|| (rule_t[i] <= rule_max[i] )
(i = 0..3)
active[i] && (rule_t[i] > rule_max[i])
active[i] = false
i = 0..3 -> active[i]
i = 0..3
!active[i]
hurry!
send(to_con[0],
(p, h))
Рис. 3. Автомат A1 .
s1
hurry?
c[0]
hurry!
c[0] = false
(i = 0..2)
to_deliver(to_con[i])
to_con_ready[i])
s1
(i = 1..9)
to_deliver(c[i])
c_ready[i]
(i = 0..2 -> ok(to_con[i])) &&
(i = 1..9 -> ok(c[i]))
Рис. 4. Автоматы Hurry (слева), Env (в центре), Chan (справа).
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
47](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-47-320.jpg)
![рификаторы. Дополнительно к разработке транслятора из целевого языка
в промежуточный язык, также разрабатываются средства обратной связи,
которые интерпретируют результаты, полученные при верификации программы на промежуточном языке, в контексте исходной аннотированной
программы. Как и в первом подходе, транслятор и средства обратной связи реализуются на некотором языке программирования общего назначения.
Примерами промежуточных языков, ориентированных на дедуктивную верификацию, являются Boogie [1] и WhyML [2]. Этот подход имеет следующие преимущества. При его реализации знания конкретной аксиоматической семантики не требуется или требуется лишь в малой степени на
уровне пользования дедуктивными верификаторами, имеющимися для промежуточного языка. Фактически разработка дедуктивного верификатора
для целевого языка состоит в разработке транслятора и требует лишь знания операционной семантики целевого и промежуточного языков и (статической) семантики используемого языка аннотаций. Недостатки второго
подхода проявляются прежде всего в случае, когда промежуточный язык
сильно отличается от целевого языка. Во-первых, обоснование корректности трансляции становится сложной задачей. Во-вторых, усложняется разработка средств обратной связи. В-третьих, при трансляции теряется структурная и семантическая информация, которая могла бы оптимизировать
генерацию условий корректности. Эта потеря, например, может быть результатом трансляции структур данных целевого языка в структуры данных промежуточного языка или результатом моделирования конструкций
целевого языка конструкциями промежуточного языка. Помимо этого, разрабатываемый верификатор не является гибким, поскольку ориентирован
на конкретные целевой язык, язык аннотаций и дедуктивные верификаторы, имеющиеся для промежуточного языка. Формат обратных связей, как
правило, также не гибок.
В третьем подходе аннотированная программа транслируется в модель
или теорию системы машинной поддержки доказательства (далее доказателя). К доказателям, используемым в дедуктивном подходе, относятся PVS,
HOL, LCF2 и др. Можно выделить следующие преимущества этого подхода. Во-первых, доказатели, как правило, основаны на логиках высшего
порядка, что позволяет использовать выразительные языки аннотаций в
дедуктивных верификаторах. Во-вторых, доказатели используют продвинутые техники доказательства для формул этих логик. В-третьих, эти техники можно применять не только к доказательству условий корректности,
но и при порождении условий корректности, таким образом оптимизируя
их вывод. Отметим недостатки третьего подхода. Во-первых, доказатели
сложны в освоении. Во-вторых, разработка модели или теории также сложна. В-третьих, доказательство условий корректности ограничено конкретным доказателем, в который вкладываются аннотированные программы.
В-четвертых, возникает непростая проблема доказательства соответствия
модели аннотированной программе. В-пятых, модель аннотированной программы, как правило, не использует дополнительную информацию, доступ-
68
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-68-320.jpg)
![могут быть использовано непосредственно для реализации простых решателей.
Требование 7. ПОЯ должен содержать развитый механизм сопоставления с образцом как на уровне синтаксической структуры (требования 3 и 4),
так и на уровне концептуальной структуры (требование 5) представлений
объектов. Сопоставление такого рода характерны для большинства средств
оперирования представлениями объектов, перечисленных в требовании 6.
Требование 8. ПОЯ должен обеспечивать средства описания смысла
конструкций целевого языка (операционной семантики целевого языка). Это
требование необходимо для формального обоснования корректности разрабатываемого дедуктивного верификатора.
3
Использование языка Atoment в качестве ПОЯ
Язык Atoment [3] — результат наших исследований по автоматизации создания операционной и аксиоматической семантик языков программирования.
В процессе его разработки возникла концепция предметно-ориентированного подхода к дедуктивной верификации и были сформулированы требования
к ПОЯ для этой предметной области. Он не является идеальным кандидатом на роль ПОЯ, но обеспечивает компромиссные показатели по всем требованиям к ПОЯ и при отсутствии на данный момент других подходящих
языков мы планируем использовать его для апробации этого подхода.
Язык Atoment обеспечивает описание объектов верификации (требование 1). Он использует два унифицированных формата для представлений
объектов (требование 2), соответствующих текстовых и нетекстовым объектам.
Текстовые объекты представляются выражениями языка Atoment. Выражения — это унифицированная форма записи конструкций языка
Atoment, подобная спискам языка Лисп. Выражения строятся из атомов
с помощью специальных символов, к которым относятся пробельные символы и круглые скобки. Например, ab и (ab (cd ef) gh) — выражения.
Атомом может быть любая последовательность Unicode символов, не содержащая специальных символов и символа кавычек ("). Специальный вид
атомов — строки позволяют использовать в атоме специальные символы.
Например, ab и "ab ("ss)" — атомы. Требование 3 для текстовых объектов обеспечивается взаимно-однозначным соответствием между их структурой и структурой выражений, представляющих эти объекты. Рассмотрим,
как обеспечивается выполнение требования 4 для текстовых объектов на
примере представления конструкций целевого языка и языка условий корректности. Ключевые слова целевого языка представляются атомами. Для
условного оператора if A then B else C ключевые слова представляются
атомами if, then и else. Сам оператор представляется выражением (if A′
then B′ else C′ ), где A′ , B′ , C′ — представления конструкций A, B, C целевого
языка. Условия корректности, как и любые другие формулы, также представляются выражениями. Так наиболее близким представлением формулы
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
71](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-71-320.jpg)
![Вспомогательное выражение (gotoStop A) обрабатывает выражение перехода (jump goto L) в случае, когда оператор (label L) принадлежит A:
(if (gotoStop A) var A then)
(if (jump E) (gotoStop A) var (+s E) (+s A) then (matchCases (jump E)
(if (jump goto L) var L then (matchCases (A)
(if (B (label L) C) var (+s B) (+s C) then C (gotoStop A))
(else (jump E))))
(else (jump E))))
Предопределенное выражение matchCases выполняет разбор случаев в соответствии с образцом. Сначала оно формирует сопоставляемое выражение. В
правиле выше это выражения (jump E) и (A) для первого и второго вхождения matchCases, соответственно. Затем для каждой ветви (if U var V then
W) оно выполняет сопоставление сформированного выражения с образцом
U для спецификации переменных образца V таким же образом, как для правила перехода. Первая подходящая ветвь выполняется таким же образом,
как правило перехода. Если ни одна из ветвей не подошла, и matchCases
содержит выражение (else W), то выполняется последовательность W. В
противном случае, с помощью механизма бектрекинга выполняется откат к
предыдущей точке ветвления.
Эта версия операционной семантики для оператора блока иллюстрирует
использование вспомогательных конструкций. Чтобы адаптировать правила
операционной семантики, мы не меняем их, а добавляем вспомогательную
конструкцию, которая специфицирует требуемую адаптацию, и для нее описываем операционную семантику. Соответствующие вспомогательные конструкции используются и при описании аксиоматической семантики.
Рассмотрим теперь, как с помощью правил перехода описываются правила и стратегии дедуктивного вывода. Особенностью нашего подхода является то, что вместо логики Хоара используется ее расширение — логика
безопасности, предложенная в [4].
В логике Хоара ключевыми понятиями являются точки входа и выхода,
которым соответствуют пред- и пост-условия. В ряде расширений логики
Хоара допускается несколько точек входа и выхода.
В логике безопасности точек входа и выхода нет, и, соответственно, нет
предусловия и постусловия. Вместо этого ряд точек программы снабжаются
так называемыми условиями безопасности. Программа корректна в логике
безопасности (безопасна), если при любом исполнении программы, если достигнута точка программы с условием безопасности, то это условие должно быть истинно. Таким образом, логику безопасности можно применять к
программам без явных точек входа или выхода, например операционным
системам или телекоммуникационным протоколам.
Важное свойство нашего подхода, являющееся одним из его преимуществ, заключается в том, что для многих конструкций целевого языка
правила логики безопасности структурно не отличаются от правил операционной семантики. Таким образом, разработав операционную семантику
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
75](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-75-320.jpg)
![Как видно из первого правила, сначала вычисляется выражение A. Если
при его вычислении происходят побочные эффекты, то они описываются
правилами для соответствующих подвыражений выражения A. Результат
вычисления выражения A сохраняется в нульместном символе (val). Затем
выполняется сравнение значения этого символа с true или false. Второе
правило просачивает выражение перехода через условный оператор.
Правила логики безопасности для условного оператора совпадают с правилами операционной семантики. Однако операционная семантика ряда
предопределенных выражений, например cases, отличается для контекстов
применения, соответствующих операционным и дедуктивным правилам перехода [3].
5
Заключение
В заключение, ответим на вопрос, зачем разрабатывать универсальный поход к созданию верификаторов, когда существующие дедуктивные верификаторы для конкретных языков программирования нуждаются в существенном улучшении. Во-первых, предлагаемый подход является предметноориентированным, что означает, что он предоставляет средства, позволяющие в полной мере учитывать особенности целевых языков программирования и используемых методов и техник дедуктивной верификации. Вовторых, технология быстрой предметно-ориентированной разработки дедуктивных верификаторов может оказаться востребованной, когда для целевого языка не существует средств дедуктивной верификации. В-третьих,
существующие дедуктивные верификаторы представляют собой черные
ящики, что не позволяет, например, улучшить реализованную аксиоматическую семантику или стратегию ее применения или скомбинировать операционный, аксиоматический и дедуктивный подходы при генерации условий
корректности. В-четвертых, подход может быть применен для апробации
новых методов дедуктивной верификации специалистами в этой области.
В-пятых, применение подхода к специально разработанным учебным языкам программирования позволяет использовать его в сфере образования.
Список литературы
1. Barnett M., Chang B.-Y.E., DeLine R., Jacobs B., Leino K.R.M. Boogie: A modular
reusable verifier for object-oriented programs // Proc. of Conf. "Formal Methods for
Components and Objects Springer-Verlaf, Berlin, LNCS. 2006. Vol. 4111. P. 364–387.
2. Filliˆtre J.-C., Paskevich A. Why3 – where programs meet provers // Proc. of the
a
22nd European Symposium on Programming, Springer-Verlaf, Berlin, LNCS. 2013.
Vol. 7792. P. 125–128.
3. Ануреев И.C. Предметно-ориентированные системы переходов: объектная модель и язык // Системная информатика. 2013. № 1. С. 1–34.
4. Ануреев И.С. Дедуктивная верификация телекоммуникационных систем, представленных на языке Си // Моделирование и анализ информационных систем.
2012. Т. 19. № 6. С. 34–44.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
77](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-77-320.jpg)
![Верификация распределенных автоматных
программ с использованием инструментального
средства Spin
М. А. Лукин, А. А. Шалыто
СПб НИУ ИТМО
lukinma@gmail.com, anatoly.shalyto@gmail.com
Аннотация. В данной статье рассмотрен комплексный подход к
разработке и верификации распределенных автоматных программ, в
которых иерархические автоматы могут реализовываться в разных
потоках и взаимодействовать друг с другом. Предложен интерактивный
подход к верификации распределенных автоматных программ при
помощи инструмента Spin, который включает в себя автоматическое
построение модели на языке Promela, приведение LTL-формулы в формат,
определяемый инструментом Spin и построение контрпримера в терминах
автоматов. На основе этого подхода создано инструментальное средство
Stater, позволяющее создавать распределенную систему конечных
автоматов, генерировать на ее основе программный код на целевых
языках программирования и верифицировать ее при помощи
верификатора Spin. Автоматы могут быть созданы в инструменте Stater, а
также импортированы из Stateflow.
Ключевые слова: верификация, системы конечных автоматов, model
checking, распределенные автоматные программы, Spin, LTL.
1
Введение
Формальные методы набирают все большую популярность при проверке
программного обеспечения. При этом они не конкурируют с традиционным
тестированием, а гармонично дополняют его. В данной работе рассматривается
верификация методом проверки моделей (model checking) [1 – 3] при помощи
верификатора Spin [4]. Метод проверки моделей характеризуется высокой
степенью автоматизации [1]. По данной теме проводятся исследования в
России и за рубежом [5 – 30]. Настоящая работа является продолжением работ
[16, 22, 26].
78
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-78-320.jpg)
![М. А. Лукин, А. А. Шалыто
2
2
Описание метода
2.1
Описание автоматной модели
В методе используется распределенная система взаимодействующих
иерархических конечных автоматов [31 – 33]. При этом каждый иерархический
автомат в системе работает в отдельном потоке. Под иерархическим автоматом
в данной работе понимается система вложенных автоматов.
При этом каждый граф переходов задает не конкретный автомат, а тип
автоматов (по аналогии с типом данных или классом в ООП). Назовем его
автоматным типом. У каждого автоматного типа может быть несколько
экземпляров (по аналогии с объектом в ООП). Назовем эти объекты
автоматными объектами. Каждый автоматный объект имеет уникальное имя.
В дальнейшем, если не указано иное, автоматные объекты будут называться
просто автоматами.
Переходы автоматов осуществляются по событиям. Также на переходе могут
быть охранные условия [34]. Однако что делать, если встретилось событие, по
которому нет перехода? Традиционно в теории языков и вычислений
детерминированный конечный автомат в таком случае переходит в
недопускающее состояние. Но такое поведение не всегда удобно.
Альтернативой переходу в недопускающее состояние может быть
игнорирование таких событий, которое реализуется как неявное добавление
пустых (без выходных воздействий) петель по всем событиям, переходы по
которым не были добавлены пользователем. Таким образом, в предлагаемом
методе автомат может работать в одном из двух режимов:
─ при появлении события, по которому нет перехода, это событие
игнорируется (добавляются пустые петли по всем событиям);
─ при появлении события, по которому нет перехода, автомат переходит в
недопускающее состояние.
Есть специальное событие «*», которое означает переход по любому
событию, кроме тех, которые есть на других переходах из этого состояния
(аналог default в блоках switch для C-подобных языков или else в условных
конструкциях).
Автомат может иметь конечное число переменных целочисленных типов
(включая массивы). Для переменных есть следующие модификаторы:
─ volatile – переменная может быть использована в любом месте программы;
─ external – переменная может быть использована другим автоматом;
─ param – переменная является параметром автомата.
По умолчанию считается, что переменная не используется нигде, кроме как
на диаграмме переходов автомата.
Все события общие для всей системы автоматов.
Выходные воздействия автомата бывают двух типов:
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
79](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-79-320.jpg)
![Верификация распределенных автоматных программ с использованием
инструментального средства Spin
3
1. На переходах и в состояниях может быть выполнен любой код. Однако
верификатор и генератор кода перенесут его без изменений, поэтому код
должен быть допустимым в целевом языке.
2. Запуск на переходах и в состояниях функций, определяемых пользователем
на целевом языке программирования (после того, как сгенерирован код).
Автомат может иметь вложенные автоматы любого типа, кроме
собственного, иначе будет бесконечная рекурсия. Циклическая рекурсия также
запрещена.
Автомат может запускать поток с новым автоматом любого типа. Задается
тип автомата <StateMachine> и имя <concreteStateMachine>. Нельзя запускать
несколько автоматов с одним именем. Нельзя запускать автоматы своего типа.
Автомат может взаимодействовать с другим автоматом, выступая
источником событий для него. Сообщения с событиями отправляются
асинхронно.
Автомат может использовать отмеченные специальным модификатором
переменные другого автомата.
Таким образом, в системе могут быть несколько автоматов с одинаковым
графом переходов, более того, часть этих автоматов могут быть вложенными, а
часть нет.
Все запреты проверяются при помощи верификации.
2.2
Описание процесса верификации
Для того чтобы провести верификацию программы методом проверки
моделей, требуется составить модель программы и формализовать требуемые
свойства (спецификацию) на языке темпоральной логики [1]. Так как в данной
работе используется верификатор Spin, то языком темпоральной логики
является LTL [1]. При этом модель автоматной программы строится
автоматически и построение модели описано в разделе «Генерация кода на
Promela».
Обозначим автоматный тип через AType, автоматный объект через aObject.
Пусть состояния AType называются s0, s1 и т. д., в автомат поступают события
e0, e1 и т. д., а переменные называются x0, x1 и т. д., внешние воздействия
второго типа z0, z1 и т. д. Пусть автоматный тип AType имеет вложенный
автомат, назовем его nested. Пусть AType запускает автомат, назовем его fork.
Процесс верификации состоит из следующих этапов:
1. Генерация кода на языке Promela [4]. В нашем случае она происходит
автоматически.
2. Преобразование LTL-формул (переход от нотации автоматной программы в
нотацию Spin).
3. Запуск верификатора Spin.
4. Преобразование контрпримера в термины исходной системы автоматов. В
нашем случае преобразование происходит автоматически.
80
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-80-320.jpg)
![6
М. А. Лукин, А. А. Шалыто
─ Все переменные автомата.
Каждый тип автоматов записывается в inline-функцию переходов, которая
моделирует один шаг автомата. Переходы записываются при помощи охранных
команд Дейкстры [34]. Эта функция в качестве параметров принимает
структуру с данными автомата и событие и имеет следующий вид (листинг 1):
Листинг 1. Функция переходов.
inline Mnemo(machine, evt)
{
atomic
{
printf("machine%d. event_happened: %d n", evt);
machine.curevent = evt;
}
if //Определение текущего состояния.
::(machine.state == AType_s0) ->
printf("machine%d.state = AType.state0 n",
machine.ID);
if //Выбор перехода.
::((evt == e1) && cond_1) ->
machine.state = AType_s1;
//Действия внутри состояния.
::((evt == e2) && cond_2) ->
machine.state = AType_s2;
//Действия внутри состояния.
//Остальные переходы.
:: else ->
//Действия в случае, если не найден переход
//по событию evt.
fi;
//Остальные состояния.
fi;
}
Функция состоит из двух условий: внешнего и внутреннего. Внешнее
условие определяет состояние, в котором находится автомат. Внутренне
условие определяет переход в следующее состояние. Каждый вариант
внутреннего условия соответствует одному из переходов из текущего состояния
автомата и состоит из двух частей: проверка события и проверка условия на
переходе. Условия на переходах в листинге 1 обозначены как cond_1, cond_2
и т. д.
Для каждого экземпляра автомата создается экземпляр структуры и канал, по
которому происходит передача событий.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
83](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-83-320.jpg)
![Верификация распределенных автоматных программ с использованием
инструментального средства Spin
7
Для каждого экземпляра автомата, кроме вложенных, создается процесс,
который извлекает из канала событие и запускает функцию переходов автомата
с этим событием.
Для каждого экземпляра автомата, кроме вложенных, создается процесс,
который недетерминированно выбирает событие и отправляет его в канал
автомата. Этот процесс эмулирует внешнюю среду. В зависимости от уровня
абстракции по источникам событий этот процесс выбирает событие из всего
списка событий (внешняя среда отправляет любые события), из списка
переходов текущего автомата (внешняя среда отправляет только те события,
которые автомат может в данный момент обработать) либо не активен и удален
из модели (внешняя среда не взаимодействует с автоматом).
Для публичных переменных перед каждым шагом автомата вызывается
специальная функция, которая эти переменные недетерминированно изменяет.
Для переменных-параметров такая функция вызывается один раз – при
запуске автомата.
Если по данному событию нет перехода, и в текущем состоянии есть
вложенный автомат, то запускается вложенный автомат (запускается
встраиваемая функция автомата).
Если в текущем состоянии автомат запускает другой автомат, то запускается
заранее созданный процесс запускаемого автомата, а также .
Если автомат отправляет сообщение с событием другому автомату, то он
записывает номер события в канал этого автомата.
Преобразование LTL-формул
Расширим нотацию LTL-формул верификатора Spin. В фигурных скобках
будем записывать высказывания в терминах рассматриваемой автоматной
модели. Добавим следующие высказывания:
1. aObject.si, которое означает, что автомат aObject перешел в состояние
si.
2. aObject.ei, которое означает, что в автомат aObject пришло событие ei.
3. aObject.zi, которое означает, что автомат aObject вызвал функцию
(внешнее воздействие) zi.
4. aObject->nested, которое означает, что в автомате aObject управление
передано вложенному автомату nested.
5. aObject || fork, которое означает, что автомат aObject запустил
автомат fork.
6. Бинарные логические операции с переменными автоматов, например,
aObject.x0 >= fork.x0[fork.x1].
Пример LTL-формулы в расширенной нотации:
[] ({aObject.x0 <= 5} U {aObject.s1})
(1)
Алгоритм преобразования формулы в нотацию Spin следующий:
1. Все высказывания в фигурных скобках перенумеровываются.
84
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-84-320.jpg)
![8
М. А. Лукин, А. А. Шалыто
2. Каждое такое высказывание преобразовывается в терминах модели на
Promela и записывается в макрос.
3. Макросы подставляются в исходную LTL-формулу.
Макросы записываются следующим образом:
1. Автомат aObject перешел в состояние si: (aObject.state == si).
2. В автомат aObject пришло событие ei: (aObject. curEvent == ei).
3. Автомат aObject вызвал функцию (внешнее воздействие) zi: (aObject.
functionCall == zi).
4. В автомате aObject управление передано вложенному автомату nested:
(aObject. nestedMachine == nested).
5. Автомат aObject запустил автомат fork: (aObject. forkMachine ==
fork).
Формула (1) будет преобразована алгоритмом в следующий вид:
#define p0 (aObject.x0 <= 5)
#define p1 (aObject.state == AType_s1)
ltl f0 {[] (p0 U p1) }}
Spin поддерживает несколько LTL-формул в одной модели, поэтому
формулы нумеруются f0, f1, и т. д.
Запуск верификатора Spin
Верификация построенной нами модели при помощи инструмента Spin
состоит из следующих этапов:
1. Построение верификатора pan. При запуске к ключом -a по модели на языке
Promela Spin генерирует верификатор pan на языке C.
2. Компиляция верификатора pan. При компиляции можно определить
константы, которые влияют на то, как в памяти будет храниться модель
Крипке [1]. Наиболее компактный вариант задается константой BITSTATE,
однако в этом случае происходит аппроксимация, и верификация может быть
не точна.
3. Запуск верификатора pan. Верификатор pan также может быть запущен с
разными ключами, важнейший из которых является –a (поиск допускающих
циклов).
4. Анализ контрпримера. Описан в разделе «Преобразование контрпримера».
Интерактивность достигается за счет предоставления пользователю
возможности использования вышеперечисленных вариантов работы на этапах
верификации.
Преобразование контрпримера
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
85](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-85-320.jpg)
![Верификация распределенных автоматных программ с использованием
инструментального средства Spin
9
Для того чтобы было удобнее понимать контрпример, приведем метод
автоматической трансляции контрпримера, который получается на выходе
верификатора Spin, в термины используемой автоматной модели.
Для каждого действия автомата создается пометка при помощи функции
printf. На языке Promela функция printf работает аналогично функции printf из
языка C [35]. Во время случайной симуляции [4] она выводит текст на экран, а во
время верификации этот текст появляется в контрпримере. Остается его считать
и вывести пользователю. Подробнее преобразование контрпримера описано в
работе [26].
Корректность построения модели
Построенная функция переходов автомата в модели на Promela соответствует
его графу переходов, так как содержит в себе ровно все его состояния и ровно
все переходы для каждого состояния. Состояние каждого автомата хранится в
его поле state, и в модели на Promela это поле не изменяется нигде, кроме
функции переходов. Поэтому, атомарные высказывания о состояниях автомата
тождественны соответствующим атомарным высказываниям в модели.
Номер события передается в функцию переходов в качестве параметра. В
функции перехода этот номер присваивается полю curEvent. Других
присваиваний полю curEvent нет. Поэтому, атомарные высказывания о
событиях, пришедших в автомат, эквивалентны соответствующим атомарным
высказываниям в модели.
Выходные воздействия второго типа перенумерованы и в момент вызова их
номер присваивается полю functionCall. Поэтому, атомарные высказывания о
выходных воздействиях второго типа эквивалентны соответствующим
атомарным высказываниям в модели.
Выходные воздействия первого типа, которые могут являться любым кодом,
записываются в модель без изменения за исключением добавления названия
структуры автомата.
Аналогично с остальными вариантами атомарных высказываний.
На основе изложенного можно сделать вывод о том, что LTL спецификация
равновыполнима на исходной системе автоматов и в модели на Promela.
2.3
Генерация программного кода
Метод разработан для объектно-ориентированных языков, но может быть
расширен и для прочих языков. Однако это выходит за рамки данного
исследования.
В отличие от таких инструментов, как Unimod [36] и Stateflow [37] в данном
подходе предлагается генерировать не самостоятельную программу, а
подпрограмму. Для объектно-ориентированных языков это набор классов,
который пользователь может включить в свою программу. Для того, чтобы
обеспечить удобство использования сгенерированного кода, делаются
следующие шаги (ограничение на размер статьи не позволяет подробно описать
алгоритмы первичной и повторной генерации кода, отметим лишь, что они
86
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-86-320.jpg)
![М. А. Лукин, А. А. Шалыто
10
используют конечные автоматы и были разработаны при помощи самого
инструментального средства Stater):
─ Для каждого автоматного типа генерируется отдельный класс в отдельном
файле. Такой класс называется автоматизированным классом [33].
─ Сгенерированный класс содержит функцию переходов для автомата,
перечисление, содержащее события, необходимые переменные для
переходов и определения функций (выходных воздействий второго типа),
в которые пользователь может дописать собственный код, и этот код не
исчезнет при повторной генерации кода.
─ В коде специальными комментариями помечаются места, которые
полностью переписываются, и в которые не следует писать
пользовательский код. Пользовательский код из остальных мест будет
полностью сохранен.
─ Если пользователь добавит новые выходные воздействия второго типа, то
их определения будут добавлены к сгенерированному коду.
─ Пользователь может задать пространство имен (или пакет в языке Java),
в котором будет находиться сгенерированный код. Если между
генерациями кода пространство имен было удалено, то оно будет
восстановлено.
─ Если пользователь добавит к автоматизированному классу наследование
от базового класса или интерфейса, то повторная генерация кода сохранит
это наследование.
─ Генерируются вспомогательные классы, включая менеджер потоков,
которые обеспечивают взаимодействие автоматов, находящихся в разных
потоках. Если многопоточность не требуется, их генерацию можно
отключить.
─ Пользователь может ввести произвольное количество автоматных
объектов, которые будут запущены при запуске менеджера потоков.
2.4
Хранение диаграмм
При совместной разработке программы несколькими разработчиками
существует проблема объединения программного кода, когда один файл
редактируется несколькими разработчиками одновременно. Для обычных
программ эта проблема решается при помощи систем контроля версий
(SVN [38], Git [39], Mercurial [40] и т. д.). Однако системы контроля версий
хорошо объединяют только текстовые файлы. Диаграммы графов переходов
конечных автоматов у популярных инструментов плохо приспособлены для
совместной разработки. Для того чтобы облегчить объединение диаграмм, в
данной работе предлагаются следующие свойства, которыми должен обладать
формат хранения диаграмм:
1. Формат должен быть текстовым.
2. Каждая диаграмма должна быть в отдельном файле или в отдельном
множестве файлов.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
87](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-87-320.jpg)
![Верификация распределенных автоматных программ с использованием
инструментального средства Spin
11
3. Структура диаграммы хранится в отдельных файлах от информации, которая
нужна для отображения диаграммы.
3
Описание инструментального средства Stater
Для поддержки предложенного метода было разработано инструментальное
средство Stater. Оно позволяет следующее:
─ создавать распределенную систему конечных иерархических автоматов;
─ импортировать конечные автоматы из Stateflow;
─ верифицировать созданную систему конечных автоматов при помощи
верификатора Spin;
─ генерировать программный код по созданной системе конечных
автоматов.
Инструментальное средство Stater использовалось при разработке самого
себя, а именно модулей загрузки диаграмм из файла и преобразования LTLформул, а также модуля генерации кода.
Ни предложенный метод, ни разработанное на его основе инструментальное
средство Stater не претендуют на полноту верификации систем, разработанных
в Stateflow. Это связано, в первую очередь, с тем, что спецификация к Stateflow
имеет более 1300 страниц [41].
4
Пример
Продемонстрируем работу метода на примере прототипа программы
управления гусеничным шасси для робота. В шасси два двигателя: по одному на
левую гусеницу и на правую. Прототип программы состоит из двух автоматных
типов: AEngine и AManager. Автомат manager типа AManager Два автомата left
и right типа AEngine (рис. 1) управляют соответственно левым и правым
двигателями.
88
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-88-320.jpg)
![Верификация распределенных автоматных программ с использованием
инструментального средства Spin
13
Рис. 2. Диаграмма переходов автоматного типа AManager
Проверим свойство: «В любой момент если поступила команда «стоп»,
то будет подана команда остановки левого двигателя». Мы не можем проверить,
что остановился, так как это утверждение относится к аппаратной части.
Формализуем это свойство. Высказывание «Поступила команда «стоп»
означает, что в автомат manager пришло событие stop. В нотации Stater оно
записывается следующим образом: {manager.stop}. Высказывание «подана
команда остановки левого двигателя» означает, что автомат left вызвал
функцию EngineStop. В нотации Stater оно записывается следующим образом:
{left.EngineStop}. Поэтому, свойство переписывается так: в любой
момент в автомат manager пришло событие stop, следовательно, в будущем
автомат left вызовет функцию EngineStop:
G ({manager.stop} => (F {left.EngineStop}))
(2)
В итоге получаем следующий вид:
[] ( {manager.stop} -> (<> {left.EngineStop} ))
(3)
Запускаем верификацию и получаем ответ, который означает, что свойство
выполняется в построенной системе:
0. [] ( {manager.stop} -> (<> {left.EngineStop} ))
Verification successful!
90
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-90-320.jpg)
![Проверка корректности поведения
HDL-моделей цифровой аппаратуры на основе
динамического сопоставления трасс
В.П. Иванников, А.С. Камкин, М.М. Чупилко
Федеральное государственное бюджетное учреждение науки
Институт системного программирования Российской академии наук (ИСП РАН),
109004, г. Москва, ул. Александра Солженицына, д. 25.
{ivan,kamkin,chupilko}@ispras.ru
Аннотация Проверка корректности поведения HDL-моделей является неотъемлемой частью динамической верификации аппаратуры.
Как правило, она основана на сравнении поведения HDL-модели с
поведением эталонной модели, разработанной на языке программирования. В процессе верификации на обе модели подается одна и та
же последовательность стимулов; реакции перехватываются и сравниваются друг с другом. Из-за абстрактности эталонной модели сопоставление трасс не является тривиальной задачей: порядок событий может не совпадать, а некоторые события одной трассы могут
отсутствовать в другой. В работе рассматривается метод динамического сопоставления трасс для моделей аппаратуры разного уровня
абстракции. Метод был успешно применен в нескольких промышленных проектах по верификации модулей микропроцессоров.
1
Введение
Несмотря на развитие формальных методов, динамическая верификация
остается основным методом проверки сложной цифровой аппаратуры [1].
Объектом верификации выступают не сами устройства, а их модели, разработанные на специальных языках описания аппаратуры (HDL, Hardware
Description Languages), например, на Verilog или VHDL (такие модели называются HDL-моделями) [2]. С одной стороны, HDL-модели представляют
основу для автоматизированного производства интегральных схем; с другой
стороны, это имитационные модели, поведение которых можно анализировать в специальных средах (симуляторах). Для автоматизации проверки
корректности поведения HDL-моделей разрабатываются мониторы, которые перехватывают события на входах и выходах (стимулы и реакции) и
проверяют допустимость получаемой трассы [3].
Существует множество подходов к формальному описанию поведения,
позволяющих автоматизировать создание мониторов: расширенные регулярные выражения [4], контрактные спецификации [5], системы правил [6],
94
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-94-320.jpg)
![2
Проверка корректности поведения HDL-моделей цифровой аппаратуры
темпоральные утверждения [7], однако указанные формализмы не покрывают всех потребностей индустрии. Большинство компаний, проектирующих аппаратуру, для оценки проектных решений используют исполнимые
модели, разработанные на языках программирования (прежде всего, на C и
C++) [8]. Экономически целесообразно использовать эти модели и для верификации создаваемой аппаратуры, в частности, для проверки корректности
поведения HDL-моделей.
При наличии исполнимой модели применяют следующую схему проверки корректности поведения: эталонная модель (по терминологии тестирования соответствия, спецификация) выполняется совместно с проверяемой
HDL-моделью (реализацией); на спецификацию поступает та же последовательность стимулов, что и на реализацию; реакции обеих моделей перехватываются монитором и сравниваются. Основная проблема указанной схемы
связана с обобщенным характером спецификации, из-за чего порядок реакций, выдаваемых спецификацией и реализацией, а также их состав могут
различаться. Перед тем как использовать эталонную модель для мониторинга, необходимо понять, насколько она абстрактна и насколько можно
доверять производимым ею трассам.
В работе предлагается способ построения мониторов для HDL-моделей
аппаратуры, адаптируемый для эталонных моделей разного уровня абстракции. Рассматриваемый подход может быть формализован на основе модели
частично упорядоченных мультимножеств [9]. Поведение спецификации и
реализации описывается временн´ ми трассами над общим алфавитом. Свеы
дения об абстрактности спецификации позволяют обобщать последовательности выдаваемых реакций в частично упорядоченные мультимножества,
в которых для каждой реакции задан допустимый временной интервал.
Монитор проверяет, что трасса реализации является линеаризацией обобщенной трассы спецификации (или ее подмножества) и реакции реализации
удовлетворяют ограничениям, заданными временными интервалами.
´
Оставшаяся часть статьи организована следующим образом. В разделе 2
вводятся основные понятия и обозначения. Раздел 3 описывает предлагаемый метод динамического сопоставления трасс: в этом разделе определяется
отношение соответствия между реализацией и спецификацией и рассматривается устройство монитора, проверяющего соответствие. В разделе 4 описывается опыт использования предлагаемого подхода для верификации модулей микропроцессоров. Раздел 5 содержит краткий обзор работ близких
к нашей. В разделе 6 дается заключение и указываются направления дальнейших исследований.
2
Основные понятия и обозначения
В дальнейшем будем использовать следующие обозначения: Σ — конечный
алфавит событий, T — временн´я область (для определенности, N). Поа
следовательности событий называются словами. Σ ∗ обозначает множество
всех (конечных) слов над алфавитом Σ. Если u и v — два слова над одним
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
95](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-95-320.jpg)
![Проверка корректности поведения HDL-моделей цифровой аппаратуры
3
алфавитом и u конечно, то uv обозначает их конкатенацию. Для w = uv
говорят, что w является продолжением u с помощью v.
В контексте динамической верификации HDL-моделей удобно структурировать алфавит событий, разбив его на два множества: множество входных событий (стимулов) I и множество выходных событий (реакций) O,
а также сопоставив каждому событию его порт: port : Σ → {1, 2, ..., k}.
На содержательном уровне стимул представляет собой посылку запроса к
устройству, а реакция — выдачу ответа. При этом события на разных портах
могут происходить параллельно.
Определение 1 (Временн´е слово [10]) Временн´ м словом (timed word)
о
ы
w над алфавитом Σ и временн´й областью T называется последовательо
ы
ность (a0 , t0 )(a1 , t1 )... временн´ х событий (ai , ti ) ∈ Σ × T, удовлетворяющая следующим ограничениям:
1. для каждого i ≥ 0 выполняется неравенство ti ≤ ti+1 ;
2. для любого T ∈ T найдется i ≥ 0, такой что ti > T (если w бесконечна);
3. для всех i, j ≥ 0, таких что i = j и ti = tj , port(ei ) = port(ej ).
В параллельных системах, к которым относится аппаратура, используется концепция независимости событий: два события считаются независимыми, если между ними нет причинно-следственной связи (для таких событий не накладываются ограничения на их относительный порядок). Эта
идея лежит в основе двух формальных моделей параллельных вычислений:
(1) трасс Мазуркевича (Mazurkiewicz) [11] и (2) частично упорядоченных
мультимножеств [9]. В настоящей статье мы будем придерживаться более
общей второй модели.
Определение 2 (Частично упорядоченное мультимножество [9]) Σразмеченным частичным порядком называется кортеж V, , λ , где V —
конечное множество вершин и λ : V → Σ — функция разметки. Два Σразмеченных частичных порядка называются эквивалентными, если они
изоморфны относительно
и λ (совпадают или отличаются названием
вершин). Частично упорядоченным мультимножеством (pomset, partially
ordered multiset) над алфавитом Σ называется класс эквивалентности Σразмеченных частичных порядков.
Для удобства мы будем использовать конкретного представителя (конкретный размеченный частичный порядок) для обозначения частично упорядоченного мультимножества. Линеаризацией частично упорядоченного мультимножества V, , λ называется размеченный полный порядок V, ≤, λ ,
где ⊆≤.
Определение 3 (Временн´я трасса [12]) Временн´й трассой над алфаа
о
витом Σ и временн´й областью T называется четверка V, , λ, θ , где
о
V, , λ — частично упорядоченное мультимножество, а θ : V → T —
функция времени, удовлетворяющая следующим условиям:
96
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-96-320.jpg)
![4
Проверка корректности поведения HDL-моделей цифровой аппаратуры
1. для всех x, y ∈ V , из x y вытекает θ(x) < θ(y);
2. для любого t ∈ T существует срез C ⊆ V , такой что minx∈C {θ(x)} ≥ t
(если V бесконечно).
Множество всех трасс над алфавитом Σ и временн´й областью T обознао
´
чается Mθ (Σ, T). Заметим, что временные слова являются частным случаем
временных трасс. Для заданной непустой трассы σ = V, , λ, θ введем обо´
значения: begin(σ) = minx∈V {θ(x)} и end(σ) = maxx∈V {θ(x)} (если σ бесконечна, end(σ) = ∞); σ[t,t+∆t] — подтрасса трассы σ, состоящая из тех x ∈ V ,
для которых θ(x) ∈ [t, t + ∆t]. Пусть TI(T) — множество временных интер´
валов во временн´й области T (то есть TI(T) = {[t, t + ∆t] | t, t + ∆t ∈ T}).
о
Определение 4 (Интервальная трасса) Интервальной трассой над алфавитом Σ и временн´й областью T называется четверка σ = V, , λ, δ ,
о
где V, , λ — частично упорядоченное мультимножество, а δ : V →
TI(T) — функция, ассоциирующая с каждой вершиной временной интервал. Языком интервальной трассы σ является множество L(σ) = { V,
, λ, θ ∈ Mθ (Σ, T) | ∀x ∈ V . θ(x) ∈ δ(x)}.
Множество всех интервальных трасс над алфавитом Σ и временн´й облао
стью T обозначается Mδ (Σ, T). В дальнейшем мы будем иметь дело с парами
а
трасс σθ , σδ , где σθ — временн´я трасса, а σδ — интервальная трасса, такие что σθ ∈ L(σδ ). Каждая такая пара описывается пятеркой V, , λ, θ, δ
и называется расширенной интервальной трассой. Множество всех расширенных интервальных трасс обозначается Mθδ (Σ, T).
3
Динамическая верификация на основе исполнимых
моделей
Временн´е слово (временн´я трасса с тривиальным частичным порядком)
о
а
описывает конкретное выполнение HDL-модели (реализации), в то время
как расширенная интервальная трасса описывает поведение эталонной модели (спецификации). Наша цель — проверить в динамике (on-the-fly), что
трасса реализации wI ∈ (Σ × T)∗ соответствует трассе спецификации σS ∈
Mθδ (Σ, T). Поясним, откуда берется расширенная интервальная трасса σS . В
процессе выполнения спецификация порождает конкретную трассу wS , описываемую временным словом. Прямое сравнение двух временных слов, wI и
´
´
wS , на равенство возможно только для потактово точной спецификации.
Как правило, спецификация абстрактнее реализации, особенно в отношении временных свойств. Сведения о степени абстрактности спецификации
´
позволяют обобщить конкретное временн´е слово wS до расширенной ино
тервальной трассы σS , смягчая тем самым проверку соответствия между
реализацией и спецификацией (см. Рисунок 1).
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
97](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-97-320.jpg)
![Проверка корректности поведения HDL-моделей цифровой аппаратуры
5
Рис. 1. Схема проверки соответствия между реализацией и спецификацией
3.1
Отношение соответствия
В дальнейшем мы будем называть трассы с тривиальным частичным порядком (порядком, заданным отношением равенства) трассами выполнения. Если Σ = I ∪ O, то трассы выполнения над алфавитом I будем называть входными последовательностями, а трассы выполнения над алфавитом O — выходными последовательностями. Отметим, что тривиальный
частичный порядок в трассах выполнения отражает тот факт, что реализация рассматривается как “черный ящик”, и причинно-следственные связи
между ее событиями если и известны, то не от самой реализации. Множества входных и выходных последовательностей обозначаются Iθ (Σ, T) и
Oθ (Σ, T) соответственно. Для краткости будем использовать сокрашенные
обозначения: I = Iθ (Σ, T) и O = Oθ (Σ, T).
Определение 5 (Поведение) Детерминированным поведением над алфавитом Σ = I ∪ O и временн´й областью T называется (частичное) отобо
ражение B : I × T → O, удовлетворяющее следующим ограничениям:
- для всех w ∈ I и t ∈ T выполняется неравенство end B(w, t) ≤ t;
- для всех w ∈ I и t ∈ T справедливо равенство B(w, t) = B(w[0,t] , t);
- для всех w ∈ I и t ∈ T существует wv ∈ I, продолжение w, и ∆t ≥ 0,
такие что end B(wv, t + ∆t) ≥ t.
Поведение описывает, каким образом входная последовательность преобразуется в выходную последовательность, принимая во внимание момент
времени, в которое производится наблюдение. Предположим, что у нас есть
исполнимая спецификация. Рассмотрим, как ее можно использовать для
динамической проверки поведения реализации. Расширим определение поведения, позволив спецификации возвращать расширенные интервальные
трассы, а не конкретные последовательности, как это требуется. Обозначим
множество всех таких трасс символом Oθδ .
Для заданной выходной трассы V, , λ, θ, δ ∈ Oθδ , определим две функции, ∆t± , такие что для всех x ∈ V , δ(x) = [θ(x)−∆t− (x), θ(x)+∆t+ (x)]. Будем полагать, что функции ∆t± ограничены (существуют константы ∆T ± >
0, такие что |∆t± (x)| ≤ ∆T ± для всех x ∈ V ). Также положим, что значения
98
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-98-320.jpg)
![6
Проверка корректности поведения HDL-моделей цифровой аппаратуры
∆t± (x) зависят от события, а не от вершины: ∆t± (x) = ∆t± (λ(x)). Пусть
I и S — поведение реализации и поведение спецификации соответственно.
Для заданной входной последовательности w ∈ I и момента времени t ∈ T
рассмотрим выход реализации и спецификации: I(w, t) = VI , ∅, λI , θI и
S(w, t) = VS , S , λS , θS , δS . Введем обозначения:
past∆t (w, t) = {y ∈ I(w, t) | θI (y) ≤ t − ∆t− (y) };
I
pastI (w, t) = {y ∈ I(w, t) | θI (y) ≤ t};
past∆t (w, t) = {x ∈ S(w, t) | θS (x) ≤ t − ∆t+ (x) };
S
pastS (w, t) = {x ∈ S(w, t) | θS (x) ≤ t};
match(x, y) = λI (y) = λS (x) ∧ θI (y) ∈ δS (x) .
Определение 6 (Отношение соответствия) Говорят, что поведение реализации I соответствует поведению спецификации S, если domI = domS
и для всех w ∈ domS и t ∈ T существует бинарное отношение M(w, t) ⊆
{(x, y) ∈ pastS (w, t)×pastI (w, t) | match(x, y)} (называемое сопоставлением),
такое что:
1. M(w, t) взаимно однозначно;
2. для каждой реакции спецификации x ∈ past∆t (w, t) существует реакция
S
реализации y ∈ pastI (w, t), такая что (x, y) ∈ M(w, t);
3. для каждой реакции реализации y ∈ past∆t (w, t) существует реакция
I
спецификации x ∈ pastS (w, t), такая что (x, y) ∈ M(w, t);
4. для всех (x, y), (x , y ) ∈ M(w, t) если x x , то θI (y) ≤ θI (y ).
Если для некоторых w ∈ I и t ∈ T вышеуказанные свойства нарушаются, то говорят, что I не соответствует S, при этом w[0,t] называется
контрпримером.
Рисунок 2 иллюстрирует определение отношения соответствия для некоторой входной последовательности (будучи неважной, она на рисунке не
показана) и момента времени (t = 4). Верхняя часть рисунка показывает
реакции реализации (черные кружки с белыми надписями: b, a и c), нижняя — реакции спецификации (белые кружки с черными надписями: a, b, c
и d). Будем обозначать вершины трассы (собственно, кружки) символами
yb , ya и yc (для реализации) и xa , xb , xc и xd (для спецификации). Между
вершинами реализационной трассы нет причинно-следственных связей. Вершины спецификационной трассы частично упорядочены (предшествование
xc , xb
xc , xa
xd и xb
xd ) и пособытий показано стрелками: xa
мечены временными интервалами (δ(xa ) = [0, 2], δ(xb ) = [1, 3], δ(xc ) = [0, 4]
´
и δ(xd ) = [1, 5]). Сопоставление реакций отмечено пунктирными линиями
((xa , ya ), (xb , yb ) и (xc , yc )). Легко видеть, что изображенное отношение является сопоставлением (в смысле данного выше определения): (1) оно взаимно однозначно; (2 и 3) оно включает все реакции с истекшим “времеxc и
нем жизни”; (4) оно сохраняет спецификационный порядок: (a) xa
θ(ya ) = 2 ≤ 3 = θ(yc ); (b) xb xc и θ(yb ) = 1 ≤ 3 = θ(yc ). Безусловно, каждая пара этого отношения удовлетворяет условию сопоставления реакций:
(a) λ(xa ) = λ(ya ) = a и θ(ya ) = 2 ∈ [0, 2] = δ(xa ); (b) λ(xb ) = λ(yb ) = b и
θ(yb ) = 1 ∈ [1, 3] = δ(xb ); (c) λ(xc ) = λ(yc ) = c и θ(yc ) = 3 ∈ [0, 4] = δ(xc ).
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
99](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-99-320.jpg)
![Проверка корректности поведения HDL-моделей цифровой аппаратуры
7
Рис. 2. Соответствие между реализацией и спецификацией
3.2
Динамическое сопоставление трасс
Монитор, осуществляющий сопоставление трасс реализации и спецификации, может быть представлен как временной автомат [10] с двумя типами
входных портов: (1) порты для получения спецификационных реакций и (2)
порты для получения реализационных реакций. Когда автомат обнаруживает расхождение в трассах реализации и спецификации, он переходит в
определенное состояние, информируя, тем самым, что реализация не соответствует спецификации.
Ниже представлено формальное описание монитора в виде системы действий с условиями (guarded actions). Каждое действие атомарно и выполняется, как только соответствующее условие становится истинным. Действия
и условия зависят от внешней переменной t, отражающей текущее время, и
реакций, выдаваемых реализацией и спецификацией в ответ на одну и ту же
последовательность стимулов (S и I соответственно). Значение t монотонно возрастает в процессе верификации. Запись y ∈ I[t] (x ∈ S[t]) означает,
что в момент времени t реализация (спецификация) выдает реакцию y (x).
Описание базируется на двух функциях: (1) первичный арбитр (arbiterS ) и
(2) вторичный арбитр (arbiterI ), определенных ниже:
arbiterS (X) =
arbiterI (y, X) =
100
min (X)
φ
arg minx∈X.match(x,y) {θS (x)}
φ
если X = ∅,
иначе (φ ∈ Σ);
/
если ∃x ∈ X . match(x, y),
иначе.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-100-320.jpg)
![8
Проверка корректности поведения HDL-моделей цифровой аппаратуры
Действие 1 onSpecOut[x], x ∈ S[t]
Если: true
Вход: x
pastS ⇐ pastS ∪ {x}
if x ∈ arbiterS (pastS ) then
for all y ∈ pastI [↑ θI (y)] do
if x = arbiterI (y, {x}) then
pastS ⇐ pastS {x}
pastI ⇐ pastI {y}
match ⇐ match ∪ { x, y }
break
end if
end for
end if
Действие 2 onImplOut[y], y ∈ I[t]
Если: true
Вход: y
pastI ⇐ pastI ∪ {y}
x ⇐ arbiterI (y, arbiterS (pastS ))
if x = φ then
pastS ⇐ pastS {x}
pastI ⇐ pastI {y}
match ⇐ match ∪ { x, y }
end if
Действие 3 onSpecT ime[x], x ∈ pastS Действие 4 onImplT ime[y], y ∈ pastI
`
´
Если: θS (x) + ∆t+ (x) ≤ t
Вход: x
pastS ⇐ pastS {x}
verdict ⇐ f alse‘
trace(“Missing output”)
terminate
`
´
Если: θI (y) + ∆t− (y) ≤ t
Вход: y
pastI ⇐ pastI {y}
verdict ⇐ f alse
trace(“Unexpected output”)
terminate
Действие 5 onInitialize
Действие 6 onF inalize
Если: t = 0
Вход: ∅
pastS ⇐ ∅
pastI ⇐ ∅
match ⇐ ∅
Если: `
´
max end(S)+∆T + , end(I)+∆T − ≤ t
Вход: ∅
verdict ⇐ true
terminate
Ниже приведен порядок проверки условий и запуска действий внутри
одного временн´го слота t (при несоблюдении этого порядка возможны ложо
ные сообщения об ошибках):
1.
2.
3.
4.
инициализация (onInitialize);
прием реакции (onSpecOut, onImplOut);
превышение лимита времени (onSpecT ime, onImplT ime);
завершение (onF inalize).
Когда говорят, что некоторое свойство ϕ выполняется в момент времени
t, имеется в виду, что ϕ выполняется после завершения всех действий, активированных в момент t. Для многопортовых систем (что типично для
аппаратуры) монитор можно разбить на слабо связанные компоненты, параллельно обслуживающие отдельные порты.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
101](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-101-320.jpg)
![Проверка корректности поведения HDL-моделей цифровой аппаратуры
9
Утверждение 1 (Корректность) Входная последовательность является контрпримером тогда и только тогда, когда монитор завершается с
verdict = f alse.
На практике встречается аппаратура, в которой операции в некоторых
ситуациях отменяют другие операции (конфликтующие с ними и имеющие более низкий приоритет). Например, операция записи может быть отменена другой операцией записи, адресующейся к той же ячейке памяти
и запущенной сразу после рассматриваемой операции. Из-за абстрактности спецификации в ее терминах не всегда возможно выразить условия,
при которых происходит отмена операций и соответствующие реакции не
посылаются наружу. Принимая во внимание вышесказанное, определение
спецификационного поведения может быть расширено: каждая спецификационная реакция дополнительно помечается признаком возможной отмены.
Предложенный подход к организации мониторов может быть перенесен и
на этот случай. Следует, однако, учесть, что если некоторое событие отменяется, то также отменяются все зависимые от него события.
4
Инструментальная поддержка и опыт применения
Предложенный метод к проверке корректности поведения HDL-моделей был
реализован в инструменте C++TESK [13]. Библиотека инструмента содержит классы и макросы для создания компонентов систем динамической верификации аппаратуры (эталонных моделей, мониторов, генераторов стимулов и других). Возможности C++TESK для разработки эталонных моделей аппаратуры (и, соответственно, мониторов) включают средства для
посылки и приема пакетов данных (примитивы send и receive), ветвления
и объединения параллельных процессов (f ork и join), моделирования временных задержек (delay) и задания зависимостей между пакетами (depends).
´
Инструмент позволяет создавать модели аппаратуры на разных уровнях абстракции (относительно точности моделирования времени): (1) модели без учета времени (описывающие общие причинно-следственные связи
между пакетами данных без моделирования временных задержек между
´
ними: ∆t± = ∞), (2) модели с приближенным учетом времени (частично
специфицирующие внутренние схемы арбитража пакетов, но учитывающие
время лишь примерно: ∆t± ≤ T , где T имеет значение нескольких десятков
тактов) и (3) потактовые модели (реализующие точное или почти точное
моделирование времени: ∆t± ≤ 1).
Инструмент C++TESK был использован для динамической верификации модулей промышленных микропроцессоров, разрабатываемых в НИИСИ РАН и ЗАО “МЦСТ”. Наш опыт уже был представлен в [14], но с тех
пор он был расширен. Последняя информацию о применении инструмента и заложенного в нем метода представлена в Таблице 1. Как видно из
таблицы, подход поддерживает верификацию как с помощью абстрактных
эталонных моделей (доступных на ранних стадиях проектирования), так и
102
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-102-320.jpg)
![10
Проверка корректности поведения HDL-моделей цифровой аппаратуры
с помощью потактово точных моделей (доступных на заключительных этапах). Что важно, подход позволяет использовать для верификации C++модели, изначально создаваемые для других целей (в частности, компоненты системного симулятора микропроцессора). Таким способом, например,
был проверен модуль поиска по таблице страниц.
Название модуля
Стадия разработки
Точность моделирования
от
до
Буфер трансляции адресов
Поздняя / завершающая
Приближенная
Потактовая
Модуль арифметики (FPU)
Поздняя / завершающая
Без учета времени —
Кэш-память 2-ого уровня (L2)
Промежуточная / поздняя
Приближенная
Коммутатор северного моста
Промежуточная / завершающая Прилиженная
Модуль доступа к памяти
Ранняя / промежуточная
Без учета времени Потактовая
Контроллер прерываний
Ранняя / промежуточная
Без учета времени Приближенная
Модуль поиска по таблице страниц
Поздняя
Приближенная
—
Контроллер банка кэш-памяти L2
Поздняя
Потактовая
—
Буфер команд
Поздняя / завершающая
Потактовая
—
Кэш-память 3-его уровня (L3)
Промежуточная
Приближенная
—
—
Потактовая
Таблица 1. Опыт применения предложенного метода
5
Обзор существующих работ
В работе [15] используется модель автомата с частично упорядоченными входными/выходными событиями (POIOA, Partial Order Input/Output
Automaton) для представления поведения спецификации и реализации. В
статье предлагается метод построения тестового набора, гарантирующего
обнаружение ошибок определенного типа. Если (1) реализация сообщает о
приеме неподдерживаемых стимулов, (2) можно установить порядок выдачи реакций, (3) время ответа реализации ограничено, и (4) каждый единичный переход в спецификации соответствует единичному переходу в реализации, можно определить соответствие между реализацией и спецификацией.
Реализация соответствует спецификации, если она принимает допускаемые
спецификацией стимулы и выдает описываемые спецификацией реакции в
допустимом порядке. Определение отношения соответствия, данное в этой
статье, близко к используемому нами. Главными отличиями нашего подхода являются поддержка необязательных реакций и контроль временных
´
интервалов.
Статья [16] описывает подход к проверке поведения временных систем,
´
основанный на инвариантах трассы. Рассматриваются два типа инварианМеждународная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
103](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-103-320.jpg)
![Проверка корректности поведения HDL-моделей цифровой аппаратуры
11
тов: (1) инварианты ожидания, выражающие то свойство, что после заданной трассы всегда ожидается определенное событие (в определенном временн´м интервале) и (2) инварианты наблюдения, утверждающие, что межо
ду двумя заданными событиями всегда наблюдается определенная последовательность событий. Корректность поведения реализации проверяется в
два этапа: (1) проверка соответствия инвариантов спецификации, выраженной в форме временного конечного автомата (TFSM, Timed Finite State
Machine); (2) проверка выполнимости инвариантов для трассы реализации.
Подход представляет теоретический интерес, однако его промышленное использование может быть затруднено необходимостью постоянного согласования проверяемых инвариантов со спецификацией.
В работе [17] рассматривается метод тестирования параллельных систем
с помощью неявно заданных асинхронных конечных автоматов (AFSM,
Asynchronous Finite State Machines). Поведение реализации проверяется только в стационарных состояниях, в которых не ожидается выдача реакций.
Используется следующая процедура: (1) собираются все события и определяется их частичный порядок; (2) строятся и проверяются все возможные
линеаризации множества событий (проверка базируется на пред- и постусловиях, определенных для каждого события). Считается, что реализация
соответствует спецификации, если допускается хотя бы одна из построенных линеаризаций. Применение подхода возможно только для ограниченного класса входных последовательностей: требуется, чтобы регулярно возникали стационарные состояния. В нашем случае такого ограничения нет.
6
Заключение
Работа сфокусирована на использовании исполнимых моделей для динамической верификации HDL-моделей. Проблема не так проста, как кажется
на первый взгляд. Проверка того, что реализация и спецификация выдают
одинаковые реакции в одинаковые моменты времени в большинстве случаев
не является адекватной. Спецификация в силу своей абстрактности может
не учитывать многих особенностей реализации, таких как упорядочивание
событий и их распределение во времени. В работе предложены механизмы,
позволяющие настраивать точность проверки поведения, учитывая степень
абстрактности спецификации. К ним относятся: (1) описание отношения зависимости событий, (2) расширение временных меток событий до временных
´
´
интервалов и (3) пометка некоторых событий как необязательных. Основываясь на предложенных механизмах, разработан метод проверки поведения
HDL-моделей. Метод был реализован в инструменте C++TESK и применялся в более чем 10 проектах по верификации модулей микропроцессоров.
Наши дальнейшие исследования связаны с диагностикой ошибочного поведения HDL-моделей на основе более глубокого анализа трасс, выполняемого
после сеанса верификации. Целью такого анализа является упрощение локализации ошибок путем определения характера расхождений наблюдаемого
поведения HDL-модели от эталонного.
104
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-104-320.jpg)
![Использование контрольных точек для
верификации SystemC-программ
А.А. Шипин, В.А. Соколов? , Д.Ю. Чалый??
Ярославский государственный университет
150000, Ярославль, Советская, 14
andrey.shipin@gmail.com, valery-sokolov@yandex.ru, chaly@uniyar.ac.ru
Аннотация Верификатор, работающий с использованием метода
проверки модели (model checking), должен иметь возможность обхода множества достижимых состояний системы. Для SystemC-моделей
генерация этого множества является нетривиальной задачей, так как
SystemC представляет собой набор классов, расширяющих язык C++.
В результате SystemC-модель системы компилируется в виде исполняемого файла, который позволяет проводить только имитационное
моделирование или тестирование. В работе представлен подход, основанный на использовании контрольных точек, реализующий исчерпывающее построение множества достижимых состояний моделируемой системы.
Keywords: SystemC, model checking, верификация, контрольная точка
1
Введение
SystemC (IEEE Standard 1666-2005) [4,10] открытый промышленный язык
для проектирования и верификации моделей системного уровня, реализованный в виде C++-библиотеки с открытым исходным кодом. Основной
областью применения языка являются встраиваемые системы, системы на
кристалле, где важной является задача обеспечения корректной работы. В
библиотеку включено ядро моделирования событий, что позволяет получить
исполняемую модель устройства, а при разработке можно использовать все
средства языка C/C++.
Модель на языке SystemC это набор компонентов и соединений между ними. Многие компоненты аппаратного обеспечения, такие как, например, модули, каналы, сигналы, порты, имеют соответствующие аналоги в
SystemC. Язык применяется в основном для построения транзакционных и
поведенческих моделей. Поведенческая модель описывает взаимодействие
?
??
106
работа поддержана грантом РФФИ, проект 11-07-00549-а
работа поддержана программой ФЦП ⌧Научные и научно-педагогические кадры инновационной России� на 2009–2013 годы, соглашение №14.B37.21.0392 от
06.08.2012
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-106-320.jpg)
![2
компонент системы между собой, информационные процессы в системе, поведение системы. Если функциональная модель позволяет ответить на вопрос что делает система?, то поведенческая модель отвечает на вопрос
как система это делает?. В ней фигурируют такие категории как состояние системы, события, переход из одного состояния в другое, условия перехода, последовательность событий.
Моделирование на уровне транзакций это подход к моделированию
систем, в котором детали связи между модулями отделены от деталей реализации модулей. Механизмы связи моделируются в виде каналов, и используются модулями с помощью специальных интерфейсов. Запрос транзакции
начинается с вызова функции интерфейса этих каналов, которая заключает
в себе детали обмена информацией. На уровне транзакций обмен информацией более выразителен и понятен [4].
К основным расширениям SystemC, отсутствующим в C++, относятся:
понятие модельного времени; возможности описания параллельно выполняющихся вычислений; дополнительные типы данных, отражающие специфику проектирования аппаратуры.
SystemC был разработан для достижения возможности использовать единый язык программирования с общим окружением для описания системы от
самых высокоуровневых моделей на C++ до структурных синтезируемых
моделей уровня RTL (Register Transfer Level). Это позволяет постепенно
детализировать описание системы в процессе проектирования. С помощью
SystemC можно добиться модели взаимодействия программной и аппаратной частей системы, как если бы это было реальное устройство, но на высоком уровне абстракции. За счет этого можно выявить многие проблемы на
ранних стадиях разработки [10].
В [21] отмечается, что средства верификации SystemC-моделей находятся в зачаточном состоянии. Стандартная поставка позволяет лишь проводить имитационное моделирование и тестирование. Там же, в [21], ставится
задача разработки средств верификации, в частности таких, которые исчерпывающе исследуют множество достижимых состояний модели.
2
Обзор существующих подходов к верификации
SystemC-моделей
Основными методами верификации систем являются имитационное моделирование, тестирование, дедуктивный анализ и проверка модели [1].
Обычно SystemC-модели верифицируются с помощью тестирования. Проверяемая модель выполняется в рамках заранее подготовленных сценариев. Тестирование сопровождается созданием контролируемой среды модели,
обеспечивающей получение результатов ее работы и измерение различных
характеристик, а также оценка этих результатов и характеристик [1].
Испытательный стенд (test bench) это среда, используемая для проверки свойств или проверки на безошибочность системы или ее модели.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
107](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-107-320.jpg)
![3
Стенды, разрабатывающиеся для SystemC-моделей, как правило, содержат проверяемую систему (device under test тестируемое устройство), связующие элементы и элементы, необходимые для проверки (тесты). В таких
стендах могут использоваться специальные высокоуровневые модели, предназначенные для различных целей: генерации входных сигналов, постобработки данных, создания эталонных моделей, схем обеспечения безопасности
(верификаторов свойств, мониторов, наблюдателей) [10]. Создание хороших
стендов довольно трудоемкий процесс, требующий хорошего знания C++.
Для верификации SystemC-моделей предусмотрена специальная библиотека SCV (SystemC Verification Library). SCV предоставляет средства, помогающие разработчику эффективно проводить комплексные испытания системы [19]. С помощью SCV создаются испытательные стенды и случайным
образом генерируются тесты, которые используются средой в качестве входных данных. Существуют разные виды и приемы генерации тестов.
Архитектурой модели назовем набор компонентов и соединение между
ними, а также механизмы синхронизации и коммуникации, такие как, например, события, сигналы, запись в порты и чтение из них.
Лучшие верификаторы SystemC на данный момент переводят код на
SystemC в формальную модель с помощью предварительных обработчиков
(front-end). Они формализуют семантику языка так, чтобы можно было использовать полученный код как входную информацию для верификаторов.
Так как SystemC является библиотекой C++, все особенности C++ должны поддерживаться предварительным обработчиком. Этого можно достичь,
написав свой парсер, удовлетворяющий этим условиям, либо использовать
существующий предварительный обработчик для C++ (GCC, LLVM, EDG
и т.д.). Обычный предварительный обработчик C++ не в состоянии уловить
специфику языка SystemC, поэтому предварительные обработчики SystemC
должны уметь определять специфичные конструкции языка и помечать их
в промежуточном представлении особым образом.
В случае создания предварительного обработчика со своим парсером
SystemC воспринимается как язык программирования, а не библиотека для
C++. Создание полноценного парсера является сложной задачей, поэтому, как правило, не все конструкции C++ поддерживаются такими предварительными обработчиками. Представителями такого подхода являются:
ParSyc [9], KaSCPar [11], sc2v [8], BSSC based [17], SystemPerl [20].
К проектам, использующим существующие предварительные обработчики C++, относятся: SystemCXML [3], Quiny [18], Pinapa [15], PinaVM [13],
Scoot [5], Dust [12], SystemCASS [7].
Предварительные обработчики для SystemC делятся на статические, динамические и гибридные.
Статический анализ позволяет распознавать конструкции языка. Статическим анализом кода можно построить архитектуру модели, но статический анализ позволяет работать только с моделями с относительно простой
архитектурой. К проектам, основанным на статическом подходе, относятся
108
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-108-320.jpg)
![4
все проекты со своим собственным парсером языка, а также SystemCXML
и Scoot.
Динамический подход основан на выполнении откомпилированной программы, в частности на выполнении фазы разработки модели. С помощью ее
выполнения также можно получить архитектуру модели. При выполнении
программы собираются данные, которые генерируются во время выполнения. Так как некоторым инструментам требуется только архитектура, они
могут использовать динамический подход. Такие инструменты позволяют
искать информацию в архитектуре, но не знают ничего о поведении процессов. К проектам, основанным на динамическом подходе, относятся Quiny,
Dust, SystemCASS.
Перед предварительным обработчиком SystemC стоит задача построить
архитектуру системы, а также распознать происходящие в архитектуре взаимодействия между модулями и процессами. Причем необходимо организовать связь между архитектурой и этими взаимодействиями. С этой задачей
достаточно успешно справляется гибридный подход, являющийся комбинацией статического и динамического подходов.
Существуют проприетарные решения, предлагаемые компаниями Synopsys
и Semantic Designs. Эти решения основаны на статическом анализе и отлично распознают конструкции языка SystemC. Так как их разработка является
закрытой, они здесь не рассматриваются.
В [14,13] был проведен сравнительный обзор функциональности нескольких предварительных обработчиков, которые были доступны на тот момент.
Сравнение производилось на ряде тестовых примеров. В таблице 1 приведены полученные результаты, которые показывают, что на данный момент
не существует универсального средства верификации SystemC-моделей.
3
Предлагаемый подход для верификации
SystemC-моделей
Как мы уже видели, использование предварительных обработчиков не позволяет учитывать все нюансы SystemC-моделей. Это по-видимому является
врожденным недостатком всех методов, которые основаны на парсинге исходного кода SystemC-программы с целью получения формальной модели,
пригодной для верификации. Наш подход основывается на методе CMC (C
Model Checking) [16], который при помощи внесения изменений, не влияющих на семантику SystemC-программы, позволяет строить эту формальную
модель во время ее выполнения.
3.1
Метод верификации CMC
Метод CMC [16] позволяет автоматически создавать формальную модель из
C/C++ кода, которую можно верифицировать с помощью метода проверки
модели (model checking). Так как SystemC это библиотека для языка C++,
то можно использовать средства, разработанные для анализа кода на C++.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
109](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-109-320.jpg)
![8
Состояние графа должно хранить состояние всей модели, в том числе
значение времени, состояние SystemC-процессов и состояние других объектов библиотеки. Новые типы CMC сможет сохранять и восстанавливать,
потому что эти типы представляют собой обычные классы языка C++.
Во время обхода графа для рассматриваемого состояния генерируются
его состояния-потомки. В некоторых случаях генерируется только одно состояние: когда состояние системы может лишь детерминировано перейти в
другое, используя единственный доступный переход. В остальных случаях генерируется несколько состояний. Это происходит, когда CMC может
использовать более одного перехода, а именно: в случаях параллельного
выполнения SystemC-процессов, в случаях различного поведения среды модели, в случаях какого-либо иного недетерминированного поведения модели. Среда для SystemC-модели зависит от самой модели и разрабатывается
точно так же, как и в случае немодифицированного C/C++ кода.
Для нашей реализации метода CMC ключевой задачей является способ
сохранения и восстановления состояния SystemC-модели. От этого зависит
корректность работы верификатора, скорость его работыа также насколько
экономно будут расходоваться ресурсы компьютера. Для сохранения состояния программы можно использовать два способа. Первый способ предполагает сериализацию значений переменных (сохранение состояния) внутри
кода модели с последующей десериализацией (восстановление состояния).
Второй способ напротив сохраняет снимок состояния модели как программы с помощью сторонних средств.
В исходном коде SystemC существует класс sc_simcontext, отвечающий
за хранение всех объектов, использующихся в SystemC-модели. Если сохранить и восстановить объект этого класса в момент выполнения модели
перед запуском новой итерации фазы вычислений, теоретически можно достигнуть желаемого результата и добиться более быстрой работы, чем при
втором способе. Важным моментом является то, что сохранение класса по
сути является глубоким копированием: копированием объекта с выделением под него нового участка памяти, а не копированием лишь указателей на
переменные. В C++ не существует ни стандартных средств глубокого копирования, ни сторонних библиотек, которые позволили бы выполнить такую
операцию.
Другой подход к сохранению и восстановлению состояний основан на
использовании контрольных точек. Контрольная точка снимок состояния приложения, хранящий всю необходимую информацию для того, чтобы
можно было восстановить работу приложения с сохраненного состояния.
Чаще всего контрольные точки используются для резервного хранения состояний [6].
Существует ряд проектов для операционной системы Linux, позволяющих создавать контрольные точки приложений. Среди них: BLCR, DMTCP,
CRIU, Cryopid, OpenVZ. Нами был выбран DMTCP [2], так как проект стабилен и выполняет все необходимые функции. В частности, в отличие от
BLCR, DMTCP поддерживает сокеты (программный интерфейс для обес-
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
113](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-113-320.jpg)
![9
печения информационного обмена между процессами). Это важно, так как
разработанный верификатор взаимодействует с исследуемой моделью через сокеты. Программный пакет DMTCP позволяет организовать ⌧прозрачное� создание контрольных точек для многопоточных и распределенных
программ. Пакет реализован на уровне системных библиотек операционной
системы Linux и не требует модификаций ядра этой ОС. DMTCP позволяет
обеспечить формирование контрольных точек и восстановление из них для
таких программ, как: OpenMPI, MATLAB, Python, Perl. Он поддерживает
различные языки программирования, включая скриптовые языки.
Нами было разработано программное средство SCMC (SystemC Model
Checker), которое представляет собой программу, позволяющую выполнять
SystemC-модель всеми возможными способами и оповещать пользователя
о достижении определенных условий при выполнении. Она хранит граф
состояний модели и выполняет направляющую роль. Для языка SystemC
предусмотрено дополнение, необходимое для указания в модели точек, в
которых SCMC будет разветвлять выполнение модели.
После запуска SCMC происходит ожидание запуска SystemC-модели. Как
только модель запустилась, SCMC ожидает от нее сообщения чтобы начать генерировать граф достижимых состояний. Интерфейс дополнения для
SystemC-моделей содержит ряд методов, которые разработчику необходимо
внедрить в свою модель.
Метод SendCheckpointAndWait отправляет в SCMC сообщение о месте разветвления выполнения. Каждая ветвь определяется целочисленным
значением, которое возвращает метод. В зависимости от значения модель
осуществляет ту или иную работу, это настраивается вручную сразу после
вызова метода. Номер ветви лежит в диапазоне [0, N], где N максимальный номер ветви. Метод принимает аргументы: максимальный номер ветви
и аннотацию состояния модели в данный момент в виде строки, которую
пользователь формирует по своему усмотрению вручную. Состояние модели представляет из себя строку из значений переменных, совокупность
которых точно определяет состояние. Важно учесть все необходимые переменные, иначе может возникнуть ситуация, когда два разных состояния
SCMC примет за одинаковые и ошибочно отсечет целую ветку исполнения.
После сохранения состояния модель завершает работу. SCMC восстанавливает новое состояние из очереди.
SendAssertMessage отправляет в SCMC сообщение о выполнении свойства. Аргументом метода является сопутствующее сообщение, которое будет
выведено в файле с результатами.
SendExitMessage отправляет в SCMC сообщение о завершении работы
модели.Этот метод может быть вызван в конце работы модели, чтобы SCMC
мог перейти к рассмотрению следующего в очереди состояния.
Для сохранения и восстановления состояния модели используется DMTCP.
Физически на жесткий диск состояние сохраняется в момент отправления
сообщения о месте разветвления, причем для всего набора добавляемых со-
114
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-114-320.jpg)
![При этом одним из путей снижения трудовых и финансовых затрат на
верификацию может быть интеграция различных подходов и методов,
позволяющих использовать одни и те же инструменты и исходные
формализованные описания (input) для возможно большего числа задач. В
статье излагается возможный интеграционный подход.
2. Унифицирующие свойства моделей цифровых систем
С точки зрения унификации подходов к различным задачам
верификации для нас представляют интерес два способа описания систем на
высоком уровне абстракции, для которых в литературе используют одну и ту же
аббревиатуру, но разные названия и смысл, а именно Abstract State Machine [1,2]
и Algorithmic State Machine [3]. Для удобства изложения мы будем использовать
AbSM в первом случае и ASM во втором.
Abstract State Machine, рассматриваемая в настоящее время как
унифицированная модель вычислений, представляет собой систему переходов,
реализующих конечное множество т.н. правил переходов (transition rules) вида
if Condition then Updates, где Condition - некоторый предикат на указанном
множестве, Updates - конечное множество операторов (assignments) вида f (t1, .
. . , tn) := t, чье выполнение приводит к параллельному изменению значений
аргументов функции f и получению ее значения на данном измененном наборе
аргументов. Благодаря тому, что AbSM позволяет описывать изменения
(переходы) абстрактных данных для произвольных множеств и функций, они
могут быть использованы на различных иерархических уровнях описания
проектируемой системы, что соответствует различным этапам проектирования.
Ввиду возможности задания времени переходов [4], данная модель может быть
использована как для функциональной спецификации, так и для получения
временных
характеристик
выполнения
задач,
т.е.
для
анализа
производительности. Это, очевидно, означает, что AbSM можно рассматривать
как соответствующее средство интеграции различных задач проектирования.
Однако указанная абстрактность означает необходимость использовать
различные конверторы данных для перехода с уровня на уровень. Поэтому в
наших работах мы использовали также другой формализм, основанный на
“алгоритмических машинах состояний” (ASM) [3]. В самом общем виде ASM
можно определить как направленный связанный граф, вершины которого
соответствуют операциям, выполняемым на каждом шаге описываемого
алгоритма, или условным переходам, а дуги задают последовательности
выполнения операций. Пример и все необходимые пояснения приводятся в
разделе 3.2. Подробное описание можно найти в [5].
Предложенная нами унификация спецификаций различных аспектов
функционирования цифровой системы основана на использовании ASMспецификаций, по которым выполняется высокоуровневый синтез цифровых
схем, для более широкого круга задач проектирования. Например, такая
спецификация может быть использована для формальной верификации
функциональной корректности, для оценки временной корректности на уровне
взаимодействий
и
протоколов,
для
оценки
помехоустойчивости
разрабатываемых архитектур. Показано, что ASM-спецификация, при
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
119](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-119-320.jpg)
![использовании разработанных в ИПИРАН программ генерации SMV и Spinкодов и программ моделирования цепей Маркова [7], может выполнять
интегрирующую (унифицирующую) функцию при высокоуровневом синтезе
[7]. Программы SMV (Symbolic Model Verifier) [18] и Spin [19] предназначены
для верификации проектов методом Model Checking аппаратных (SMV) и
программных (Spin) систем.
Эта возможность обеспечивается тем, что для обоих классов задач
верификации (функциональной и отказоустойчивости) используются одни и те
же автоматные модели [7]. Существенным является также то, что при
использовании для трансляции ASM-диаграмм программы синтеза цифровых
систем Abelite [3] мы получаем структуру Крипке [5], позволяющую перебирать
все возможные варианты работы верифицируемой системы, т.е. описывать
недетерминированность ее поведения. Получаемое из ASM автоматное
представление моделируемой системы выглядит следующим образом:
{ am, fms(xi1,,…,xik), as, Y},
(1)
где am, as - текущее и следующее состояние автомата, fms(xi1,,…,xik) - функция
возбуждения автомата (булевы выражения относительно входных переменных,
определяющие условия переходов), и Y - вектор выходов. Это представление
совместно со структурой Крипке позволяют осуществлять интерпретацию
системных элементов на любых уровнях абстракции [5].
3. Интеграция моделей и инструментов, предназначенных для решения
задач функциональной верификации и оценки помехоустойчивости
цифровых систем на ранних этапах проектирования
В настоящее время мы имеем определенный опыт использования ASM
спецификаций для верификации различных проектируемых объектов, причем
не только самих проектируемых систем, но и их верификационных тестов.
Например, ASM использовалась для описания тестов верификации (через
моделирование) проекта некоторого процессора. Неформально говоря, тесты
представляют собой набор некоторых команд и данных, которые могут
выполняться либо строго поочередно (очередную операцию можно подавать на
выполнение только после того, как полностью завершена предыдущая), либо, в
случае конвейерного выполнения операций, операции можно подавать
последовательно друг за другом, не дожидаясь завершения предыдущей
операции, либо одновременно могут подаваться несколько операций. Так как
число операций может быть достаточно велико (несколько сотен), тест должен
быть верифицирован на выполнение указанных условий упорядоченности, т.е.
тестовое множество должно быть организовано таким образом, чтобы
выполняемые операции не вступали в конфликты друг с другом, при том, что
возможно взаимное влияние операций (например, ввиду использования одного
и того же буфера данных).
Очевидно, что если выполнение этих тестов описать как переходы
некоторого автомата, или нескольких определенным образом связанных
автоматов, то для проверки этих условий хорошо подходит метод Model
120
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-120-320.jpg)
![Checking [8], состоящий в формальной проверке выполнения логической
формулы, выражающей некоторое свойство “правильного” поведения модели
системы. Автоматы Мили, необходимые для построения соответствующей
модели системы, могут быть получены из ASM диаграмм выполнения
множества тестов с использованием свойств декомпозируемости и
иерархичности ASM-описаний (из-за ограниченного объема статьи детали здесь
не приводятся).
В качестве другой задачи, решаемой на основе высокоуровневой ASMспецификации проекта, рассмотрим возможность учета требований
помехоустойчивости на ранних этапах проектирования.
3.1 Проблема верификации помехоустойчивости проектируемых цифровых
систем на ранних этапах проектирования
По сути современное проектирование цифровых систем состоит в поиске
компромисса между надежностью выполнения функциональных задач,
производительностью и потреблением энергии. Причем существенной
составляющей данной проблемы является обеспечение правильной и
эффективной работы в условиях действия переходных помех, прямое действие
которых ограниченно лишь сравнительно небольшим интервалом времени.
Поэтому ошибки функционирования, вызываемые помехами, называются
“мягкими” (soft) [8]. Важным примером является воздействие ионизированных
частиц, порождаемых космическими лучами.
В настоящее время известно много способов защиты цифровых схем от
действия различных внешних помех. Однако их применение связано с
дополнительными аппаратурными и энергетическими затратами (повышением
потребления электроэнергии), а также с возможным снижением
производительности, как за счет увеличения суммарных задержек в
дополнительных элементах (вентилях, элементах памяти), так и за счет
необходимости ограничений скорости работы процессорных элементов. Дело в
том, что энергопотребление растет примерно как квадрат частоты
переключений, и это может лимитировать объем резервирования, например, изза роста энергозатрат резервирующего оборудования. Все эти обстоятельства
делают актуальной задачу выбора минимально необходимого числа элементов,
защита (protection) которых необходима для обеспечения требуемого уровня
надежности в присутствии т.н. SEU (single event upset, одиночных сбоев, то есть
кратковременных событий, представляющих собой ошибочное изменение
значения логического сигнала (переменной) в некоторой точке системы),
возникающих под действием указанных выше внешних факторов (лучей, частиц
и т.д. ).
В настоящее время предложен и активно развивается подход к
определению критичных к действию помех элементов, которые необходимо
обеспечить той или иной аппаратной защитой, с использованием формальных
методов, Model Checking прежде всего [8]. Этот метод используется совместно с
инжектированием в модель проектируемой системы возможных мутаций
внутренних состояний. Этим способом определяют триггеры–защелки [8],
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
121](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-121-320.jpg)
![которые могут эффективно влиять на результат вычислений, и которые поэтому
следует защищать от ошибок (ошибочного изменения состояний).
Преимущества Model Checking по сравнению с просто моделированием
(симуляцией) модели устройства в присутствии инжектированных
неисправностей состоит в том, что устраняется проблема обеспечения
репрезентативности выбираемых входов (команд и данных), которые могут
отобразить все возможные рабочие ситуации. Model Checking выполняет
исчерпывающий анализ всех состояний системы, начиная с множества
возможных начальных состояний.
Этот подход рассматривают и пытаются использовать не только как
дополнение
к
известным
процедурам
формальной
верификации
функциональных свойств проектов цифровых устройств, но и как средство
оценки полноты анализа надежностных свойств, и как средство анализа
результатов с точки зрения снижения избыточности при обеспечении
помехоустойчивых решений [11].
Хотя указанные выше помехи (лучи, частицы) непосредственно влияют
на те или иные элементы оборудования (оперативную память, шины кэш),
вызывая SEU, они приводят и к программным ошибкам. С программноаппаратной (архитектурной) точки зрения эти ошибки в программе могут
распространяться по управлению (control flow) и данным (data flow). Очевидно,
что непосредственную связь указанных аппаратных сбоев реально можно
установить (описать) только со сравнительно низкоуровневым представлением
программ, например, на уровне машинных кодов или ассемблера.
Существенным, однако, является то, что указанные формальные подходы к
верификации устойчивости проектируемой системы к конкретному SEU [8]
указывают лишь на потенциальную возможность того, что в данной точке
может быть нарушено правильное функционирование проектируемого
устройства, но реальное нарушение функционирования может зависеть от
статистических свойств обрабатываемой информации, например, переменных
fms(xi1,,…,xik) в функции, представленной в структуре ASM (1). При этом
переходные ошибки, индуцированные SEU на некотором такте работы
устройства, не обязательно запоминаются в элементах памяти на следующих
тактах, что можно интерпретировать как самовосстановление устройства (selfhealing). Поэтому желательно было бы дополнить формальную верификацию
вычислением вероятностей такого самовосстановления.
Рассмотрим для этой цели вероятностную модель, предложенную в
[6,9], важным свойством которой является возможность ее использования для
уточнения выводов о рисках, связанных с SEU для конкретных переменных
программы, полученных формальными методами, используя Model Checking
[8].
3.2 Вероятностная модель
Разработана следующая
модель для вычисления распределения
вероятностей времени до самовосстановления после действия SEU. Пусть в
начальный момент 0 под действием помехи (разовой) автомат X (называемый
исправным, fault-free) переходит в состояние Y0 вместо состояния X0 (при этом
предполагается, что действие помехи в выходном сигнале не проявилось).
122
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-122-320.jpg)
![Будем называть автомат, подвергшийся действию помехи, “неисправным”
(faulty), и обозначать его как Y. Неисправный автомат Y действует на тех же
входных сигналах
с теми же переходами и выходными сигналами в
зависимости от текущих состояний и входных сигналов. Так происходит до того
момента, когда либо выходной сигнал неисправного автомата окажется
отличным от выходного сигнала исправного автомата (проявилось действие
помехи в выходном сигнале), либо состояния обоих автоматов совпадут. Считая
входные сигналы автоматов независимыми случайными двоичными
переменными, на произведении этих автоматов (автомата, состояния которого
равны различным парам состояний указанных двух автоматов) определяется
Цепь Маркова (ЦМ) Zt=(Xt, Yt), описывающая совместное функционирование
ЦМ Xt и Yt до момента, когда либо выходной сигнал неисправного автомата
окажется отличным от выходного сигнала исправного автомата (проявилось
действие помехи в выходном сигнале), либо состояния обоих автоматов
совпадут. Множества состояний S1,2, |S1,2| = n, обеих ЦМ одинаковы, начальные
состояния X0, Y0, Y0 ≠ X0 детерминированы. Множество состояний ЦМ Zt
представляет собой S = {(i,j), i,j = 1,…,n, j ≠ i} A0 A1, где состояние (i,j)
означает, что исправный автомат находится в состоянии i, а неисправный – в
состоянии j (отличном от состояния i исправного автомата), состояние A1 –
неправильное функционирование (в результате действия помехи) уже
проявилась в выходном сигнале), и A0 – произошло восстановление траектории
функционирования автомата до проявления эффекта помехи на выходе. Число
состояний этой ЦМ равно n(n – 1) + 2. Состояния A0 и A1 представляют собой
поглощающие состояния двумерной цепи Маркова Zt.
Матрица P* переходных вероятностей ЦМ Zt вычисляется следующим
образом. Пусть Zt находится в состоянии (i1,j1) и поступает входной сигнал x,
переводящий ЦМ исправного автомата в состояние i2, а автомата,
подвергшегося действию помехи, – в состояние j2, причем выходные сигналы
автоматов y0 и y1. Тогда, возможны следующие ситуации:
- если выходы y0 и y1 не совпадают, то ЦМ Zt попадает в поглощающее
состояние A1;
- если выходы y0 и y1 совпадают и совпадают состояния i2 и j2,то ЦМ Zt
попадает в поглощающее состояние A0;
- если выходные сигналы y0 и y1 совпадают, но не совпадают состояния i2
и j2 (в которые произошел переход обоих автоматом по действием входа x), то
ЦМ Zt попадает в (i2,j2).
Вероятности переходов вычисляются по известным вероятностям
булевых значений независимых входных последовательностей, по известной
булевой функции переходов f(xi1,…xin) (1). Подробнее алгоритм вычисления
изложен в статье [6].
Введем обозначения:
p(1)(t) – вероятность, того, что неисправное поведение автомата Y будет
обнаружено (по выходу) не позже t-го шага (при этом до момента обнаружения
неисправности автомат не восстановится);
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
123](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-123-320.jpg)
![p(0)(t) – вероятность того, что автомат Y восстановит свое правильное
поведение не позже t-го шага (до момента восстановления неисправность не
проявится по выходу, т.е. выходы обоих автоматов будут полностью совпадать);
pi,j(t) – вероятность попадания ЦМ Zt в состояние (i,j) (т.е. исправного
автомата X в состояние i, неисправного автомата Y в состояние j ≠ i, при этом
до момента t состояния исправного и неисправного автоматов будут
различными, но выходные сигналы совпадать).
В терминах ЦМ Zt вероятность p(0)(t) представляет собой вероятность
нахождения в момент t в поглощающем состоянии A0, вероятность p(1)(t) – в
поглощающем состоянии A1, вероятность pi,j(t) - в непоглощающем состоянии
(i,j) (j ≠ i).
Начальное распределение p(0) определяется начальными состояниями
исправного и неисправного автоматов. Если исправный автомат в начальный
момент 0 находится в состоянии i0, а неисправный – в состоянии j0 ≠ i0, то
p(i0,j0)(0) = 1, а остальные координаты вектора p(0) равны нулю.
Распределение ЦМ Zt в момент t может быть вычислено из уравнения:
p(t ) p(t 1) P* p(0)( P*)t .
Заметим, что мы считаем, что действие помех не приводят к появлению
новых состояний в моделирующем автомате. Это предположение используется
во многих работах по верификации устойчивости к действию помех [8,10, 11].
Рассмотрим применение данной модели к верификации устойчивости к
сбоям конвейеризированного микропроцессора на стадии выборки инструкций
из памяти. На рисунке 1 представлена соответствующая ASM-диаграмма
режима, представляющая собой направленный граф с начальной вершиной
Begin, финальной End, вершинами, соответствующими выполнению операций
(прямоугольники) и условными вершинами (ромбы). Заметим, что “серые”
вершины соответствуют вложенным ASM.
Инструкции считываются в регистры IR1 (короткие инструкции) и IR2
(длинные), адреса инструкций – в PC (Program Counter). Сгенерированный
программой Abelite соответствующий данной диаграмме конечный автомат
(FSM) в форме Mealy имеет вид таблицы 1, входы, состояния и выходы в
которой интерпретируются таблицей 2.
Заметим, что строки Logical conditions, относящиеся к условным
переходам, определяют входные переменные FSM.
124
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-124-320.jpg)
![Таблица 2. Структура переменных автомата в терминах микроопераций
процессора
Micro Operations
y1 : Fetch2
y2 : Fetch1
y3 : Int
y4 : PCf:=PCf+1
y5 : Fetch2Oper2
y6 : CheckBranch
y7 : Fetch2Oper1
y8 : DMACycle
Logical Conditions
x1 : ShLodInpBran_in_F
x2 : bool2std(IR1f(0to3)=1100)
x3 : IR1f(5)
x4 : DMA
x5 : FGO
x6 : FGI
x7 : IR1f(4)
x8 : S
:
Пусть функциональную верификацию процессора планируется
выполнить с помощью Model Checking, сравнивая поведение на уровне
инструкций с поведением автомата в терминах микроопераций таблицы 2.
Рассмотрим, например, выполнение следующего свойства: всегда, пока
выполняется операция с DMA ((DirectMemory Access), фаза выборки ожидает ее
окончания, чтобы избежать конфликтов. Как видно из таблиц 1 и 2, эти
свойства связаны с выполнениями условий, задаваемых входными
переменными x4, x8, и состояниями a1,a2. Тогда опасность (потенциальная
возможность) неверного функционирования в результате SEU, приводящего к
переключению того или иного бита, соответствующего переходу к
неправильному состояния автомата, может быть также верифицирована с
использованием стандартных средств верификации (SMV, Spin), задавая
свойства, подлежащие верификации на том или ином языке CTL или LTL-типа
(подробно этот вопрос рассматривается в [8]).
Учитывая что описанный выше алгоритм построения цепи Маркова для
переходов автомата под действием SEU использует целочисленное кодирование
состояний, присвоим каждому состоянию ak, k=1,2..7, таблицы 2 значение его
индекса. Конкретный SEU, приводящий к сбою на время такта, мы можем
описать, как указано выше, задавая единичную вероятность в векторе
начальных состояний 2-мерной цепи Маркова Zt . Тогда, назначив вероятности
единичных значений переменным x1, ... x8, мы можем оценить вероятность
перехода в состояние, при котором на начальном такте работы системы (t=0)
выполняется операция DMAcycle до команды “S” (Start), представляющей
собой начало вычислений. В предложенной выше нотации этот сбой
представляется как (1,2). При распределении входных переменных{x1=0.9,
x2=0.8, x3=0.45, x4=0.7, x5=0.65, x6=0.5, x7=0.7, x8=0.7)}, модель дает
следующие
значения
вероятностей
возвращения
к
правильному
функционированию автомата таблицы 2 за соответствующее число тактов после
126
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-126-320.jpg)
![прекращения действия причины сбоя: SH = (0.0, 0.034, 0.46, 0.55, 0.64, 0.68).
Скажем, через 4 такта вероятность будет 0.64, что, разумеется не позволяет
считать этот сбой несущественным. Однако для сбоя (5,2) (ошибка заполнения
программного счетчика) получаем SH = (0.00, 0.79, 0.79, 0,85, 0.89, 0.92, 0.93),
что в ряде случаев (в зависимости от требований к быстродействию и
надежности
проектируемой
системы)
может
быть
приемлемым.
Соответственно, у разработчика есть некоторая свобода выбора - пытаться ли
ввести дополнительную аппаратную защиту данных переменных (например,
используя Triple Modular Redundancy (TMR –защиту [17]) или же нет.
Заметим, что мы используем для верификации те же средства Abelite,
что и для синтеза реальных ASIC или FPGA, и поэтому каждый сбой,
описанный на высоком уровне (сбой перехода автоматной переменной), можно
связать с аппаратным блоком проектируемой системы, реализующим данный
переход.
4. Направление дальнейших исследований
Выше мы рассмотрели модель оценки помехоустойчивости для одного
конкретного сбоя, специфицированного как (i,j) - ошибочный переход автомата
в новое состояние j вместо i, определяемого спецификацией системы.
Чтобы построить модель учета действия различных сбоев можно
рассмотреть семейство марковских цепей с данной матрицей вероятностей
переходов P, Zt,F = Pi, F, P для данного списка возможных сбоев F,
задаваемых единицей (единичной начальной вероятностью) в ячейке (i,j) в
векторе начального распределения вероятностей P0i , i=1,2,..,│F│, тогда как
остальные ячейки – нулевые, как это описано в параграфе 3.2. Тогда [9] мы
можем, используя формулу полной вероятности [13], выразить вероятность
того, что за время t ни один из сбоев не приведет к ошибке функционирования
автомата. Эта вероятность представляет собой характеристику устойчивости
автомата, моделирующего проектируемое устройство, к указанному классу
сбоев. При этом мы неявно предполагаем, что сбои наступают достаточно
редко, и к началу некоторого сбоя (i,j), эффект действия предыдущего (k,l)
полностью прекратился. Поэтому для учета вероятности (частоты)
возникновения сбоев в настоящее время разрабатывается более общая модель.
С методологической точки зрения предложенный нами подход
представляет собой дополнение формальной верификации функциональных
свойств вычислительной вероятностной моделью отказоустойчивости. При
этом, хотя оба подхода используют общее входное описание в виде ASM, ряд
данных приходится вводить независимо для каждой из моделей, а именно,
свойства (property) на LTL или CTL для формальной верификации (хотя и с
возможностью использования некоторых языковых конверторов, упрощающих
для разработчика описание указанных свойств), и некоторые распределения
вероятностей для оценки вероятности самовосстановления (раздел 3.2).
Хотя соответствие (интерпретация) переменных автомата и элементов
архитектуры проектируемой системы задается таблицами, подобными 1 и 2,
для достаточно сложных систем, особенно для систем с конкуренцией
вычислений за ресурсы, может возникнуть проблема непротиворечивости обеих
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
127](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-127-320.jpg)
![групп описании. В настоящее время предложено несколько формальных языков
(моделей) совместного описания задач функциональной верификации и оценки
производительности (Performance evaluation) [14,15]. В этих работах
предполагается, что работа системы может моделироваться в терминах теории
очередей, т.е. поведение проектируемой системы представляется в терминах
обработки запросов некоторым сервером (или несколькими серверами) [15].
При этом функциональная спецификация дополняется вероятностным
распределением времени обслуживания “заявок”, что представляется в языках
типа PCTL (probability computation tree logic) [16]. Однако, для таких аспектов
анализа производительности как отказоустойчивость, подобные модели не
вполне естественны. Разработка этого вопроса представляется весьма
перспективной.
5. Заключение
На ранних этапах разработки программно-аппаратных систем перед
инженером – разработчиком часто встает проблема выбора наилучшей
программной архитектуры (для данной среды), обеспечивающей максимальную
вероятность корректного выполнения данного приложения в данной рабочей
среде при заданном уровне случайных ошибок (soft-error rate). Мы выражаем
отказоустойчивость (fault-tolerance) работы системы в терминах вероятностей
переходов в конечном автомате, моделирующем работу системы. Существенно,
что описания автоматов могут быть получены из ASM-диаграмм, используемых
для спецификации проектируемой системы, что также позволяет сократить
суммарную трудоемкость проектирования. Более того, различные аспекты
проектирования
устройства,
такие,
как
функционально-временная
корректность, устойчивость к сбоям (fault toleranсe), и даже оптимизация
потребления электроэнергии системой (low power design) могут быть учтены,
поскольку все эти задачи требуют использования FSM модели проектируемой
системы, и эта модель автоматически строится по ASM-спецификации системы.
При
этом
вычислительная
сложность
оценки
вероятностей
самовосстановления O(n4) для рассматриваемой марковской цепи размера n(n1)+2 существенно ниже вычислительной сложности реализации алгоритмов
Model Checking [12], что определяется квадратичной вычислительной
сложностью решения линейных уравнений Колмогорова-Чапмена.
Литература
1. Egon Börger, Abstract State Machines: a unifying view of models of abstract state
machines capture sequential algorithms // Annals of Pure and Applied Logic, 133,
(2005), p. 149–171.
2. A. Blass, Y. Gurevich, Abstract state machines capture parallel algorithms // ACM
Transactions on Computational Logic, 3, (2002).
3. S. Baranov, ASMs in high-level synthesis of EDA tool Abelite // in Proc.
DESD’09 Int. IFAC Workshop, Valensia, Spain, 2009, pp. 195-200. Available:
http://www.dcud.uz.zgora.pl/shw/dCUD-Baranov.pdf.
128
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-128-320.jpg)
![Особенности разработки программного обеспечения
для Linux-контроллеров
М.А. Смирнов, В.В. Олоничев, Б.А. Староверов
Костромской государственный технологический университет
amt@kstu.edu.ru
Аннотация. В статье рассмотрены некоторые особенности разработки
программного обеспечения для современных встраиваемых систем,
работающих под управлением операционной системы Linux. Описанный
подход является альтернативой для средств проектирования стандарта
МЭК и предназначен для реализации эффективных алгоритмов цифрового
управления технологическими установками.
Ключевые
слова.
Программируемый
логический
контроллер,
операционная система Linux, процессор ARM, кросс-компиляция,
toolchain, реализация на языке Си, цифровое адаптивное управление, sshпротокол, научная библиотека GNU GSL, средства межпроцессного
взаимодействия.
1
Введение
На сегодняшний день ведущие производители промышленных компьютеров
(JetBox, Atmel, Techbase и др.) и программируемых логических контроллеров
(WAGO, ICP DAS, NPE и др.) предоставляют пользователям возможность
реализовывать гибкие и эффективные алгоритмы цифрового управления на
языках высокого уровня благодаря поддержке многозадачной операционной
системы (ОС) Linux [1].
В современном ядре ОС Linux большинство системных вызовов являются
вытесняемыми и имеются таймеры высокого разрешения. Вследствие этого
Linux начинает занимать области, ранее принадлежащие классическим ОС
реального времени, таким как QNX, OS-9 и VxWorks [2–4]. Поддержка
спецификации POSIX данными ОС позволяет сравнительно легко переносить
программы между ними.
К преимуществам Linux-устройств можно отнести также низкую цену (в
своем сегменте средств автоматизации), открытую архитектуру, низкие
требования к аппаратным ресурсам [5].
В связи с высокими требованиями, предъявляемыми сегодня к качеству
выпускаемой продукции, разработка программного обеспечения (ПО) под
описываемые вычислительные системы весьма актуальна [6–8]. В то же время,
130
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-130-320.jpg)
![как показывает практика работы с Linux-контроллерами отечественного
производства (например, ПЛК серии 304/308 фирмы «Овен»), пользователь по
причине отсутствия универсальных пошаговых инструкций сталкивается с
серьезными не для профессионала проблемами. К ним можно отнести
следующие [9]:
─ необходимость модификации и конфигурирования ядра Linux;
─ необходимость поиска и построения инструментального пакета (toolchain);
─ необходимость
библиотек;
интеграции
дополнительных
драйверов,
приложений,
─ необходимость тестирования, отладки и масштабирования проекта.
Указанные причины, по мнению авторов, сдерживают широкое применение Linux-контроллеров и заставляют разработчиков использовать ограниченные
возможности языков стандарта МЭК (язык структурированного текста,
функциональных блоков, релейных схем и др.).
Изложенный далее материал позволяет ликвидировать проблему
масштабирования
и
быстрого
реконфигурирования
встраиваемого
программного обеспечения. Что касается переноса исполняемых файлов с
персонального компьютера (ПК) на целевую платформу, то рассмотрено
конкретное решение для процессора ARM AT91RM9200 фирмы ATMEL, на
базе которого работает большое количество отечественных и зарубежных
контроллеров, в частности ПЛК304/308 «ОВЕН». Наиболее важные
рекомендации по общему порядку действий даны в работах [9, 10].
2
Мультипроцессный комплекс управления
технологическими установками
Для класса апериодических объектов с одной доминирующей постоянной
времени, подверженных за технологический цикл девиации параметров в
широких пределах, что в свою очередь требует перенастройки коэффициентов
регулятора, разработана адаптивная многопроцессная управляющая система,
функциональная схема которой представлена на рис. 1 [11]. За основу принята
классическая САУ с регулятором состояния и наблюдателем [12].
Идентификатор однократно или в темпе с процессом вычисляет параметры
технологического объекта управления, которые в свою очередь используются
для расчета коэффициентов настройки динамического регулятора.
В состав мультипрограммного продукта входят следующие процессы [13]:
«диспетчер», «регулятор состояния», «наблюдатель полного порядка»,
«адаптатор», «задающее устройство эталонного сигнала», «цифровая модель
объекта управления», «связь с реальным объектом», «идентификаторы»
(«пассивный идентификатор», «идентификатор однократного действия»,
«идентификатор многократного действия»). Данный комплекс реализован на
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
131](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-131-320.jpg)
![языке Си с помощью GNU Scientific Library (GSL) v1.3 – библиотеки для
научных расчетов. В качестве средств межпроцессного взаимодействия
используется разделяемая память и семафоры System V.
Рис. 1. Цифровая адаптивная самонастраивающаяся система управления: ОУ – объект
управления; И – идентификатор; А – адаптатор; Н – наблюдатель; РС – регулятор
состояния
Главное преимущество мультипроцессной организации цифровой системы
управления
заключается
в
том,
что
на
основе
небольших
узкоспециализированных программ можно собирать целые комплексы
произвольной конфигурации и теоретически неограниченной сложности
(именно такой подход отвечает идеологии ОС UNIX [14]). В частности, в
зависимости от требований технологического процесса «идентификаторы»
реализованы в трех вариантах: «пассивный идентификатор», «идентификатор
однократного действия», «идентификатор многократного действия» [11].
Процесс «диспетчер» призван координировать работу всех остальных
программ. При запуске он получает два параметра: первый задает режим работы
(0 – асинхронный, 1 – синхронный), второй – имя конфигурационного файла.
При асинхронном режиме обмен данными между процессами осуществляется
по их готовности и происходит с максимально возможной для данной
вычислительной системы скоростью. Данный способ взаимодействия
применяется для моделирования поведения системы управления и может быть
использован при отладке и тестировании программ на ПК.
При синхронном режиме все вычисления и межпроцессная коммуникация
происходят по команде от источника синхросигнала, которым является таймер
реального времени. Он генерирует импульсы с заданным пользователем
периодом квантования. Описанный способ взаимодействия используется для
управления работой технологической установки в режиме реального времени.
Конфигурационный файл содержит следующую информацию: количество
регуляторов в системе управления, количество процессов-участников, не
132
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-132-320.jpg)
![а)
б)
Рис. 3. Исследование работы мультипроцессной системы управления на незагруженной
печи при внесении возмущающего воздействия: а) работает неадаптивная система; б)
работает адаптивная система
3
Подготовка и запись исполняемых файлов в контроллер
Для компиляции и генерации исполняемого кода для целевой платформы
(ПЛК308), работающей под управлением процессора ARM9, на ПК с ОС Linux
(uCLinux v 2.6), установлен и сконфигурирован набор необходимых программ –
toolchain фирмы «Ronetix» – ronetix-arm-linux-uclibc-4.1.2 [15], благодаря
которому можно осуществить кросс-компиляцию исходных кодов. Диаграмма
развертывания описываемой системы представлена на рис. 4.
134
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-134-320.jpg)
![Об усовершенствовании статистического метода
оценки полноты тестов программ и устройств
Басок Б. М., Гречин А.А.1
1
Московский государственный технический университет радиотехники, электроники
и автоматики,
119454, Россия, г. Москва, Проспект Вернадского, 78
vm_e@mail.ru
Aннотация. Рассматривается статистический метод проверки полноты
тестов, основывающийся на анализе результатов работы программ и
математических моделей дискретных устройств с внесѐнными дефектами.
В работе предлагается существенно сократить временные затраты при
оценке качества тестов данным методом, с одной стороны, путѐм внесения
кратных дефектов, с другой, – путѐм взаимного использования
результатов анализа тестов объекта тестирования и отдельных его
компонентов. Приводятся экспериментальные данные, подтверждающие
эффективность предлагаемых подходов. Ключевые слова: полнота тестов,
анализ тестов, кратные отказы, мутации.
1 Введение. Постановка задачи
Важнейшей характеристикой тестов программных систем (ПС) и дискретных
устройств (ДУ) является их полнота. Под полнотой теста или его проверяющей
способностью принято понимать [1,2] выраженное в процентах отношение
выявляемых данным тестом отказов заданного класса к общему их числу. От
полноты тестов напрямую зависит качество контролируемого объекта. Поэтому
задача синтеза тестов высокой полноты является одной из важнейших задач
контроля любого продукта на всех этапах его разработки и эксплуатации. При
этом следует отметить, что, как правило, тесты ПС и существенная часть тестов
ДУ создаются и отлаживаются вручную, и разработка новых дополнительных
тестов для повышения полноты контроля требует больших затрат времени и
средств.
Обычно при проверке полноты функциональных тестов ПС используются
методы, основывающиеся на покрытии кода программы или методы,
базирующиеся на оценке количества охваченных тестом отдельных функций
ПС [3].
Наряду с данными методами для проверки полноты тестов используется
метод, основывающийся на анализе результатов выполнения тестов для ПС с
искусственно введенными одиночными постоянными дефектами из списка
отказов заданного класса и исходной ПС. При этом предполагается, что данный
метод применяется после того, когда все собственные дефекты, обнаруженные
данными тестами, исправлены, и влияние не обнаруженных ими собственных
138
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-138-320.jpg)
![дефектов ПС невелико. Указанный метод является некоторым аналогом
классического метода, применяемого при анализе тестов ДУ и
основывающегося на сравнении результатов моделирования исправной и
неисправной ДУ[4].
Известны два подхода при реализации данного метода. Первый из них [5,6]
основывается на внесении дефектов непосредственно в объектный код ПС.
Такими дефектами могут быть, например, инверсия бита или байта объектного
кода программы.
Второй подход, получивший название мутационного анализа [7-10],
основывается на внесении в исходный текст программы незначительных
дефектов (мутантов). По определению [7] мутант – это одиночное
синтаксически корректное изменение подлежащей тестированию ПС.
Специальные программы – генераторы мутантов - формируют их списки.
Мутанты, входящие в список, осуществляют либо замещение констант, либо
замещение переменных, либо замещение операторов. Генераторы мутантов
строятся на основе синтаксического анализа исходного кода ПС[7].
Первый подход применим, в первую очередь, при анализе тестов ПС, для
которых отсутствует доступ к исходному коду.В то же время, для обеспечения
безопасности работы эксплуатируемых ПС необходимо убедиться в высокой
степени их надежности. Поэтому в любой момент может возникнуть
необходимость
в оценке качества предоставленных пользователю
функциональных тестов, поскольку в редких случаях технологии разработки
ПС, применяемые разработчиками включают обязательный этап тестирования
безопасности [6].
Второй метод особенно полезен, поскольку с его помощью можно точно
установить место внесенного дефекта и разрабатывать дополнительные тесты
для выявления дефектов, не обнаруженных анализируемыми тестами. Кроме
того, при реализации второго подхода, в отличие от первого, отсутствует
опасность того, что внесение искусственного дефекта в ПС исказит
операционную среду. Впрочем, данный недостаток можно преодолеть путем
запуска ПС в системе виртуальных машин. При этом отказ, внесение которого
приводит к искажению операционной среды, можно считать выявляемым.
Описанные подходы применимы и при тестировании поведенческой модели
ДУ на языке описания аппаратуры HDL, в частности на VHDLи Verilog,и
анализе собственно тестов ДУ, представленных этой моделью [9,11].Например,
в [9] описаны принципы разработки генератора мутаций для ПС на VHDL.
Главным недостатком, как первой, так и второй реализации
рассматриваемого метода оценки полноты тестов ПС являются чрезвычайно
большие затраты времени, как следствие наличия большого количества
мутантов или возможных искажений разрядов объектного кода ПС. Даже при
тестировании сравнительно небольших ПС их количество может достигать
многих десятков тысяч. При тестировании программ, содержащих несколько
тысяч операторов, это число может многократно увеличиться. Например, при
тестировании программы, реализующей метод Монте-Карло, генератор выдал
более девятисот тысяч мутантов [10].
В некоторых работах [7] были рассмотрены методы сокращения множества
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
139](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-139-320.jpg)
![рассматриваемых мутантов путем выделения групп эквивалентных мутантов и
при оценке полноты тестов анализировать только одиночных представителей
этих групп. Однако, как показано в [7], список анализируемых отказов
сокращается не более чем на 8% - 10%.
Другой подход, основывается на замене общего списка мутантов некоторой
его выборкой, как правило, это некоторая часть общего списка, например, в [7]
случайным образом выбирается 10% общего списка дефектов. Тем не менее,
выбранный список оказывается достаточно большим. Кроме того в подобных
работах отсутствует обоснование размеров выборки. В этом случае обычно
полагаются на накопленный в данной области опыт.
Для существенного сокращения времени при реализации метода оценки
полноты в работе [12] предложен и обоснован способ, известный как
статистический. В соответствии с этим способом при анализе тестов
используется не полное множество отказов, а некоторая небольшая случайная
выборка. Согласно [12] для случайной выборки из 400 отказов заданного класса
можно гарантировать, что полнота тестового набора для всей совокупности
отказов заданного класса отличается не более чем на 5% от истинного значения
с достоверностью 0,95. Величина выборки не зависит от сложности и размеров
объекта тестирования.
Таким образом, количество модифицированных неисправных копий
анализируемого объекта (ПС или ДУ) оказывается фиксированным и
сравнительно небольшим.
Статистический способ оценки полноты был программно реализован и
показал свою эффективность при многолетней эксплуатации программного
комплекса моделирования, синтеза и анализа тестов, разработанного в ИНЭУМ
и внедренного в ряде организаций, а также при анализе полноты тестов СБИС
повышенной сложности с помощью первого в Советском Союзе
многопроцессорного
программно-аппаратного
комплекса-ускорителя
логического моделирования, разработанного в ИНЭУМ [13].
В работах [5,11] обсуждаются возможности применения статистического
способа оценки полноты при мутационном подходе и искажении объектного
кода программы.
Однако, несмотря на ряд преимуществ статистического способа проверки
полноты абсолютная величина временных затрат при его использовании
остается весьма значительной. В первую очередь, это касается затрат времени
при анализе тестов программ с невысокой проверяющей способностью. Так при
анализе пяти тестов программы размер исполнительного модуля которой
составляет 18 кбайт, понадобилось 1708 прогонов данной программы. Если
предположить, что время выполнения программы составляет одну минуту, то
временные затраты составят более 28 часов. При этом несмотря на то, что
имеется такой источник сокращения
времени,
как возможность
распараллеливания процесса оценки полноты, к примеру на нескольких
компьютерах, величина временных затрат остается существенной.
В данной работе рассматриваются два подхода к сокращению времени
оценки статистической полноты тестов. Первый подход основывается на
анализе тестов в классе одиночных константных отказов путѐм внесения
кратных дефектов из данного класса. Второй подход базируется на совместном
140
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-140-320.jpg)
![анализе интеграционных тестов объекта контроля и тестов отдельных его
частей.
2 Метод внесения кратных отказов
В работе одного из авторов данной статьи [14] был предложен метод анализа
тестов ДУ, называемый методом моделирования кратных отказов. В
соответствии с этим методом процесс проверки полноты тестов можно
ускорить, если вносить не одиночные, а кратные отказы. Последние можно
получить путѐм случайного разбиения списка невыявленных предыдущими
тестами отказов на небольшие непересекающиеся группы одного размера
(возможно последняя из групп окажется меньше). Отказы объединяются в
группы случайным образом. При этом в соответствии с гипотезой о редкой
компенсации кратных отказов [1,11] считается, если тестом не выявляется
полученный таким образом кратный отказ, то не выявится и не один из
одиночных дефектов, входящих в данную группу. В том случае, если состояния
выходов модели объекта тестирования с внесѐнным кратным отказом
отличаются от состояний одноименных выходов модели исправного объекта,
следует проверить возможность выявления тестом дефектов, образующих
кратный отказ по одному.
В работе [14] обосновывается близкий к оптимальному размер групп для
списка дефектов, оставшихся не выявленными после анализа группы первых
тестов и относящихся к классу трудно проверяемых отказов. В соответствии с
приводимыми в работе [14] оценками применение указанного метода повысит
скорость анализа качества тестов в несколько раз.
В докладе применяется подход, использующий, с одной стороны,
статистический способ проверки полноты тестов, с другой, – метод кратных
отказов. Этот подход применим как для ПС, так и для ДУ. В соответствии с
данным подходом не выявленные очередным тестом отказы из выборки [5,12]
разбиваются на группы. Размер группы определяется исходя из минимизации
математического ожидания случайной величины количества прогонов теста
[14]. Общее количество прогонов теста определяется как сумма двух слагаемых:
количества прогонов равных количеству полученных групп отказов и
количества прогонов равного количеству одиночных дефектов, образующих
обнаруженные кратные дефекты.
Таким образом, величина группы при анализе полноты теста i может быть
определена путем минимизации функции, имеющей следующий вид:
F (Gi )
Gi
N Li 1 j 1
1
1 i
N j 1
Gi
j 1
i
(1)
где Li 1 - количество выявленных дефектов на предыдущем (i-1)-ом тесте, Ni –
количество дефектов заданного класса, оставшихся невыявленными после
анализа предыдущих (i-1) тестов.
Размер группы для анализа качества первого теста можно принять равным
единице, учитывая тот факт, что первые тесты обычно обладают хорошими
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
141](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-141-320.jpg)
![Увеличение выигрыша во времени от теста к тесту объясняется резким
сокращением количества выявляемых отказов и тем, что в списке не
выявленных отказов остаются отказы, относящиеся к подмножеству так
называемых «трудно проверяемых».
Данные, помещенные в Таблицы 1 и 2, наглядно показывают выигрыш во
времени при использовании метода кратных отказов по сравнению с методом
внесения одиночных отказов примерно в 2,7 раза.
Кроме того, проведенные эксперименты продемонстрировали, что
эффективность метода кратных отказов тем выше, чем меньше полнота тестов.
При этом экспериментально установлено, что существует некоторый порог
полноты анализируемого теста (30%-40%),
при превышении которого
использование кратных отказов нецелесообразно. Однако следует заметить, что,
как правило, полнота отдельных тестов в классе рассматриваемых отказов не
превышает 25%.
Полученные результаты показали, что отказы из случайной выборки,
объединенные в группу, мало влияют друг на друга. Это позволяет
предполагать, что подобный алгоритм будет особенно полезен при реализации
мутационного подхода.
3 Совместный анализ интеграционных
контроля и тестов его отдельных частей
тестов
объекта
Как правило, полнота анализируемых тестов не является удовлетворительной, и
для выявления не обнаруженных отказов следует разрабатывать
дополнительные тесты. Это весьма трудоѐмкий процесс. Поэтому в данной
работе предлагается, прежде чем приступить к синтезу дополнительных тестов,
использовать для повышения полноты интеграционных тестов системы
возможности тестов компонентов, и наоборот: использовать результаты оценки
полноты интеграционных тестов для повышения качества проверки отдельных
компонентов. Использование такого подхода сократит количество не
выявляемых указанными тестами дефектов и, следовательно, сократит время
для разработки дополнительных тестов.
Следует отметить, что в работе [15] предлагался оригинальный метод
компонентного тестирования информационных систем, позволяющий на основе
выделения наиболее часто встречающихся типов ошибок в программе выявлять
их на уровне компонентов программ.
Суть предлагаемого в настоящей работе подхода заключается в следующем.
Вначале осуществляется синтез тестов компонентов, поиск и исправление
дефектов обнаруженных с их помощью в этих компонентах. После завершения
данного этапа контроля аналогичные процедуры выполняются для системы с
применением интеграционных тестов системы.
Теперь, после выявления и исправления всех обнаруженных тестами
компонентов и тестами системы отказов можно приступить к оценке
статистической полноты данных тестов в классе одиночных отказов (например,
мутантов). Очевидно, что как дефекты, не выявляемые тестами системы, могут
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
143](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-143-320.jpg)
![быть выявлены тестами компонентов, так и невыявленные отказы компонентов
могут быть обнаружены тестами системы.
Поэтому следует проанализировать возможность выявления непроверенных
отказов интеграционных тестов системы тестами компонентов, которым эти
отказы принадлежат. Для этого предлагается взять список непроверенных
отказов после определения статистической полноты и путѐм последовательного
внесения этих отказов в соответствующие компоненты определить, выявляют
тесты компонентов эти отказы или нет.
Аналогичную процедуру можно применить для анализа списка
непроверенных отказов компонентов. В этом случае непроверенные отказы
компонентов последовательно вносятся в компонент, собирается версия
системы и выполняются интеграционные тесты.
Как показали эксперименты, интеграционные тесты выявляют не менее 10%
из невыявленных тестами компонентов отказов-мутантов.
Заключение
В работе рассматривался статистический метод оценки полноты тестов ПС и
ДУ, обсуждались его достоинства и недостатки. Для модификации данного
метода были предложены два подхода. Первый из них основывается на
использовании кратных отказов вместо одиночных. Его применение позволит
сократить время проверки полноты тестов в несколько раз. При этом показано,
что в отличие от предложенного в [14] метода данный подход можно
применять, начиная с первого теста. Второй подход использует пересечение
множеств отказов контролируемого объекта и его отдельных компонентов.
Благодаря этому удается повысить полноту, как интеграционных тестов, так и
тестов отдельных компонентов ПС и ДУ и сократить время разработки
дополнительных тестов.
В качестве дальнейших исследований в области оценки качества тестов нам
представляется актуальным продолжать работы в области сокращения
временных затрат. Одним из путей здесь видится сокращение выборки из
множества отказов за счет некоторой потери точности как это предлагается,
например, в [5,16].
Перспективным направлением является применение статистических методов
для оценки качества и отказоустойчивости встроенных систем, когда имитация
отказов сводится к внесению искусственных неисправностей в программное
обеспечение этих систем [17].
Литература
1. Гробман Д.М. Программный контроль и диагностика неисправностей ЦВМ. //
Диагностика неисправностей вычислительных машин. М.: Наука. 1965 г. С. 7 – 22.
144
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-144-320.jpg)
![2
1
Введение
Современное сетевое оборудование обладает большим функционалом, реализация которого уже давно не возможна только на аппаратном уровне. Как
следствие, такое оборудование содержит в себе специализированный процессор, на котором исполняется операционная система и прикладное программное обеспечение.
Операционная система в сетевом оборудовании несет на себе основную
нагрузку по обеспечении безопасности и реализации основного функционала, как следствие, для разработки доверенных решений операционная система должна обладать повышенными средствами защиты от проникновения
и отказов.
Микроядерные операционные системы - это такие операционные системы, в которых большая часть функциональности ядра реализована в виде
отдельных сервисов. Подобные системы находятся в разработке с 1970-х годов; некоторые проекты достигли коммерческого успеха и применяются в
промышленности. Однако, особенности архитектуры микроядра могут накладывать ограничения на производительность и границы применимости
таких систем [5].
Основные механизмы обеспечения безопасности в микроядерной среде выполнение всех процесов в депривелигированном (пользовательском) режиме и использование системы межпроцессного взаимодействия вместо прямого обращения к памяти другого процесса[6]. Большая часть функциональности, такой как драйвера устройств, файловые системы, управление памятью, реализуется в виде независимых процессов, выполняющихся в пространстве пользователя. Компрометация одной из подсистем ядра не дает
атакующему доступ в привелигированный режим, в то время, как в получивших большее распространение монолитных ОС, где все системные компоненты выполняются в пространстве ядра (режиме супервизора), такая
угроза есть.
В данной статье представлен опыт создания сетевого оборудования на
основе экспериментального микроядра Fiasco.OC в окружении Genode. Используемое микроядро, с одной стороны, обладает высоким потенциалом
с точки зрения безопасности, поскольку вынесение критического функционала из ядра в пространство пользователя, а так же жесткая изоляция
компонентов 1 уменьшают количество векторов атак и повышает отказоустойчивость. С другой стороны, изоляция компонентов ядра приводит к
интенсивному межпроцессному обмену, что может негативно влиять на производительность сетевого оборудования.
Для оценки производительности такого оборудования был разработан
прототип аппаратно-программного комплекса, решающего задачу изоляции
сетевый сервисов при помощи паравиртуализации. В качестве гипервизора
1
Под изоляцией подразумевают использование раздельных адресных пространств и использование принципа наименьших привилегий в выделении ресурсов
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
147](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-147-320.jpg)
![3
было использовано экспериментальное микроядро Fiasco.OC, виртуальные
машины реализованы на основе паравиртулизированного ядра L4Linux[4].
Результирующие тесты производительности системы показали деградацию пропускной способности сети в сравнении с системами построенными
на монолитно-модульном ядре Linux. Для выявления причин деградации
был разработан набор программного обеспечения для профилирования ядра и окружения. Этот набор инструментов позволил выявить компоненты
программного окружения, вносящие наибольший вклад в падение производительности сетевой подсистемы, а также отличия в поведении микроядра
Fiasco.OC на одно- и многопроцессорных системах.
Статья имеет следующую структуру: В первой главе представлена архитектура экспериментального аппаратно-программного комплекса, а так же
результаты нагрузочного тестирования. Во второй главе описана методология профилирования и ее результаты. В третьей главе представлен анализ
профилирования, а в четвертой главе приведены рассуждения о методах повышения производительности. В заключительной, пятой главе, подводятся
итоги работы и формулируются планы на дальнейшую работу.
2
2.1
Аппаратано-программный комплекс «Шлюз»
Функциональное назначение
Гарантированное разделение ресурсов в вычислительных системах - одна
из основных задач информационной безопасности. При этом есть необходимость как ограничить доступ к вычислительным ресурсам внутри одной
машины, так и контролировать потоки данных между различными сетевыми устройствами.
При проектировании корпоративной локальной сети, необходимо изолировать безопасный сегмент сети (сетевое хранилище и автоматизированные рабочие места работников, обрабатывающих внутрикорпоративные документы) и сетевые устройства, имеющие доступ в интернет или другие
публичные сети. Возникает задача контроля входящих сетевые соединения
для того, чтобы блокировать трафик от недоверенных узлов. Кроме того, требуется производить мониторинг сетевого трафика для обнаружения
специальным образом сформированных сетевых пакетов, направленных на
повышение привелегий злоумышленника путем эксплуатации уязвимостей
в программном и аппаратном обеспечении.
Зачастую требуется предоставить доступ к части внутрисетевых ресурсов. Например, внутри безопасной локальной сети пользователям могут быть
доступен сервис сетевого хранения данных, реализованный в виде сетевого диска. Если определенные файлы необходимо сделать доступными из
внешней сети, может использоваться веб-сервер для выдачи индивидуальных файлов. Помимо возможности проведения дополнительной авторизации пользователей средствами веб-интерфейса, такое решение скрывает от
потенциальных злоумышленников физическую топологию внутрикорпоративной сети.
148
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-148-320.jpg)
![5
Поскольку стояла задача оценить производительность полностью микроядерного окружения, в котором драйвера сетевой подсистемы реализованы
в пространстве пользователя, были исключены решения на базе гибридных
ядер ОС. Кроме того, к используемой комбинации ядра ОС и программного
окружения предъявлялись следующие требования:
– Открытый исходный код, так как предполагалась доработка системы и
последующее распространение изменений.
– Поддержка микропроцессорной архитектуры X86 и многопроцессорных
(SMP) систем.
– Поддержка современного оборудования, в частности, наиболее распространённых моделей сетевых карт.
Этим требованиям удовлетворяют микроядра семейства L4, такие, как OKL4,
Fiasco, Fiasco.OC. Было использовано ядро Fiasco.OC, как наиболее активно
развиваемое (новые версии выходят раз в несколько месяцев, в то время как
последний публичный релиз OKL4 был несколько лет назад) и официально
поддерживаемое окружением Genode.
Рис. 2. Архитектура сетевого шлюза с использованием микроядра
Программная среда Genode - это набор системных сервисов (драйверов
устройств и файловых систем) и библиотек, предназначенных для разработки программного обеспечения для микроядерной ОС. Ряд библиотек реализуют программный интерфейс POSIX, позволяя переносить некоторые
приложения из ОС Linux посредством перекомпиляции. Кроме того, Genode
содержит библиотеку DDEKit[7], позволяющую использовать ряд драйверов устройств из других ОС (таких, как Linux и iPXE). Одним из сервисов, использующих библиотеку DDEkit, является DDE_ipxe, реализующий
функциональность драйвера сетевого интерфейса. Таким образом, драйвер
150
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-150-320.jpg)
![6
сетевого интерфейса представляет собой программу, выполняющуюся в пространстве пользователя, тем самым изолированную от других сервисов. В
случае, если будет обнаружена уязвимость в этом драйвере, позволяющая
злоумышленнику внедрить свой код в сервис, не произойдет компрометации
других программ, в частности, приложений, выполняющихся в виртуальных
машинах.
Виртуальные машины реализованы при помощи L4Linux. L4Linux - это
адаптированное ядро Linux для работы в депривилегированном режиме
(пространстве пользователя) в качестве сервиса среды Genode. L4Linux позволяет использовать программы для ОС Linux без модификации за счет
двоичной совместимости. Помимо сокращения затрат времени на адаптацию программного обеспечения для работы в микроядерной среде, это позволяет использовать программы, которые невозможно адаптировать ввиду
отсутствия исходных кодов, например, значительная часть коммерческого
программного обеспечения.
2.3
Модель угроз
Основной вектор атаки на сетевые устройства под управлением монолитных ОС типа Linux и FreeBSD - это эксплуатация уязвимостей в одном из
сервисов, доступных извне (например, HTTP сервер, используемый для конфигурации или вывода информации) для повышения привилегий. Ряд атак
позволяет злоумышленнику повысить уровень доступа в пределах одного
сервиса, другие направлены на получение полного доступа к ядру ОС (root
expoits). Большое количество атак для повышения привилегий использует
ошибки в ПО, связанные с переполнением буфера [3]. Атака с переполнением буфера заключается в возможности перезаписи переменных в программе
из-за ошибок обработки пользовательского ввода. Данный класс уязвимостей возможен в связи с тем, что для хранения кода программ и пользовательских данных используется одна и та же область памяти. Кроме того,
для передачи параметров в системные вызовы зачастую используется разделяемый между пространством ядра и пространством пользователя регион
памяти, что позволяет получить доступ к структурам ядра, если в коде
обработки системного вызова отсутствуют или некорректно реализованы
проверки размера передаваемых данных.
В микроядре Fiasco.OC взаимодействие между процессами реализовано
через систему обмена сообщениями. Сообщения передаются через специальный регион памяти фиксированного размера (UTCB, Userspace Thread
Control Block). При передаче данных от процесса к процессу данные копируются из UTCB первого процесса в UTCB второго, что, с одной стороны, защищает от утечек данных через указатели на структуры ядра, а с
другой, может увеличить время затрачиваемое на системные вызовы. Важно заметить, что эта мера поддерживающая целостность данных при осуществлении межпроцессных вызовов, тем самым не позволяя злоумышленнику, получившему контроль над каким-либо сервисом, атаковать сервисы,
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
151](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-151-320.jpg)
![7
связанные с ним, но не гарантируют невозможность проведения атаки на
отдельный сервис.
Одной из угроз вляется атака через устройства, поддерживающих DMA.
Технология DMA (Direct Memory Access) позволяет устройству обращаться
к произвольной области физической памяти. Защища от таких атак не зависит от типа ядра и реализуется при помощи IOMMU (Input/Output Memory
Management Unit) - аппаратного блока виртулизирующего физическую память с которой работает DMA устройство.
Другим типом угроз является атака на драйвер устройства. Выявление и
использование уязвимости в сетевой подсистеме не дает доступа злоумышленнику к структурам ядра поскольку сетевая подсистема исполняется в
режиме пользователя и изолированная от других компонентов.
2.4
Анализ производительности
Ключевой характеристикой аппратно-программного комплекса являлась производительность. Как упоминалось ранее, микроядерная архитектура способствует повышению защищенности системы, но, в то же время, может
способствовать деградации производительности. При анализе производительности мы использовали ОС Linux в качестве эталонной, исполняемой
на таком же оборудовании без использования гипервизора.
Для измерения производительности сети были использованы два компьютера - рабочая станция разработчика (далее - PC Host) и сервер, представляющий собой аппаратную часть разрабатываемого комплекса (далее
SRV). Оба компьютера оснащены сетевым контроллером Intel 82579LM с
пропускной способностью 1Гб/с. Для проведения тестов использовалась программа netperf [1].
Были проведены тесты приема и передачи данных. В первом случае один
экземпляр программы netperf запускался в режиме сервера внутри среды
L4Linux, а другой - в режиме клиента на рабочей станции под управлением Linux (на графике данная конфигурация обозначена как «SRV Host PC Client»). Во втором случае («PC Host - SRV Client») в L4Linux netperf
запускался в режиме клиента. Для рабочей станции использовался дистрибутив Fedora Linux 18 с версией ядра Linux 3.8; при запуске на сервере в
среде Genode использовалось ядро L4Linux версии 3.5, в качестве корневой
файловой системы также использовался образ дистрибутива Fedora.
Результаты тестирования приведены на графике ниже (Рис. 3). Можно
выделить следующие особенности:
– Максимальная пропускная способность сети с использованием системы
L4Linux в среде Genode в 1.75 раз ниже, чем без использования паравиртуализации
– Показатели скорости передачи данных отличаются для входящего и исходящего трафика. Скорость приёма данных почти в 10 раз ниже, чем
без использования паравиртуализации.
152
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-152-320.jpg)
![9
сообщений замедляет работу исследуемой программы. Для решения этой
задачи был реализован сервис, сохраняющий отладочный журнал в оперативную память. Был использован существующий драйвер ram_fs в среде
Genode, который реализует файловую систему в оперативной памяти. По
окончании тестирования журнал копировался с тестового компьютера через
HTTP интерфейс, предоставляемый сервером lighttpd, запущенным в среде
Genode.
В приведенной ниже таблице 1 представлено среднее время выполнения
функций сетевого стека (в тиках процессора).
Процедура
Количество тиков
Файл
dde_kit_sem_up
dde_kit_sem_down
memcpy
13
59
23
lib/nic.c [dde_ipxe]
lib/nic.c [dde_ipxe]
lib/nic.c [dde_ipxe]
get_acked
submit_packet
packed_descriptor
46
190-160K
10
nic/component.h [Nic]
nic/component.h [Nic]
nic/component.h [Nic]
get_packet
acknowledge_packet
submit_packet
memcpy
Таблица 1. Время
3.2
8
lib/l4lx/genode_net.cc [L4Linux]
254
lib/l4lx/genode_net.cc [L4Linux]
65
lib/l4lx/genode_net.cc [L4Linux]
25
lib/l4lx/genode_net.cc [L4Linux]
выполнения процедур сетевого стека
Анализ результатов профилирования
Как следует из таблицы 1, наиболее затратная операция - submit_packet,
которая помещает пакет в циклический буфер и делает IPC запрос к другому процессу. При тестировании программой netperf было обнаружено, что
при длительной передаче данных время выполнения операции submit_packet
спорадически увеличивается на несколько порядков. Было сделано предположение, что причинами такого поведения могут быть как особенности реализации драйверов устройств, так и алгоритмов управления процессами и
памятью в ядре ОС.
Драйвера устройств
Одной из причин несимеетричной производительности сетевой подсистемы при приеме и передаче данных может являться реализация обработки
аппаратных прерываний в микроядре Fiasco.OC. В Genode не реализована поддержка прерываний, инициируемых сообщениями (MSI-X) для шины
PCI. Это не позволяет назначить обработчик для прерывания, сигнализирующего о наличии входных данных на сетевом интерфейсе, и приходится
154
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-154-320.jpg)
![10
использовать прерывание от шины PCI, которое может быть разделено с
другими устройствами, что может приводить к увеличению времени обработки входящего трафика. Кроме того, драйвер контроллера прерываний
IO APIC на некоторых системах, оставляет контроллер в состоянии, в котором тот остался на момент загрузки, не реализуя включение/выключение
источника прерываний, что осложняет отладку программного комплекса.
Управление памятью
В процессе тестирования программа netperf последовательно увеличивает размер сетевых пакетов. При длительном тестировании наблюдается
большой разброс времени выполнения операции submit_packet, в связи с
чем было сделано предположение, что драйвер сетевого интерфейса тратит
много времени в ожидании выделения памяти для очередного пакета. С
целью проверки этого предположения были увеличены в 8 раз размеры буферов для входящих и исходящих данных. Поскольку увеличение размеров
буферов не внесло изменений в поведение системы, необходимо было провести исследование поведения алгоритма выделения памяти. Для управления
памятью в сетевой подсистеме Genode используется алгоритм SLAB[2], который содержит несколько списков блоков памяти фиксированного размера
(1Кб, 2Кб, 16Кб и т.д.). Память для пакетов с данными организована в виде
кольцевого буфера, где пакет, освобожденный одним из сервисов (например,
драйвером сетевого адаптера DDE_ipxe), попадает в очередь свободных пакетов другого сервиса (драйвер виртуального сетевого интерфейса L4Linux).
При передаче региона памяти в процесс другого сервиса выполняется операция освобождения региона (unmap), и операция выделения памяти в новом
процессе. При конфигурации микроядра Fiasco.OC для поддержки многопроцессорного режима (SMP), реализация многих алгоритмов и структур
данных, в том числе примитивов синхронизации (мьютексов), отличается
от однопроцессорной версии. Кроме того, при использовании нескольких
процессоров потоки, выполняющие системные функции (обработку прерываний, ввод-вывод) и пользовательские задачи выполняются одновременно.
Для определения влияния данных различий на производительность системы, было проведено тестирование в двух режимах: при включении всех ядер
процессора поддержки SMP в Fiasco.OC (время выполнения теста составило
24929000 мкс), и при использовании одного ядра и отключения SMP (146000
мкс). При использовании одного ядра процессора, разница между скоростью
приема и передачи данных уменьшается. В многопроцессорном режиме планировщик проводит значительную часть времени (до 30%) в режиме простоя
(idle thread) вместо того, чтобы передавать управление потокам приложений. Изучение причин такого поведения планировщика и сравнение с другими микроядрами, поддерживаемыми средой Genode является задачей для
дальнейших исследований.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
155](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-155-320.jpg)
![SQL Server BCP и Oracle SQL*Plus. Конвертация данных проводилась в три
этапа: часть данных конвертировалась при выгрузке, часть при загрузке,
оставшиеся конвертации проводились как отдельный шаг после загрузки.
В настоящей статье даётся более технически подробное описание реализованного авторами этапа тестирования – верификации корректности
миграции путем сравнения набора хэшей.
2. Связанные работы
Методологии миграции баз данных описаны в нескольких статьях. В статье
[7] представлен пример методологии миграции данных. Процесс миграции
между базами данных с отличающимися моделями данных, сопутствующие
риски и проблемы описаны в [9] и [1]. Методологии миграции legacy-систем
представлены в [15].
Проекты миграции баз данных сталкиваются со специфичными рисками
и проблемами. Типичные риски и подходы к тестированию и обеспечению
качества описываются в [11]. Разновидности тестирования, применяемые
в течение жизненного цикла проекта миграции, рассматриваются в [12].
Общая схема организации обеспечения качества нашего проекта описана в
статье [8].
Вопросы хэширования неупорядоченных коллекций (множеств и мультимножеств) рассматриваются в [4]. В этой же работе впервые вводится определение устойчивости хэш-функции множества (мультимножества)
к коллизиям. Хэширование неупорядоченных коллекций тесно связано с
инкрементальным хэшированием. Результаты с использованием операции
XOR получены в работах [10] и [3]. Подход к хэшированию таблиц, использованный в нашем проекте, напоминает MSet-XOR-Hash из статьи [4].
Схожие подходы используются в похожей задаче поддержания консистентности реплицированных баз данных. К таким работам относятся: статьи [5], [6] и доклад [2]. В данных статьях не рассматривается сравнение
БД, находящихся под управлением разных СУБД.
3. Требования к методу
На этапе планирования проекта было решено, что совпадение данных в
исходной и целевой БД должно быть проверено отдельным инструментом.
Были сформулированы требования к инструменту:
1. Сравнение БД, находящихся в разных СУБД. Все используемые методы должны быть реализованы в MS SQL Server 2005 и Oracle 11gR2.
2. Настраиваемая процедура сравнения.
3. Независимость результата сравнения от порядка записей в выборках.
Это требование связано с тем, что СУБД не гарантируют порядок выдачи результатов для выборки без явной директивы ORDER BY. От
добавления явной директивы для упорядочивания отказались по двум
причинам: отсутствие первичного ключа или уникального индекса у
части таблиц, и существенное увеличение времени работы при упорядочивании без использования индекса.
2
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
159](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-159-320.jpg)
![4.3. Расчет хэшей
Для каждой таблицы вычисляются n+2 хэша, где n – количество столбцов.
Первый - количество записей в таблице. Несовпадение количества записей
позволяет выявить грубые ошибки перегрузки, но совпадение возможно при
искажениях в значениях данных, что является большим недостатком, особенно для таблиц, содержащих типы данных, трансформирующиеся при
миграции.
Остальные хэши предназначены для устранения этого недостатка. Они
рассчитываются следующим образом: записи таблицы обрабатываются одна за одной в произвольном порядке – выполняется запрос SELECT COLU M N1 ,
COLU M N2 ,· · ·, COLU M NN FROM TABLE.
Значение каждого поля преобразуется в массив байтов, например, datetime
преобразуется в количество миллисекунд с 01.01.1970 00:00:00 (POSIX time)
как bigint. Получившееся число интерпретируется как массив байтов. Массивы конкатенируются. Получившийся массив подается на вход хэш-функции.
Может быть использована любая, реализация которой доступна в обеих
СУБД. Авторами была выбрана MD5 [13]. Возвращенное значение представляет собой хэш записи. Данная операция может интерпретироваться
как создание дополнительного столбца в таблице. Набор хэшей таблицы не
должен зависеть от порядка обхода записей, поэтому было принято решение
использовать коммутативную операцию XOR (исключающее или) для получения итоговых хэшей из хэшей записей: для каждого столбца, включая
“виртуальный” столбец хэшей записей, вычисляется XOR всех элементов.
MD5 – криптографическая хэш-функция, поэтому возвращаемое значение можно рассматривать как равномерно распределенную случайную
величину из интервала [0; 2128 − 1]. XOR таких величин не меняет распределение, поэтому XOR “виртуального” столбца хэшей записей можно рассматривать как равномерно распределенную случайную величину из интервала [0; 2128 − 1]. В исходной БД количество записей в каждой таблице
не превышает 1013 . Вероятность обнаружения не менее одной коллизии не
превышает 10−12 [14]. Четное количество идентичных записей из-за свойства XOR(x, x) ≡ 0 может скрыть ошибку в миграции какого-либо типа
данных, но отладка метода производилась с использованием таблиц, содержащих уникальные записи. Вероятность же нескольких аппаратных сбоев,
не попавших в журнал, и, повлиявших только на четное количество идентичных записей в одной таблице, оценивается как пренебрежимо малая.
Таблицу БД с первичным ключом можно рассматривать как множество. Изложенный выше метод отличается от MSet-XOR-Hash [4] для хэширования (мульти)множеств отсутствием рандомизации – хэш-функция
фиксирована, а не выбирается из некоторого семейства. Это делает метод
уязвимым для целенаправленной атаки. Однако во время разработки он
позволил выявить ряд ошибок в процессе перегрузки.
Остальные хэши вычисляются не криптографическими хэш-функциями,
но на этапе отладки они облегчали процесс поиска источников ошибок.
Поскольку данные могут подвергнуться трансформации при перегрузке
и представляться разными наборами байтов, вычисление хэш-функции может завершиться с разными результатами в исходной и целевой БД. Для
унификации результатов значения полей приводятся к нормальной форме для составления аргумента хэш-функции по правилам, изложенным в
4
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
161](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-161-320.jpg)
![Этап
Выгрузка из MSSQL
Хэширование в MSSQL
Загрузка в Oracle
Хэширование в Oracle
Время (сек.)
1109
799
2134
2279
Таблица 2: Время этапа миграции тестового набора данных
ошибки в процедуре перегрузки и процедуре вычисления хэшей.
Для доказательства эквивалентности изменений, совершаемых в исходной и целевой БД, при воспроизведении трасс типичных действий пользователя были сгенерированы журналирующие триггеры, вычисляющие хэши
перехваченных наборов записей по описанной выше схеме.
6. Заключение
Примененный метод сравнения содержимого баз данных путем подсчёта использующий коммутативные и криптографические хэш-функции позволил
успешно решить поставленную перед авторами задачу: было реализовано
автоматизированное тестирование корректности миграции данных между
различными СУБД путем сравнения набора хэшей, что позволило устранить ряд методических ошибок перегрузки. Разработанный метод возможно
переиспользовать, при необходимости пополнив поддержкой типов данных,
не встретившихся в схеме исходной БД, и поддержкой СУБД, отличных от
MS SQL Server 2005 и Oracle 11gR2.
Список литературы
[1] Maatuk A. Migrating Relational Databases into Object-Based and XML
Databases. Northumbria University, 2009.
[2] Ulrich Arndt. How to compare tables between td systems in a dual active
environment. In The 2012 Teradata PARTNERS Conference, 2012.
[3] Mihir Bellare, Oded Goldreich, and Shafi Goldwasser.
Incremental
cryptography: The case of hashing and signing. In In CRYPTO, 1994.
[4] Dwaine Clarke, Srinivas Devadas, Marten van Dijk, Blaise Gassend, and
G. Edward Suh. Incremental multiset hash functions and their application
to memory integrity checking. In In Advances in Cryptology - Asiacrypt
2003 Proceedings, volume 2894 of LNCS, pages 188–207. Springer-Verlag,
2003.
[5] Fabien Coelho. Remote comparison of database tables technical report
a/375/cri, 2006.
[6] Fabien Coelho. Remote comparison of database tables. In DBKDA 2011 :
The Third International Conference on Advances in Databases, Knowledge,
and Data Applications, 2011.
8
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
165](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-165-320.jpg)
![[7] Hudicka J. The Complete Data Migration Methodology. Dulcian Inc., 2000.
[8] I. Kirilenko and E. Baranov. Automation of QA in the project of
DB migration from SQL Server into Oracle. In Proceedings of the 6th
Spring/Summer Young Researchers’ Colloquium on Software Engineering
(SYRCoSE 2012), pages 178–181. Perm, Russia, May 30-31, 2012.
[9] Chang-Yang Lin. Migrating to relational systems: Problems, methods, and
strategies. 4(4):369–380, 2008.
[10] R. Guerin M. Bellare and P. Rogaway. Xor macs: New methods for message
authentication using finite pseudorandom functions. In In CRYPTO, 1994.
[11] Haller K. Matthes F., Schulz C. Testing quality assurance in data
migration projects. In 2011 27th IEEE International Conference, 2011.
[12] Augustinez J. Redlichx A. Lodha S. Vin H. Deshpande A. Gharote M.
Mehrotrak A. Patil S., Royy S. Minimizing testing overheads in database
migration lifecycle. In The 16th International Conference on Management
of Data (COMAD), 2010.
[13] Ronald L. Rivest. The md5 message-digest algorithm. Internet RFC 1321,
April 1992.
[14] Bruce Schneier. Applied Cryptography, Second Edition. John Wiley Sons,
1996.
[15] Bisbal J. Grimson J. Wade V. O’Sullivan D. Richardson R. Wu B.,
Lawless D. Legacy system migration : A legacy data migration engine.
In Proccedings of the 17th International Database Conference, pages 129–
138. Springer-Verlag, 1997.
166
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
9](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-166-320.jpg)
![Применение технологий OLAP и MapReduce для
обработки результатов нагрузочного тестирования
Сенов А.А.
Костромской государственный технологический университет
г. Кострома, ул. Дзержинского, 17
andrey.senov@gmail.com
Аннотация. Современные трейдинговые платформы представляют собой
сложные распределённые системы, обслуживающие большое число
пользователей
по различным протоколам передачи данных. При
нагрузочном тестировании таких систем возникает существенный объём
информации, которая может быть проанализирована QA-специалистами с
целью обнаружения дефектов. Для этого часто требуется выявлять
зависимости между значениями показателей, полученными в ходе
тестирования, путём проведения многофакторного анализа, что при
большом объёме данных является трудоёмкой задачей, требующей
специализированного ПО, в частности, систем интерактивной
аналитической обработки OLAP. В данной статье описывается
оригинальный алгоритм многомерного анализа результатов нагрузочного
тестирования на стороне клиента. С помощью технологии MapReduce
предложенный алгоритм оптимизирован для работы под управлением
многоядерных процессоров. Ключевые слова: OLAP, MapReduce,
нагрузочное тестирование, анализ данных
1 Введение
Анализ результатов нагрузочного тестирования трейдинговых платформ в
большинстве случаев связан с обработкой существенных объёмов информации.
Это обусловлено тем, что современные платформы являются сложными
распределёнными системами, обрабатывающими свыше 40 тысяч заявок в
секунду при среднем времени отклика менее 300 микросекунд. С другой
стороны,
аппаратная
инфраструктура
тестовых
инструментов
по
производительности на несколько порядков уступает биржевой. Это неизбежно
влечёт необходимость разрабатывать инструменты как можно более простые, не
перегруженные функциональностью, для достижения высокой эффективности
при решении основных задач[1]. В связи с этим при анализе данных,
полученных в ходе нагрузочного тестирования, чтобы быстро ответить на
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
179](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-179-320.jpg)
![поставленные
вопросы,
возникает
потребность
в
использовании
специализированного ПО, к какому можно отнести большой класс продуктов
бизнес-аналитики BI (англ. Business Intelligence). Среди программных решений
BI-класса можно выделить системы интерактивной аналитической обработки
OLAP (англ. Online Analytical Processing), предназначенные для построения
обобщённой информации на основе данных, имеющих многомерное
представление. При нагрузочном тестировании такие системы помогают QAаналитикам (англ. Quality Assurance) качественно осуществить многофакторный
анализ зависимостей между значениями показателей, полученными в ходе
тестирования, с целью обнаружения дефектов платформы.
2 Существующие Решения
В основе любой OLAP-системы лежит многомерная модель данных, называемая
многомерным кубом, гиперкубом или просто кубом. По месту нахождения
машины, рассчитывающей многомерные кубы, современные OLAP-системы
можно разделить на две группы: клиентские и серверные. В случае клиентской
системы сервер отправляет клиенту исходные данные, клиент производит
расчет многомерных кубов и выдает результат пользователю. В случае
серверной системы сервер рассчитывает многомерные кубы и отправляет
результат клиенту, клиент выдает результат пользователю[2].
На сегодняшний день обе группы представлены на рынке широким спектром
продуктов. Для серверных систем это, например, такие решения, как Microsoft
SQL Server Analysis Services[3], OLAP Option to Oracle Database[4] или Palo[5].
Серверные решения являются наиболее быстрыми, надежными и имеют ряд
других преимуществ: например, техническую поддержку от производителей.
Как следствие, такие системы являются дорогостоящими. Можно принять во
внимание наличие open-source версии Palo, но она имеет существенные
ограничения по сравнению с коммерческой: например, отсутствие возможности
использования более чем одного ядра процессора[6].
Среди клиентских решений популярными остаются электронные таблицы MS
Office Excel, позволяющие выполнять многомерный анализ с помощью
механизма Pivot table[7]. Pivot table удобно использовать, когда исходные
данные изначально заносятся в электронную таблицу, что при серьёзных
задачах, таких как нагрузочное тестирование, исключено. Поэтому
пользователь обязательно сталкивается со сложностью конфигурации
подключения к внешним источникам данных.
Факт наличия на рынке разнообразных продуктов, обладающих своими
достоинствами и недостатками, говорит о том, что для OLAP, как и для многих
сложных задач, до сих пор нет единого решения, одинаково подходящего для
всех. В рамках статьи предлагается рассмотреть оригинальный алгоритм
многомерного анализа результатов нагрузочного тестирования на стороне
клиента. Решение главным образом направлено на сокращение затрат на
тестовые и аналитические инструменты.
180
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-180-320.jpg)
![3 Предлагаемое Решение
В случае тестирования биржевых платформ существует несколько основных
источников, из которых можно получить информацию для анализа:
1. Данные, которыми оперируют непосредственно тестовые инструменты;
2. Статистическая информация из внутренней базы данных платформы, а
также записи журналов активности её компонентов и пользователей;
3. Независимые данные, полученные напрямую от сетевых устройств, через
которые происходит общение клиентов с платформой.
Опыт показывает, что наиболее достоверным является источник под номером
3, но для полноты картины поведения тестируемой системы данные обычно
собираются изо всех трёх источников и складываются в общую базу. Данные,
как правило, представляют собой разнообразные сведения о типах сообщений,
значениях полей сообщений, клиентах, разного рода настройках и, конечно,
временных отметках. Опираясь на весь этот массив информации, аналитики
оценивают такие параметры, как время отклика, количество сообщений,
пропускную способность, используемую память, загрузку процессоров и
прочее[8].
При создании алгоритма основным принципом служила простота, и вся его
суть сводится к выполнению операций над generic-контейнерами в оперативной
памяти клиентской машины. Перенос вычислений на сторону клиента
обусловлен высокой производительностью современных настольных ПК,
сочетающейся с их низкой стоимостью. Так, например, в настоящее время
конфигурация среднего рабочего места это: процессор с 2-4 ядрами и 4-8 ГБ
оперативной памяти. Такие характеристики в сочетании с гигабитными сетями,
использующимися уже повсеместно, позволяют решить задачу многомерного
анализа без привлечения дополнительных ресурсов.
Алгоритм написан на языке C++ с применением Qt Framework, что даёт такие
преимущества, как высокое быстродействие, кроссплатформенность, а также
возможность использования настольной реализации технологии MapReduce[9] с
целью получения масштабируемого решения для работы под управлением
многоядерных процессоров.
Как было сказано выше, в основе любой OLAP-системы лежит гиперкуб. И
первая проблема, которую необходимо решить, – это представление гиперкуба с
точки зрения кода. Для этого сначала необходимо определиться, как
информация будет попадать из базы данных в гиперкуб. Ответ очевиден –
нужно выполнить SQL-запрос SELECT. Запросы предлагается писать по
правилам, которые отражены в листинге 1.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
181](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-181-320.jpg)
;
private:
QVector QVectorCell _data;
};
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
183](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-183-320.jpg)
![QString key;
int i = 0;
foreach (const QString dimension, _xDimensions) {
i = _dimensions[dimension];
key += tuple.keys()[i];
}
keys.first = key;
key.clear();
foreach (const QString dimension, _yDimensions) {
i = _dimensions[dimension];
key += tuple.keys()[i];
}
keys.second = key;
return keys;
}
void reduceFullKeys(int /*i*/, const QPairQString,
QString keys)
{
_xCoordinates[keys.first] = -1;
_yCoordinates[keys.second] = -1;
}
Функция mapFullKeys в листинге 5 вызывается для каждого элемента
гиперкуба параллельно. Имена выбранных для отчёта измерений представлены
в виде двух списков: _xDimensions, _yDimensions. С помощью словаря
_dimensions восстанавливаются индексы измерений и уже по индексам
извлекаются их значения. В случае если на строки отчёта отображаются
несколько измерений гиперкуба, то ключ будет представлять собой
конкатенацию значений измерений. То же самое справедливо и для столбцов. В
итоге функция возвращает пару ключей, которая автоматически передается
функции reduceFullKeys, которая, в свою очередь, помещает ключи в
формируемые словари _xCoordinates и _yCoordinates. В итоге словари будут
состоять из уникальных ключей, автоматически отсортированных в порядке
возрастания.
На втором шаге оба словаря перебираются по порядку и ключам
присваиваются возрастающие значения: 0, 1, 2, 3 и т.д. Таким образом, словари
в качестве ключей содержат заголовки столбцов и строк будущего отчёта, а в
качестве значений – их порядковые индексы.
Реализация третьего шага отображена ниже:
Листинг 6. Функции Map и Reduce для заполнения отчёта.
QMapQString, int _dimensions;
QMapQString, int _xCoordinates, _yCoordinates;
QStringList _xDimensions, _yDimensions;
Projection _projection;
Cell mapProjection(const Tuple tuple)
{
186
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-186-320.jpg)
![QString key;
foreach (const QString dimension, _xDimensions) {
int i = _dimensions[dimension];
key += tuple.keys()[i];
}
int x = _xCoordinates[key];
key.clear();
foreach (const QString dimension, _yDimensions) {
int i = _dimensions[dimension];
key += tuple.keys()[i];
}
int y = _yCoordinates[key];
return Cell(x, y, tuple.measure());
}
void reduceProjection(int /*i*/, const Cell cell)
{
_projection[cell.x()][cell.y()] += cell.value();
}
Функция mapProjection в листинге 6 строит уникальные ключи по той же
схеме, что и mapFullKeys в листинге 5. По ключам из сформированных ранее
словарей _xCoordinates и _yCoordinates извлекаются координаты ячеек отчёта, а
из текущего кортежа гиперкуба извлекается величина _measure. Все три
значения передаются в функцию reduceProjection в виде экземпляра класса Cell.
В свою очередь, reduceProjection по указанным координатам получает ячейку
отчёта и к её значению прибавляет величину _measure.
После распараллеливания алгоритма была проведена экспериментальная
оценка затрат времени на построение отчета по различным сочетаниям
измерений гиперкуба. Для того чтобы наглядно убедиться в эффективности
MapReduce, описанная выше реализация сравнивается с тестовой реализацией,
выполненной по технологии PTHREAD[10] с использованием примитивов
синхронизации.
Априори известно, что затраты времени зависят от ряда как контролируемых,
так и неконтролируемых факторов, таких как:
1. объём выборки из базы данных, т. е. размер гиперкуба;
2. количество и длины полных ключей измерений гиперкуба, выбранных для
построения отчёта;
3. количество параллельных потоков;
4. тип процессора: архитектура, количество ядер, частота, объём кэш;
5. объём и частота основной памяти;
6. тип, разрядность и версия операционной системы, частота системного
таймера;
7. версия Qt Framework.
Из перечисленных факторов, факторы с 4 по 7 являются неконтролируемыми
и, более того, все они быстро меняются с течением времени, поэтому их
влияние можно оценить только качественно.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
187](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-187-320.jpg)
![Первый фактор, пока объём выборки не превышает объем доступной
оперативной памяти, соответствует линейной зависимости затрат времени от
размера выборки; при этом соотношение затрат времени для различных
вариантов реализации параллельного кода должно оставаться постоянным,
поэтому в эксперименте рассматривается достаточно малый объём данных:
тестовый гиперкуб имеет 9 измерений и состоит из 66 354 кортежей.
Для оценки количества и размеров составных ключей предлагается
использовать обобщённый параметр K, для определения которого используется
следующее соотношение, основанное на том, что среднее время поиска в дереве
пропорционально его глубине, а среднее время сравнения двух строк
пропорционально их длине[11]:
K= log2(N)*L .
(1)
где: K– обобщённый параметр; N– количество ключей; L– средняя длина
ключа.
Так как отчёт является двумерным массивом, то результирующий показатель
будет равен сумме показателей для колонок и строк:
K = Kx + Ky = log2(X)*Lx + log2(Y)*Ly .
(2)
где: K – результирующий параметр; Kx,y – обобщённые параметры для
колонок и строк; X, Y – количество ключей; Lx,y – средние длины ключей.
Для проведения экспериментов использовался компьютер с 6-ядерным
процессором AMD Phenom II X6 1100T и 4 Гб ОЗУ; операционная система
Linux KUbuntu 12.04 LTS 64-bit с версией ядра 3.2; Qt Framework версии 4.8.4.
Данные снимались в 10-кратной повторности. Для определения затрат времени
на формирование словарей с ключами и заполнение отчёта использовался
системный вызов clock_gettime.
На рисунке 2 представлены общие затраты времени для сравниваемых
технологий: однопоточного варианта, многопоточного варианта на MapReduce
и многопоточных вариантов на PTHREAD - в зависимости от значений
предлагаемого обобщенного параметра K.
188
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-188-320.jpg)
![Литература
1. Иткин И.Л.: Тестирование биржевых систем в условиях высокочастотного трейдинга
//
SQA
Days
#10:
[Электронный
ресурс].
Режим
доступа:
http://sqadays.com/talk.sdf/sqadays/11151/talks/12196
2. Каширин И.Ю., Семченков С.Ю.: Интерактивная аналитическая обработка данных в
современных OLAP-системах // Бизнес-информатика. 2009. Вып. 2(8).
3. SQL Server Analysis Services - Multidimensional Data // MSDN: [Электронный ресурс].
Режим доступа: http://msdn.microsoft.com/en-us/library/bb522607(v=sql.105).aspx
4. Oracle
OLAP
//
Oracle:
[Электронный
ресурс].
Режим
доступа:
http://www.oracle.com/technetwork/database/options/olap/index.html
5. Palo by Jedox // Palo: [Электронный ресурс]. Режим доступа: http://palo.net/
6. Comparison - Palo (Open Source) / Jedox (Premium) // Palo: [Электронный ресурс].
Режим доступа: http://www.palo.net/index.php?id=13
7. Jelen Bill, Alexander Mike. Pivot table data crunching. Pearson Education: 2011.
8. Alexey Zverev: Technical Testing // EXTENT February 2011: [Электронный ресурс].
Режим доступа: http://www.slideshare.net/IosifItkin/technical-testing-introduction
9. Qt 4.8: Concurrent Programming // Qt Reference Documentation: [Электронный ресурс].
Режим доступа: http://doc-snapshot.qt-project.org/4.8/threads-qtconcurrent.html
10. Blaise Barney: POSIX Threads Programming // Lawrence Livermore National Laboratory:
[Электронный ресурс]. Режим доступа: https://computing.llnl.gov/tutorials/pthreads/
11. Кнут Д. Э.: Искусство программирования, том 3. Сортировка и поиск, 2-е издание. –
М.: Издательский дом «Вильямс», 2003.
190
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-190-320.jpg)
![Особенности инструментов для тестирования,
применимых при промышленной эксплуатации
трейдинговых систем
Aнастасия Матвеева1, Николай Антонов2, Иосиф Иткин3
1
ООО «Инновационные Трейдинговые Системы», Россия, 156013, г. Кострома,
ул. Ленина, 20, Anastasia.Matveeva@exactpro.com
2
Костромской государственный технологический университет, г. Кострома,
ул. Дзержинского, 17, Nikolay.Antonov@exactpro.com
3
Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA
Iosif.Itkin@exactpro.com
Aннотация. В статье рассматриваются основные требования к
инструментам, разработанным для верификации корректной работы
электронных трейдинговых систем с использованием методов большого
объема автоматизированного тестирования (НiVAT); анализируется
применимость подобных инструментов при промышленной эксплуатации
трейдинговых систем. Ключевые слова: автоматизация тестирования,
трейдинговые системы, HiVAT.
1 Введение
Ускоренное развитие технологий, используемых в электронных
трейдинговых системах, признается одним из наиболее существенных
факторов, влияющих на изменения в структуре и стабильности
функционирования международных финансовых рынков [1]. Решения,
обеспечивающие качество программных и архитектурных компонентов,
становятся все более востребованными участниками рынка и организациями,
регулирующими финансовый сектор [2; 3].
С технологической точки зрения трейдинговые системы в большинстве
случаев являются сложными адаптивными распределенными программноаппаратными комплексами, осуществляющими параллельное выполнение
большого количества транзакций в режиме реального времени [4].
Современные системы обеспечивают время отклика, измеряемое долями
миллисекунды, и при своей работе генерируют значительные объемы данных
[5].
В связи с возрастающей долей финансовых транзакций, осуществляемых
посредством автоматизированных компьютерных систем [6], основные
взаимодействия в трейдинговых системах базируются на различных открытых и
закрытых сетевых протоколах и программных интерфейсах доступа [7].
Специфика автоматизированных рабочих мест пользователя трейдинговой
системы состоит, в частности, в высокой частоте обновления данных о
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
191](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-191-320.jpg)
![котировках, статусе выполнения финансовых транзакций, текущих позициях и
рисках [8].
Рассмотрим несколько ключевых аспектов обеспечения качества
трейдинговых систем:
Как и другие сложные многопоточные системы, трейдинговые платформы
предрасположены к появлению в них трудновоспроизводимых сбоев [9],
которые проявляются, исключительно когда система находится под нагрузкой.
Часто речь идет о функциональных проблемах, не связанных с исчерпанием
ресурсов системы, но вызванных ситуацией конфликтующих друг с другом по
времени условий (race conditions) при обработке параллельных транзакций или
проявлением
статистически
маловероятных
внутренних
нарушений
целостности [10]. Нахождение таких проблем требует проведения верификации
на границе между функциональным и нагрузочным тестированием [11];
Обеспечение полноты покрытия тестами функциональности трейдинговой
системы требует большого
количества
сценариев
в
библиотеке
автоматизированных тестов [12]. Количество нуждающихся в проверке
комбинаций особенно велико для производных и составных финансовых
инструментов [13]. Даже однократный прогон сценариев такой библиотеки
тестов через систему приводит к продолжительному исполнению
последовательности автоматических тестов. Многократный запуск позволяет
выделить скрытые проблемы с внутренними состояниями системы;
Регулирующие органы, акционеры и участники торгов ожидают высокой
устойчивости биржевых и брокерских систем к непредусмотренным внешним
воздействиям [3]. В научной литературе детально проработаны методы
тестирования устойчивости, основанные на прогоне большого количества
случайно созданных данных через систему — фаззинге (fuzzing) [14].
Описанные выше свойства приводят к необходимости отправки большого
количества созданных для тестирования сообщений в систему в течение
продолжительного периода времени. Для обнаружения дефектов, связанных с
обработкой потоков сообщений, необходима доскональная функциональная
верификация выходящих сообщений и внутренних состояний системы.
Применимые для этого методы известны под аббревиатурой HiVAT –
большие объемы автоматизированного тестирования (High Volume Automated
Testing) [15; 16; 17]. Эти методы направлены на выявление проблем, которые с
большой долей вероятности могут остаться незамеченными при использовании
других подходов, требующих ручного создания сценариев для автоматического
тестирования и приводящих к статистически недостаточному количеству
выходных данных.
Опыт авторов показывает, что для высоконагруженных трейдинговых систем
использование HiVAT-методов служит не столько возможным способом
расширения покрытия тестированием, сколько обязательным методом их
тестирования в условиях, приближенных к использованию в режиме
промышленной эксплуатации.
Продолжительное применение HiVAT-методов позволило выявить основные
требования к инструментам тестирования. Эти требования перечисляются во
второй части данной статьи. Третья часть посвящена сравнению инструментов
тестирования с трейдинговыми системами, используемыми в промышленной
192
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-192-320.jpg)
![эксплуатации. В последней части приведены возможные расширения созданных
средств и направления дальнейших исследований.
2 Требования к инструментам тестирования
По влиянию на тестируемую систему инструменты тестирования можно
разделить на два типа: пассивные и активные [18]. Пассивное тестирование —
это процесс обнаружения неисправностей в тестируемой системе путем
исследования ее поведения без оказания воздействий на нормальный процесс
работы. Активные инструменты непосредственно воздействуют на
трейдинговую систему и используются для обмена сообщениями, анализа
полученных от системы откликов, нагрузочного тестирования.
2.1 Пассивные инструменты тестирования
Пассивные инструменты тестирования используются для автоматизированного
сбора логов, структурирования данных, мониторинга и анализа поведения
системы, сертификации пользователей. Инструменты тестирования позволяют
оперативно исследовать большой объем данных, реагировать на отклонения в
поведении системы от установленных требований, локализировать неполадки.
Инструмент тестирования позволяет эффективно решать эти задачи, если
выполнены следующие требования:
обеспечена полнота сбора данных обо всех событиях в системе;
минимизировано влияние на систему;
обеспечено оповещение в реальном режиме времени о нестандартных
ситуациях;
реализованы гибко настраиваемые критерии распознавания образов;
обеспечено хранение и предоставление доступа к историческим данным;
предоставлена возможность отслеживать последовательность событий и
внутренние состояния системы на определенный момент времени.
Нахождение первопричины сбоя, произошедшего при использовании HiVATметодов, зачастую является более сложным процессом по сравнению с
обычными методиками ручного и автоматизированного тестирования. Эта
сложность обусловлена, в основном, двумя факторами: автоматическим
созданием сценариев тестирования и большим объемом разнородных данных,
пропущенных через систему. Тестировщику необходимы удобные
инструменты, информирующие его о возникновении проблем и позволяющие
детально исследовать состояние системы до и после возникновения сбоев.
Недетерминированный характер входного потока сообщений, являющийся
отличительной чертой использования HiVAT-методов, подразумевает
необходимость в гибкости сценариев распознавания проблем и предоставление
тестировщику возможностей по их настройке.
Невозможно обеспечить полноту сбора информации без присутствия эффекта
измерения для высоконагруженной системы. Задача инструмента тестирования
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
193](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-193-320.jpg)
![состоит в том, чтобы минимизировать влияние самого инструмента на
функциональность и производительность тестируемой системы.
Инструмент дожен предоставлять доступ к детальным и аггрегированным
данным, полученным в результате выполнения текущей и предыдущих
итераций тестирования. Диаграмма на рис. 1 показывает компоненты
необходимые для реализации перечисленных требований к пассивным
инструментам тестирования.
Рис. 1. Высокоуровневая схема основных компонентов инструмента для пассивного
тестирования трейдинговых систем
2.2 Активные инструменты тестирования
Инструмент для активного тестирования должен обладать универсальностью, то
есть способностью подключаться к различным тестируемым окружениям,
используя
разнообразные
протоколы.
Применение
фаззинга
для
распределенных трейдинговых систем накладывает ограничения на
создаваемые сообщения [25] с целью обеспечить их прохождение к ядру и
другим внутренним компонентам без блокирования их на внешних шлюзах
протокольных подключений или на начальных ступенях защиты модулей
контроля рисков.
Автоматический характер создания сценариев тестирования и их значительный
объем требует сохранения информации об отправленных сообщениях и
внутренних состояниях инструмента тестирования, его настройках. При
использовании сложных техник необходима также сверка данных между
инструментом и тестируемой системой.
Использование HiVAT-методов для высоконагруженных трейдинговых систем
требует
создания
масштабной
инфраструктуры
для
тестирования.
194
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-194-320.jpg)
![ удобность и интерактивность.
Эти
обязательные
характеристики
совпадают
с
предъявляемыми к промышленным трейдинговым системам.
требованиями,
3
Использование
инструментов
тестирования
промышленной эксплуатации трейдинговых систем
в
В этой части статьи мы сопоставим требования, предъявляемые к инструментам
для тестирования трейдинговых систем с использованием методов HiVAT, с
требованиями к трейдинговым системам и системам мониторинга,
используемым в промышленной эксплуатации.
Таблица 1. Требования к системам мониторинга и контроля финансовых рисков
Требование
Полнота сбора данных
обо всех событиях в
системе
Минимизация влияния
на трейдинговую
систему
Оповещение в реальном
режиме времени о
нестандартных
ситуациях
Использование в промышленной эксплуатации
Основная задача системы мониторинга и контроля
финансовых рынков — поддерживать аналитическую
работу отделов, отвечающих за выявление возможных
манипуляций [19]. Система мониторинга должна собирать
информацию обо всех входящих заявках, ответах системы,
данных, поступающих из внешних источников, а также о
релевантных
внутренних
состояниях
трейдинговой
платформы.
Сбор большого объема информации невозможен без
масштабируемой
мониторинговой
инфраструктуры.
Наблюдение за рынком исключительно важный процесс,
являющийся обязательным в абсолютном большинстве
финансовых юрисдикций. Тем не менее, для обеспечения
минимальных времен отклика на приходящие в реальном
режиме времени сообщения операторы трейдинговых
систем стараются избегать негативного влияния эффекта
измерения на основную функциональность трейдинговой
платформы.
Операторы системы должны быть немедленно уведомлены
при
возникновении
технических
проблем
или
подозрительных
транзакций.
Такие
уведомления
называются
оповещениями
системы
мониторинга
(surveillance alerts). Эффективно работающая система
оповещения — ключевой компонент системы мониторинга
и контроля рисков.
Гибко настраиваемые
Очень часто недобросовестные участники рынка пытаются
критерии распознавания скрыть злоупотребления и манипуляции рынком под видом
образов
легитимных
финансовых
транзакций.
Системам
мониторинга и контроля рынков приходится делать
196
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-196-320.jpg)
![аналитические заключения на основе нечеткой логики,
параметры которой приходится непрерывно адаптировать
под новые трейдинговые ситуации и схемы поведения
участников торгов [20].
Хранение и
предоставление доступа
к историческим данным
По запросам аудита или регулирующих органов операторы
трейдинговых систем обязаны предоставлять исторические
данные и результаты их обработки
Возможность отследить
последовательность
событий и внутренние
состояния системы на
определенный момент
времени
Формальные критерии сами по себе не являются
достаточным доказательством наличия манипуляции.
Операторы
системы
нуждаются
в
возможности
восстанавливать последовательность событий относящихся
к конкретным эпизодам, вызвавшим оповещение о
проблеме. Данная функция называется проигрыванием
книги заявок (order book replay). Удобная реализация
позволяет операторам исследовать большее количество
событий и делать выводы о правильности работы
механизмов распознания образов.
Рис. 3. Высокоуровневая схема основных компонентов системы мониторига и контроля
финансовых рисков создаваемой в компании «Exactpro Systems», LLC.
Из схемы на рис. 3 видна концептуальная близость системы к инструментам для
пассивного тестирования трейдинговых платформ.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
197](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-197-320.jpg)
![Таблица 2. Требования к системам выполнения биржевых и алгоритмических заявок
Требование
Универсальность.
Подключение ко
множеству других
систем и поддержка
используемых ими
протоколов
Использование в промышленной эксплуатации
В условиях фрагментации финансовых рынков брокерские
системы должны обеспечивать возможность подключения к
разным биржевым системам и сторонним брокерам [21].
Высоконагруженная
трейдинговая
система
должна
Предоставление
одновременного доступа обеспечить одновременный доступ большому количеству
участников торгов
Возможность
выполнения сложных
сценариев
Хранение информации
обо всех отправленных
сообщениях и
внутренних состояниях.
Возможность сверки
этих данных с данными,
поступающими из
внешних систем,
включая клиринг и
депозитарии
198
Основная функция систем алгоритмической торговли —
предоставление пользователям возможности задавать
стратегию посылки заявок на выполнение финансовых
транзакций в зависимости от состояния рынка, портфеля,
параметров риска, информационных сообщений и т.д.
Оператор трейдинговой системы, предоставляющий доступ
своим клиентам на финансовые рынки, обязан хранить
информацию обо всех совершенных финансовых
транзакциях [22] и производить сверку этих данных с
данными клиентов и контрагентов, а также с информацией
из пост-торговых систем.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-198-320.jpg)
![сложных интегрированных трейдинговых систем [23]. Внесенные изменения
называются мутациями и основываются на мутационных операторах [24],
которые имитируют типичные ошибки или нежелательные воздействия.
Мутации также позволяют оценить эффективность существующего набора
тестов и качество инструментов для тестирования.
Операторами
мутации
трейдинговой
системы
для
проверки
нефункциональных свойств могут стать следующие изменения:
введение случайных задержек во внутренние компоненты, логические
алгоритмы и в функционирование внешних подключений;
замена оптимизированных TCP/IP потоков данных на множество
параметризованных библиотек на различных языках;
заполнение памяти или дискового пространства на компьютере с
исследуемой системой большим количеством логов;
загрузка сети паразитными сообщениями или внедрение ошибок в
структуры данных.
Второе направление дальнейших исследований - это изучение методов
фаззинга, совместимых со структурой и консистентностью промышленных
систем [25].
5 Заключение
На основе обобщения опыта по верификации корректной работы
высоконагруженных электронных трейдинговых систем с функциональной и
нефункциональной точек зрения в статье проанализированы методы
обеспечения их качества, основанные на большом объеме автоматизированного
тестирования (НiVAT).
Практическое использование этих методов авторами позволило определить
набор основных требований к инструментам пассивного и активного
тестирования, применяемым для верификации подобного рода систем. В статье
сделан вывод, что инструмент для тестирования, соответствующий
определенному набору требований, является по своей сути системой,
применимой при промышленной эксплуатации трейдинговых систем.
Полученные
авторами
результаты
обосновали
оправданность
финансирования создания инструментов для тестирования, основанных на
описанных выше методах и принципах. В рамках проектов компании «Exactpro
Systems», LLC разрабатываются: система мониторинга и контроля финансовых
рынков и система поддержки алгоритмической торговли. Обе системы имеют
двойное назначение и могут использоваться и как инструмент для тестирования,
и как самостоятельный элемент промышленной трейдинговой инфраструктуры
[26].
Выше были рассмотрены также дополнительные возможности по
использованию методов мутационного тестирования на системном уровне для
анализа
и
расширения
полноты
покрытия
функциональными
и
нефункциональными тестами. Указанные возможности открываются при
включении инструментов тестирования в состав трейдинговой платформы.
200
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-200-320.jpg)
![Литература
1. The Future of Computer Trading in Financial Markets. Final Project Report. / Foresight. The
Government Office for Science, London. // [Электронный ресурс]. – Режим доступа
http://www.bis.gov.uk/assets/foresight/docs/computer-trading/12-1086-future-of-computertrading-in-financial-markets-report.pdf
2. Bloomfield,R., Wetherilt,A.: Computer trading and systemic risk: a nuclear perspective. /
Foresight. The Government Office for Science, London // [Электронный ресурс]. –
Режим доступа http://www.bis.gov.uk/assets/foresight/docs/computer-trading/12-1059dr26-computer-trading-and-systemic-risk-nuclear-perspective.pdf
3. Commission Roundtable on Technology and Trading: Promoting Stability in Today's
Markets. / U.S. Securities and Exchange, October 2, 2012 // [Электронный ресурс]. –
Режим доступа http://www.sec.gov/news/otherwebcasts/2012/ttr100212-transcript.pdf
4. Иткин И.Л.: Высоконагруженные трейдинговые системы и их тестирование. /
Конференция разработчиков высоконагруженных систем HighLoad++ //
[Электронный ресурс]. – Режим доступа http://www.highload.ru/2012/abstracts/388.html
5. Penhaligan,P.: Equity Trading: Performance, Latency Throughput. / ExTENT Conference
// [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3turquoise-equitytrading2012
6. Avellaneda,M.: Algorithmic and High-frequency trading: an overview / New York
University Finance Concepts LLC Quant Congress USA 2011. // [Электронный ресурс].
– Режим доступа
http://www.math.nyu.edu/faculty/avellane/QuantCongressUSA2011AlgoTradingLAST.pdf
7. Millennium Exchange Technical Specifications / Официальный сайт London Stock
Exhcange // [Электронный ресурс]. – Режим доступа
http://www.londonstockexchange.com/products-and-services/technical-library/millenniumexchange-technical-specifications/millennium-exchange-technical-specifications.htm
8. Zverev,A., Bobrov,I, Pryadkina,N..: Testing of HFT GUI. / ExTENT conference //
[Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3exactpro-testingofhftgui-12944204
9. Yu,T.: An observable and controllable testing framework for modern systems. // ICSE '13:
Proceedings of the 2013 International Conference on Software Engineering Publisher: IEEE
Press, May 2013
10. Netzer,R.H.B, Miller,B.P.: What are race conditions?: Some issues and formalizations //
Letters on Programming Languages and Systems (LOPLAS) , Volume 1 Issue 1, March
1992
11. Zverev,A., Bulda,A., Bobrov,I.: Trading Systems: Testing at the Confluence of FTNFT. /
ExTENT conference // [Электронный ресурс]. – Режим доступа
http://www.slideshare.net/extentconf/extent-2013-obninsk-trading-systems-testing-at-theconfluence-of-ft-nft-17082512
12. Heider,W., Rabiser,R., Grünbacher,P., Lettner,D.: Using regression testing to analyze the
impact of changes to variability models on products. // SPLC '12: Proceedings of the 16th
International Software Product Line Conference - Volume 1, September 2012
13. Eurodollars on CME Globex: Implied Price Functionality // [Электронный ресурс]. –
Режим доступа http://www.cmegroup.com/trading/interest-rates/files/Butterflies.pdf
14. Sutton,M., Greene,A., Amini,P.: Fuzzing: Brute Force Vulnerability Discovery. // AddisonWesley Professional, 2007
15. McGee,P., Kaner,C.: Experiments with high volume test automation. // SIGSOFT Software
Engineering Notes, September 2004
16. Kaner,C: An Overview of High Volume Automated Testing. // [Электронный ресурс]. –
Режим доступа http://kaner.com/?p=278
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
201](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-201-320.jpg)
![17. Teaching High Volume Automated Testing (HiVAT). //12th Workshop on Teaching
Software Testing (WTST 2013), January 25-27, 2013, Melbourne, Florida, at the Harris
Institute for Assured Information. // [Электронный ресурс]. – Режим доступа
http://wtst.org/
18. Cavalli,R., Montes de Oca,E., Mallouli,W., Lallali,M.: Two Complementary Tools for the
Formal Testing of Distributed Systems with Time Constraints. //12th 2008 IEEE/ACM
International Symposium on Distributed Simulation and Real-Time Applications.
19. Diaz,D., Zaki,M., Theodoulidis,B., Sampaio,P.: A Systematic Framework for the Analysis
and Development of Financial Market Monitoring Systems. // 2011 Annual SRII Global
Conference
20. Иткин И., Прядкина Н., Крюков А.: Анализ данных в высоконагруженных
трейдинговых системах. / Конференция АИСТ-2013. // [Электронный ресурс]. –
Режим доступа http://clubqa.ru/blogs/?p=436
21. Официальный сайт Fidessa Fragmentation Index // [Электронный ресурс]. – Режим
доступа http://fragmentation.fidessa.com/
22. OATS Reporting Technical Specifications. // [Электронный ресурс]. – Режим доступа
http://www.finra.org/web/groups/industry/@ip/@comp/@regis/documents/appsupportdocs/
p197473.pdf
23. Mateo,P.R., Usaola,M.P., Alema´n,J.L.F.:Validating Second-Order Mutation at System
Level. // IEEE Transactions on softvare engineering, vol. 39, No. 4, April 2013
24. Mateo,P.R., Usaola,M.P., Offutt,J.: Mutation at System and Functional Levels. // Third
International Conference on Software Testing, Verification, and Validation Workshops
25. Wang,T., Wei,T., Gu,G., Zou,W.: Checksum-Aware Fuzzing Combined with Dynamic
Taint Analysis and Symbolic Execution. // ACM Transactions on Information and System
Security, Vol. 14, No. 2, Article 15, Publication date: September 2011
26. Itkin,I., Matveeva,A., Barch,A.: Test Tools evolution. / ExTENT conference //
[Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent2013-obninsk-test-tools-for-trading-systems-evolution-theory-17007184
202
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-202-320.jpg)
![Тестирование совместимости протокольных
подключений клиентов биржевых и брокерских
систем
Андрей Алексеенко1, Анастасия Матвеева1, Даниил Шаров1, Павел
2
Проценко , Иосиф Иткин3
1
ООО «Инновационные Трейдинговые Системы», Россия, 1156088, г. Москва, 2-й
Южнопортовый проезд, 20А/4
Andrey.Alexeenko@exactpro.com, Anastasia.Matveeva@exactpro.com,
Daniel.Sharov@exactpro.com
2
Exactpro Systems UK, 10 Paternoster Square, London, EC4M 7LSl, UK
Pavel.Protsenko@exactpro.com
3
Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA
Iosif.Itkin@exactpro.com
Aннотация. Жизненный цикл разработки биржевого и брокерского
программного обеспечения, помимо проверки функциональных и
технических характеристик системы, включает в себя обязательный этап
интеграционного тестирования, называемый сертификацией клиентов.
Этот этап призван обеспечить совместимость систем автоматизированной
торговли, подключаемых к бирже или брокеру посредством финансовых
протоколов (таких как FIX/FAST, ITCH или специализированные
бинарные интерфейсы доступа). В статье представлен оригинальный
инструмент, разработанный для проверки совместимости торговых
систем. Отличительная особенность разработанного инструмента унифицированный способ поддержки множества протоколов. Приведены
примеры его использования при самостоятельной сертификации
участников торгов, а также при масштабных миграциях трейдинговых
платформ. Ключевые слова: финансовые протоколы, FIX-протокол,
тестирование совместимости, самостоятельная сертификация, торговый
брокер, биржа.
1 Введение
Адаптация новых клиентов к трейдинговой платформе и их поддержка при
обновлениях программного обеспечения - это один из ключевых бизнеспроцессов биржевых и брокерских организаций [1; 2; 3]. Существенной
составляющей этого процесса служит тестирование, проводимое для выявления
проблем с совместимостью трейдинговой платформы с системами,
принадлежащими подключаемым к бирже или брокеру участникам торгов,
называемое сертификацией клиентов [4].
Сертификация клиентов обязательна для любого оператора биржевой или
брокерской платформы, предоставляющей возможность
осуществлять
финансовые транзакции, и в настоящее время широко используется в
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
203](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-203-320.jpg)
![финансовой индустрии [5]. Ссылки на правила сертификации клиентов и
соответствующую документацию можно найти на официальных сайтах
соответствующих организаций [6; 7; 8; 9].
Программное обеспечение, ранее успешно прошедшее внутреннее
интеграционное тестирование, проходит после этого через завершающий тест интеграцию с клиентами (обычно юридическими лицами). Общепринятой
практикой является ситуация, когда клиенты и оператор трейдинговой
платформы задают временной интервал для выполнения активного
тестирования и оценивают его результаты с обеих сторон.
В связи с тем, что в процесс сертификационного тестирования вовлечены люди,
представляющие разные компании, данный процесс требует значительной
степени координации и слаженности работы. Это чрезвычайно важно как с
финансовой, так и с репутационной точек зрения. Любой дефект программного
обеспечения, обнаруженный на этапе сертификационного тестирования,
является достаточно дорогостоящим с точки зрения его устранения, поскольку
все стадии жизненного цикла программного обеспечения уже пройдены [10], а
любая задержка с обнаружением проблем совместимости вносит существенные
дополнительные затраты.
К характерным проблемам, с которыми приходится сталкиваться при
проведении сертификации клиентов, относятся:
наличие часовых поясов и возникающие в связи с этим сложности в
планировании и координации проведения тестирования командами
профессионалов, находящимися физически в разных частях земного
шара;
производительность: сертификация может требоваться несколькими
клиентами одновременно из-за бизнес- или технических событий, таких
как выход новых версий программного обеспечения, изменений
нормативных или технических требований;
компетентность: специалист по обеспечению качества программного
обеспечения, проводящий сертификацию, обязан обладать должным
уровнем технических и бизнес-знаний;
покрытие: сертификационные тесты должны быть основаны на
типичных сценариях и обеспечивать значимые результаты.
В трейдинговой индустрии начинает формироваться понимание того, что одним
из способов преодоления этих проблем может стать создание более
совершенных решений по автоматизации сертификационного тестирования и
анализу его результатов [11]. Несмотря на актуальность автоматизации
процесса сертификации биржевых/брокерских клиентов, данная проблематика
пока практически не освещена в отечественной и зарубежной научной
литературе.
На рынке присутствует несколько коммерческих инструментов тестирования,
созданных для ускорения процесса сертификации клиентов:
FIX Conductor от компании Lasalletech [12];
FACTS от B2BITS, EPAM Systems [13];
CertiFIX от Greenline [14];
Catalys Studio от Cameron [15];
204
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-204-320.jpg)
![ Ignition от FIXFlyer [16];
VegaFABS от Pravega Financial Technologies [17];
Certpoint от Tradepoint Systems [18];
Certification Platform от FixSpec.com [19].
Биржевые платформы используют два основных подхода к сертификации:
Предоставление клиентам специализированного симулятора для
проведения сертификации [20; 21; 22]. Клиенты проводят тестирование,
используя предоставленный инструмент, и предоставляют логи
сертификации;
Предоставление доступа к специализированному тестовому
окружению, которое является уменьшенной копией промышленной
системы; документирование процедуры; совместное проведение
сертификации с клиентом либо использование самостоятельной
сертификации [23]; использование пассивных методов, таких как
перехват трафика сетевых подключений или данные из лог-файлов, для
анализа успешности и полноты проведенной процедуры сертификации.
Оба подхода в той или иной степени реализованы в существующих
коммерческих решениях.
Основное достоинство метода, основанного на использовании симуляторов, это снижение нагрузки на сертифицирующую организацию и клиентов,
обеспечиваемое возможностью проводить сертификацию в любое время суток,
а не только в период открытого торгового дня. Проблема, специфичная для всех
симуляторов, - отсутствие гарантии, что фактическое сообщение, отправленное
с его помощью, идентично сообщениям, отправляемым реальным программным
обеспечением [24].
Пассивное тестирование является, на наш взгляд, наиболее корректным
методом проведения сертификации клиентов. Общая концепция пассивного
тестирования и её преимущества описаны в [25], различные алгоритмы
пассивного тестирования предложены в [26; 27]. Основным преимуществом
пассивного тестирования является то, что инструмент для тестирования не
оказывает влияния на тестируемую систему и не приводит к созданию потоков
дополнительных сообщений. Данное преимущество, однако, одновременно
является и недостатком: для успешного проведения пассивного тестирования
необходимые сообщения должны быть кем-то созданы. В случае сертификации
клиентов требуется привлекать представителей другой компании для создания
входящего потока сообщений.
Данная практика неизбежна при первичной сертификации. Однако с целью
снижения временных затрат сторонних организаций требуется использовать
более эффективные методы: например, предложенный в [28] подход. Используя
данные первичной сертификации для автоматизированного создания новых
сценариев тестирования, при сохранении неизменной спецификации протокола
доступа, оператор трейдинговой платформы получает возможность провести
повторную сертификацию клиента самостоятельно.
Присутствующие на рынке инструменты для сертификации клиентов обладают
следующими ограничениями:
специализация на одном фиксированном протоколе, например FIX [29];
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
205](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-205-320.jpg)
![интерактивные инструменты анализа данных и создания новых
сценариев малопригодны для обработки действительно больших
объемов данных о гетерогенных клиентских подключениях.
Авторы принимают участие в разработке и использовании программного
решения компании Exactpro Systems LLC, направленного на преодоление
указанных ограничений [30; 31]. Созданный инструмент описывается во второй
части данной статьи. Третья часть содержит описание практического
использования созданного инструмента для самостоятельной сертификации
участников биржевых торгов. Четвертая часть описывает использование
разработанного инструмента при масштабных миграциях брокерских систем.
2
Многопротокольное
решение
тестировання трейдинговых систем
для
пассивного
Инструмент для пассивного тестирования сетевых подключений к
трейдинговым системам разработан с использованием языка Java и системы
управления базами данных MySQL. В основе подхода - унифицированное
описание структуры протокольных сообщений - система словарей. Для каждого
протокола создается словарь. Для групп протоколов может потребоваться
написание специальных модулей, приводящих сетевые потоки данных к
унифицированному внутреннему формату на основе словарей. Концепция
близка к логике Complex Events Processing [32]. Для создания шаблона словаря
был взят и доработан для большей общности шаблон словарей, используемый в
системе QuickFIX/J [33].
Разработанный инструмент может получать на входящие данные о
перехваченных сетевых сообщениях, полученных с использованием tcpdump
[34] или различных прокси-серверов [35]. Пользователю также предоставлена
возможность загружать лог-файлы, содержащие массив сообщений, в
настраиваемом формате.
Основная таблица в базе данных содержит информацию о каждом
перехваченном пакете, включая повторную пересылку TCP-данных. Если
трейдинговая система находится под нагрузкой, сетевой пакет может содержать
несколько сообщений или же сообщение может быть разбито между
несколькими TCP-пакетами. Выделив сообщения из сетевых пакетов,
инструмент делает попытку конвертации в унифицированный формат на основе
словарей. Информация о сетевых пакетах и сообщениях, не прошедших
проверку посредством словарей, заносится в отдельную таблицу, по сути
содержащую список проблем сертификации первого уровня.
Детали перехваченных и успешно обработанных сообщений могут быть
сохранены в реляционную базу данных посредством двух основных методов:
использования общей таблицы, содержащей идентификаторы
сообщения, имя параметра и его значение;
использования индивидуальной таблицы для каждого типа сообщения,
размещая параметры сообщения в соответствующих колонках, с
именами, произведенными от имени параметров.
206
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-206-320.jpg)
![Сертификационные тесты и сверки данных могут быть реализованы
посредством обычных SQL-запросов. Инструмент предоставляет возможность
подсветки и анализа сообщений, полученных в результате выполнения того или
иного запроса. На рисунке 2 представлен пример окна графического интерфейса
разработанного инструмента.
Рис.2. Графический пользовательский интерфейс инструмента тестирования и
сертификации.
3 Самостоятельная сертификация участников биржевых
торгов
Регулирующие органы требуют от операторов биржевой системы
предоставления эквивалентного доступа всем участникам торгов [36]. При
внесении изменений в технологическую платформу биржи ее оператор обязан
провести сертификацию всех подключенных торговых систем в короткий
промежуток времени. Данная особенность процесса создает существенную
нагрузку на отделы организации-оператора биржевой площадки, отвечающие за
поддержку клиентов. Для снижения этой нагрузки биржевые площадки
используют метод самостоятельной сертификации.
Клиентам предоставляется доступ к тестовому окружению и сценарий
выполнения
сертификационных
тестов.
После
выполнения
шагов
предоставленного
сценария
клиент
высылает
логи
процесса
в
сертифицирующую организацию, где они проходят дополнительную проверку.
Пассивное тестирование значительно упрощает процесс сертификации для
участников торгов. При данном подходе от них требуется только подключиться
208
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-208-320.jpg)
![к тестовому окружению и отправить заявки, обозначенные в тестовом сценарии.
Таким образом, участники торгов избавлены от выполнения любых шагов
(таких как установка дополнительного программного обеспечения, сбор логов и
т.д.), кроме тех, которые непосредственно необходимы для подключения к
технологической платформе биржи.
Разработанный инструмент перехватывает все сообщения, переданные от
клиента к бирже или в обратную сторону, разбирает структуру и содержимое
каждого сообщения и сохраняет всё в реляционную базу данных. Используя
SQL-запросы, аналитик сертифицирующей организации может получить
статистику по попыткам выполнения шагов тестового сценария и их
успешности для каждого из участников торгов. Данные о сетевых пакетах
позволяют также обнаружить дополнительные проблемы, такие как разрывы
соединений или проблемы с буферизацией сообщений.
Приведем пример сертификационного SQL-сценария, проверяющего
успешность размещения клиентом агрессивной рыночной заявки, в результате
появления которой по исполнении её против заявок, размещенных на
противоположной стороне стакана заявок, образовались две и более сделки:
insert into t_native_testcases
(user,sourceip,sourceport,testcase,timestamp,clordid,orderid,
otherid)
select distinct n.user, n.sourceip, n.sourceport, 'MEx-012.2
Agg. MO' as testcase, n.timestamp, n.clordid, e.orderid, ''
from t_lsenative_neworder n
, t_lsenative_executionreport e
, t_lsenative_executionreport e2
where n.user=e.user
and n.sourceip=e.destinationip and
n.sourceport=e.destinationport
and n.clordid=e.clordid and n.user=e2.user and
n.sourceip=e2.destinationip
and n.sourceport=e2.destinationport and n.clordid=e2.clordid
and n.ordertype=1 and e.ordstatus=1 and
e.tradeliquidityindicator='R'
and e2.typeoftrade='2' and e2.ordstatus in (1,2)
and e2.tradeliquidityindicator='R' and e2.typeoftrade='2'
and e.execid e2.execid
order by user, clordid, orderid;
Для нескольких биржевых платформ были разработаны совокупности SQLсценариев, покрывающие все требования по сертификации клиентских
соединений, опубликованные организатором торгов [9].
4 Миграция брокерской платформы с большим
количеством гетерогенных клиентских подключений
В сравнении с биржевыми платформами брокерские системы обычно
предоставляют существенно более широкие возможности по настройке
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
209](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-209-320.jpg)
![протокола взаимодействия с системами клиентов: например, используя
возможности таких систем, как UL Bridge [37]. Один и тот же клиент может
использовать одновременно несколько брокеров для получения доступа на
биржу. Часто брокеры стараются снизить количество изменений в протоколах
коммуникации, которые конкретный клиент вынужден имплементировать со
своей стороны. Облегчая взаимодействие с клиентом, этот подход
одновременно приводит к появлению большого количесва гетерогенных
конфигураций со стороны брокерской трейдинговой платформы. При
внутренних изменениях брокерской платформы возникает необходимость в
регрессионном тесте на совместимость с клиентскими системами.
Разработанный инструмент позволяет обработать имеющиеся данные из
тестовых и промышленных окружений и создать необходимый набор активных
тестовых сценариев. Выполнив эти сценарии против тестового окружения без
привлечения конечных клиентов тестовый инструмент запускает SQL-сценарии,
выполняющие сверку ответов брокерской платформы до и после изменений.
Особенность созданного авторами инструмента состоит в том, что он позволяет
проводить этот процесс одновременно для большого количества клиентов,
подключений, рынков и типов сообщений. Гибкость при создании сверяющих
SQL-запросов позволяет не только исключить из сравнения поля, про которые
заранее известно, что их значения должны различаться (например, sequence
numbers, timestamps и другие), но и задать требования по обработке более
сложных расхождений.
Подход доказал свою жизнеспособность и эффективность при миграции
трейдинговой платформы одного из крупнейших международных брокеров,
предоставляющего доступ к торговле производными финансовыми
инструментами. Последовательность шагов отображена на схеме на рисунке 3.
210
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-210-320.jpg)
![крупномасштабных трейдинговых систем для торговли финансовыми
инструментами разных классов.
В статье описаны используемые в индустрии методы сертификации клиентских
подключений и сделаны выводы о преимуществах подхода, основанного на
использовании многопротокольного пассивного инструмента, сохраняющего
данные в реляционную СУБД. Рассмотрен также вариант использования
данного инструмента с целью создания активных тестов и сокращения затрат
при масштабных миграциях систем с множеством гетерогенных клиентских
подключений.
Дальнейшие исследования будут направлены на оптимизацию структуры базы
данных: в частности, в вопросе распространения разработанных методов на
трейдинговые протоколы, основанные не на сетевых взаимодействиях, а на
программных интерфейсах доступа (API).
Источники
1. Markit Magazine Issue 10 - Focus: Client Onboarding – Markit.com // [Электронный
ресурс]. – Режим доступа http://www.markit.com/assets/en/docs/markit-magazine/issue10/mm10_focus5-onboardingroundtable.pdf
2. Fenergo 2013, Client Onboarding: Solving the Challenges, Maximizing the Opportunities.
// [Электронный ресурс]. – Режим доступа http://www.fenergo.com/industryknowledge/whitepapers/client-onboarding-solving-challenges-maximizingopportunities.html
3. Axel Pierron, Anshuman Jaswal: Institutional Client On-Boarding in the Financial Industry
Time to Move to the Industrialization Phase. // Celent Report, October 2012 //
[Электронный ресурс]. – Режим доступа http://www.celent.com/reports/institutionalclient-boarding-financial-industry
4. Challenges and Solutions to Onboarding Trading Clients. // [Электронный ресурс]. –
Режим доступа http://www.trdpnt.com/blog/bid/294222/Challenges-and-Solutions-toOnboarding-Trading-Clients
5. FIA Market Access Risk Management Recommendations April 2010. // [Электронный
ресурс]. – Режим доступа http://www.futuresindustry.org/downloads/Market_Access6.pdf
6. Moscow Exchange. // [Электронный ресурс]. – Режим доступа
http://fs.moex.com/files/4531
7. BOX Options Exchange. // [Электронный ресурс]. – Режим доступа
http://boxexchange.com/what-you-need-to-know/software-certification/
8. Eris Exchange. // [Электронный ресурс]. – Режим доступа
http://www.erisfutures.com/sites/default/files/Electronic_Trading_Certification_Process.pd
f
9. TQ 601 - Technical Specification Turquoise Equities Guide to Certification. //
[Электронный ресурс]. – Режим доступа
http://www.lseg.com/sites/default/files/content/documents/TQ601%20%20Guide%20To%20Application%20Certifcation.pdf
10. Forrest Shull, Vic Basili, Barry Boehm, A. Winsor Brown, Patricia Costa, Mikael
Lindvall,Dan Port, Ioana Rus, Roseanne Tesoriero, Marvin Zelkowitz: What We Have
Learned About Fighting Defects // METRICS '02 Proceedings of the 8th International
Symposium on Software Metrics, IEEE Computer Society Washington, DC, USA 2002
212
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-212-320.jpg)
![11. Candyce Edelen: Making the Case for Automated FIX Certification. // [Электронный
ресурс]. – Режим доступа http://www.advancedtrading.com/high-frequency/making-thecase-for-automated-fix-certif/240155554
12. FIX Conductor™ от компании Lasalletech. // [Электронный ресурс]. – Режим доступа
http://www.lasalletech.com/products/fix-automated-onboarding
13. FACTS от B2BITS, EPAM Systems. // [Электронный ресурс]. – Режим доступа
http://www.b2bits.com/trading_solutions/fix_testing_facts.html
14. CertiFIX® от Greenline. // [Электронный ресурс]. – Режим доступа
http://www.greenlinetech.com/products/certifix.php
15. Catalys Studio от Cameron. // [Электронный ресурс]. – Режим доступа
http://www.camerontec.com/products/catalys/catalys-studio/
16. Ignition от FIXFlyer. // [Электронный ресурс]. – Режим доступа
http://fixflyer.com/materials/software/Ki/FlyerIgnition.pdf
17. VegaFABS от Pravega® Financial Technologies. // [Электронный ресурс]. – Режим
доступа
http://www.pravegatech.com/index.php?option=com_contentview=articleid=64Itemi
d=65
18. Certpoint от Tradepoint Systems. // [Электронный ресурс]. – Режим доступа
http://www.trdpnt.com/certpoint/
19. Certification Platform от FixSpec.com // [Электронный ресурс]. – Режим доступа
http://forexmagnates.com/fixspec-launches-innovative-multi-venue-certification-utility-tostreamline-connectivity/
20. The Stock Exchange of Hong Kong Limited. // [Электронный ресурс]. – Режим
доступаhttp://www.hkex.com.hk/eng/market/partcir/sehk/2012/Documents/CTMO06612E.
pdf
21. MyCTC (Certification and Testing Center) от BMFBOVESPA. // [Электронный
ресурс]. – Режим доступа http://www.bmfbovespa.com.br/enus/services/download/MyCTC-User-Guide.pdf
22. CME Group. // [Электронный ресурс]. – Режим доступа http://www.cmegroup.com/confluence/display/EPICSANDBOX/Client+System+Certificati
on
23. The London Stock Exchange. // [Электронный ресурс]. – Режим доступа
http://www.lseg.com/areas-expertise/technology/market-connectivity/customercertification-and-testing-services
24. Zverev A., Bulda A.: Exchange Simulators for SOR/Algo Testing: Advantages vs.
Shortcomings. / ExTENT conference. // [Электронный ресурс]. – Режим доступа
http://www.slideshare.net/IosifItkin/exchange-simulators-for-sor-algo-testing-advantages-vsshortcomings
25. K. M. Brzezinski: Towards the Methodological Harmonisation of Passive Testing Across
ICT Communities // Engineering the Computer Science and IT, October 2009
26. David Lee, Dongluo Chen, Ruibing Hao, Raymond E. Miller, Jianping Wu and Xia Yin:
Network Protocol System Monitoring – A Formal Approach With Passive Testing //
IEEE/ACM Transactions on Networking, Vol. 14, No. 2, April 2006
27. Ana Cavalli, Stephane Maag, Edgardo Montes de Oca: A passive conformance testing
approach for a MANET routing protocol // Proceedings of the 2009 ACM symposium on
Applied Computing March 2009, SAC '09
28. James Newsome, David Brumley, Jason Franklin, Dawn Song: Replayer: Automatic
Protocol Replay by Binary Analysis // CCS '06: Proceedings of the 13th ACM conference
on Computer and communications security, October 2006
29. FIX Protocol. // [Электронный ресурс]. – Режим доступа http://fixprotocol.org
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
213](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-213-320.jpg)
![30. Zverev A., Moskaleva O., Kudryavtseva M., Doronichev D., Bulda A.: Four Houses – Test
Tools presentation. / ExTENT conference // [Электронный ресурс]. – Режим доступа
http://www.slideshare.net/extentconf/extent3-exactpro-fourhousestesttools2012-1
31. Zaitseva N., Popovchuk N.: Next Step in Reconciliation Testing. / ExTENT conference //
[Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3exactpro-thenextstepinreconciliationtesting
32. G. Cugola and A. Margara: Processing flows of information: From data stream to complex
event processing // ACM Computing Surveys, 2011.
33. QuickFIX/J . // [Электронный ресурс]. – Режим доступа http://quickfixj.org
34. Felix Fuentes, Dulal C. Kar: Ethereal vs. Tcpdump: a comparative study on packet sniffing
tools for educational purpose // Journal of Computing Sciences in Colleges , Volume 20
Issue 4, April 2005
35. The Grinder TCP Proxy. // [Электронный ресурс]. – Режим доступа
http://grinder.sourceforge.net/g3/tcpproxy.html
36. Investment Services Directive – Markets in Financial Instruments Directive (MiFID)
37. UL Bridge. // [Электронный ресурс]. – Режим доступа http://www.ullink.com/fixsolutions.php
214
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-214-320.jpg)
![финансового инструмента являются основными характеристиками для такого
рода компонентов высоконагруженных систем.
1.1 Рыночная информация (Market Data) и ее основные представления
Обычно рыночная информация включает в себя следующий набор параметров,
специфичных для определённого финансового инструмента: краткое название
инструмента (ticker symbol), цена последней сделки (last trade price), текущие
лучшие цены спроса и предложения (Best Bid Offer), идентификационный
номер инструмента (ISIN), биржа, на которой произошла сделка (exсhange
code), время последней сделки (Trade Time), цена сделки при закрытии торговой
сессии на инструменте (Close Price). В зависимости от сложности
высоконагруженных биржевых систем, рыночная информация о котировках
может обрабатываться внутренними компонентами электронных бирж и
обогащаться дополнительной информацией: например, об общем объёме
сделок в течение биржевого дня (Turnover), о средневзвешенной цене по
общему объему и количеству сделок (VWAP), а так же более детальной
информацией об акции или деривативе – справочные данные, такие как
параметры трейдеров, рынка, торговых сессий, инструментов (или Reference
Data). Справочные данные (Reference Data или Static Data) представляют собой
информацию об инструменте, которая не меняется в режиме реального времени:
например, международный идентификационный код ценной бумаги (ISIN), цена
сделки при закрытии трейдинговой сессии за предыдущий день (Close Price),
валюта, в которой данный финансовый инструмент торгуется на бирже
(Currency), параметры так называемых «прерывателей торгов», которые чаще
указываются в процентных соотношениях к цене последней сделки (Dynamic or
Static Circuit Breaker Tolerances (%)), и так далее[1].
Для предоставления перечисленной выше информации существует ряд
стандартных протоколов распространения котировок (например, FIX/FAST [2]),
так называемых протоколов распространенния котировок с фиксированной
длинной сообщений (например, ITCH [3]), или кодированные протоколы
передачи данных (например, HTTPS (HyperText Transfer Protocol Secure) [4] [5]).
Многие электронные биржи распространяют информацию о котировках как
через стандартные протоколы, так и через специальные. Трейдеры часто не
могут позволить себе дорогостоящую разработку программ, которые бы
собирали необходимую им для работы информацию о котировках. Таким
образом, возникает необходимость создания систем сбора и агрегации
рыночных данных с различных бирж и по различным финансовым протоколам
передачи данных.
216
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-216-320.jpg)
![1.2 Cистема агрегации информации (Ticker Plant) и ее основные функции
Ticker Plant - это система агрегации информации о котировках с различных
электронных торговых площадок (или бирж) и её распределения. Данная
система предоставляет рыночные данные трейдерам в нормализованном или
унифицированном виде [6]. Зачастую Ticker Plant рассчитывает
дополнительные параметры на основе предоставленных рыночных данных, то
есть обогащает статистическую информацию об акциях и деривативах. Кроме
того, для таких систем характерна способность объединять однородные
величины распространяемых котировок: ценовые уровни (Price Levels),
предоставление котировок согласно запросам клиентов (например, широко
распространены такие сервисы, как Level 1, Level 2, Index, TS, News) в режиме
реального времени, а так же хранение переданной рыночной информации.
Указанные выше типы сервисов по предоставлению рыночной информации
достаточно распространены в электронной торговле финансовыми
инструментами. Рассмотрим каждый из них подробнее:
• Level1 - информация о последних Bid/Ask, OHLC (Open, High, Low, Close),
Volume;
• Level2 - информация о Level1 + Order Book (5-10 уровней глубины торговой
книжки, Bid/Ask PxQty). Level2 может содержать атрибутированные или
анонимные заявки), и использовать модели MBO (Market by Order, т.е.
индивидуальное отображение всех заявок в пределах отдельно взятого ценового
уровня) и MBP (Market by Price, т.е. агрегированное отображение заявок в
пределах отдельно взятого ценового уровня). [7];
• Level2 - Total View - более полная информация по сравнению с Level2;
• News - последние новости о компании [8];
• Index - данные об индексах [9].
Схематичное представление системы агрегации и распределения
информации о котировках (Ticker Plant) показано на рисунке 1.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
217](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-217-320.jpg)
![6. обрабатывать эти данные с целью расширить функциональность системы:
например, предоставлять статистику (VWAP, Turnover, Trade High/Low, 52 week
Trade High/Low);
7. предоставлять данные согласно запросам клиентов: Level1, Level2, TS,
News, Index, Option chains и другое;
8. предоставлять записанную историческую информацию о котировках.
• с нефункциональной точки зрения:
1. быструю обработку потоков информации о котировках, поступающей в
режиме реального времени от электронных бирж;
2. быструю обработку запросов, поступающих от клиентов и предоставление
данных о котировках в зависимости от вида запроса клиента (например,
отдельно на торгуемый инструмент, или на группу инструментов, или на весь
рынок);
3. бесперебойную работоспособность системы;
4. управляемость системой (operability);
5. возможность мониторинга систем (наличие приложений, с помощью
которых можно наблюдать за системой или упралять её компонентами);
6. пропускную способность (throughput);
7. временную задержку (latency);
8. отказоустойчивость (fault tolerance).
Определив набор функциональных и нефункциональных характеристик
системы агрегации и распределения информации о котировках (Ticker Plant),
нам необходимо понять, как будет проходить процесс тестирования отдельно
взятой характеристики. Очевидными становятся два пути тестирования такого
рода систем.
Первый - это тестирование с реальными тестовыми площадками (CDS customer development service [10]). Обычно биржи предоставляют своим
клиентам тестовые окружения (test environments), аналогичные реальной
электронной трейдинговой платформе. Чаще всего это делается с целью пройти
сертификационный процесс или предоставить клиентам возможность для
отладки своего клиентского программного обеспечения.
И второй - это тестирование с помощью симуляторов трейдинговых
платформ, разработанных на основе данных о бирже, находящихся в публичном
доступе.
3 «Тестовая» биржа: описание и основные возможности
“Тестовая” биржа - это своего рода полная копия реальной трейдинговой
биржи [11]. Такой аналог трейдинговой биржи должен наиболее полно
представлять реальную электронную платформу. Тестовые биржи
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
219](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-219-320.jpg)
![предоставляются клиентам, которым необходимо отладить разработанное ими
трейдинговое и информационное программное обеспечение [12]. Заявки и
сделки в таких тестовых биржах генерируются как следствие взаимодействия
самих клиентов, тестирующих собственное программное обеспечение, друг с
другом.
В идеале тестовая биржа состоит из тех же компонентов и частей, что и
реальная биржевая система[13]. Торговые сессии, основные параметры
торгуемых инструментов, правила трейдинга, графические приложения для
управления настройками справочных данных (reference data) и т.д - все эти
характеристики полностью аналогичны компонентам реальной системы.
Поэтому такое тестовое окружение (test environment) позволяет проверять
программное обеспечение, заведомо ориентируясь на аналогичные настройки в
реальной системе.
Ниже приведена схема тестирования Ticker Plant с применением тестовой
биржи.
Рис.2 Тестирование Ticker Plant с помощью тестовой биржи
220
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-220-320.jpg)
![4 Симулятор рынка ценных бумаг: описание и основные
возможности
Симулятор рынка ценных бумаг (или биржевой симулятор) - это интерактивная
программа, разработанная для имитации возможностей и свойств реальных
моделей рынка[14]. Симулятор рынка должен уметь эмулировать реальные
действия, происходящие на
бирже: сам трейдинг (размещение заявок,
генерацию сделок, изменения статусов инструментов и т.д), симуляцию
мониторинга за ходом торгов на рынке и внесение изменений (market operations:
отмена/изменение заявок и сделок, остановка торгов, и т.д.), режим работы
рынка (переход рынка из одного статуса в другой - открытие рынка (Market
Open), аукционы (Opening/Closing/ Periodic Auction Calls), вычисления цен
аукционов и публикация цены закрытия, закрытие рынка и т.д. Биржевой
симулятор рынка содержит API, аналогичный реальной бирже, с элементами
контроля отсылаемых ответов клиенту[15]. Такие симуляторы рынков
позволяют иметь более полный контроль над генерируемыми событиями для
системы агрегации и распределения информации о котировках (Ticker
Plant)[16], таким образом увеличивая покрытие тестирования системы. С
помощью симуляторов можно создать необходимую нагрузку, сравнимую с
потоками данных, свойственным реальным высоконагруженным биржевым и
брокерским системам.
Далее представлена схема верификации системы Ticker Plant при помощи
симулятора.
Рис.3 Схема тестирования Ticker Plant с применением симулятора
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
221](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-221-320.jpg)
![6 Методика анализа покрытия тестирования системы
агрегации и распределения информации о котировках (Ticker
Plant) при помощи инструментов для тестирования
Для того, чтобы оценить и проанализировать, насколько полно инструметы
тестирования покрывают области функциональности системы Ticker Plant,
которую необходимо протестировать, нами была разработана специальная
методика. Она основывается на переборе сценариев в процентном отношении к
всевозможным сценариям, относящимся к той или иной области. Основываясь
на опыте тестирования, полученном в компании Exactpro Systems [17], была
определена приоритетность областей системы Ticker Plant, обозначенной в
правой колонке таблицы 1.
Следующий раздел рассказывает об опыте применения данной методики
покрытия тестами для оценки полноты тестирования системы Ticker Plant, как с
помощью реальных тестовых площадок, так и с
помощью биржевых
симуляторов.
6.1 Сравнительная характеристика оценочных данных при тестировании
системы агрегации и распределения информации о котировках Ticker Plant
с помощью реальной тестовой биржи и симулятора
В таблице 2 приведены сравнительные характеристики, включающие в себя
оценочные данные, полученные в ходе тестирования системы Ticker Plant с
помощью реальной тестовой биржи и симулятора, а так же детальное
объяснение полученных данных.
Табл. 2. Сравнительные характеристики данных для тестовой биржи и симулятора.
№
1
228
Область
тестирования
Техническое
подключение к
биржам - поток
данных о
котировках и
торгах в режиме
реального
времени
Покрытие
функциональности
при тестировании
с помощью
реальной тестовой
биржей (%)
Покрытие
функциональности
при тестировании
с помощью
симулятора (%)
100
40
Детализация
оценочных данных
При данной оценке
мы исходим из того
что симулятор
биржи, по своему
определению, не
способен
полноценно
воспроизвести все
технические детали
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-228-320.jpg)
![Анализ данных, приведенных в таблице 2 и на рисунке 4, показывает, что
тестирование с помощью симуляторов и реальных тестовых бирж (в разумный
временной период) имеет свои плюсы и минусы. В целом, мы имеем
приблизительно одинаковые показатели по оценочной методике.
Общая формула покрытия всех функциональностей соответствующим
инструментом тестирования:
Summ(CovN*(1/PriorN))/Summ(1/PriorN) .
(1)
где Summ - сумма (Табл. 2), CovN* - относительное покрытие данной
функциональности соответствующим инструментом тестирования (Табл. 2),
PriorN - приоритет данной функциональности (Табл. 1).
Итоговый результат: тестирование при помощи симуляторов обеспечивает
76% покрытия; тестирование при помощи тестовой площадки - 83%.
7 Заключение
В данной статье приводится описание системы агрегации и распределения
информации о котировках (Ticker Plant), перечислены его основные
характеристики, составлена справочная библиотека скриптов для тестирования,
максимально покрывающих функциональность обобщенной системы Ticker
Plant. Также в статье даны определения биржевого симулятора и реальной
тестовой биржи. При помощи разработанной методики оценки покрытия
сценариями для тестирования системы агрегации и распределения информации
о котировках (Ticker Plant) были проанализированы и обработаны два
возможных пути тестирования: при помощи реальной тестовой биржи и
симуляторов бирж. На основе двух сводных таблиц было выведено заключение
о преимуществах тестирования как с реальной тестовой биржей, так и с
биржевым симулятором.
Литература
1.
2.
3.
240
Официальный сайт B2Bits epam. // [Электронный ресурс]. – Режим доступа
http://www.b2bits.com/trading_solutions/market-data-solutions.html
Официальный сайт FIXprotocol. // [Электронный ресурс]. – Режим доступа
http://www.fixprotocol.org/
Документация о Level1 Market Data / Официальный сайт Лондонской Фондовой
Биржи – London Stock Exchange // [Электронный ресурс]. – Режим доступа
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-240-320.jpg)
![4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
http://www.londonstockexchange.com/products-and-services/millenniumexchange/millennium-exchange-migration/mit303.pdf
P. Karlton, P. Kocher.: The Secure Sockets Layer (SSL) Protocol Version 3.0 //
[Электронный ресурс]. – Режим доступа http://tools.ietf.org/html/rfc6101
Официальный сайт FTSE. // [Электронный ресурс]. – Режим доступа
http://www.ftse.com/Indices/Data_Licenses/Real-time_Constituent_Data.jsp
Официальный сайт B2Bits epam. // [Электронный ресурс]. – Режим доступа
http://www.b2bits.com/trading_solutions/market-data-solutions.html
Building the Book: A Full-Hardware Nasdaq Itch Ticker Plant on Solarflare’s AoE
FPGA Board / Sherman,M., Sood,P., Wong,K., Iakovlev,A., Parashar,N. //
[Электронный
ресурс].
–
Режим
доступа
http://www.cs.columbia.edu/~sedwards/classes/2013/4840/reports/Itch.pdf
Официальный сайт Tokyo Stock Exchange // [Электронный ресурс]. – Режим
доступа http://www.tse.or.jp/english/market/mkinfo/mains.html
Day Trading. / Официальный сайт About.com // [Электронный ресурс]. – Режим
доступа
http://daytrading.about.com/od/daytradingmarketdata/a/MarketDataDefin.htm
Customer Development Service (CDS). / Официальный сайт Лондонской
Фондовой Биржи – London Stock Exchange // [Электронный ресурс]. – Режим
доступа
http://www.londonstockexchange.com/products-and-services/technicallibrary/customer/customerdevelopmentservice/customerdevelopmentservice.htm
Trading Floor Architecture / Официальный сайт Cisco // [Электронный ресурс]. –
Режим
доступа
http://www.cisco.com/en/US/docs/solutions/Verticals/Trading_Floor_ArchitectureE.html
Официальный сайт BSE India // [Электронный ресурс]. – Режим доступа
http://www.bseindia.com/markets/MarketInfo/DispNoticesNCirculars.aspx?page=20
12053122pagecont=0,31/05/2012,31/05/2012,,All,All,All,Scrip%20Name%20/%20Code
Официальный сайт ММВБ // [Электронный ресурс]. – Режим доступа
http://rts.micex.ru/s437
Статья К.В.Воронцов (ВЦ РАН), С.Б. Пшеничников (ММВБ): Имитационное
моделирование торгов: новая технология биржевых тренажеров. / Журнал
«Индикатор», №2 (42). М. 2002 год // [Электронный ресурс]. – Режим доступа
http://www.forecsys.com/site/about/press/exchange_simulator/
Официальный сайт Oslo Bors Stock Exchange. // [Электронный ресурс]. – Режим
доступа
http://www.oslobors.no/ob_eng/Oslo-Boers/Trading/Delta/MillenniumExchange/Guide-to-Testing-Services-updated-issue
Zverev,A., Bulda,A.: Exchange Simulators for SOR. Algo Testing: Advantages vs.
Shortcomings. / Конференция ExTENT // [Электронный ресурс]. – Режим
доступа
http://www.slideshare.net/extentconf/exchsimsforsoralgotestingadvantagesvsshortcomings29102011111113011104phpapp02
Официальный сайт Exactpro Systems. // [Электронный ресурс]. – Режим доступа
http://www.exactprosystems.com/
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
241](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-241-320.jpg)
![Высокопроизводительный генератор нагрузки для
тестирования систем автоматизированной торговли
Дмитрий Гурьев1, Мария Гай1, Иосиф Иткин2, Александр Терентьев3
1
ООО «Инновационные Трейдинговые Системы», Россия, 115088, г. Москва, 2-й
Южнопортовый проезд, 20А/4
Dmitry.Guriev@exactpro.com, Maria.Gai@exactpro.com
2
Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA
Iosif.Itkin@exactpro.com
3
Саратовский государственный технический университет имени Гагарина Ю.А.,
Россия, 410054, Саратов, ул. Политехническая, 77
a_a_terentyev@mail.ru
Aннотация. В связи с существенным ростом числа торговых заявок,
вызванным развитием высокочастотной торговли, ставится задача
тестирования биржевых и брокерских систем в режимах, приближенных к
реальным. Для обеспечения качества высоконагруженных трейдинговых
систем высокой доступности применяются специализированные
инструменты тестирования. Основные требования к таким инструментам это способность создавать высокие реалистичные нагрузки, используя
ограниченную аппаратную базу. В данной статье описывается
разработанный генератор нагрузки для тестирования систем
автоматизированной торговли. Представлен подход, обеспечивающий
высокую производительность.
Ключевые слова: нагрузочное тестирование, высокочастотная торговля
(HFT), инструменты для тестирования.
1 Введение
Высокочастотная электронная торговля финансовыми инструментами (HFT),
позволяющая минимизировать временные задержки при совершении сделок,
выросла в последние годы и составляет в настоящее время около 30% от всего
объёма торговли акциями в Великобритании и, возможно, более 60% от всего
объёма торговли акциями в США [1]. В результате этого брокерские и
биржевые системы испытывают всё большую нагрузку от потока транзакций,
генерируемого системами автоматизированной торговли. Операторы
трейдинговых платформ, регулирующие органы и участники торгов должны
быть уверены в надёжности программного обеспечения и инфраструктуры
торговых площадок [2] в условиях постоянно растущих нагрузок.
В ходе разработки программного обеспечения для выявления максимальной
пропускной способности, возможных узких мест и определения проблемных
242
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-242-320.jpg)
![элементов системы применяют методы нагрузочного тестирования. Под
нагрузочным тестированием понимается процесс отправки системе большого
количества запросов, проверка своевременности и корректности полученных от
неё откликов, а также проверка внутреннего состояния системы.
В настоящее время для нагрузочного тестирования программного
обеспечения широко используются различные коммерческие и свободно
распространяемые генераторы нагрузки. В качестве примера можно привести
следующие продукты: Apache JMeter, HP Load Runner, IBM Rational Performance
Tester, Borland Silk Performer и другие [3-6]. Основной концепцией,
используемой в этих продуктах, является создание множества виртуальных
пользователей, эмулирующих поведение реальных пользователей для
моделирования
условий,
при
которых
программа/система
будет
функционировать в реальности. При имитации и поддержке соединения с
большим количеством пользователей и высокой нагрузке у инструментов
тестирования могут возникать ограничения производительности, разобранные
во второй части данной статьи.
В компании Exactpro Systems LLC разработан инструмент для тестирования
высоконагруженных трейдинговых систем, обладающий необходимой
производительностью и использованный на практике при проверке некоторых
из крупнейших биржевых технологических инфраструктур в Западной Европе
[7; 8]. Разработанный инструмент поддерживает протоколы: FIX (все версии),
ITCH, LSE Native, SOLA SAIL HSVF, HTTP, SOAP, а также различные
бинарные протоколы трейдинговых систем. Многопротокольность является
одной из архитектурных особенностей разработанного инструмента для
тестирования, вследствие чего добавление новых протоколов и новых версий
уже поддерживаемых протоколов представляет собой относительно
малозатратную задачу. В третьей части статьи рассмотрены особенности
подготовки данных для нагрузочного тестирования. В четвёртой части
представлены возможности по настройке инструмента, включая задание
профиля нагрузки.
2 Оптимизация процесса создания нагрузки
Общее представление о процессе создания нагрузки даётся в ряде работ, в
частности в [9]. Генераторы нагрузки делят на основанные на измерениях
(measurement-based) и основанные на моделях (model-based) [10]. Основанные
на измерениях генераторы удобны для нахождения пропускной способности
тестируемой системы и построения зависимостей времён отклика от нагрузки.
Генераторы нагрузки, основанные на моделях, направлены на симуляцию
распределения входных данных, максимально приближенную к реальному
промышленному использованию системы. В разработанном авторами
высокопроизводительном генераторе нагрузки поддерживаются оба описанных
варианта. Данные модели используются при создании конфигурационных
файлов перед запуском генератора. Таким образом, инструмент может не
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
243](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-243-320.jpg)
![тратить ресурсы на обработку информации, относящейся к модели
непосредственно во время выполнения тестов.
Генераторы нагрузки подразделяются на работающие по принципам
закрытого цикла (closed-cycle) и открытого цикла (open-cycle) [11]. После
посылки сообщения исполняемый поток в генераторе закрытого типа
дожидается ответа от системы, прежде чем приступить к посылке следующих
запросов. Генератор открытого цикла продолжает посылку сообщений не
дожидаясь ответа от тестируемой системы. Большинство инструментов для
тестирования веб-приложений являются генераторами закрытого цикла. Это
связано с использованием концепции виртуальных пользователей, каждый из
которых последовательно выполняет шаги определённого сценария. Генератор
закрытого цикла требует существенно большего количества потоков
исполнения и переключений между ними в сравнении с генератором открытого
цикла. В генераторах закрытого цикла часто обработка исходящих из системы
ответов происходит в том же потоке, что и посылка входящих сообщений,
дополнительно снижая производительность инструмента и иногда даже влияя
на его аккуратность. Таким образом, генераторы открытого цикла требуют
меньшей аппаратной базы для создания требуемого уровня нагрузки. Они также
не требуют порождения лишних потоков и их синронизации для производства
фиксированного уровня нагрузки. Представленный в статье инструмент
работает как генератор открытого цикла.
При разработке инструмента для нагрузочного тестирования рассматривался
вопрос о необходимости привязки исполняемых потоков к ядрам процессора
для сглаживания распределения входящих в систему сообщений по времени
[12]. Авторы пришли к выводу, что миллисекундное разрешение системных
таймеров, присутствующее в большинстве современных Linux-системах,
достаточно для создания реалистичной трейдинговой нагрузки, а отсутствие
привязки к ядрам процессора освобождает некоторое дополнительное
количество аппаратных ресурсов на генераторе нагрузки, позволяя
централизованно запускать оптимальное количество потоков. Разработанный
инструмент использует центральный контроллер, позволяя заранее задать в
конфигурации количество и состав протокольных соединений, которые будут
работать в каждом потоке. Наличие центрального контроллера также позволяет
выдавать команду на выполнение скоординированных действий всеми
потоками. Например, одновременный старт потока сообщений или
одновременное отключение установленных соединений.
При тестировании трейдинговой системы генератор нагрузки заменяет
большое количество систем автоматизированной торговли, использующих
множество серверов. Однако аппаратная база, доступная для размещения
инструментов тестирования, всегда ограничена соображениями экономии [13].
В условиях продолжающейся финансовой нестабильности даже крупнейшие
финансовые институты работают в режиме максимально возможной
оптимизации затрат. Требуется существенно облегчить процесс создания
исходящих сообщений. Для оптимизации процесса создания нагрузки
необходимо до выполнения теста заготовить шаблоны сообщений, сократив
процессорное время на серверах, содержащих инструменты для тестирования.
Сходные соображения заложены в генератор нагрузки, созданный
244
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-244-320.jpg)
![разработчиками крупнейшего российского поисковика «Яндекс». Инструмент
для тестирования с открытым кодом «Яндекс.Танк» предназначен для
генерации огромных объёмов сообщений по протоколу HTTP [14]. Высокая
производительность «Яндекс.Танк» достигается концентрацией нагрузки в
одной сессии и одном потоке, а также использованием заготовленного файла со
статическими запросами. Генераторы нагрузки для трейдинговых систем не
могут использовать статические данные и обладают рядом других ограничений,
рассматриваемых в следующей части.
3 Особенности нагрузочного тестирования торговых систем
В [15] разобраны основные требования к моделированию нагрузки для систем
высокочастотной торговли. Логика работы таких систем существенно
затрудняет использование статичных, ранее записанных или предопределенных
данных. В этой секции рассматриваются некоторые из особенностей создания
нагрузки и подготовки входных данных для тестирования трейдинговых систем.
3.1. Создание сообщений из шаблонов
Вследствие того, что торговля не анонимна, для поддержания сессии сервер
должен получать имена существующих пользователей, корректные порядковые
номера сообщений, а также время отправки каждого сообщения. Наш анализ
показал, что построение сообщений непосредственно перед отправкой с
использованием словарей обходится очень дорого с точки зрения используемых
системных ресурсов. Поэтому было решено использовать заготовки, в которых
порядок полей и набор ключевых значений заданы до начала теста. Например, в
FIX-сообщении NewOrderSingle перед моментом отправки будут изменяться
всего несколько параметров, которые должны быть уникальны (например,
ClOrdID(11) – номер клиентской заявки) и зависеть от текущего времени
(ExpireTime(126) – время истечения срока заявки, ExpireDate(432) – день
истечения срока заявки). Остальные параметры новой заявки не изменяются.
Для поддержания сессии изменяются служебные параметры:
BodyLength(9) – длина сообщения;
SenderCompID(49) – название компании, которая отправила заявку;
TargetCompID(56) – название компании, которой была отправлена заявка;
MsgSeqNum(34) – уникальный номер сообщения;
SendingTime(52) – текущее время;
CheckSum(10) – проверочное число.
В сообщения OrderCancelReplaceRequest и OrderCancelRequest подставляются
все необходимые параметры, взятые из сообщения NewOrderSingle, такие как:
OrderID(37) – идентификатор заявки;
Price(44) – цена заявки;
Quantity(53) – размер заявки;
Side(54) – сторона заявки (покупка или продажа);
Symbol(55) – символическое обозначение инструмента.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
245](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-245-320.jpg)
![Начальная цена задается в массиве данных для каждого инструмента и для
каждой стороны (покупки или продажи). Начальные цены должны
удовлетворять следующим условиям:
- цена покупки должна быть меньше цены продажи;
- разница начальных цен продажи и покупки должна составлять около 2-3% от
цены открытия рынка.
Диапазон изменения цены покупки и продажи выбирается таким образом,
чтобы цены встречных предложений пересекались, обеспечивая торговлю, и
чтобы цены предложений не выходили за 10%-й барьер - условие, при
несоблюдении которого возможна остановка торговли на данном инструменте
или на целом сегменте инструментов. Эти параметры позволяют гибко
подбирать желаемое среднее соотношение количества сделок к количеству
изменений, приходящихся в среднем на одну заявку. Чем меньше область
пересечения цен покупки и продажи, тем меньше будет сделок, и заявка в
среднем будет изменяться большее количество раз. Надо заметить, что это
отношение нелинейно зависит от интервала пересечения цен. Поскольку цены
задаются для каждого инструмента в отдельности, становится возможным
настроить разное количество сделок на разных инструментах в одном тесте.
Шаг изменения цены задаётся исходя из конфигурации инструмента.
Например, одни инструменты могут торговаться с шагом цены 0,05, другие - с
шагом цены 0,10.
Механизм обратной связи необходим, чтобы отслеживать состояние заявки
на рынке и обеспечивать возможность изменения или отмены заявки. Заявка
может иметь следующие состояния:
New – заявка еще не приняла участие в торговле;
PartFilled – заявка выполнена частично;
Filled – заявка выполнена полностью;
Canceled – заявка отменена клиентом;
Expired – заявка с истекшим сроком действия;
Rejected – заявка отклонена биржей.
Только заявки в состояниях «New» и «PartFilled» могут участвовать в
торговле. Как только заявка переходит в другое состояние, она перестает быть
интересной, и информация о ней тут же удаляется.
4 Пример настройки разработанного генератора нагрузки
В этой части статьи подробнее остановимся на нескольких вариантах настройки
разработанного авторами генератора нагрузки для тестирования трейдинговых
систем на основе протокола FIX [16].
Настройка теста осуществляется посредством 4-х типов конфигурационных
файлов, которые содержат:
настройку параметров нагрузки;
конфигурацию сессий;
заготовку сообщений;
распределение по сообщениям.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
247](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-247-320.jpg)
![4.1. Формат файла параметров нагрузки
Для настройки параметров нагрузки используется файл, имеющий следующий
формат:
#Конфигурационный файл с настройками сессий:
CONNECTIONS_CONFIG = fixConnections.cfg
#Указание используемых сессий из файла с сессиями:
CONNECTIONS_RANGE = 1-3, 5, 7#Файл с заготовками сообщений:
MESSAGE_TEMPLATES = fixMessageTemplates.dat
#Файл с распределением по сообщениям:
MESSAGE_RATES = messageRates.cfg
#Последовательность действий до начала теста:
INIT_CONFIG = connect(100ms), logon(3s)
#Конфигурация нагрузки:
LOAD_CONFIG = const(1000,5m)
#Задается постоянная нагрузка 1000 сообщений в секунду
#на протяжении 5-и минут.
#Количество повторений нагрузочного сценария, заданного
#параметром LOAD_CONFIG:
NUMBER_REPETITIONS = 10
#Последовательность действий после окончания теста:
SHUTDOWN_CONFIG = logout(1s), disconnect(10ms)
#Последовательность действий при внезапном обрыве
#соединения
ON_RECONNECT_CONFIG = connect(10ms), logon(3s)
#Флаг на выполнение действий, указанных в
#ON_RECONNECT_CONFIG при обрыве соединения:
HOLD_CONNECTION = 1
#Если значение = 0, действия в ON_RECONNECT_CONFIG не
#выполняются, и соединение не восстанавливается.
#Время задержки между авторизацией сессий в миллисекундах
LOGON_INTERVAL = 1000
Поскольку у клиентов есть возможность использовать собственные
программы для торговли, существует вероятность того, что по какой-то
причине, например, в случае отправки торговой системой большого объёма
сообщений, клиентские программы не смогут вовремя прочитать эти данные.
Это может негативным образом повлиять на поведение торговой системы. Для
тестирования этой возможности в разработанном программном продукте
существует специальное ограничение по количеству читаемых данных в
секунду для эмуляции медленных клиентов.
4.2. Формат файла конфигурации сессий
Настройки параметров соединений задаются в файле следующего формата:
В секции COMMON задаются общие параметры соединений:
[COMMON]
HOST = 10.10.10.10
PORT = 5555
TARGET_COMP_ID = FGW
В секции [FIX] задаются уникальные параметры отдельного соединения:
[FIX]
SENDER_COMP_ID = LOAD_1
RESET_SEQ_NUM_AFTER_LOGOUT = 0
248
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-248-320.jpg)
![PARTY_ID = LOAD_1
Секция [FIX] должна повторяться столько раз, сколько предполагается
использовать соединений. При этом соединения, которым предстоит
участвовать в тесте, задаются параметром CONNECTIONS_RANGE в файле с
параметрами нагрузки.
4.3. Формат файла заготовок сообщений
Файл содержит массив именованных сообщений-заготовок. Эти заготовки
имеют правильные формат и последовательность полей в сообщениях.
Некоторые поля будут заменяться корректными данными непосредственно
перед отправкой сообщения.
Logon
8=FIXT.1.1|9=61|35=A|34=1|49=SenderCompID|56=TargetCompID|98=0|108=3600|
554=password|1137=9|10=135|EOM
NewOrderBuy
8=FIXT.1.1|9=199|35=D|34=1|49=SenderCompID|56=TargetCompID|1=CLIENT|11=C
lOrdID|38=200|40=2|44=9.8|54=1|55=Symbol|59=6|60=2013072813:34:03.194|432=20130730|528=P|581=3|1138=60000|9303=I|453=1|448=PartyI
D|447=D|452=76|10=047|EOM
NewOrderSell
8=FIXT.1.1|9=199|35=D|34=1|49=SenderCompID|56=TargetCompID|1=CLIENT|11=C
lOrdID|38=150|40=2|44=10.2|54=2|55=Symbol|59=6|60=2013072813:34:03.194|432=20130730|528=P|581=3|1138=60000|9303=I|453=1|448=PartyI
D|447=D|452=76|10=047|EOM
Cancel
8=FIXT.1.1|9=134|35=F|34=1|49=SenderCompID|56=TargetCompID|11=ClOrdID|41
=OrigClOrdID|54=1|55=Symbol|60=2013072813:34:03.178|9303=I|453=1|448=PartyID|447=D|452=76|10=050|EOM
Replace
8=FIXT.1.1|9=179|35=G|34=1|49=SenderCompID|56=TargetCompID|1=CLIENT|11=C
lOrdID|38=180|40=2|41=OrigClOrdID|54=1|55=Symbol|60=2013072813:34:03.178|432=20130730|1138=70000|9303=I|453=1|448=PartyID|447=D|452=
76|10=077|EOM
Logout
8=FIXT.1.1|9=29|35=5|34=111|49=SenderCompID|56=TargetCompID|10=249|EOM
4.4. Формат файла распределения нагрузки по сообщениям
Файл содержит соотношение количества сообщений, указанных в долях для
каждого типа сообщения:
NewOrderBuy = 15
Replace = 50
Cancel = 5
В зависимости от настройки, MESSAGE_SELECTION_ORDER = sequential
или random, сообщения будут выбираться или последовательно, или случайным
образом.
4.5. Упрощенная схема работы алгоритма
На рисунке 1 приведена блок-схема алгоритма по выбору и отправке
сообщений. На первом этапе происходит чтение входящих данных. В случае,
если данные есть, происходит анализ полученных ответов и изменение
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
249](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-249-320.jpg)
![Указанный объем нагрузки, создаваемой с одного сервера, превышает
пропускную способность существующих систем торговли акциями. Показатель
70,000 исходящих сообщений в секунду с одного ядра соответствует
максимальным показателям инструментов для тестирования веб-инфраструктур
с помощью статических запросов [17].
4.6. Настройка профиля нагрузки
В этой части статьи описывается настройка профиля нагрузки. Нагрузка
задается параметром:
LOAD_CONFIG = фаза1 [, фаза2, … фазаN]
Нагрузочная фаза может быть следующей:
-const(freq, dur) – постоянная нагрузка c частотой freq и длительностью
dur. Возможно также использовать сокращенный формат – freq:dur;
-step(freq, delta, steps, dur) – увеличивающаяся нагрузка с начальной
частотой freq, шагом изменения частоты delta, количаством шагов steps и
длительностью одного шага dur;
- connect(dur) – все сессии должны установить соединение с задержкой dur;
- disconnect(dur) – все сессии должны оборвать соединение с задержкой dur;
- logon(dur) – все сессии должны послать сообщение с авторизацией с
задержкой dur;
- logout(dur) – все сессии должны послать сообщение о прекращении сессии с
задержкой dur;
Обрыв соединения сам по себе не является критической проблемой.
Например, все web-соединения, и особенно соединения в мобильных
приложениях, рассчитаны на то, что они будут прерываться. Для финансовых
протоколов это событие может означать потерю участником торговли контроля
над его заявками, и многие системы настроены на отмену всех открытых заявок.
Если клиент активно ведёт торговлю и выставляет много заявок, потеря
соединения приведет к тому, что его заявки будут массово отменены системой,
что вызовет повышенную нагрузку на ядро системы. Также необходимо знать,
как поведёт себя система при восстановлении соединения и авторизации под
нагрузкой. Очень важно иметь возможность воспроизводить внезапный обрыв и
восстановление соединения под нагрузкой. Для этой цели были созданы выше
описанные фазы: connect, disconnect, logon, logout.
На рисунке 2. Изображены различные нагрузочные профили const, step и
micro burst. Последний профиль создается при помощи фазы const с малой
длительностью и высокой нагрузкой.
Рис. 2. Простейшие варианты профилей нагрузки.
const: LOAD_CONFIG=const(1000, 20m)
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
251](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-251-320.jpg)
![step: LOAD_CONFIG=step(500, 500, 4, 4m)
micro burst: LOAD_CONFIG=200:5m, 40000:10ms, 200:5m, 75000:10ms, 200:5m
Из опыта авторов, нагрузка в форме ступеней (step) в наибольшей степени
подходит для определения максимальной производительности системы.
Нагрузка в форме микро-всплекса в наибольшей степени воспроизводит
поведение современных высоконагруженных трейдинговых систем.
5 Заключение
Созданный и описанный в данной статье инструмент тестирования
используется при измерении пропускной способности и времён отклика
крупномасштабных биржевых и брокерских платформ, обеспечивающих
технологическую инфраструктуру финансовых рынков, в рамках проектов,
осуществляемых при поддержке компании Exactpro Systems LLC. Достигнутые
результаты подтверждают эффективность выбранных методов работы:
управление исполняемыми потоками посредством центрального контроллера и
использование заготовленных шаблонов при генерации потока сообщений.
Планируется дальнейшее расширение списка открытых и коммерческих
протоколов коммуникаций, поддерживаемых данным инструментом для
тестирования. Несмотря на то, что существующая производительность
генератора нагрузки позволяет создать реалистичный поток данных, используя
один сервер, достаточный для перегрузки любой из существующих торговых
площадок, а также для обеспечения качества трейдиговых систем, которые
появятся в ближайшие годы, планируется разработка масштабируемого модуля,
позволяющего контролировать нагрузку, создаваемую с нескольких серверов.
Основным
направлением
исследовательской
работы
станет
совершенствование механизмов обработки обратного потока данных для
повышения сложности и реалистичности сценариев нагрузочного тестирования
торговых платформ. При этом высокая экономичность и эффективность
используемых для тестирования инструментов сохранятся.
Источники
1. The Future of Computer Trading in Financial Markets. Final Project Report. / Foresight. The
Government Office for Science, London. // [Электронный ресурс]. – Режим доступа
http://www.bis.gov.uk/assets/foresight/docs/computer-trading/12-1086-future-of-computertrading-in-financial-markets-report.pdf
2. Commission Roundtable on Technology and Trading: Promoting Stability in Today's
Markets. / U.S. Securities and Exchange, October 2, 2012 // [Электронный ресурс]. – Режим
доступа http://www.sec.gov/news/otherwebcasts/2012/ttr100212-transcript.pdf
3. Apache JMeter manual // [Электронный ресурс]. – Режим доступа
http://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.pdf
4. HP LoadRunner manual // [Электронный ресурс]. – Режим доступа
ftp://ftp.itrc.hp.com/applications/HPSoftware/ONLINE_HELP/LoadRunner11.50_User.pdf
252
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-252-320.jpg)
![5. Rational Performance Tester // [Электронный ресурс]. – Режим доступа http://www03.ibm.com/software/products/ru/ru/performance/
6. Silk Performer // [Электронный ресурс]. – Режим доступа
http://www.borland.com/products/silkperformer/
7. Penhaligan,P.: Equity Trading: Performance, Latency Throughput. / ExTENT Conference
// [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3turquoise-equitytrading2012
8. Benedetti E., Zanetti L.: London Stock Exchange - The Focus Beyond Low Latency. /
ExTENT Conference // [Электронный ресурс]. – Режим доступа
http://www.slideshare.net/extentconf/extent-2013-obninsk-lse-the-focus-beyond-low-latency
9. Cong, J.: Load Specification and Load Generation for Multimedia Traffic Loads in
Computer Networks. // Ph.D. Dissertation, FB Informatik, Univ. Hamburg, 2006; also
published at: Shaker-Verlag, Aachen 2006
10. Jing Cong, Bernd E. Wolfinger: A Unified Load Generator Based on Formal Load
Specification and Load Transformation // valuetools '06: Proceedings of the 1st international
conference on Performance evaluation methodolgies and tools
11. Bodík P., Fox A., Franklin M., Jordan M., Patterson D.: Characterizing, Modeling, and
Generating Workload Spikes for Stateful Services // SoCC’10, June 10–11, 2010
12. David Mosberger, Tai Jin: httperf—a tool for measuring web server performance //
SIGMETRICS Performance Evaluation Review , Volume 26 Issue 3, December 1998
13. Иткин И.Л.: Тестирование биржевых систем в условиях высокочастотного трейдинга
// SQA Days #10: http://sqadays.com/talk.sdf/sqadays/11151/talks/12196
14. Yandex.Tank Documentation // [Электронный ресурс]. – Режим доступа
https://media.readthedocs.org/pdf/yandextank/latest/yandextank.pdf
15. Itkin Iosif: Theory of High Frequency Trading systems testing // Software Development
Analysis Technologies Seminar http://sdat.ispras.ru/2011/09/20-октября-моделитестирования-систем/ http://www.slideshare.net/IosifItkin/theory-of-high-frequency-tradingsystems-testing
16. Официальный сайт FIXprotocol // [Электронный ресурс]. - Режим доступа
http://www.fixprotocol.org/
17. How to Generate Millions of HTTP Requests // [Электронный ресурс]. - Режим доступа
http://dak1n1.com/blog/14-http-load-generate
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
253](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-253-320.jpg)
![Использование MBT-подхода для верификации
систем мониторинга и контроля на фондовых биржах
Наталья Прядкина1, Антон Крюков1
1 Костромской государственный технологический университет 156005, г. Кострома,
ул. Дзержинского, 17
Natalia.Pryadkina@exactpro.com, Anton.Kryukov@exactpro.com
Аннотация. Данная статья описывает проблемы тестирования систем мониторинга и контроля на фондовых биржах (СМКнФБ). На сегодняшний
день такие системы представляют собой комплексные программные продукты, реализующие сложные математические алгоритмы и обрабатывающие большой объём данных. Одной из их задач является уменьшение
количества ложных срабатываний, что достигается за счёт наиболее полного покрытия при тестировании. В работе определены подходы для адаптации метода тестирования на основе модели (ТнОМ, MBT) к верификации СМКнФБ. Построена структурная модель системы, дано формализованное описание метода в нотации IDEF0. Определены требования к степени абстракции функциональной модели СМКнФБ, необходимой для
проведения тестирования. Ключевые слова: обеспечение качества; тестирование на основе модели; автоматическое создание тестовых сценариев;
система мониторинга на фондовых биржах.
1 Введение
В связи с тем, что манипуляции на фондовых биржах подрывают эффективность финансовых рынков и доверие к ним, вплоть до снижения стабильности
всей экономической системы, они являются одной из серьёзных проблем для
финансовых организаций и участников торгов [1, 7].
В настоящее время законодательство обязывает финансовые институты применять системы мониторинга и контроля (СМКнФБ, surveillance system) с целью выявления и пресечения незаконных действий на рынке, таких как распространение недостоверной информации, манипулирование ценами или мошенничество за счёт использования информации, недоступной широкой публике
(инсайдерская информация) [1, 2].
Современные СМКнФБ являются комплексными продуктами, интегрированными в трейдинговые системы, и основываются на адаптивной логике. Они
реализуют сложные математические алгоритмы, собирают статистическую информацию о ситуации на рынке и обрабатывают большие объёмы данных в
режиме реального времени. Одной из их задач является уменьшение количества
254
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-254-320.jpg)
![ложных срабатываний, т.е. сокращение количества ошибок первого и второго
рода [2].
Такие системы требуют особого подхода к тестированию. Существует множество методов, которые могут быть применимы для верификации работы информационной системы. Выбранный метод – в идеале - должен обеспечивать
достижение ряда целей:
1. универсальная теория всего;
2. моделирование на основе тестов (test-based modeling);
3. стопроцентная автоматизация тестирования;
4. максимально полное проектирование тестов [3].
Методологии тестирования исторически развиваются так, что каждая из них
делает ещё один шаг в этих направлениях.
Метод тестирования на основе модели (ТнОМ, model-based testing, MBT)
нашёл широкое применение в проверке качества работы информационных систем. Данный подход имеет значительный потенциал для выполнения гибкоуправляемого тестирования сложных систем, которые не могут быть протестированы в достаточной мере при помощи основных технологий с приемлемыми
трудозатратами [11].
Во второй главе данной статьи будут рассмотрены особенности систем мониторинга и контроля на фондовой бирже; в третьей – основные методологии,
которые могут быть применены к тестированию таких систем, а также будет
сделан вывод о наиболее эффективной из них; в четвертой главе будут определены основные подходы для адаптации метода тестирования на основе модели к
верификации СМКнФБ.
2 Особенности систем мониторинга и контроля на фондовой
бирже
СМКнФБ выполняет функцию мониторинга рынка с целью выявления нетипичных ситуаций, которые могут служить идентификаторами незаконных финансовых транзакций [8, 16]. Контролируют данный процесс такие регулирующие органы в сфере финансовых услуг, как: Департамент управления финансовыми рынками Великобритании (Financial Conduct Authority, FCA), Комиссия
по ценным бумагам и биржам США (Securities and Exchange Commission, SEC)
и другие [5].
В таблице 1 отображены основные требования к СМКнФБ.
Табл. 1. Требования к системе мониторинга и контроля на фондовой бирже
Требование
Определение и предотвращение
различных типов мошенничества на бирже
Описание
На сегодняшний день существуют десятки типов
поведения на рынке, которые могут быть расценены как мошенничество. СМКнФБ должны
сигнализировать о потенциально нелегитимном
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
255](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-255-320.jpg)
![Гибко настраиваемые алгоритмы
распознавания
образов
(адаптивная логика)
Обработка большого количества
данных в режиме реального
времени
Минимизация ложных (ложноположительное / ложноотрицательное) срабатываний: избежание ошибок первого и второго
рода
Интеграция с трейдинговой
системой: поддержка различных
протоколов
Сбор статистических данных за
определенный период
поведении с помощью сигнала тревоги (alert).
Пусковые механизмы этих сигналов реализуются с помощью математических алгоритмов
Для эффективного выявления мошенничества
необходимо непрерывно адаптировать существующие алгоритмы к новым ситуациям, возникающим в ходе торгов [6]
СМКнФБ непрерывно получает информацию от
трейдинговых и других внешних систем, обрабатывает её и выдаёт результат анализа (сигналы
о потенциально нелегитимном поведении участников торгов и статистика), информацию о состоянии рынка
Основной проблемой современных систем мониторинга и контроля на фондовой бирже является разграничение нарушителей и механизмов
биржи, отвечающих за ликвидность на рынке
(market makers). Необходимо минимизировать
ошибки первого рода (false positives) – ложная
тревога – и ошибки второго рода (false negatives)
– пропуск случаев манипулирования и иных
нарушений на рынке
Вследствие того, что трейдинговая система использует различные протоколы для обмена информацией с клиентами и внешними системами,
возникает необходимость поддержки их и в
СМКнФБ. Кроме этого, такая система поддерживает внутренние протоколы
СМКнФБ, кроме наблюдения в режиме реального времени за чистотой и упорядоченностью
биржевой торговли, должна нести в себе функцию сбора статистических данных и предоставлять возможность детального восстановления
ситуации на рынке на определенный период
времени.
Особенности, обозначенные в таблице 1, влекут за собой повышенные требования к тестированию таких систем.
В процессе верификации СМКнФБ, как и любой системы, тестировщики
стремятся осуществить близкую к стопроцентной проверку работоспособности
системы, что достигается за счёт большего покрытия и большего количества
тестовых сценариев [14]. С другой стороны, с расширением библиотеки тестов
увеличивается время, необходимое на верификацию работы СМКнФБ. Более
того, незначительное изменение функциональности системы может повлечь за
собой существенное преобразование библиотеки тестов.
256
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-256-320.jpg)
![Таким образом, проблема выбора оптимального метода для построения процесса тестирования СМКнФБ является актуальной.
На Рисунке 1 представлена, разработанная в рамках проектов компании Exactpro Systems, LLC, структурная модель системы мониторинга и контроля на
фондовых биржах, определены главные компоненты и информационные потоки, типичные для такой системы.
Рис. 1. Структурная модель системы мониторинга и контроля на фондовой бирже, разработанная в рамках проектов компании Exactpro Systems, LLC
Как видно из рисунка 1, СМКнФБ может получать информацию как по сетевым протоколам TCP/IP и UDP, так и проводить анализ на основе файла. Используются базы данных Level DB для сохранения обрабатываемых сообщений;
Mongo DB – для сигналов тревоги о потенциальном случае манипулирования
или иного нарушения (surveillance alerts) и статистики. Поток сообщений в системе обрабатывается с помощью так называемых «акторов» (actors systems,
akka) трансляции, хранения сообщений, сценариев и бизнес логики.
3 Выбор метода тестирования
Верификация работы программных продуктов охватывает широкий спектр
деятельности: от тестировании, выполняемого разработчиками (unit testing), до
приёмо-сдаточных испытаний (acceptance testing) [3, 9].
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
257](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-257-320.jpg)
![В этой главе была проанализирована возможность применения различных
методологий к тестированию СМКнФБ.
3.1 Методы тестирования
3.1.1 Ручное тестирование (Manual Testing)
Несмотря на ряд ограничений, присущих ручному тестированию, оно широко
используется при верификации определенного рода программных продуктов.
Тестировщик, используя тестовый план и спроектированные сценарии, воздействует на систему и считывает результат своего воздействия с её графического интерфейса.
Хотя СМКнФБ и имеет свой интерфейс, с помощью которого пользователь
может считывать информацию (окна приложения), для воспроизведения даже
одного вида потенциальных нарушений, необходимо сделать десятки манипуляций. Более того, чем разнообразнее становится функциональность системы,
тем сложнее делать повторный прогон тестов на новой версии (regression
testing). К тому же, система обрабатывает огромный поток данных, за которым
порой трудно уследить.
3.1.2 Тестирование на основе скриптов (Script Based Testing)
Тестирование на основе скриптов нашло широкое применение в процессе верификации программных продуктов.
Данный метод предполагает использование тестового инструмента, который
применяется для автоматического прогона тестовых сценариев, написанных на
специальном языке. Сами же тесты пишутся вручную.
Пользователь СМКнФБ, применяя специальные инструменты, может отправлять данные, воздействуя на систему, а также получать ответ от системы и сопоставлять его с ожидаемым результатом.
3.1.3 Тестирование на основе модели (Model Based Testing)
Коротко данный вид тестирования можно охарактеризовать как автоматизированное проектирование тестов черного ящика. Вместо того, чтобы вручную
создавать тесты, основанные на документации, MBT подход подразумевает
проектирование модели, отвечающей некоторым требованиям и имитирующей
тестируемую систему [4].
258
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-258-320.jpg)
![3.2 Оценка методов тестирования систем мониторинга и контроля на
фондовых биржах
Метод тестирования систем мониторинга и контроля на фондовых биржах
должен отвечать следующим требованиям:
1. обеспечение наиболее полного покрытия тестами [15];
2. высокая степень автоматизации сценариев тестирования;
3. возможность повторного выполнения сценариев (regression testing);
4. минимизация ошибок первого и второго рода (ложных срабатываний);
5. выполнение прогона библиотеки тестов за приемлемое время;
6. минимизация изменений сценариев тестирования при изменении функционального поведения системы:
7. обеспечение возможности автоматизированного тестирования при недетерминированном поведении системы.
MBT метод наиболее полно отвечает всем обозначенным выше требованиям.
4 Тестирование на основе модели (Model Based Testing)
Методология тестирования на основе модели предполагает автоматизацию
процесса проектирования сценариев тестирования и матриц покрытия (traceability matrix) [4].
Данный подход позволяет существенно снизить затраты на создание библиотеки тестовых сценариев: вместо ручного написания тестировщиком сотен и
тысяч сценариев, проектировщик создает абстрактную модель системы, затем с
помощью инструмента MBT автоматически генерируется множество тестовых
сценариев на основе этой модели. Таким образом, общее время проектирования
тестов сокращается; кроме того, при использовании других критериев отбора,
может быть создан новый тестовый набор на основе существующей модели [4,
12].
Модель должна представлять собой проекцию структуры и поведения системы, причём может быть спроектирована как целая система, так и отдельные её
функциональные части.
4.1 Этапы МВТ подхода
Формализованное описание тестирования на основе модели дано на рисунке
2. На первом этапе происходит проектирование модели системы. Здесь необходимо выбрать оптимальную степень абстракции, удовлетворяющую заданным
требованиям.
На втором этапе на основе модели создаются абстрактные тестовые сценарии. Вследствие того, что количество всевозможных тестов стремится к бесконечности, нам необходимо выбрать критерии отбора, которые ограничат множество тестовых вариантов до требуемого. Выходными данными на этом этапе
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
259](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-259-320.jpg)
![2. Jens Wirén Farhad Kimanos: A Survey Implementation of Financial Alarm Classification
[Электронный
ресурс]
//
Режим
доступа
–
http://scila.se/wpcontent/uploads/2013/07/AIforAlertClassification-ScilaReport.pdf
3. Antonia Bertolino Software Testing Research: Achievements, Challenges, Dreams [Электронный
ресурс]
//
Режим
доступа
–
http://ieeexplore.ieee.org/xpl/login.jsp?tp=arnumber=4221614url=http%3A%2F%2Fieeexp
lore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4221614
4. Mark Utting, Bruno Legeard: Practical Model-Based Testing a Tools Approach. Morgan
Kaufmann Publishers, 2007
5. Michael J. Aitken: Strategic Surveillance in the Philippine Capital Markets and the expectations of surveillance technology [Электронный ресурс] // Режим доступа –
http://www.telchar.com/pdf/surveillance.pdf
6. Иосиф Иткин, Наталья Прядкина, Антон Крюков: «Анализ данных в высоконагруженных трейдинговых системах» [Электронный ресурс] // Режим доступа –
http://clubqa.ru/blogs/?p=436
7. David Diaz, Mohamed Zaki, Babis Theodoulidis, Pedro Sampaio: A Systematic Framework
for the Analysis and Development of Financial Market Monitoring Systems [Электронный
ресурс]
//
Режим
доступа
–
http://ieeexplore.ieee.org/xpl/login.jsp?tp=arnumber=5958083url=http%3A%2F%2Fieeexp
lore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5958083
8. Johan Örtenblad, Vladimir Vlassov, Torkel Erhardsson, Håkan Carlbom, Johan Norén: Market
Surveillance
System
[Электронный
ресурс]
//
Режим
доступа
–
http://web.it.kth.se/~maguire/DEGREE-PROJECT-REPORTS/020606-Johan-Ortenblad.pdf
9. Noah Höjeberg: Random Tests In A Trading System Using Simulations And A Test Oracle
[Электронный
ресурс]
//
Режим
доступа
–
http://kiosk.nada.kth.se/utbildning/grukth/exjobb/rapportlistor/2008/rapporter08/hojeberg_noah
_08037.pdf
10. Wolfgang Prenninger, Alexander Pretschner: Abstractions for Model-Based Testing [Электронный ресурс] // Режим доступа – ftp://ftp.ira.uka.de/pub/ZVI/papers/tacos04.pdf
11. Victor V. Kuliamin: Model Based Testing of Large-scale Software: How Can Simple Models
Help to Test Complex System [Электронный ресурс] // Режим доступа –
http://panda.ispras.ru/~kuliamin/docs/ISOLA-2004-en.pdf
12.Mark Utting, Alexander Pretschner, Bruno Legeard: A Taxonomy Of Model-Based Testing
[Электронный ресурс] // Режим доступа – http://www.cs.waikato.ac.nz/pubs/wp/2006/uowcs-wp-2006-04.pdf
13. Learning from Financial Trading Bugs [Электронный ресурс] // Режим доступа –
http://gaynwinters.wordpress.com/2012/10/26/learning-from-financial-trading-bugs/
14. NASA Software Safety Guidebook [Электронный ресурс] // Режим доступа –
http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf
15. Phyllis Franklt Dick Hamlet Bev Littlewood Lorenzo Strigini: Choosing a Testing Method to
Deliver
Reliability
[Электронный
ресурс]
//
Режим
доступа
–
http://www.computer.org/csdl/proceedings/icse/1997/2162/00/21620068-abs.html
16. Afroditi Katika, Babis Theodoulidis, David Diaz: Investigating Financial Fraud In High Frequency Trading: Context And Drivers [Электронный ресурс] // Режим доступа –
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1974911
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
263](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-263-320.jpg)
![Тестирование графического интерфейса
трейдинговых терминалов в условиях
высокочастотной торговли
Иван Бобров1, Алексей Зверев
2
1
ООО «Инновационные Трейдинговые Системы», Россия, 156013, г. Кострома, ул.
Ленина, 20
Ivan.Bobrov@exactpro.com
2
Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA
Alexey.Zverev@exactpro.com
Aннотация. При работе систем высокочастотного трейдинга в
состоянии максимальной нагрузки количество изменений
котировок может достигать нескольких тысяч в секунду. Для
слежения за рынком на экранах терминалов применяются
специальные графические средства, реализованные в виде
программного обеспечения. Тестирование такого программного
обеспечения представляет собой специфическую задачу. В статье
рассматривается метод проверки функциональности графического
интерфейса трейдинговых систем. Для тестирования предлагается
сохранять графическое представление областей интерфейса в
момент их перерисовки операционной системой. Полученные
таким образом данные в оцифрованном виде сравниваются с
данными, полученными из независимого источника котировок. В
статье описывается реализация предложенного метода и
анализируются результаты с точки зрения применимости в
условиях реальной торговли.
1 Введение
В последние годы высокочастотная торговля занимает большую часть торгов на
соответствующих электронных площадках. По данным РТС в 2010 году на долю
торговых роботов в обороте на срочном рынке РТС FORBS приходилось
примерно 50%, а их доля в общем количестве заявок в определенные моменты
достигала 90% [1]. Системы, ориентированные на высокочастотную торговлю,
многокомпоненты и строятся из расчёта максимальной отдачи и надежности.
Основными компонентами, напрямую используемыми пользователями,
являются торговые терминалы и шлюзы, находящиеся под управлением
специализированных протоколов, таких как FIX, NATIVE [2]. За информацию,
на базе которой эти компоненты формируют представление о рынке, отвечает
компонент, являющийся важной составляющей любой торговой платформы и
264
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-264-320.jpg)
![отвечающий за поставку котировок [3]. Поставщик котировок предоставляет
котировки и другую финансовую информацию в режиме реального времени, что
позволяет получателям обрабатывать и представлять её конечному
пользователю в том или ином виде.
2 Торговый терминал и шлюз
Торговый терминал – это программное обеспечение, позволяющее трейдеру в
режиме реального времени получать всю необходимую информацию о ходе
торгов на мировых биржевых и внебиржевых рынках, а также анализировать
полученные данные посредством встроенных в торговый терминал
инструментов и делать выводы, на основе которых совершать торговые сделки.
[4].
Основным отличием торгового терминала является графическая оболочка,
посредством которой происходит отображение данных на экран. В случае с
подключением через шлюз, все данные, как правило, передаются в формате
протокола, по которому совершено подключение (см. рисунок 1). В итоге сам
торговый терминал может быть подключен непосредственно через подобный
протокол к рынку.
И шлюз и терминал, получают данные, основанные на потоке,
распространяемом компонентом поставщика котировок. В случае со шлюзом
пользователь самостоятельно производит расшифровку полученного пакета
данных, а в терминале вся информация представляется в удобочитаемом виде.
На сегодняшний день количество заявок, обрабатываемых биржей, в течение
торговой сессии исчисляется миллионами. Особенностью же HFT логики
является высокоскоростной обмен сообщениями с рынком в зависимости от
модели торгового робота. В ходе эволюции средств связи и коммуникации
скорость обработки запросов значительно возросла, а время ответа системы на
запрос стало исчисляться в микросекундах [5].
Таким образом, в момент максимальной нагрузки рынка торговый терминал
получает информацию со скоростью, с которой вывод на экран сделает
невозможным попытки визуально отследить все изменения, происходящие в
окне клиента, вследствие чего пользователь не сможет дать адекватную оценку
корректности отображаемой информации.
При приёме данных через шлюз весь поток информации будет сохранен в
виде сообщений, полученных в рамках установленной сессии и доступных для
анализа, что позволяет выполнить их проверку на соответствие спецификации
без каких-либо серьёзных потерь и в любой удобный для этого момент времени.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
265](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-265-320.jpg)
![Рис. 1. Пример графического интерфейса трейдингового терминала.
3 Симуляция нагрузки
Для тестирования системы в состоянии высокочастотного трейдинга в первую
очередь необходимо создать условия, совпадающие с представлениями о
высокой нагрузке. Для создания подобных условий может быть использован
инструмент «Генератор нагрузки» (англ. LoadInjector), разработанный
компанией Exactpro Systems LLC. Инструмент позволяет согласно
сконфигурированному сценарию создавать и поддерживать продолжительную
отправку и приём большого количества сообщений, доводя таким образом
торговую систему до необходимого уровня нагрузки.
Объектом тестирования выступает графическая оболочка торгового клиента,
из которой необходимо получить поток данных для анализа. В качестве эталона
для сравнения в ходе анализа может быть использован шлюз, подписка через
который на мониторинг отправки котировок позволит получить достаточно
надёжную картину происходящего на протяжении всего периода теста.
Для этого организуется подключение по протоколу шлюза с последующей
подпиской на необходимые обновления, которые будут сохранены в виде набора
сообщений в формате используемого протокола обмена данными.
Тесты проводились при помощи симуляции исторической маркет даты,
доступной для общего доступа на сайте histdata.com, воспроизводимой с
различной скоростью.
4 Запись данных из графического интерфейса
Требуется сохранить аналогичный поток изменений в окне торгового
терминала. Для осуществления этого есть несколько возможных способов.
Первый способ - запись области экрана в видеофайл посредством
специальных утилит, таких как CamStudio [6], c последующей обработкой и
266
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-266-320.jpg)
![На данном этапе алгоритм применим для большинства торговых клиентов,
содержимое книжки которых отражается на экране терминала. Однако стоит
учитывать, что реализация отображения не одинакова в разных клиентах.
Объект тестирования и реализованный алгоритм узко специализированны
относительно объекта тестирования и для применения алгоритма против
другого клиента он потребует переработки в зависимости от того как будет
представлена информация на экране терминала. Таким образом основных
изменений потребует часть преобразования снятой графической информации.
5 Microsoft Detours
В качестве инструмента для реализации выбранного метода, используется
библиотека Microsoft Detours [7]. Данная библиотека позволяет устанавливать
перехватчики стандартных событий системы и использовать собственную
процедуру, предваряющую дальнейшее выполнение (Рисунок 2.). В случае с
торговым терминалом, перехватчик устанавливается на событие перерисовки
любого графического элемента экранной формы торгового терминала.
Процедура сохраняет графическое представление переданной области,
которая будет изменена, в виде файла, в имени которого сохраняется
идентификатор окна, штамп даты и времени, а также координаты, по которым
происходит перерисовка. На основании полученного набора файлов делается
выборка по зонам, в которых отображается информация. Особенностью
различных графических интерфейсов трейдинговых терминалов является их
способность одновременно показывать ситуацию сразу по нескольким торговым
инструментам в отдельно открытых окнах или наоборот - показывать лишь один
инструмент строго в одном окне интерфейса. Для записи в таком случае может
быть использовано как одно окно одного инструмента, так и весь набор окон с
привязанными к ним инструментами.
Следующим шагом является преобразование графического представления в
читаемый массив значений. На основании полученных значений, а также
значений из подписки к шлюзу, строятся два набора книжек [8] с определенным
шагом времени (t). Во внимание принимается максимальное количество заявок,
отображаемых в торговом терминале.
268
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-268-320.jpg)
![короткого интервала она будет перерисована другой, правильной, книжкой.
Однако, с другой стороны, если плотность непопаданий велика, то возрастает
вероятность того, что пользователь увидит некорректную книжку, и такое
поведение следует считать существенным дефектом пользовательского
интерфейса.
На основе предложенного подхода (Рисунок 4) был разработан инструмент,
позволяющий перехватывать все изменения графического интерфейса, а также
дополнительные инструменты для
распознавания графических данных,
построения книг заявок и сравнения двух наборов книг между собой [9].
Рис. 4. Графическая схема метода, разработанного на базе
библиотеки Microsoft Detours
7 Заключение
В данной статье мы показали, что имеется техническая возможность валидации
активного потока котировок, демонстрируемого пользователю через элементы
графического интерфейса. Мы разработали инструменты, реализующие
представленную методику снятия данных. В результате построенный набор
инструментов позволяет эффективно анализировать графическую выдачу и
сравнивать её с независимым цифровым потоком, а также вычислять задержки и
потенциальные несовпадения двух потоков.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
271](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-271-320.jpg)
![Источники
1. Slon.ru - Деловые новости и блоги // [Электронный ресурс]. – Режим
доступа http://slon.ru/economics/lyudi_luchshe_robotov-970172.xhtml
2. Официальный сайт FIXprotocol // [Электронный ресурс] - Режим доступа
http://www.fixprotocol.org/
3. Wikipedia // [Электронный ресурс]. - Режим доступа
http://en.wikipedia.org/wiki/Market_data
4. Форекс журнал для трейдеров // [Электронный ресурс]. -
http://fortrader.ru/forex-terminals/
5. Leo King.: London Stock Exchange smashes world record treade speed with
Linux. / Coputerworld UK // [Электронный ресурс].
http://www.computerworlduk.com/news/networking/3244936/london-stock-exchangesmashes-world-record-trade-speed-with-linux/
6. Официальный сайт CamStudio // [Электронный ресурс]. - Режим доступа
http://camstudio.org
7. Dejan Lukan.: API Hooking with Microsoft Detours / INFOSEC Institute
Resources // [Электронный ресурс]. - Режим доступа
http://resources.infosecinstitute.com/api-hooking-detours/
8. Wikipedia // [Электронный ресурс]. - Режим доступа
http://en.wikipedia.org/wiki/Order_book_%28trading%29
9. Zverev,A., Bobrov,I, Pryadkina,N..: Testing of HFT GUI. / ExTENT conference
// [Электронный ресурс]. – Режим доступа
http://www.slideshare.net/extentconf/extent3-exactpro-testingofhftgui-12944204
272
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-272-320.jpg)
![Динамический поиск гонок в Java-программах на
основе синхронизационных контрактов
Дмитрий Цителов (tsitelov@acm.org), Devexperts LLC
Виталий Трифанов (vitaly.trifanov@gmail.com), СПбГУ
Аннотация. Состояние гонки (data race) возникает в многопоточной
программе, когда несколько потоков одновременно обращаются к одному
и тому же разделяемому участку памяти, где хотя бы одно обращение –
запись. Состояния гонки слабо локализованы и их сложно обнаружить
вручную, поэтому исследования в области автоматического поиска гонок
ведутся уже более 20 лет. В данной статье рассматриваются вопросы
производительности и точности динамического поиска гонок в Javaпрограммах и предлагается идея снижения накладных расходов
обнаружения с помощью синхронизационных контрактов. Последние
опираются на описания пар вызовов методов, обеспечивающих
синхронизацию потоков, и помогают исключать из анализа части целевого
приложения, не интересные с точки зрения поиска гонок – например,
сторонние библиотеки. Приводится схема языка спецификации
контрактов и некоторые технические детали реализации, рассматриваются
преимущества и ограничения подхода.
Ключевые слова: многопоточность, состояние гонки, динамический
анализ, автоматическое обнаружение ошибок.
1
Введение
С развитием многоядерных и многопроцессорных систем все большее
количество программ создаются многопоточными. Использование нескольких
потоков выполнения может приводить к дополнительным ошибкам, связанным
с некорректной организацией взаимодействия этих потоков. Такие ошибки
сложно искать вручную, поскольку чередование операций в потоках обладает
высокой степенью неопределённости, и программисту нужно полностью
просчитать все возможные ситуации. Одной из типичных ошибок
многопоточных программ является наличие в них состояний гонки (data races).
Они возникают, когда несколько потоков без должной синхронизации
обращаются к одному и тому же разделяемому участку памяти, где хотя бы
одно обращение – запись [14]. Дополнительная трудность с обнаружением
гонок состоит в том, что они, как правило, не приводят к немедленному сбою и
отказу программы. Напротив, приложение продолжает работать с
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
273](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-273-320.jpg)
![повреждёнными глобальными структурами данных, что приводит к
труднообъяснимым эффектам впоследствии.
За несколько последних десятков лет было разработано несколько
статических и динамических подходов к обнаружению гонок. Статические
детекторы ([7,11,13]) анализируют все пути исполнения программы, не требуют
её запуска, но обладают низкой точностью. Динамические ([3,4,6,8,15,16,17,18])
анализируют программу во время её работы, но ограничены лишь фактическим
путём выполнения программы. Хотя динамические алгоритмы и обладают
полной информацией о конкретном пути выполнения программы, на практике
их точность ограничена накладными расходами, которые они вносят. Проблема
достижения высокой точности обнаружения гонок и отсутствия ложных
срабатываний (false positives) при сохранении приемлемого уровня потребления
аппаратных ресурсов является краеугольной технической проблемой
динамического анализа.
Данная работа предлагает способ понижения накладных расходов на
динамическое обнаружение гонок в Java-программах без потери точности.
Основная идея заключается в сокращении области программы, где
отслеживаются все операции синхронизации. Чтобы это не привело к потере
информации о синхронизации между потоками и, как следствие, к ложным
срабатываниям, вводится понятие синхронизационного контракта, которое
позволяет в достаточной степени описать поведение исключённого кода в
многопоточной среде. Далее во время работы детектор распознает эти
контракты и встретив методы, соответствующие им, обрабатывает эти методы
как высокоуровневые синхронизационные события. Такой подход позволяет
восполнить неотслеженные операции синхронизации и обеспечить высокую
точность поиска.
Дальнейшая часть статьи организована следующим образом. Во второй главе
описывается отношение happens-before и приводится формальное определение
понятия гонки в терминах спецификации Java, после чего описывается точный
алгоритм поиска гонок, основанный на отслеживании этого отношения. Третья
глава акцентируется на проблеме обеспечения одновременно точности
динамического поиска гонок и приемлемого уровня накладных расходов. В
четвертой главе излагается концепция синхронизационных контрактов, в пятой
главе – её реализация в разработанном нами динамическом детекторе гонок
jDRD. Шестая глава посвящена преимуществам и недостаткам подхода и
содержит некоторые экспериментальные результаты. В заключении мы
подводим итог и указываем дальнейшие возможные направления работы. В
приложении описан язык описания контрактов, используемый в jDRD.
2
Happens-before алгоритм поиска гонок
Отношение happens-before было предложено Лесли Лампортом в работе [10]
для установления частичного порядка на множестве всех событий
распределенной системы, в которой единственный способ взаимодействия
274
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-274-320.jpg)
![между участниками – это обмен сообщениями. Данный подход хорошо
переносится на многопоточные системы, если рассматривать каждый поток как
отдельного участника системы, а операции синхронизации – как передачу
сообщений. Язык программирования Java был одним из первых языков с
собственной архитектурно-независимой моделью памяти, определяющей
семантику взаимодействия потоков через отношение happens-before, и
распространяющей это отношение на все операции в программе.
Для этого в спецификации Java [9] сначала вводится отношение
синхронизированности (synchronized-with) – полное отношение порядка на
множестве всех операций синхронизации в программе. Так,
освобождение монитора синхронизировано с его последующими захватами;
запись volatile-переменной синхронизирована с ее последующими чтениями;
запуск потока синхронизирован с первым действием в потоке;
последнее действие в потоке T1 синхронизировано с любым действием в
другом потоке, случившемся после того, как тот обнаружил, что T1
завершился;
прерывание потока T1 синхронизировано с любым действием в другом
потоке, которое обнаружит, что T1 получил сигнал прерывания.
События слева (например, захват монитора) будем называть отправкой, а
справа (отпускание монитора) – приёмом синхронизационного сообщения.
Обратим внимание, что во всех случаях с синхронизационным сообщением
естественным образом ассоциирован уникальный объект – монитор, volatileпеременная или объект потока. Поэтому далее будем считать, что с каждой
парой
синхронизированных
событий
связан
некий
уникальный
синхронизационный объект.
Объединение
отношения
синхронизированности
с
естественным
темпоральным отношением порядка в рамках операций одного потока даёт
частичное отношение порядка – отношение предшествования (happens-before),
определённое уже на множестве всех операций в программе. Факт «событие х
произошло перед событием y» записывается как hb(x,y). Само отношение
определяется следующим образом:
если x и y – операции в одном потоке, и x произошло раньше y, то hb(x,y);
завершение конструктора объекта предшествует запуску его финализатора;
если события x и y синхронизированы, то hb(x,y);
транзитивность: если hb(x,y) и hb(y,z), то hb(x,z).
Отслеживание отношения happens-before позволяет определить, получил ли
некоторый поток информацию о действиях другого потока – например,
изменения в разделяемой памяти, новые значения переменных и т.д.
Наконец, спецификация Java формально определяет понятие гонки: два
обращения x и y к разделяемой переменной из различных потоков, хотя бы одно
из которых – запись, образуют гонку, если ни одно из них не предшествует
другому:
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
275](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-275-320.jpg)
![DR(x,y) !hb(x,y) ˄ !hb(y,x).
Таким образом, для точного обнаружения гонок в программе достаточно
отслеживать конфликтующие обращения различных потоков к разделяемым
переменным, не упорядоченные отношением happens-before. Для этого
традиционно используются векторные часы (vector clock)1, предложенные в
работе [12]. Векторные часы представляют собой динамический массив
неотрицательных чисел, равный по размеру количеству потоков в программе.
Над векторными часами определена операция слияния:
merge(V1, V2): for each i ∈ [1..n] V1[i] := max(V1[i], V2[i])
Каждый поток хранит свои векторные часы, отражающие его знания о
системе: i-я компонента его часов равна последней компоненте i-го потока,
которые он наблюдал2. Компонента, соответствующая ему самому, называется
собственной компонентой. Изначально собственная компонента часов потока
проинициализирована единицей, а остальные – нулями. Перед каждой
операцией синхронизации x в потоке T1, собственная компонента часов потока
T1 увеличивается на единицу, а часы загружаются в часы соответствующего
синхронизационного объекта. Когда в другом потоке T2 происходит событие y,
такое что x синхронизированно с y, в часы потока T 2 загружаются часы
синхронизационного объекта. Это позволяет отследить отношение synchronizedwith.
Для отслеживания отношения happens-before нужно проассоциировать
векторные часы с каждой разделяемой переменной в программе. Когда поток T 1
обращается к такой переменной, он покомпонентно сравнивает свои часы с
часами переменной. Если есть компонента часов потока, которая не
превосходит соответствующей компоненты часов переменной, обнаружена
гонка. Далее поток загружает свои часы в часы переменной.
Если в программе N потоков, то хранение одних векторных часов требует
O(N) памяти, и основные операции над ними также имеют сложность O(N). В
работе [8] показано, что для отслеживания отношения happens-before вместо
полных часов переменной достаточно хранить номер и собственную
компоненту потока, который последним обращался к этой переменной. Таким
образом, значительная часть операций будет требовать O(1) и снизится
количество потребляемой памяти, что позволило алгоритму happens-before
достичь уровня производительности менее точных динамических алгоритмов.
3
Точность поиска и накладные расходы
К сожалению, точечные оптимизации алгоритма, хотя и производят
безусловный положительный эффект (что подтверждает множество
исследований), не могут обеспечить приемлемый уровень накладных расходов
1
2
276
Эквивалентное название – логические часы (logical clocks).
Не умаляя общности, предполагается, что все потоки пронумерованы от 1 до n.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-276-320.jpg)
![на приложениях, состоящих хотя бы из нескольких тысяч классов и
использующих 10-20 потоков.3 Подавляющее большинство исследовательских
работ останавливается на прототипе детектора и модельном тестировании.
Подробный обзор состояния предметной области можно найти в работах [1,2].
Нам удалось обнаружить лишь два готовых к использованию детектора (IBM
MSDK[16] и TSan[18]), но попытки использовать их на крупных приложениях
приводили либо к немедленному отказу, либо к переполнению памяти. О
схожих проблемах сообщают также авторы работы [15].
Для обеспечения точности поиска нужно отслеживать все операции
обращения к разделяемым данным и все операции синхронизации. Первые
можно ограничить путём отсечения областей кода, в которых нас не интересуют
гонки – например, сторонние библиотеки или стандартные Java-классы. Для
большинства разрабатываемых программных систем решения об использовании
сторонних компонент принимаются на стадии проектирования, когда уже
известны требования по надежности и безотказности системы, поэтому есть
смысл считать, что сторонние компоненты обладают достаточной степенью
надежности и концентрироваться на обнаружении ошибок в непосредственно
разрабатываемом программном коде и проверке корректности использования
сторонних компонент.
Однако исключить таким же образом операции синхронизации нельзя,
поскольку их пропуск приведет к неполучению информации о передаче
отношения happens-before и, как следствие, к ложным срабатываниям, –
детектор будет сигнализировать о гонках, которых в действительности не
произошло. Количество этих операций велико и экспоненциально растёт с
увеличением количества потоков в программе, что в совокупности с
необходимостью отслеживать операции обращения к разделяемым данным в
итоге и приводит к описанным эффектам.
4
Синхронизационные контракты
Принцип инкапсуляции в объектно-ориентированном подходе к
программированию, которому следует Java, предполагает, что использование
объекта осуществляется посредством вызова его публичных методов. Поэтому,
в идеале, достаточно иметь возможность описать правила использования
методов исключённых классов в многопоточной среде. Возможны следующие
варианты:
метод не потокобезопасен, то есть его одновременное использование
несколькими потоками не предусмотрено и требует внешней синхронизации;
метод потокобезопасен; он может быть вызван (и в некотором смысле
предназначен для этого) несколькими потоками одновременно без внешней
синхронизации.
3
Обратим внимание, что характеристики многих промышленных программных систем
могут в десятки и тысячи раз превосходить указанные.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
277](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-277-320.jpg)
![Вызовы методов первого типа необходимо отслеживать и обрабатывать по
алгоритму happens-before как обращения к объекту-владельцу метода на чтение,
если метод немодифицирующий, или на запись в противном случае.
Разработанный нами детектор jDRD трактует по умолчанию все обращения как
модифицирующие и предоставляет возможность на уровне конфигурации
указать, что некоторые конкретные методы являются немодифицирующими.
С вызовами методов второго типа немного сложней. Вообще говоря, их
можно игнорировать, поскольку они предназначены для многопоточного
использования. Однако именно в эту группу методов попадают те, которые
обеспечивают синхронизацию между потоками. Как правило, такие методы
содержатся в классах, созданных как средство обеспечения корректного
взаимодействия потоков, что чётко декларировано в их описании. Так, начиная
с версии 1.5 в Java появились высокоуровневые средства синхронизации,
отличные от захватов/блокировок мониторов и volatile-переменных. В основном
они содержатся в пакете java.util.concurrent и его подпакетах.
Например, там есть потокобезопасная хеш-таблица ConcurrentHashMap,
которая гарантирует, что вызов метода put по некоторому ключу предшествует
последующему вызову метода get на том же объекте по тому же ключу [5].
Более формально, это означает, что между событиями вызова метода put в
первом потоке и метода get во втором потоке есть цепочка событий, через
которые передается отношение happens-before. Если детектор отслеживает все
операции синхронизации, то он обнаружит эту цепочку и вычислит, что эти два
вызова методов также упорядочены отношением happens-before.
Теперь предположим, что мы хотим исключить класс ConcurrentHashMap из
области анализа – то есть, не отслеживать в нем операции синхронизации. В
этом случае детектор не получит информации о том, что вызов put
предшествует вызову get. Таким образом, ему её нужно явно сообщить.
Отметим, что для этого не подходят аннотации, поскольку в случае
библиотечных классов нет возможности модифицировать исходный код. Нами
был разработан метод конфигурирования на базе языка xml.
Рассмотрим два метода: метод f(P 11, … P1n) объекта O1 и метод g(P21, …, P2m)
объекта O2, где n,m ≥ 0. Объект O1 будем называть объектом-владельцем метода
f, а O2 – объектом-владельцем метода g. Между этими методами может быть
примитивная явная связь одного из трёх типов:
1. связь «владелец-владелец»: O1 == O2, то есть методы принадлежат одному
объекту;
2. связь «владелец-параметр»: n 0, ∃i ∈ [1..n]: O2 == P1i или m 0,∃j ∈ [1..m]:
O1 == P2j, то есть параметр одного метода является объектом-владельцем
другого метода;
3. связь «параметр-параметр»: n,m 0, ∃i ∈ [1..n], j ∈ [1..m]: P1i == P2j, то есть i-й
параметр метода f и j-й параметр метода g являются одним и тем же
объектом.
Будем называть явной связью комбинацию любого количества примитивных
связей.
278
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-278-320.jpg)
![Обнаружение дефектов работы с указателями
в программах на языках C и C++ с
использованием статического анализа и
логического вывода
Татьяна Верт1 , Татьяна Крикун1 и Михаил Глухих2
1
Санкт-Петербургский государственный политехнический университет, Россия,
werttanya@mail.ru, krikuntatiana@mail.ru,
2
Технический университет Клаусталя, Германия,
mikhail.glukhikh@gmail.com
Аннотация В статье рассматривается один из способов повышения
точности обнаружения дефектов при помощи статического анализа,
а именно дополнение классических алгоритмов анализом зависимостей. Предлагается в процессе абстрактной интерпретации извлекать
информацию как об известных статически значениях переменных,
так и о зависимостях между неизвестными значениями, представляемых предикатами логики первого порядка. Это позволяет при проверке условий наличия дефектов, а также при анализе ветвлений,
использовать готовые средства логического вывода для доказательства истинности или ложности соответствующих условий. Основной
упор сделан на логику анализа указателей и на правила обнаружения
дефектов работы с указателями. Приведены результаты исследования программного прототипа, использующего Microsoft Z3 Solver в
качестве средства вывода. Показано значительное повышение точности анализа, предложены пути снижения ресурсоёмкости данного
метода.
Keywords: обнаружение дефектов работы с указателями, статический анализ, логический вывод
1
Введение
Проблема обеспечения надёжности программного обеспечения является одной из ключевых в современном мире. Известно [6], что даже в хорошо
отлаженных программах содержится до 0.7 ошибок на 1000 строк исходного кода. Одним из наиболее распространённых классов ошибок являются
ошибки работы с указателями.
Основным методом проверки качества программного обеспечения попрежнему является тестирование. Не умаляя достоинств данного метода,
следует отметить, что тестирование не дает гарантий обнаружения всех
286
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-286-320.jpg)
![имеющихся в программе ошибок и поэтому в ряде случаев не может являться единственным методом проверки качества. Подобную гарантию могут предоставить только статические методы, одним из которых является
статический анализ кода [23][20].
Ключевыми характеристиками методов обнаружения ошибок в программном коде являются полнота, точность и ресурсоёмкость. Полнота анализа
вычисляется как доля обнаруженных истинных ошибок среди всех имеющихся ошибок в программе, а точность —как доля обнаруженных истинных ошибок среди всех обнаруженных. Как правило, три данные характеристики находятся в противоречии друг с другом, и в средствах обнаружения ошибок приходится выбирать разумный компромисс. В частности,
промышленные средства статического анализа [11] обычно ориентированы
на высокую точность и низкую ресурсоёмкость, но не гарантируют полноту. Исследовательские средства анализа часто стремятся к обнаружению
всех имеющихся ошибок определенного класса, что приводит к понижению
точности и росту ресурсоёмкости; во многих случаях подобные характеристики препятствуют широкому распространению средств статического анализа [20].
Распространённым алгоритмом статического анализа является абстрактная интерпретация [13]. Данный алгоритм подобен обычной интерпретации.
Однако, абстрактная интерпретация осуществляет анализ всех путей программы, обеспечивая таким образом полноту анализа. При этом для хранения возможных значений переменных используются так называемые абстрактные семантические домены — в частности, множество целочисленных
интервалов, множество указателей и т.д. Абстрактная интерпретация допускает как раздельный анализ путей программы, имеющий высокую точность
и очень высокую ресурсоёмкость, так и совместный анализ путей, имеющий приемлемую ресурсоёмкость, но низкую точность за счёт объединения
возможных значений переменных при слиянии путей.
Одним из способов повышения точности при совместном анализе путей
является дополнение классических алгоритмов анализом зависимостей [19].
Зависимостью здесь называется произвольная связь между значениями
двух и более переменных программы; математически, зависимость может
быть представлена в виде предиката [22]. Анализ зависимостей позволяет
полностью или частично компенсировать погрешность, вызванную слиянием путей в ходе статического анализа. Для реализации анализа зависимостей могут быть использованы готовые методы и средства логического вывода, такие, как аппарат дизъюнктов Хорна и средства логического программирования [18], логика первого и высших порядков [22], SMT-решатели [3].
Подобная возможность позволяет, в числе прочего, упростить другие используемые алгоритмы, в частности, использовать анализ точных значений
вместо интервального анализа. В [15] Патрик Кузо рассматривает одну из
возможных математических моделей объединения абстрактной интерпретации и логического вывода. Насколько известно авторам статьи, на данный
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
287](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-287-320.jpg)
![момент эта модель не реализована в рамках существующих средств статического анализа.
Ключевой идеей данной работы является использование сочетания методов статического анализа и логического вывода для обнаружения ошибок
в исходном коде. В качестве основной группы ошибок была выбрана некорректная работа с указателями, однако предлагаемый подход может быть
расширен и на другие группы ошибок. В разделе 2 приведён обзор существующих работ по рассматриваемой тематике. В разделе 3 рассматривается
предлагаемый подход. Раздел 4 посвящен практической реализации подхода и проведённым экспериментальным исследованиям. Раздел 5 подводит
итоги и намечает направления дальнейшего развития подхода.
2
Обзор существующих работ
В настоящее время, известно ряд как коммерческих, так и исследовательских средств статического анализа [9]. Ведущим коммерческим средством
обнаружения дефектов методом статического анализа де-факто является
платформа Coverity SAVE [8]. Концептуально данное средство ориентировано на анализ программ произвольного размера и обеспечение высокой
точности — от 80% до 90% по данным авторов. Средство не гарантирует
полноты анализа, но тем не менее обнаруживает довольно большое количество серьёзных ошибок — порядка 7 ошибок на 10000 строк кода — в реальных программных проектах [11,6]. Подход средства Coverity SAVE основан
на извлечении из исходного кода правил использования различных его объектов [17], при этом извлекаются как точные правила вида «указатель P не
NULL», так и статистические правила вида «mutex M, возможно, защищает
переменную V». В дальнейшем эти правила проверяются на непротиворечивость с целью обнаружения ошибок в программе.
Исследовательское средство Astree [7] разработано под руководством Патрика Кузо. Средство ориентировано на поиск ошибок времени исполнения в
программах на языке C и было использовано для анализа ряда промышленных программных проектов среднего размера (порядка 100000 строк кода).
Согласно [14], средство использует как общеизвестные абстрактные семантические домены (целочисленные интервалы, множества указателей), так
и ряд доменов, позволяющих отследить зависимости между переменными
(в частности, домен октагонов, домен линейных выражений). После разбора исходного кода Astree вначале выполняет ряд простых видов анализа,
позволяющих упростить основную задачу (в частности, выявление мёртвых
ветвей и переменных), после чего выполняет основной анализ сверху вниз,
начиная с точки входа в программу и кончая наиболее простыми функциями.
Исследовательское средство Saturn [4] построено на анализе программ
снизу вверх [10]. Информация, полученная при анализе конкретных функций, используется в точках их вызова и анализ функций не повторяется.
Тот же принцип может быть использован при анализе циклов. При ана-
288
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-288-320.jpg)
![лизе отдельных операторов используется вывод ограничений в различных
точках исполнения программы с последующим запуском SAT-решателя для
определения логической разрешимости. Для описания правил анализа используется язык логического программирования Calypso. Средство может
быть использовано для анализа больших программных систем, однако, как
следует из [16], имеет довольно низкую точность.
Средство PREfix также анализирует программы снизу вверх [21]. Используются традиционные алгоритмы анализа потока данных, сопоставления с образцом и некоторые другие. В частности, используется идея хранения состояния программы в виде множества точных значений, дополненных
множеством предикатов [12].
Продукты PC-Lint (для MS Windows) и FlexeLint (для Unix, Linux, Mac
OS X, Solaris) компании Gimpel Software [5] предназначены для обнаружения
дефектов в программах на языках C/C++. Система производит синтаксический анализ исходного кода, анализ потока данных и управления, осуществляет межпроцедурный анализ. Используются специальные средства
проверки, в том числе: анализ значений, дополнительная строгая проверка типов, определяемая пользователем семантическая проверка аргументов
функции и возвращаемых значений.
Исследовательское средство Aegis [1] анализирует программы сверху вниз.
Средство использует анализ указателей, интервальный анализ, ресурсный
анализ; для повышения точности используется также простой анализ зависимостей [19].
3
Описание разработанного подхода
Предлагаемый подход ориентирован на использование средств верификации
и логического вывода для доказательства различных утверждений в ходе
статического анализа, в частности, утверждений о наличии либо отсутствии
дефектов в отдельных операторах программы.
3.1
Архитектура
Первым этапом выполнения статического анализа является построение модели по исходному коду программы. Наиболее удобной моделью для выполнения статического анализа является граф потока управления (ГПУ), в
нем присутствуют только узлы, соответствующие исполнимым операторам
программы.
На следующем этапе происходит применение собственно алгоритмов статического анализа с целью определить состояния программы во всех точках
её исполнения. Алгоритмы, используя известную информацию о семантике
языка, вычисляют возможные значения всех переменных программы.
На последнем этапе (выполняемым параллельно с предыдущим) рассчитанные состояния используются алгоритмами обнаружения дефектов для
выявления и локализации имеющихся в программе ошибок.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
289](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-289-320.jpg)
![Для того, чтобы использовать средства логического вывода в ходе абстрактной интерпретации, необходимо предоставить им входные данные в
подходящей для них форме. Один из вариантов подобного представления —
хранение состояния программы в виде множества предикатов, с последующим использованием данного множества для формирования выводов.
Общая схема анализатора, отражающая структуру предлагаемого подхода, представлена на рис.1.
Рис. 1. Структура предлагаемого подхода
Данный способ предполагает, что для некоторых переменных хранятся их точные на данный момент значения. Если значение данной переменной вычислить статически невозможно, для неё могут храниться различные
условия, связывающие её значение со значениями других переменных. Таким образом, происходит дополнение точных значений зависимостями между переменными.
Средство логического вывода отвечает за взаимодействие с внешним доказателем. Предполагается решение двух задач — доказательства истинности определенных предикатов и упрощения множества предикатов для
сокращения его объёма.
Анализатор, оперируя состоянием программы и результатами вывода,
осуществляет поиск дефектов в конкретных операторах.
3.2
Извлечение предикатов
В ходе анализа отдельных операторов программы происходит извлечение
информации о значениях переменных и связях между ними, представляемых в виде логических утверждений — предикатов [22][18]. В наиболее
простом случае интерпретация одного оператора приводит к формированию одного предиката, в точности описывающего семантическое преобразо-
290
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-290-320.jpg)
![После проверки условия в состояние истинной ветви добавляется предикат,
соответствующий истинности условия cond, а в состояние ложной ветви —
предикат, соответствующий ложности условия cond. В частности, если cond
является переменной, используются предикаты nonzero(cond) и zero(cond)
соответственно.
Для снижения количества анализируемых путей применяется объединение состояний программы в точках слияния путей (так называемых фифункциях) с последующим совместным анализом объединённых путей. В
отличие от других операторов оператор фи-функции имеет два и более входных операторов и соответственно два или более предикатных состояния на
входе. Основные правила слияния состояний:
• если одна и та же предикатная переменная vi имеет разные значения
во входных состояниях, то её возможные значения xj объединяются по
ИЛИ путём добавления предиката oneof (equals(vi , x1 ), equals(vi , x2 ));
• если некоторой переменной программы v соответствуют разные предикатные переменные v1 и v2 во входных состояниях, то для неё создается
новая предикатная переменная v3 , при этом в выходное состояние добавляется предикат oneof (equals(v3 , v1 ), equals(v3 , v2 ));
• все предикаты, входящие во входные состояния, необходимо добавить в
выходное состояние.
Для описания логики работы с составными переменными языка C (структурами, массивами) и с указателями на них, используется дополнительный
набор предикатов:
• элемент сложного объекта arr(a, v, s) — массив (структура) a содержит
значение v по смещению s байт — a[s]=v в случае байтового массива;
• размер сложного объекта sizeof (a, s) — массив (структура) a имеет размер s байт, или sizeof(a)=s;
• указатель на объект ptr(a, p, s) — указатель p указывает на массив (структуру, переменную) a со смещением s байт, или p=(void*)(a)+s;
• разадресация указателя deref (p, v) — значение переменной v равно значению по адресу p, или v=*p;
• корректность указателя correct_ptr(p), incorrect_ptr(p) — указатель p
имеет корректное (указывающее на реально существующую переменную) или некорректное (равное нулю, указывающее на несуществующую
переменную) значение.
При слиянии ветвей в некоторых ситуациях важной является связь между значением указателей и выражением из условия. В общем случае, если
некоторая переменная имеет разные значения в разных ветвях условного
оператора, предикат, описывающий её значение, следует связать с условием
оператора if для повышения точности. Рассмотрим пример:
1
2
3
4
292
if(size 0)
q = malloc(size);
else
q = 0;
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-292-320.jpg)
![• правило сложения указателя с целочисленной константой:
ptr(a, p, s), sum(t, s, b), sum(q, p, b)
ptr(a, q, t)
(4)
если указатель p указывает на a со смещением s, t равно сумме s и b, а
указатель q равен сумме p и b, то q указывает на a со смещением t.
Эти правила применяются для обнаружения программных дефектов,
связанных с использованием указателей.
3.4
Правила обнаружения дефектов
В данной работе особое внимание уделено следующим типам дефектов:
• некорректное использование указателей;
• переполнение буферов и выходы за границы массивов.
Некорректное использование указателей — группа дефектов, связанная с
разадресацией некорректного или нулевого указателя. Некорректный указатель — это указатель, в результате разадресации которого возникает ошибка. Примером некорректного указателя может служить указатель на освобождённую память. Процедура обнаружения дефектов при интерпретации
операторов косвенной записи или косвенного чтения зависит от значения
указателя. Если разадресуемый указатель имеет точное значение: нулевой
указатель или некорректное значение, то дефект считается обнаруженным.
Если указатель не имеет точного значения, то присутствие дефекта в операторе подтверждается путём доказательства разрешимости определённых
предикатов относительно множества уже существующих предикатов. Такими предикатами являются:
• нулевой указатель: equals(ptr, 0);
• некорректный указатель: oppos(correct_ptr(ptr)).
Чтобы показать отсутствие дефекта, необходимо доказать неразрешимость
противоположных предикатов:
• ненулевой указатель: not_equals(ptr, 0);
• корректный указатель: correct_ptr(ptr).
Обнаружение выхода за границу объекта производится при выполнении операции разадресации *ptr и операции обращения по индексу ptr[i]. Для
каждого значения указателя (obj, shift) следует проверить, что смещение shif t ≥ 0 и shif t sizeof (obj). Если это условие доказуемо, то дефект
отсутствует, в противном случае дефект считается обнаруженным.
294
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-294-320.jpg)
![4
Экспериментальные исследования
Для проведения экспериментальных исследований описанного подхода было разработано средство-прототип. Для получения графа потока управления из исходного кода программы был использован плагин к компилятору
gcc, в качестве ядра прототипа была использована библиотека статического
анализатора Aegis [1]. В качестве средства логического вывода был выбран
SMT-решатель Z3 [3]. Z3 —это свободно распространяемый SMT решатель
с открытым исходным кодом, разрабатываемый в Microsoft Research и имеющий API доступа для множества языков программирования. В настоящее
время Z3 считается самым мощным средством работы с SMT-предикатами
по данным соревнования SMT-COMP [2].
Исследование проводилось на различных тестовых программах (всего
порядка 30 программ, объем каждой программы 30-50 строк), содержащих
и не содержащих дефекты. Данные программы также были протестированы
с помощью средства FlexeLint компании Gimpel Software и базовым анализатором Aegis, не использующим механизм зависимостей. Сводные результаты
анализа приведены в таблице 1.
Таблица 1. Результаты анализа
Средство анализа
Прототип
FlexeLint
Aegis
Точность
95%
60%
68%
Полнота
95%
45%
75%
Среднее время анализа
53 сек
4 сек
5 сек
Приведенные результаты наглядно демонстрируют значительный выигрыш в точности анализа в результате ввода правил анализа зависимостей.
Недостатком разработанного прототипа являются временные затраты на
анализ, которые в зависимости от сложности программы составляли от одной секунды до десяти минут.
Наиболее ресурсоемким является анализ циклических участков программ
из-за большого количества создаваемых предикатов на каждой итерации
цикла. Для снижения ресурсоемкости анализа можно предложить несколько решений. Одним из таких решений является применение алгоритмов
сборки мусора. Этот подход подразумевает удаление из состояния программы предикатов, значения которых не используются при проведении дальнейшего анализа. Другим возможным решением является применение алгоритмов упрощения состояния программы на основе правил трансформации
предикатов. Применение данного подхода позволит снизить количество вызовов внешнего решателя.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
295](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-295-320.jpg)
![граммного обеспечения. Однако, эффективность проведения тестирования определяется не только количеством разработанных тестов, но и их качеством. Зачастую
качество тестов зависит только от профессиональных навыков тестировщика, в то
время как требуется, чтобы качество создаваемых тестов больше зависело от разработанного программного обеспечения и спецификации требований. Поэтому в последнее время активно развивается направление программной инженерии, связанное с автоматизацией синтеза тестов на основе различных проектных артефактов. В
качестве таких артефактов в разных исследованиях используются спецификации
требований, аннотации, контракты, исходный код программного обеспечения и т.п.
При формировании тестов перед разработчиками встают следующие основные
задачи:
обеспечение максимального покрытия тестами программы, при этом обычно
рассматривается один следующих критериев покрытия: покрытие операторов,
покрытие ветвлений или покрытие путей;
формирование тестов, покрывающих максимально возможный диапазон входных
значений функций и методов;
проверка максимально возможного числа требований, предъявляемых к программе.
В данной статье описывается разработанный авторами подход, целями которого
было решение перечисленных выше задач. Подход основан на интеграции двух
методов тестирования: структурного, базирующегося на анализе исходного кода
программы, и функционального, использующего спецификации. Разработаны методы автоматизации создания тестов, учитывающие как внутреннее устройство программы, так и функциональные требования к ней. Для построения модели программы и извлечения трасс выполнения используются методы статического анализа. В
качестве спецификаций требований используются контракты, позволяющие описывать требования, предъявляемые к отдельным методам и классам. Совместный анализ извлеченных трасс и контрактов позволяет синтезировать комплекты тестов,
обеспечивающих покрытие путей программы. Подход реализован в виде инструментального средства генерации тестов на основе анализа Java-программ и системы
контрактов CoFoJa[1].
1.2
Результаты
В данной работе получены следующие теоретические и практические результаты:
разработаны принципы генерации тестов, форсирующих прохождения выбранной трассы программы;
разработаны методы комплексирования синтеза функционального и структурного тестирования, основанные на объединении анализа кода и контрактов;
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
2
299](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-299-320.jpg)
![ предложены методы формирования множественных тестов для обеспечения покрытия всей области определения;
разработано инструментальное средство генерации тестов для Java-программ.
1.3
Структура статьи
Оставшаяся часть работы организована следующим образом. Второй раздел содержит описание разработанного авторами подхода к генерации тестов. Подробно рассматривается построение модели программы, извлечение трасс исполнения и формирование системы утверждений для SMT-солверов, а также генерация множественных тестов. Третий раздел посвящен описанию созданного прототипа генератора тестов. В четвертом разделе приводится информация об апробации подхода.
Пятый раздел содержит обзор текущего состояния дел в области автоматизированного синтеза тестов на основе анализа программы и учета контрактов. В заключении подводится итог проведенной работы, формулируются направления дальнейших исследований.
2
Предлагаемый подход
В данной работе предлагается подход к автоматизации создания модульных тестов,
обеспечивающий покрытие путей программы. Далее в этой работе не умаляя общности мы будем рассматривать создание тестов для одного метода какого-либо
класса. Для обеспечения покрытия путей метода необходимо для каждой возможной трассы исполнения программы сгенерировать такой набор значений аргументов
метода, который форсирует прохождение программой этой трассы. То есть необходимо так подобрать значения аргументов, чтобы при каждом возможном ветвлении
выбиралась требуемая ветвь программы. Построение для заданных значений аргументов соответствующих трасс исполнения является прямой задачей. Вычисление
же требуемых значений аргументов метода для удовлетворения заданной трассы это обратная задача. В общем случае обратная задача - сложная научная NP-полная
проблема, требующая решения сложных систем уравнений. В данной статье описывается способ решения этой задачи с определенными ограничениями, позволяющий
вычислить требуемые значения аргументов за приемлемое время. Если ограничиться формированием модульных тестов только на основе критерия покрытия, то полученные тесты никак не будут учитывать требования, предъявляемые ко всей программе вообще или к конкретному методу в частности. Чтобы использовать информацию о требованиях, описанный способ формирования тестов на основе анализа
программы может быть расширен с помощью учета спецификаций. Спецификация
(или частичная спецификация) может быть задана с помощью контрактов [2]. Анализ предусловий метода и инвариантов класса может сузить множество возможных
300
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
3](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-300-320.jpg)
![Очевидно, что такая система утверждений неразрешима, так как с одной стороны
x=10 (строка 1), а с другой стороны x=30 (строка 4). Такая коллизия обусловлена
кардинальными семантическими отличиями переменных императивных языков
программирования от переменных, используемых в логиках. Для разрешения этой
коллизии используется известный подход, применяемый при построении модели
SSA, основанный на введении дополнительных алгебраических переменных, отражающих состояния переменных языка программирования после выполнения присваивания. Такие переменные называются версиями исходной переменной, а сама
операция - введением версионирования. Таким образом, после введения версионирования каждой верисонированной переменной в системе уравнений значение будет присвоено только один раз. Для приведенного примера система уравнений будет следующей:
1:
2:
3:
4:
x1=10
y1=20
z15
x2=x1+y1
Полученная таким образом система становится алгебраически разрешимой. Она
относится к классу Satisfiability Modulo Theories (SMT) [3]. Как следствие, она может быть разрешена с помощью какого-либо SMT-солвера. Для этого необходимо:
преобразовать систему утверждений в формат, являющийся входным для SMTсолвера;
запустить SMT-солвер для решения системы уравнений;
проинтерпретировать результаты работы солвера.
В случае успеха из результатов извлекаются значения аргументов метода, форсирующие выполнение указанного пути. Если солвер не смог разрешить систему
уравнений, то это свидетельствует либо о наличии в программе “мертвого” кода,
либо о некорректности допущений, сделанных при построении модели программы,
либо о недостаточной мощности математического аппарата логики первого порядка, либо о недостаточной мощности самого солвера. Во всех случаях будет принято
решение о невозможности создания теста для покрытия данного пути.
2.4
Расширение системы утверждений с помощью контрактов
Построенные тесты обеспечивают прохождение программой соответствующих
трасс исполнения, при этом значения аргументов методов расположены в области
допустимых значений произвольно, в соответствии с правилами вывода решений
выбранного SMT-солвера [3]. То есть сгененрированные значения аргументов могут
нарушать контракты методов, определяющиеся с помощью предусловий, постусло-
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
6
303](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-303-320.jpg)
![вий и инвариантов [2]. Конкретно в данном случае могут нарушаться предусловия
методов или инварианты классов. Решение этой проблемы заключается в расширении построенной системы утверждений с помощью инвариантов классов и предусловий методов. Так как контракты уже задаются в форме утверждений логики
первого порядка, то преобразование их в утверждения для SMT-солвера не представляет никакого труда.
В результате после решения расширенной системы утверждений будут находиться аргументы метода, удовлетворяющие контракту анализируемого метода.
2.5
Генерация тестовых оракулов
Для генерации полноценной системы тестов кроме значений аргументов методов
необходимо также формировать тестовые оракулы, проверяющие корректность
выполнения тестов. Постусловия, используемые в контрактном программировании,
являются частью спецификаций методов и задают свойства, гарантируемые методом после его завершения в случае выполнения предусловий. В данной работе мы
предлагаем генерировать основу тестовых оракулов на базе постусловий методов и
инвариантов классов, как это сделано в работе [4].
Заданные в форме логических утверждений постусловия и инварианты транслируются в эквивалентные конструкции на целевом языке программирования и интегрируются в созданные тесты. При этом у тестировщика остается возможность
расширить сгенерированные автоматически оракулы дополнительными проверками.
2.6
Формирование множественных тестов
Представленная технология формирования тестов обеспечивает генерацию по одному набору тестов для каждого класса эквивалентности. Этого достаточно для
того, чтобы по одному разу протестировать все пути в графе потока управления.
Однако на практике часто имеет смысл иметь несколько тестов для каждого класса
эквивалентности, так как необходимо проверить не только сам факт прохождения
программы по заданной трассе, но и другие свойства. Например, часто требуется
проверять корректность работы программы на граничных значениях интервалов,
правильность отработки начала и конца цикла и т.п.
Для этого необходимо для каждого класса эквивалентности генерировать множество тестов, обеспечивающих определенное покрытие области допустимых значений аргументов в соответствии с выбранной эвристикой.
В данной работе реализован метод формирования множественных тестов, основанный на последовательной генерации новых тестов для классов эквивалентности
за счет вычисления области допустимых значений для аргументов метода. Исходя
из количества тестов, которые должны быть сгененированы для каждого класса
304
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
7](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-304-320.jpg)
![эквивалентности (задано пользователем), строится равномерное покрытие nмерного пространства аргументов функции, на основе ограничений области допустимых значений, заданных в контрактах. Для каждого набора параметров генерируется свой модульный тест в результирующем тестовом наборе. Алгоритм формирования равномерного покрытия пространства аргументов с ограничениями имеет
итеративный характер, а его подробное описание выходит за рамки настоящей статьи.
В дальнейшем авторы предполагают использовать более сложные эвристики для
формирования тестовых наборов, более чувствительных к стандартным ошибкам,
встречающихся в программах.
3
Описание созданного прототипа
Разработанный подход был реализован в виде инструментального средства генерации тестов для языка Java. В качестве системы задания контрактов используется
CoFoJa[1]. В качестве SMT-солвера применяется солвер Z3 [3], разработанный Microsoft Research, тесты генерируются в формате JUnit. Общая архитектура системы
вместе с артефактами изображена на рис.1. Блоками белого цвета изображены модули, разработанные авторами, серым цветом отмечены сторонние компоненты.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
8
305](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-305-320.jpg)
![зации разработки, систем для синтеза тестов. Многие из них используют в качестве
основы подход синтетического структурного тестирования. В этом случае после
первого случайно выбранного теста остальные тесты генерируются автоматически
так, чтобы обеспечить покрытие еще не покрытых ранее элементов кода. Для выбора подходящих тестовых данных используются решатели, учитывающие символическую информацию об ограничениях на данные, отделяющие прошедшие тесты от
еще не покрытого кода, а для построения нужных последовательностей воздействий
— случайная генерация, направляемая как этой же символической информацией,
так и некоторыми эвристическими абстракциями, уменьшающими пространство
состояний проверяемой системы. В рамках этого подхода интегрируются статический анализ кода, символическое исполнение, структурное тестирование и дедуктивный анализ, выполняемый решателями. Одними из представителей этого класса
являются Microsoft Pex and Moles, два исследовательских проекта, направленных на
повышение производительности тестировщиков и качества кода.
Microsoft Pex [5,6] – набор инструментов, выполняющих анализ тестируемого кода
и подбирающий параметры, которые позволяют покрыть максимально возможный
объем кода. Microsoft Pex работает в петле обратной связи: код выполняется несколько раз, и производится анализ поведения программы на уровне промежуточного языка .NET CIL (Common Intermediate Language) с помощью мониторинга потока управления и потока данных. После каждого запуска Pex выбирает ветвь, которая не была покрыта ранее, создает систему ограничений, которая описывает, как
достичь этой ветви, использует решатель Z3 для определения новых значений входных данных, которые удовлетворяют ограничениям, если таковые существуют. Код
выполняется снова с новым набором входных значений, и процесс повторяется. В
результате работы создается отчет, который можно проанализировать вручную, и
набор unit-тестов для дальнейшего использования. Microsoft Moles [6,7] – фреймворк, также разработанный в лаборатории Microsoft Research и позволяющий разработчикам создавать тестовые заглушки и избегать непосредственного вызовов методов в .NET. Moles расширяет Pex за счет формирования тестового окружения и
гибкого манипулирования драйверами и заглушками. Существует ряд ограничений
при использовании указанных инструментов. Во-первых, невозможно обнаруживать ошибки, которые вносятся при параллельном выполнении задач, во-вторых,
указанные средства не могут справиться с недетерминизмом. Это приводит к разным результатам при каждом запуске Pex. В-третьих, Pex и Moles не могут быть
использованы для анализа кода, который не работает под управлением .NET. Множество поддерживаемых языков ограничено только языком C#. Возможность использования внешнего солвера, отличного от Z3, также не предусмотрена.
Еще один подход к автоматизации модульного тестирования был предложен C.
Engel и R Hähnle. В работе [8] рассматривается метод автоматической генерации
тестов для JAVA CARD, базирующийся на формальной проверке выполнения тестируемого кода. В его основе лежат два подхода к тестированию: по методу “бело-
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
10
307](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-307-320.jpg)
![го” и “черного” ящика. Автономные модульные тесты в формате JUnit генерируются автоматически. VBT (verification-based test generation) использует полную информацию, содержащуюся в формальной спецификации и лежащую в основе реализацию тестируемого кода (implementation under test, IUT). В качестве языка описания спецификации используется Java Modeling Language (JML). При этом полная
функциональная спецификация тестируемого кода не требуется, поскольку генерация тестов реализуется на основе символического исполнения, а заданные в пред- и
постусловиях ограничения требуются только для синтеза тестовых оракулов.
Система Kiasan [9,13] представляет собой механизм символического исполнения
для последовательных Java программ, основанный на фреймворке Bogor, использующем технологию проверки модели (model checking). Предложенный подход был
позднее расширен в фреймворке KUnit [9], который автоматически генерирует тесты для контрактно-аннотированых методов и отображает множество объектов
(heap objects), получаемых и возвращаемых методами, что может быть использовано разработчиками для анализа сложных методов и диагностики причин ошибок в
программе. Фреймворк KUnit использует тестирование по методу “черного ящика”
с помощью генерации входных значений на основе символического исполнения,
постусловия используются в качестве тестовых оракулов. При наличии формальной
спецификации подход, используемый в KUnit, может реализовывать такие техники
тестирования, как: разделение на классы эквивалентности, анализ граничных значений. В общем случае традиционное тестирование обычно не основывается на формальной спецификации, в то время, как KUnit требует формального описания требований.
Инструмент Unit Meister [10], разработанный компанией Microsoft, использует символическое исполнение для анализа трасс программы. Подход во многом схож с
Kiasan, однако существует ряд отличий. Unit Meister включает функциональные
символы для композиционной проверки, в то время, как Kisan допускает только
исходные символы, а композиционная проверка осуществляется с помощью спецификаций. В то время как Kiasan является полностью автоматическим, Unit Meister,
зависимый от решателя системы ограничений, требует от пользователя указания
области определения параметров.
Symstra [11,12] – еще одно средство символического исполнения для создания минимальной последовательности вызовов публичных методов для проверки класса.
Symstra использует примитивные символические значения, конкретные структуры
множеств и предполагаемые состояния для генерации неизоморфных конечных
состояний. Для генерации подмножества возможных предварительных состояний в
Symstra применяются последовательности вызовов публичных методов. В разработанном прототипе предварительные состояния задаются предусловиями и инвариантами. Пользователь может изменять предусловия и инварианты, более точно
определяя их значения.
308
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
11](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-308-320.jpg)
![Одним из инструментов, ориентированных на использование контрактных спецификаций в процессе создания тестов, является AutoTest framework [4]. Он автоматизирует процесс тестирования программного обеспечения, опираясь на программы,
содержащие инструменты их собственной проверки, в форме контрактов для классов и отдельных методов. Предусловия и инварианты позволяют ограничить множество входных данных для тестирования, постусловия преобразуются в тестовые
оракулы. Основная особенность AutoTest заключается в способе генерации тестов.
Тестовые последовательность формируются случайно, опираясь только на предсуловия методов и инварианты классов. Успешность прохождения тестов анализируется в тестовых оракулах. Отдельно стоит отметить механизм Test Extraction, который автоматически создает тесты по результатам отказов программы. Основными
ограничениями подхода являются отсутствие гарантий покрытия путей (из-за сугубо случайной генерации тестов), а также поддержка только языка Eiffel и среды
EiffelStudio.
Все рассмотренные подходы подтверждают эффективность интеграции различных
методологий процесса тестирования на практике. Тем не менее, несмотря на достигнутые успехи, каждый из имеющихся подходов использует лишь часть имеющегося потенциала, ограничен анализом программ, написанных на каком-то определенном языке программирования, и не предоставляет единой интеграционной
платформы для всего многообразия различных техник верификации ПО. Кроме
того, большинство из рассмотренных подходов являются академическими и неприменимы для анализа сложных программных систем. [14,15].
6
Заключение
В результате проведенного исследования разработан подход к синтезу тестов для
языка Java, обеспечивающих покрытие трасс исполнения методов. Разработанные
методы с помощью применения SMT-солвера генерируют параметры модульных
тестов, форсирующие реализацию заданных трасс исполнения. Учет контрактов
методов позволяет с одной стороны с помощью постусловий частично автоматизировать синтез тестовых оракулов, а с другой с помощью предусловий ограничивать
генерацию параметров тестов. Применение разработанного на основе подхода прототипа на наборе тестовых примеров показало полную работоспособность предложенных методов. Основными направлениями развития теоретических и
практических исследований являются:
разработка новых алгоритмов генерации множественных тестов, более эффективно распределяющих значения переменных по области определения;
совершенствование анализатора (прототипа) с целью обеспечения анализа более
широкого класса Java-программ;
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
12
309](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-309-320.jpg)
![ДИАГРАММЫ КЛАССОВ ООП:
ФОРМАЛИЗАЦИЯ И АНАЛИЗ
Дмитрий Буй1 , Сергей Компан2
Киевский национальный университет имени Тараса Шевченка, Украина
1
buy@unicyb.kiev.ua, 2 robin_2005@mail.ru
Аннотация В статье приводится короткий сравнительный анализ работ, посвящённых формальным моделям объектно-ориентированного программирования (ООП). Предмет исследования – модель диаграммы классов (соответствующее частично упорядоченное множество). Модель класса (спецификация класса) —- пара бинарных функциональных отношений, одна компонента уточняет атрибуты, вторая — методы. Наследование уточняется как включение графиков функций. Над классами вводятся две операции –– пересечение и сочленение. Формальные результаты: структура частично упорядоченного множества классов, свойства
операции наложения, в терминах которой вводится операция сочленения: идемпотентность, ассоциативность, критерий коммутативности.
Модель диаграммы классов можно использовать для анализа структуры классов, который может помочь для выделения подсистем клонов и
оптимизации самой диаграммы.
Ключевые слова: формальные модели ООП, диаграммы классов, спецификация класса, операции над классами, клон
1. Вступление
Основы объектно-ориентированного подхода (ООП) были заложены в конце 60-х годов. В основе ООП лежит объектная модель данных (ОМД). Появление ОМД связано с появлением абстрактных типов данных. В 1971 году
Парнас (D. L. Parnas) в работе [1] предложил идею инкапсуляции (сокрытия
информации). В 80-х годах ХХ столетия Г. Буч (G. Booch) в своей книге [2]
предложил использовать идеи ООП для разработки программных продуктов промышленного уровня. Благодаря ООП появилась потенциальная возможность выхода из кризиса, связанного с проектированием и реализацией
сложных программных систем (ПС). Таким образом, ООП стало очередной
ступенью к созданию методов разработки надежных ПС. В результате ускорился процесс создания программных комплексов, в основе которого лежат
принципы ООП, а так же качественно снизился уровень сложности разработки ПС.
Согласно ООП предметная область (ПрО) представляется как множество
объектов со свойствами, которые необходимы для определения и идентификации объектов, а также описаниями их поведения в рамках выбранной системы понятий на зафиксированном уровне абстракции. Предметная область,
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
311](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-311-320.jpg)
![которая моделируется объектами, сама является объектом и поэтому может
быть отдельным объектом в составе другой ПрО. При моделировании объект
ПрО получает хотя бы одно свойство, необходимое для его идентификации
в множестве объектов ПрО [3]. В основе ООП лежат: абстракция, инкапсуляция, наследование, полиморфизм. Язык программирования, в котором реализованы эти понятия, является объектно-ориентированным и именно они
придают языку гибкость при программной реализации сущностей ПрО.
2. Краткий анализ современного состояния ООП
Сразу необходимо заметить, что в связи с популярностью ООП как средства проектирования и разработки ПС существует достаточное количество
соответствующей литературы [2–11]. Следует отметить ряд работ заведующей отделом Института программных систем НАН Украины, профессора
Лаврищевой Е.М. [3,10,12], в которых уделяется большое внимание проектированию и программированию систем, в основе которых лежит ООП. Автор
предлагает выделять четыре уровня абстрактного представления объектной
модели (ОМ): обобщающий, структурно-упорядоченный, характеристический
и поведенческий. На каждом из этих уровней применяется свой математический аппарат [10].
Отметим, что существует группа OMG (Object Management Group), в
основе деятельности которой лежит пропагандирование и стандартизация
ООП. Эта группа описала набор стандартов OMA (Object Management Architecture). Самым известным и широко применяемым на сегодняшний день
является CORBA (Common Object Request Broker Architecture) —- спецификация взаимодействия разнотипных объектов в распределенной системе [13].
В данной модели для описания понятий применяется декларативный язык
определения интерфейсов IDL (Interface Definition Language).
Для полной уверенности в том, что информационная система, построенная
на основе ООП, будет удовлетворять исходным спецификациям и стабильно
работать (будет гарантоустойчивой по терминологии [14]), необходимо выделить компоненты системы, формально их описать и верифицировать. В результате возникла необходимость формального определения понятий объекта, класса, операций над объектами и т.д. Для ООП построены формальные
модели. Например, в работе [15] формально даётся определение основных
понятий ООП: класса, объекта, наследования, инкапсуляции, полиморфизма
с использованием математического аппарата теории множеств, функций, абстрактных автоматов (в этой же работе приводится обширная библиография
по ООП). В работе [16] авторы строят формальную модель для объектных
баз данных (БД), в основе которой лежит теория категорий. В [17, 18] даны
формальное определение основных понятий ООП, в основе определения которых лежит композиционное программирование, созданное академиком НАН
Украины В. Н. Редько [19–21].
Особое внимание следует уделить вопросу построения объектной модели
для объектных БД, так как в основе более-менее сложной информационной
312
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-312-320.jpg)
![системы лежит именно БД. Широкое распространение ООП резко обозначило проблему семантического разрыва между моделью языка программирования и моделью представления данных в БД. Объектная модель позволяет
оперировать сложными структурами данных. В результате системы управления базами данных (СУБД) стали развиваться в трех направлениях. Первое — это построение отображения объектов в традиционную реляционную
модель данных. Второе — включение понятий ООП в реляционные СУБД путем расширения типов данных, используемых в БД. Третье направление -—
создание принципиально новых, объектно-ориентированных СУБД, которые
в своей работе следуют стандарту ODMG [22].
В [23] авторы формально строят модель данных, в которую входят: конечное множество основных типов D, счетное множество объектных идентификаторов O, множество имен атрибутов A, множество имен методов M ,
множество имен классов C. Так как объект может содержать в себе данные,
то различают примитивные значения (atomic values) и сложные значения
(structured values). После этого авторы приводят синтаксическое описание
класса (неформальное). Даётся формальное определение метода, который является функцией, отображающей сигнатуру в тело функции. Сигнатура формально описывается следующим образом — c : m(τ1 , τ2 , . . . , τn ) → τr , где c -–
имя класса, которому принадлежит метод, m —- имя метода, τ1 , τ2 , . . . , τn —
список типов параметров и τr — тип возвращаемого значения. Также в статье
упоминается простое наследование, которое формально не определено. Приводится формальное определение объекта, который задаётся тройкой (o, ν, c),
где o ∈ O —- идентификатор объекта,v — значение объекта, c ∈ C — класс,
которому принадлежит объект. Также приводится формальное определение
объектной БД. БД содержит схему (Schema) и экземпляры схемы (Instances).
Схема описывается тройкой (C, σ, G), где C — как и ранее множество имен
классов БД, σ — функция, которая сопоставляет именам классов собственно
классы, G — множество глобальных переменных классов. Множества C и G
выступают в качестве точки входа в БД.
Экземпляры схемы БД содержат конечное множество объектов и четыре
функции: πd — назначает объектам уникальные объектные идентификаторы (oid), π -— функция, которая по объекту определяет идентификатор oid,
присвоенный объекту функцией πd , υ — функция, которая сопоставляет объектным идентификаторам значения всех находящихся в БД объектов, γ -—
функция, которая присваивает значения глобальным переменным объектов.
Вкратце обсудим построение объектной алгебры. По аналогии с реляционной моделью данных, в основе которой лежит реляционная алгебра
Кодда, для ООП также рассматривают так называемую объектную алгебру, носителем которой является множество объектов [23–25]. Различаются
эти алгебры только сигнатурными операциями над объектами. В [26] авторы
вводят операции пересечения и сочленения (в работе она называлась объединением) над классами. В результате предлагается рассматривать вместо
объектной алгебры алгебраическую систему. Формально ее можно описать
как O, K; Ωobj ; Ωspec , ≤, где O -— множество объектов классов, K -—
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
313](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-313-320.jpg)
![те получим новую диаграмму классов (рис. 3), относительно которой сделаем
несколько замечаний. Как указывается в обзоре [27] клоны могут быть удале-
Рис. 3. Диаграмма классов ПрО “Школа и ВУЗ”
ны с использованием операций “выделение метода” (Extract Method) и “Подъем метода” (Pull Up Method), изложенных в монографии [28]. Выделение
метода (в русскоязычной литературе называемое процедурной абстракцией)
заключается в выделении общего кода в новую функцию (или метод класса,
если речь об ООП). Подъем метода заключается в перемещении общего мето-
316
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-316-320.jpg)
![да двух классов в их базовый класс. Если два класса не являются потомками
одного базового класса, то перед операцией Подъема метода можно создать
новый базовый класс при помощи операции выделения родительского класса (Extract Superclass) [29]. В нашем подходе могут быть также выделены
и общие атрибуты. Фактически своими преобразованиями над спецификациями классов мы изменяем внутреннюю структуру программ, не затрагивая
их поведения и в какой-то степени улучшаем понимание кода. Целью работы является разработка теории ООП при минимальных предположениях о
этой ПрО. Мы разделяем атрибуты и методы и рассматриваем функции, которые присваивают атрибутам и методам семантику (пока не уточняя какую
именно семантику; это будет сделано при последующей конкретизации). Мы
надеемся, что формальные результаты, представленные в следующем разделе,
обосновывают право на существование выбранного нами уровня абстракции.
По сути, в работе реализован принцип “разделяй и властвуй”.
4. Математические результаты
Приведем формальное уточнение класса (синоним — спецификации класса). Под классом будем понимать пару s, µ , где s —- функциональное
бинарное отношение, которое атрибуту ставит в соответствие его тип (множество значений из универсального домена D), а µ —- функциональное бинарное отношение (функция), которое сигнатуре метода ставит в соответствие
его реализацию (семантику, логику). Можно рассматривать µ как функциональное бинарное отношение, которое сигнатуре метода ставит в соответствие
его тип; в этом случае получим определение интерфейса.1
Отношение наследования ≤ между классами уточняется так:
s, µ ≤ s′ , µ′ , если s ⊆ s′ и µ ⊆ µ′ .
Приведем несколько определений, которые понадобятся в дальнейшем при
изложении материала.
Определение 1. Пусть α,β — функциональные бинарные отношения, тогда операция наложения определяется так: α▽β = β α | (domα domβ),
где domα и domβ области определения соответственно функций α и β, а
2
γ | X — ограничение функции γ по множеству X, т.е. γ | X = γ (X ×π2 γ)
2
(π2 γ — проекция отношения γ по второй компоненте).
Наложение иллюстрируется на рис. 4.
Уточним бинарную операцию сочленения
и пересечения ∩ классов.
Обозначим K — множество классов, K ∈ K — класс. Операция сочленения
является операцией вида:
: K × K → K, где s1 , µ1 s2 , µ2 =
= s1 ▽s2 , µ1 ▽µ2 .
1
Несмотря на то, что тип метода входит в сигнатуру, нам для построения функционального бинарного отношения необходимо разделять (считать разными) методы,
сигнатура которых отличается только типом возвращаемого значения. Такой подход
необходим для исследования интерфейсов.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
317](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-317-320.jpg)
![При доказательстве свойств операций над классами и установлении структуры семейства классов будут использоваться следующие абстрактные свойства ограничения [30]. Ниже U1 , U2 , . . . — произвольные бинарные отношения, X, X1 , . . . — произвольные множества, α, β, . . . — как и ранее, произвольные бинарные функциональные отношения. Параметрический оператор
U �→ U | X обозначен через ↑ X, ◦ — традиционная композиция бинарных
2
отношений, πi α — проекция бинарного отношения по i-той компоненте.
Предложение 1 (свойства ограничения). Ограничение имеет свойства:
1) U1 ⊆ U2 ∧ X1 ⊆ X2 ⇒ U1 | X1 ⊆ U2 | X2 (монотонность ограничения,
монотонность оператора ↑ X);
2
2
2) π1 (U | X) = π1 U X (проекция ограничения);
2
3) U | X = ε ⇔ π1 U X = ∅ (критерий пустоты ограничения); в частности, ε | X = U | ∅ = ε (сохранение ограничением пустого отношения
и пустого множества);
2
2
4) U | X = U | (X π1 U ), U = U | π1 U ; в частности,
2
π1 U ⊆ X ⇒ U | X = U ;
5) (U | X) | Y = U | (X Y ), в операторном виде ↑ Y ◦ ↑ X =↑ (X Y )
(композиция ограничений);
в частности, ↑ X◦ ↑ X =↑ X (идемпотентность оператора ↑ X);
6) U | X ⊆ U (оператор ↑ X убывающий);
7) оператор ↑ X является оператором замыкания (т.е. монотонным,
убывающим и идемпотентным оператором) относительно теоретикомножественного включения ⊆;
8) ( Ui ) | X = (Ui | X), U | Xi = (U | Xi ) (дистрибутивность
i
i
i
i
ограничения относительно объединений);
9) ( Ui ) | X = (Ui | X), U | Xi = (U | Xi ) (дистрибутивность
i
i
i
i
ограничения относительно пересечений);
10) α ⊆ β ∧ X ⊆ domα ⇒ α | X = β | X; в частности, α ⊆ β ⇒ α = β |
domα, α ⊆ β ∧ domα = domβ ⇒ α = β;
Очевидно, что операция наложения, вообще говоря, некоммутативная. Таким
образом, возникает вопрос о поиске соответствующего критерия. Ответ приведен в следующем утверждении.
Предложение 2 (критерий коммутативности операции наложения). Для
произвольных функциональных бинарных отношений α и β выполняется
эквивалентность α ≈ β ⇔ α▽β = β▽α. �
Следствие 1. Пусть α, β –– функциональные бинарные отношения. Тогда
имеют место следующие эквивалентности:
α▽β = β▽α ⇔ α▽β = α β
α▽β = β▽α ⇔ β▽α = β α. �
Следствие 2 (критерий совместности функций). Пусть α, β —- функциональные бинарные отношения. Тогда следующие утверждения эквивалентны:
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
319](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-319-320.jpg)
![1)
2)
3)
4)
5)
α ∪ β — функциональное бинарное отношение;
α▽β = β▽α;
α▽β = α ∪ β;
α ≈ β;
β▽α = β ∪ α. �
Доказательство. Доказательство проводится с использованием свойства отношения совместности ≈ [31]: α ≈ β ⇔ α β функциональное бинарное
отношение.
Для проведения доказательств последующих утверждений важна следующая
лемма.
Лемма 1. Пусть α, β —- функциональные бинарные отношения. Тогда
α β = (α β) | (domα domβ). �
Следствие 3. Для функциональных бинарных отношений α, β выполняются две эквивалентности
α ≈ β ⇔ dom(α β) = domα domβ,
α �≈ β ⇔ dom(α β) ⊂ domα domβ. �
Следствие 4. Для функциональных бинарных отношений α, β выполняются две эквивалентности
α ≈ β ⇔ α β = α | (domα domβ),
α ≈ β ⇔ α β = β | (domα domβ). �
Следующее следствие дополняет cледствие 2.
Следствие 5 (критерий совместности функций). Пусть α, β —- функциональные бинарные отношения. Тогда следующие утверждения эквивалентны:
1)
2)
3)
4)
α ≈ β;
dom(α β) = domα domβ;
α β = α | (domα domβ);
α β = β | (domα domβ). �;
Что касается самой операции наложения, то ее свойства приведены в следующем утверждении.
Предложение 3 (свойства наложения). Пусть α, β —- функциональные
бинарные отношения. Тогда имеют место следующие утверждения:
1)
2)
3)
4)
320
α▽α = α (идемпотентность);
α▽β �= β▽α, вообще говоря;
α▽β = β▽α ⇔ α ≈ β (критерий коммутативности);
(α▽β)▽γ = α▽(β▽γ) (ассоциативность). �
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-320-320.jpg)
![Доказательство. Докажем только 4 пункт. Будем использовать очевидное
равенство dom(α▽β) = domα domβ. Используя определение наложения и
свойства ограничения (предложение 1) имеем цепочку равенств:
(α▽β)▽γ = (β ∪ α | (domα domβ))▽γ =
= γ ∪ (β ∪ α | (domα domβ)) | (domα ∪ domβ) domγ =
= γ ∪ (β ∪ α | (domα domβ)) | ((domα domγ) ∪ (domβ domγ)) =
= γ ∪ β | (domα domγ) ∪ β | (domβ domγ) ∪ α | (domα domβ) |
| (domα domγ) ∪ (α | (domα domβ)) | (domβ domγ) =
= γ ∪ β | (domα domγ) ∪ β | (domβ domγ) ∪ α |
| (domα domβ) ∩ (domα domγ) ∪ α | (domα domβ) ∩ (domβ domγ) =
= γ ∪ β | (domα domγ) ∪ β | (domβ domγ) ∪ α |
| domα (domβ ∪ domγ) ∪ ε = γ ∪ β | (domβ domγ) ∪ α |
| (domα (domβ ∪ domγ)) ∪ β | (domα domγ) =
= γ ∪ β | (domβ domγ) ∪ α | (domα (domβ ∪ domγ)).
(1)
Прокомментируем неочевидные переходы. Переход от первого выражения
ко второму и от второго к третьему сделали по определению наложения; при
переходе от третьего к четвертому выражению воспользовались стандартным теоретико-множественным свойством (A ∪ B) C = A C ∪ B C; при
переходе от четвертого к пятому выражению — дистрибутивностью ограничения относительно объединений (предложение 1); при переходе от пятого
к шестому — свойством ограничения (α | A) | B = α | (A ∩ B) (предложение 1); при переходе от шестого к седьмому — теоретико-множественным
равенством (A B) ∩ (A C) = A (B ∪ C) и свойством ограничения α |
((domα domβ) ∩ (domβ domγ)) = α | ∅ = ε (предложение 1); при переходе
от восьмого к девятому — свойствами ограничения (предложение 1)
α | B = α | (domα ∩ B),
A⊆B⇒α|A⊆α|B и
β | domα domγ = β | domβ ∩ (domα domγ) ⊆ β | domβ domγ.
Перейдем к правой части равенства:
α▽(β▽γ) = α▽(γ ∪ β | (domβ domγ)) =
= γ ∪ β | (domβ domγ) ∪ α | (domα (domβ ∪ domγ)).
Из (1), (2) и вытекает доказываемое равенство.
(2)
�
Пусть F — класс всех функциональных бинарных отношений (на некотором зафиксированном универсуме D). Очевидно, что F, ⊆ — частично
упорядоченное множество (ч. у. м.). Перейдем к установлению его структуры. Здесь имеют место два следующих утверждения (для ч. у. м. используем
терминологию [32]).
Предложение 4. Ч. у. м. F, ⊆ есть нижняя полурешетка, причем inf {f, g} =
f ∩ g. �
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
321](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-321-320.jpg)
![Доказательство. Доказательство следует из того, что F, ∩ есть коммутативная идемпотентная полугруппа, и хорошо известной связи между такими полугруппами и нижними полурешетками,(см., например, [32]).
Таким образом, в терминах классов наибольшая общая часть двух классов
существует всегда, но она может быть пустой. Более полную информацию о
ч. у. м. F, ⊆ даёт следующее утверждение.
Предложение 5 (структура ч. у. м. F, ⊆). Выполняются следующие утверждения:
1) Всюду неопределённая функция f∅ — наименьший элемент (“дно”)
ч. у. м. F, ⊆.
2) Наибольший элемент в ч. у. м. F, ⊆ существует тогда и только
тогда, когда универсум D — не больше чем одноэлементный.
3) Точная нижняя грань (инфимум) существует для любого непустого
множества F , причем inf F = ∩f ∈F f .
4) Точная верхняя грань множества F (супремум) существует тогда
и только тогда, когда множество F ограничено сверху, при этом
sup F = ∪f ∈F f .
5) Элемент f является атомом тогда и только тогда, когда график f —
одноэлементный, т.е. f есть функцией вида f : {x} → {y}.
6) Ч. у. м. F, ⊆ является условно полным ч. у. м. и полной (верхней)
полурешеткой (complete semilattice).
Так как отношение наследования ≤ на классах вводится покомпонентно (эквивалентно: операцией прямого произведения порядков), то свойства ч. у. м.
F, ⊆ переносятся на ч. у. м. K, ≤: например, f∅ , f∅ — наименьший элемент и т.д.
Приведем соответствующий классический результат (см., например, [33]).
Пусть D1 , ≤1 , D2 , ≤2 — два ч. у. м. Их прямое произведение определяется стандартно: D1 × D2 , �, где d1 , d2 � d′ , d′ ⇔ d1 ≤1
1 2
d′ ∧ d2 ≤2 d′ . Для точных граней имеют место формулы:
1
2
2
2
sup L ≃ sup π1 L, sup π2 L ,
D1 ×D2
D1
2
2
inf L ≃ inf π1 L, inf π2 L ,
D1 ×D2
D1
(3)
D2
(4)
D2
L ⊆ D1 × D2 .
Здесь ≃ обобщенное равенство (сильное равенство Клини). Формулы (3) и
(4) и позволяют переносить свойства ч. у. м. F, ⊆ на ч. у. м. K, ≤.
Приведённые формальные результаты могут иметь практическое значение
при анализе диаграмм классов. Это во-первых, выделение компонент связности в соответствующем графе (по терминологии [32] речь идет о разложении ч. у. м. в кардинальную сумму). Выделение компонент соответствует декомпозиции системы на подсистемы. Во-вторых, в диаграмме классов можно
322
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-322-320.jpg)
![проводить поиск клонов для их элиминации (по этой проблематике см. [29]).
Наконец, в-третьих, диаграмму классов можно подвергнуть модификации с
помощью операций сочленения и пересечения с целью оптимизации по соответствующему критерию.
5. Результаты, выводы
В работе приведен короткий анализ доступной библиографии по ООП,
уточняются классы ООП в виде пар функциональных бинарных отношений.
Бинарное отношение, являющееся первой компонентой, атрибутам приписывает их типы (значения); отношение, являющееся второй компонентой, сигнатурам методов приписывает их семантику (тип значений функции — семантики для интерфейса).
Над классами рассматриваются операции пересечения и сочленения. Пересечение классов вводится на основе стандартного теоретико-множественного
пересечения бинарных отношений, а сочленение — на основе специальной
операции наложения, которая позволяет разрешить конфликт имен. Указанные операции над классами могут быть использованы при рефакторинге
(refactoring) программ.
Наследование классов уточняется в виде стандартного теоретико-множественного включения между соответствующими компонентами классов. В
работе получены следующие основные математические результаты:
– установлены основные свойства наложения (идемпотентность, ассоциативность, критерий коммутативности в терминах отношения совместности);
– структура ч. у. м. множества всех функциональных бинарных отношений,
упорядоченного по включению (это ч. у. м. является нижней полурешеткой; всюду неопределённая функция является наименьшим элементом;
инфимумы непустых подмножеств существуют всегда, супремумы подмножеств существуют тогда и только тогда, когда подмножества ограничены с верху; для точных граней приведены формулы их нахождения).
Предложенная формальная модель может использоваться для анализа и
модификации диаграмм классов:
– нахождения компонент связности, что соответствует декомпозиции системы на подсистемы;
– поиска клонов;
– модификации диаграмм с помощью введенных операций пересечений и
сочленения.
Что касается дальнейших математических исследований, имеющих содержательную интерпретацию, то это, например, установление взаимной дистрибутивности рассматриваемых операций.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
323](https://image.slidesharecdn.com/tmpa2013proceedings-131009050023-phpapp01/85/TMPA-2013-Conference-Proceedings-323-320.jpg)
Uploaded byIosif Itkin
TMPA-2013 Conference Proceedings
On 10-12 October 2013, Kostroma, Russia, will host 2013 International Workshop-Conference “Tools & Methods of Program Analysis” (TMPA-2013). Its general theme will be one of the most pertinent and important areas of software engineering: the analysis of software quality. The issues of efficiency and correctness of software are key for the majority of knowledge-intensive industries in modern economy, including IT, financial sector, transportation, medicine, high-technology industries, and many others. The development of new instruments and methods of program analysis, as well as the modification of existing ones, is one of the necessary prerequisites for introducing innovation. The purpose of the conference is to promote progress in the software development industry and the introduction of the latest achievements in the areas of testing, analysis and verification. The conference program will include plenary reports and mini-courses delivered by experts; presentations selected by the Program Committee; presentations of on-going projects, short reports about new ideas, research that is still underway or new tools. The program will include, and won’t be limited to, the following topics: - software test automation; static program analysis; verification; dynamic methods of program analysis; testing and analysis of parallel and distributed systems; testing and analysis of high-load and high-availability systems; analysis and verification of hardware and software systems; methods of building quality software; tools for software analysis, testing and verification.
TMPA-2013 Conference Proceedings
- 2. Министерство образования инауки РФ Костромской государственный технологический университет Санкт-Петербургский государственный политехнический университет Российская академия наук Институт проблем информатики ООО «Инновационные Трейдинговые Системы» ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ TOOLS & METHODS OF PROGRAM ANALYSIS TMPA-2013 Материалы Международной научно-практической конференции 10—12 октября 2013 Кострома 2013
- 3. УДК 004.413.5 И726 Печатается порешению научно-технического совета КГТУ Редакционная коллегия: Председатель: Киселев М.В. Члены редколлегии: Захаров В.Н., Ицыксон В.М., Лустгартен Ю.Л., Иткин И.Л., Ходченко А.С., Загоруйко К.В., Аввакумова Е.С., Зверев А.В., Рудовский П.Н И726 Инструменты и методы анализа программ Tools & Methods of Program Analysis TMPA-2013: материалы Международной науч.практ. конф.- Кострома: Из-во Костромского гос. технол. ун-та, 2013. - 348 с. ISBN 978-5-8285-0666-8 В сборнике публикуются доклады участников Международной научно-практической конференции «Инструменты и методы анализа программ / Tools & Methods of Program Analysis (TMPA2013)», состоявшейся 10-12 октября 2013 г. в Костромском государственном технологическом университете. Для широкого круга читателей. ISBN 978-5-8285-0666-8 16+ УДК 004.413.5 © Костромской государственный технологический университет, 2013
- 6. Содержание: ВЕРИФИКАЦИЯ: • Пакулин Н. Динамическаяверификация гибридных систем 19 Институт системного программирования РАН • Подымов В., Попеско У. 36 Верификация программно-конфигурируемых сетей при помощи системы UPPAAL МГУ имени М.В. Ломоносова • Кузьмин Е., Рябухин Д., Шипов А. Построение и верификация ПЛК-программ по LTL-спецификации 48 Ярославский государственный университет им. П.Г. Демидова • Ануреев И. На пути к технологии разработки стредств дедуктивной верификации программ 66 Институт систем информатики имени А.П. Ершова • Лукин М., Шалыто А. Верификация распределенных автоматных программ с использованием инструментального средства Spin 78 СПб НИУ ИТМО АППАРАТНЫЙ ТРЕК: • Иванников В., Камкин А., Чупилко М. Проверка корректности поведения HDL-моделей цифровой аппаратуры на основе динамического сопоставления трасс 94 Институт системного программирования Российской академии наук (ИСП РАН) • Шипин А., Соколов В., Чалый Д. Использование контрольных точек для верификации SystemCпрограмм 106 Ярославский государственный университет 6 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 7. • Френкель С.,Захаров В., Ушаков В. Унифицированная высокоуровневая модель программноаппаратной системы для верификации свойств надежности функционирования 118 Институт проблем информатики РАН, Московский гос. университет им. М.В. Ломоносова • Смирнов М., Олоничев В., Староверов Б. Особенности разработки программного обеспечения для Linuxконтроллеров 130 Костромской государственный технологический университет ТЕСТИРОВАНИЕ: • Басок Б., Гречин А. Об усовершенствовании статистического метода оценки полноты тестов программ и устройств 138 Московский государственный технический университет радиотехники, электроники и автоматики • Сартаков В., Тарасиков А. Анализ производительности сетевой подсистемы микроядерного окружения Genode 146 ksys labs • Журавлев М., Полозов В. Подход к верификации корректности миграции данных между СУБД с использованием криптографических хэш-функций 158 Санкт-Петербургский Государственный Университет • Никешин А., Пакулин Н., Шнитман В. Автоматизация тестирования соответствия протокола безопасности транспортного уровня TLS 167 Институт системного программирования РАН Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 7
- 8. • Сенов А. Применениетехнологий OLAP и MapReduce для обработки результатов нагрузочного тестирования 179 Костромской государственный технологический университет ТРЕЙДИНГОВЫЕ СИСТЕМЫ: • Матвеева А., Антонов Н., Иткин И. Особенности инструментов для тестирования, применимых при промышленной эксплуатации трейдинговых систем 191 ООО «Инновационные Трейдинговые Системы», Костромской государственный технологический университет, Exactpro Systems LLC • Алексеенко А., Проценко П., Матвеева А., Иткин И., Шаров Д. 203 Тестирование совместимости протокольных подключений клиентов биржевых и брокерских систем ООО «Инновационные Трейдинговые Системы», Exactpro Systems LLC • Буянова О., Булда А, Зверев А. Применение симуляторов рынка ценных бумаг для тестирования систем агрегации и распределения информации о котировках (Ticker Plant) 215 ООО «Инновационные Трейдинговые Системы», Костромской государственный технологический университет, Exactpro Systems LLC • Гурьев Д., Гай М., Иткин И., Терентьев А. Высокопроизводительный генератор нагрузки для тестирования систем автоматизированной торговли 242 ООО «Инновационные Трейдинговые Системы», Саратовский государственный технический университет имени Гагарина Ю.А. 8 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 9. • Прядкина Н.,Крюков А. Использование MBT-подхода для верификации систем мониторинга и контроля на фондовых биржах 254 Костромской государственный технологический университет • Бобров И., Зверев А. Тестирование графического интерфейса трейдинговых терминалов в условиях высокочастотной торговли 264 ООО «Инновационные Трейдинговые Системы» АНАЛИЗ ПРОГРАММ: • Цителов Д., Трифанов В. Динамический поиск гонок в Java-программах на основе синхронизационных контрактов 273 Devexperts LLC, СПбГУ • Верт Т., Крикун Т., Глухих М. Обнаружение дефектов работы с указателями в программах С и С++ с использованием статического анализа и логического вывода 286 Санкт-Петербургский государственный политехнический университет, Технический университет Клаусталя • Андрианова А., Ицыксон В. Автоматизированный синтез тестов для Java-программ на основе анализа программ и учета контрактов 298 Санкт-Петербургский государственный политехнический университет • Буй Д., Компан С. Диаграммы классов ООП: формализация и анализ 311 Киевский национальный университет имени Тараса Шевченко Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 9
- 10. Конференция TMPA-2013 10 Международная научно-практическаяконференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 11. Международная научно-практическая конференция: Tools& Methods of Program Analysis (Инструменты и методы анализа программ, TMPA-2013) 10-12 октября 2013, г. Кострома, РФ Конференция посвящена одному из наиболее актуальных и важных направлений программной инженерии – анализу качества программного обеспечения. Вопросы эффективности и корректности функционирования программного обеспечения являются ключевыми для большинства наукоемких отраслей современной экономики, включая ИТ-индустрию, финансовый сектор, транспорт, медицину, высокотехнологическую промышленность и многие другие. Разработка новых и усовершенствование существующих инструментов и методов анализа программ – одно из необходимых условий внедрения инноваций в этих отраслях. Конференция нацелена на развитие индустрии разработки программного обеспечения и внедрение новейших разработок в области тестирования, анализа и верификации. В рамках конференции планируются пленарные доклады и лекционные мини-курсы экспертов; доклады участников, отобранные программным комитетом из числа поступивших заявок; презентации открытых проектов, короткие сообщения, представляющие новые идеи, незавершенные исследования или новые инструменты. Темы, рассматриваемые на конференции, включают (но не ограничиваются): • автоматизация тестирования программного обеспечения; • статический анализ программ; • верификация; • динамические методы анализа программ; • тестирование и анализ параллельных и распределенных систем; • тестирование и анализ высоконагруженных систем и систем высокой доступности; • анализ и верификация программно-аппаратных систем; • методы создания качественного программного обеспечения; • инструментальные средства анализа, тестирования и верификации Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 11
- 12. Программный комитет конференции • Захаров Виктор Николаевич, д.т.н., ИПИ РАН, сопредседатель • Ицыксон Владимир Михайлович, к.т.н., доцент кафедры компьютерных систем и программных технологий СПбГПУ, сопредседатель • Лустгартен Юрий Леонидович, к.т.н., декан ФАСТ КГТУ, сопредседатель • Петренко Александр Константинович, д.ф.-м.н., зав. отделом Технологий программирования Института системного программирования РАН, профессор кафедры Системного программирования ВМиК МГУ им. М.В.Ломоносова • Басок Борис Моисеевич, к.т.н., доцент МИРЭА • Глухих Михаил Игоревич, к.т.н., доцент, СПбГПУ, приглашенный исследователь в Clausthal University of Technology • Евтушенко Нина Владимировна, д.т.н., профессор, зав. кафедры Информационных технологий в исследовании дискретных структур, Радиофизический факультет, Национальный исследовательский Томский государственный университет (ТГУ) • Зайцев Дмитрий Анатольевич, д.т.н., профессор, Международный гуманитарный университет, Одесса, Украина • Захаров Владимир Анатольевич, д.ф.-м.н., доцент кафедры МК, зав. лабораторией МПКБ • Иванов Александр Николаевич, к.ф.-м.н., ведущий разработчик ООО «КоФиТе» • Иткин Иосиф Леонидович, компания Exactpro Systems, координатор • Камкин Александр Сергеевич, к.ф.-м.н., с.н.с. ИСП РАН; • Климов Андрей Валентинович, зав. сектором методов анализа и преобразования программ ИПМ им. М.В.Келдыша РАН 12 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 13. • Кириленко ЯковАлександрович, старший преподаватель, МатМех СПбГУ • Кулямин Виктор Вячеславович, к.ф.-м.н., с.н.с. ИСП РАН, доцент ВМК МГУ • Моисеев Михаил Юрьевич, к.т.н., доцент, СПбГПУ • Пакулин Николай Витальевич, к.ф.-м.н., старший научный сотрудник ИСП РАН • Павлова Елена Анатольевна, к.т.н., координатор программ, Microsoft • Прохоров Сергей Петрович, к.ф.-м.н., ИСП РАН, доцент МФТИ • Соколов Валерий Анатольевич, д.ф.-м.н., проф., зав. каф. теоретической информатики ЯГУ им. П.Г. Демидова • Федосеев Андрей Алексеевич, к.т.н., в.н.с. ИПИ РАН • Филиппов Станислав Александрович, к.т.н., с.н.с. ИПИ РАН • Христочевский Сергей Александрович, к.ф.-м.н., зав. лаб. ИПИ РАН • Цесько Вадим Александрович, старший разработчик, Яндекс Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 13
- 14. Программа конференции TMPA-2013 14 Международная научно-практическаяконференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 15. 10 октября 8:30 Регистрация 9:30 Открытие 10:15 11:15 Карпов Ю. Верификацияпараллельных программ: современный этап и перспективы Кофе-брейк ВЕРИФИКАЦИЯ 11:45 Пакулин Н. Динамическая верификация гибридных систем 12:15 Подымов В., Попеско У. Верификация программно-конфигурируемых сетей при помощи системы UPPAAL 12:45 Кузьмин Е., Рябухин Д., Шипов А. Построение и верификация ПЛК-программ по LTL-спецификации 13:15 Ануреев И. На пути к технологии разработки средств дедуктивной верификации программ 13:45 Лукин М., Шалыто А. Верификация распределенных автоматных программ с использованием инструментального средства Spin 14:00 Обед 15:30 Зайцев Д. Эффективная универсальная сеть Слепцова АППАРАТНЫЙ ТРЕК 16:00 Иванников В., Камкин А., Чупилко М. Проверка корректности поведения HDL-моделей цифровой аппаратуры на основе динамического сопоставления трасс 17:00 Шипин А., Соколов В., Чалый Д. Использование контрольных точек для верификации SystemC-программ 17:30 Френкель С., Захаров В., Ушаков В. Унифицированная высокоуровневая модель программно-аппаратной системы для верификации свойств надежности функционирования 17:45 Смирнов М., Олоничев В., Староверов Б. Особенности разработки программного обеспечения для Linuxконтроллеров Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 15
- 16. 11 октября 8:30 Регистрация 9:30 Петренко А.К. Технические решения и нетехнические проблемы автоматизации тестирования 10:30 ISTQB ТЕСТИРОВАНИЕ 11:00 11:30 Басок Б., Гречин А. Об усовершенствовании статистического метода оценки полноты тестов программ и устройств Кофе-брейк 12:00 Никешин А., Пакулин Н., Шнитман В. Автоматизация тестирования соответствия реализаций стандарту протокола безопасности транспортного уровня TLS 12:30 Сартаков В., Тарасиков А. Анализ производительности сетевой подсистемы микроядерного окружения Genode 13:00 Журавлев М., Полозов В. Подход к верификации корректности миграции данных между СУБД с использованием криптографических хэш-функций 13:15 Сенов А. Применение технологий OLAP и MapReduce для обработки результатов нагрузочного тестирования ТРЕЙДИНГОВЫЕ СИСТЕМЫ 13:30 14:00 15:30 Матвеева А., Антонов Н., Иткин И. Особенности инструментов для тестирования, применимых при промышленной эксплуатации трейдинговых систем Обед Алексеенко А., Проценко П., Матвеева А., Иткин И., Шаров Д. Тестирование совместимости протокольных подключений клиентов биржевых и брокерских систем 15:50 16:10 Гурьев Д., Гай М., Иткин И., Терентьев А. Высокопроизводительный генератор нагрузки для тестирования систем автоматизированной торговли 16:30 16 Буянова О., Булда А, Зверев А. Применение симуляторов рынка ценных бумаг для тестирования систем агрегации и распределения информации о котировках (Ticker Plant) Прядкина Н., Крюков А. Использование MBT-подхода для верификации систем мониторинга и контроля на фондовых биржах Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 17. 11 октября 16:45 Бобров И.,Зверев А. Тестирование графического интерфейса трейдинговых терминалов в условиях высокочастотной торговли 17:00 Кофе-брейк 17:30 Круглый стол: Нешаблонные методы тестирования программного обеспечения для электронных торговых платформ 12 октября 9:00 Регистрация 9:30 Захаров В. А. Математические аспекты задачи обфускации программ АНАЛИЗ ПРОГРАММ 10:30 Цителов Д., Трифанов В. Динамический поиск гонок в Java-программах на основе синхронизационных контрактов 11:00 Верт Т., Крикун Т. и Глухих М. Обнаружение дефектов работы с указателями в программах С и С++ с использованием статического анализа и логического вывода 11:30 Кофе-брейк 12:30 Андрианова А., Ицыксон В. Автоматизированный синтез тестов для Java-программ на основе анализа программ и учета контрактов 12:45 Буй Д., Компан С. Диаграммы классов ООП: формализация и анализ 13:00 Круглый стол: Как написать хорошую научную статью 13:30 Закрытие конференции 14:00 Завершающий обед Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 17
- 18. Cекционные доклады TMPA-2013 18 Международная научно-практическаяконференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 19. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 19
- 20. 20 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 21. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 21
- 22. 𝑑𝑑𝑑𝑑 𝑑𝑑𝑑𝑑 = 𝑘𝑘(100 −𝑇𝑇 ) 𝑘𝑘1 < 𝑑𝑑𝑑𝑑 𝑑𝑑𝑑𝑑 𝑘𝑘 < 𝑘𝑘2 𝑇𝑇 𝑇 70 𝑇𝑇 𝑇 68 22 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 23. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 23
- 24. 𝑀𝑀 𝐼𝐼 𝑆𝑆 𝐼𝐼 24 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 25. 𝜑𝜑 𝐼𝐼 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 = 𝑓𝑓(𝑥𝑥) 𝑙𝑙 ≤ 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 ≤ 𝑚𝑚 𝑙𝑙 𝑚𝑚 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 25
- 26. 26 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 27. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 27
- 28. 28 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 29. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 29
- 30. 30 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 31. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 31
- 32. 32 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 33. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 33
- 34. 34 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 35. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 35
- 36. Верификация программно-конфигурируемых сетей припомощи системы UPPAAL Владислав Подымов, Ульяна Попеско МГУ имени М.В. Ломоносова valdus@yandex.ru, ulya_kiber@mail.ru Аннотация В последние несколько лет активное развитие получили программно-конфигурируемые сети (ПКС) – особый вид компьютерных сетей, в которых все коммутирующие устройства имеют централизованное управление. В статье исследуются задачи формального описания и верификации ПКС. Для описания ПКС используется библиотека элементов UML в редакторе диаграмм Dia. Для верификации ПКС используется программно-инструментальное средство UPPAAL. Основной результат исследований - разработка транслятора, позволяющего по диаграмме сети получить её модель для верификации в виде сети конечных временных автоматов. Корректность алгоритма трансляции строго обоснована. Проведен ряд экспериментов, которые показывают применимость предложенного метода верификации для проверки свойств поведения ПКС, специфицированных посредством формул темпоральной логики реального времени. Keywords: программно-конфигурируемая сеть, верификация, временные автоматы, темпоральная логика, UPPAAL 1 Введение Идея программно-конфигурируемых сетей (ПКС) сформулирована специалистами университетов Стэнфорда и Беркли в 2006 году [1]. В таких сетях уровень управления отделен от устройств передачи данных: коммутаторы не участвуют в определении маршрутов для пакетов, а только реализуют программу контроллера. Наиболее широко применяемым стандартом для построения ПКС является протокол OpenFlow [2]. Сеть OpenFlow состоит из коммутаторов, управляемых централизованным контроллером. Пакет, передаваемый по сети, обрабатывается контроллером существенно медленнее, нежели коммутатором, поэтому одной из основных функций контроллера является организация работы коммутаторов так, чтобы они обрабатывали большую часть пакетов, и лишь в исключительных случаях пакеты обрабатывались бы на контроллере. Организация работы коммутаторов заключается в установке правил в таблицы коммутации (flow tables), определяющих, как будут обрабатываться те или иные пакеты. Правило состоит из шаблона, идентифицирующего вид пакетов, целочисленного приоритета, устраняющего неоднозначность в 36 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 37. 2 Владислав Подымов, УльянаПопеско случае наложения шаблонов, целочисленного лимита времени, указывающего число секунд до истечения срока активности правила, и списка действий, описывающих обработку пакета. Также для каждого правила в этих таблицах коммутатор содержит счетчики для учета количества и размера обрабатываемых пакетов. Коммутатор обрабатывает приходящий пакет в 3 этапа. Сначала он выбирает правило из своей таблицы коммутации так, чтобы заголовок пакета соответствовал шаблону этого правила. Если такового не найдено, коммутатор отправляет пакет контроллеру для дальнейшей обработки. Иначе выбирается совпадающее по шаблону правило с наибольшим приоритетом. На втором шаге обновляются счетчики для выбранного правила. И наконец, к пакету поочередно применяются все действия, записанные в правиле. К допустимым действиям относятся output(op) и modif y(h,n). По действию output(op) пакет отправляется на порт op. Действие modif y(h,n) предписывает переписать заголовочное поле h на n. Контроллер устанавливает правила в таблицы коммутации, реагируя на события в сети. Такими событиями являются подключение нового коммутатора к сети, удаление ранее действующего коммутатора из сети, события для сбора статистики, истечение лимита времени правила коммутатора. Также контроллер оперирует функциями отправки сообщений коммутаторам: установкой правил в таблицу коммутации, удалением всех правил с заданным шаблоном из таблицы коммутации, отправкой пакета и действия для его обработки коммутатором. В статье исследуется возможность верификации ПКС как распределенных систем реального времени. Для этого потребовалось решить следующие задачи: 1) выбрать адекватное средство для построения сетей; 2) выбрать подходящее средство для верификации сетей как систем реального времени; 3) построить корректный транслятор из выбранного средства построения сетей во входной язык нужной системы верификации; 4) провести экспериментальное исследование возможности применения выбранного средства верификации для проверки спецификаций ПКС. Стандарт OpenFlow включает в себя большое количество свойств и предписаний для коммутации пакетов в сети. Производители компонентов компьютерных сетей используют лишь часть из них. Мы также ограничимся в рассматриваемых вариантах. При моделировании правил таблиц коммутации не будем уделять внимание приоритетам и счетчикам, а из всех допустимых действий будем рассматривать только действия типа output(op). Сбор статистических данных в сети также не будет нас интересовать. С другой стороны, в нашу модель будут добавлены временные характеристики, описывающие работу физических объектов сети. Посредством этого мы будем учитывать не только предписания стандарта OpenFlow, но и технические возможности коммутаторов и каналов. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 37
- 38. Верификация ПКС припомощи системы UPPAAL 2 3 Схема верификации Для построения ПКС был выбран кроссплатформенный редактор диаграмм Dia1 . Сеть из рассматриваемого нами подкласса описывается с помощью объектов библиотеки элементов UML, предоставляемых редактором, следующим образом (см. рисунок 1). Каждый коммутатор изображается в виде прямоугольника с тремя секциями. В верхней секции обозначается имя коммутатора, в нижней содержатся правила таблицы коммутации, в средней — физические характеристики коммутатора. Каждое правило таблицы коммутации имеет четыре поля: имя порта, на который поступил пакет, заголовок поступившего пакета, лимит времени жизни правила и порт, на который необходимо отправить пакет. Описываются следующие характеристики коммутатора: port — множество портов коммутатора, соединяющих его с другими коммутаторами и внешней средой; rule_imp — задержка поиска и выполнения правила на коммутаторе (временной интервал); rule_def — задержка установки в коммутатор правила от контроллера; rule_ar — интенсивность поступления пакетов из внешней среды; rule_con — задержка доставки необработанного пакета контроллеру; tab — объем таблицы коммутации, то есть максимальное число правил таблицы. Рис. 1. Пример описания ПКС диаграммами Dia. Для отображения топологии сети коммутаторы соединяются линиями, моделирующими дуплексные каналы сети. Каналы также имеют временную характеристику — задержку доставки пакета. Поведение контроллера опре1 38 Руководство пользователя редактора Dia доступно по адресу http://diainstaller.de/doc/en/dia-manual.pdf Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 39. 4 Владислав Подымов, УльянаПопеско деляется политикой коммутации пакетов в сети, которая для нашего класса задач представима в виде таблицы, отображающей соответствие между заголовком поступившего на контроллер пакета и правилом, которое необходимо установить на коммутатор, приславший этот пакет. Также отдельно описывается множество всех возможных заголовков пакетов. Для проверки спецификаций построенных таким образом ПКС было выбрано программно-инструментальное средство UPPAAL [3], использующее метод проверки свойств на моделях. Данный метод предполагает наличие модели, описывающей систему на определенном уровне абстракции, и позволяет проверить, удовлетворяет ли заданная модель системы формальным спецификациям. В средстве верификации UPPAAL в качестве модели используются сети конечных временных автоматов (параллельные композиции временных автоматов) [4], а формальные спецификации задаются формулами темпоральной логики TCTL [3]. Временные автоматы представляют собой конечные автоматы, работающие в реальном времени и осуществляющие синхронизацию посредством передачи сигналов через каналы связи. Особенностью таких автоматов является возможность использования таймеров. Значения таймеров можно указывать во временных ограничениях условий переходов между состояниями. Показания всех таймеров изменяются на одинаковые величины с течением времени. Для верификации ПКС, описанных в терминах диаграмм Dia, средством UPPAAL, нами предложен алгоритм трансляции диаграмм в сети временных автоматов. Сеть, получаемая при трансляции, состоит из автоматов, моделирующих коммутаторы, контроллер, внешнюю среду и каналы сети. Таким образом, в результате трансляции диаграмм мы получаем сеть, пригодную для верификации средством UPPAAL. Подобный подход к верификации распределенных систем реального времени был применен в работе [5]. 3 Формальный синтаксис ПКС Перед описанием алгоритма трансляции необходимо ввести формальную модель ПКС. С учетом выбранных нами ограничений ПКС может быть описана системой (H, con, Com, Chan), где H — множество заголовков пакетов сети, con — контроллер, Com = (com1 , . . . , comn ) — набор коммутаторов сети и Chan = (c1 , . . . , cm ) — набор каналов сети. Заметим, что во введенной формальной модели ПКС вместо пакетов рассматриваются только их заголовки, при этом содержащиеся в пакетах сообщения опускаются. Для простоты восприятия далее под пакетами в формальной модели будут подразумеваться их заголовки. Коммутатор comi включает в себя множество портов P orti , начальную таблицу коммутации Rulei ⊆ P orti × H × Real × P orti объема tab и временimp def ar con ные характеристики Limp , Ri , Ldef , Ri , Lar , Ri , Lcon , Ri , естественi i i i ным образом соотносящиеся с характеристиками коммутатора, описанными Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 39
- 40. Верификация ПКС припомощи системы UPPAAL 5 в диаграмме (см., например, рисунок 1). Правило (p, h, x, p ) таблицы коммутации означает, что пакет h, пришедший на порт p, перенаправляется на порт p . При этом x — время жизни правила; если x ≥ 0, то правило назовем активным, иначе истекшим. Шаблоном правила (p, h, x, p ) будем называть пару (p, h). Контроллер con представляет собой множество пар вида (i, r), означающих, что правило r может быть выслано коммутатору comi . Канал c описывается тем, из какого порта какого коммутатора он исходит, в какой порт какого коммутатора он входит и временными характеристиками L, R — минимальное и максимальное время задержки при доставке пакета. Заметим, что в предложенной модели каналы являются однонаправленными. Такое ограничение несущественно, т.к. дуплексный канал моделируется двумя однонаправленными. 4 Формальная семантика ПКС Для доказательства корректности алгоритма трансляции необходимо ввести формальное описание работы ПКС. Данное описание является формализацией поведения ПКС в рамках стандарта OpenFlow с учетом введенных нами ограничений. Состояние ПКС складывается из состояний контроллера и всех коммутаторов и каналов. Для удобства описания предполагаем, что каждый коммутатор comi располагает следующими каналами: канал car входного потока i ar с временными характеристиками L = Lar , R = Ri , ведущий в специально i выделенный под него порт; канал cto con , ведущий в контроллер из другого i con специально выделенного порта, с характеристиками L = Lcon , R = Ri ; i f rom con , ведущий от контроллера в третий специально выделенный канал ci порт коммутатора, с характеристиками L = R = 0. Таким образом, состояние S ПКС включает в себя состояния scon контроллера, scom , . . . , scom комn 1 мутаторов и sch , . . . , sch , sar , . . . , sar , stocon , . . . , stocon , sf romcon , . . . , sf romcon m n n n 1 1 1 1 каналов ch между коммутаторами, ar от входного потока, to con к и f rom con от контроллера соответственно. Коммутатор comi может находиться в состояниях (start, Rule), (select, t, Rule, h, p), (hit, Rule, h, p), (miss, Rule, h, p), (mod, t, Rule). В состоянии start коммутатор прослушивает входящие каналы на предмет поступивших пакетов. В состоянии select коммутатор, получив на порт p пакет h, просматривает таблицу коммутации для принятия решения о перенаправлении пакета. В состоянии hit пакет засылается в канал, исходящий из порта p. В состоянии miss шаблон, состоящий из пакета h и порта p, на который он пришел, засылается в канал к контроллеру. Вообще говоря, коммутатор также должен посылать контроллеру свой идентификатор, однако в построенной формальной модели идентификатор может быть восстановлен по номеру порта, входящего в коммутатор. В состоянии mod происходит запись в таблицу коммутации правила, присланного контроллером. Во всех состояниях 40 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 41. 6 Владислав Подымов, УльянаПопеско коммутатора Rule — текущая таблица коммутации, t — время нахождения в текущем управляющем состоянии, h и p — хранимые пакет и порт. Каналы могут могут находиться в состояниях (empty), (f ull, t, o) и (sent, o), где o — пакет для обычных и поточных каналов, шаблон для каналов к контроллеру либо правило для каналов от контроллера. Компонента t ∈ Real — время обработки сообщения каналом. Контроллер может находиться только в состояниях (idle) (ожидание запросов от коммутаторов) и (send, i, r) (послать i-му коммутатору новое правило r). Начальное состояние S0 системы строится из начальных состояний коммутаторов, контроллера и каналов. Начальное состояние i-го коммутатора — (start, Rulei ), контроллера — (idle), каналов — (empty). Работа ПКС характеризуется последовательностью состояний, начинающейся в S0 и строящейся по описанным далее правилам. Запись s → s означает, что следующее состояние может быть получено из предыдущего заменой компоненты s на s . Запись s1 , s2 → s1 , s2 означает то же самое для пары компонент. Построение вычисления ПКС происходит по следующим правилам. 1. Получение пакета: scom , sar = (start, Rule), (sent, h) → (select, 0, Rule, i i h, p), (empty). 2. Применение активного правила r = (p, h, x, p ): scom = (select, Rule, t, i imp h, p) → (hit, Rule, h, p ), если t ∈ [Limp , Ri ], r ∈ Rule. i 3. Обработка истекшего правила r = (p, h, x, p ): scom = (select, Rule, t, h, p) i imp → (miss, Rule , h, p), если t ∈ [Limp , Ri ], r ∈ Rule и Rule = Rule {r}. i 4. Сброс пакета: scom = (select, Rule, t, h, p) → (start, Rule), если t ∈ i imp [Limp , Ri ], |Rule| = tabi , все правила из Rule активны и ни одно из i них не имеет шаблона (p, h). 5. Несоответствие шаблонов: scom = (select, Rule, t, h, p) → (miss, Rule , i h, p), где Rule получается из Rule удалением всех истекших правил. 6. Начало перезаписи таблицы: scom , sf rom con = (start, Rule), (sent, rule) i i → (mod, 0, Rule), (sent, rule). 7. Успешная перезапись таблицы: scom , sf rom con = (mod, t, Rule), (sent, (p, i i def h, x, p )) → (hit, Rule , h, p ), (empty), если t ∈ [Ldef , Ri ], |Rule| < tabi i и Rule = Rule ∪ {(p, h, x, p )}. 8. Неуспешная перезапись таблицы: scom , sf rom con = (mod, t, Rule), (sent, i i def rule) → (start, Rule), (empty), если t ∈ [Ldef , Ri ] и |Rule| = tab. i com ch 9. Пересылка пакета коммутатору: si , sj = (hit, Rule, h, p), (empty) → (start, Rule), (f ull, 0, h), если канал cj исходит из порта p коммутатора i. 10. Пересылка шаблона контроллеру: scom , sto con = (miss, Rule, h, p), (empty) i i → (start, Rule), (f ull, 0, (p, h)). 11. Успешная обработка шаблона контроллером: scon , sto con = (idle), (sent, i (p, h)) → (send, i, r), (empty), если (i, (p, h, x, p )) ∈ con. 12. Неуспешная обработка шаблона контроллером: scon , sto con = (idle), (sent, i / (p, h)) → (idle), (empty), если (i, (p, h, x, p )) ∈ con. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 41
- 42. Верификация ПКС припомощи системы UPPAAL 7 13. Пересылка правила от контроллера: scon , sf rom con = (send, i, r), (empty) i → (idle), (f ull, 0, r). 14. Появление пакета в сети: sar = (empty) → (f ull, 0, h), если h ∈ H. i 15. Сброс пакета в окружение: scom = (hit, Rule, h, p) → (start, Rule), если i ни один канал cj не исходит из порта p коммутатора comi . 16. Доставка в канале: (f ull, t, o) → (sent, o), если t ∈ [L, R] для характеристик L, R соответствующего канала. 17. Продвижение времени: таймеры всех коммутаторов и каналов увеличиваются на одну и ту же положительную величину d, времена жизни правил уменьшаются на эту же величину, и при этом: – если какой-либо канал находится в состоянии (f ull, t, o), то t + d ≤ R для характеристики R этого канала; imp – если scom = (select, Rule, t, h, p), то t + d ≤ Ri ; i def com – если si = (mod, Rule, t), то t + d ≤ Ri . 5 Алгоритм трансляции Алгоритм Alg переводит ПКС в эквивалентную ей сеть временных автоматов. Понятие эквивалентности обсуждается в следующем разделе. Сеть N , получаемая в результате трансляции ПКС ((com1 , . . . , comn ), con, (c1 , . . . , cm ), H), содержит автоматы Hurry, Env, Stream, Chan, Acon и Ai , i ∈ {1, . . . , n}. Каждый канал ci моделируется булевыми переменными f ull[ci ] (пакет послан), ready[ci ] (пакет доставлен), таймером t[ci ] и переменными для хранения объектов, пересылаемых через канал. Сброс пакетов в окружение моделируется с помощью особого канала cenv . Также в сеть добавляются все каналы car , cto con , cf rom con . i i i Автомат Hurry обеспечивает срочные дуги (т.е. дуги, выполняющиеся немедленно по выполнении их предусловий) и состоит из одной вершины и петли, принимающей сигнал по срочному каналу hurry. К срочным дугам по умолчанию добавляется посылка сигнала по каналу hurry. Автомат Env удаляет пакеты из канала cenv и состоит из одной вершины и срочной петли с записью в переменную f ull[cenv ] значения f alse. Автомат Stream генерирует пакеты, состоит из одной вершины и содержит набор срочных петель, недетерминированно засылающий пакеты в каналы car . i Автомат Chan обеспечивает доставку пакетов каналами, состоит из одной вершины и содержит петлю для каждого канала c, помеченную предусловием f ull[c] && !ready[c] && (t[c] ≥ L(c)) и записью в переменную ready[c] значения true, где L(c) — характеристика L канала c. Сама вершина автомата Chan при этом помечена инвариантом — конъюнкцией неравенств t[c] ≤ R(c). Автомат Acon имеет два обычных состояния — idle и send — и одно срочное состояние l. Срочная дуга idle → l записывает в локальные переменные автомата шаблон, присланный коммутатором, и номер этого коммутатора и в зависимости от наличия отправляемого обратно правила переходит либо 42 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 43. 8 Владислав Подымов, УльянаПопеско обратно в idle, либо в send. Срочная дуга send → idle присваивает переменной f ull[c] значение true и записывает в переменную канала выбранное правило. Автомат Ai моделирует работу коммутатора comi и состоит из обычных состояний start, select, hit, miss, mod, соединенных через срочные вершины. Срочная дуга start → select записывает в локальные переменные автомата доставленный через канал c пакет и порт, на который он пришел, и записывает в переменную f ull[c] значение f alse. Состояние select, помеченное imp инвариантом t ≤ Ri , имеет одну исходяющую дугу в срочное состояние l, помеченную предусловием t ≥ Limp . Здесь t — локальный таймер комi мутатора. Из состояния l в зависимости от наличия шаблона происходит переход в состояния hit и miss с модификацией таблицы согласно правилам 2-5 семантики ПКС. Удаление многих правил из таблицы коммутации обеспечивается срочной вершиной l с петлей, удаляющей из таблицы истекшие правила, и исходящей дугой, помеченной предусловием, утверждающим, что из таблицы удалены все истекшие правила. Срочная дуга start → mod записывает в локальные переменные автомата правило, доставленное каналом def cf rom con . Состояние mod помечено инвариантом t ≤ Ri , исходящие из него i def дуги — предусловием r ≥ Li . В зависимости от того, заполнена ли таблица коммутации, из состояния mod автомат может либо перейти в состояние start, либо перейти в состояние hit с записью правила в таблицу. 6 Корректность алгоритма трансляции Под корректностью алгоритма Alg понимается равновыполнимость формул, используемых в средстве UPPAAL, для исходной ПКС N и результирующей сети Alg(N ). Ключевым понятием в доказательстве корректности алгоритма Alg является эквивалентность по прореживанию (stuttering equivalence) для систем переходов [6]. Неформально, такая эквивалентность означает, что если в каждом вычислении двух данных систем склеить все одинаковые состояния, то мы получим одинаковые множества вычислений. Одинаковыми полагаются состояния с совпадающими множествами выполнимых формул. В работе [7] сформулирована следующая теорема. Теорема 1 Если системы переходов M1 , M2 эквивалентны по прореживанию и формула Φ логики LT L−X истинна для M1 , то она также истинна для M2 . Следующая теорема позволяет применить только что сформулированную к системам переходов, описывающим поведение ПКС N и сети Alg(N ). Система переходов, описывающая поведение сети временных автоматов, обсуждается, например, в [4]. Пусть T SA — система переходов, описывающая поведение системы A. Теорема 2 Пусть N — произвольная ПКС. Тогда системы переходов T SN и T SAlg(N ) эквивалентны по прореживанию. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 43
- 44. Верификация ПКС припомощи системы UPPAAL 9 Теорему обосновывают следующие рассуждения. Состояниям контроллера и коммутаторов ставятся в соответствие одноименные состояния получающихся из них автоматов вместе с необходимыми значениями локальных переменных. Состояниям каналов ставятся в соответствие наборы значений переменных f ull, ready и переменных для хранения данных. Одному применению семантических правил 1-17 соответствует последовательность переходов в сети временных автоматов через срочные состояния, и смена значений переменных происходит только в одном месте последовательности. В результате применения правила в ПКС и построенной по нему последовательности переходов в сети соответствующие состояния переводятся в соответствующие. Корректность алгоритма напрямую следует из приведенных теорем с учетом того, что формулы, проверяемые средством UPPAAL, могут быть переформулированы в терминах логики LT L−X . 7 Экспериментальное исследование В приложении приведена сеть автоматов, построенная транслятором по описанию сети на рисунке 1. Ниже приведены проверенные с помощью средства UPPAAL свойства и их запись на языке запросов UPPAAL [3]. 1. В работе системы не возникает блокировки: A[] not deadlock 2. В сеть всегда будут поступать пакеты из внешней среды: A <> f orall(num : int[0, 2]) (channel_h[stream.align[num]]) 3. Допустим сценарий работы сети, в котором коммутатор не принимает ни одного пакета: E[] com1.start 4. При любом сценарии работы сети контроллер обработает хотя бы один пакет: E <> !con.idle 5. Хотя бы один пакет будет успешно перенаправлен коммутатором (т.е. коммутатор выполняет свою главную функцию): E <> com1.hit Свойства 1,2,4,5 соответствуют спецификации сетей OpenFlow, в то время как свойство 3 является недопустимым. Проверка показала, что свойства 1,2,4,5 выполняются, а свойство 3 не выполняется. Это свидетельствует о том, что функционирование полученной сети временных автоматов соответствует нашим ожиданиям и что предложенная схема верификации ПКС 44 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 45. 10 Владислав Подымов, УльянаПопеско с помощью средства UPPAAL позволяет проверять свойства поведения ПКС как системы реального времени. В ячейках таблицы 1 представлено время проверки описанных темпоральных свойств для некоторых моделей ПКС: 1 – три коммутатора в топологии кольца (рисунок 1); 2 – четыре коммутатора в топологии звезды; 3 – четыре коммутатора в произвольной топологии; 4 – два коммутатора с изначально пустыми таблицами коммутации. Проверка проводилась на вычислительном устройстве со следующими характеристиками: INTEL Core i7 3820/1600 МГц/2Гб DDR3. Первое свойство не было проверено на моделях 1–3 в связи с нехваткой памяти. Таблица 1. Время проверки свойств ПКС. Модель Модель Модель Модель 8 1 2 3 4 1 27 часов 1 1 1 1 2 секунда секунда секунда секунда 1 1 1 1 Свойство номер: 3 4 5 секунда 7 секунд 1 секунда секунда 1 минута 2 секунды 1 минута 25 секунд секунда 1 минута 1 минута 19 секунд секунда 1 секунда 1 секунда Заключение В результате проведенных исследований мы подтвердили практическую осуществимость подхода, предложенного в статье [5], для проверки выполнимости свойств поведения моделей программно-конфигурируемых сетей в реальном времени. Предложенное нами средство анализа поведения ПКС может быть использовано для наглядного описания конфигурации и коммутационной политики сети в виде диаграмм. Разработанный нами алгоритм трансляции преобразует диаграмму в сеть временных автоматов, подаваемую на вход системы верификации UPPAAL. Корректность алгоритма трансляции строго обоснована, транслятор реализован на языке программирования Perl. Получаемая на выходе транслятора сеть временных автоматов позволяет проверять спецификации ПКС с помощью системы UPPAAL. Особенностью такой верификации является возможность учитывать временной аспект поведения ПКС как распределённых систем реального времени. Список литературы 1. Casado M., Garfinkel T., Akella A., Fredman M., Boneh D., McKeown N., Shenker S. SANE: A Protection Architecture for Enterprise Networks // 15-th Usenix Security Symposium, Vancouver, Canada, August 2006. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 45
- 46. Верификация ПКС припомощи системы UPPAAL 11 2. McKeown N., Anderson T., Balakrishnan H., Parulkar G., Peterson L., Rexford J., Shenker S., Turner J. Openflow: Enabling innovation in campus network // SIGCOMM Computer Communication Review, 2008, v.38, n.2, p.69-74. 3. Behrmann G., David A., Larsen K. A tutorial on Uppaal // Lecture Notes in Computer Science, 2004, v.3185, p.200-236. 4. Alur R., Dill D. Automata for modeling real-time systems // Proc. of Int. Colloquium on Algorithms, Languages, and Programming, LNCS, 1990, v.443, p.322-335. 5. Волканов Д.Ю., Захаров В.А., Зорин Д.А., Коннов И.В., Подымов В.В. Как разработать простое средство верификации систем реального времени // Моделирование и анализ информационных систем, 2012, Том 19, №6, с.45–56. 6. Browne M.C., Clarke E.M., Grumberg O. Characterizing finite Kripke structures in propositional temporal logics // Theor. Comp. Sci., 1988, v.59(1-2), p.115-131. 7. Clarke E.M., Grumberg O., Peled D. Model Checking. The MIT Press. 1999. Приложение Сеть временных автоматов, полученная в результате трансляции из ПКС, изображенной на рисунке 1, приведена на рисунках 2–4. В целях удобочитаемости выражения автоматов написаны в синтаксисе, отличном от синтаксиса UPPAAL и при этом более простом для восприятия. Запись вида (i = 1..3, 5, 7) означает перебор всех i из заданного диапазона и создание копий дуги для каждого значения i. Запись вида (i = 1..3 → Φ) означает “для всех i из заданного диапазона верна формула Φ”. Функция get(c) сохраняет содержимое канала c в локальные переменные (h, p, . . .) и выполняет присваивание c = f alse. Функция send(c, o) копирует o в содержимое канала и выполняет присваивания c = true, c_ready = f alse, c_t = 0. Функция set_rule(i) копирует локальные переменные коммутатора, отвечающие компонентам правила, в i-ю позицию таблицы. Предикат to_deliver(c) описывается как c && !c_ready && (c_t ≥ c_L). Предикат ok(c) описывается как !c || c_ready || (c_t ≤ c_R). Канал c[0] выделен под окружение, каналы c[1], c[2], c[3] — под потоки, прикрепленные к соответствующим коммутаторам. Автоматы A2 , A3 отличаются от автомата A1 только номерами задействованных каналов и константами, определяемыми количеством портов и объемом таблицы, и по этой причие опущены. 46 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 47. 12 Владислав Подымов, УльянаПопеско (i = 0..2) hurry! idle to_con_ready[i] get(to_con[i]), c = i i = 0..2 -> !hit(rule[i], (c, p, h)) !con_in[c] hurry! send(from_con[c], rule[r]) (i = 0..2) hit(r[i], (c, p, h)) r=i s1 send (i = 1..3, num = 1..3) !c[num] hurry! send(c[num], i) Рис. 2. Автоматы Acon (слева), Stream (справа). from_con[0] hurry! get(from_con[0]), t=0 (i = 0..3) (t >= 2) && !active[i] set_rule(i) rewrite t <= 3 i = 1..3 -> active[i] !c[r] hurry! send(c[r], h) hit start t >= 3 (i = 1,4,5) select c_ready[i] t <= 5 hurry! get(c[i]), p = i, t = 0 (i = 0..3) hit(rule[i]) r=i rule_t[r] < rule_max[r] rule_t[r] >= rule_max[r] active[r] = false miss i = 0..3 -> !hit(rule[i]) i = 0..3 -> !active[i] || (rule_t[i] <= rule_max[i] ) (i = 0..3) active[i] && (rule_t[i] > rule_max[i]) active[i] = false i = 0..3 -> active[i] i = 0..3 !active[i] hurry! send(to_con[0], (p, h)) Рис. 3. Автомат A1 . s1 hurry? c[0] hurry! c[0] = false (i = 0..2) to_deliver(to_con[i]) to_con_ready[i]) s1 (i = 1..9) to_deliver(c[i]) c_ready[i] (i = 0..2 -> ok(to_con[i])) && (i = 1..9 -> ok(c[i])) Рис. 4. Автоматы Hurry (слева), Env (в центре), Chan (справа). Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 47
- 48. ⋆ ⋆ 48 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 49. P S = (S,s0 , →, L) s0 ∈ S L : S → 2P S →⊆ S × S s0 π = s0 s1 s2 . . . ∀i≥0 si → si+1 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 49
- 50. pi ∈ P ϕ,ψ ::= true | p0 | p1 | . . . | pn | ¬ ϕ | ψ ∧ ϕ | Xϕ | ψ U ϕ | F ϕ | G ϕ. X F G ϕ U Gϕ Xϕ Fϕ ϕ ϕ ψU ϕ ϕ ψ F G F ϕ = true U ϕ G ϕ = ¬F ¬ϕ ∨ ϕ ϕ 50 ⇒ s0 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 51. V V (1) G X( V> V ⇒ OldValCond ∧ FiringCond ∧ V = NewValExpr ) V V V OldValCond FiringCond NewValExpr V V V X FiringCond OldValCond FiringCond V NewValExpr OldValCond V (1) ⇒ OldValCond i ∧ FiringCond i ∧ V = NewValExpr i V G X( V < V ⇒ OldValCond ′ ∧ FiringCond ′ ∧ V = NewValExpr ′ ) (1′ ) Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 51
- 52. (1) (1′ ) V (2) G X(¬ V ∧ V ⇒ FiringCond ) V (2′ ) G X( V ∧ ¬V ⇒ FiringCond ′ ) ′ (1) (1 ) V FiringCond = FiringCond ′ = 1 NewValExpr = NewValExpr ′ OldValCond = ( V < NewValExpr ) OldValCond ′ = ( V > NewValExpr ) G X( V > V ⇒ V < NewValExpr ∧ V = NewValExpr ) G X( V < V ⇒ V > NewValExpr ∧ V = NewValExpr ) (3) G X( V = NewValExpr ) (1) V (2) ′ (1 ) (2′ ) (3) V (3) NewValExpr V 52 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 53. (V ) =1 V V+ (1) OldValCond OldValCond ′ V (1′ ) V− V := NewValExpr V := NewValExpr ′ FiringCond FiringCond ′ V+ V− V OldValCond i ∧ FiringCond i ∧ V = NewValExpr i V V V V + (2) V − (2′ ) V := 1 V := 0 FiringCond FiringCond ′ V+ V− V (3) V := NewValExpr V V V V := V Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 53
- 54. V V V V =0 V =1 V(1) ∼ (1′ ) V + G( X(V > V ) ⇒ X(OldValCond ) ∧ X(FiringCond ) ∧ X(V = NewValExpr )) V − G( X(V < V ) ⇒ X(OldValCond ′ ) ∧ X(FiringCond ′ ) ∧ X(V = NewValExpr ′ )) X V 54 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 55. OldValCond OldValCond ′ FiringCond FiringCond ′ V ∼V V FiringCond FiringCond′ (2′ ) (2) (3) V := V NewValExpr NewValExpr ′ V := 1 V := 0 V := V V V V := V := V := V NewValExpr NewValExpr X G( V = NewValExpr ) V = NewValExpr G( V = NewValExpr ) X G( V = NewValExpr ) V V := NewValExpr Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 55
- 56. 56 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 57. Последний ход: Ход 0 0 4 4 4 4 4 Старт 1 2 3 4 5 Победа 4 6 Игрок ПЛК Игрок ПЛК Международная научно-практическаяконференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 57
- 58. Входы Кнопки Кнопка 1 PB1 ПЛК Выходы ход поцифре 1 1 выбрана цифра 1 1 ход по цифре 2 2 Кнопка 2 PB2 выбрана цифра 2 Кнопка 3 PB3 выбрана цифра 3 ход по цифре 3 2 3 ход по цифре 4 4 3 ход по цифре 5 5 Кнопка 4 PB4 выбрана цифра 4 ход по цифре 6 4 6 Лампы Лампа 1 Out1 Лампа 2 Out2 Лампа 3 Out3 Лампа 4 Out4 Лампа 5 Out5 Лампа 6 Out6 выбрана цифра 6 Старт PBStart Ход игрока Ход ПЛК Turn победил игрок выбрана цифра 5 Кнопка 6 PB6 право хода у игрока право хода у ПЛК Кнопка 5 PB5 Игрок ManWin ПЛК PLCWin начать игру заново 5 7 7 6 8 победил ПЛК 7 9 58 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 59. V1 V2 V3V4 V5 V6 Sum Mv1 Mv2 Mv3 Mv4 Mv5 Mv6 Mv Lck Rst Skp G(¬PLCWin ∨ ¬ManWin) Sum G(Sum ≤ 37) G(Mv1 +Mv2 +Mv3 +Mv4 +Mv5 +Mv6 ≤ 1) PBStart G(PBStart ⇒ V1 = 4∧V2 = 4∧V3 = 4∧V4 = 4∧V5 = 4∧V6 = 4∧¬Mv ∧ ¬Turn ∧ ¬(P LCW in ∨ M anW in) ∧ Sum = 0) G(F(Mv )) ⇒ G(F(PLCWin ∨ManWin ∨PBStart )) PBStart G(F(Mv )) ∧ G(¬PBStart ∧X(PBStart ) ⇒ (PLCWin ∨ManWin)) ⇒ G(PBStart ∧X(¬PBStart ) ⇒ X(¬PBStart U (PLCWin ∨ ManWin))) Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 59
- 60. G(F(Mv)) ∧ G(¬PBStart∧ X(PBStart ) ⇒ (PLCWin ∨ ManWin)) ⇒ G(Mv3 ∧ Sum = 3 ⇒ ((¬ManWin ∧ ¬PLCWin) U PLCWin)) G(F(Mv)) ∧ G(¬PBStart ∧ X(PBStart ) ⇒ (PLCWin ∨ ManWin)) ⇒ G(Mv4 ∧ Sum = 4 ⇒ ((¬ManWin ∧ ¬PLCWin) U PLCWin)) G(F(Mv)) ∧ G(¬PBStart ∧ X(PBStart ) ⇒ (PLCWin ∨ ManWin)) ⇒ G(Mv6 ∧ Sum = 6 ⇒ ((¬ManWin ∧ ¬PLCWin) U PLCWin)) G(X(Mv1 ∧ Sum = 1 ∨ Mv2 ∧ Sum = 2 ∨ Mv3 ∧ Sum = 3 ∨ Mv4 ∧ Sum = 4 ∨ Mv5 ∧ Sum = 5 ∨ Mv6 ∧ Sum = 6) ⇒ ¬Turn) 60 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 61. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 61
- 62. 62 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 63. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 63
- 64. 64 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 65. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 65
- 66. На пути ктехнологии разработки средств дедуктивной верификации программ⋆ Игорь Ануреев Институт систем информатики имени А.П. Ершова anureev@iis.nsk.su Аннотация Статья представляет подход к разработке средств дедуктивной верификации программ. Основой подхода является предметно-ориентированный язык для данной предметной области. Сформулированы требования к такому языку и дано обоснование использования языка спецификации предметно-ориентированных систем переходов Atoment в качестве возможного кандидата. Особенности применения подхода и принципы, на которых он основан, проиллюстрированы на простых примерах. На базе подхода предполагается создать технологию разработки средств дедуктивной верификации программ. Ключевые слова: дедуктивная верификация программ, предметно-ориентированный язык, предметно-ориентированные системы переходов, операционная семантика, аксиоматическая семантика, денотационная семантика, логика безопасности, язык Atoment 1 Введение В статье предлагается предметно-ориентированный подход к разработке средств дедуктивной верификации программ (далее дедуктивных верификаторов). Термин «предметная ориентированность» применительно к подходу может иметь два значения. В первом случае, он означает ориентированность на предметную область, к которой применяется дедуктивная верификация. Во втором случае, он означает ориентированность на саму область разработки средств дедуктивной верификации программ. Мы рассматриваем предметную ориентированность во втором значении. Прежде чем описывать подход, определим необходимые термины этой предметной области и дадим классификацию существующих подходов к разработке средств дедуктивной верификации программ. Дедуктивный верификатор применяется к аннотированной программе на некотором целевом языке программирования. Аннотированная программа на этом языке — это текст, построенный по определенным правилам ⋆ 66 Работа частично поддержана грантом РФФИ 11-01-00028-а и междисциплинарным интеграционным проектом СО РАН № 3 «Принципы построения онтологии на основе концептуализаций средствами логических дескриптивных языков». Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 67. из конструкций целевогоязыка и аннотаций. Аннотации описывают свойства программы на целевом языке. Аннотированная программа называется корректной, если эти свойства выполняются. Обычно в качестве языка аннотаций используется некоторый логический язык. Задача дедуктивного верификатора — доказать корректность аннотированной программы или указать условия, при которых выполнение этой программы некорректно. Дедуктивный верификатор рассматривает аннотированную программу как формулу некоторого логического исчисления (называемого аксиоматической семантикой в контексте дедуктивной верификации) и преобразует ее в наборы формул некоторого логического языка в соответствии с определенной стратегией логического вывода в этом исчислении таким образом, что из истинности полученных в результате преобразования формул (называемых условиями корректности этой программы) следует корректность самой программы. Для доказательства условий корректности дедуктивный верификатор применяет разного рода средства автоматической поддержки доказательства (универсальные средства автоматического или интерактивного доказательства такие, как, например, PVS или HOL; SAT-решатели, SMT-решатели и др.). Применительно к задаче дедуктивной верификации будем называть эти средства решателями условий корректности. В качестве логического исчисления в дедуктивных верификаторах обычно используется логика Хоара или ее расширения. Инструменты, базирующиеся на логике отделимости (separation logic) и исчислении синонимов (alias calculus), также можно отнести к дедуктивным верификаторам в случае, если эти инструменты базируются на некотором виде аксиоматической семантики. Опишем, как выглядит процесс разработки дедуктивного верификатора. Сначала разрабатывается концепт дедуктивного верификатора. Его разработка включает выбор целевого языка, языка аннотаций, аксиоматической семантики, методов оптимизации условий корректности, решателя условий корректности и т. д. После того, как он разработан, можно выделить три подхода к его реализации. В первом подходе дедуктивный верификатор разрабатывается напрямую на некотором языке программирования общего назначения. Единственным достоинством этого подхода является большая степень свободы в оптимизации разрабатываемого верификатора. Эта степень ограничена только уровнем компетенций разработчика. Отметим недостатки подхода. Во-первых, при этом подходе высока сложность разработки, поскольку снижается уровень абстракции при переходе от концепта к реализации. Во-вторых, по той же причине, обоснование корректности верификатора представляет сложную проблему. В-третьих, верификатор не является гибким, поскольку ориентирован на конкретные целевой язык, язык аннотаций и аксиоматическую семантику. Во втором подходе аннотированная программа транслируется в программу на промежуточном языке, для которого уже имеются дедуктивные веМеждународная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 67
- 68. рификаторы. Дополнительно кразработке транслятора из целевого языка в промежуточный язык, также разрабатываются средства обратной связи, которые интерпретируют результаты, полученные при верификации программы на промежуточном языке, в контексте исходной аннотированной программы. Как и в первом подходе, транслятор и средства обратной связи реализуются на некотором языке программирования общего назначения. Примерами промежуточных языков, ориентированных на дедуктивную верификацию, являются Boogie [1] и WhyML [2]. Этот подход имеет следующие преимущества. При его реализации знания конкретной аксиоматической семантики не требуется или требуется лишь в малой степени на уровне пользования дедуктивными верификаторами, имеющимися для промежуточного языка. Фактически разработка дедуктивного верификатора для целевого языка состоит в разработке транслятора и требует лишь знания операционной семантики целевого и промежуточного языков и (статической) семантики используемого языка аннотаций. Недостатки второго подхода проявляются прежде всего в случае, когда промежуточный язык сильно отличается от целевого языка. Во-первых, обоснование корректности трансляции становится сложной задачей. Во-вторых, усложняется разработка средств обратной связи. В-третьих, при трансляции теряется структурная и семантическая информация, которая могла бы оптимизировать генерацию условий корректности. Эта потеря, например, может быть результатом трансляции структур данных целевого языка в структуры данных промежуточного языка или результатом моделирования конструкций целевого языка конструкциями промежуточного языка. Помимо этого, разрабатываемый верификатор не является гибким, поскольку ориентирован на конкретные целевой язык, язык аннотаций и дедуктивные верификаторы, имеющиеся для промежуточного языка. Формат обратных связей, как правило, также не гибок. В третьем подходе аннотированная программа транслируется в модель или теорию системы машинной поддержки доказательства (далее доказателя). К доказателям, используемым в дедуктивном подходе, относятся PVS, HOL, LCF2 и др. Можно выделить следующие преимущества этого подхода. Во-первых, доказатели, как правило, основаны на логиках высшего порядка, что позволяет использовать выразительные языки аннотаций в дедуктивных верификаторах. Во-вторых, доказатели используют продвинутые техники доказательства для формул этих логик. В-третьих, эти техники можно применять не только к доказательству условий корректности, но и при порождении условий корректности, таким образом оптимизируя их вывод. Отметим недостатки третьего подхода. Во-первых, доказатели сложны в освоении. Во-вторых, разработка модели или теории также сложна. В-третьих, доказательство условий корректности ограничено конкретным доказателем, в который вкладываются аннотированные программы. В-четвертых, возникает непростая проблема доказательства соответствия модели аннотированной программе. В-пятых, модель аннотированной программы, как правило, не использует дополнительную информацию, доступ- 68 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 69. ную при компиляцииэтой программы, так как учитывание этой информации усложнило бы модель и сделала бы ее непригодной на практике. Предлагаемый нами подход нивелирует недостатки описанных подходов, сохраняя их преимущества, и может быть в дальнейшем развит в технологию разработки дедуктивных верификаторов. Он заключается в использовании предметно-ориентированного языка (далее ПОЯ) для разработки дедуктивных верификаторов. 2 Требования к предметно-ориентированному языку Опишем требования, которые должны выполняться для ПОЯ. Набор этих требований не претендует на полноту и скорее является квинтэссенцией опыта, накопленного авторами в области дедуктивной верификации. Требование 1. ПОЯ должен описывать объекты, которыми обычно оперирует дедуктивный верификатор. К ним относятся аннотированные программы, состояния программ, правила дедуктивного вывода (аксиоматической семантики) и стратегии их применения, условия корректности, интерфейсы к решателям условий корректности. Далее будем называть эти объекты объектами верификации. Требование 2. Форматы описания объектов верификации на ПОЯ должны быть унифицированными для каждого типа объектов, т. е. не зависеть от конкретных используемых в дедуктивном верификаторе языков программ, аннотаций, правил и стратегий дедуктивного вывода, условий корректности и решателей условий корректности. Тем самым, обеспечиваются перечисленные выше преимущества второго и третьего подходов, обусловленные трансляцией. Будем называть результаты трансляции объектов верификации в ПОЯ представлениями или образами этих объектов. Требование 3. Представления объектов верификации на ПОЯ должны быть структурно эквивалентными соответствующим им объектам. Структурная эквивалентность означает существование взаимно-однозначного отображения между объектами и их представлениями на уровне структуры объектов и, соответственно, структуры представлений. Тем самым нивелируются недостатки второго и третьего подходов, обусловленные трансляцией. Во-первых, упрощается разработка транслятора объектов конкретного языка в их представления на ПОЯ. Во-вторых, при такой трансляции не теряется информация. В-третьих, упрощается разработка средств обратной связи (перехода от представлений объектов к самим объектам). Требование 4. Для текстовых объектов верификации (объектов, являющихся текстами) представления объектов на ПОЯ должны быть текстуально близкими к соответствующим им объектам. Текстуальная близость означает, что представления объектов по возможности должны выглядеть похожими на сами объекты. В частности, они должны использовать такие же ключевые слова и размещать их в том же самом порядке. В этом случае достигается читабельность и понимание представлений объектов, сравнимые с читабельностью и пониманием самих текстовых объектов. Это требоМеждународная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 69
- 70. вание конфликтует стребованием 2, поэтому должен быть найден разумный компромисс. Требование 5. Представления объектов верификации на ПОЯ должны быть концептуально близкими к соответствующим им объектам. Концептуальная близость означает, что представления используют ту же самую концептуальную структуру (понятия, атрибуты понятий, отношения между понятиями), что и объекты. Так семантические сущности, описывающие состояния программ на современных языках программирования, имеют сложную концептуальную структуру, которую важно точно отражать на уровне представлений соответствующих объектов. Требование 6. ПОЯ должен описывать средства оперирования с представлениями объектов, сооветствующие средствам, которые дедуктивный верификатор использует для оперирования объектами верификации. Их можно разделить на базовые и дополнительные. К базовым относятся средства, необходимые для выполнения дедуктивной верификации, к дополнительным — средства, которые оптимизируют этот процесс. Базовые средства включают средства взаимодействия с объектами через их представления и средства выполнения правил и стратегий дедуктивного вывода на представлениях объектов. Средства взаимодействия включают трансляторы аннотированных программ конкретных целевых языков в их представления на ПОЯ, средства построения обратных связей, средства взаимодействия с решателями условий корректности и т. д. Средства выполнения (интерпретации) правил и стратегий дедуктивного вывода, задаваемых в унифицированном формате на ПОЯ, позволяют реализовывать дедуктивные верификаторы, для которых эти правила и стратегии являются параметрами. Дополнительные средства оперируют с представлениями объектов, и могут, например, включать средства комбинации дедуктивных верификаторов, средства трансформации аннотированных программ, средства комбинирования решателей условий корректности и средства трансформации условий коректности. Средства трансформации представлений целевых программ позволят комбинировать операционный и аксиоматический подходы к верификации программ. Предварительное преобразование представления (операционный подход) может упростить последующий вывод условий корректности в аксиоматической семантике. В частности, трансформации могут собирать информацию о программе, которая обычно собирается алгоритмами статического анализа или на этапе ее компиляции. Эта информация может быть использована для оптимизации вывода условий корректности. Так как решатели условий корректности — узкое место современных дедуктивных верификаторов, средства трансформации условий корректности повышают возможности таких верификаторов. Эти средства позволяют делать предобработку условий корректности и передавать решателю упрощенные условия корректности. При использовании нескольких решателей, они могут также распределять фрагменты условий корректности наиболее подходящим для их доказательства решателям. Кроме того, такие средства 70 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 71. могут быть использованонепосредственно для реализации простых решателей. Требование 7. ПОЯ должен содержать развитый механизм сопоставления с образцом как на уровне синтаксической структуры (требования 3 и 4), так и на уровне концептуальной структуры (требование 5) представлений объектов. Сопоставление такого рода характерны для большинства средств оперирования представлениями объектов, перечисленных в требовании 6. Требование 8. ПОЯ должен обеспечивать средства описания смысла конструкций целевого языка (операционной семантики целевого языка). Это требование необходимо для формального обоснования корректности разрабатываемого дедуктивного верификатора. 3 Использование языка Atoment в качестве ПОЯ Язык Atoment [3] — результат наших исследований по автоматизации создания операционной и аксиоматической семантик языков программирования. В процессе его разработки возникла концепция предметно-ориентированного подхода к дедуктивной верификации и были сформулированы требования к ПОЯ для этой предметной области. Он не является идеальным кандидатом на роль ПОЯ, но обеспечивает компромиссные показатели по всем требованиям к ПОЯ и при отсутствии на данный момент других подходящих языков мы планируем использовать его для апробации этого подхода. Язык Atoment обеспечивает описание объектов верификации (требование 1). Он использует два унифицированных формата для представлений объектов (требование 2), соответствующих текстовых и нетекстовым объектам. Текстовые объекты представляются выражениями языка Atoment. Выражения — это унифицированная форма записи конструкций языка Atoment, подобная спискам языка Лисп. Выражения строятся из атомов с помощью специальных символов, к которым относятся пробельные символы и круглые скобки. Например, ab и (ab (cd ef) gh) — выражения. Атомом может быть любая последовательность Unicode символов, не содержащая специальных символов и символа кавычек ("). Специальный вид атомов — строки позволяют использовать в атоме специальные символы. Например, ab и "ab ("ss)" — атомы. Требование 3 для текстовых объектов обеспечивается взаимно-однозначным соответствием между их структурой и структурой выражений, представляющих эти объекты. Рассмотрим, как обеспечивается выполнение требования 4 для текстовых объектов на примере представления конструкций целевого языка и языка условий корректности. Ключевые слова целевого языка представляются атомами. Для условного оператора if A then B else C ключевые слова представляются атомами if, then и else. Сам оператор представляется выражением (if A′ then B′ else C′ ), где A′ , B′ , C′ — представления конструкций A, B, C целевого языка. Условия корректности, как и любые другие формулы, также представляются выражениями. Так наиболее близким представлением формулы Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 71
- 72. ∀x((a ≤ x)∧ (y ≤ b)) является выражение (∀ x ((a ≤ x) ∧ (y ≤ b))). Обычно для удобства ввода вместо этого выражения используется выражение (forall x ((a <= x) and (x <= b))). Нетекстовые объекты представляются конечными наборами символов языка Atoment, а их (как правило, концептуальная) структура — состояниями в языке Atoment. Символы в языке Atoment — это выражения вида (A), где A — последовательность атомов. Состояние в языке Atoment — это отображение, которое сопоставляет символам их интерпретацию (значение). Значением символа в состоянии являются функции заданной местности, сопоставляющие кортежу элементов элемент (Подобно тому, как атом является наименьшей синтаксической единицей языка Atoment, элемент является его наименьшей семантической единицей. Название Atoment является объединением двух слов — атом и элемент.). Местность этих функций совпадает с числом спецификаторов аргументов, входящих в символ. Спецификатор аргумента — это атом одного из видов +v или -v. Символы позволяют адекватно описывать концептуальную структуру (требование 5) семантических сущностей целевого языка. Например, переменная может быть представлена символами (-v is variable), (value of -v) и (type of -v). При таком представлении s(-v is variable)(x) = true, s(type of -v)(x) = int и s(value of -v)(x) = 2 означает, что переменная с именем x имеет тип int и значение 2 в состоянии s. Средства оперирования с представлениями объектов (требование 6), механизм сопоставления с образцом (требование 7) и средства описания операционной семантики целевого языка (требование 8) реализуются с помощью предметно-ориентированных правил перехода и контекстов их применения. Правило перехода — это выражение вида (if A var B P then C), где A, B, C — последовательности выражений, называемые образцом, спецификацией переменных образца и телом правила, соответственно, необязательная последовательность выражений P обозначает дополнительные параметры правила. Правила перехода суть средства трансформации конфигураций. Конфигурация на языке Atoment — это пара, состоящая из последовательности выражений (далее программы на языке Atoment) и состояния. Правило (if A var B P then C) применимо к конфигурации (D, s), если D имеет вид E A′ F и A′ удовлетворяет образцу A, т. е. получается из A заменой переменных образца из B на некоторые выражения или последовательности выражений (значения переменных образца). Результатом применения правила будет конфигурация (E C′ F, s′ ), где C′ — результат замены в C переменных образца их значениями. Контекст применения определяет, как получается s′ , может дополнительно модифицировать C′ и накладывать дополнительные условие на применимость правила. Контекст определяется видом правил перехода (операционные, дедуктивные, условные, онтологические и т. д.). Так средства выполнения (интерпретации) правил и стратегий дедуктивного вывода применительно к некоторой аннотированной программе описываются дедуктивными правилами перехода, а операционная семантика целевых языков — операционными правилами перехода. Рассмотрим пример применения правила. Операционное правило 72 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 73. (if (jump E)(break) var (+s E) then (jump E)) применимо к программе (jump goto L) (break) (x := 3) и преобразует ее в программу (jump goto L) (x := 3). Состояние при этом не меняется. Спецификатор +s перед переменной образца E, означает, что ее значением может быть (возможно пустая) последовательность выражений. Если бы его не было, значением E могло бы быть только выражение. Предметно-ориентированные системы переходов определяют операционную семантику выражений. Операционная семантика выражения U определяется множеством правил, образец которых включает выражение U′ такое, что U получается из U′ означиванием переменных образца. Таким образом, операционная семантика выражения определяется в контексте окружающих его выражений в программе на языке Atoment. Например, операционная семантика выражения (break) из примера выше определяется в контексте, когда этому выражению предшествует выражение (jump E′ ), где E′ — произвольная последовательность выражений. Комбинирование дедуктивных верификаторов и решателей условий корректности осуществляется за счет предопределенных выражений языка Atoment, описывающих основные структуры управления (последовательное выполнение, разбор случаев, бэктрекинг и др.). Операционная семантика предопределенных выражений задается напрямую, а не определяется правилами перехода. Для спецификации семантики формул (например, условий корректности) используется денотационная семантика выражений. Денотационная семантика выражений — это отображение, которое сопоставляет выражениям их значения, принадлежащие множеству элементов языка Atoment (денотату). Значением атома является сам атом. Значение выражения, отличного от атома, определяется семантикой символа, который является шаблоном для этого выражения. Так символ (+v + +v), интерпретируемый как операция сложения чисел, является шаблоном для выражения (2 + (3 + 4)) относительно сопоставленных аргументам выражений 2 и (3 + 4). Спецификатор аргумента +v означает, что в качестве значения аргумента берется значение сопоставленного выражения. Таким образом, значением выражения (2 + (3 + 4)) будет 9. Спецификатор аргумента -v означает, что в качестве значения аргумента берется само выражение. Этот спецификатор используется, например, в символе (forall -v -v), интерпретируемом как квантор всеобщности. 4 Применение предметно-ориентированного подхода Рассмотрим применение предметно-ориентированного подхода на примере разработки дедуктивного верификатора для целевого языка, включающего простые типовые конструкции языков программирования. Из-за недостатка места мы ограничимся только вопросами разработки операционной семантики и логики безопасности (варианта аксиоматической семантики) для этих конструкций. Несмотря на свою простоту, пример иллюстрирует несколько Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 73
- 74. ключевых особенностей, лежащихв его основе: инкрементальность разработки, использование вспомогательных конструкций, гибкость разработки, разрешение на месте побочных эффектов при дедуктивном выводе. Будем разрабатывать верификатор сразу для выражений, представляющих конструкции целевого языка, считая, что требования структурной эквивалентности и текстуальной и концептуальной близости удовлетворены. Рассмотрим оператор блока ({ A }), где A — последовательность операторов. Заметим, что такое представление близко к представлению этого оператора на ряде императивных языков программирования. Опишем сначала его операционную семантику. Первую версию семантики зададим правилом (if ({ A }) var (+s A) then A) В соответствии с этой семантикой выполнение оператора ({ A }) сводится к выполнению последовательности операторов A. Предположим теперь, что целевой язык содержит средства передачи управления (операторы посылки исключений, операторы break, continue, return и т. п.). В этом случае, такая семантика уже не подходит, поскольку оператор блока не должен выполняться, если перед ним произошла передача управления. Для описания этой ситуации введем понятие выражения перехода и концепцию просачивания выражения переходов. Выражение перехода имеет вид (jump E), где E — последовательность выражений, которые кодируют информацию о том, какой оператор перехода сработал, и какую информацию он передал. Например, для оператора (break) соответствующее выражение перехода может иметь вид (jump break). Зададим вторую версию семантики блока правилами (if ({ A }) var (+s A) then A) (if (jump E) ({ A }) var (+s E) (+s A) then A) Дополнительное второе правило обеспечивает просачивание выражения перехода через оператор блока. Последовательность выражений E хранит информацию, которая передается при переходе. Таким образом, мы фактически «программируем» операционную семантику конструкций целевого языка на специализированном языке высокого уровня, уточняя ее на каждом шаге итерации. Как будет показано ниже, аналогичным образом «программируются» правила и стратегии дедуктивного вывода. В этом заключается инкрементальность разработки верификатора. Эта версия, однако, не учитывает ситуацию, когда целевой язык включает операторы перехода по метке (goto L) и пустые помеченные операторы (label L), оператор (label L) входит в A и в результате выполнения блока порождается выражение перехода (jump goto L). В этом случае, выполнение должно быть продолжено с оператора (label L) последовательности A, а в соответствии с текущей семантикой блока выражение перехода (jump goto L) будет просачиваться дальше за блок. Третья версия семантики блока определяется правилами (if ({ A }) var (+s A) then A (gotoStop A)) (if (jump E) ({ A }) var (+s E) (+s A) then A) 74 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 75. Вспомогательное выражение (gotoStopA) обрабатывает выражение перехода (jump goto L) в случае, когда оператор (label L) принадлежит A: (if (gotoStop A) var A then) (if (jump E) (gotoStop A) var (+s E) (+s A) then (matchCases (jump E) (if (jump goto L) var L then (matchCases (A) (if (B (label L) C) var (+s B) (+s C) then C (gotoStop A)) (else (jump E)))) (else (jump E)))) Предопределенное выражение matchCases выполняет разбор случаев в соответствии с образцом. Сначала оно формирует сопоставляемое выражение. В правиле выше это выражения (jump E) и (A) для первого и второго вхождения matchCases, соответственно. Затем для каждой ветви (if U var V then W) оно выполняет сопоставление сформированного выражения с образцом U для спецификации переменных образца V таким же образом, как для правила перехода. Первая подходящая ветвь выполняется таким же образом, как правило перехода. Если ни одна из ветвей не подошла, и matchCases содержит выражение (else W), то выполняется последовательность W. В противном случае, с помощью механизма бектрекинга выполняется откат к предыдущей точке ветвления. Эта версия операционной семантики для оператора блока иллюстрирует использование вспомогательных конструкций. Чтобы адаптировать правила операционной семантики, мы не меняем их, а добавляем вспомогательную конструкцию, которая специфицирует требуемую адаптацию, и для нее описываем операционную семантику. Соответствующие вспомогательные конструкции используются и при описании аксиоматической семантики. Рассмотрим теперь, как с помощью правил перехода описываются правила и стратегии дедуктивного вывода. Особенностью нашего подхода является то, что вместо логики Хоара используется ее расширение — логика безопасности, предложенная в [4]. В логике Хоара ключевыми понятиями являются точки входа и выхода, которым соответствуют пред- и пост-условия. В ряде расширений логики Хоара допускается несколько точек входа и выхода. В логике безопасности точек входа и выхода нет, и, соответственно, нет предусловия и постусловия. Вместо этого ряд точек программы снабжаются так называемыми условиями безопасности. Программа корректна в логике безопасности (безопасна), если при любом исполнении программы, если достигнута точка программы с условием безопасности, то это условие должно быть истинно. Таким образом, логику безопасности можно применять к программам без явных точек входа или выхода, например операционным системам или телекоммуникационным протоколам. Важное свойство нашего подхода, являющееся одним из его преимуществ, заключается в том, что для многих конструкций целевого языка правила логики безопасности структурно не отличаются от правил операционной семантики. Таким образом, разработав операционную семантику Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 75
- 76. целевого языка, мыавтоматически получаем большую часть правил логики безопасности этого языка. Также в силу идентичности правил логики безопасности и операционной семантики доказательство корректности правил логики безопасности становится более простой задачей. Рассмотрим правила логики безопасности для блока, соответствующие последней третьей версии операционной семантики: (if ({ A }) var (+s A) then A (gotoStop A)) (if (jump E) ({ A }) var (+s E) (+s A) then A) Таким образом, правила логики безопасности и операционной семантики для блока совпадают. Однако логика безопасности для вспомогательного выражения (gotoStop A) меняется, поскольку в ней используется, как и в логике Хоара, инвариант метки: (if (gotoStop A) var A then) (if (jump E) (gotoStop A) var (+s E) (+s A) then (matchCases (jump E) (if (jump goto L) var L then (matchCases (A) (if (B (label L inv I) C) var (+s B) (+s C) I then (assert I)) (else (jump E)))) (else (jump E)))) Выражение I в помеченном операторе (label L inv I) соответствует инварианту метки L, т. е. I — условие безопасности, которое должно быть истинным при любом достижении этого оператора. Предопределенное выражение (assert I) добавляет условие безопасности I в соответствующую точку. Побочные эффекты затрудняют применение логики Хоара. Например, чтобы применить классическое правило логики Хоара к условному оператору (if A then B else C), требуется, чтобы условие A не имело побочных эффектов (не меняло состояние программы). В нашем подходе такой проблемы не возникает и условие A может иметь побочные эффекты, поскольку побочные эффекты не только в операционной семантике, но и в логике безопасности, разрешаются на месте. Правила операционной семантики для условного оператора имеют вид: (if (if A then B else C) var A (+s B) (+s C) then A (cases (if ((val) = true) then B) (else C))) (if (jump E) (if A) var (+s E) (+s A) then (jump E)) Предопределенное выражение cases выполняет разбор случаев. Выполняется первая ветвь (if U then V), для которой значение (денотационная семантика) выражения U равна true. Выполнение ветви заключается в выполнении последовательности выражений V. Если ни одна из ветвей не выполняется и cases содержит выражение (else W), то выполняется последовательность W. В противном случае, с помощью механизма бектрекинга выполняется выполняется откат к предыдущей точке ветвления. 76 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 77. Как видно изпервого правила, сначала вычисляется выражение A. Если при его вычислении происходят побочные эффекты, то они описываются правилами для соответствующих подвыражений выражения A. Результат вычисления выражения A сохраняется в нульместном символе (val). Затем выполняется сравнение значения этого символа с true или false. Второе правило просачивает выражение перехода через условный оператор. Правила логики безопасности для условного оператора совпадают с правилами операционной семантики. Однако операционная семантика ряда предопределенных выражений, например cases, отличается для контекстов применения, соответствующих операционным и дедуктивным правилам перехода [3]. 5 Заключение В заключение, ответим на вопрос, зачем разрабатывать универсальный поход к созданию верификаторов, когда существующие дедуктивные верификаторы для конкретных языков программирования нуждаются в существенном улучшении. Во-первых, предлагаемый подход является предметноориентированным, что означает, что он предоставляет средства, позволяющие в полной мере учитывать особенности целевых языков программирования и используемых методов и техник дедуктивной верификации. Вовторых, технология быстрой предметно-ориентированной разработки дедуктивных верификаторов может оказаться востребованной, когда для целевого языка не существует средств дедуктивной верификации. В-третьих, существующие дедуктивные верификаторы представляют собой черные ящики, что не позволяет, например, улучшить реализованную аксиоматическую семантику или стратегию ее применения или скомбинировать операционный, аксиоматический и дедуктивный подходы при генерации условий корректности. В-четвертых, подход может быть применен для апробации новых методов дедуктивной верификации специалистами в этой области. В-пятых, применение подхода к специально разработанным учебным языкам программирования позволяет использовать его в сфере образования. Список литературы 1. Barnett M., Chang B.-Y.E., DeLine R., Jacobs B., Leino K.R.M. Boogie: A modular reusable verifier for object-oriented programs // Proc. of Conf. "Formal Methods for Components and Objects Springer-Verlaf, Berlin, LNCS. 2006. Vol. 4111. P. 364–387. 2. Filliˆtre J.-C., Paskevich A. Why3 – where programs meet provers // Proc. of the a 22nd European Symposium on Programming, Springer-Verlaf, Berlin, LNCS. 2013. Vol. 7792. P. 125–128. 3. Ануреев И.C. Предметно-ориентированные системы переходов: объектная модель и язык // Системная информатика. 2013. № 1. С. 1–34. 4. Ануреев И.С. Дедуктивная верификация телекоммуникационных систем, представленных на языке Си // Моделирование и анализ информационных систем. 2012. Т. 19. № 6. С. 34–44. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 77
- 78. Верификация распределенных автоматных программс использованием инструментального средства Spin М. А. Лукин, А. А. Шалыто СПб НИУ ИТМО lukinma@gmail.com, anatoly.shalyto@gmail.com Аннотация. В данной статье рассмотрен комплексный подход к разработке и верификации распределенных автоматных программ, в которых иерархические автоматы могут реализовываться в разных потоках и взаимодействовать друг с другом. Предложен интерактивный подход к верификации распределенных автоматных программ при помощи инструмента Spin, который включает в себя автоматическое построение модели на языке Promela, приведение LTL-формулы в формат, определяемый инструментом Spin и построение контрпримера в терминах автоматов. На основе этого подхода создано инструментальное средство Stater, позволяющее создавать распределенную систему конечных автоматов, генерировать на ее основе программный код на целевых языках программирования и верифицировать ее при помощи верификатора Spin. Автоматы могут быть созданы в инструменте Stater, а также импортированы из Stateflow. Ключевые слова: верификация, системы конечных автоматов, model checking, распределенные автоматные программы, Spin, LTL. 1 Введение Формальные методы набирают все большую популярность при проверке программного обеспечения. При этом они не конкурируют с традиционным тестированием, а гармонично дополняют его. В данной работе рассматривается верификация методом проверки моделей (model checking) [1 – 3] при помощи верификатора Spin [4]. Метод проверки моделей характеризуется высокой степенью автоматизации [1]. По данной теме проводятся исследования в России и за рубежом [5 – 30]. Настоящая работа является продолжением работ [16, 22, 26]. 78 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 79. М. А. Лукин,А. А. Шалыто 2 2 Описание метода 2.1 Описание автоматной модели В методе используется распределенная система взаимодействующих иерархических конечных автоматов [31 – 33]. При этом каждый иерархический автомат в системе работает в отдельном потоке. Под иерархическим автоматом в данной работе понимается система вложенных автоматов. При этом каждый граф переходов задает не конкретный автомат, а тип автоматов (по аналогии с типом данных или классом в ООП). Назовем его автоматным типом. У каждого автоматного типа может быть несколько экземпляров (по аналогии с объектом в ООП). Назовем эти объекты автоматными объектами. Каждый автоматный объект имеет уникальное имя. В дальнейшем, если не указано иное, автоматные объекты будут называться просто автоматами. Переходы автоматов осуществляются по событиям. Также на переходе могут быть охранные условия [34]. Однако что делать, если встретилось событие, по которому нет перехода? Традиционно в теории языков и вычислений детерминированный конечный автомат в таком случае переходит в недопускающее состояние. Но такое поведение не всегда удобно. Альтернативой переходу в недопускающее состояние может быть игнорирование таких событий, которое реализуется как неявное добавление пустых (без выходных воздействий) петель по всем событиям, переходы по которым не были добавлены пользователем. Таким образом, в предлагаемом методе автомат может работать в одном из двух режимов: ─ при появлении события, по которому нет перехода, это событие игнорируется (добавляются пустые петли по всем событиям); ─ при появлении события, по которому нет перехода, автомат переходит в недопускающее состояние. Есть специальное событие «*», которое означает переход по любому событию, кроме тех, которые есть на других переходах из этого состояния (аналог default в блоках switch для C-подобных языков или else в условных конструкциях). Автомат может иметь конечное число переменных целочисленных типов (включая массивы). Для переменных есть следующие модификаторы: ─ volatile – переменная может быть использована в любом месте программы; ─ external – переменная может быть использована другим автоматом; ─ param – переменная является параметром автомата. По умолчанию считается, что переменная не используется нигде, кроме как на диаграмме переходов автомата. Все события общие для всей системы автоматов. Выходные воздействия автомата бывают двух типов: Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 79
- 80. Верификация распределенных автоматныхпрограмм с использованием инструментального средства Spin 3 1. На переходах и в состояниях может быть выполнен любой код. Однако верификатор и генератор кода перенесут его без изменений, поэтому код должен быть допустимым в целевом языке. 2. Запуск на переходах и в состояниях функций, определяемых пользователем на целевом языке программирования (после того, как сгенерирован код). Автомат может иметь вложенные автоматы любого типа, кроме собственного, иначе будет бесконечная рекурсия. Циклическая рекурсия также запрещена. Автомат может запускать поток с новым автоматом любого типа. Задается тип автомата <StateMachine> и имя <concreteStateMachine>. Нельзя запускать несколько автоматов с одним именем. Нельзя запускать автоматы своего типа. Автомат может взаимодействовать с другим автоматом, выступая источником событий для него. Сообщения с событиями отправляются асинхронно. Автомат может использовать отмеченные специальным модификатором переменные другого автомата. Таким образом, в системе могут быть несколько автоматов с одинаковым графом переходов, более того, часть этих автоматов могут быть вложенными, а часть нет. Все запреты проверяются при помощи верификации. 2.2 Описание процесса верификации Для того чтобы провести верификацию программы методом проверки моделей, требуется составить модель программы и формализовать требуемые свойства (спецификацию) на языке темпоральной логики [1]. Так как в данной работе используется верификатор Spin, то языком темпоральной логики является LTL [1]. При этом модель автоматной программы строится автоматически и построение модели описано в разделе «Генерация кода на Promela». Обозначим автоматный тип через AType, автоматный объект через aObject. Пусть состояния AType называются s0, s1 и т. д., в автомат поступают события e0, e1 и т. д., а переменные называются x0, x1 и т. д., внешние воздействия второго типа z0, z1 и т. д. Пусть автоматный тип AType имеет вложенный автомат, назовем его nested. Пусть AType запускает автомат, назовем его fork. Процесс верификации состоит из следующих этапов: 1. Генерация кода на языке Promela [4]. В нашем случае она происходит автоматически. 2. Преобразование LTL-формул (переход от нотации автоматной программы в нотацию Spin). 3. Запуск верификатора Spin. 4. Преобразование контрпримера в термины исходной системы автоматов. В нашем случае преобразование происходит автоматически. 80 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 81. 4 М. А. Лукин,А. А. Шалыто Этапы процесса верификации будут описаны ниже. Эти этапы похожи на этапы ручной верификации при помощи Spin. Основным отличием является их максимальная автоматизированность и большая приближенность модели к реализации, чем при верификации неавтоматных программ. Интерактивность Одна из главных проблем в верификации методом проверки моделей – это размер модели Крипке. Для того чтобы уменьшить модель (отсечь лишние подробности), мы будем ее строить интерактивно. Для обеспечения интерактивности вводится возможность выбирать, какие уровни абстракции автоматной системы входят в модель, а какие нет. Кроме того, модель структурируется понятным для человека образом для того, чтобы пользователь мог самостоятельно модифицировать построенную модель. Переменные Для переменных введем следующие уровни абстракции: 1. Переменные в модели не учитываются. 2. Переменные в модель включены, но модель абстрагируется от их значения. Недетерминированно выбирается, какое охранное условие будет верно. 3. Модель вычисляет значения переменных. При этом переменные могут быть следующих видов: a. Локальные. Эти переменные могут быть изменены только самим конечным автоматом. Все изменения таких переменных находятся только в выходных воздействиях автомата. b. Параметры. Извне изменяются только один раз, при запуске автомата. В остальном они подобны локальным. c. Публичные. Такие переменные могут быть изменены извне автоматной системы. В модели перед каждым переходом автомата таким переменным недетерминированно присваивается произвольное значение. d. Совместно используемые. К таким переменным данного автомата имеют доступ другие автоматы, параллельно работающие с данным. Параметры и публичные переменные могут быть также одновременно и совместно используемыми. Параллелизм Вводятся два уровня: параллелизм включен либо выключен. Если нет, то в модель не вводятся взаимодействия параллельных автоматов. Остаются только взаимодействия по вложенности. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 81
- 82. Верификация распределенных автоматныхпрограмм с использованием инструментального средства Spin 5 Источники событий В качестве источников событий для автоматов в системе могут выступать внешняя среда и другие автоматы. Внешняя среда как источник событий для каждого автомата может работать в одном из трех режимов: ─ внешняя среда не взаимодействует с автоматом (события от внешней среды не приходят); ─ внешняя среда отправляет только те события, которые автомат может в данный момент обработать; ─ внешняя среда отправляет любые события. Другие автоматы как источники событий можно отключить, если отключить параллелизм. Процесс верификации Интерактивность процесса верификации основывается на возможностях верификатора Spin и описана в разделе «Запуск верификатора Spin». Генерация кода на языке Promela Все состояния каждого автоматного типа перенумеровываются и для них создаются константы. Для каждого автоматного типа состояния нумеруются отдельно. Имя константы состоит из имени автоматного типа и имени состояния, разделенных знаком подчеркивания. Это сделано для того, чтобы состояния разных автоматов с одинаковыми именами не конфликтовали друг с другом. Пример: #define AType_s0 0 #define AType_s1 1 Все события перенумеровываются и для них создаются константы. Для событий применяется сквозная нумерация. Пример: #define e0 1 #define e1 1 Все внешние воздействия второго типа (вызываемые функции) перенумеровываются и для них создаются константы аналогично состояниям. Все вызовы вложенных и запуски параллельных автоматов перенумеровываются аналогично состояниям. Для каждого типа автоматов создается структура. Элементы структуры: ─ ─ ─ ─ byte state – номер текущего состояния; byte curEvent – номер последнего пришедшего события; byte ID – номер автомата; byte functionCall – номер последней запущенной функции, если такая есть; ─ byte nestedMachine – номер активного вложенного автомата, если такой есть; ─ byte forkMachine – номер запущенного автомата, если такой есть; 82 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 83. 6 М. А. Лукин,А. А. Шалыто ─ Все переменные автомата. Каждый тип автоматов записывается в inline-функцию переходов, которая моделирует один шаг автомата. Переходы записываются при помощи охранных команд Дейкстры [34]. Эта функция в качестве параметров принимает структуру с данными автомата и событие и имеет следующий вид (листинг 1): Листинг 1. Функция переходов. inline Mnemo(machine, evt) { atomic { printf("machine%d. event_happened: %d n", evt); machine.curevent = evt; } if //Определение текущего состояния. ::(machine.state == AType_s0) -> printf("machine%d.state = AType.state0 n", machine.ID); if //Выбор перехода. ::((evt == e1) && cond_1) -> machine.state = AType_s1; //Действия внутри состояния. ::((evt == e2) && cond_2) -> machine.state = AType_s2; //Действия внутри состояния. //Остальные переходы. :: else -> //Действия в случае, если не найден переход //по событию evt. fi; //Остальные состояния. fi; } Функция состоит из двух условий: внешнего и внутреннего. Внешнее условие определяет состояние, в котором находится автомат. Внутренне условие определяет переход в следующее состояние. Каждый вариант внутреннего условия соответствует одному из переходов из текущего состояния автомата и состоит из двух частей: проверка события и проверка условия на переходе. Условия на переходах в листинге 1 обозначены как cond_1, cond_2 и т. д. Для каждого экземпляра автомата создается экземпляр структуры и канал, по которому происходит передача событий. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 83
- 84. Верификация распределенных автоматныхпрограмм с использованием инструментального средства Spin 7 Для каждого экземпляра автомата, кроме вложенных, создается процесс, который извлекает из канала событие и запускает функцию переходов автомата с этим событием. Для каждого экземпляра автомата, кроме вложенных, создается процесс, который недетерминированно выбирает событие и отправляет его в канал автомата. Этот процесс эмулирует внешнюю среду. В зависимости от уровня абстракции по источникам событий этот процесс выбирает событие из всего списка событий (внешняя среда отправляет любые события), из списка переходов текущего автомата (внешняя среда отправляет только те события, которые автомат может в данный момент обработать) либо не активен и удален из модели (внешняя среда не взаимодействует с автоматом). Для публичных переменных перед каждым шагом автомата вызывается специальная функция, которая эти переменные недетерминированно изменяет. Для переменных-параметров такая функция вызывается один раз – при запуске автомата. Если по данному событию нет перехода, и в текущем состоянии есть вложенный автомат, то запускается вложенный автомат (запускается встраиваемая функция автомата). Если в текущем состоянии автомат запускает другой автомат, то запускается заранее созданный процесс запускаемого автомата, а также . Если автомат отправляет сообщение с событием другому автомату, то он записывает номер события в канал этого автомата. Преобразование LTL-формул Расширим нотацию LTL-формул верификатора Spin. В фигурных скобках будем записывать высказывания в терминах рассматриваемой автоматной модели. Добавим следующие высказывания: 1. aObject.si, которое означает, что автомат aObject перешел в состояние si. 2. aObject.ei, которое означает, что в автомат aObject пришло событие ei. 3. aObject.zi, которое означает, что автомат aObject вызвал функцию (внешнее воздействие) zi. 4. aObject->nested, которое означает, что в автомате aObject управление передано вложенному автомату nested. 5. aObject || fork, которое означает, что автомат aObject запустил автомат fork. 6. Бинарные логические операции с переменными автоматов, например, aObject.x0 >= fork.x0[fork.x1]. Пример LTL-формулы в расширенной нотации: [] ({aObject.x0 <= 5} U {aObject.s1}) (1) Алгоритм преобразования формулы в нотацию Spin следующий: 1. Все высказывания в фигурных скобках перенумеровываются. 84 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 85. 8 М. А. Лукин,А. А. Шалыто 2. Каждое такое высказывание преобразовывается в терминах модели на Promela и записывается в макрос. 3. Макросы подставляются в исходную LTL-формулу. Макросы записываются следующим образом: 1. Автомат aObject перешел в состояние si: (aObject.state == si). 2. В автомат aObject пришло событие ei: (aObject. curEvent == ei). 3. Автомат aObject вызвал функцию (внешнее воздействие) zi: (aObject. functionCall == zi). 4. В автомате aObject управление передано вложенному автомату nested: (aObject. nestedMachine == nested). 5. Автомат aObject запустил автомат fork: (aObject. forkMachine == fork). Формула (1) будет преобразована алгоритмом в следующий вид: #define p0 (aObject.x0 <= 5) #define p1 (aObject.state == AType_s1) ltl f0 {[] (p0 U p1) }} Spin поддерживает несколько LTL-формул в одной модели, поэтому формулы нумеруются f0, f1, и т. д. Запуск верификатора Spin Верификация построенной нами модели при помощи инструмента Spin состоит из следующих этапов: 1. Построение верификатора pan. При запуске к ключом -a по модели на языке Promela Spin генерирует верификатор pan на языке C. 2. Компиляция верификатора pan. При компиляции можно определить константы, которые влияют на то, как в памяти будет храниться модель Крипке [1]. Наиболее компактный вариант задается константой BITSTATE, однако в этом случае происходит аппроксимация, и верификация может быть не точна. 3. Запуск верификатора pan. Верификатор pan также может быть запущен с разными ключами, важнейший из которых является –a (поиск допускающих циклов). 4. Анализ контрпримера. Описан в разделе «Преобразование контрпримера». Интерактивность достигается за счет предоставления пользователю возможности использования вышеперечисленных вариантов работы на этапах верификации. Преобразование контрпримера Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 85
- 86. Верификация распределенных автоматныхпрограмм с использованием инструментального средства Spin 9 Для того чтобы было удобнее понимать контрпример, приведем метод автоматической трансляции контрпримера, который получается на выходе верификатора Spin, в термины используемой автоматной модели. Для каждого действия автомата создается пометка при помощи функции printf. На языке Promela функция printf работает аналогично функции printf из языка C [35]. Во время случайной симуляции [4] она выводит текст на экран, а во время верификации этот текст появляется в контрпримере. Остается его считать и вывести пользователю. Подробнее преобразование контрпримера описано в работе [26]. Корректность построения модели Построенная функция переходов автомата в модели на Promela соответствует его графу переходов, так как содержит в себе ровно все его состояния и ровно все переходы для каждого состояния. Состояние каждого автомата хранится в его поле state, и в модели на Promela это поле не изменяется нигде, кроме функции переходов. Поэтому, атомарные высказывания о состояниях автомата тождественны соответствующим атомарным высказываниям в модели. Номер события передается в функцию переходов в качестве параметра. В функции перехода этот номер присваивается полю curEvent. Других присваиваний полю curEvent нет. Поэтому, атомарные высказывания о событиях, пришедших в автомат, эквивалентны соответствующим атомарным высказываниям в модели. Выходные воздействия второго типа перенумерованы и в момент вызова их номер присваивается полю functionCall. Поэтому, атомарные высказывания о выходных воздействиях второго типа эквивалентны соответствующим атомарным высказываниям в модели. Выходные воздействия первого типа, которые могут являться любым кодом, записываются в модель без изменения за исключением добавления названия структуры автомата. Аналогично с остальными вариантами атомарных высказываний. На основе изложенного можно сделать вывод о том, что LTL спецификация равновыполнима на исходной системе автоматов и в модели на Promela. 2.3 Генерация программного кода Метод разработан для объектно-ориентированных языков, но может быть расширен и для прочих языков. Однако это выходит за рамки данного исследования. В отличие от таких инструментов, как Unimod [36] и Stateflow [37] в данном подходе предлагается генерировать не самостоятельную программу, а подпрограмму. Для объектно-ориентированных языков это набор классов, который пользователь может включить в свою программу. Для того, чтобы обеспечить удобство использования сгенерированного кода, делаются следующие шаги (ограничение на размер статьи не позволяет подробно описать алгоритмы первичной и повторной генерации кода, отметим лишь, что они 86 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 87. М. А. Лукин,А. А. Шалыто 10 используют конечные автоматы и были разработаны при помощи самого инструментального средства Stater): ─ Для каждого автоматного типа генерируется отдельный класс в отдельном файле. Такой класс называется автоматизированным классом [33]. ─ Сгенерированный класс содержит функцию переходов для автомата, перечисление, содержащее события, необходимые переменные для переходов и определения функций (выходных воздействий второго типа), в которые пользователь может дописать собственный код, и этот код не исчезнет при повторной генерации кода. ─ В коде специальными комментариями помечаются места, которые полностью переписываются, и в которые не следует писать пользовательский код. Пользовательский код из остальных мест будет полностью сохранен. ─ Если пользователь добавит новые выходные воздействия второго типа, то их определения будут добавлены к сгенерированному коду. ─ Пользователь может задать пространство имен (или пакет в языке Java), в котором будет находиться сгенерированный код. Если между генерациями кода пространство имен было удалено, то оно будет восстановлено. ─ Если пользователь добавит к автоматизированному классу наследование от базового класса или интерфейса, то повторная генерация кода сохранит это наследование. ─ Генерируются вспомогательные классы, включая менеджер потоков, которые обеспечивают взаимодействие автоматов, находящихся в разных потоках. Если многопоточность не требуется, их генерацию можно отключить. ─ Пользователь может ввести произвольное количество автоматных объектов, которые будут запущены при запуске менеджера потоков. 2.4 Хранение диаграмм При совместной разработке программы несколькими разработчиками существует проблема объединения программного кода, когда один файл редактируется несколькими разработчиками одновременно. Для обычных программ эта проблема решается при помощи систем контроля версий (SVN [38], Git [39], Mercurial [40] и т. д.). Однако системы контроля версий хорошо объединяют только текстовые файлы. Диаграммы графов переходов конечных автоматов у популярных инструментов плохо приспособлены для совместной разработки. Для того чтобы облегчить объединение диаграмм, в данной работе предлагаются следующие свойства, которыми должен обладать формат хранения диаграмм: 1. Формат должен быть текстовым. 2. Каждая диаграмма должна быть в отдельном файле или в отдельном множестве файлов. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 87
- 88. Верификация распределенных автоматныхпрограмм с использованием инструментального средства Spin 11 3. Структура диаграммы хранится в отдельных файлах от информации, которая нужна для отображения диаграммы. 3 Описание инструментального средства Stater Для поддержки предложенного метода было разработано инструментальное средство Stater. Оно позволяет следующее: ─ создавать распределенную систему конечных иерархических автоматов; ─ импортировать конечные автоматы из Stateflow; ─ верифицировать созданную систему конечных автоматов при помощи верификатора Spin; ─ генерировать программный код по созданной системе конечных автоматов. Инструментальное средство Stater использовалось при разработке самого себя, а именно модулей загрузки диаграмм из файла и преобразования LTLформул, а также модуля генерации кода. Ни предложенный метод, ни разработанное на его основе инструментальное средство Stater не претендуют на полноту верификации систем, разработанных в Stateflow. Это связано, в первую очередь, с тем, что спецификация к Stateflow имеет более 1300 страниц [41]. 4 Пример Продемонстрируем работу метода на примере прототипа программы управления гусеничным шасси для робота. В шасси два двигателя: по одному на левую гусеницу и на правую. Прототип программы состоит из двух автоматных типов: AEngine и AManager. Автомат manager типа AManager Два автомата left и right типа AEngine (рис. 1) управляют соответственно левым и правым двигателями. 88 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 89. М. А. Лукин,А. А. Шалыто 12 Рис. 1. Диаграмма переходов автоматного типа AEngine Автомат типа AManager (рис. 2) отправляет команды на управление двигателями в зависимости от команд для шасси. При входе в состояния он отправляет следующие события автоматам AEngine (слева от стрелки написано имя автомата, справа – событие): ─ ─ ─ ─ ─ ─ ─ ─ ─ Stopped: left ← stop, right ← stop. MoveForward: left ← forward, right ← forward. MoveBackward: left ← backward, right ← backward. TurnRight: left ← backward, right ← forward. TurnLeft: left ← forward, right ← backward. ForwardRight: left ← stop, right ← forward. ForwardLeft: left ← forward, right ← stop. BackwardRight: left ← backward, right ← stop. BackwardLeft: left ← stop, right ← backward. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 89
- 90. Верификация распределенных автоматныхпрограмм с использованием инструментального средства Spin 13 Рис. 2. Диаграмма переходов автоматного типа AManager Проверим свойство: «В любой момент если поступила команда «стоп», то будет подана команда остановки левого двигателя». Мы не можем проверить, что остановился, так как это утверждение относится к аппаратной части. Формализуем это свойство. Высказывание «Поступила команда «стоп» означает, что в автомат manager пришло событие stop. В нотации Stater оно записывается следующим образом: {manager.stop}. Высказывание «подана команда остановки левого двигателя» означает, что автомат left вызвал функцию EngineStop. В нотации Stater оно записывается следующим образом: {left.EngineStop}. Поэтому, свойство переписывается так: в любой момент в автомат manager пришло событие stop, следовательно, в будущем автомат left вызовет функцию EngineStop: G ({manager.stop} => (F {left.EngineStop})) (2) В итоге получаем следующий вид: [] ( {manager.stop} -> (<> {left.EngineStop} )) (3) Запускаем верификацию и получаем ответ, который означает, что свойство выполняется в построенной системе: 0. [] ( {manager.stop} -> (<> {left.EngineStop} )) Verification successful! 90 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 91. 14 М. А. Лукин,А. А. Шалыто Источники 1. Кларк Э., Грамберг О., Пелед Д. Верификация моделей программ: Model Checking. М.: МЦНМО, 2002. 2. Вельдер С. Э., Лукин М. А., Шалыто А. А., Яминов Б. Р. Верификация автоматных программ. СПб.: Наука, 2011. 3. Карпов Ю. Г. Model Checking: верификация параллельных и распределенных программных систем. СПб.: БХВ-Петербург, 2010. 4. Официальный сайт инструмента Spin. http://spinroot.com 5. Mikk E., Lakhnech Y., Siegel M. , Holzmann G. J. “Implementing Stateacharts in Promela/SPIN” in Proc. of WIFT'98, 1998 6. Latella D., Majzik I., Massink M. Automatic verification of a behavioral subset UML stetechart diagrams using the SPIN model-checker // Formal Aspects of Computing 11:637–664, 1999. 7. Lilius, J., Paltor I. P. Formalising UML State Machines for Model Checking, in: R. B. France and B. Rumpe, editors, Proc. 2nd Int. Conf. UML, Lect. Notes Comp. Sci. 1723 (1999), pp. 430–445. 8. Eschbah R. A verification approach for distributed abstract state machines. // PSI '02 109-115, 2001. http://dl.acm.org/citation.cfm?id=705973 9. Shaffer T., Knapp A., Merz S. Model checking UML state machines and collaborations. //Electronic notes in theoretical computer science 47:1-13, 2001. 10. Tiwari A.. Formal semantics and analysis methods for Simulink Stateow models. Technical report, SRI International, 2002. http://www.csl.sri.com/~tiwari/~stateflow.html 11. Roux C., Encrenaz E. CTL May Be Ambiguous when Model Checking Moore Machines. UPMC LIP6 ASIM, CHARME, 2003. http://sed.free.fr/cr/charme2003.ps 12. Gnesi S., Mazzanti F. On the fly model checking of communicating UML state machines. 2004. http://fmt.isti.cnr.it/WEBPAPER/onthefly-SERA04.pdf 13. Gnesi S., Mazzanti F. A model checking verification environment for UML statecharts / Proceedings of XLIII Congresso Annuale AICA, 2005. http://fmt.isti.cnr.it/~gnesi/matdid/aica.pdf 14. Виноградов Р. А., Кузьмин Е. В., Соколов В. А. Верификация автоматных программ средствами CPN/Tools // Моделирование и анализ информационных систем. 2006. № 2, с. 4–15. http://is.ifmo.ru/verification/_cpnverif.pdf 15. Васильева К. А., Кузьмин Е. В. Верификация автоматных программ с использованием LTL // Моделирование и анализ информационных систем. 2007. № 1, с. 3–14. http://is.ifmo.ru/verification/_LTL_for_Spin.pdf 16. Лукин М. А. Верификация автоматный программ. Бакалаврская работа. СПбГУ ИТМО, 2007. http://is.ifmo.ru/papers/_lukin_bachelor.pdf 17. Яминов Б. Р. Автоматизация верификации автоматных UniMod-моделей на основе инструментального средства Bogor. Бакалаврская работа. СПбГУ Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 91
- 92. Верификация распределенных автоматныхпрограмм с использованием инструментального средства Spin 15 ИТМО, 2007. http://is.ifmo.ru/papers/_jaminov_bachelor.pdf 18. Ma G. Model checking support for CoreASM: model checking distributed abstract state machines using Spin. 2007. http://summit.sfu.ca/item/8056 19. David A., Moller O., Yi W. Formal Verification of UML Statecharts with Real-time Extensions. / Formal Methods 2006 20. Егоров К. В., Шалыто А. А. Методика верификации автоматных программ // Информационно-управляющие системы. 2008. № 5, с. 15–21. http://is.ifmo.ru/works/_egorov.pdf 21. Курбацкий Е. А. Верификация программ, построенных на основе автоматного подхода с использованием программного средства SMV // Научно-технический вестник СПбГУ ИТМО. Вып. 53. Автоматное программирование. 2008, с. 137–144. http://books.ifmo.ru/ntv/ntv/53/ntv_53.pdf 22. Лукин М. А., Шалыто А. А. Верификация автоматных программ с использованием верификатора SPIN // Научно-технический вестник СПбГУ ИТМО. Вып. 53. Автоматное программирование. 2008, с. 145–162. http://books.ifmo.ru/ntv/ntv/53/ntv_53.pdf 23. Гуров В. С., Яминов Б. Р. Верификация автоматных программ при помощи верификатора UNIMOD.VERIFIER // Научно-технический вестник СПбГУ ИТМО. Вып. 53. Автоматное программирование. 2008, с. 162–176. http://books.ifmo.ru/ntv/ntv/53/ntv_53.pdf 24. Егоров К. В., Шалыто А. А. Разработка верификатора автоматных программ // Научно-технический вестник СПбГУ ИТМО. Вып. 53. Автоматное программирование. 2008, с. 177–188. http://books.ifmo.ru/ntv/ntv/53/ntv_53.pdf 25. Prashanth C.M., Shet K. C. Efficient Algorithms for Verification of UML Statechart Models. // Journal of Software. 2009. Issue 3 pp 175-182. 26. Лукин М. А. Верификация визуальных автоматных программ с использованием инструментального средства SPIN. СПбГУ ИТМО, 2009. http://is.ifmo.ru/papers/_lukin_master.pdf 27. Ремизов А. О., Шалыто А. А. Верификация автоматных программ / Сборник докладов научно-технической конференции «Состояние, проблемы и перспективы создания корабельных информационно-управляющих комплексов. ОАО «Концерн Моринформсистема Агат». М.: 2010, с. 90–98. http://is.ifmo.ru/works/_2010_05_25_verific.pdf 28. Клебанов А. А., Степанов О. Г., Шалыто А. А. Применение шаблонов требований к формальной спецификации и верификации автоматных программ / Труды семинара «Семантика, спецификация и верификация программ: теория и приложения». Казань, 2010, с. 124–130. http://is.ifmo.ru/works/_2010-10-01_klebanov.pdf 29. Вельдер С. Э., Шалыто А. А. Верификация автоматных моделей методом редуцированного графа переходов // Научно-технический вестник 2009. Вып. 6(64), с. 66–77. СПбГУ ИТМО. http://is.ifmo.ru/works/_2010_01_29_velder.pdf 92 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 93. 16 М. А. Лукин,А. А. Шалыто 30. Chen C., Sun J., Liu Y., Dong J., Zheng M. Formal modeling and validation of Stateflow diagrams // International Journal on Software Tools for Technology Transfer. 2012. Issue 6, pp 653 – 671. 31. Шалыто А. А. Switch-технология. Алгоритмизация и программирование задач логического управления. СПб.: Наука, 1998. http://is.ifmo.ru/books/switch/1 32. I. Cardei, R. Jha, M. Cardei. Hierarchical architecture for real-time adaptive resource management. Secaucus, NJ, USA: Springer-Verlag, 2000. 33. Поликарпова Н. И., Шалыто А. А. Автоматное программирование. СПб.: Питер, 2010. http://is.ifmo.ru/books/_book.pdf 34. Dijkstra E.W. Guarded commands, non-determinacy and formal derivation of programs // CACM. 18. 1975. № 8. 35. Последний черновик спецификации языка C. http://www.openstd.org/jtc1/sc22/wg14/www/docs/n1570.pdf 36. Официальный сайт проекта UniMod. http://unimod.sf.net 37. Официальный сайт продукта Stateflow. http://www.mathworks.com/products/stateflow/ 38. Официальный сайт проекта SVN. http://subversion.apache.org 39. Официальный сайт проекта Git. http://git-scm.com/ 40. Официальный сайт проекта Mercurial. http://mercurial.selenic.com/ 41. The MathWorks. Stateflow and Stateflow coder – User's Guide. 2009. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 93
- 94. Проверка корректности поведения HDL-моделейцифровой аппаратуры на основе динамического сопоставления трасс В.П. Иванников, А.С. Камкин, М.М. Чупилко Федеральное государственное бюджетное учреждение науки Институт системного программирования Российской академии наук (ИСП РАН), 109004, г. Москва, ул. Александра Солженицына, д. 25. {ivan,kamkin,chupilko}@ispras.ru Аннотация Проверка корректности поведения HDL-моделей является неотъемлемой частью динамической верификации аппаратуры. Как правило, она основана на сравнении поведения HDL-модели с поведением эталонной модели, разработанной на языке программирования. В процессе верификации на обе модели подается одна и та же последовательность стимулов; реакции перехватываются и сравниваются друг с другом. Из-за абстрактности эталонной модели сопоставление трасс не является тривиальной задачей: порядок событий может не совпадать, а некоторые события одной трассы могут отсутствовать в другой. В работе рассматривается метод динамического сопоставления трасс для моделей аппаратуры разного уровня абстракции. Метод был успешно применен в нескольких промышленных проектах по верификации модулей микропроцессоров. 1 Введение Несмотря на развитие формальных методов, динамическая верификация остается основным методом проверки сложной цифровой аппаратуры [1]. Объектом верификации выступают не сами устройства, а их модели, разработанные на специальных языках описания аппаратуры (HDL, Hardware Description Languages), например, на Verilog или VHDL (такие модели называются HDL-моделями) [2]. С одной стороны, HDL-модели представляют основу для автоматизированного производства интегральных схем; с другой стороны, это имитационные модели, поведение которых можно анализировать в специальных средах (симуляторах). Для автоматизации проверки корректности поведения HDL-моделей разрабатываются мониторы, которые перехватывают события на входах и выходах (стимулы и реакции) и проверяют допустимость получаемой трассы [3]. Существует множество подходов к формальному описанию поведения, позволяющих автоматизировать создание мониторов: расширенные регулярные выражения [4], контрактные спецификации [5], системы правил [6], 94 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 95. 2 Проверка корректности поведенияHDL-моделей цифровой аппаратуры темпоральные утверждения [7], однако указанные формализмы не покрывают всех потребностей индустрии. Большинство компаний, проектирующих аппаратуру, для оценки проектных решений используют исполнимые модели, разработанные на языках программирования (прежде всего, на C и C++) [8]. Экономически целесообразно использовать эти модели и для верификации создаваемой аппаратуры, в частности, для проверки корректности поведения HDL-моделей. При наличии исполнимой модели применяют следующую схему проверки корректности поведения: эталонная модель (по терминологии тестирования соответствия, спецификация) выполняется совместно с проверяемой HDL-моделью (реализацией); на спецификацию поступает та же последовательность стимулов, что и на реализацию; реакции обеих моделей перехватываются монитором и сравниваются. Основная проблема указанной схемы связана с обобщенным характером спецификации, из-за чего порядок реакций, выдаваемых спецификацией и реализацией, а также их состав могут различаться. Перед тем как использовать эталонную модель для мониторинга, необходимо понять, насколько она абстрактна и насколько можно доверять производимым ею трассам. В работе предлагается способ построения мониторов для HDL-моделей аппаратуры, адаптируемый для эталонных моделей разного уровня абстракции. Рассматриваемый подход может быть формализован на основе модели частично упорядоченных мультимножеств [9]. Поведение спецификации и реализации описывается временн´ ми трассами над общим алфавитом. Свеы дения об абстрактности спецификации позволяют обобщать последовательности выдаваемых реакций в частично упорядоченные мультимножества, в которых для каждой реакции задан допустимый временной интервал. Монитор проверяет, что трасса реализации является линеаризацией обобщенной трассы спецификации (или ее подмножества) и реакции реализации удовлетворяют ограничениям, заданными временными интервалами. ´ Оставшаяся часть статьи организована следующим образом. В разделе 2 вводятся основные понятия и обозначения. Раздел 3 описывает предлагаемый метод динамического сопоставления трасс: в этом разделе определяется отношение соответствия между реализацией и спецификацией и рассматривается устройство монитора, проверяющего соответствие. В разделе 4 описывается опыт использования предлагаемого подхода для верификации модулей микропроцессоров. Раздел 5 содержит краткий обзор работ близких к нашей. В разделе 6 дается заключение и указываются направления дальнейших исследований. 2 Основные понятия и обозначения В дальнейшем будем использовать следующие обозначения: Σ — конечный алфавит событий, T — временн´я область (для определенности, N). Поа следовательности событий называются словами. Σ ∗ обозначает множество всех (конечных) слов над алфавитом Σ. Если u и v — два слова над одним Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 95
- 96. Проверка корректности поведенияHDL-моделей цифровой аппаратуры 3 алфавитом и u конечно, то uv обозначает их конкатенацию. Для w = uv говорят, что w является продолжением u с помощью v. В контексте динамической верификации HDL-моделей удобно структурировать алфавит событий, разбив его на два множества: множество входных событий (стимулов) I и множество выходных событий (реакций) O, а также сопоставив каждому событию его порт: port : Σ → {1, 2, ..., k}. На содержательном уровне стимул представляет собой посылку запроса к устройству, а реакция — выдачу ответа. При этом события на разных портах могут происходить параллельно. Определение 1 (Временн´е слово [10]) Временн´ м словом (timed word) о ы w над алфавитом Σ и временн´й областью T называется последовательо ы ность (a0 , t0 )(a1 , t1 )... временн´ х событий (ai , ti ) ∈ Σ × T, удовлетворяющая следующим ограничениям: 1. для каждого i ≥ 0 выполняется неравенство ti ≤ ti+1 ; 2. для любого T ∈ T найдется i ≥ 0, такой что ti > T (если w бесконечна); 3. для всех i, j ≥ 0, таких что i = j и ti = tj , port(ei ) = port(ej ). В параллельных системах, к которым относится аппаратура, используется концепция независимости событий: два события считаются независимыми, если между ними нет причинно-следственной связи (для таких событий не накладываются ограничения на их относительный порядок). Эта идея лежит в основе двух формальных моделей параллельных вычислений: (1) трасс Мазуркевича (Mazurkiewicz) [11] и (2) частично упорядоченных мультимножеств [9]. В настоящей статье мы будем придерживаться более общей второй модели. Определение 2 (Частично упорядоченное мультимножество [9]) Σразмеченным частичным порядком называется кортеж V, , λ , где V — конечное множество вершин и λ : V → Σ — функция разметки. Два Σразмеченных частичных порядка называются эквивалентными, если они изоморфны относительно и λ (совпадают или отличаются названием вершин). Частично упорядоченным мультимножеством (pomset, partially ordered multiset) над алфавитом Σ называется класс эквивалентности Σразмеченных частичных порядков. Для удобства мы будем использовать конкретного представителя (конкретный размеченный частичный порядок) для обозначения частично упорядоченного мультимножества. Линеаризацией частично упорядоченного мультимножества V, , λ называется размеченный полный порядок V, ≤, λ , где ⊆≤. Определение 3 (Временн´я трасса [12]) Временн´й трассой над алфаа о витом Σ и временн´й областью T называется четверка V, , λ, θ , где о V, , λ — частично упорядоченное мультимножество, а θ : V → T — функция времени, удовлетворяющая следующим условиям: 96 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 97. 4 Проверка корректности поведенияHDL-моделей цифровой аппаратуры 1. для всех x, y ∈ V , из x y вытекает θ(x) < θ(y); 2. для любого t ∈ T существует срез C ⊆ V , такой что minx∈C {θ(x)} ≥ t (если V бесконечно). Множество всех трасс над алфавитом Σ и временн´й областью T обознао ´ чается Mθ (Σ, T). Заметим, что временные слова являются частным случаем временных трасс. Для заданной непустой трассы σ = V, , λ, θ введем обо´ значения: begin(σ) = minx∈V {θ(x)} и end(σ) = maxx∈V {θ(x)} (если σ бесконечна, end(σ) = ∞); σ[t,t+∆t] — подтрасса трассы σ, состоящая из тех x ∈ V , для которых θ(x) ∈ [t, t + ∆t]. Пусть TI(T) — множество временных интер´ валов во временн´й области T (то есть TI(T) = {[t, t + ∆t] | t, t + ∆t ∈ T}). о Определение 4 (Интервальная трасса) Интервальной трассой над алфавитом Σ и временн´й областью T называется четверка σ = V, , λ, δ , о где V, , λ — частично упорядоченное мультимножество, а δ : V → TI(T) — функция, ассоциирующая с каждой вершиной временной интервал. Языком интервальной трассы σ является множество L(σ) = { V, , λ, θ ∈ Mθ (Σ, T) | ∀x ∈ V . θ(x) ∈ δ(x)}. Множество всех интервальных трасс над алфавитом Σ и временн´й облао стью T обозначается Mδ (Σ, T). В дальнейшем мы будем иметь дело с парами а трасс σθ , σδ , где σθ — временн´я трасса, а σδ — интервальная трасса, такие что σθ ∈ L(σδ ). Каждая такая пара описывается пятеркой V, , λ, θ, δ и называется расширенной интервальной трассой. Множество всех расширенных интервальных трасс обозначается Mθδ (Σ, T). 3 Динамическая верификация на основе исполнимых моделей Временн´е слово (временн´я трасса с тривиальным частичным порядком) о а описывает конкретное выполнение HDL-модели (реализации), в то время как расширенная интервальная трасса описывает поведение эталонной модели (спецификации). Наша цель — проверить в динамике (on-the-fly), что трасса реализации wI ∈ (Σ × T)∗ соответствует трассе спецификации σS ∈ Mθδ (Σ, T). Поясним, откуда берется расширенная интервальная трасса σS . В процессе выполнения спецификация порождает конкретную трассу wS , описываемую временным словом. Прямое сравнение двух временных слов, wI и ´ ´ wS , на равенство возможно только для потактово точной спецификации. Как правило, спецификация абстрактнее реализации, особенно в отношении временных свойств. Сведения о степени абстрактности спецификации ´ позволяют обобщить конкретное временн´е слово wS до расширенной ино тервальной трассы σS , смягчая тем самым проверку соответствия между реализацией и спецификацией (см. Рисунок 1). Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 97
- 98. Проверка корректности поведенияHDL-моделей цифровой аппаратуры 5 Рис. 1. Схема проверки соответствия между реализацией и спецификацией 3.1 Отношение соответствия В дальнейшем мы будем называть трассы с тривиальным частичным порядком (порядком, заданным отношением равенства) трассами выполнения. Если Σ = I ∪ O, то трассы выполнения над алфавитом I будем называть входными последовательностями, а трассы выполнения над алфавитом O — выходными последовательностями. Отметим, что тривиальный частичный порядок в трассах выполнения отражает тот факт, что реализация рассматривается как “черный ящик”, и причинно-следственные связи между ее событиями если и известны, то не от самой реализации. Множества входных и выходных последовательностей обозначаются Iθ (Σ, T) и Oθ (Σ, T) соответственно. Для краткости будем использовать сокрашенные обозначения: I = Iθ (Σ, T) и O = Oθ (Σ, T). Определение 5 (Поведение) Детерминированным поведением над алфавитом Σ = I ∪ O и временн´й областью T называется (частичное) отобо ражение B : I × T → O, удовлетворяющее следующим ограничениям: - для всех w ∈ I и t ∈ T выполняется неравенство end B(w, t) ≤ t; - для всех w ∈ I и t ∈ T справедливо равенство B(w, t) = B(w[0,t] , t); - для всех w ∈ I и t ∈ T существует wv ∈ I, продолжение w, и ∆t ≥ 0, такие что end B(wv, t + ∆t) ≥ t. Поведение описывает, каким образом входная последовательность преобразуется в выходную последовательность, принимая во внимание момент времени, в которое производится наблюдение. Предположим, что у нас есть исполнимая спецификация. Рассмотрим, как ее можно использовать для динамической проверки поведения реализации. Расширим определение поведения, позволив спецификации возвращать расширенные интервальные трассы, а не конкретные последовательности, как это требуется. Обозначим множество всех таких трасс символом Oθδ . Для заданной выходной трассы V, , λ, θ, δ ∈ Oθδ , определим две функции, ∆t± , такие что для всех x ∈ V , δ(x) = [θ(x)−∆t− (x), θ(x)+∆t+ (x)]. Будем полагать, что функции ∆t± ограничены (существуют константы ∆T ± > 0, такие что |∆t± (x)| ≤ ∆T ± для всех x ∈ V ). Также положим, что значения 98 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 99. 6 Проверка корректности поведенияHDL-моделей цифровой аппаратуры ∆t± (x) зависят от события, а не от вершины: ∆t± (x) = ∆t± (λ(x)). Пусть I и S — поведение реализации и поведение спецификации соответственно. Для заданной входной последовательности w ∈ I и момента времени t ∈ T рассмотрим выход реализации и спецификации: I(w, t) = VI , ∅, λI , θI и S(w, t) = VS , S , λS , θS , δS . Введем обозначения: past∆t (w, t) = {y ∈ I(w, t) | θI (y) ≤ t − ∆t− (y) }; I pastI (w, t) = {y ∈ I(w, t) | θI (y) ≤ t}; past∆t (w, t) = {x ∈ S(w, t) | θS (x) ≤ t − ∆t+ (x) }; S pastS (w, t) = {x ∈ S(w, t) | θS (x) ≤ t}; match(x, y) = λI (y) = λS (x) ∧ θI (y) ∈ δS (x) . Определение 6 (Отношение соответствия) Говорят, что поведение реализации I соответствует поведению спецификации S, если domI = domS и для всех w ∈ domS и t ∈ T существует бинарное отношение M(w, t) ⊆ {(x, y) ∈ pastS (w, t)×pastI (w, t) | match(x, y)} (называемое сопоставлением), такое что: 1. M(w, t) взаимно однозначно; 2. для каждой реакции спецификации x ∈ past∆t (w, t) существует реакция S реализации y ∈ pastI (w, t), такая что (x, y) ∈ M(w, t); 3. для каждой реакции реализации y ∈ past∆t (w, t) существует реакция I спецификации x ∈ pastS (w, t), такая что (x, y) ∈ M(w, t); 4. для всех (x, y), (x , y ) ∈ M(w, t) если x x , то θI (y) ≤ θI (y ). Если для некоторых w ∈ I и t ∈ T вышеуказанные свойства нарушаются, то говорят, что I не соответствует S, при этом w[0,t] называется контрпримером. Рисунок 2 иллюстрирует определение отношения соответствия для некоторой входной последовательности (будучи неважной, она на рисунке не показана) и момента времени (t = 4). Верхняя часть рисунка показывает реакции реализации (черные кружки с белыми надписями: b, a и c), нижняя — реакции спецификации (белые кружки с черными надписями: a, b, c и d). Будем обозначать вершины трассы (собственно, кружки) символами yb , ya и yc (для реализации) и xa , xb , xc и xd (для спецификации). Между вершинами реализационной трассы нет причинно-следственных связей. Вершины спецификационной трассы частично упорядочены (предшествование xc , xb xc , xa xd и xb xd ) и пособытий показано стрелками: xa мечены временными интервалами (δ(xa ) = [0, 2], δ(xb ) = [1, 3], δ(xc ) = [0, 4] ´ и δ(xd ) = [1, 5]). Сопоставление реакций отмечено пунктирными линиями ((xa , ya ), (xb , yb ) и (xc , yc )). Легко видеть, что изображенное отношение является сопоставлением (в смысле данного выше определения): (1) оно взаимно однозначно; (2 и 3) оно включает все реакции с истекшим “времеxc и нем жизни”; (4) оно сохраняет спецификационный порядок: (a) xa θ(ya ) = 2 ≤ 3 = θ(yc ); (b) xb xc и θ(yb ) = 1 ≤ 3 = θ(yc ). Безусловно, каждая пара этого отношения удовлетворяет условию сопоставления реакций: (a) λ(xa ) = λ(ya ) = a и θ(ya ) = 2 ∈ [0, 2] = δ(xa ); (b) λ(xb ) = λ(yb ) = b и θ(yb ) = 1 ∈ [1, 3] = δ(xb ); (c) λ(xc ) = λ(yc ) = c и θ(yc ) = 3 ∈ [0, 4] = δ(xc ). Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 99
- 100. Проверка корректности поведенияHDL-моделей цифровой аппаратуры 7 Рис. 2. Соответствие между реализацией и спецификацией 3.2 Динамическое сопоставление трасс Монитор, осуществляющий сопоставление трасс реализации и спецификации, может быть представлен как временной автомат [10] с двумя типами входных портов: (1) порты для получения спецификационных реакций и (2) порты для получения реализационных реакций. Когда автомат обнаруживает расхождение в трассах реализации и спецификации, он переходит в определенное состояние, информируя, тем самым, что реализация не соответствует спецификации. Ниже представлено формальное описание монитора в виде системы действий с условиями (guarded actions). Каждое действие атомарно и выполняется, как только соответствующее условие становится истинным. Действия и условия зависят от внешней переменной t, отражающей текущее время, и реакций, выдаваемых реализацией и спецификацией в ответ на одну и ту же последовательность стимулов (S и I соответственно). Значение t монотонно возрастает в процессе верификации. Запись y ∈ I[t] (x ∈ S[t]) означает, что в момент времени t реализация (спецификация) выдает реакцию y (x). Описание базируется на двух функциях: (1) первичный арбитр (arbiterS ) и (2) вторичный арбитр (arbiterI ), определенных ниже: arbiterS (X) = arbiterI (y, X) = 100 min (X) φ arg minx∈X.match(x,y) {θS (x)} φ если X = ∅, иначе (φ ∈ Σ); / если ∃x ∈ X . match(x, y), иначе. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 101. 8 Проверка корректности поведенияHDL-моделей цифровой аппаратуры Действие 1 onSpecOut[x], x ∈ S[t] Если: true Вход: x pastS ⇐ pastS ∪ {x} if x ∈ arbiterS (pastS ) then for all y ∈ pastI [↑ θI (y)] do if x = arbiterI (y, {x}) then pastS ⇐ pastS {x} pastI ⇐ pastI {y} match ⇐ match ∪ { x, y } break end if end for end if Действие 2 onImplOut[y], y ∈ I[t] Если: true Вход: y pastI ⇐ pastI ∪ {y} x ⇐ arbiterI (y, arbiterS (pastS )) if x = φ then pastS ⇐ pastS {x} pastI ⇐ pastI {y} match ⇐ match ∪ { x, y } end if Действие 3 onSpecT ime[x], x ∈ pastS Действие 4 onImplT ime[y], y ∈ pastI ` ´ Если: θS (x) + ∆t+ (x) ≤ t Вход: x pastS ⇐ pastS {x} verdict ⇐ f alse‘ trace(“Missing output”) terminate ` ´ Если: θI (y) + ∆t− (y) ≤ t Вход: y pastI ⇐ pastI {y} verdict ⇐ f alse trace(“Unexpected output”) terminate Действие 5 onInitialize Действие 6 onF inalize Если: t = 0 Вход: ∅ pastS ⇐ ∅ pastI ⇐ ∅ match ⇐ ∅ Если: ` ´ max end(S)+∆T + , end(I)+∆T − ≤ t Вход: ∅ verdict ⇐ true terminate Ниже приведен порядок проверки условий и запуска действий внутри одного временн´го слота t (при несоблюдении этого порядка возможны ложо ные сообщения об ошибках): 1. 2. 3. 4. инициализация (onInitialize); прием реакции (onSpecOut, onImplOut); превышение лимита времени (onSpecT ime, onImplT ime); завершение (onF inalize). Когда говорят, что некоторое свойство ϕ выполняется в момент времени t, имеется в виду, что ϕ выполняется после завершения всех действий, активированных в момент t. Для многопортовых систем (что типично для аппаратуры) монитор можно разбить на слабо связанные компоненты, параллельно обслуживающие отдельные порты. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 101
- 102. Проверка корректности поведенияHDL-моделей цифровой аппаратуры 9 Утверждение 1 (Корректность) Входная последовательность является контрпримером тогда и только тогда, когда монитор завершается с verdict = f alse. На практике встречается аппаратура, в которой операции в некоторых ситуациях отменяют другие операции (конфликтующие с ними и имеющие более низкий приоритет). Например, операция записи может быть отменена другой операцией записи, адресующейся к той же ячейке памяти и запущенной сразу после рассматриваемой операции. Из-за абстрактности спецификации в ее терминах не всегда возможно выразить условия, при которых происходит отмена операций и соответствующие реакции не посылаются наружу. Принимая во внимание вышесказанное, определение спецификационного поведения может быть расширено: каждая спецификационная реакция дополнительно помечается признаком возможной отмены. Предложенный подход к организации мониторов может быть перенесен и на этот случай. Следует, однако, учесть, что если некоторое событие отменяется, то также отменяются все зависимые от него события. 4 Инструментальная поддержка и опыт применения Предложенный метод к проверке корректности поведения HDL-моделей был реализован в инструменте C++TESK [13]. Библиотека инструмента содержит классы и макросы для создания компонентов систем динамической верификации аппаратуры (эталонных моделей, мониторов, генераторов стимулов и других). Возможности C++TESK для разработки эталонных моделей аппаратуры (и, соответственно, мониторов) включают средства для посылки и приема пакетов данных (примитивы send и receive), ветвления и объединения параллельных процессов (f ork и join), моделирования временных задержек (delay) и задания зависимостей между пакетами (depends). ´ Инструмент позволяет создавать модели аппаратуры на разных уровнях абстракции (относительно точности моделирования времени): (1) модели без учета времени (описывающие общие причинно-следственные связи между пакетами данных без моделирования временных задержек между ´ ними: ∆t± = ∞), (2) модели с приближенным учетом времени (частично специфицирующие внутренние схемы арбитража пакетов, но учитывающие время лишь примерно: ∆t± ≤ T , где T имеет значение нескольких десятков тактов) и (3) потактовые модели (реализующие точное или почти точное моделирование времени: ∆t± ≤ 1). Инструмент C++TESK был использован для динамической верификации модулей промышленных микропроцессоров, разрабатываемых в НИИСИ РАН и ЗАО “МЦСТ”. Наш опыт уже был представлен в [14], но с тех пор он был расширен. Последняя информацию о применении инструмента и заложенного в нем метода представлена в Таблице 1. Как видно из таблицы, подход поддерживает верификацию как с помощью абстрактных эталонных моделей (доступных на ранних стадиях проектирования), так и 102 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 103. 10 Проверка корректности поведенияHDL-моделей цифровой аппаратуры с помощью потактово точных моделей (доступных на заключительных этапах). Что важно, подход позволяет использовать для верификации C++модели, изначально создаваемые для других целей (в частности, компоненты системного симулятора микропроцессора). Таким способом, например, был проверен модуль поиска по таблице страниц. Название модуля Стадия разработки Точность моделирования от до Буфер трансляции адресов Поздняя / завершающая Приближенная Потактовая Модуль арифметики (FPU) Поздняя / завершающая Без учета времени — Кэш-память 2-ого уровня (L2) Промежуточная / поздняя Приближенная Коммутатор северного моста Промежуточная / завершающая Прилиженная Модуль доступа к памяти Ранняя / промежуточная Без учета времени Потактовая Контроллер прерываний Ранняя / промежуточная Без учета времени Приближенная Модуль поиска по таблице страниц Поздняя Приближенная — Контроллер банка кэш-памяти L2 Поздняя Потактовая — Буфер команд Поздняя / завершающая Потактовая — Кэш-память 3-его уровня (L3) Промежуточная Приближенная — — Потактовая Таблица 1. Опыт применения предложенного метода 5 Обзор существующих работ В работе [15] используется модель автомата с частично упорядоченными входными/выходными событиями (POIOA, Partial Order Input/Output Automaton) для представления поведения спецификации и реализации. В статье предлагается метод построения тестового набора, гарантирующего обнаружение ошибок определенного типа. Если (1) реализация сообщает о приеме неподдерживаемых стимулов, (2) можно установить порядок выдачи реакций, (3) время ответа реализации ограничено, и (4) каждый единичный переход в спецификации соответствует единичному переходу в реализации, можно определить соответствие между реализацией и спецификацией. Реализация соответствует спецификации, если она принимает допускаемые спецификацией стимулы и выдает описываемые спецификацией реакции в допустимом порядке. Определение отношения соответствия, данное в этой статье, близко к используемому нами. Главными отличиями нашего подхода являются поддержка необязательных реакций и контроль временных ´ интервалов. Статья [16] описывает подход к проверке поведения временных систем, ´ основанный на инвариантах трассы. Рассматриваются два типа инварианМеждународная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 103
- 104. Проверка корректности поведенияHDL-моделей цифровой аппаратуры 11 тов: (1) инварианты ожидания, выражающие то свойство, что после заданной трассы всегда ожидается определенное событие (в определенном временн´м интервале) и (2) инварианты наблюдения, утверждающие, что межо ду двумя заданными событиями всегда наблюдается определенная последовательность событий. Корректность поведения реализации проверяется в два этапа: (1) проверка соответствия инвариантов спецификации, выраженной в форме временного конечного автомата (TFSM, Timed Finite State Machine); (2) проверка выполнимости инвариантов для трассы реализации. Подход представляет теоретический интерес, однако его промышленное использование может быть затруднено необходимостью постоянного согласования проверяемых инвариантов со спецификацией. В работе [17] рассматривается метод тестирования параллельных систем с помощью неявно заданных асинхронных конечных автоматов (AFSM, Asynchronous Finite State Machines). Поведение реализации проверяется только в стационарных состояниях, в которых не ожидается выдача реакций. Используется следующая процедура: (1) собираются все события и определяется их частичный порядок; (2) строятся и проверяются все возможные линеаризации множества событий (проверка базируется на пред- и постусловиях, определенных для каждого события). Считается, что реализация соответствует спецификации, если допускается хотя бы одна из построенных линеаризаций. Применение подхода возможно только для ограниченного класса входных последовательностей: требуется, чтобы регулярно возникали стационарные состояния. В нашем случае такого ограничения нет. 6 Заключение Работа сфокусирована на использовании исполнимых моделей для динамической верификации HDL-моделей. Проблема не так проста, как кажется на первый взгляд. Проверка того, что реализация и спецификация выдают одинаковые реакции в одинаковые моменты времени в большинстве случаев не является адекватной. Спецификация в силу своей абстрактности может не учитывать многих особенностей реализации, таких как упорядочивание событий и их распределение во времени. В работе предложены механизмы, позволяющие настраивать точность проверки поведения, учитывая степень абстрактности спецификации. К ним относятся: (1) описание отношения зависимости событий, (2) расширение временных меток событий до временных ´ ´ интервалов и (3) пометка некоторых событий как необязательных. Основываясь на предложенных механизмах, разработан метод проверки поведения HDL-моделей. Метод был реализован в инструменте C++TESK и применялся в более чем 10 проектах по верификации модулей микропроцессоров. Наши дальнейшие исследования связаны с диагностикой ошибочного поведения HDL-моделей на основе более глубокого анализа трасс, выполняемого после сеанса верификации. Целью такого анализа является упрощение локализации ошибок путем определения характера расхождений наблюдаемого поведения HDL-модели от эталонного. 104 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 105. 12 Проверка корректности поведенияHDL-моделей цифровой аппаратуры Список литературы 1. Wile, B., Goss, J., Roesner, W.: Comprehensive Functional Verification: The Complete Industry Cycle. Morgan Kaufmann (2005) 2. Bergeron, J.: Writing Testbenches: Functional Verification of HDL Models. Kluwer Academic (2000) 3. Glasser, M.: Open Verification Methodology Cookbook. Springer (2009) 4. Sen, K., Rosu, G.: Generating Optimal Monitors for Extended Regular Expressions. Electronic Notes in Theoretical Computer Science 89(2) (2003) 162– 181 5. Ivannikov, V., Kamkin, A., Kossatchev, A., Kuliamin, V., Petrenko, A.: The Use of Contract Specifications for Representing Requirements and for Functional Testing of Hardware Models. Programming and Computer Software 33(5) (2007) 272–282 6. Barringer, H., Rydeheard, D., Havelund, K.: Rule Systems for Run-Time Monitoring: From Eagle to RuleR. In: Proceedings of 7th International Workshop on Runtime Verification. Revised Selected Papers. (2007) 111–125 7. Bauer, A., Leucker, M., Schallhart, C.: Runtime Verification for LTL and TLTL. ACM Transactions on Software Engineering and Methodology 20(4) (2011) 14:1– 14:64 8. Mintz, M., Ekendahl, R.: Hardware Verification with C++: A Practitioner’s Handbook. Springer Science+Business Media, LLC (2006) 9. Pratt, V.: The Pomset Model of Parallel Processes: Unifying the Temporal and the Spatial. In: Seminar on Concurrency. (1984) 180–196 10. Alur, R., Dill, D.: A Theory of Timed Automata. Theoretical Computer Science 126(2) (1994) 183–235 11. Mazurkiewicz, A.: Trace Theory. In: Advances in Petri Nets 1986, Part II on Petri Nets: Applications and Relationships to Other Models of Concurrency, New York, NY, USA, Springer-Verlag New York, Inc. (1987) 279–324 12. Chieu, D., Hung, D.: Timed Traces and Their Applications in Specification and Verification of Distributed Real-time Systems. In: Proceedings of the Third Symposium on Information and Communication Technology. (2012) 31–40 13. ISPRAS: C++TESK Homepage. http://forge.ispras.ru/projects/cpptesk-toolkit/ 14. Chupilko, M., Kamkin, A.: A TLM-Based Approach to Functional Verification of Hardware Components at Different Abstraction Levels. In: Proceedings of the 12th Latin-American Test Workshop. (2011) 1–6 15. von Bochmann, G., S.Haar, C.Jard, Jourdan, G.V.: Testing Systems Specified as Partial Order Input/Output Automata. In: Proceedings of the 20th IFIP TC 6/WG 6.1 International Conference on Testing of Software and Communicating Systems: 8th International Workshop. TestCom ’08 / FATES ’08 (2008) 169–183 16. Andr´s, C., Merayo, M., N´nez, M.: Formal Passive Testing of Timed Systems: e u˜ Theory and Tools. Software Testing, Verification & Reliability 22(6) (2012) 365– 405 17. Kuliamin, V., Petrenko, A., Pakoulin, N., Kossatchev, A., Bourdonov, I.: Integration of Functional and Timed Testing of Real-Time and Concurrent Systems. In: Perspectives of System Informatics. (2003) 450–461 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 105
- 106. Использование контрольных точекдля верификации SystemC-программ А.А. Шипин, В.А. Соколов? , Д.Ю. Чалый?? Ярославский государственный университет 150000, Ярославль, Советская, 14 andrey.shipin@gmail.com, valery-sokolov@yandex.ru, chaly@uniyar.ac.ru Аннотация Верификатор, работающий с использованием метода проверки модели (model checking), должен иметь возможность обхода множества достижимых состояний системы. Для SystemC-моделей генерация этого множества является нетривиальной задачей, так как SystemC представляет собой набор классов, расширяющих язык C++. В результате SystemC-модель системы компилируется в виде исполняемого файла, который позволяет проводить только имитационное моделирование или тестирование. В работе представлен подход, основанный на использовании контрольных точек, реализующий исчерпывающее построение множества достижимых состояний моделируемой системы. Keywords: SystemC, model checking, верификация, контрольная точка 1 Введение SystemC (IEEE Standard 1666-2005) [4,10] открытый промышленный язык для проектирования и верификации моделей системного уровня, реализованный в виде C++-библиотеки с открытым исходным кодом. Основной областью применения языка являются встраиваемые системы, системы на кристалле, где важной является задача обеспечения корректной работы. В библиотеку включено ядро моделирования событий, что позволяет получить исполняемую модель устройства, а при разработке можно использовать все средства языка C/C++. Модель на языке SystemC это набор компонентов и соединений между ними. Многие компоненты аппаратного обеспечения, такие как, например, модули, каналы, сигналы, порты, имеют соответствующие аналоги в SystemC. Язык применяется в основном для построения транзакционных и поведенческих моделей. Поведенческая модель описывает взаимодействие ? ?? 106 работа поддержана грантом РФФИ, проект 11-07-00549-а работа поддержана программой ФЦП ⌧Научные и научно-педагогические кадры инновационной России� на 2009–2013 годы, соглашение №14.B37.21.0392 от 06.08.2012 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 107. 2 компонент системы междусобой, информационные процессы в системе, поведение системы. Если функциональная модель позволяет ответить на вопрос что делает система?, то поведенческая модель отвечает на вопрос как система это делает?. В ней фигурируют такие категории как состояние системы, события, переход из одного состояния в другое, условия перехода, последовательность событий. Моделирование на уровне транзакций это подход к моделированию систем, в котором детали связи между модулями отделены от деталей реализации модулей. Механизмы связи моделируются в виде каналов, и используются модулями с помощью специальных интерфейсов. Запрос транзакции начинается с вызова функции интерфейса этих каналов, которая заключает в себе детали обмена информацией. На уровне транзакций обмен информацией более выразителен и понятен [4]. К основным расширениям SystemC, отсутствующим в C++, относятся: понятие модельного времени; возможности описания параллельно выполняющихся вычислений; дополнительные типы данных, отражающие специфику проектирования аппаратуры. SystemC был разработан для достижения возможности использовать единый язык программирования с общим окружением для описания системы от самых высокоуровневых моделей на C++ до структурных синтезируемых моделей уровня RTL (Register Transfer Level). Это позволяет постепенно детализировать описание системы в процессе проектирования. С помощью SystemC можно добиться модели взаимодействия программной и аппаратной частей системы, как если бы это было реальное устройство, но на высоком уровне абстракции. За счет этого можно выявить многие проблемы на ранних стадиях разработки [10]. В [21] отмечается, что средства верификации SystemC-моделей находятся в зачаточном состоянии. Стандартная поставка позволяет лишь проводить имитационное моделирование и тестирование. Там же, в [21], ставится задача разработки средств верификации, в частности таких, которые исчерпывающе исследуют множество достижимых состояний модели. 2 Обзор существующих подходов к верификации SystemC-моделей Основными методами верификации систем являются имитационное моделирование, тестирование, дедуктивный анализ и проверка модели [1]. Обычно SystemC-модели верифицируются с помощью тестирования. Проверяемая модель выполняется в рамках заранее подготовленных сценариев. Тестирование сопровождается созданием контролируемой среды модели, обеспечивающей получение результатов ее работы и измерение различных характеристик, а также оценка этих результатов и характеристик [1]. Испытательный стенд (test bench) это среда, используемая для проверки свойств или проверки на безошибочность системы или ее модели. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 107
- 108. 3 Стенды, разрабатывающиеся дляSystemC-моделей, как правило, содержат проверяемую систему (device under test тестируемое устройство), связующие элементы и элементы, необходимые для проверки (тесты). В таких стендах могут использоваться специальные высокоуровневые модели, предназначенные для различных целей: генерации входных сигналов, постобработки данных, создания эталонных моделей, схем обеспечения безопасности (верификаторов свойств, мониторов, наблюдателей) [10]. Создание хороших стендов довольно трудоемкий процесс, требующий хорошего знания C++. Для верификации SystemC-моделей предусмотрена специальная библиотека SCV (SystemC Verification Library). SCV предоставляет средства, помогающие разработчику эффективно проводить комплексные испытания системы [19]. С помощью SCV создаются испытательные стенды и случайным образом генерируются тесты, которые используются средой в качестве входных данных. Существуют разные виды и приемы генерации тестов. Архитектурой модели назовем набор компонентов и соединение между ними, а также механизмы синхронизации и коммуникации, такие как, например, события, сигналы, запись в порты и чтение из них. Лучшие верификаторы SystemC на данный момент переводят код на SystemC в формальную модель с помощью предварительных обработчиков (front-end). Они формализуют семантику языка так, чтобы можно было использовать полученный код как входную информацию для верификаторов. Так как SystemC является библиотекой C++, все особенности C++ должны поддерживаться предварительным обработчиком. Этого можно достичь, написав свой парсер, удовлетворяющий этим условиям, либо использовать существующий предварительный обработчик для C++ (GCC, LLVM, EDG и т.д.). Обычный предварительный обработчик C++ не в состоянии уловить специфику языка SystemC, поэтому предварительные обработчики SystemC должны уметь определять специфичные конструкции языка и помечать их в промежуточном представлении особым образом. В случае создания предварительного обработчика со своим парсером SystemC воспринимается как язык программирования, а не библиотека для C++. Создание полноценного парсера является сложной задачей, поэтому, как правило, не все конструкции C++ поддерживаются такими предварительными обработчиками. Представителями такого подхода являются: ParSyc [9], KaSCPar [11], sc2v [8], BSSC based [17], SystemPerl [20]. К проектам, использующим существующие предварительные обработчики C++, относятся: SystemCXML [3], Quiny [18], Pinapa [15], PinaVM [13], Scoot [5], Dust [12], SystemCASS [7]. Предварительные обработчики для SystemC делятся на статические, динамические и гибридные. Статический анализ позволяет распознавать конструкции языка. Статическим анализом кода можно построить архитектуру модели, но статический анализ позволяет работать только с моделями с относительно простой архитектурой. К проектам, основанным на статическом подходе, относятся 108 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 109. 4 все проекты сосвоим собственным парсером языка, а также SystemCXML и Scoot. Динамический подход основан на выполнении откомпилированной программы, в частности на выполнении фазы разработки модели. С помощью ее выполнения также можно получить архитектуру модели. При выполнении программы собираются данные, которые генерируются во время выполнения. Так как некоторым инструментам требуется только архитектура, они могут использовать динамический подход. Такие инструменты позволяют искать информацию в архитектуре, но не знают ничего о поведении процессов. К проектам, основанным на динамическом подходе, относятся Quiny, Dust, SystemCASS. Перед предварительным обработчиком SystemC стоит задача построить архитектуру системы, а также распознать происходящие в архитектуре взаимодействия между модулями и процессами. Причем необходимо организовать связь между архитектурой и этими взаимодействиями. С этой задачей достаточно успешно справляется гибридный подход, являющийся комбинацией статического и динамического подходов. Существуют проприетарные решения, предлагаемые компаниями Synopsys и Semantic Designs. Эти решения основаны на статическом анализе и отлично распознают конструкции языка SystemC. Так как их разработка является закрытой, они здесь не рассматриваются. В [14,13] был проведен сравнительный обзор функциональности нескольких предварительных обработчиков, которые были доступны на тот момент. Сравнение производилось на ряде тестовых примеров. В таблице 1 приведены полученные результаты, которые показывают, что на данный момент не существует универсального средства верификации SystemC-моделей. 3 Предлагаемый подход для верификации SystemC-моделей Как мы уже видели, использование предварительных обработчиков не позволяет учитывать все нюансы SystemC-моделей. Это по-видимому является врожденным недостатком всех методов, которые основаны на парсинге исходного кода SystemC-программы с целью получения формальной модели, пригодной для верификации. Наш подход основывается на методе CMC (C Model Checking) [16], который при помощи внесения изменений, не влияющих на семантику SystemC-программы, позволяет строить эту формальную модель во время ее выполнения. 3.1 Метод верификации CMC Метод CMC [16] позволяет автоматически создавать формальную модель из C/C++ кода, которую можно верифицировать с помощью метода проверки модели (model checking). Так как SystemC это библиотека для языка C++, то можно использовать средства, разработанные для анализа кода на C++. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 109
- 110. PinaVM Pinapa SystemCXML KaSCPar Quiny Scoot SystemPerl sc2v 5 elab-only elab-easy elab-easy-int elab-easy-uint elab-easy-array elab-easy-sc_stop elab-port-bool elab-pointer elab-instances elab-clock signal event fifo RAM 6 6 6 6 6 6 6 4 6 6 6 6 3 6 6 6 6 6 6 6 6 4 5 3 4 6 0 2 6 6 6 6 0 6 0 0 0 6 0 6 0 6 6 1 1 1 1 1 1 0 1 1 0 1 0 0 5 5 3 3 2 3 2 2 2 3 0 2 0 0 6 6 6 6 1 3 2 0 3 5 5 6 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 2 2 2 0 3 0 0 0 3 0 2 0 0 Таблица 1. Сравнительныйанализ функциональности нескольких предварительных обработчиков SystemC-моделей. Обозначения: 6 пример может быть проанализирован; 5 пример может быть проанализирован, но с небольшим изменением теста; 4 пример проанализирован лишь частично; 3 пример не может быть проанализирован, но требуется незначительная доработка проекта; 2 пример не может быть проанализирован и требуется значительная доработка проекта; 1 пример не может быть проанализирован по неизвестной причине; 0 пример не может быть проанализирован из-за ограничений подхода. Так как исходный код Стэндфордской реализации метода CMC является закрытым, нам пришлось написать свою реализацию с учетом специфики SystemC-моделей. Каждая система в CMC моделируется в виде взаимодействующих процессов. Такие процессы выполняют код реализации системы в контексте верификации модели. Программа, реализующая метод CMC и содержащая все процессы, работает в операционной системе как единый процесс. Многопоточные объекты могут моделироваться как процессы, содержащие любое количество потоков выполнения. Поток имеет доступ к глобальным переменным и куче процесса, в котором он выполняется. Процессы могут обмениваться информацией через специальную общую память, выделенную для всех процессов одновременно. Состояние потока состоит из его стека и содержимого регистров процессора. Состояние процесса состоит из копии своих глобальных переменных, содержимого кучи и состояния всех его потоков. Состояние системы это совокупность состояний процессов и общей памяти. 110 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 111. 6 CMC позволяет настраиватьграфик запуска потоков, что, в свою очередь, позволяет получать разное поведение системы. Переход системы это выполнение детерминированного, атомарного шага, который изменяет состояние системы. Переход выполняется с передачи контроля потоку и до вызова специально определенной в CMC функции cmc_yield(), которая внедряется в исходный код исследуемой программы согласно решению разработчика и его пониманию этой программы. Так как переходы являются атомарным шагом, они определяют степень чередования выполнения параллельных потоков, и разработчик должен решить, как должны выполняться потоки, чтобы желаемые свойства были проверены. После того, как реализация будет представлена в виде процессов и потоков и определятся соответствующие системе переходы, в реализацию необходимо добавить модель среды. Под средой здесь подразумеваются все внешние объекты, с которыми взаимодействует система (человек, сеть, файловая система и так далее). Важной частью среды являются входные данные. Обычно система объединяется с другими компонентами в более сложную систему. Чтобы минимизировать затраты на моделирование среды ряд компонентов предлагается сделать универсальными, чтобы использовать в разных задачах. Поведение системы является недетерминированным. Оно может зависеть, например, от следующих факторов среды: порядок получения системой входных данных, различные значения входных данных, порядок запланированного запуска потоков. Чтобы смоделировать недетерминированность поведения, в CMC используется функция cmc_choose(int n), которая внедряется разработчиком в части кода, где есть необходимость проверки недетерминированного поведения. Она возвращает случайное число в диапозоне от 0 до n - 1. Использовать эту функцию можно, предоставив каждому значению возвращаемого значения уникальное поведение системы. При реализации метода CMC каждое из поведений будет рассмотрено. Например, удобно написать функцию динамического выделения памяти, которая будет либо выделять, либо не выделять память в зависимости от значения cmc_choose(). Таким образом, будет рассмотрено оба случая: поведение системы при корректном выделении памяти и поведение системы, при котором происходит ошибка при выделении по каким-либо причинам. Важной причиной недетерминированного поведения является параллельное выполнение процессов в системе (параллельность системы). Выполнение потоков в системе может произвольно чередоваться. CMC реализует этот недетерминизм контролем за расписанием запуска потоков в модели. Многократные чередования CMC исследует, задавая различные расписания запуска потоков. Модель, построенная из реализации системы, вместе с моделью среды доступна для соединения с CMC. CMC начинает контролировать выполнение этой модели, исследуя по мере выполнения состояния на выполнение в них заданной спецификации. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 111
- 112. 7 СМС этометод верификации модели, который создает пространство состояний посредством прямого исполнения реализации системы (на языке С/С++). СМС генерирует граф достижимых состояний системы при помощи его обхода в глубину или в ширину. Если граф обходится в ширину, интересным развитием алгоритма является эвристический анализ предпочтительности состояний в очереди. Выбирая из очереди наиболее интересные состояния, мы добьемся большей эффективности процесса верификации, особенно если исчерпывающее построение множества достижимых состояний не представляется возможным. Для того чтобы производить обход графа состояний, необходимо уметь сохранять состояния модели и возвращаться к ним. Чтобы выполнять эти действия, необходимо уметь их выполнять со всеми составными частями состояния модели. Во время верификации системы методом CMC граф состояний может начинать экспоненциально расти. Количество состояний может становится чрезмерно большим (или даже являться бесконечным) для обработки. Эта проблема известна как проблема взрыва состояний. Чем больше граф, тем быстрее кончатся ресурсы компьютера, необходимые для процесса верификации. Несмотря на разные подходы к ее решению, она остается довольно серьезной проблемой. СМС использует различные подходы эффективного обхода пространства состояний. CMC может проверять свойства безопасности (safety), но не может проверять свойства живости (liveness). Свойства безопасности составляют большой класс интересных для верификации свойств, к тому же свойства живости в графах с конечным количеством состояний могут быть выражены в виде свойств безопасности. Специализированные свойства отслеживаются с помощью вызовов функции assert(). Разработчик вставляет функции проверки так, чтобы каждое новое состояние было проверено на свойства. 3.2 Верификация SystemC-моделей c использованием метода CMC Модель, написанная на языке SystemC, представляется в CMC в качестве процесса. Если для верификации необходимо взаимодействие нескольких моделей, все они представляются в качестве отдельных процессов. SystemCпроцессы (SC_METHOD и SC_THREAD) выполняют роль CMC-потоков, то есть при обходе графа достижимости они будут выполнять переходы между состояниями. Переходы выполняются с момента передачи управления SystemCпроцессу и до момента его окончания, или, в случае SystemC-потока, до момента его откладывания. Во время фазы инициализации производится формирование начального состояния графа. Далее выполняется алгоритм обхода с начального состояния, пошагово исполняя код программы. Если какая-то из ветвей графа приведет к завершению фазы вычислений, то осуществляется фаза постобработки и завершение выполнения этой ветви. 112 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 113. 8 Состояние графа должнохранить состояние всей модели, в том числе значение времени, состояние SystemC-процессов и состояние других объектов библиотеки. Новые типы CMC сможет сохранять и восстанавливать, потому что эти типы представляют собой обычные классы языка C++. Во время обхода графа для рассматриваемого состояния генерируются его состояния-потомки. В некоторых случаях генерируется только одно состояние: когда состояние системы может лишь детерминировано перейти в другое, используя единственный доступный переход. В остальных случаях генерируется несколько состояний. Это происходит, когда CMC может использовать более одного перехода, а именно: в случаях параллельного выполнения SystemC-процессов, в случаях различного поведения среды модели, в случаях какого-либо иного недетерминированного поведения модели. Среда для SystemC-модели зависит от самой модели и разрабатывается точно так же, как и в случае немодифицированного C/C++ кода. Для нашей реализации метода CMC ключевой задачей является способ сохранения и восстановления состояния SystemC-модели. От этого зависит корректность работы верификатора, скорость его работыа также насколько экономно будут расходоваться ресурсы компьютера. Для сохранения состояния программы можно использовать два способа. Первый способ предполагает сериализацию значений переменных (сохранение состояния) внутри кода модели с последующей десериализацией (восстановление состояния). Второй способ напротив сохраняет снимок состояния модели как программы с помощью сторонних средств. В исходном коде SystemC существует класс sc_simcontext, отвечающий за хранение всех объектов, использующихся в SystemC-модели. Если сохранить и восстановить объект этого класса в момент выполнения модели перед запуском новой итерации фазы вычислений, теоретически можно достигнуть желаемого результата и добиться более быстрой работы, чем при втором способе. Важным моментом является то, что сохранение класса по сути является глубоким копированием: копированием объекта с выделением под него нового участка памяти, а не копированием лишь указателей на переменные. В C++ не существует ни стандартных средств глубокого копирования, ни сторонних библиотек, которые позволили бы выполнить такую операцию. Другой подход к сохранению и восстановлению состояний основан на использовании контрольных точек. Контрольная точка снимок состояния приложения, хранящий всю необходимую информацию для того, чтобы можно было восстановить работу приложения с сохраненного состояния. Чаще всего контрольные точки используются для резервного хранения состояний [6]. Существует ряд проектов для операционной системы Linux, позволяющих создавать контрольные точки приложений. Среди них: BLCR, DMTCP, CRIU, Cryopid, OpenVZ. Нами был выбран DMTCP [2], так как проект стабилен и выполняет все необходимые функции. В частности, в отличие от BLCR, DMTCP поддерживает сокеты (программный интерфейс для обес- Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 113
- 114. 9 печения информационного обменамежду процессами). Это важно, так как разработанный верификатор взаимодействует с исследуемой моделью через сокеты. Программный пакет DMTCP позволяет организовать ⌧прозрачное� создание контрольных точек для многопоточных и распределенных программ. Пакет реализован на уровне системных библиотек операционной системы Linux и не требует модификаций ядра этой ОС. DMTCP позволяет обеспечить формирование контрольных точек и восстановление из них для таких программ, как: OpenMPI, MATLAB, Python, Perl. Он поддерживает различные языки программирования, включая скриптовые языки. Нами было разработано программное средство SCMC (SystemC Model Checker), которое представляет собой программу, позволяющую выполнять SystemC-модель всеми возможными способами и оповещать пользователя о достижении определенных условий при выполнении. Она хранит граф состояний модели и выполняет направляющую роль. Для языка SystemC предусмотрено дополнение, необходимое для указания в модели точек, в которых SCMC будет разветвлять выполнение модели. После запуска SCMC происходит ожидание запуска SystemC-модели. Как только модель запустилась, SCMC ожидает от нее сообщения чтобы начать генерировать граф достижимых состояний. Интерфейс дополнения для SystemC-моделей содержит ряд методов, которые разработчику необходимо внедрить в свою модель. Метод SendCheckpointAndWait отправляет в SCMC сообщение о месте разветвления выполнения. Каждая ветвь определяется целочисленным значением, которое возвращает метод. В зависимости от значения модель осуществляет ту или иную работу, это настраивается вручную сразу после вызова метода. Номер ветви лежит в диапазоне [0, N], где N максимальный номер ветви. Метод принимает аргументы: максимальный номер ветви и аннотацию состояния модели в данный момент в виде строки, которую пользователь формирует по своему усмотрению вручную. Состояние модели представляет из себя строку из значений переменных, совокупность которых точно определяет состояние. Важно учесть все необходимые переменные, иначе может возникнуть ситуация, когда два разных состояния SCMC примет за одинаковые и ошибочно отсечет целую ветку исполнения. После сохранения состояния модель завершает работу. SCMC восстанавливает новое состояние из очереди. SendAssertMessage отправляет в SCMC сообщение о выполнении свойства. Аргументом метода является сопутствующее сообщение, которое будет выведено в файле с результатами. SendExitMessage отправляет в SCMC сообщение о завершении работы модели.Этот метод может быть вызван в конце работы модели, чтобы SCMC мог перейти к рассмотрению следующего в очереди состояния. Для сохранения и восстановления состояния модели используется DMTCP. Физически на жесткий диск состояние сохраняется в момент отправления сообщения о месте разветвления, причем для всего набора добавляемых со- 114 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 115. 10 стояний с разныминомерами ветви для восстановления используется один и тот же файл с состоянием программы, что экономит память. В SCMC реализован в целом похожий на CMC алгоритм, граф достижимых состояний обходится в ширину. В принципе реализация не ограничивает работу SCMC исключительно языком SystemC, верификатор также может работать с любой другой программой на языке C++, которая сохраняется и восстанавливается DMTCP. 4 Экспериментальные результаты Эксперименты проводились с моделью, которая распространяется вместе с пакетом SystemC. Она описывает передачу данных от отправителя получателю через канал связи, представленный в виде очереди ограниченной длины. Канал связи допускает только потерю символов. Передаваемая строка задается заранее. Получатель может принимать в один момент времени только один символ, а остальные ожидают в канале. В эксперименте проверяется свойство, может ли получатель последовательно принять два одинаковых символа подряд. Эксперименты проводились на компьютере с процессором Intel Core i3-2310M. В модель с помощью разветвления выполнения модели добавлена возможность потери любого символа при передаче. Метод, сообщающий о разветвлении, срабатывает непосредственно перед передачей символа в канал. В сообщении передается максимальный номер ветви, равный единице, и информация о состоянии, которая включает в себя историю переданных получателю символов, номер следующего символа в очереди канала, список хранящихся в канале символов и оставшаяся для передачи в канал строка на отправителе. Это тот минимальный набор информации, который позволяет идентифицировать состояние модели единственным образом для данной задачи. Так как SystemC ведет себя детерминированно, нет опасности пропустить новые состояния при отсечении повторяющихся состояний. Каждый новый принятый получателем символ сравнивается с предыдущим. Если они совпадают, в SCMC отправляется сообщение о выполнении проверяемого свойства. В результате исследования модели можно заключить, что предложенный метод работоспособен. Каждое состояние модели занимает на жестком диске примерно 2 Мб, сохранение и восстановление занимает порядка 0.5 секунды. Оперативная память на хранение информации о состояниях практически не расходуется. В таблице 2 приведены результаты, показывающие скорость работы с различными входными данными. Длина очереди канала несущественно влияет на подсчет затраченного времени, поэтому для нее во всех тестах установлено значение 10. Время работы может варьироваться на одних и тех же входных данных из-за особенностей DMTCP. Если вернуться к таблице 1 (предпоследняя строка), проверка моделей с очередями плохо поддается верификации среди известных подходов, но с описанным в данной работе методом такая проверка становится возможной. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 115
- 116. 11 11 Передаваемая строка Кол-вовыполненных условий Кол-во состояний Затрачено (сек) Передаваемая строка Кол-во выполненных условий Кол-во состояний Затрачено (сек) aaa 3 14 7 aaa cac 1 3 16 14 7 7 cac abc 0 1 16 16 6 7 abc 0 16 aaaaa 5 26 12 6 aaaaa cabac 5 5 60 26 27 12 cabac abcde 0 5 64 60 28 27 abcde 0 64 aaaaaaa 7 38 19 28 aaaaaaa cababac 29 7 164 38 84 19 cababac 29 164 abcdefg 0 256 121 84 abcdefg aaaaaaaaa 9 0 50 256 28 121 aaaaaaaaa cabababac 69 9 332 50 193 28 cabababac 332 abcdefghi 0 69 1024 480193 abcdefghi 0 1024 480 Таблица 2. Производительность метода SCMC Таблица 2. Производительность метода SCMC 5 5 Заключение Заключение Целью этой работы было создание формального верификатора для SystemCЦелью который позволил бы проверять непосредственно саму SystemCмоделей, этой работы было создание формального верификатора для SystemCмоделей, который позволил бы проверять непосредственно саму SystemCмодель без ее трансляции в язык одного из существующих верификаторов. модель без ее такого верификатора был выбран метод CMC, исследуюДля реализации трансляции в язык одного из существующих верификаторов. Для реализации такого всех возможных выбран выполнения. Метод щий программу переборомверификатора былпутей ее метод CMC, исследующий программу перебором всех возможных путей ее выполнения. Метод предполагает необходимость сохранять и восстанавливать состояние пропредполагает необходимость сохранять и восстанавливать состояние граммы, что в данном случае делается с использованием пакета DMTCP. программы, что в выполнения задачи был суспешно создан желаемый форВ результате данном случае делается использованием пакета DMTCP. В результате выполнения задачи был успешно создан желаемый формальный верификатор, названный SCMC. В отличие от существующих вемальный верификатор, названный SCMC. В отличие от существующих рификаторов SystemC используемый подход позволяет охватить все множе- верификаторов SystemC используемый подход позволяет охватить все множество SystemC-моделей. Для проведения верификации в исследуемой SystemCство должны быть указаны контрольные точки, где производится ветвлемоделиSystemC-моделей. Для проведения верификации в исследуемой SystemCмодели должны быть указаны контрольные точки, где производится выние модели, либо проверяется желаемое свойство. Пользователю будутветвление модели, либо проверяется желаемое свойство. Пользователю будут ведены все случаи выполнения заданного свойства модели, а такжебудут выведены пути исполнения модели, приведшие к выполненному также будут выведены все случаи выполнения заданного свойства модели, асвойству. выведены пути исполнения модели, приведшие к выполненному свойству. Существует проблема взрыва состояний, частично решаемая исключеСуществует проблема взрыва состояний, частично решаемая исключением одинаковых веток графа состояний. Для экономии памяти в будущем нием одинаковых веток графа состояний. контрольных точек SystemCможно будет добавить инкрементное сжатиеДля экономии памяти в будущем можно будет добавить инкрементное ускоряющие его работу. моделей, также разработать алгоритмы, сжатие контрольных точек SystemCмоделей, также разработать алгоритмы, ускоряющие его работу. Список литературы Список литературы 1. Кулямин В.В. Методы верификации программного обеспечения // Всероссийский конкурсный отбор обзорно-аналитических статей по приоритетному на1. Кулямин В.В. Методы верификации программного обеспечения // Всероссийправлению ⌧Информационно-телекоммуникационные системыприоритетному наский конкурсный отбор обзорно-аналитических статей по �, 2008, 117 с. 2. Ansel J., Arya ⌧Информационно-телекоммуникационные системы�, for Clusterс. правлению K., Cooperman G. DMTCP: Transparent Checkpointing 2008, 117 Computations and the Desktop // 23rd IEEE International Parallel and Distributed 2. Ansel J., Arya K., Cooperman G. DMTCP: Transparent Checkpointing for Cluster Processing Symposium (IPDPS’09). Rome, Italy. May, 2009. Parallel and Distributed Computations and the Desktop // 23rd IEEE International Processing Symposium (IPDPS’09). Rome, Italy. May, 2009. 116 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 117. 12 3. Berner D.,Talpin J.-P., Patel H., Mathaikutty D.A., Shukla E. SystemCXML: an extensible SystemC front end using XML // Proc. of the Forum on specification and design languages (FDL), 2005. 4. Black D.C., Donovan J. SystemC: from the ground up // Kluwer Academic Publishers 2004. 263 p. 5. Blanc N., Kroening D., Sharygina N. Scoot: A tool for the analysis of SystemC models // Proc. of TACAS, 2008, pp. 467–470 6. Bronevetsky G., Marques D., Pingali K., Szwed P., Schulz M. Application-level Checkpointing for Shared Memory Programs // Proc. of the 11th international conference on Architectural support for programming languages and operating systems, 2004. pp. 235–247.. 7. Buchmann R., Petrot F., Greiner A. Fast cycle accurate simulator to simulate eventdriven behavior // Proc. of Electrical, Electronic and Computer Engineering, 2004. ICEEC ’04. 2004, Cairo, Egypt. pp. 35–38 8. Castillo J., Huerta P., Martinez J.I. An open-source tool for SystemC to Verilog automatic translation // Lat. Am. appl. res. v.37 n.1. 2007. p. 53-58. 9. Fey G., Große D., Cassens T., Genz C., Warode T., Drechsler R. Parsyc: An efficient SystemC parser // Workshop on Synthesis And System Integration of Mixed Information technologies (SASIMI), 2004, pp. 148–154. 10. Grotker T., Liao S., Martin G., Swan S. System design with SystemC // Kluwer Academic Publishers 2002. 219 p. 11. KaSCPar. http://forge.greensocs.com/ja/Projects/KaSCPar 12. Klingauf W., Geffken M. Design structure analysis and transaction recording in SystemC // Proc. of FDL, 2006, pp. 169–177 13. Marquet K., Moy M. PinaVM: a SystemC front-end based on an executable intermediate representation // International Conference on Embedded Software, Scottsdale, USA, 2010. pp. 79–88 14. Marquet K., Moy M., Karkare B. A theoretical and experimental review of SystemC front-ends // Verimag Research Report TR-2010-4. 2010. 14 p. 15. Moy M., Maraninchi F., Maillet-Contoz L. Pinapa: an extraction tool for SystemC descriptions of systems-on-a-chip // EMSOFT ’05: Proceedings of the 5th ACM international conference on Embedded software. New York, NY, USA: ACM, 2005, pp. 317–324. 16. Musuvathi M., D.Y.W. Park, A. Chou, D.R. Engler, D.L. Dill CMC: a pragmatic approach to model checking real code // Proc. of OSDI 02: Fifth Symposium on Operating Systems Design and Implementation, 2002. pp. 75–88 17. Scarpazza D.P., Brandolese C., Pomante L., Felice P.D. Parsing SystemC: an open-source, easy-to-extend parser // IADIS International Conference on Applied Computing, 2006, pp. 25–28 18. Schubert T., Nebel W. The Quiny SystemC front end: self-synthesising designs // Proc. of FDL. ECSI, 2006, pp. 135–143. 19. Singh L., Drucker L., Khan N. Advanced verification techniques: a SystemC based approach for successful tapeout / Kluwer Academic Publishers, 2004. 373 p. 20. SystemPerl. http://www.veripool.org/wiki/systemperl. 21. Vardi M. Formal techniques for SystemC verification // Design Automation Conference (DAC) 2007. San Diego, California. June 4–8, 2007. p. 188–192. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 117
- 118. Унифицированная высокоуровневая модель программно-аппаратнойсистемы для верификации свойств надежности функционирования 1 С.Л. Френкель1 , В.Н.Захаров1, В.Г. Ушаков2 1 Институт проблем информатики РАН, Вавилова 44, корп. 2, Москва, РФ (fsergei@mail.ru, VZakharov@ipiran.ru) 2 Московский гос. университет им. М.В. Ломоносова, Институт проблем информатики РАН ( Ushakov@akado.ru ). Аннотация. В статье приводятся некоторые результаты исследования и разработки алгоритмов и программ, позволяющих комбинировать решение различных задач функциональной верификации с анализом вероятностей проявления и компенсации сбоев в системе, представленной автоматной моделью, получаемой в результате синтеза системного уровня по ASMспецификации проекта. Ключевые слова: Верификация, отказоустойчивость 1. Введение Разработчику программно-аппаратных систем на ранних этапах проектирования приходится сталкиваться с такими разными задачами как функциональная верификация проекта для проверки возможности реализации системой специфицированных (требуемой исходной спецификацией) функций, помехоустойчивости относительно определенных классов помех, производительности. Все эти задачи требуют различных подходов к их решению, с использованием разных математических моделей и проектных инструментов. В целом эти задачи трудоемки, требуют привлечения высококвалифицированного персонала и дорогостоящих средств проектирования. Ввиду крайне большого объема данных, необходимых для исчерпывающего решения указанных задач через моделирование (simulation) проектируемых объектов, большие усилия прилагаются для использования формальных методов верификации. Общим требованием к формальной модели является ее способность использовать различные уровни абстракции, возможность добавлять постепенно те или иные аспекты реализации (например, микроархитектуру), то есть иметь возможность использовать иерархический стиль проектирования. 1 Работа выполнена при частичной поддержке грантов РФФИ № 12-07-00109 и 13-07-00579. 118 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 119. При этом однимиз путей снижения трудовых и финансовых затрат на верификацию может быть интеграция различных подходов и методов, позволяющих использовать одни и те же инструменты и исходные формализованные описания (input) для возможно большего числа задач. В статье излагается возможный интеграционный подход. 2. Унифицирующие свойства моделей цифровых систем С точки зрения унификации подходов к различным задачам верификации для нас представляют интерес два способа описания систем на высоком уровне абстракции, для которых в литературе используют одну и ту же аббревиатуру, но разные названия и смысл, а именно Abstract State Machine [1,2] и Algorithmic State Machine [3]. Для удобства изложения мы будем использовать AbSM в первом случае и ASM во втором. Abstract State Machine, рассматриваемая в настоящее время как унифицированная модель вычислений, представляет собой систему переходов, реализующих конечное множество т.н. правил переходов (transition rules) вида if Condition then Updates, где Condition - некоторый предикат на указанном множестве, Updates - конечное множество операторов (assignments) вида f (t1, . . . , tn) := t, чье выполнение приводит к параллельному изменению значений аргументов функции f и получению ее значения на данном измененном наборе аргументов. Благодаря тому, что AbSM позволяет описывать изменения (переходы) абстрактных данных для произвольных множеств и функций, они могут быть использованы на различных иерархических уровнях описания проектируемой системы, что соответствует различным этапам проектирования. Ввиду возможности задания времени переходов [4], данная модель может быть использована как для функциональной спецификации, так и для получения временных характеристик выполнения задач, т.е. для анализа производительности. Это, очевидно, означает, что AbSM можно рассматривать как соответствующее средство интеграции различных задач проектирования. Однако указанная абстрактность означает необходимость использовать различные конверторы данных для перехода с уровня на уровень. Поэтому в наших работах мы использовали также другой формализм, основанный на “алгоритмических машинах состояний” (ASM) [3]. В самом общем виде ASM можно определить как направленный связанный граф, вершины которого соответствуют операциям, выполняемым на каждом шаге описываемого алгоритма, или условным переходам, а дуги задают последовательности выполнения операций. Пример и все необходимые пояснения приводятся в разделе 3.2. Подробное описание можно найти в [5]. Предложенная нами унификация спецификаций различных аспектов функционирования цифровой системы основана на использовании ASMспецификаций, по которым выполняется высокоуровневый синтез цифровых схем, для более широкого круга задач проектирования. Например, такая спецификация может быть использована для формальной верификации функциональной корректности, для оценки временной корректности на уровне взаимодействий и протоколов, для оценки помехоустойчивости разрабатываемых архитектур. Показано, что ASM-спецификация, при Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 119
- 120. использовании разработанных вИПИРАН программ генерации SMV и Spinкодов и программ моделирования цепей Маркова [7], может выполнять интегрирующую (унифицирующую) функцию при высокоуровневом синтезе [7]. Программы SMV (Symbolic Model Verifier) [18] и Spin [19] предназначены для верификации проектов методом Model Checking аппаратных (SMV) и программных (Spin) систем. Эта возможность обеспечивается тем, что для обоих классов задач верификации (функциональной и отказоустойчивости) используются одни и те же автоматные модели [7]. Существенным является также то, что при использовании для трансляции ASM-диаграмм программы синтеза цифровых систем Abelite [3] мы получаем структуру Крипке [5], позволяющую перебирать все возможные варианты работы верифицируемой системы, т.е. описывать недетерминированность ее поведения. Получаемое из ASM автоматное представление моделируемой системы выглядит следующим образом: { am, fms(xi1,,…,xik), as, Y}, (1) где am, as - текущее и следующее состояние автомата, fms(xi1,,…,xik) - функция возбуждения автомата (булевы выражения относительно входных переменных, определяющие условия переходов), и Y - вектор выходов. Это представление совместно со структурой Крипке позволяют осуществлять интерпретацию системных элементов на любых уровнях абстракции [5]. 3. Интеграция моделей и инструментов, предназначенных для решения задач функциональной верификации и оценки помехоустойчивости цифровых систем на ранних этапах проектирования В настоящее время мы имеем определенный опыт использования ASM спецификаций для верификации различных проектируемых объектов, причем не только самих проектируемых систем, но и их верификационных тестов. Например, ASM использовалась для описания тестов верификации (через моделирование) проекта некоторого процессора. Неформально говоря, тесты представляют собой набор некоторых команд и данных, которые могут выполняться либо строго поочередно (очередную операцию можно подавать на выполнение только после того, как полностью завершена предыдущая), либо, в случае конвейерного выполнения операций, операции можно подавать последовательно друг за другом, не дожидаясь завершения предыдущей операции, либо одновременно могут подаваться несколько операций. Так как число операций может быть достаточно велико (несколько сотен), тест должен быть верифицирован на выполнение указанных условий упорядоченности, т.е. тестовое множество должно быть организовано таким образом, чтобы выполняемые операции не вступали в конфликты друг с другом, при том, что возможно взаимное влияние операций (например, ввиду использования одного и того же буфера данных). Очевидно, что если выполнение этих тестов описать как переходы некоторого автомата, или нескольких определенным образом связанных автоматов, то для проверки этих условий хорошо подходит метод Model 120 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 121. Checking [8], состоящийв формальной проверке выполнения логической формулы, выражающей некоторое свойство “правильного” поведения модели системы. Автоматы Мили, необходимые для построения соответствующей модели системы, могут быть получены из ASM диаграмм выполнения множества тестов с использованием свойств декомпозируемости и иерархичности ASM-описаний (из-за ограниченного объема статьи детали здесь не приводятся). В качестве другой задачи, решаемой на основе высокоуровневой ASMспецификации проекта, рассмотрим возможность учета требований помехоустойчивости на ранних этапах проектирования. 3.1 Проблема верификации помехоустойчивости проектируемых цифровых систем на ранних этапах проектирования По сути современное проектирование цифровых систем состоит в поиске компромисса между надежностью выполнения функциональных задач, производительностью и потреблением энергии. Причем существенной составляющей данной проблемы является обеспечение правильной и эффективной работы в условиях действия переходных помех, прямое действие которых ограниченно лишь сравнительно небольшим интервалом времени. Поэтому ошибки функционирования, вызываемые помехами, называются “мягкими” (soft) [8]. Важным примером является воздействие ионизированных частиц, порождаемых космическими лучами. В настоящее время известно много способов защиты цифровых схем от действия различных внешних помех. Однако их применение связано с дополнительными аппаратурными и энергетическими затратами (повышением потребления электроэнергии), а также с возможным снижением производительности, как за счет увеличения суммарных задержек в дополнительных элементах (вентилях, элементах памяти), так и за счет необходимости ограничений скорости работы процессорных элементов. Дело в том, что энергопотребление растет примерно как квадрат частоты переключений, и это может лимитировать объем резервирования, например, изза роста энергозатрат резервирующего оборудования. Все эти обстоятельства делают актуальной задачу выбора минимально необходимого числа элементов, защита (protection) которых необходима для обеспечения требуемого уровня надежности в присутствии т.н. SEU (single event upset, одиночных сбоев, то есть кратковременных событий, представляющих собой ошибочное изменение значения логического сигнала (переменной) в некоторой точке системы), возникающих под действием указанных выше внешних факторов (лучей, частиц и т.д. ). В настоящее время предложен и активно развивается подход к определению критичных к действию помех элементов, которые необходимо обеспечить той или иной аппаратной защитой, с использованием формальных методов, Model Checking прежде всего [8]. Этот метод используется совместно с инжектированием в модель проектируемой системы возможных мутаций внутренних состояний. Этим способом определяют триггеры–защелки [8], Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 121
- 122. которые могут эффективновлиять на результат вычислений, и которые поэтому следует защищать от ошибок (ошибочного изменения состояний). Преимущества Model Checking по сравнению с просто моделированием (симуляцией) модели устройства в присутствии инжектированных неисправностей состоит в том, что устраняется проблема обеспечения репрезентативности выбираемых входов (команд и данных), которые могут отобразить все возможные рабочие ситуации. Model Checking выполняет исчерпывающий анализ всех состояний системы, начиная с множества возможных начальных состояний. Этот подход рассматривают и пытаются использовать не только как дополнение к известным процедурам формальной верификации функциональных свойств проектов цифровых устройств, но и как средство оценки полноты анализа надежностных свойств, и как средство анализа результатов с точки зрения снижения избыточности при обеспечении помехоустойчивых решений [11]. Хотя указанные выше помехи (лучи, частицы) непосредственно влияют на те или иные элементы оборудования (оперативную память, шины кэш), вызывая SEU, они приводят и к программным ошибкам. С программноаппаратной (архитектурной) точки зрения эти ошибки в программе могут распространяться по управлению (control flow) и данным (data flow). Очевидно, что непосредственную связь указанных аппаратных сбоев реально можно установить (описать) только со сравнительно низкоуровневым представлением программ, например, на уровне машинных кодов или ассемблера. Существенным, однако, является то, что указанные формальные подходы к верификации устойчивости проектируемой системы к конкретному SEU [8] указывают лишь на потенциальную возможность того, что в данной точке может быть нарушено правильное функционирование проектируемого устройства, но реальное нарушение функционирования может зависеть от статистических свойств обрабатываемой информации, например, переменных fms(xi1,,…,xik) в функции, представленной в структуре ASM (1). При этом переходные ошибки, индуцированные SEU на некотором такте работы устройства, не обязательно запоминаются в элементах памяти на следующих тактах, что можно интерпретировать как самовосстановление устройства (selfhealing). Поэтому желательно было бы дополнить формальную верификацию вычислением вероятностей такого самовосстановления. Рассмотрим для этой цели вероятностную модель, предложенную в [6,9], важным свойством которой является возможность ее использования для уточнения выводов о рисках, связанных с SEU для конкретных переменных программы, полученных формальными методами, используя Model Checking [8]. 3.2 Вероятностная модель Разработана следующая модель для вычисления распределения вероятностей времени до самовосстановления после действия SEU. Пусть в начальный момент 0 под действием помехи (разовой) автомат X (называемый исправным, fault-free) переходит в состояние Y0 вместо состояния X0 (при этом предполагается, что действие помехи в выходном сигнале не проявилось). 122 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 123. Будем называть автомат,подвергшийся действию помехи, “неисправным” (faulty), и обозначать его как Y. Неисправный автомат Y действует на тех же входных сигналах с теми же переходами и выходными сигналами в зависимости от текущих состояний и входных сигналов. Так происходит до того момента, когда либо выходной сигнал неисправного автомата окажется отличным от выходного сигнала исправного автомата (проявилось действие помехи в выходном сигнале), либо состояния обоих автоматов совпадут. Считая входные сигналы автоматов независимыми случайными двоичными переменными, на произведении этих автоматов (автомата, состояния которого равны различным парам состояний указанных двух автоматов) определяется Цепь Маркова (ЦМ) Zt=(Xt, Yt), описывающая совместное функционирование ЦМ Xt и Yt до момента, когда либо выходной сигнал неисправного автомата окажется отличным от выходного сигнала исправного автомата (проявилось действие помехи в выходном сигнале), либо состояния обоих автоматов совпадут. Множества состояний S1,2, |S1,2| = n, обеих ЦМ одинаковы, начальные состояния X0, Y0, Y0 ≠ X0 детерминированы. Множество состояний ЦМ Zt представляет собой S = {(i,j), i,j = 1,…,n, j ≠ i} A0 A1, где состояние (i,j) означает, что исправный автомат находится в состоянии i, а неисправный – в состоянии j (отличном от состояния i исправного автомата), состояние A1 – неправильное функционирование (в результате действия помехи) уже проявилась в выходном сигнале), и A0 – произошло восстановление траектории функционирования автомата до проявления эффекта помехи на выходе. Число состояний этой ЦМ равно n(n – 1) + 2. Состояния A0 и A1 представляют собой поглощающие состояния двумерной цепи Маркова Zt. Матрица P* переходных вероятностей ЦМ Zt вычисляется следующим образом. Пусть Zt находится в состоянии (i1,j1) и поступает входной сигнал x, переводящий ЦМ исправного автомата в состояние i2, а автомата, подвергшегося действию помехи, – в состояние j2, причем выходные сигналы автоматов y0 и y1. Тогда, возможны следующие ситуации: - если выходы y0 и y1 не совпадают, то ЦМ Zt попадает в поглощающее состояние A1; - если выходы y0 и y1 совпадают и совпадают состояния i2 и j2,то ЦМ Zt попадает в поглощающее состояние A0; - если выходные сигналы y0 и y1 совпадают, но не совпадают состояния i2 и j2 (в которые произошел переход обоих автоматом по действием входа x), то ЦМ Zt попадает в (i2,j2). Вероятности переходов вычисляются по известным вероятностям булевых значений независимых входных последовательностей, по известной булевой функции переходов f(xi1,…xin) (1). Подробнее алгоритм вычисления изложен в статье [6]. Введем обозначения: p(1)(t) – вероятность, того, что неисправное поведение автомата Y будет обнаружено (по выходу) не позже t-го шага (при этом до момента обнаружения неисправности автомат не восстановится); Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 123
- 124. p(0)(t) – вероятностьтого, что автомат Y восстановит свое правильное поведение не позже t-го шага (до момента восстановления неисправность не проявится по выходу, т.е. выходы обоих автоматов будут полностью совпадать); pi,j(t) – вероятность попадания ЦМ Zt в состояние (i,j) (т.е. исправного автомата X в состояние i, неисправного автомата Y в состояние j ≠ i, при этом до момента t состояния исправного и неисправного автоматов будут различными, но выходные сигналы совпадать). В терминах ЦМ Zt вероятность p(0)(t) представляет собой вероятность нахождения в момент t в поглощающем состоянии A0, вероятность p(1)(t) – в поглощающем состоянии A1, вероятность pi,j(t) - в непоглощающем состоянии (i,j) (j ≠ i). Начальное распределение p(0) определяется начальными состояниями исправного и неисправного автоматов. Если исправный автомат в начальный момент 0 находится в состоянии i0, а неисправный – в состоянии j0 ≠ i0, то p(i0,j0)(0) = 1, а остальные координаты вектора p(0) равны нулю. Распределение ЦМ Zt в момент t может быть вычислено из уравнения: p(t ) p(t 1) P* p(0)( P*)t . Заметим, что мы считаем, что действие помех не приводят к появлению новых состояний в моделирующем автомате. Это предположение используется во многих работах по верификации устойчивости к действию помех [8,10, 11]. Рассмотрим применение данной модели к верификации устойчивости к сбоям конвейеризированного микропроцессора на стадии выборки инструкций из памяти. На рисунке 1 представлена соответствующая ASM-диаграмма режима, представляющая собой направленный граф с начальной вершиной Begin, финальной End, вершинами, соответствующими выполнению операций (прямоугольники) и условными вершинами (ромбы). Заметим, что “серые” вершины соответствуют вложенным ASM. Инструкции считываются в регистры IR1 (короткие инструкции) и IR2 (длинные), адреса инструкций – в PC (Program Counter). Сгенерированный программой Abelite соответствующий данной диаграмме конечный автомат (FSM) в форме Mealy имеет вид таблицы 1, входы, состояния и выходы в которой интерпретируются таблицей 2. Заметим, что строки Logical conditions, относящиеся к условным переходам, определяют входные переменные FSM. 124 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 125. Рис. 1 ASMдиаграмма фазы выборки конвейеризированного процессора Таблица 1. Таблица переходов автомата, формирующего операции выборки инструкций am as X(am, as ) Y a1 a1 x8x4 y8 a1 a7 x8~x4 y6 a1 a1 ~x8 -- a2 a1 x1 y5 a2 a1 ~x1 y7 a3 a2 x3 y1 a3 a5 ~x3x2 y4 a3 a1 ~x3~x2x1 y5 a3 a1 ~x3~x2~x1 y7 a4 a3 1 y2 a5 a6 x7x5 y4 a5 a1 x7~x5 -- a5 a6 ~x7x6 y4 a5 a1 a6 a1 a7 a4 ~x7~x6 1 1 -y4 y3 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 125
- 126. Таблица 2. Структурапеременных автомата в терминах микроопераций процессора Micro Operations y1 : Fetch2 y2 : Fetch1 y3 : Int y4 : PCf:=PCf+1 y5 : Fetch2Oper2 y6 : CheckBranch y7 : Fetch2Oper1 y8 : DMACycle Logical Conditions x1 : ShLodInpBran_in_F x2 : bool2std(IR1f(0to3)=1100) x3 : IR1f(5) x4 : DMA x5 : FGO x6 : FGI x7 : IR1f(4) x8 : S : Пусть функциональную верификацию процессора планируется выполнить с помощью Model Checking, сравнивая поведение на уровне инструкций с поведением автомата в терминах микроопераций таблицы 2. Рассмотрим, например, выполнение следующего свойства: всегда, пока выполняется операция с DMA ((DirectMemory Access), фаза выборки ожидает ее окончания, чтобы избежать конфликтов. Как видно из таблиц 1 и 2, эти свойства связаны с выполнениями условий, задаваемых входными переменными x4, x8, и состояниями a1,a2. Тогда опасность (потенциальная возможность) неверного функционирования в результате SEU, приводящего к переключению того или иного бита, соответствующего переходу к неправильному состояния автомата, может быть также верифицирована с использованием стандартных средств верификации (SMV, Spin), задавая свойства, подлежащие верификации на том или ином языке CTL или LTL-типа (подробно этот вопрос рассматривается в [8]). Учитывая что описанный выше алгоритм построения цепи Маркова для переходов автомата под действием SEU использует целочисленное кодирование состояний, присвоим каждому состоянию ak, k=1,2..7, таблицы 2 значение его индекса. Конкретный SEU, приводящий к сбою на время такта, мы можем описать, как указано выше, задавая единичную вероятность в векторе начальных состояний 2-мерной цепи Маркова Zt . Тогда, назначив вероятности единичных значений переменным x1, ... x8, мы можем оценить вероятность перехода в состояние, при котором на начальном такте работы системы (t=0) выполняется операция DMAcycle до команды “S” (Start), представляющей собой начало вычислений. В предложенной выше нотации этот сбой представляется как (1,2). При распределении входных переменных{x1=0.9, x2=0.8, x3=0.45, x4=0.7, x5=0.65, x6=0.5, x7=0.7, x8=0.7)}, модель дает следующие значения вероятностей возвращения к правильному функционированию автомата таблицы 2 за соответствующее число тактов после 126 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 127. прекращения действия причинысбоя: SH = (0.0, 0.034, 0.46, 0.55, 0.64, 0.68). Скажем, через 4 такта вероятность будет 0.64, что, разумеется не позволяет считать этот сбой несущественным. Однако для сбоя (5,2) (ошибка заполнения программного счетчика) получаем SH = (0.00, 0.79, 0.79, 0,85, 0.89, 0.92, 0.93), что в ряде случаев (в зависимости от требований к быстродействию и надежности проектируемой системы) может быть приемлемым. Соответственно, у разработчика есть некоторая свобода выбора - пытаться ли ввести дополнительную аппаратную защиту данных переменных (например, используя Triple Modular Redundancy (TMR –защиту [17]) или же нет. Заметим, что мы используем для верификации те же средства Abelite, что и для синтеза реальных ASIC или FPGA, и поэтому каждый сбой, описанный на высоком уровне (сбой перехода автоматной переменной), можно связать с аппаратным блоком проектируемой системы, реализующим данный переход. 4. Направление дальнейших исследований Выше мы рассмотрели модель оценки помехоустойчивости для одного конкретного сбоя, специфицированного как (i,j) - ошибочный переход автомата в новое состояние j вместо i, определяемого спецификацией системы. Чтобы построить модель учета действия различных сбоев можно рассмотреть семейство марковских цепей с данной матрицей вероятностей переходов P, Zt,F = Pi, F, P для данного списка возможных сбоев F, задаваемых единицей (единичной начальной вероятностью) в ячейке (i,j) в векторе начального распределения вероятностей P0i , i=1,2,..,│F│, тогда как остальные ячейки – нулевые, как это описано в параграфе 3.2. Тогда [9] мы можем, используя формулу полной вероятности [13], выразить вероятность того, что за время t ни один из сбоев не приведет к ошибке функционирования автомата. Эта вероятность представляет собой характеристику устойчивости автомата, моделирующего проектируемое устройство, к указанному классу сбоев. При этом мы неявно предполагаем, что сбои наступают достаточно редко, и к началу некоторого сбоя (i,j), эффект действия предыдущего (k,l) полностью прекратился. Поэтому для учета вероятности (частоты) возникновения сбоев в настоящее время разрабатывается более общая модель. С методологической точки зрения предложенный нами подход представляет собой дополнение формальной верификации функциональных свойств вычислительной вероятностной моделью отказоустойчивости. При этом, хотя оба подхода используют общее входное описание в виде ASM, ряд данных приходится вводить независимо для каждой из моделей, а именно, свойства (property) на LTL или CTL для формальной верификации (хотя и с возможностью использования некоторых языковых конверторов, упрощающих для разработчика описание указанных свойств), и некоторые распределения вероятностей для оценки вероятности самовосстановления (раздел 3.2). Хотя соответствие (интерпретация) переменных автомата и элементов архитектуры проектируемой системы задается таблицами, подобными 1 и 2, для достаточно сложных систем, особенно для систем с конкуренцией вычислений за ресурсы, может возникнуть проблема непротиворечивости обеих Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 127
- 128. групп описании. Внастоящее время предложено несколько формальных языков (моделей) совместного описания задач функциональной верификации и оценки производительности (Performance evaluation) [14,15]. В этих работах предполагается, что работа системы может моделироваться в терминах теории очередей, т.е. поведение проектируемой системы представляется в терминах обработки запросов некоторым сервером (или несколькими серверами) [15]. При этом функциональная спецификация дополняется вероятностным распределением времени обслуживания “заявок”, что представляется в языках типа PCTL (probability computation tree logic) [16]. Однако, для таких аспектов анализа производительности как отказоустойчивость, подобные модели не вполне естественны. Разработка этого вопроса представляется весьма перспективной. 5. Заключение На ранних этапах разработки программно-аппаратных систем перед инженером – разработчиком часто встает проблема выбора наилучшей программной архитектуры (для данной среды), обеспечивающей максимальную вероятность корректного выполнения данного приложения в данной рабочей среде при заданном уровне случайных ошибок (soft-error rate). Мы выражаем отказоустойчивость (fault-tolerance) работы системы в терминах вероятностей переходов в конечном автомате, моделирующем работу системы. Существенно, что описания автоматов могут быть получены из ASM-диаграмм, используемых для спецификации проектируемой системы, что также позволяет сократить суммарную трудоемкость проектирования. Более того, различные аспекты проектирования устройства, такие, как функционально-временная корректность, устойчивость к сбоям (fault toleranсe), и даже оптимизация потребления электроэнергии системой (low power design) могут быть учтены, поскольку все эти задачи требуют использования FSM модели проектируемой системы, и эта модель автоматически строится по ASM-спецификации системы. При этом вычислительная сложность оценки вероятностей самовосстановления O(n4) для рассматриваемой марковской цепи размера n(n1)+2 существенно ниже вычислительной сложности реализации алгоритмов Model Checking [12], что определяется квадратичной вычислительной сложностью решения линейных уравнений Колмогорова-Чапмена. Литература 1. Egon Börger, Abstract State Machines: a unifying view of models of abstract state machines capture sequential algorithms // Annals of Pure and Applied Logic, 133, (2005), p. 149–171. 2. A. Blass, Y. Gurevich, Abstract state machines capture parallel algorithms // ACM Transactions on Computational Logic, 3, (2002). 3. S. Baranov, ASMs in high-level synthesis of EDA tool Abelite // in Proc. DESD’09 Int. IFAC Workshop, Valensia, Spain, 2009, pp. 195-200. Available: http://www.dcud.uz.zgora.pl/shw/dCUD-Baranov.pdf. 128 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 129. 4. Васильев П.К.Расширение языка машин абстрактных состояний Гуревича рациональным временем // Вестник Санкт-Петербургского университета, Серия 10 «Прикладная математика информатика процессы управления», 2007, с. 90100. 5. S.Baranov, S. Frenkel, V.Zakharov, Semi-formal verification for pipelined digital design based on Algorithmic State Machines // Информатика и ее применения, vol. 4, issue 4, 2010, p. 49- 60. 6. S. L. Frenkel, A. V. Pechinkin, Estimation of self-healing time for digital system under transient faults // Информатика и ее применения, vol. 4, issue 3, 2010, p. 2- 8. 7. S. Frenkel, Some probabilistic and formal techniques for fault tolerant design // Proceedings of 5th IEEE International workshop on Impact of Low Power Designs on Test and Reliability, Annecy, France, Jun. 2012, p. 16-17. 8. S.A. Seshia, W. Li, S. Mitra, Verification - guided soft error resilience // Proceedings of the Conference on Design, Automation and Test, DATE07, 2007, p.1442-1447,. 9. S. Frenkel, Some measures of self-repairing ability for fault-tolerant circuits design // Second Workshop on Manufacturable and Dependable Multicore Architectures at Nanoscale (MEDIAN'13), Avignon, France, May 30-31, 2013, p. 57-60. 10. U.Krautz, M. Pflanz, et al, Evaluating coverage of error detection logic for soft errors using formal methods // Proceedings of the Conference on Design, Automation and Test in Europe, vol. 1, 2006, pp. 1–6. 11. Souheib Baarir et al, Complementary Formal Approaches for Dependability Analysis // 24th IEEE International Symposium on Defect and Fault Tolerance in VLSI Systems, 2009. 12. S. Demri, F. Laroussinie, and Ph. Schnoebelen, A parametric analysis of the state explosion problem in model checking // Proc. 19th Ann. Symp. Theoretical Aspects of Computer Science (STACS'2002), vol. 2285 of Lect. Notes in Comp. Sci., Springer, 2002, p. 620-631.. 13. W. Feller, Introduction to Probability Theory and its Applications // vol. 1, Wiley, 1968. 14. Hermanns H., Herzog U., Katoen J.-P. Process algebra for performance evaluation // Theor. Comp. Sci. 274 (2002), p. 43–87. 15. Coste, et al, Quantitative evaluation in embedded system design: Validation of multiprocessor multithreaded architectures // In: DATE. IEEE (2008), p. 88–89. 16. Hansson H. and Jonsson B. A logic for reasoning about time and reliability // Formal Aspects of Comp. 6, 5 (1994), p. 512–535. 17. O. Ruano, J. A. Maestro, P. Reviriego, A fast and efficient technique to apply Selective TMR through optimization // Microelectronics Reliability, 51, 2011, p. 2388–2401. 18. K.L. McMillan, The SMV language // CadenceBerkey Lab, 1998. 19. G.J. Holzmann, The Model checker SPIN // IEEE Transaction on Software Engineering, vol.23, 1997, p. 76-95. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 129
- 130. Особенности разработки программногообеспечения для Linux-контроллеров М.А. Смирнов, В.В. Олоничев, Б.А. Староверов Костромской государственный технологический университет amt@kstu.edu.ru Аннотация. В статье рассмотрены некоторые особенности разработки программного обеспечения для современных встраиваемых систем, работающих под управлением операционной системы Linux. Описанный подход является альтернативой для средств проектирования стандарта МЭК и предназначен для реализации эффективных алгоритмов цифрового управления технологическими установками. Ключевые слова. Программируемый логический контроллер, операционная система Linux, процессор ARM, кросс-компиляция, toolchain, реализация на языке Си, цифровое адаптивное управление, sshпротокол, научная библиотека GNU GSL, средства межпроцессного взаимодействия. 1 Введение На сегодняшний день ведущие производители промышленных компьютеров (JetBox, Atmel, Techbase и др.) и программируемых логических контроллеров (WAGO, ICP DAS, NPE и др.) предоставляют пользователям возможность реализовывать гибкие и эффективные алгоритмы цифрового управления на языках высокого уровня благодаря поддержке многозадачной операционной системы (ОС) Linux [1]. В современном ядре ОС Linux большинство системных вызовов являются вытесняемыми и имеются таймеры высокого разрешения. Вследствие этого Linux начинает занимать области, ранее принадлежащие классическим ОС реального времени, таким как QNX, OS-9 и VxWorks [2–4]. Поддержка спецификации POSIX данными ОС позволяет сравнительно легко переносить программы между ними. К преимуществам Linux-устройств можно отнести также низкую цену (в своем сегменте средств автоматизации), открытую архитектуру, низкие требования к аппаратным ресурсам [5]. В связи с высокими требованиями, предъявляемыми сегодня к качеству выпускаемой продукции, разработка программного обеспечения (ПО) под описываемые вычислительные системы весьма актуальна [6–8]. В то же время, 130 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 131. как показывает практикаработы с Linux-контроллерами отечественного производства (например, ПЛК серии 304/308 фирмы «Овен»), пользователь по причине отсутствия универсальных пошаговых инструкций сталкивается с серьезными не для профессионала проблемами. К ним можно отнести следующие [9]: ─ необходимость модификации и конфигурирования ядра Linux; ─ необходимость поиска и построения инструментального пакета (toolchain); ─ необходимость библиотек; интеграции дополнительных драйверов, приложений, ─ необходимость тестирования, отладки и масштабирования проекта. Указанные причины, по мнению авторов, сдерживают широкое применение Linux-контроллеров и заставляют разработчиков использовать ограниченные возможности языков стандарта МЭК (язык структурированного текста, функциональных блоков, релейных схем и др.). Изложенный далее материал позволяет ликвидировать проблему масштабирования и быстрого реконфигурирования встраиваемого программного обеспечения. Что касается переноса исполняемых файлов с персонального компьютера (ПК) на целевую платформу, то рассмотрено конкретное решение для процессора ARM AT91RM9200 фирмы ATMEL, на базе которого работает большое количество отечественных и зарубежных контроллеров, в частности ПЛК304/308 «ОВЕН». Наиболее важные рекомендации по общему порядку действий даны в работах [9, 10]. 2 Мультипроцессный комплекс управления технологическими установками Для класса апериодических объектов с одной доминирующей постоянной времени, подверженных за технологический цикл девиации параметров в широких пределах, что в свою очередь требует перенастройки коэффициентов регулятора, разработана адаптивная многопроцессная управляющая система, функциональная схема которой представлена на рис. 1 [11]. За основу принята классическая САУ с регулятором состояния и наблюдателем [12]. Идентификатор однократно или в темпе с процессом вычисляет параметры технологического объекта управления, которые в свою очередь используются для расчета коэффициентов настройки динамического регулятора. В состав мультипрограммного продукта входят следующие процессы [13]: «диспетчер», «регулятор состояния», «наблюдатель полного порядка», «адаптатор», «задающее устройство эталонного сигнала», «цифровая модель объекта управления», «связь с реальным объектом», «идентификаторы» («пассивный идентификатор», «идентификатор однократного действия», «идентификатор многократного действия»). Данный комплекс реализован на Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 131
- 132. языке Си спомощью GNU Scientific Library (GSL) v1.3 – библиотеки для научных расчетов. В качестве средств межпроцессного взаимодействия используется разделяемая память и семафоры System V. Рис. 1. Цифровая адаптивная самонастраивающаяся система управления: ОУ – объект управления; И – идентификатор; А – адаптатор; Н – наблюдатель; РС – регулятор состояния Главное преимущество мультипроцессной организации цифровой системы управления заключается в том, что на основе небольших узкоспециализированных программ можно собирать целые комплексы произвольной конфигурации и теоретически неограниченной сложности (именно такой подход отвечает идеологии ОС UNIX [14]). В частности, в зависимости от требований технологического процесса «идентификаторы» реализованы в трех вариантах: «пассивный идентификатор», «идентификатор однократного действия», «идентификатор многократного действия» [11]. Процесс «диспетчер» призван координировать работу всех остальных программ. При запуске он получает два параметра: первый задает режим работы (0 – асинхронный, 1 – синхронный), второй – имя конфигурационного файла. При асинхронном режиме обмен данными между процессами осуществляется по их готовности и происходит с максимально возможной для данной вычислительной системы скоростью. Данный способ взаимодействия применяется для моделирования поведения системы управления и может быть использован при отладке и тестировании программ на ПК. При синхронном режиме все вычисления и межпроцессная коммуникация происходят по команде от источника синхросигнала, которым является таймер реального времени. Он генерирует импульсы с заданным пользователем периодом квантования. Описанный способ взаимодействия используется для управления работой технологической установки в режиме реального времени. Конфигурационный файл содержит следующую информацию: количество регуляторов в системе управления, количество процессов-участников, не 132 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 133. включая «диспетчер», количествосемафоров, а также порядок объекта управления и период квантования. Структурная схема установки, на которой была развернута мультипроцессная система адаптивного управления представлена на рис. 2. Она включает в себя персональный компьютер, сетевой коммутатор, ПЛК308 фирмы «Овен», модуль аналогового ввода МВА8 фирмы «Овен», модуль дискретного ввода-вывода МДВВ фирмы «Овен», твердотельное реле фирмы «Fotek», электрическую печь (объект управления) и датчик температуры. Рис. 2. Структурная схема САУ: 1 – кабель Ethernet; 2 – кабель RS-485; 3 – широтноимпульсный сигнал (ШИМ); 4 – сигнал обратной связи В ходе своей работы программный комплекс считывает по RS-485 c МВА8 сигнал с датчика (датчиков) температуры и выдает в соответствии с заложенным алгоритмом управляющее воздействие в виде процентного изменения мощности на модуль МДВВ, тот в свою очередь формирует на выходе ШИМ сигнал, а твердотельное реле коммутирует нагрузку (электрический нагреватель). Контролируемые параметры могут быть переданы на персональный компьютер или панель оператора. Для этого целесообразно использовать сетевые сокеты. Результаты работы мультипроцессной системы адаптивного управления представлены на рис. 3 на примере решения задачи стабилизации температуры печи при уменьшении напряжения питания с 220 В до 120 В, начиная с 4000 с. Как видно из рис. 3 а, применение традиционного ПИД-регулятора не позволяет оперативно отреагировать на возмущение и приводит к недопустимому снижению температуры, в то время как адаптивная система (рис. 3 б) обеспечивает высокие статические и динамические показатели. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 133
- 134. а) б) Рис. 3. Исследованиеработы мультипроцессной системы управления на незагруженной печи при внесении возмущающего воздействия: а) работает неадаптивная система; б) работает адаптивная система 3 Подготовка и запись исполняемых файлов в контроллер Для компиляции и генерации исполняемого кода для целевой платформы (ПЛК308), работающей под управлением процессора ARM9, на ПК с ОС Linux (uCLinux v 2.6), установлен и сконфигурирован набор необходимых программ – toolchain фирмы «Ronetix» – ronetix-arm-linux-uclibc-4.1.2 [15], благодаря которому можно осуществить кросс-компиляцию исходных кодов. Диаграмма развертывания описываемой системы представлена на рис. 4. 134 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 135. Рис. 4. Диаграммаразвертывания мультипрограммной системы управления При выборе toolchain необходимо знать процессор целевой платформы. Также следует проверить корректное выполнение собранных вместе со специальными библиотеками программ на ОС, установленной на ПЛК. Для сборки программ можно использовать следующий скрипт, получающий имя исходного файла в качестве параметра командной строки: F=$1 Fo=$F.o Fc=$F.c Fa=$F.arm arm-linux-gcc -I/usr/local/include -o $Fo -c $Fc arm-linux-gcc -o $Fa $Fo Для сборки программы вместе со специальными библиотеками (в нашем случае использовались статические библиотеки gsl) их следует указать явно: Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 135
- 136. F=$1 Fo=$F.o Fc=$F.c Fa=$F.arm arm-linux-gcc -I/usr/local/include -o$Fo -c $Fc arm-linux-gcc -o $Fa $Fo ./lib/libgsl.a ./lib/libgslcblas.a Для копирования исполняемых файлов на ПЛК можно воспользоваться различными приемами, а именно: ─ Применяем команду scp, использующую безопасный шифрованный протокол ssh. Например: scp ./myprog root@plc308:/home/arm/myprog. При необходимости можно составить пакетный файл, копирующий за один прием несколько файлов. ─ Если важна наглядность, можно использовать консольный файловый менеджер mc, настроив одну из его панелей на удаленное подключение по тому же протоколу ssh: /#sh:root@plc308/home/arm. Представленная технология разработки и способ переноса программ прошли испытание на реально работающем оборудовании и подтвердили свою эффективность. 4 Выводы В статье рассмотрены особенности разработки программного обеспечения для ПЛК-Linux и способ переноса программ на целевую платформу. Описанный подход может быть использован разработчиками программного обеспечения для встраиваемых Unix-систем. Библиографический список 1. Все для автоматизации. Встраиваемые компьютеры, АСУ ТП, коммуникации, http://empc.ru/e-store/compact_pc_ark/ 2. VxWorks, http://www.windriver.com/products/vxworks/ 3. QNX, http://www.qnx.com 4. OS-9, http://www.radisys.com/products/microware-os-9/ 5. Горбунов Н. О выборе встраиваемой ОС для проекта // СТА. – 2011. – №2. – С. 22-28 6. Ицкович Э.Л. Проблемы развития контроллеров российских производителей // Промышленные АСУ и контроллеры. – 2007. – №2 136 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 137. 7. Ицкович Э.Л.Методы совершенствования систем регулирования технологических процессов // Промышленные АСУ и контроллеры. – 2011. – №1. – С. 3-9 8. Колесников А.А. Промышленный компьютер на базе Linux со встроенным GSMмодулем // ИСУП. – 2009. – №1 9. Даммер С. О реальной стоимости «доморощенной» Linux // СТА. – 2010. – №4. – С. 20-26 10. Zimmerly B. Install the GNU ARM toolchain under Linux // EN, developerWorks, May, 2009 11. Староверов Б.А., Олоничев В.В., Смирнов М.А. Реализация законов адаптивного управления технологическими установками на Linux-контроллерах // Промышленные АСУ и контроллеры. – 2012. – №7. – С. 48-53 12. Изерман Р. Цифровые системы управления. М.: Мир, 1984. – 541 с. 13. Олоничев В.В., Смирнов М.А., Староверов Б.А. Мультипроцессный комплекс цифрового управления технологическими установками. Свидетельство о государственной регистрации программы для ЭВМ № 2011611749. © М.: РОСПАТЕНТ, 2011 14. Реймонд Э. Искусство программирования для Unix. – М.: Издательский дом «Вильямс», 2005 15. Toolchain ronetix, http://www.ronetix.at Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 137
- 138. Об усовершенствовании статистическогометода оценки полноты тестов программ и устройств Басок Б. М., Гречин А.А.1 1 Московский государственный технический университет радиотехники, электроники и автоматики, 119454, Россия, г. Москва, Проспект Вернадского, 78 vm_e@mail.ru Aннотация. Рассматривается статистический метод проверки полноты тестов, основывающийся на анализе результатов работы программ и математических моделей дискретных устройств с внесѐнными дефектами. В работе предлагается существенно сократить временные затраты при оценке качества тестов данным методом, с одной стороны, путѐм внесения кратных дефектов, с другой, – путѐм взаимного использования результатов анализа тестов объекта тестирования и отдельных его компонентов. Приводятся экспериментальные данные, подтверждающие эффективность предлагаемых подходов. Ключевые слова: полнота тестов, анализ тестов, кратные отказы, мутации. 1 Введение. Постановка задачи Важнейшей характеристикой тестов программных систем (ПС) и дискретных устройств (ДУ) является их полнота. Под полнотой теста или его проверяющей способностью принято понимать [1,2] выраженное в процентах отношение выявляемых данным тестом отказов заданного класса к общему их числу. От полноты тестов напрямую зависит качество контролируемого объекта. Поэтому задача синтеза тестов высокой полноты является одной из важнейших задач контроля любого продукта на всех этапах его разработки и эксплуатации. При этом следует отметить, что, как правило, тесты ПС и существенная часть тестов ДУ создаются и отлаживаются вручную, и разработка новых дополнительных тестов для повышения полноты контроля требует больших затрат времени и средств. Обычно при проверке полноты функциональных тестов ПС используются методы, основывающиеся на покрытии кода программы или методы, базирующиеся на оценке количества охваченных тестом отдельных функций ПС [3]. Наряду с данными методами для проверки полноты тестов используется метод, основывающийся на анализе результатов выполнения тестов для ПС с искусственно введенными одиночными постоянными дефектами из списка отказов заданного класса и исходной ПС. При этом предполагается, что данный метод применяется после того, когда все собственные дефекты, обнаруженные данными тестами, исправлены, и влияние не обнаруженных ими собственных 138 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 139. дефектов ПС невелико.Указанный метод является некоторым аналогом классического метода, применяемого при анализе тестов ДУ и основывающегося на сравнении результатов моделирования исправной и неисправной ДУ[4]. Известны два подхода при реализации данного метода. Первый из них [5,6] основывается на внесении дефектов непосредственно в объектный код ПС. Такими дефектами могут быть, например, инверсия бита или байта объектного кода программы. Второй подход, получивший название мутационного анализа [7-10], основывается на внесении в исходный текст программы незначительных дефектов (мутантов). По определению [7] мутант – это одиночное синтаксически корректное изменение подлежащей тестированию ПС. Специальные программы – генераторы мутантов - формируют их списки. Мутанты, входящие в список, осуществляют либо замещение констант, либо замещение переменных, либо замещение операторов. Генераторы мутантов строятся на основе синтаксического анализа исходного кода ПС[7]. Первый подход применим, в первую очередь, при анализе тестов ПС, для которых отсутствует доступ к исходному коду.В то же время, для обеспечения безопасности работы эксплуатируемых ПС необходимо убедиться в высокой степени их надежности. Поэтому в любой момент может возникнуть необходимость в оценке качества предоставленных пользователю функциональных тестов, поскольку в редких случаях технологии разработки ПС, применяемые разработчиками включают обязательный этап тестирования безопасности [6]. Второй метод особенно полезен, поскольку с его помощью можно точно установить место внесенного дефекта и разрабатывать дополнительные тесты для выявления дефектов, не обнаруженных анализируемыми тестами. Кроме того, при реализации второго подхода, в отличие от первого, отсутствует опасность того, что внесение искусственного дефекта в ПС исказит операционную среду. Впрочем, данный недостаток можно преодолеть путем запуска ПС в системе виртуальных машин. При этом отказ, внесение которого приводит к искажению операционной среды, можно считать выявляемым. Описанные подходы применимы и при тестировании поведенческой модели ДУ на языке описания аппаратуры HDL, в частности на VHDLи Verilog,и анализе собственно тестов ДУ, представленных этой моделью [9,11].Например, в [9] описаны принципы разработки генератора мутаций для ПС на VHDL. Главным недостатком, как первой, так и второй реализации рассматриваемого метода оценки полноты тестов ПС являются чрезвычайно большие затраты времени, как следствие наличия большого количества мутантов или возможных искажений разрядов объектного кода ПС. Даже при тестировании сравнительно небольших ПС их количество может достигать многих десятков тысяч. При тестировании программ, содержащих несколько тысяч операторов, это число может многократно увеличиться. Например, при тестировании программы, реализующей метод Монте-Карло, генератор выдал более девятисот тысяч мутантов [10]. В некоторых работах [7] были рассмотрены методы сокращения множества Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 139
- 140. рассматриваемых мутантов путемвыделения групп эквивалентных мутантов и при оценке полноты тестов анализировать только одиночных представителей этих групп. Однако, как показано в [7], список анализируемых отказов сокращается не более чем на 8% - 10%. Другой подход, основывается на замене общего списка мутантов некоторой его выборкой, как правило, это некоторая часть общего списка, например, в [7] случайным образом выбирается 10% общего списка дефектов. Тем не менее, выбранный список оказывается достаточно большим. Кроме того в подобных работах отсутствует обоснование размеров выборки. В этом случае обычно полагаются на накопленный в данной области опыт. Для существенного сокращения времени при реализации метода оценки полноты в работе [12] предложен и обоснован способ, известный как статистический. В соответствии с этим способом при анализе тестов используется не полное множество отказов, а некоторая небольшая случайная выборка. Согласно [12] для случайной выборки из 400 отказов заданного класса можно гарантировать, что полнота тестового набора для всей совокупности отказов заданного класса отличается не более чем на 5% от истинного значения с достоверностью 0,95. Величина выборки не зависит от сложности и размеров объекта тестирования. Таким образом, количество модифицированных неисправных копий анализируемого объекта (ПС или ДУ) оказывается фиксированным и сравнительно небольшим. Статистический способ оценки полноты был программно реализован и показал свою эффективность при многолетней эксплуатации программного комплекса моделирования, синтеза и анализа тестов, разработанного в ИНЭУМ и внедренного в ряде организаций, а также при анализе полноты тестов СБИС повышенной сложности с помощью первого в Советском Союзе многопроцессорного программно-аппаратного комплекса-ускорителя логического моделирования, разработанного в ИНЭУМ [13]. В работах [5,11] обсуждаются возможности применения статистического способа оценки полноты при мутационном подходе и искажении объектного кода программы. Однако, несмотря на ряд преимуществ статистического способа проверки полноты абсолютная величина временных затрат при его использовании остается весьма значительной. В первую очередь, это касается затрат времени при анализе тестов программ с невысокой проверяющей способностью. Так при анализе пяти тестов программы размер исполнительного модуля которой составляет 18 кбайт, понадобилось 1708 прогонов данной программы. Если предположить, что время выполнения программы составляет одну минуту, то временные затраты составят более 28 часов. При этом несмотря на то, что имеется такой источник сокращения времени, как возможность распараллеливания процесса оценки полноты, к примеру на нескольких компьютерах, величина временных затрат остается существенной. В данной работе рассматриваются два подхода к сокращению времени оценки статистической полноты тестов. Первый подход основывается на анализе тестов в классе одиночных константных отказов путѐм внесения кратных дефектов из данного класса. Второй подход базируется на совместном 140 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 141. анализе интеграционных тестовобъекта контроля и тестов отдельных его частей. 2 Метод внесения кратных отказов В работе одного из авторов данной статьи [14] был предложен метод анализа тестов ДУ, называемый методом моделирования кратных отказов. В соответствии с этим методом процесс проверки полноты тестов можно ускорить, если вносить не одиночные, а кратные отказы. Последние можно получить путѐм случайного разбиения списка невыявленных предыдущими тестами отказов на небольшие непересекающиеся группы одного размера (возможно последняя из групп окажется меньше). Отказы объединяются в группы случайным образом. При этом в соответствии с гипотезой о редкой компенсации кратных отказов [1,11] считается, если тестом не выявляется полученный таким образом кратный отказ, то не выявится и не один из одиночных дефектов, входящих в данную группу. В том случае, если состояния выходов модели объекта тестирования с внесѐнным кратным отказом отличаются от состояний одноименных выходов модели исправного объекта, следует проверить возможность выявления тестом дефектов, образующих кратный отказ по одному. В работе [14] обосновывается близкий к оптимальному размер групп для списка дефектов, оставшихся не выявленными после анализа группы первых тестов и относящихся к классу трудно проверяемых отказов. В соответствии с приводимыми в работе [14] оценками применение указанного метода повысит скорость анализа качества тестов в несколько раз. В докладе применяется подход, использующий, с одной стороны, статистический способ проверки полноты тестов, с другой, – метод кратных отказов. Этот подход применим как для ПС, так и для ДУ. В соответствии с данным подходом не выявленные очередным тестом отказы из выборки [5,12] разбиваются на группы. Размер группы определяется исходя из минимизации математического ожидания случайной величины количества прогонов теста [14]. Общее количество прогонов теста определяется как сумма двух слагаемых: количества прогонов равных количеству полученных групп отказов и количества прогонов равного количеству одиночных дефектов, образующих обнаруженные кратные дефекты. Таким образом, величина группы при анализе полноты теста i может быть определена путем минимизации функции, имеющей следующий вид: F (Gi ) Gi N Li 1 j 1 1 1 i N j 1 Gi j 1 i (1) где Li 1 - количество выявленных дефектов на предыдущем (i-1)-ом тесте, Ni – количество дефектов заданного класса, оставшихся невыявленными после анализа предыдущих (i-1) тестов. Размер группы для анализа качества первого теста можно принять равным единице, учитывая тот факт, что первые тесты обычно обладают хорошими Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 141
- 142. проверяющими свойствами. Сдругой стороны, как показали эксперименты, эту величину можно увеличить до трѐх. Если очередной тест не выявил ни одного отказа, то переменной в функции (1) можно присвоить не равное нулю значение аналогичной переменной, определенное ранее для ближайшего из предыдущих тестов. Данный подход был апробирован при анализе тестов группы промышленных консольных приложений (консольный тип был выбран для удобства автоматизации процесса проверки полноты), работающих в операционной среде Windows. В качестве моделей отказов использовались постоянные дефекты типа инверсии бита/байта. Результаты анализа тестов методами одиночных и кратных отказов с использованием статистической выборки моделируемых отказов показали, что количество прогонов после первых пяти тестов при реализации метода кратных отказов сокращается в три раза, а при анализе полноты десяти тестов выигрыш во времени может достигнуть одного порядка. В Таблицах 1 и 2 приведены некоторые экспериментальные данные. Испытания проводились для пяти тестов, проверяющих работу программы, исполнительный модуль которой занимает примерно 18 килобайт. Таблица 1. Статистика прогонов тестов для одиночных отказов. Номер теста Кол-во отказов Размер группы Кол-во групп Кол-во выявл. отказов 66 Всего прогонов 400 Кол-во выявл. групп 66 1 400 1 2 334 1 334 5 5 334 3 4 329 1 329 2 2 329 327 1 326 1 1 327 5 318 1 318 9 9 318 400 1708 Итого Таблица 2. Статистика прогонов тестов для кратных отказов. Номер теста Кол-во отказов Размер группы Кол-во групп Кол-во выявл. отказов 66 Всего прогонов 134 Кол-во выявл. групп 55 1 400 3 2 334 3 329 3 112 5 5 127 9 37 2 2 55 4 327 10 33 1 1 43 5 318 10 33 8 9 113 Итого 299 637 Средняя статистическая полнота тестов - 21%. 142 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 143. Увеличение выигрыша вовремени от теста к тесту объясняется резким сокращением количества выявляемых отказов и тем, что в списке не выявленных отказов остаются отказы, относящиеся к подмножеству так называемых «трудно проверяемых». Данные, помещенные в Таблицы 1 и 2, наглядно показывают выигрыш во времени при использовании метода кратных отказов по сравнению с методом внесения одиночных отказов примерно в 2,7 раза. Кроме того, проведенные эксперименты продемонстрировали, что эффективность метода кратных отказов тем выше, чем меньше полнота тестов. При этом экспериментально установлено, что существует некоторый порог полноты анализируемого теста (30%-40%), при превышении которого использование кратных отказов нецелесообразно. Однако следует заметить, что, как правило, полнота отдельных тестов в классе рассматриваемых отказов не превышает 25%. Полученные результаты показали, что отказы из случайной выборки, объединенные в группу, мало влияют друг на друга. Это позволяет предполагать, что подобный алгоритм будет особенно полезен при реализации мутационного подхода. 3 Совместный анализ интеграционных контроля и тестов его отдельных частей тестов объекта Как правило, полнота анализируемых тестов не является удовлетворительной, и для выявления не обнаруженных отказов следует разрабатывать дополнительные тесты. Это весьма трудоѐмкий процесс. Поэтому в данной работе предлагается, прежде чем приступить к синтезу дополнительных тестов, использовать для повышения полноты интеграционных тестов системы возможности тестов компонентов, и наоборот: использовать результаты оценки полноты интеграционных тестов для повышения качества проверки отдельных компонентов. Использование такого подхода сократит количество не выявляемых указанными тестами дефектов и, следовательно, сократит время для разработки дополнительных тестов. Следует отметить, что в работе [15] предлагался оригинальный метод компонентного тестирования информационных систем, позволяющий на основе выделения наиболее часто встречающихся типов ошибок в программе выявлять их на уровне компонентов программ. Суть предлагаемого в настоящей работе подхода заключается в следующем. Вначале осуществляется синтез тестов компонентов, поиск и исправление дефектов обнаруженных с их помощью в этих компонентах. После завершения данного этапа контроля аналогичные процедуры выполняются для системы с применением интеграционных тестов системы. Теперь, после выявления и исправления всех обнаруженных тестами компонентов и тестами системы отказов можно приступить к оценке статистической полноты данных тестов в классе одиночных отказов (например, мутантов). Очевидно, что как дефекты, не выявляемые тестами системы, могут Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 143
- 144. быть выявлены тестамикомпонентов, так и невыявленные отказы компонентов могут быть обнаружены тестами системы. Поэтому следует проанализировать возможность выявления непроверенных отказов интеграционных тестов системы тестами компонентов, которым эти отказы принадлежат. Для этого предлагается взять список непроверенных отказов после определения статистической полноты и путѐм последовательного внесения этих отказов в соответствующие компоненты определить, выявляют тесты компонентов эти отказы или нет. Аналогичную процедуру можно применить для анализа списка непроверенных отказов компонентов. В этом случае непроверенные отказы компонентов последовательно вносятся в компонент, собирается версия системы и выполняются интеграционные тесты. Как показали эксперименты, интеграционные тесты выявляют не менее 10% из невыявленных тестами компонентов отказов-мутантов. Заключение В работе рассматривался статистический метод оценки полноты тестов ПС и ДУ, обсуждались его достоинства и недостатки. Для модификации данного метода были предложены два подхода. Первый из них основывается на использовании кратных отказов вместо одиночных. Его применение позволит сократить время проверки полноты тестов в несколько раз. При этом показано, что в отличие от предложенного в [14] метода данный подход можно применять, начиная с первого теста. Второй подход использует пересечение множеств отказов контролируемого объекта и его отдельных компонентов. Благодаря этому удается повысить полноту, как интеграционных тестов, так и тестов отдельных компонентов ПС и ДУ и сократить время разработки дополнительных тестов. В качестве дальнейших исследований в области оценки качества тестов нам представляется актуальным продолжать работы в области сокращения временных затрат. Одним из путей здесь видится сокращение выборки из множества отказов за счет некоторой потери точности как это предлагается, например, в [5,16]. Перспективным направлением является применение статистических методов для оценки качества и отказоустойчивости встроенных систем, когда имитация отказов сводится к внесению искусственных неисправностей в программное обеспечение этих систем [17]. Литература 1. Гробман Д.М. Программный контроль и диагностика неисправностей ЦВМ. // Диагностика неисправностей вычислительных машин. М.: Наука. 1965 г. С. 7 – 22. 144 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 145. 2. Скобцов Ю.А., Сперанский Д. В., Скобцов В.Ю.Моделирование, тестирование и диагностика цифровых устройств. // Учебное пособие. М.: ИНТУИТ. 2012 г. 440 с. 3. Синицин С.В., Налютин Н.Ю. Верификация программного обеспечения. // Учебное пособие. М.: Бином. 2008 г. 307 с. 4. Seshu S. On an Improved Diagnosis Program // IEEE Trans. on Elec. Com-puters. 1965. Vol. 12, February, p. 76-79. 5. Корчемный Д.И. Оценка полноты тестирования методом последовательного анализа. // Вопросы радиоэлектроники. Сер. ЭВТ. 1980 г. Вып.17. С. 68 – 74. 6. Благодаренко А.В. Статистический и динамический анализ программного обеспечения без исходных текстов. // Проблемы информационной безопасности в системе высшей школы: труды XIV всероссийской научной конференции.–М.:МИФИ, 2007г. С. 33-34. 7. Mattias Bybro. A Mutation Testing Tool for Java Programs, Ett verktyg för mutationstestning av Javaprogram Examensarbete i Datalogi, 2003, 20p., http://www.nada.kth.se/~karlm/a_mutation_testing_tool_for_java.pdf. 8. Harman M., YueJia, Langdon W.B. A Manifesto for Higher Order Mutation Testing, Software Testing, Verification, and Validation Workshops (ICSTW), 2010 Third International Conference on, 2010, 6-10 April, p.80-89. 9. Lorez C., RiesgoT.,De la Torre E.,Useda J. A method to perform error simulation in VHDL // Desing of Circuits and Integrated Systems Conference. Madrid (Spain), 1998. p. 495-500. 10. Offutt A.J., Untch R.H. Mutation 2000: Uniting the Orthogonal // Mutation Testing in the Twentieth and the Twenty First Centuries San Jose, 2000. p. 45-55. 11. Басок Б.М., Гречин А.А. О едином подходе при анализе тестов дискретных устройств и программ. // Вопросы радиоэлектроники. Сер. ЭВТ. 2010 г. Вып.3. С. 140 – 145. 12. Гробман Д.М. Статистический способ определения полноты тестов. // Тезисы докладов IV Всесоюзного совещания по технической диагностике. Черкассы. 1979 г. С. 9 – 11. 13. Сергеев Б.Г., Басок Б.М., Бродский М.А. Использование аппаратных средств моделирования в САПР СБИС. // Автоматизация логического проектирования средств вычислительной техники: труды первой международной конференции «САПР СВТ 89» Л., 1989 г. С. 25-31. 14. Басок Б.М. Об одном методе оценки качества тестов дискретных компонентов вычислительных сетей. // Автоматика и вычислительная техника. 1985 г. №1. С. 56 – 58. 15. Кораблин Ю.П., Куликова Н.Л., Чумакова Е.В. Компонентное тестирование и его реализация. // Учебное пособие. М.: Союз, 2009 г. 23 с. 16. Рабинович Ю.Г. Ускорение статистического метода проверки полноты теста с использованием специализированных средств моделирования.// Труды Всесоюзного семинара «Специализированные процессоры в САПР». Тез.докл. - Москва, 1989. С. 1718. 17. Thorhuus R. Software Fault Injection Testing. // Master of Science Thesis in Electronic System Design. Stockholm, Sweden: KungligaTekniskaHögskolan, 2000, 58 с. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 145
- 146. Анализ производительности сетевой подсистемымикроядерного окружения Genode Василий Сартаков and Александр Тарасиков ksys labs Аннотация Микроядерные операционные системы имеют долгую историю развития, однако на сегодняшний день большинство из них остаётся экспериментальными исследовательскими проектами. В данной работе представлен опыт использования микроядра L4 Fiasco.OC и окружения Genode для построения сетевой инфраструктуры, приведен анализ ее производительности, а так же рассмотрены архитектурные особенности микроядра и программного окружения влияющие на пропускную способность сетевой подсистемы. 146 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 147. 2 1 Введение Современное сетевое оборудованиеобладает большим функционалом, реализация которого уже давно не возможна только на аппаратном уровне. Как следствие, такое оборудование содержит в себе специализированный процессор, на котором исполняется операционная система и прикладное программное обеспечение. Операционная система в сетевом оборудовании несет на себе основную нагрузку по обеспечении безопасности и реализации основного функционала, как следствие, для разработки доверенных решений операционная система должна обладать повышенными средствами защиты от проникновения и отказов. Микроядерные операционные системы - это такие операционные системы, в которых большая часть функциональности ядра реализована в виде отдельных сервисов. Подобные системы находятся в разработке с 1970-х годов; некоторые проекты достигли коммерческого успеха и применяются в промышленности. Однако, особенности архитектуры микроядра могут накладывать ограничения на производительность и границы применимости таких систем [5]. Основные механизмы обеспечения безопасности в микроядерной среде выполнение всех процесов в депривелигированном (пользовательском) режиме и использование системы межпроцессного взаимодействия вместо прямого обращения к памяти другого процесса[6]. Большая часть функциональности, такой как драйвера устройств, файловые системы, управление памятью, реализуется в виде независимых процессов, выполняющихся в пространстве пользователя. Компрометация одной из подсистем ядра не дает атакующему доступ в привелигированный режим, в то время, как в получивших большее распространение монолитных ОС, где все системные компоненты выполняются в пространстве ядра (режиме супервизора), такая угроза есть. В данной статье представлен опыт создания сетевого оборудования на основе экспериментального микроядра Fiasco.OC в окружении Genode. Используемое микроядро, с одной стороны, обладает высоким потенциалом с точки зрения безопасности, поскольку вынесение критического функционала из ядра в пространство пользователя, а так же жесткая изоляция компонентов 1 уменьшают количество векторов атак и повышает отказоустойчивость. С другой стороны, изоляция компонентов ядра приводит к интенсивному межпроцессному обмену, что может негативно влиять на производительность сетевого оборудования. Для оценки производительности такого оборудования был разработан прототип аппаратно-программного комплекса, решающего задачу изоляции сетевый сервисов при помощи паравиртуализации. В качестве гипервизора 1 Под изоляцией подразумевают использование раздельных адресных пространств и использование принципа наименьших привилегий в выделении ресурсов Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 147
- 148. 3 было использовано экспериментальноемикроядро Fiasco.OC, виртуальные машины реализованы на основе паравиртулизированного ядра L4Linux[4]. Результирующие тесты производительности системы показали деградацию пропускной способности сети в сравнении с системами построенными на монолитно-модульном ядре Linux. Для выявления причин деградации был разработан набор программного обеспечения для профилирования ядра и окружения. Этот набор инструментов позволил выявить компоненты программного окружения, вносящие наибольший вклад в падение производительности сетевой подсистемы, а также отличия в поведении микроядра Fiasco.OC на одно- и многопроцессорных системах. Статья имеет следующую структуру: В первой главе представлена архитектура экспериментального аппаратно-программного комплекса, а так же результаты нагрузочного тестирования. Во второй главе описана методология профилирования и ее результаты. В третьей главе представлен анализ профилирования, а в четвертой главе приведены рассуждения о методах повышения производительности. В заключительной, пятой главе, подводятся итоги работы и формулируются планы на дальнейшую работу. 2 2.1 Аппаратано-программный комплекс «Шлюз» Функциональное назначение Гарантированное разделение ресурсов в вычислительных системах - одна из основных задач информационной безопасности. При этом есть необходимость как ограничить доступ к вычислительным ресурсам внутри одной машины, так и контролировать потоки данных между различными сетевыми устройствами. При проектировании корпоративной локальной сети, необходимо изолировать безопасный сегмент сети (сетевое хранилище и автоматизированные рабочие места работников, обрабатывающих внутрикорпоративные документы) и сетевые устройства, имеющие доступ в интернет или другие публичные сети. Возникает задача контроля входящих сетевые соединения для того, чтобы блокировать трафик от недоверенных узлов. Кроме того, требуется производить мониторинг сетевого трафика для обнаружения специальным образом сформированных сетевых пакетов, направленных на повышение привелегий злоумышленника путем эксплуатации уязвимостей в программном и аппаратном обеспечении. Зачастую требуется предоставить доступ к части внутрисетевых ресурсов. Например, внутри безопасной локальной сети пользователям могут быть доступен сервис сетевого хранения данных, реализованный в виде сетевого диска. Если определенные файлы необходимо сделать доступными из внешней сети, может использоваться веб-сервер для выдачи индивидуальных файлов. Помимо возможности проведения дополнительной авторизации пользователей средствами веб-интерфейса, такое решение скрывает от потенциальных злоумышленников физическую топологию внутрикорпоративной сети. 148 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 149. 4 Ряд приложений требуетпередачи конфиденциальных данных по незащищенному (публичному) каналу. Для организации безопасного обмена данными используются туннели с шифрованием трафика. При этом требуется гарантировать, что ключи, использующиеся для шифрования, не будут скомпрометированы. Поэтому необходим механизм разделения вычислительных процессов внутри узла сети, реализующего туннель. Рассмотренные выше задачи решаются использованием сетевого шлюза, то есть, сетевого устройства, имеющего связь с безопасным и небезопасным сегментами сети, и ограничивающего обмен данными между ними. Схема топологии сети с применением сетевого шлюза приведена на рисунке 1. Далее представлена реализация сетевого шлюза с использованием микроядера Fiasco.OC. Рис. 1. Схема сети с использованием шлюза 2.2 Реализация Рассмотрим одну из возможных реализаций описанного выше сетевого шлюза. В качестве аппаратной части комплекса используется сервер с двумя сетевыми интерфейсами, один из которых обеспечивает связь с безопасными, а другой - с небезопасными сегментами сети. Задачи фильтрации и маршрутизации трафика решаются при помощи виртуальных машин. Для обмена данными между виртуальными машинами может использоваться как виртуальный сетевой интерфейс, так и криптографический сервис, обеспечивающий конфиденциальность передаваемых по незащищенному сегменту сети данных. Программная часть реализована при помощи микроядра Fiasco.OC, программной среды Genode и паравиртуализованного ядра L4Linux. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 149
- 150. 5 Поскольку стояла задачаоценить производительность полностью микроядерного окружения, в котором драйвера сетевой подсистемы реализованы в пространстве пользователя, были исключены решения на базе гибридных ядер ОС. Кроме того, к используемой комбинации ядра ОС и программного окружения предъявлялись следующие требования: – Открытый исходный код, так как предполагалась доработка системы и последующее распространение изменений. – Поддержка микропроцессорной архитектуры X86 и многопроцессорных (SMP) систем. – Поддержка современного оборудования, в частности, наиболее распространённых моделей сетевых карт. Этим требованиям удовлетворяют микроядра семейства L4, такие, как OKL4, Fiasco, Fiasco.OC. Было использовано ядро Fiasco.OC, как наиболее активно развиваемое (новые версии выходят раз в несколько месяцев, в то время как последний публичный релиз OKL4 был несколько лет назад) и официально поддерживаемое окружением Genode. Рис. 2. Архитектура сетевого шлюза с использованием микроядра Программная среда Genode - это набор системных сервисов (драйверов устройств и файловых систем) и библиотек, предназначенных для разработки программного обеспечения для микроядерной ОС. Ряд библиотек реализуют программный интерфейс POSIX, позволяя переносить некоторые приложения из ОС Linux посредством перекомпиляции. Кроме того, Genode содержит библиотеку DDEKit[7], позволяющую использовать ряд драйверов устройств из других ОС (таких, как Linux и iPXE). Одним из сервисов, использующих библиотеку DDEkit, является DDE_ipxe, реализующий функциональность драйвера сетевого интерфейса. Таким образом, драйвер 150 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 151. 6 сетевого интерфейса представляетсобой программу, выполняющуюся в пространстве пользователя, тем самым изолированную от других сервисов. В случае, если будет обнаружена уязвимость в этом драйвере, позволяющая злоумышленнику внедрить свой код в сервис, не произойдет компрометации других программ, в частности, приложений, выполняющихся в виртуальных машинах. Виртуальные машины реализованы при помощи L4Linux. L4Linux - это адаптированное ядро Linux для работы в депривилегированном режиме (пространстве пользователя) в качестве сервиса среды Genode. L4Linux позволяет использовать программы для ОС Linux без модификации за счет двоичной совместимости. Помимо сокращения затрат времени на адаптацию программного обеспечения для работы в микроядерной среде, это позволяет использовать программы, которые невозможно адаптировать ввиду отсутствия исходных кодов, например, значительная часть коммерческого программного обеспечения. 2.3 Модель угроз Основной вектор атаки на сетевые устройства под управлением монолитных ОС типа Linux и FreeBSD - это эксплуатация уязвимостей в одном из сервисов, доступных извне (например, HTTP сервер, используемый для конфигурации или вывода информации) для повышения привилегий. Ряд атак позволяет злоумышленнику повысить уровень доступа в пределах одного сервиса, другие направлены на получение полного доступа к ядру ОС (root expoits). Большое количество атак для повышения привилегий использует ошибки в ПО, связанные с переполнением буфера [3]. Атака с переполнением буфера заключается в возможности перезаписи переменных в программе из-за ошибок обработки пользовательского ввода. Данный класс уязвимостей возможен в связи с тем, что для хранения кода программ и пользовательских данных используется одна и та же область памяти. Кроме того, для передачи параметров в системные вызовы зачастую используется разделяемый между пространством ядра и пространством пользователя регион памяти, что позволяет получить доступ к структурам ядра, если в коде обработки системного вызова отсутствуют или некорректно реализованы проверки размера передаваемых данных. В микроядре Fiasco.OC взаимодействие между процессами реализовано через систему обмена сообщениями. Сообщения передаются через специальный регион памяти фиксированного размера (UTCB, Userspace Thread Control Block). При передаче данных от процесса к процессу данные копируются из UTCB первого процесса в UTCB второго, что, с одной стороны, защищает от утечек данных через указатели на структуры ядра, а с другой, может увеличить время затрачиваемое на системные вызовы. Важно заметить, что эта мера поддерживающая целостность данных при осуществлении межпроцессных вызовов, тем самым не позволяя злоумышленнику, получившему контроль над каким-либо сервисом, атаковать сервисы, Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 151
- 152. 7 связанные с ним,но не гарантируют невозможность проведения атаки на отдельный сервис. Одной из угроз вляется атака через устройства, поддерживающих DMA. Технология DMA (Direct Memory Access) позволяет устройству обращаться к произвольной области физической памяти. Защища от таких атак не зависит от типа ядра и реализуется при помощи IOMMU (Input/Output Memory Management Unit) - аппаратного блока виртулизирующего физическую память с которой работает DMA устройство. Другим типом угроз является атака на драйвер устройства. Выявление и использование уязвимости в сетевой подсистеме не дает доступа злоумышленнику к структурам ядра поскольку сетевая подсистема исполняется в режиме пользователя и изолированная от других компонентов. 2.4 Анализ производительности Ключевой характеристикой аппратно-программного комплекса являлась производительность. Как упоминалось ранее, микроядерная архитектура способствует повышению защищенности системы, но, в то же время, может способствовать деградации производительности. При анализе производительности мы использовали ОС Linux в качестве эталонной, исполняемой на таком же оборудовании без использования гипервизора. Для измерения производительности сети были использованы два компьютера - рабочая станция разработчика (далее - PC Host) и сервер, представляющий собой аппаратную часть разрабатываемого комплекса (далее SRV). Оба компьютера оснащены сетевым контроллером Intel 82579LM с пропускной способностью 1Гб/с. Для проведения тестов использовалась программа netperf [1]. Были проведены тесты приема и передачи данных. В первом случае один экземпляр программы netperf запускался в режиме сервера внутри среды L4Linux, а другой - в режиме клиента на рабочей станции под управлением Linux (на графике данная конфигурация обозначена как «SRV Host PC Client»). Во втором случае («PC Host - SRV Client») в L4Linux netperf запускался в режиме клиента. Для рабочей станции использовался дистрибутив Fedora Linux 18 с версией ядра Linux 3.8; при запуске на сервере в среде Genode использовалось ядро L4Linux версии 3.5, в качестве корневой файловой системы также использовался образ дистрибутива Fedora. Результаты тестирования приведены на графике ниже (Рис. 3). Можно выделить следующие особенности: – Максимальная пропускная способность сети с использованием системы L4Linux в среде Genode в 1.75 раз ниже, чем без использования паравиртуализации – Показатели скорости передачи данных отличаются для входящего и исходящего трафика. Скорость приёма данных почти в 10 раз ниже, чем без использования паравиртуализации. 152 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 153. 8 Скорость передачи (Mbps) 1,000 800 PCHost - SRV Client SRV Host - PC Client 704703 600 402 400 200 89 0 Linux Genode Рис. 3. Сравнение производительности сетевой подсистемы 3 Профилирование сетевого стека Высокая деградация производительности полученной системы говорит о недостатках архитектуры. Дальнейшие эксперименты по анализу производительности системы осуществлялись на одном экземпляре L4Linux который непосредственно обращался к драйверу сетевого адаптера DDE_iPXE. 3.1 Инструментарий профилирования Программная среда Genode не предоставляет средств для профилирования кода. Была рассмотрена возможность портирования инструментов, используемых в других ОС, таких, как gprof или DTrace. Одним из препятствий к портированию данных утилит стало отсутствие в библиотеках, реализующих уровень совместимости со стандартом POSIX, некоторых системных вызовов, например, profil и mcount, необходимых для реализации инструментирующего профилировщика. Кроме того, сложность представляет организация доступа из профилировщика к объектам ядра ОС и аппаратным счётчикам производительности без внесения изменений в конфигурацию сервисов и нарушения принципа изоляции процессов в микроядерном окружении. Ввиду отсутствия средств измерения производительности, в участки кода драйвера сетевого интерфейса были вручную расставлены счетчики тиков системного таймера (получаемых инструкцией rdtsc), затрачиваемых на выполнение интересующей нас процедуры. Сообщения выводились в журнал, который передавался на компьютер разработчика через последовательный порт UART. При использовании пакетов большего размера было обнаружено, что изза низкой скорости вывода данных через UART, добавление отладочных Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 153
- 154. 9 сообщений замедляет работуисследуемой программы. Для решения этой задачи был реализован сервис, сохраняющий отладочный журнал в оперативную память. Был использован существующий драйвер ram_fs в среде Genode, который реализует файловую систему в оперативной памяти. По окончании тестирования журнал копировался с тестового компьютера через HTTP интерфейс, предоставляемый сервером lighttpd, запущенным в среде Genode. В приведенной ниже таблице 1 представлено среднее время выполнения функций сетевого стека (в тиках процессора). Процедура Количество тиков Файл dde_kit_sem_up dde_kit_sem_down memcpy 13 59 23 lib/nic.c [dde_ipxe] lib/nic.c [dde_ipxe] lib/nic.c [dde_ipxe] get_acked submit_packet packed_descriptor 46 190-160K 10 nic/component.h [Nic] nic/component.h [Nic] nic/component.h [Nic] get_packet acknowledge_packet submit_packet memcpy Таблица 1. Время 3.2 8 lib/l4lx/genode_net.cc [L4Linux] 254 lib/l4lx/genode_net.cc [L4Linux] 65 lib/l4lx/genode_net.cc [L4Linux] 25 lib/l4lx/genode_net.cc [L4Linux] выполнения процедур сетевого стека Анализ результатов профилирования Как следует из таблицы 1, наиболее затратная операция - submit_packet, которая помещает пакет в циклический буфер и делает IPC запрос к другому процессу. При тестировании программой netperf было обнаружено, что при длительной передаче данных время выполнения операции submit_packet спорадически увеличивается на несколько порядков. Было сделано предположение, что причинами такого поведения могут быть как особенности реализации драйверов устройств, так и алгоритмов управления процессами и памятью в ядре ОС. Драйвера устройств Одной из причин несимеетричной производительности сетевой подсистемы при приеме и передаче данных может являться реализация обработки аппаратных прерываний в микроядре Fiasco.OC. В Genode не реализована поддержка прерываний, инициируемых сообщениями (MSI-X) для шины PCI. Это не позволяет назначить обработчик для прерывания, сигнализирующего о наличии входных данных на сетевом интерфейсе, и приходится 154 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 155. 10 использовать прерывание отшины PCI, которое может быть разделено с другими устройствами, что может приводить к увеличению времени обработки входящего трафика. Кроме того, драйвер контроллера прерываний IO APIC на некоторых системах, оставляет контроллер в состоянии, в котором тот остался на момент загрузки, не реализуя включение/выключение источника прерываний, что осложняет отладку программного комплекса. Управление памятью В процессе тестирования программа netperf последовательно увеличивает размер сетевых пакетов. При длительном тестировании наблюдается большой разброс времени выполнения операции submit_packet, в связи с чем было сделано предположение, что драйвер сетевого интерфейса тратит много времени в ожидании выделения памяти для очередного пакета. С целью проверки этого предположения были увеличены в 8 раз размеры буферов для входящих и исходящих данных. Поскольку увеличение размеров буферов не внесло изменений в поведение системы, необходимо было провести исследование поведения алгоритма выделения памяти. Для управления памятью в сетевой подсистеме Genode используется алгоритм SLAB[2], который содержит несколько списков блоков памяти фиксированного размера (1Кб, 2Кб, 16Кб и т.д.). Память для пакетов с данными организована в виде кольцевого буфера, где пакет, освобожденный одним из сервисов (например, драйвером сетевого адаптера DDE_ipxe), попадает в очередь свободных пакетов другого сервиса (драйвер виртуального сетевого интерфейса L4Linux). При передаче региона памяти в процесс другого сервиса выполняется операция освобождения региона (unmap), и операция выделения памяти в новом процессе. При конфигурации микроядра Fiasco.OC для поддержки многопроцессорного режима (SMP), реализация многих алгоритмов и структур данных, в том числе примитивов синхронизации (мьютексов), отличается от однопроцессорной версии. Кроме того, при использовании нескольких процессоров потоки, выполняющие системные функции (обработку прерываний, ввод-вывод) и пользовательские задачи выполняются одновременно. Для определения влияния данных различий на производительность системы, было проведено тестирование в двух режимах: при включении всех ядер процессора поддержки SMP в Fiasco.OC (время выполнения теста составило 24929000 мкс), и при использовании одного ядра и отключения SMP (146000 мкс). При использовании одного ядра процессора, разница между скоростью приема и передачи данных уменьшается. В многопроцессорном режиме планировщик проводит значительную часть времени (до 30%) в режиме простоя (idle thread) вместо того, чтобы передавать управление потокам приложений. Изучение причин такого поведения планировщика и сравнение с другими микроядрами, поддерживаемыми средой Genode является задачей для дальнейших исследований. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 155
- 156. 11 4 Предлагаемые решения Для минимизациизадержек при обработке сетевых данных были предложены несколько способов доработки сетевой подсистемы: – Использовать регион разделяемой памяти (Dataspace в терминологии L4/Genode) вместо буферизации в каждом процессе. Но такое решение противоречит принципам безопасности микроядерных систем, так как в случае компрометаци драйвера сетевого интерфейса злоумышленник потенциально получает доступ к памяти всех процессов, использующих сеть. – Предоставить паравиртуализированным экземплярам L4Linux доступ к физическому сетевому адаптеру. Для обеспечения доступа к памяти и регистрам PCI устройств был реализован драйвер виртуальной PCI шины для L4Linux, однако проблема обработки прерываний в ACPI системах не позволяет провести полноценное тестирование решения. Кроме того, очевидные минусы - невозможность использования одного сетевого интерфейса различными сервисами. – Минимизировать количество потоков выполнения (threads), занимающихся обработкой данных. Синхронизация доступа к критическим секциям может занимать значительную часть времени обработки сетевого пакета, как можно видеть в таблице 1. Некоторые подсистемы среды Genode (в частности, DDE_kit) переделаны для выполнения в однопоточным режиме. Для задач, производительность которых ограничена операциями ввода-вывода, использование многопоточной архитектуры зачастую увеличивает латентность. – Реализовать поддержку прерываний MSI-X и контроллера IO APIC и провести анализ влияния используемого источника прерываний (от устройства посредством MSI-X и через шину PCI) на время обработки входящих данных. 5 Заключение Был разработан рабочий прототип доверенного сервера, обеспечивающего изоляцию приложений при помощи паравиртуализации в среде Genode/L4Linux. В ходе тестирования было обнаружено падение производительности сетевой подсистемы, не позволяющее использовать полученное программное решение в качестве непосредственной замены ОС Linux. Детальный анализ прохождения нагрузочных тестов выявил ряд недостатков в дизайне системы, связанных с драйверами устройств и механизмом выделения памяти в многопроцессорной системе. Дальнейшая работа будет посвящена оптимизации драйверов и реорганизации многозадачности. Список литературы 1. Netperf homepage. http://netperf.org. 156 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 157. 12 2. Jeff Bonwicket al. The slab allocator: An object-caching kernel memory allocator. In USENIX summer, volume 16. Boston, MA, USA, 1994. 3. Crispin COwan. Buffer overflows: Attacks and defenses for the vulnerability of the decade. 2000. 4. TU Dresden. L4linux-running linux on top of l4. 5. Hermann Haertig et al. The performance of u-kernel-based systems. In ACM Simposum on Operating Systems Principles, volume 16. Saint-Malo, France, 1997. 6. Jochen Liedtke. Toward real microkernels. Communications of the ACM, 39(9):70– 77, 1996. 7. Hannes Weisbach. Ddekit approach for linux user space drivers. 2011. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 157
- 158. Подход к верификациикорректности миграции данных между СУБД с использованием криптографических хэш-функций Максим Журавлев, Виктор Полозов Кафедра системного программирования, Санкт-Петербургский государственный университет 24 сентября 2013 г. Аннотация В данной статье описывается автоматизированный подход к сравнению содержимого баз данных в промышленном проекте по миграции БД из СУБД MS SQL Server 2005 в Oracle 11gR2. Целевая БД должна содержать те же данные, что и исходная с точностью до ограничений, налагаемых используемыми СУБД, и быть функционально эквивалентной. Размер данных в исходной базе составляет порядка 6 терабайт, размер кода - 2.5 миллиона строк кода в хранимых процедурах. Разработан метод сравнения содержимого БД независимый от порядка просмотра записей, использующий коммутативные и криптографические хэш-функции. Показана применимость данного метода для практического использования. Ключевые слова - базы данных, миграция данных, тестирование, реинжиниринг, обеспечение качества, хэширование 1. Введение Перед коллективом, в котором имеют честь работать авторы, была поставлена задача произвести миграцию промышленной БД из Microsoft SQL Server 2005 в Oracle Database 11g Release 2. Проект условно можно разделить на следующие части: миграцию кода хранимых процедур, представлений (VIEW) и триггеров, миграция данных и обеспечение качества. При миграции производилась доработка кода с учётом специфики целевой СУБД, новых требований к системе, удалялся мёртвый код, и проводились другие согласованные с заказчиком изменения. При миграции схемы БД проводились такие изменения, как переименование процедур, таблиц и колонок, в основном связанные с ограничением СУБД Oracle в 30 байт на имя, и согласованные изменения в схеме, такие как разбиение по схемам и удаление не используемых объектов. Миграция данных проводилась без наличия прямого подключения между базами, через временные файлы с использованием инструментов Microsoft 158 1 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 159. SQL Server BCPи Oracle SQL*Plus. Конвертация данных проводилась в три этапа: часть данных конвертировалась при выгрузке, часть при загрузке, оставшиеся конвертации проводились как отдельный шаг после загрузки. В настоящей статье даётся более технически подробное описание реализованного авторами этапа тестирования – верификации корректности миграции путем сравнения набора хэшей. 2. Связанные работы Методологии миграции баз данных описаны в нескольких статьях. В статье [7] представлен пример методологии миграции данных. Процесс миграции между базами данных с отличающимися моделями данных, сопутствующие риски и проблемы описаны в [9] и [1]. Методологии миграции legacy-систем представлены в [15]. Проекты миграции баз данных сталкиваются со специфичными рисками и проблемами. Типичные риски и подходы к тестированию и обеспечению качества описываются в [11]. Разновидности тестирования, применяемые в течение жизненного цикла проекта миграции, рассматриваются в [12]. Общая схема организации обеспечения качества нашего проекта описана в статье [8]. Вопросы хэширования неупорядоченных коллекций (множеств и мультимножеств) рассматриваются в [4]. В этой же работе впервые вводится определение устойчивости хэш-функции множества (мультимножества) к коллизиям. Хэширование неупорядоченных коллекций тесно связано с инкрементальным хэшированием. Результаты с использованием операции XOR получены в работах [10] и [3]. Подход к хэшированию таблиц, использованный в нашем проекте, напоминает MSet-XOR-Hash из статьи [4]. Схожие подходы используются в похожей задаче поддержания консистентности реплицированных баз данных. К таким работам относятся: статьи [5], [6] и доклад [2]. В данных статьях не рассматривается сравнение БД, находящихся под управлением разных СУБД. 3. Требования к методу На этапе планирования проекта было решено, что совпадение данных в исходной и целевой БД должно быть проверено отдельным инструментом. Были сформулированы требования к инструменту: 1. Сравнение БД, находящихся в разных СУБД. Все используемые методы должны быть реализованы в MS SQL Server 2005 и Oracle 11gR2. 2. Настраиваемая процедура сравнения. 3. Независимость результата сравнения от порядка записей в выборках. Это требование связано с тем, что СУБД не гарантируют порядок выдачи результатов для выборки без явной директивы ORDER BY. От добавления явной директивы для упорядочивания отказались по двум причинам: отсутствие первичного ключа или уникального индекса у части таблиц, и существенное увеличение времени работы при упорядочивании без использования индекса. 2 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 159
- 160. 4. Эффективность работы.Сюда включается возможность достаточно эффективной реализации и возможность распараллеливания в обеих СУБД. Приемлемым считалось время сравнимое со временем работы процедуры перегрузки данных. От требования определения места расхождения было решено отказаться, т.к. основной сценарий предусматривал использование верификации как средства доказательства корректности процедуры перекачки данных, а не как средства диагностики. Обзор как доступных для приобретения, так и бесплатных инструментов не выявил удовлетворяющих всем вышеперечисленным требованиям. 4. Реализация 4.1. Контролируемые параметры Верификация данных выполняется по следующим параметрам: 1. По метаданным контроль наличия всех необходимых объектов исходной БД в целевой БД и нахождения их в корректном статусе (процедуры успешно откомпилированы, триггеры установлены). 2. Контроль числа строк в таблицах. 3. Хэши столбцов таблиц и таблиц целиком. Первый из вышеперечисленных пунктов реализуется анализом кодов завершения и других записей в log-файлах, описывающих процесс выгрузкизагрузки. Остальные – сравнением результатов выполнения скриптов подсчета хэшей в исходной и целевой БД. 4.2. Этапы верификации миграции 1. Выполнение скриптов расчета хэшей в исходной БД. Хэши сохраняются в новую таблицу исходной БД. 2. Выгрузка таблицы с хэшами в промежуточный файл. 3. Загрузка результатов из промежуточного файла в целевую БД. 4. Выполнение скриптов расчета хэшей в целевой БД. Результаты пополняют таблицу с хэшами исходной БД. 5. Генерация отчета о расхождениях или полном совпадении набора хэшей. Шаги, относящиеся к целевой БД, выполняются до включения в журналирующих триггеров. 160 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 3
- 161. 4.3. Расчет хэшей Длякаждой таблицы вычисляются n+2 хэша, где n – количество столбцов. Первый - количество записей в таблице. Несовпадение количества записей позволяет выявить грубые ошибки перегрузки, но совпадение возможно при искажениях в значениях данных, что является большим недостатком, особенно для таблиц, содержащих типы данных, трансформирующиеся при миграции. Остальные хэши предназначены для устранения этого недостатка. Они рассчитываются следующим образом: записи таблицы обрабатываются одна за одной в произвольном порядке – выполняется запрос SELECT COLU M N1 , COLU M N2 ,· · ·, COLU M NN FROM TABLE. Значение каждого поля преобразуется в массив байтов, например, datetime преобразуется в количество миллисекунд с 01.01.1970 00:00:00 (POSIX time) как bigint. Получившееся число интерпретируется как массив байтов. Массивы конкатенируются. Получившийся массив подается на вход хэш-функции. Может быть использована любая, реализация которой доступна в обеих СУБД. Авторами была выбрана MD5 [13]. Возвращенное значение представляет собой хэш записи. Данная операция может интерпретироваться как создание дополнительного столбца в таблице. Набор хэшей таблицы не должен зависеть от порядка обхода записей, поэтому было принято решение использовать коммутативную операцию XOR (исключающее или) для получения итоговых хэшей из хэшей записей: для каждого столбца, включая “виртуальный” столбец хэшей записей, вычисляется XOR всех элементов. MD5 – криптографическая хэш-функция, поэтому возвращаемое значение можно рассматривать как равномерно распределенную случайную величину из интервала [0; 2128 − 1]. XOR таких величин не меняет распределение, поэтому XOR “виртуального” столбца хэшей записей можно рассматривать как равномерно распределенную случайную величину из интервала [0; 2128 − 1]. В исходной БД количество записей в каждой таблице не превышает 1013 . Вероятность обнаружения не менее одной коллизии не превышает 10−12 [14]. Четное количество идентичных записей из-за свойства XOR(x, x) ≡ 0 может скрыть ошибку в миграции какого-либо типа данных, но отладка метода производилась с использованием таблиц, содержащих уникальные записи. Вероятность же нескольких аппаратных сбоев, не попавших в журнал, и, повлиявших только на четное количество идентичных записей в одной таблице, оценивается как пренебрежимо малая. Таблицу БД с первичным ключом можно рассматривать как множество. Изложенный выше метод отличается от MSet-XOR-Hash [4] для хэширования (мульти)множеств отсутствием рандомизации – хэш-функция фиксирована, а не выбирается из некоторого семейства. Это делает метод уязвимым для целенаправленной атаки. Однако во время разработки он позволил выявить ряд ошибок в процессе перегрузки. Остальные хэши вычисляются не криптографическими хэш-функциями, но на этапе отладки они облегчали процесс поиска источников ошибок. Поскольку данные могут подвергнуться трансформации при перегрузке и представляться разными наборами байтов, вычисление хэш-функции может завершиться с разными результатами в исходной и целевой БД. Для унификации результатов значения полей приводятся к нормальной форме для составления аргумента хэш-функции по правилам, изложенным в 4 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 161
- 162. таблице 1. 4.4. Генерацияскриптов Скрипты, не зависящие от схемы БД, – командные файлы для утилит загрузки-выгрузки данных обеих СУБД, SQL-запросы для создания таблиц с результатами и генерации отчета, вспомогательные функции для хэширования отдельных типов данных в исходной СУБД, Java-функция хэширования в целевой СУБД, написаны вручную. Скрипты, зависящие от схемы, генерируются разработанной утилитой (язык реализации F#) на основании актуальной схемы исходной БД (используется экземпляр класса Server) и дополнительных параметров, перечисленных в конфигурационном файле. Скрипт для исходной БД – код на Transact-SQL определяет три вспомогательных функции: для конвертации DATETIME в BIGINT, вычисления хэша BINARY, вычисления хэша VARCHAR, затем для каждой таблицы вычисляются хэши по схеме, описанной выше. Скрипт для целевой БД – код на PL/SQL создаёт для каждой таблицы объект CURSOR, передаёт его в Java-функцию вычисления хэшей, сохраняет возвращенный результат в таблицу. Данный подход обусловлен недостаточной производительностью хэширования, реализованного средствами PL/SQL. Как сказано выше, в качестве коммутативной операции, обеспечивающей независимость итоговых хэшей от порядка просмотра записей, выбрана операция XOR, которую в данной версии PL/SQL можно выразить только посредством нескольких вызовов встроенных функций. Получившийся объем разработанного кода составил 1,5KLOC на F#, 0,3KLOC на cmd/shell, 0,4KLOC на Java. Объем сгенерированного кода для мигрируемой БД, содержащей 2410 таблиц, – 144КLOC на PL/SQL (8,4Mb) и 215KLOC на T-SQL (18,3Mb). 4.5. Показания производительности Сравнение БД описанным методом требует значительных вычислительных ресурсов. В отличие от загрузки-выгрузки “узким местом” является не производительность системы ввода-вывода, а скорость вычисления хэшей. Затраты времени на сравнение стали сравнимы с временем перегрузки БД, после того как утилита генерации скриптов была доработана для генерации скриптов, вычисляющих наборы хэшей для нескольких таблиц параллельно. Для MS SQL Server 2005 генерируются несколько файлов с кодом на Transact-SQL для обработки набора таблиц сопоставимого суммарного размера. Каждый скрипт передаётся для исполнения экземпляру служебной утилиты Microsoft ® SQL Server Command Line Tool средствами ОС. Для Oracle 11gR2 генерируется один файл с кодом на PL/SQL, использующий пользовательские функции реализованные на встроенном языке Java для обработки переданного ResultSet. Скрипт передаётся для исполнения служебной утилите Oracle SQL*Pus. Средствами СУБД Oracle устанавливается количество потоков, обрабатывающих задания из очереди, заполняется очередь заданий. Каждое задание в очереди обрабатывает одну таблицу или часть таблицы, имеющей численный первичный ключ. 162 5 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 163. Тип в исходнойБД BIT TINYINT SMALLINT INT BIGINT FLOAT DECIMAL(n, m), n − m ≤ 18 и m ≤ 18 DECIMAL(n, m), остальные NUMERIC(n, m) MONEY DATETIME Тип в целевой БД NUMBER(1) NUMBER(18) NUMBER(18) NUMBER(18) NUMBER(19) FLOAT NUMBER(n, m) Преобразование 4 байта little-endian 4 байта little-endian 4 байта little-endian 4 байта little-endian 8 байтов little-endian 8 байтов little-endian по 4 байта целой и дробной частей, рассматриваемых как INT, little-endian NUMBER(n, m) SMALLDATETIME DATE BINARY BLOB IMAGE BLOB VARBINARY BLOB CHAR(n), n ≤ 4000 VARCHAR2(n) CHAR(n), пустая строка или NULL VARCHAR2(n) NCHAR(n), n ≤ 4000 SYSNAME VARCHAR(n), n ≤ 4000 NVARCHAR(n), n ≤ 4000 CHAR(n), n 4000 NCHAR(n), n 4000 VARCHAR(n), n 4000; VARCHAR(MAX) NVARCHAR(n), n 4000; NVARCHAR(MAX) TEXT; NTEXT VARCHAR2(n) результат вычисления хэш-функции(MD5) от значения поля, преобразованного в строку аналогично DECIMAL(n, m) аналогично DECIMAL(19, 4) аналогично BIGINT после конвертации в Unix time аналогично BIGINT после конвертации в Unix time результат вычисления хэш-функции (MD5) от значения поля результат вычисления хэш-функции (MD5) от значения поля результат вычисления хэш-функции (MD5) от значения поля удаляются ведущие и замыкающие пробелы, символы переноса строки (при загрузке в целевую БД происходит нормализация); получившаяся строка конвертируется в набор байтов с учетом кодовой страницы; вычисляется значение хэшфункции(MD5) СУБД Oracle рассматривает пустую строку как NULL; набор байтов совпадающий со значением хэш-функции при аргументе – пустой строке аналогично CHAR VARCHAR2(128) VARCHAR2(n) аналогично NCHAR(128) аналогично CHAR VARCHAR2(n) аналогично CHAR CLOB CLOB CLOB аналогично CHAR аналогично CHAR аналогично CHAR CLOB аналогично CHAR CLOB аналогично CHAR NUMBER(n, m) NUMBER(19, 4) DATE Таблица 1: Преобразование полей записей в набор байтов 6 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 163
- 164. При выборе подходак реализации были рассмотрены различные подходы к реализации и проведено сравнение их производительности: • Код на Transact-SQL в целом удовлетворял требованиям по производительности. • Реализация хэширования на PL/SQL, – через проход циклом по курсору, с подсчётом хэшей, и их объединение через операцию XOR, реализованную через встроенную функцию BitAND, – проигрывал в производительности TSQL-коду в 5-10 раз. Поэтому было принято решение о его оптимизации. • Реализация на языке Java, встроенном в Oracle, на разных таблицах показала или сходный результат с PL/SQL-реализацией, или улучшение производительности. Дополнительным аргументом, в пользу реализации на Java, так же можно назвать относительною простоту реализации, что позволило быстрее получить как первые, так и окончательные результаты. • Реализация на языке Java, запущенная в несколько потоков, показала почти линейный рост производительности до достижения насыщения. На следующем графике представлены сравнение времени работы различных реализаций хэширования для одной из основных таблиц. В уменьшенной для целей тестирования базе в этой таблице 4 миллиона записей общим объемом порядка 2.5 гигабайт. Тестирование производилось на сервере с 8-ядерным процессором. SQLServer 294 PL/SQL 1 поток Java 1 поток Java 2 потока 615 Java 4 потока 395 Java 8 396 Java 16 1047 1510 2231 0 300 600 900 1200 1500 1800 2100 График 1: влияние реализации на время расчета (сек.) По результатам тестирования для Oracle было принято решение в пользу Java-реализации с запуском несколько потоков. Итоговые составляющие времени перегрузки тестовой базы, содержащей 21Гб в 1.5К не пустых таблицах даны в таблице 2. Таким образом, время хэширования сопоставимо со временем перегрузки, что позволяет утверждать, что поставленные требования были удовлетворены. 5. Результаты Описанным методом сравнивались исходная и целевая БД при каждом ночном тестировании очередной сборки, что позволило выявить и исправить 7 164 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 165. Этап Выгрузка из MSSQL Хэшированиев MSSQL Загрузка в Oracle Хэширование в Oracle Время (сек.) 1109 799 2134 2279 Таблица 2: Время этапа миграции тестового набора данных ошибки в процедуре перегрузки и процедуре вычисления хэшей. Для доказательства эквивалентности изменений, совершаемых в исходной и целевой БД, при воспроизведении трасс типичных действий пользователя были сгенерированы журналирующие триггеры, вычисляющие хэши перехваченных наборов записей по описанной выше схеме. 6. Заключение Примененный метод сравнения содержимого баз данных путем подсчёта использующий коммутативные и криптографические хэш-функции позволил успешно решить поставленную перед авторами задачу: было реализовано автоматизированное тестирование корректности миграции данных между различными СУБД путем сравнения набора хэшей, что позволило устранить ряд методических ошибок перегрузки. Разработанный метод возможно переиспользовать, при необходимости пополнив поддержкой типов данных, не встретившихся в схеме исходной БД, и поддержкой СУБД, отличных от MS SQL Server 2005 и Oracle 11gR2. Список литературы [1] Maatuk A. Migrating Relational Databases into Object-Based and XML Databases. Northumbria University, 2009. [2] Ulrich Arndt. How to compare tables between td systems in a dual active environment. In The 2012 Teradata PARTNERS Conference, 2012. [3] Mihir Bellare, Oded Goldreich, and Shafi Goldwasser. Incremental cryptography: The case of hashing and signing. In In CRYPTO, 1994. [4] Dwaine Clarke, Srinivas Devadas, Marten van Dijk, Blaise Gassend, and G. Edward Suh. Incremental multiset hash functions and their application to memory integrity checking. In In Advances in Cryptology - Asiacrypt 2003 Proceedings, volume 2894 of LNCS, pages 188–207. Springer-Verlag, 2003. [5] Fabien Coelho. Remote comparison of database tables technical report a/375/cri, 2006. [6] Fabien Coelho. Remote comparison of database tables. In DBKDA 2011 : The Third International Conference on Advances in Databases, Knowledge, and Data Applications, 2011. 8 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 165
- 166. [7] Hudicka J.The Complete Data Migration Methodology. Dulcian Inc., 2000. [8] I. Kirilenko and E. Baranov. Automation of QA in the project of DB migration from SQL Server into Oracle. In Proceedings of the 6th Spring/Summer Young Researchers’ Colloquium on Software Engineering (SYRCoSE 2012), pages 178–181. Perm, Russia, May 30-31, 2012. [9] Chang-Yang Lin. Migrating to relational systems: Problems, methods, and strategies. 4(4):369–380, 2008. [10] R. Guerin M. Bellare and P. Rogaway. Xor macs: New methods for message authentication using finite pseudorandom functions. In In CRYPTO, 1994. [11] Haller K. Matthes F., Schulz C. Testing quality assurance in data migration projects. In 2011 27th IEEE International Conference, 2011. [12] Augustinez J. Redlichx A. Lodha S. Vin H. Deshpande A. Gharote M. Mehrotrak A. Patil S., Royy S. Minimizing testing overheads in database migration lifecycle. In The 16th International Conference on Management of Data (COMAD), 2010. [13] Ronald L. Rivest. The md5 message-digest algorithm. Internet RFC 1321, April 1992. [14] Bruce Schneier. Applied Cryptography, Second Edition. John Wiley Sons, 1996. [15] Bisbal J. Grimson J. Wade V. O’Sullivan D. Richardson R. Wu B., Lawless D. Legacy system migration : A legacy data migration engine. In Proccedings of the 17th International Database Conference, pages 129– 138. Springer-Verlag, 1997. 166 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 9
- 167. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 167
- 168. 168 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 169. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 169
- 170. 𝐶𝐶𝐶𝐶 𝐶𝐶 𝐶𝐶𝐶𝐶𝐶𝐶 𝐶𝐶 𝐶𝐶𝐶𝐶 𝐶𝐶 𝐶𝐶 170 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 171. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 171
- 172. 172 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 173. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 173
- 174. 174 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 175. 𝐶𝐶𝐶𝐶 𝐶𝐶 𝐶𝐶𝐶𝐶𝐶𝐶 𝐶𝐶 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝐶𝐶 𝐶𝐶 𝐶𝐶 𝐶𝐶 𝐶𝐶𝐶𝐶 𝐶𝐶 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 175
- 176. 176 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 177. Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 177
- 178. 178 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 179. Применение технологий OLAPи MapReduce для обработки результатов нагрузочного тестирования Сенов А.А. Костромской государственный технологический университет г. Кострома, ул. Дзержинского, 17 andrey.senov@gmail.com Аннотация. Современные трейдинговые платформы представляют собой сложные распределённые системы, обслуживающие большое число пользователей по различным протоколам передачи данных. При нагрузочном тестировании таких систем возникает существенный объём информации, которая может быть проанализирована QA-специалистами с целью обнаружения дефектов. Для этого часто требуется выявлять зависимости между значениями показателей, полученными в ходе тестирования, путём проведения многофакторного анализа, что при большом объёме данных является трудоёмкой задачей, требующей специализированного ПО, в частности, систем интерактивной аналитической обработки OLAP. В данной статье описывается оригинальный алгоритм многомерного анализа результатов нагрузочного тестирования на стороне клиента. С помощью технологии MapReduce предложенный алгоритм оптимизирован для работы под управлением многоядерных процессоров. Ключевые слова: OLAP, MapReduce, нагрузочное тестирование, анализ данных 1 Введение Анализ результатов нагрузочного тестирования трейдинговых платформ в большинстве случаев связан с обработкой существенных объёмов информации. Это обусловлено тем, что современные платформы являются сложными распределёнными системами, обрабатывающими свыше 40 тысяч заявок в секунду при среднем времени отклика менее 300 микросекунд. С другой стороны, аппаратная инфраструктура тестовых инструментов по производительности на несколько порядков уступает биржевой. Это неизбежно влечёт необходимость разрабатывать инструменты как можно более простые, не перегруженные функциональностью, для достижения высокой эффективности при решении основных задач[1]. В связи с этим при анализе данных, полученных в ходе нагрузочного тестирования, чтобы быстро ответить на Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 179
- 180. поставленные вопросы, возникает потребность в использовании специализированного ПО, ккакому можно отнести большой класс продуктов бизнес-аналитики BI (англ. Business Intelligence). Среди программных решений BI-класса можно выделить системы интерактивной аналитической обработки OLAP (англ. Online Analytical Processing), предназначенные для построения обобщённой информации на основе данных, имеющих многомерное представление. При нагрузочном тестировании такие системы помогают QAаналитикам (англ. Quality Assurance) качественно осуществить многофакторный анализ зависимостей между значениями показателей, полученными в ходе тестирования, с целью обнаружения дефектов платформы. 2 Существующие Решения В основе любой OLAP-системы лежит многомерная модель данных, называемая многомерным кубом, гиперкубом или просто кубом. По месту нахождения машины, рассчитывающей многомерные кубы, современные OLAP-системы можно разделить на две группы: клиентские и серверные. В случае клиентской системы сервер отправляет клиенту исходные данные, клиент производит расчет многомерных кубов и выдает результат пользователю. В случае серверной системы сервер рассчитывает многомерные кубы и отправляет результат клиенту, клиент выдает результат пользователю[2]. На сегодняшний день обе группы представлены на рынке широким спектром продуктов. Для серверных систем это, например, такие решения, как Microsoft SQL Server Analysis Services[3], OLAP Option to Oracle Database[4] или Palo[5]. Серверные решения являются наиболее быстрыми, надежными и имеют ряд других преимуществ: например, техническую поддержку от производителей. Как следствие, такие системы являются дорогостоящими. Можно принять во внимание наличие open-source версии Palo, но она имеет существенные ограничения по сравнению с коммерческой: например, отсутствие возможности использования более чем одного ядра процессора[6]. Среди клиентских решений популярными остаются электронные таблицы MS Office Excel, позволяющие выполнять многомерный анализ с помощью механизма Pivot table[7]. Pivot table удобно использовать, когда исходные данные изначально заносятся в электронную таблицу, что при серьёзных задачах, таких как нагрузочное тестирование, исключено. Поэтому пользователь обязательно сталкивается со сложностью конфигурации подключения к внешним источникам данных. Факт наличия на рынке разнообразных продуктов, обладающих своими достоинствами и недостатками, говорит о том, что для OLAP, как и для многих сложных задач, до сих пор нет единого решения, одинаково подходящего для всех. В рамках статьи предлагается рассмотреть оригинальный алгоритм многомерного анализа результатов нагрузочного тестирования на стороне клиента. Решение главным образом направлено на сокращение затрат на тестовые и аналитические инструменты. 180 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 181. 3 Предлагаемое Решение Вслучае тестирования биржевых платформ существует несколько основных источников, из которых можно получить информацию для анализа: 1. Данные, которыми оперируют непосредственно тестовые инструменты; 2. Статистическая информация из внутренней базы данных платформы, а также записи журналов активности её компонентов и пользователей; 3. Независимые данные, полученные напрямую от сетевых устройств, через которые происходит общение клиентов с платформой. Опыт показывает, что наиболее достоверным является источник под номером 3, но для полноты картины поведения тестируемой системы данные обычно собираются изо всех трёх источников и складываются в общую базу. Данные, как правило, представляют собой разнообразные сведения о типах сообщений, значениях полей сообщений, клиентах, разного рода настройках и, конечно, временных отметках. Опираясь на весь этот массив информации, аналитики оценивают такие параметры, как время отклика, количество сообщений, пропускную способность, используемую память, загрузку процессоров и прочее[8]. При создании алгоритма основным принципом служила простота, и вся его суть сводится к выполнению операций над generic-контейнерами в оперативной памяти клиентской машины. Перенос вычислений на сторону клиента обусловлен высокой производительностью современных настольных ПК, сочетающейся с их низкой стоимостью. Так, например, в настоящее время конфигурация среднего рабочего места это: процессор с 2-4 ядрами и 4-8 ГБ оперативной памяти. Такие характеристики в сочетании с гигабитными сетями, использующимися уже повсеместно, позволяют решить задачу многомерного анализа без привлечения дополнительных ресурсов. Алгоритм написан на языке C++ с применением Qt Framework, что даёт такие преимущества, как высокое быстродействие, кроссплатформенность, а также возможность использования настольной реализации технологии MapReduce[9] с целью получения масштабируемого решения для работы под управлением многоядерных процессоров. Как было сказано выше, в основе любой OLAP-системы лежит гиперкуб. И первая проблема, которую необходимо решить, – это представление гиперкуба с точки зрения кода. Для этого сначала необходимо определиться, как информация будет попадать из базы данных в гиперкуб. Ответ очевиден – нужно выполнить SQL-запрос SELECT. Запросы предлагается писать по правилам, которые отражены в листинге 1. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 181
- 182. Листинг 1. Общийвид SQL-запроса выборки данных; где dimension0 … dimensionN – значения измерений гиперкуба, measure – мера, значение ячейки гиперкуба, образуемое при уникальном сочетании значений измерений. select dimension0, dimension1, dimensionN, measure from … inner join … on … … where condition … dimension2, …, Проще говоря, запросы должны возвращать кортежи, состоящие из различных сочетаний измерений и соответствующие этим сочетаниям числовые значения анализируемой величины. Таким образом, правила помогают подготовить данные и передать их клиенту уже в структурированном виде. Атрибуты кортежей, описывающие значения измерений, могут иметь самые разнообразные типы, а последний атрибут measure в общем случае, является числом с плавающей точкой. Так как на этом этапе задача состоит не только в создании универсального способа хранения данных в ОЗУ, но и обеспечении возможности построения простых и составных ключей по значениям измерений на осях гиперкуба, которые будут необходимы для упорядочивания и поиска информации, все измерения следует привести к одному типу ещё до размещения в ОЗУ. В качестве такого типа подходят строки. Это объясняется тем, что большинство измерений изначально имеют строковые значения: названия протоколов, сообщений, финансовых инструментов, имена пользователей и т.п., а все другие типы при необходимости всегда можно привести к строковому, используя SQL-функцию cast. Что касается дат, то при переводе их в строковый тип они приобретают ISO-формат YYYY-MM-DD, и упорядочивание таких строк напрямую соответствует упорядочиванию дат. Таким образом, кортежи запроса можно описать следующим классом: Листинг 2. Представление кортежей запроса, где поле класса _keys содержит атрибуты, представляющие значения измерений, приведённые к строковому типу; поле _measure – последний атрибут кортежа, представляющий ячейку гиперкуба. class Tuple { public: Tuple(const QStringList keys, double measure); const QStringList keys() const; void setKeys(const QStringList keys); double measure() const; void setMeasure(double measure); private: QStringList _keys; double _measure; }; 182 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 183. Собственно гиперкуб являетсяgeneric-контейнером QList, содержащим множество экземпляров класса Tuple, описанного в листинге 2, и представляет собой мгновенный снимок данных. Следующая проблема – выбор осей гиперкуба для формирования отчёта и передача этой информации коду, который будет его формировать. Для пользователя естественным представлением осей гиперкуба являются два списка их названий: один для строк отчёта, второй – для столбцов, допускающие множественный выбор и перемещение элементов списка относительно друг друга. С точки зрения кода, названия измерений использовать неудобно, т.к. значения измерений хранятся в QStringList, который позволяет обращаться к элементам по индексам. Когда пользователь меняет измерения местами с целью получения в отчёте необходимой детализации и агрегации, их порядок уже не будет соответствовать тому, который был задан при написании запроса, поэтому для соответствия названий измерений их порядковым индексам предлагается использовать словарь QMapQString, int, в котором в качестве ключей хранятся названия измерений, в качестве значений – их порядковые индексы. Отчёт, который строится алгоритмом, представлен в виде вектора векторов. Для удобства вектор инкапсулирован в класс Projection, который показан в листинге 3. Листинг 3. Представление отчёта, где поле класса _data является вектором векторов: двумерным массивом, содержащим ячейки отчета. class Projection { public: Projection(int width = 0, int height = 0); Projection(const QSize size); void resize(int width, int height); void resize(const QSize size); void clear(); int width(); int height(); QVectorCell operator[](int i); private: QVector QVectorCell _data; }; Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 183
- 184. Листинг 4. Представлениеячейки отчёта, где поле _value аккумулирует значения, прибавляемые к ячейке; _min, _max содержат минимальное и максимальное значения ячейки соответственно; _count считает количество слагаемых для расчёта среднего значения ячейки. class Cell { public: Cell(); Cell(int x, int y, double value); double value() const; void setValue(double value); int x() const; void setX(int x); int y() const; void setY(int y); double max() const; double min() const; double avg() const; Cell operator+=(double value); const Cell operator+(const Cell other); bool isEmpty(); void clear(); private: int _x; int _y; double _value; double _max; double _min; int _count; }; В листинге 4 можно увидеть, что алгоритм даёт возможность выбора величин отчёта, которые будут показаны пользователю в конечном счёте: сумма, минимум, максимум, среднее. Формирование самого отчёта выполняется в три этапа: 1. Сканирование гиперкуба (generic-контейнера QList) с целью формирования словарей с полными уникальными ключами (заголовки колонок и строк отчёта); 2. Сканирование полученных словарей с целью задания монотонно возрастающих целочисленных значений с шагом 1 (номера колонок и строк отчёта по порядку); 3. Сканирование гиперкуба с целью восстановления полученных ранее ключей и получения по ним координат ячеек отчёта из сформированных словарей, заполнение отчёта; В первых реализациях все три пункта выполнялись в одном потоке, что при наличии многоядерных процессоров являлось само по себе не эффективным. Поэтому, с целью оптимизации быстродействия алгоритма, было решено 184 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 185. провести распараллеливание с помощью технологии MapReduce. Предварительный анализ затратвремени показал, что на пункты 1 и 3 алгоритма приходится свыше 95% общих затрат времени, поэтому пункт 2 распараллеливать нецелесообразно. Рис. 1. Диаграмма деятельности. Пункты 1 и 3, предложенные к распараллеливанию, не являются потоковобезопасными – в них осуществляется модификация глобальных объектов: словари с полными ключами и ячейки отчёта. Но одним из плюсов MapReduce является возможность абстрагирования от использования низкоуровневых примитивов синхронизации, поэтому приведенные ниже фрагменты кода не содержат ни мьютексов, ни семафоров, ни блокировок на чтение-запись. Так, пункт 1 реализован следующим образом: Листинг 5. Функции Map и Reduce для формирования словарей с полными ключами. QMapQString, int _dimensions; QMapQString, int _xCoordinates, _yCoordinates; QStringList _xDimensions, _yDimensions; QPairQString, QString mapFullKeys(const Tuple tuple) { QPairQString, QString keys; Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 185
- 186. QString key; int i= 0; foreach (const QString dimension, _xDimensions) { i = _dimensions[dimension]; key += tuple.keys()[i]; } keys.first = key; key.clear(); foreach (const QString dimension, _yDimensions) { i = _dimensions[dimension]; key += tuple.keys()[i]; } keys.second = key; return keys; } void reduceFullKeys(int /*i*/, const QPairQString, QString keys) { _xCoordinates[keys.first] = -1; _yCoordinates[keys.second] = -1; } Функция mapFullKeys в листинге 5 вызывается для каждого элемента гиперкуба параллельно. Имена выбранных для отчёта измерений представлены в виде двух списков: _xDimensions, _yDimensions. С помощью словаря _dimensions восстанавливаются индексы измерений и уже по индексам извлекаются их значения. В случае если на строки отчёта отображаются несколько измерений гиперкуба, то ключ будет представлять собой конкатенацию значений измерений. То же самое справедливо и для столбцов. В итоге функция возвращает пару ключей, которая автоматически передается функции reduceFullKeys, которая, в свою очередь, помещает ключи в формируемые словари _xCoordinates и _yCoordinates. В итоге словари будут состоять из уникальных ключей, автоматически отсортированных в порядке возрастания. На втором шаге оба словаря перебираются по порядку и ключам присваиваются возрастающие значения: 0, 1, 2, 3 и т.д. Таким образом, словари в качестве ключей содержат заголовки столбцов и строк будущего отчёта, а в качестве значений – их порядковые индексы. Реализация третьего шага отображена ниже: Листинг 6. Функции Map и Reduce для заполнения отчёта. QMapQString, int _dimensions; QMapQString, int _xCoordinates, _yCoordinates; QStringList _xDimensions, _yDimensions; Projection _projection; Cell mapProjection(const Tuple tuple) { 186 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 187. QString key; foreach (constQString dimension, _xDimensions) { int i = _dimensions[dimension]; key += tuple.keys()[i]; } int x = _xCoordinates[key]; key.clear(); foreach (const QString dimension, _yDimensions) { int i = _dimensions[dimension]; key += tuple.keys()[i]; } int y = _yCoordinates[key]; return Cell(x, y, tuple.measure()); } void reduceProjection(int /*i*/, const Cell cell) { _projection[cell.x()][cell.y()] += cell.value(); } Функция mapProjection в листинге 6 строит уникальные ключи по той же схеме, что и mapFullKeys в листинге 5. По ключам из сформированных ранее словарей _xCoordinates и _yCoordinates извлекаются координаты ячеек отчёта, а из текущего кортежа гиперкуба извлекается величина _measure. Все три значения передаются в функцию reduceProjection в виде экземпляра класса Cell. В свою очередь, reduceProjection по указанным координатам получает ячейку отчёта и к её значению прибавляет величину _measure. После распараллеливания алгоритма была проведена экспериментальная оценка затрат времени на построение отчета по различным сочетаниям измерений гиперкуба. Для того чтобы наглядно убедиться в эффективности MapReduce, описанная выше реализация сравнивается с тестовой реализацией, выполненной по технологии PTHREAD[10] с использованием примитивов синхронизации. Априори известно, что затраты времени зависят от ряда как контролируемых, так и неконтролируемых факторов, таких как: 1. объём выборки из базы данных, т. е. размер гиперкуба; 2. количество и длины полных ключей измерений гиперкуба, выбранных для построения отчёта; 3. количество параллельных потоков; 4. тип процессора: архитектура, количество ядер, частота, объём кэш; 5. объём и частота основной памяти; 6. тип, разрядность и версия операционной системы, частота системного таймера; 7. версия Qt Framework. Из перечисленных факторов, факторы с 4 по 7 являются неконтролируемыми и, более того, все они быстро меняются с течением времени, поэтому их влияние можно оценить только качественно. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 187
- 188. Первый фактор, покаобъём выборки не превышает объем доступной оперативной памяти, соответствует линейной зависимости затрат времени от размера выборки; при этом соотношение затрат времени для различных вариантов реализации параллельного кода должно оставаться постоянным, поэтому в эксперименте рассматривается достаточно малый объём данных: тестовый гиперкуб имеет 9 измерений и состоит из 66 354 кортежей. Для оценки количества и размеров составных ключей предлагается использовать обобщённый параметр K, для определения которого используется следующее соотношение, основанное на том, что среднее время поиска в дереве пропорционально его глубине, а среднее время сравнения двух строк пропорционально их длине[11]: K= log2(N)*L . (1) где: K– обобщённый параметр; N– количество ключей; L– средняя длина ключа. Так как отчёт является двумерным массивом, то результирующий показатель будет равен сумме показателей для колонок и строк: K = Kx + Ky = log2(X)*Lx + log2(Y)*Ly . (2) где: K – результирующий параметр; Kx,y – обобщённые параметры для колонок и строк; X, Y – количество ключей; Lx,y – средние длины ключей. Для проведения экспериментов использовался компьютер с 6-ядерным процессором AMD Phenom II X6 1100T и 4 Гб ОЗУ; операционная система Linux KUbuntu 12.04 LTS 64-bit с версией ядра 3.2; Qt Framework версии 4.8.4. Данные снимались в 10-кратной повторности. Для определения затрат времени на формирование словарей с ключами и заполнение отчёта использовался системный вызов clock_gettime. На рисунке 2 представлены общие затраты времени для сравниваемых технологий: однопоточного варианта, многопоточного варианта на MapReduce и многопоточных вариантов на PTHREAD - в зависимости от значений предлагаемого обобщенного параметра K. 188 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 189. Рис. 2. Затратывремени на формирование ключей и заполнение отчета в зависимости от обобщенного параметра для 6-ядерного процессора AMD Phenom II X6 1100T, частота ядер 3.3 ГГц, кэш 6144 Кб, 64-разрядная ОС Linux 3.2, Qt 4.8.4. Из графиков видно, что гипотеза о линейной зависимости затрат времени от обобщённого параметра K подтвердилась. Общие затраты времени для варианта с 6 потоками PTHREAD и для варианта с использованием MapReduce очень близки между собой. Однако с увеличением значения обобщенного параметра, MapReduce демонстрирует лучшую эффективность. Поскольку для конечного пользователя, QA-специалиста, важны общие затраты времени, а для разработчиков - кроссплатформенность и масштабируемость, MapReduce является верным выбором при оптимизации задачи многофакторного анализа на стороне клиента. 4 Заключение Описанная методика анализа данных, обладая высокой эффективностью, кроссплатформенностью и масштабируемостью, является подходящей альтернативой существующим решениям при обработке результатов нагрузочного тестирования трейдинговых платформ. Алгоритм прост в использовании, т.к. его конфигурация заключается лишь в написании стандартного SQL-запроса выборки SELECT, придерживаясь указанных правил; а применение технологии MapReduce позволяет использовать доступную мощь многоядерных процессоров, которые в настоящее время устанавливаются на абсолютное большинство компьютеров. Данное решение апробируется в ряде проектов по нагрузочному тестированию компании «Exactpro Systems», LLC. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 189
- 190. Литература 1. Иткин И.Л.:Тестирование биржевых систем в условиях высокочастотного трейдинга // SQA Days #10: [Электронный ресурс]. Режим доступа: http://sqadays.com/talk.sdf/sqadays/11151/talks/12196 2. Каширин И.Ю., Семченков С.Ю.: Интерактивная аналитическая обработка данных в современных OLAP-системах // Бизнес-информатика. 2009. Вып. 2(8). 3. SQL Server Analysis Services - Multidimensional Data // MSDN: [Электронный ресурс]. Режим доступа: http://msdn.microsoft.com/en-us/library/bb522607(v=sql.105).aspx 4. Oracle OLAP // Oracle: [Электронный ресурс]. Режим доступа: http://www.oracle.com/technetwork/database/options/olap/index.html 5. Palo by Jedox // Palo: [Электронный ресурс]. Режим доступа: http://palo.net/ 6. Comparison - Palo (Open Source) / Jedox (Premium) // Palo: [Электронный ресурс]. Режим доступа: http://www.palo.net/index.php?id=13 7. Jelen Bill, Alexander Mike. Pivot table data crunching. Pearson Education: 2011. 8. Alexey Zverev: Technical Testing // EXTENT February 2011: [Электронный ресурс]. Режим доступа: http://www.slideshare.net/IosifItkin/technical-testing-introduction 9. Qt 4.8: Concurrent Programming // Qt Reference Documentation: [Электронный ресурс]. Режим доступа: http://doc-snapshot.qt-project.org/4.8/threads-qtconcurrent.html 10. Blaise Barney: POSIX Threads Programming // Lawrence Livermore National Laboratory: [Электронный ресурс]. Режим доступа: https://computing.llnl.gov/tutorials/pthreads/ 11. Кнут Д. Э.: Искусство программирования, том 3. Сортировка и поиск, 2-е издание. – М.: Издательский дом «Вильямс», 2003. 190 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 191. Особенности инструментов длятестирования, применимых при промышленной эксплуатации трейдинговых систем Aнастасия Матвеева1, Николай Антонов2, Иосиф Иткин3 1 ООО «Инновационные Трейдинговые Системы», Россия, 156013, г. Кострома, ул. Ленина, 20, Anastasia.Matveeva@exactpro.com 2 Костромской государственный технологический университет, г. Кострома, ул. Дзержинского, 17, Nikolay.Antonov@exactpro.com 3 Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA Iosif.Itkin@exactpro.com Aннотация. В статье рассматриваются основные требования к инструментам, разработанным для верификации корректной работы электронных трейдинговых систем с использованием методов большого объема автоматизированного тестирования (НiVAT); анализируется применимость подобных инструментов при промышленной эксплуатации трейдинговых систем. Ключевые слова: автоматизация тестирования, трейдинговые системы, HiVAT. 1 Введение Ускоренное развитие технологий, используемых в электронных трейдинговых системах, признается одним из наиболее существенных факторов, влияющих на изменения в структуре и стабильности функционирования международных финансовых рынков [1]. Решения, обеспечивающие качество программных и архитектурных компонентов, становятся все более востребованными участниками рынка и организациями, регулирующими финансовый сектор [2; 3]. С технологической точки зрения трейдинговые системы в большинстве случаев являются сложными адаптивными распределенными программноаппаратными комплексами, осуществляющими параллельное выполнение большого количества транзакций в режиме реального времени [4]. Современные системы обеспечивают время отклика, измеряемое долями миллисекунды, и при своей работе генерируют значительные объемы данных [5]. В связи с возрастающей долей финансовых транзакций, осуществляемых посредством автоматизированных компьютерных систем [6], основные взаимодействия в трейдинговых системах базируются на различных открытых и закрытых сетевых протоколах и программных интерфейсах доступа [7]. Специфика автоматизированных рабочих мест пользователя трейдинговой системы состоит, в частности, в высокой частоте обновления данных о Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 191
- 192. котировках, статусе выполненияфинансовых транзакций, текущих позициях и рисках [8]. Рассмотрим несколько ключевых аспектов обеспечения качества трейдинговых систем: Как и другие сложные многопоточные системы, трейдинговые платформы предрасположены к появлению в них трудновоспроизводимых сбоев [9], которые проявляются, исключительно когда система находится под нагрузкой. Часто речь идет о функциональных проблемах, не связанных с исчерпанием ресурсов системы, но вызванных ситуацией конфликтующих друг с другом по времени условий (race conditions) при обработке параллельных транзакций или проявлением статистически маловероятных внутренних нарушений целостности [10]. Нахождение таких проблем требует проведения верификации на границе между функциональным и нагрузочным тестированием [11]; Обеспечение полноты покрытия тестами функциональности трейдинговой системы требует большого количества сценариев в библиотеке автоматизированных тестов [12]. Количество нуждающихся в проверке комбинаций особенно велико для производных и составных финансовых инструментов [13]. Даже однократный прогон сценариев такой библиотеки тестов через систему приводит к продолжительному исполнению последовательности автоматических тестов. Многократный запуск позволяет выделить скрытые проблемы с внутренними состояниями системы; Регулирующие органы, акционеры и участники торгов ожидают высокой устойчивости биржевых и брокерских систем к непредусмотренным внешним воздействиям [3]. В научной литературе детально проработаны методы тестирования устойчивости, основанные на прогоне большого количества случайно созданных данных через систему — фаззинге (fuzzing) [14]. Описанные выше свойства приводят к необходимости отправки большого количества созданных для тестирования сообщений в систему в течение продолжительного периода времени. Для обнаружения дефектов, связанных с обработкой потоков сообщений, необходима доскональная функциональная верификация выходящих сообщений и внутренних состояний системы. Применимые для этого методы известны под аббревиатурой HiVAT – большие объемы автоматизированного тестирования (High Volume Automated Testing) [15; 16; 17]. Эти методы направлены на выявление проблем, которые с большой долей вероятности могут остаться незамеченными при использовании других подходов, требующих ручного создания сценариев для автоматического тестирования и приводящих к статистически недостаточному количеству выходных данных. Опыт авторов показывает, что для высоконагруженных трейдинговых систем использование HiVAT-методов служит не столько возможным способом расширения покрытия тестированием, сколько обязательным методом их тестирования в условиях, приближенных к использованию в режиме промышленной эксплуатации. Продолжительное применение HiVAT-методов позволило выявить основные требования к инструментам тестирования. Эти требования перечисляются во второй части данной статьи. Третья часть посвящена сравнению инструментов тестирования с трейдинговыми системами, используемыми в промышленной 192 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 193. эксплуатации. В последнейчасти приведены возможные расширения созданных средств и направления дальнейших исследований. 2 Требования к инструментам тестирования По влиянию на тестируемую систему инструменты тестирования можно разделить на два типа: пассивные и активные [18]. Пассивное тестирование — это процесс обнаружения неисправностей в тестируемой системе путем исследования ее поведения без оказания воздействий на нормальный процесс работы. Активные инструменты непосредственно воздействуют на трейдинговую систему и используются для обмена сообщениями, анализа полученных от системы откликов, нагрузочного тестирования. 2.1 Пассивные инструменты тестирования Пассивные инструменты тестирования используются для автоматизированного сбора логов, структурирования данных, мониторинга и анализа поведения системы, сертификации пользователей. Инструменты тестирования позволяют оперативно исследовать большой объем данных, реагировать на отклонения в поведении системы от установленных требований, локализировать неполадки. Инструмент тестирования позволяет эффективно решать эти задачи, если выполнены следующие требования: обеспечена полнота сбора данных обо всех событиях в системе; минимизировано влияние на систему; обеспечено оповещение в реальном режиме времени о нестандартных ситуациях; реализованы гибко настраиваемые критерии распознавания образов; обеспечено хранение и предоставление доступа к историческим данным; предоставлена возможность отслеживать последовательность событий и внутренние состояния системы на определенный момент времени. Нахождение первопричины сбоя, произошедшего при использовании HiVATметодов, зачастую является более сложным процессом по сравнению с обычными методиками ручного и автоматизированного тестирования. Эта сложность обусловлена, в основном, двумя факторами: автоматическим созданием сценариев тестирования и большим объемом разнородных данных, пропущенных через систему. Тестировщику необходимы удобные инструменты, информирующие его о возникновении проблем и позволяющие детально исследовать состояние системы до и после возникновения сбоев. Недетерминированный характер входного потока сообщений, являющийся отличительной чертой использования HiVAT-методов, подразумевает необходимость в гибкости сценариев распознавания проблем и предоставление тестировщику возможностей по их настройке. Невозможно обеспечить полноту сбора информации без присутствия эффекта измерения для высоконагруженной системы. Задача инструмента тестирования Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 193
- 194. состоит в том,чтобы минимизировать влияние самого инструмента на функциональность и производительность тестируемой системы. Инструмент дожен предоставлять доступ к детальным и аггрегированным данным, полученным в результате выполнения текущей и предыдущих итераций тестирования. Диаграмма на рис. 1 показывает компоненты необходимые для реализации перечисленных требований к пассивным инструментам тестирования. Рис. 1. Высокоуровневая схема основных компонентов инструмента для пассивного тестирования трейдинговых систем 2.2 Активные инструменты тестирования Инструмент для активного тестирования должен обладать универсальностью, то есть способностью подключаться к различным тестируемым окружениям, используя разнообразные протоколы. Применение фаззинга для распределенных трейдинговых систем накладывает ограничения на создаваемые сообщения [25] с целью обеспечить их прохождение к ядру и другим внутренним компонентам без блокирования их на внешних шлюзах протокольных подключений или на начальных ступенях защиты модулей контроля рисков. Автоматический характер создания сценариев тестирования и их значительный объем требует сохранения информации об отправленных сообщениях и внутренних состояниях инструмента тестирования, его настройках. При использовании сложных техник необходима также сверка данных между инструментом и тестируемой системой. Использование HiVAT-методов для высоконагруженных трейдинговых систем требует создания масштабной инфраструктуры для тестирования. 194 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 195. Эффективность использования такойинфраструктуры может быть обеспечена только в случае одновременной доступности ее для выполнения различных задач тестирования. Инструменты для тестирования должны позволять выполнять вручную и ставить в расписание прогонов наборы автоматизированных сценариев даже в случаях, когда параллельно многократно выполняются сценарии библиотеки регрессионного тестирования или тесты, основанные на техниках случайной генерации тестов. Для создания полноценных функциональных тестов инструмент должен предоставить удобные программируемые возможности для управления процессом генерации автоматизированных сценариев тестирования. Диаграмма на рис. 2 показывает компоненты, необходимые для реализации перечисленных требований к активным инструментам тестирования. Рис. 2. Высокоуровневая схема основных компонентов инструмента для активного тестирования трейдинговых систем 2.3 Общие требования к инструментам для тестирования трейдинговых систем Следующие характеристики являются обязательными как для пассивных, так и для активных инструментов при использовании HiVAT-методов: масштабируемость и высокая пропускная способность; устойчивость; адаптивность; Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 195
- 196. удобность иинтерактивность. Эти обязательные характеристики совпадают с предъявляемыми к промышленным трейдинговым системам. требованиями, 3 Использование инструментов тестирования промышленной эксплуатации трейдинговых систем в В этой части статьи мы сопоставим требования, предъявляемые к инструментам для тестирования трейдинговых систем с использованием методов HiVAT, с требованиями к трейдинговым системам и системам мониторинга, используемым в промышленной эксплуатации. Таблица 1. Требования к системам мониторинга и контроля финансовых рисков Требование Полнота сбора данных обо всех событиях в системе Минимизация влияния на трейдинговую систему Оповещение в реальном режиме времени о нестандартных ситуациях Использование в промышленной эксплуатации Основная задача системы мониторинга и контроля финансовых рынков — поддерживать аналитическую работу отделов, отвечающих за выявление возможных манипуляций [19]. Система мониторинга должна собирать информацию обо всех входящих заявках, ответах системы, данных, поступающих из внешних источников, а также о релевантных внутренних состояниях трейдинговой платформы. Сбор большого объема информации невозможен без масштабируемой мониторинговой инфраструктуры. Наблюдение за рынком исключительно важный процесс, являющийся обязательным в абсолютном большинстве финансовых юрисдикций. Тем не менее, для обеспечения минимальных времен отклика на приходящие в реальном режиме времени сообщения операторы трейдинговых систем стараются избегать негативного влияния эффекта измерения на основную функциональность трейдинговой платформы. Операторы системы должны быть немедленно уведомлены при возникновении технических проблем или подозрительных транзакций. Такие уведомления называются оповещениями системы мониторинга (surveillance alerts). Эффективно работающая система оповещения — ключевой компонент системы мониторинга и контроля рисков. Гибко настраиваемые Очень часто недобросовестные участники рынка пытаются критерии распознавания скрыть злоупотребления и манипуляции рынком под видом образов легитимных финансовых транзакций. Системам мониторинга и контроля рынков приходится делать 196 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 197. аналитические заключения наоснове нечеткой логики, параметры которой приходится непрерывно адаптировать под новые трейдинговые ситуации и схемы поведения участников торгов [20]. Хранение и предоставление доступа к историческим данным По запросам аудита или регулирующих органов операторы трейдинговых систем обязаны предоставлять исторические данные и результаты их обработки Возможность отследить последовательность событий и внутренние состояния системы на определенный момент времени Формальные критерии сами по себе не являются достаточным доказательством наличия манипуляции. Операторы системы нуждаются в возможности восстанавливать последовательность событий относящихся к конкретным эпизодам, вызвавшим оповещение о проблеме. Данная функция называется проигрыванием книги заявок (order book replay). Удобная реализация позволяет операторам исследовать большее количество событий и делать выводы о правильности работы механизмов распознания образов. Рис. 3. Высокоуровневая схема основных компонентов системы мониторига и контроля финансовых рисков создаваемой в компании «Exactpro Systems», LLC. Из схемы на рис. 3 видна концептуальная близость системы к инструментам для пассивного тестирования трейдинговых платформ. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 197
- 198. Таблица 2. Требованияк системам выполнения биржевых и алгоритмических заявок Требование Универсальность. Подключение ко множеству других систем и поддержка используемых ими протоколов Использование в промышленной эксплуатации В условиях фрагментации финансовых рынков брокерские системы должны обеспечивать возможность подключения к разным биржевым системам и сторонним брокерам [21]. Высоконагруженная трейдинговая система должна Предоставление одновременного доступа обеспечить одновременный доступ большому количеству участников торгов Возможность выполнения сложных сценариев Хранение информации обо всех отправленных сообщениях и внутренних состояниях. Возможность сверки этих данных с данными, поступающими из внешних систем, включая клиринг и депозитарии 198 Основная функция систем алгоритмической торговли — предоставление пользователям возможности задавать стратегию посылки заявок на выполнение финансовых транзакций в зависимости от состояния рынка, портфеля, параметров риска, информационных сообщений и т.д. Оператор трейдинговой системы, предоставляющий доступ своим клиентам на финансовые рынки, обязан хранить информацию обо всех совершенных финансовых транзакциях [22] и производить сверку этих данных с данными клиентов и контрагентов, а также с информацией из пост-торговых систем. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 199. Рис. 4. Высокоуровневаясхема основных компонентов системы выполнения биржевых и алгоритмических заявок, создаваемой в компании «Exactpro Systems», LLC. Из схемы на рис. 4 видна концептуальная близость системы к инструментам для активного тестирования трейдинговых платформ. 4 Направление дальнейших исследований Сравнение требований и концептуальных схем инструментов для тестирования с соответствующими промышленными системами позволяет утверждать, что, начиная с определенного уровня зрелости инструменты для тестирования могут использоваться как подсистема трейдинговой платформы. Но основной задачей тестирования является не нахождение правильно работающих подсистем, а выявление проблем и недостатков в исследуемом приложении. Превращение инструментов для тестирования в промышленные трейдинговые системы может потенциально привести к концентрации взаимодействия на корректно работающих участках, снижению покрытия тестами и избыточному фокусу на позитивных сценариях. Основное направление дальнейшей работы — это нахождение методов преодоления этой тенденции. Если инструменты для тестирования становятся частью промышленной инфраструктуры, то внесение небольших изменений в их код и настройки, является по сути изменением содержащей их трейдинговой платформы. Таким образом, предложенный подход открывает новые возможности по применению методов мутационного тестирования на системном уровне к исследованию Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 199
- 200. сложных интегрированных трейдинговыхсистем [23]. Внесенные изменения называются мутациями и основываются на мутационных операторах [24], которые имитируют типичные ошибки или нежелательные воздействия. Мутации также позволяют оценить эффективность существующего набора тестов и качество инструментов для тестирования. Операторами мутации трейдинговой системы для проверки нефункциональных свойств могут стать следующие изменения: введение случайных задержек во внутренние компоненты, логические алгоритмы и в функционирование внешних подключений; замена оптимизированных TCP/IP потоков данных на множество параметризованных библиотек на различных языках; заполнение памяти или дискового пространства на компьютере с исследуемой системой большим количеством логов; загрузка сети паразитными сообщениями или внедрение ошибок в структуры данных. Второе направление дальнейших исследований - это изучение методов фаззинга, совместимых со структурой и консистентностью промышленных систем [25]. 5 Заключение На основе обобщения опыта по верификации корректной работы высоконагруженных электронных трейдинговых систем с функциональной и нефункциональной точек зрения в статье проанализированы методы обеспечения их качества, основанные на большом объеме автоматизированного тестирования (НiVAT). Практическое использование этих методов авторами позволило определить набор основных требований к инструментам пассивного и активного тестирования, применяемым для верификации подобного рода систем. В статье сделан вывод, что инструмент для тестирования, соответствующий определенному набору требований, является по своей сути системой, применимой при промышленной эксплуатации трейдинговых систем. Полученные авторами результаты обосновали оправданность финансирования создания инструментов для тестирования, основанных на описанных выше методах и принципах. В рамках проектов компании «Exactpro Systems», LLC разрабатываются: система мониторинга и контроля финансовых рынков и система поддержки алгоритмической торговли. Обе системы имеют двойное назначение и могут использоваться и как инструмент для тестирования, и как самостоятельный элемент промышленной трейдинговой инфраструктуры [26]. Выше были рассмотрены также дополнительные возможности по использованию методов мутационного тестирования на системном уровне для анализа и расширения полноты покрытия функциональными и нефункциональными тестами. Указанные возможности открываются при включении инструментов тестирования в состав трейдинговой платформы. 200 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 201. Литература 1. The Futureof Computer Trading in Financial Markets. Final Project Report. / Foresight. The Government Office for Science, London. // [Электронный ресурс]. – Режим доступа http://www.bis.gov.uk/assets/foresight/docs/computer-trading/12-1086-future-of-computertrading-in-financial-markets-report.pdf 2. Bloomfield,R., Wetherilt,A.: Computer trading and systemic risk: a nuclear perspective. / Foresight. The Government Office for Science, London // [Электронный ресурс]. – Режим доступа http://www.bis.gov.uk/assets/foresight/docs/computer-trading/12-1059dr26-computer-trading-and-systemic-risk-nuclear-perspective.pdf 3. Commission Roundtable on Technology and Trading: Promoting Stability in Today's Markets. / U.S. Securities and Exchange, October 2, 2012 // [Электронный ресурс]. – Режим доступа http://www.sec.gov/news/otherwebcasts/2012/ttr100212-transcript.pdf 4. Иткин И.Л.: Высоконагруженные трейдинговые системы и их тестирование. / Конференция разработчиков высоконагруженных систем HighLoad++ // [Электронный ресурс]. – Режим доступа http://www.highload.ru/2012/abstracts/388.html 5. Penhaligan,P.: Equity Trading: Performance, Latency Throughput. / ExTENT Conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3turquoise-equitytrading2012 6. Avellaneda,M.: Algorithmic and High-frequency trading: an overview / New York University Finance Concepts LLC Quant Congress USA 2011. // [Электронный ресурс]. – Режим доступа http://www.math.nyu.edu/faculty/avellane/QuantCongressUSA2011AlgoTradingLAST.pdf 7. Millennium Exchange Technical Specifications / Официальный сайт London Stock Exhcange // [Электронный ресурс]. – Режим доступа http://www.londonstockexchange.com/products-and-services/technical-library/millenniumexchange-technical-specifications/millennium-exchange-technical-specifications.htm 8. Zverev,A., Bobrov,I, Pryadkina,N..: Testing of HFT GUI. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3exactpro-testingofhftgui-12944204 9. Yu,T.: An observable and controllable testing framework for modern systems. // ICSE '13: Proceedings of the 2013 International Conference on Software Engineering Publisher: IEEE Press, May 2013 10. Netzer,R.H.B, Miller,B.P.: What are race conditions?: Some issues and formalizations // Letters on Programming Languages and Systems (LOPLAS) , Volume 1 Issue 1, March 1992 11. Zverev,A., Bulda,A., Bobrov,I.: Trading Systems: Testing at the Confluence of FTNFT. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent-2013-obninsk-trading-systems-testing-at-theconfluence-of-ft-nft-17082512 12. Heider,W., Rabiser,R., Grünbacher,P., Lettner,D.: Using regression testing to analyze the impact of changes to variability models on products. // SPLC '12: Proceedings of the 16th International Software Product Line Conference - Volume 1, September 2012 13. Eurodollars on CME Globex: Implied Price Functionality // [Электронный ресурс]. – Режим доступа http://www.cmegroup.com/trading/interest-rates/files/Butterflies.pdf 14. Sutton,M., Greene,A., Amini,P.: Fuzzing: Brute Force Vulnerability Discovery. // AddisonWesley Professional, 2007 15. McGee,P., Kaner,C.: Experiments with high volume test automation. // SIGSOFT Software Engineering Notes, September 2004 16. Kaner,C: An Overview of High Volume Automated Testing. // [Электронный ресурс]. – Режим доступа http://kaner.com/?p=278 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 201
- 202. 17. Teaching HighVolume Automated Testing (HiVAT). //12th Workshop on Teaching Software Testing (WTST 2013), January 25-27, 2013, Melbourne, Florida, at the Harris Institute for Assured Information. // [Электронный ресурс]. – Режим доступа http://wtst.org/ 18. Cavalli,R., Montes de Oca,E., Mallouli,W., Lallali,M.: Two Complementary Tools for the Formal Testing of Distributed Systems with Time Constraints. //12th 2008 IEEE/ACM International Symposium on Distributed Simulation and Real-Time Applications. 19. Diaz,D., Zaki,M., Theodoulidis,B., Sampaio,P.: A Systematic Framework for the Analysis and Development of Financial Market Monitoring Systems. // 2011 Annual SRII Global Conference 20. Иткин И., Прядкина Н., Крюков А.: Анализ данных в высоконагруженных трейдинговых системах. / Конференция АИСТ-2013. // [Электронный ресурс]. – Режим доступа http://clubqa.ru/blogs/?p=436 21. Официальный сайт Fidessa Fragmentation Index // [Электронный ресурс]. – Режим доступа http://fragmentation.fidessa.com/ 22. OATS Reporting Technical Specifications. // [Электронный ресурс]. – Режим доступа http://www.finra.org/web/groups/industry/@ip/@comp/@regis/documents/appsupportdocs/ p197473.pdf 23. Mateo,P.R., Usaola,M.P., Alema´n,J.L.F.:Validating Second-Order Mutation at System Level. // IEEE Transactions on softvare engineering, vol. 39, No. 4, April 2013 24. Mateo,P.R., Usaola,M.P., Offutt,J.: Mutation at System and Functional Levels. // Third International Conference on Software Testing, Verification, and Validation Workshops 25. Wang,T., Wei,T., Gu,G., Zou,W.: Checksum-Aware Fuzzing Combined with Dynamic Taint Analysis and Symbolic Execution. // ACM Transactions on Information and System Security, Vol. 14, No. 2, Article 15, Publication date: September 2011 26. Itkin,I., Matveeva,A., Barch,A.: Test Tools evolution. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent2013-obninsk-test-tools-for-trading-systems-evolution-theory-17007184 202 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 203. Тестирование совместимости протокольных подключенийклиентов биржевых и брокерских систем Андрей Алексеенко1, Анастасия Матвеева1, Даниил Шаров1, Павел 2 Проценко , Иосиф Иткин3 1 ООО «Инновационные Трейдинговые Системы», Россия, 1156088, г. Москва, 2-й Южнопортовый проезд, 20А/4 Andrey.Alexeenko@exactpro.com, Anastasia.Matveeva@exactpro.com, Daniel.Sharov@exactpro.com 2 Exactpro Systems UK, 10 Paternoster Square, London, EC4M 7LSl, UK Pavel.Protsenko@exactpro.com 3 Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA Iosif.Itkin@exactpro.com Aннотация. Жизненный цикл разработки биржевого и брокерского программного обеспечения, помимо проверки функциональных и технических характеристик системы, включает в себя обязательный этап интеграционного тестирования, называемый сертификацией клиентов. Этот этап призван обеспечить совместимость систем автоматизированной торговли, подключаемых к бирже или брокеру посредством финансовых протоколов (таких как FIX/FAST, ITCH или специализированные бинарные интерфейсы доступа). В статье представлен оригинальный инструмент, разработанный для проверки совместимости торговых систем. Отличительная особенность разработанного инструмента унифицированный способ поддержки множества протоколов. Приведены примеры его использования при самостоятельной сертификации участников торгов, а также при масштабных миграциях трейдинговых платформ. Ключевые слова: финансовые протоколы, FIX-протокол, тестирование совместимости, самостоятельная сертификация, торговый брокер, биржа. 1 Введение Адаптация новых клиентов к трейдинговой платформе и их поддержка при обновлениях программного обеспечения - это один из ключевых бизнеспроцессов биржевых и брокерских организаций [1; 2; 3]. Существенной составляющей этого процесса служит тестирование, проводимое для выявления проблем с совместимостью трейдинговой платформы с системами, принадлежащими подключаемым к бирже или брокеру участникам торгов, называемое сертификацией клиентов [4]. Сертификация клиентов обязательна для любого оператора биржевой или брокерской платформы, предоставляющей возможность осуществлять финансовые транзакции, и в настоящее время широко используется в Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 203
- 204. финансовой индустрии [5].Ссылки на правила сертификации клиентов и соответствующую документацию можно найти на официальных сайтах соответствующих организаций [6; 7; 8; 9]. Программное обеспечение, ранее успешно прошедшее внутреннее интеграционное тестирование, проходит после этого через завершающий тест интеграцию с клиентами (обычно юридическими лицами). Общепринятой практикой является ситуация, когда клиенты и оператор трейдинговой платформы задают временной интервал для выполнения активного тестирования и оценивают его результаты с обеих сторон. В связи с тем, что в процесс сертификационного тестирования вовлечены люди, представляющие разные компании, данный процесс требует значительной степени координации и слаженности работы. Это чрезвычайно важно как с финансовой, так и с репутационной точек зрения. Любой дефект программного обеспечения, обнаруженный на этапе сертификационного тестирования, является достаточно дорогостоящим с точки зрения его устранения, поскольку все стадии жизненного цикла программного обеспечения уже пройдены [10], а любая задержка с обнаружением проблем совместимости вносит существенные дополнительные затраты. К характерным проблемам, с которыми приходится сталкиваться при проведении сертификации клиентов, относятся: наличие часовых поясов и возникающие в связи с этим сложности в планировании и координации проведения тестирования командами профессионалов, находящимися физически в разных частях земного шара; производительность: сертификация может требоваться несколькими клиентами одновременно из-за бизнес- или технических событий, таких как выход новых версий программного обеспечения, изменений нормативных или технических требований; компетентность: специалист по обеспечению качества программного обеспечения, проводящий сертификацию, обязан обладать должным уровнем технических и бизнес-знаний; покрытие: сертификационные тесты должны быть основаны на типичных сценариях и обеспечивать значимые результаты. В трейдинговой индустрии начинает формироваться понимание того, что одним из способов преодоления этих проблем может стать создание более совершенных решений по автоматизации сертификационного тестирования и анализу его результатов [11]. Несмотря на актуальность автоматизации процесса сертификации биржевых/брокерских клиентов, данная проблематика пока практически не освещена в отечественной и зарубежной научной литературе. На рынке присутствует несколько коммерческих инструментов тестирования, созданных для ускорения процесса сертификации клиентов: FIX Conductor от компании Lasalletech [12]; FACTS от B2BITS, EPAM Systems [13]; CertiFIX от Greenline [14]; Catalys Studio от Cameron [15]; 204 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 205. Ignition отFIXFlyer [16]; VegaFABS от Pravega Financial Technologies [17]; Certpoint от Tradepoint Systems [18]; Certification Platform от FixSpec.com [19]. Биржевые платформы используют два основных подхода к сертификации: Предоставление клиентам специализированного симулятора для проведения сертификации [20; 21; 22]. Клиенты проводят тестирование, используя предоставленный инструмент, и предоставляют логи сертификации; Предоставление доступа к специализированному тестовому окружению, которое является уменьшенной копией промышленной системы; документирование процедуры; совместное проведение сертификации с клиентом либо использование самостоятельной сертификации [23]; использование пассивных методов, таких как перехват трафика сетевых подключений или данные из лог-файлов, для анализа успешности и полноты проведенной процедуры сертификации. Оба подхода в той или иной степени реализованы в существующих коммерческих решениях. Основное достоинство метода, основанного на использовании симуляторов, это снижение нагрузки на сертифицирующую организацию и клиентов, обеспечиваемое возможностью проводить сертификацию в любое время суток, а не только в период открытого торгового дня. Проблема, специфичная для всех симуляторов, - отсутствие гарантии, что фактическое сообщение, отправленное с его помощью, идентично сообщениям, отправляемым реальным программным обеспечением [24]. Пассивное тестирование является, на наш взгляд, наиболее корректным методом проведения сертификации клиентов. Общая концепция пассивного тестирования и её преимущества описаны в [25], различные алгоритмы пассивного тестирования предложены в [26; 27]. Основным преимуществом пассивного тестирования является то, что инструмент для тестирования не оказывает влияния на тестируемую систему и не приводит к созданию потоков дополнительных сообщений. Данное преимущество, однако, одновременно является и недостатком: для успешного проведения пассивного тестирования необходимые сообщения должны быть кем-то созданы. В случае сертификации клиентов требуется привлекать представителей другой компании для создания входящего потока сообщений. Данная практика неизбежна при первичной сертификации. Однако с целью снижения временных затрат сторонних организаций требуется использовать более эффективные методы: например, предложенный в [28] подход. Используя данные первичной сертификации для автоматизированного создания новых сценариев тестирования, при сохранении неизменной спецификации протокола доступа, оператор трейдинговой платформы получает возможность провести повторную сертификацию клиента самостоятельно. Присутствующие на рынке инструменты для сертификации клиентов обладают следующими ограничениями: специализация на одном фиксированном протоколе, например FIX [29]; Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 205
- 206. интерактивные инструменты анализаданных и создания новых сценариев малопригодны для обработки действительно больших объемов данных о гетерогенных клиентских подключениях. Авторы принимают участие в разработке и использовании программного решения компании Exactpro Systems LLC, направленного на преодоление указанных ограничений [30; 31]. Созданный инструмент описывается во второй части данной статьи. Третья часть содержит описание практического использования созданного инструмента для самостоятельной сертификации участников биржевых торгов. Четвертая часть описывает использование разработанного инструмента при масштабных миграциях брокерских систем. 2 Многопротокольное решение тестировання трейдинговых систем для пассивного Инструмент для пассивного тестирования сетевых подключений к трейдинговым системам разработан с использованием языка Java и системы управления базами данных MySQL. В основе подхода - унифицированное описание структуры протокольных сообщений - система словарей. Для каждого протокола создается словарь. Для групп протоколов может потребоваться написание специальных модулей, приводящих сетевые потоки данных к унифицированному внутреннему формату на основе словарей. Концепция близка к логике Complex Events Processing [32]. Для создания шаблона словаря был взят и доработан для большей общности шаблон словарей, используемый в системе QuickFIX/J [33]. Разработанный инструмент может получать на входящие данные о перехваченных сетевых сообщениях, полученных с использованием tcpdump [34] или различных прокси-серверов [35]. Пользователю также предоставлена возможность загружать лог-файлы, содержащие массив сообщений, в настраиваемом формате. Основная таблица в базе данных содержит информацию о каждом перехваченном пакете, включая повторную пересылку TCP-данных. Если трейдинговая система находится под нагрузкой, сетевой пакет может содержать несколько сообщений или же сообщение может быть разбито между несколькими TCP-пакетами. Выделив сообщения из сетевых пакетов, инструмент делает попытку конвертации в унифицированный формат на основе словарей. Информация о сетевых пакетах и сообщениях, не прошедших проверку посредством словарей, заносится в отдельную таблицу, по сути содержащую список проблем сертификации первого уровня. Детали перехваченных и успешно обработанных сообщений могут быть сохранены в реляционную базу данных посредством двух основных методов: использования общей таблицы, содержащей идентификаторы сообщения, имя параметра и его значение; использования индивидуальной таблицы для каждого типа сообщения, размещая параметры сообщения в соответствующих колонках, с именами, произведенными от имени параметров. 206 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 207. Преимущество первого подхода– это большая общность. Преимущество второго подхода – удобство работы с SQL-запросами к базе данных. В разработанном инструменте используется комбинация обоих подходов: для каждого типа сообщений создана индивидуальная таблица, а данные из повторяющихся групп хранятся в общей таблице. Рисунок 1 содержит схему использования разработанного инструмента для перехвата и хранения сетевых сообщений. Рис.1. Процесс обработки сообщений в инструменте тестирования и сертификации. Перехваченные сообщения декодируются и складываются в базу данных инструмента. Все отчеты по сертификации хранятся в виде SQL запросов. При добавлении нового вида отчетов или иного требования, нет необходимости менять код самого инструмента. С помощью SQL запроса есть возможность найти сообщения по списку и их статус, и выделить их цветом с помощью пользовательского интерфейса для лучшего зрительного восприятия. SQL запросы так же могут быть использованы для нахождения необходимой статистики по сообщениям, количества заходов в приложения, синтаксически непроанализированные сообщения и т.д. Графический интерфейс пользователя разработанного инструмента позволяет аналитику, отвечающему за сертификацию или обеспечение качества трейдинговой платформы, просматривать сообщения и события в реальном режиме времени, включая детали сетевых пакетов, результаты верификации посредством системы словарей, значения индивидуальных полей и исходные бинарные данные. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 207
- 208. Сертификационные тесты исверки данных могут быть реализованы посредством обычных SQL-запросов. Инструмент предоставляет возможность подсветки и анализа сообщений, полученных в результате выполнения того или иного запроса. На рисунке 2 представлен пример окна графического интерфейса разработанного инструмента. Рис.2. Графический пользовательский интерфейс инструмента тестирования и сертификации. 3 Самостоятельная сертификация участников биржевых торгов Регулирующие органы требуют от операторов биржевой системы предоставления эквивалентного доступа всем участникам торгов [36]. При внесении изменений в технологическую платформу биржи ее оператор обязан провести сертификацию всех подключенных торговых систем в короткий промежуток времени. Данная особенность процесса создает существенную нагрузку на отделы организации-оператора биржевой площадки, отвечающие за поддержку клиентов. Для снижения этой нагрузки биржевые площадки используют метод самостоятельной сертификации. Клиентам предоставляется доступ к тестовому окружению и сценарий выполнения сертификационных тестов. После выполнения шагов предоставленного сценария клиент высылает логи процесса в сертифицирующую организацию, где они проходят дополнительную проверку. Пассивное тестирование значительно упрощает процесс сертификации для участников торгов. При данном подходе от них требуется только подключиться 208 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 209. к тестовому окружениюи отправить заявки, обозначенные в тестовом сценарии. Таким образом, участники торгов избавлены от выполнения любых шагов (таких как установка дополнительного программного обеспечения, сбор логов и т.д.), кроме тех, которые непосредственно необходимы для подключения к технологической платформе биржи. Разработанный инструмент перехватывает все сообщения, переданные от клиента к бирже или в обратную сторону, разбирает структуру и содержимое каждого сообщения и сохраняет всё в реляционную базу данных. Используя SQL-запросы, аналитик сертифицирующей организации может получить статистику по попыткам выполнения шагов тестового сценария и их успешности для каждого из участников торгов. Данные о сетевых пакетах позволяют также обнаружить дополнительные проблемы, такие как разрывы соединений или проблемы с буферизацией сообщений. Приведем пример сертификационного SQL-сценария, проверяющего успешность размещения клиентом агрессивной рыночной заявки, в результате появления которой по исполнении её против заявок, размещенных на противоположной стороне стакана заявок, образовались две и более сделки: insert into t_native_testcases (user,sourceip,sourceport,testcase,timestamp,clordid,orderid, otherid) select distinct n.user, n.sourceip, n.sourceport, 'MEx-012.2 Agg. MO' as testcase, n.timestamp, n.clordid, e.orderid, '' from t_lsenative_neworder n , t_lsenative_executionreport e , t_lsenative_executionreport e2 where n.user=e.user and n.sourceip=e.destinationip and n.sourceport=e.destinationport and n.clordid=e.clordid and n.user=e2.user and n.sourceip=e2.destinationip and n.sourceport=e2.destinationport and n.clordid=e2.clordid and n.ordertype=1 and e.ordstatus=1 and e.tradeliquidityindicator='R' and e2.typeoftrade='2' and e2.ordstatus in (1,2) and e2.tradeliquidityindicator='R' and e2.typeoftrade='2' and e.execid e2.execid order by user, clordid, orderid; Для нескольких биржевых платформ были разработаны совокупности SQLсценариев, покрывающие все требования по сертификации клиентских соединений, опубликованные организатором торгов [9]. 4 Миграция брокерской платформы с большим количеством гетерогенных клиентских подключений В сравнении с биржевыми платформами брокерские системы обычно предоставляют существенно более широкие возможности по настройке Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 209
- 210. протокола взаимодействия ссистемами клиентов: например, используя возможности таких систем, как UL Bridge [37]. Один и тот же клиент может использовать одновременно несколько брокеров для получения доступа на биржу. Часто брокеры стараются снизить количество изменений в протоколах коммуникации, которые конкретный клиент вынужден имплементировать со своей стороны. Облегчая взаимодействие с клиентом, этот подход одновременно приводит к появлению большого количесва гетерогенных конфигураций со стороны брокерской трейдинговой платформы. При внутренних изменениях брокерской платформы возникает необходимость в регрессионном тесте на совместимость с клиентскими системами. Разработанный инструмент позволяет обработать имеющиеся данные из тестовых и промышленных окружений и создать необходимый набор активных тестовых сценариев. Выполнив эти сценарии против тестового окружения без привлечения конечных клиентов тестовый инструмент запускает SQL-сценарии, выполняющие сверку ответов брокерской платформы до и после изменений. Особенность созданного авторами инструмента состоит в том, что он позволяет проводить этот процесс одновременно для большого количества клиентов, подключений, рынков и типов сообщений. Гибкость при создании сверяющих SQL-запросов позволяет не только исключить из сравнения поля, про которые заранее известно, что их значения должны различаться (например, sequence numbers, timestamps и другие), но и задать требования по обработке более сложных расхождений. Подход доказал свою жизнеспособность и эффективность при миграции трейдинговой платформы одного из крупнейших международных брокеров, предоставляющего доступ к торговле производными финансовыми инструментами. Последовательность шагов отображена на схеме на рисунке 3. 210 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 211. Рис.3. Схематичный примерреализации предлагаемого решения. Логи из промышленной системы загружаются в базу данных инструмента для тестирования и сертификации. Генератор скриптов использует данную базу для создания совокупности тестовых сценариев, исполняемых активным инструментом для функционального тестирования. Логи выполнения тестовых сценариев загружаются в базу данных для сравнения с данными полученными из промышленной системы. 4 Заключение С ростом объёмов автоматизированной электронной торговли стабильность и устойчивость финансовых рынков будут во все большей степени зависеть от корректной совместной работы платформ, обеспечивающих инфраструктуру рынков, и подключенных к ним автоматизированных трейдинговых систем. Стоимость процессов подключения новых клиентов, их сертификации и сохранения совместимости при регулярно вносимых изменениях существенно влияет на общую стоимость функционирования биржевых и брокерских систем. Представленный в статье инструмент используется с целью повышения эффективности и экономичности указанных процессов. Имеется позитивный опыт его применения в рамках проектов компании Exactpro Systems LLC на заключительных этапах выпуска в промышленную эксплуатацию Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 211
- 212. крупномасштабных трейдинговых системдля торговли финансовыми инструментами разных классов. В статье описаны используемые в индустрии методы сертификации клиентских подключений и сделаны выводы о преимуществах подхода, основанного на использовании многопротокольного пассивного инструмента, сохраняющего данные в реляционную СУБД. Рассмотрен также вариант использования данного инструмента с целью создания активных тестов и сокращения затрат при масштабных миграциях систем с множеством гетерогенных клиентских подключений. Дальнейшие исследования будут направлены на оптимизацию структуры базы данных: в частности, в вопросе распространения разработанных методов на трейдинговые протоколы, основанные не на сетевых взаимодействиях, а на программных интерфейсах доступа (API). Источники 1. Markit Magazine Issue 10 - Focus: Client Onboarding – Markit.com // [Электронный ресурс]. – Режим доступа http://www.markit.com/assets/en/docs/markit-magazine/issue10/mm10_focus5-onboardingroundtable.pdf 2. Fenergo 2013, Client Onboarding: Solving the Challenges, Maximizing the Opportunities. // [Электронный ресурс]. – Режим доступа http://www.fenergo.com/industryknowledge/whitepapers/client-onboarding-solving-challenges-maximizingopportunities.html 3. Axel Pierron, Anshuman Jaswal: Institutional Client On-Boarding in the Financial Industry Time to Move to the Industrialization Phase. // Celent Report, October 2012 // [Электронный ресурс]. – Режим доступа http://www.celent.com/reports/institutionalclient-boarding-financial-industry 4. Challenges and Solutions to Onboarding Trading Clients. // [Электронный ресурс]. – Режим доступа http://www.trdpnt.com/blog/bid/294222/Challenges-and-Solutions-toOnboarding-Trading-Clients 5. FIA Market Access Risk Management Recommendations April 2010. // [Электронный ресурс]. – Режим доступа http://www.futuresindustry.org/downloads/Market_Access6.pdf 6. Moscow Exchange. // [Электронный ресурс]. – Режим доступа http://fs.moex.com/files/4531 7. BOX Options Exchange. // [Электронный ресурс]. – Режим доступа http://boxexchange.com/what-you-need-to-know/software-certification/ 8. Eris Exchange. // [Электронный ресурс]. – Режим доступа http://www.erisfutures.com/sites/default/files/Electronic_Trading_Certification_Process.pd f 9. TQ 601 - Technical Specification Turquoise Equities Guide to Certification. // [Электронный ресурс]. – Режим доступа http://www.lseg.com/sites/default/files/content/documents/TQ601%20%20Guide%20To%20Application%20Certifcation.pdf 10. Forrest Shull, Vic Basili, Barry Boehm, A. Winsor Brown, Patricia Costa, Mikael Lindvall,Dan Port, Ioana Rus, Roseanne Tesoriero, Marvin Zelkowitz: What We Have Learned About Fighting Defects // METRICS '02 Proceedings of the 8th International Symposium on Software Metrics, IEEE Computer Society Washington, DC, USA 2002 212 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 213. 11. Candyce Edelen:Making the Case for Automated FIX Certification. // [Электронный ресурс]. – Режим доступа http://www.advancedtrading.com/high-frequency/making-thecase-for-automated-fix-certif/240155554 12. FIX Conductor™ от компании Lasalletech. // [Электронный ресурс]. – Режим доступа http://www.lasalletech.com/products/fix-automated-onboarding 13. FACTS от B2BITS, EPAM Systems. // [Электронный ресурс]. – Режим доступа http://www.b2bits.com/trading_solutions/fix_testing_facts.html 14. CertiFIX® от Greenline. // [Электронный ресурс]. – Режим доступа http://www.greenlinetech.com/products/certifix.php 15. Catalys Studio от Cameron. // [Электронный ресурс]. – Режим доступа http://www.camerontec.com/products/catalys/catalys-studio/ 16. Ignition от FIXFlyer. // [Электронный ресурс]. – Режим доступа http://fixflyer.com/materials/software/Ki/FlyerIgnition.pdf 17. VegaFABS от Pravega® Financial Technologies. // [Электронный ресурс]. – Режим доступа http://www.pravegatech.com/index.php?option=com_contentview=articleid=64Itemi d=65 18. Certpoint от Tradepoint Systems. // [Электронный ресурс]. – Режим доступа http://www.trdpnt.com/certpoint/ 19. Certification Platform от FixSpec.com // [Электронный ресурс]. – Режим доступа http://forexmagnates.com/fixspec-launches-innovative-multi-venue-certification-utility-tostreamline-connectivity/ 20. The Stock Exchange of Hong Kong Limited. // [Электронный ресурс]. – Режим доступаhttp://www.hkex.com.hk/eng/market/partcir/sehk/2012/Documents/CTMO06612E. pdf 21. MyCTC (Certification and Testing Center) от BMFBOVESPA. // [Электронный ресурс]. – Режим доступа http://www.bmfbovespa.com.br/enus/services/download/MyCTC-User-Guide.pdf 22. CME Group. // [Электронный ресурс]. – Режим доступа http://www.cmegroup.com/confluence/display/EPICSANDBOX/Client+System+Certificati on 23. The London Stock Exchange. // [Электронный ресурс]. – Режим доступа http://www.lseg.com/areas-expertise/technology/market-connectivity/customercertification-and-testing-services 24. Zverev A., Bulda A.: Exchange Simulators for SOR/Algo Testing: Advantages vs. Shortcomings. / ExTENT conference. // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/IosifItkin/exchange-simulators-for-sor-algo-testing-advantages-vsshortcomings 25. K. M. Brzezinski: Towards the Methodological Harmonisation of Passive Testing Across ICT Communities // Engineering the Computer Science and IT, October 2009 26. David Lee, Dongluo Chen, Ruibing Hao, Raymond E. Miller, Jianping Wu and Xia Yin: Network Protocol System Monitoring – A Formal Approach With Passive Testing // IEEE/ACM Transactions on Networking, Vol. 14, No. 2, April 2006 27. Ana Cavalli, Stephane Maag, Edgardo Montes de Oca: A passive conformance testing approach for a MANET routing protocol // Proceedings of the 2009 ACM symposium on Applied Computing March 2009, SAC '09 28. James Newsome, David Brumley, Jason Franklin, Dawn Song: Replayer: Automatic Protocol Replay by Binary Analysis // CCS '06: Proceedings of the 13th ACM conference on Computer and communications security, October 2006 29. FIX Protocol. // [Электронный ресурс]. – Режим доступа http://fixprotocol.org Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 213
- 214. 30. Zverev A.,Moskaleva O., Kudryavtseva M., Doronichev D., Bulda A.: Four Houses – Test Tools presentation. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3-exactpro-fourhousestesttools2012-1 31. Zaitseva N., Popovchuk N.: Next Step in Reconciliation Testing. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3exactpro-thenextstepinreconciliationtesting 32. G. Cugola and A. Margara: Processing flows of information: From data stream to complex event processing // ACM Computing Surveys, 2011. 33. QuickFIX/J . // [Электронный ресурс]. – Режим доступа http://quickfixj.org 34. Felix Fuentes, Dulal C. Kar: Ethereal vs. Tcpdump: a comparative study on packet sniffing tools for educational purpose // Journal of Computing Sciences in Colleges , Volume 20 Issue 4, April 2005 35. The Grinder TCP Proxy. // [Электронный ресурс]. – Режим доступа http://grinder.sourceforge.net/g3/tcpproxy.html 36. Investment Services Directive – Markets in Financial Instruments Directive (MiFID) 37. UL Bridge. // [Электронный ресурс]. – Режим доступа http://www.ullink.com/fixsolutions.php 214 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 215. Применение симуляторов рынкаценных бумаг для тестирования систем агрегации и распределения информации о котировках (Ticker Plant) Ольга Буянова1, Алёна Булда1, Алексей Зверев2 ООО «Инновационные Трейдинговые Системы», Россия, 156013, г. Кострома, ул. Ленина, 20 Olga.Buyanova@exactpro.com, Alyona.Bulda@exactpro.com 2 Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA Alexey.Zverev@exactpro.com 1 Aннотация. Системы агрегации и распределения информации о котировках широко применяются в современном трейдинге. Они позволяют собирать в реальном времени котировки с нескольких рынков, представлять данные о них в едином формате и распространять их в электронном виде в зависимости от запросов и целей внешних клиентов, трейдеров. В данной статье рассмотрена возможность применения симуляторов рынка к тестированию таких систем. Проведён анализ основных тестовых сценариев для систем распределения информации о котировках. Выделен набор основных функциональных и нефункциональных сценариев тестирования, необходимых для контроля качества распределения информации о котировках. Произведена сравнительная оценка симуляторов рынка и реальных тестовых площадок. Ключевые слова: система агрегации и распределения информации о котировках (Ticker Plant, Market Data), биржа, тестовая платформа, симулятор рынка, функциональное тестирование, нефункциональное тестирование. 1 Введение Современный электронный трейдинг невозможно представить себе без актуальных сведений о финансовых инструментах, заявках и сделках на них. Высоконагруженные биржевые и брокерские системы предоставляют рыночные данные о торгуемых на них финансовых инструментах через собственные специальные компоненты, называющиеся каналами распространения рыночных данных (или Market Data Feeds). Каждый финансовый инструмент - это значительное количество информации, генерирующейся ежесекундно, поэтому способность распространять весь поток рыночных данных и скорость распространения информации о котировках и финансовых сделках для каждого Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 215
- 216. финансового инструмента являютсяосновными характеристиками для такого рода компонентов высоконагруженных систем. 1.1 Рыночная информация (Market Data) и ее основные представления Обычно рыночная информация включает в себя следующий набор параметров, специфичных для определённого финансового инструмента: краткое название инструмента (ticker symbol), цена последней сделки (last trade price), текущие лучшие цены спроса и предложения (Best Bid Offer), идентификационный номер инструмента (ISIN), биржа, на которой произошла сделка (exсhange code), время последней сделки (Trade Time), цена сделки при закрытии торговой сессии на инструменте (Close Price). В зависимости от сложности высоконагруженных биржевых систем, рыночная информация о котировках может обрабатываться внутренними компонентами электронных бирж и обогащаться дополнительной информацией: например, об общем объёме сделок в течение биржевого дня (Turnover), о средневзвешенной цене по общему объему и количеству сделок (VWAP), а так же более детальной информацией об акции или деривативе – справочные данные, такие как параметры трейдеров, рынка, торговых сессий, инструментов (или Reference Data). Справочные данные (Reference Data или Static Data) представляют собой информацию об инструменте, которая не меняется в режиме реального времени: например, международный идентификационный код ценной бумаги (ISIN), цена сделки при закрытии трейдинговой сессии за предыдущий день (Close Price), валюта, в которой данный финансовый инструмент торгуется на бирже (Currency), параметры так называемых «прерывателей торгов», которые чаще указываются в процентных соотношениях к цене последней сделки (Dynamic or Static Circuit Breaker Tolerances (%)), и так далее[1]. Для предоставления перечисленной выше информации существует ряд стандартных протоколов распространения котировок (например, FIX/FAST [2]), так называемых протоколов распространенния котировок с фиксированной длинной сообщений (например, ITCH [3]), или кодированные протоколы передачи данных (например, HTTPS (HyperText Transfer Protocol Secure) [4] [5]). Многие электронные биржи распространяют информацию о котировках как через стандартные протоколы, так и через специальные. Трейдеры часто не могут позволить себе дорогостоящую разработку программ, которые бы собирали необходимую им для работы информацию о котировках. Таким образом, возникает необходимость создания систем сбора и агрегации рыночных данных с различных бирж и по различным финансовым протоколам передачи данных. 216 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 217. 1.2 Cистема агрегацииинформации (Ticker Plant) и ее основные функции Ticker Plant - это система агрегации информации о котировках с различных электронных торговых площадок (или бирж) и её распределения. Данная система предоставляет рыночные данные трейдерам в нормализованном или унифицированном виде [6]. Зачастую Ticker Plant рассчитывает дополнительные параметры на основе предоставленных рыночных данных, то есть обогащает статистическую информацию об акциях и деривативах. Кроме того, для таких систем характерна способность объединять однородные величины распространяемых котировок: ценовые уровни (Price Levels), предоставление котировок согласно запросам клиентов (например, широко распространены такие сервисы, как Level 1, Level 2, Index, TS, News) в режиме реального времени, а так же хранение переданной рыночной информации. Указанные выше типы сервисов по предоставлению рыночной информации достаточно распространены в электронной торговле финансовыми инструментами. Рассмотрим каждый из них подробнее: • Level1 - информация о последних Bid/Ask, OHLC (Open, High, Low, Close), Volume; • Level2 - информация о Level1 + Order Book (5-10 уровней глубины торговой книжки, Bid/Ask PxQty). Level2 может содержать атрибутированные или анонимные заявки), и использовать модели MBO (Market by Order, т.е. индивидуальное отображение всех заявок в пределах отдельно взятого ценового уровня) и MBP (Market by Price, т.е. агрегированное отображение заявок в пределах отдельно взятого ценового уровня). [7]; • Level2 - Total View - более полная информация по сравнению с Level2; • News - последние новости о компании [8]; • Index - данные об индексах [9]. Схематичное представление системы агрегации и распределения информации о котировках (Ticker Plant) показано на рисунке 1. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 217
- 218. Рис. 1. Схемасистемы Ticker Plant. 2 Основные требования к системе агрегации и распределения информации о котировках (Ticker Plant) Исходя из описания системы агрегации и распределения информации о котировках (Ticker Plant) и основных её характеристик, выделенных выше, мы определяем набор требований, которым такая система должна соответствовать. При тестировании такой системы мы будем обращаться к этому набору характеристик. Для того, чтобы было удобно оценивать каждую характеристику, мы распределили их на функциональные и нефункциональные. Итак, система агрегации и распределения информации о котировках (Ticker Plant) должна решать следующие задачи: • с функциональной точки зрения: 1. собирать рыночную информацию о котировках из нескольких источников (поставщиков рыночной информации: бирж, банков); 2. обрабатывать справочные данные (reference data), предоставляемые биржами; 3. обрабатывать информацию о котировках, предоставляемую по различным протоколам передачи данных, в режиме реального времени; 4. преобразовывать полученную информацию в один формат; 5. агрегировать данные о котировках согласно различным методам, описанным выше; 218 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 219. 6. обрабатывать этиданные с целью расширить функциональность системы: например, предоставлять статистику (VWAP, Turnover, Trade High/Low, 52 week Trade High/Low); 7. предоставлять данные согласно запросам клиентов: Level1, Level2, TS, News, Index, Option chains и другое; 8. предоставлять записанную историческую информацию о котировках. • с нефункциональной точки зрения: 1. быструю обработку потоков информации о котировках, поступающей в режиме реального времени от электронных бирж; 2. быструю обработку запросов, поступающих от клиентов и предоставление данных о котировках в зависимости от вида запроса клиента (например, отдельно на торгуемый инструмент, или на группу инструментов, или на весь рынок); 3. бесперебойную работоспособность системы; 4. управляемость системой (operability); 5. возможность мониторинга систем (наличие приложений, с помощью которых можно наблюдать за системой или упралять её компонентами); 6. пропускную способность (throughput); 7. временную задержку (latency); 8. отказоустойчивость (fault tolerance). Определив набор функциональных и нефункциональных характеристик системы агрегации и распределения информации о котировках (Ticker Plant), нам необходимо понять, как будет проходить процесс тестирования отдельно взятой характеристики. Очевидными становятся два пути тестирования такого рода систем. Первый - это тестирование с реальными тестовыми площадками (CDS customer development service [10]). Обычно биржи предоставляют своим клиентам тестовые окружения (test environments), аналогичные реальной электронной трейдинговой платформе. Чаще всего это делается с целью пройти сертификационный процесс или предоставить клиентам возможность для отладки своего клиентского программного обеспечения. И второй - это тестирование с помощью симуляторов трейдинговых платформ, разработанных на основе данных о бирже, находящихся в публичном доступе. 3 «Тестовая» биржа: описание и основные возможности “Тестовая” биржа - это своего рода полная копия реальной трейдинговой биржи [11]. Такой аналог трейдинговой биржи должен наиболее полно представлять реальную электронную платформу. Тестовые биржи Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 219
- 220. предоставляются клиентам, которымнеобходимо отладить разработанное ими трейдинговое и информационное программное обеспечение [12]. Заявки и сделки в таких тестовых биржах генерируются как следствие взаимодействия самих клиентов, тестирующих собственное программное обеспечение, друг с другом. В идеале тестовая биржа состоит из тех же компонентов и частей, что и реальная биржевая система[13]. Торговые сессии, основные параметры торгуемых инструментов, правила трейдинга, графические приложения для управления настройками справочных данных (reference data) и т.д - все эти характеристики полностью аналогичны компонентам реальной системы. Поэтому такое тестовое окружение (test environment) позволяет проверять программное обеспечение, заведомо ориентируясь на аналогичные настройки в реальной системе. Ниже приведена схема тестирования Ticker Plant с применением тестовой биржи. Рис.2 Тестирование Ticker Plant с помощью тестовой биржи 220 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 221. 4 Симулятор рынкаценных бумаг: описание и основные возможности Симулятор рынка ценных бумаг (или биржевой симулятор) - это интерактивная программа, разработанная для имитации возможностей и свойств реальных моделей рынка[14]. Симулятор рынка должен уметь эмулировать реальные действия, происходящие на бирже: сам трейдинг (размещение заявок, генерацию сделок, изменения статусов инструментов и т.д), симуляцию мониторинга за ходом торгов на рынке и внесение изменений (market operations: отмена/изменение заявок и сделок, остановка торгов, и т.д.), режим работы рынка (переход рынка из одного статуса в другой - открытие рынка (Market Open), аукционы (Opening/Closing/ Periodic Auction Calls), вычисления цен аукционов и публикация цены закрытия, закрытие рынка и т.д. Биржевой симулятор рынка содержит API, аналогичный реальной бирже, с элементами контроля отсылаемых ответов клиенту[15]. Такие симуляторы рынков позволяют иметь более полный контроль над генерируемыми событиями для системы агрегации и распределения информации о котировках (Ticker Plant)[16], таким образом увеличивая покрытие тестирования системы. С помощью симуляторов можно создать необходимую нагрузку, сравнимую с потоками данных, свойственным реальным высоконагруженным биржевым и брокерским системам. Далее представлена схема верификации системы Ticker Plant при помощи симулятора. Рис.3 Схема тестирования Ticker Plant с применением симулятора Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 221
- 222. 5 Составление библиотекисценариев и тестов для верификации корректности работы системы агрегации и распределения информации о котировках (Ticker Plant) 5 Составление библиотеки сценариев и Исходя из основных требований к системе Ticker Plant, мытестов для разработали верификации корректности работы системы агрегации и библиотеку сценариев тестирования, которыми можно проверить распределения такой системы. В таблице (Ticker Plant) работоспособность информации о котировках 1 приведены области тестирования системы Ticker Plant и дано их краткое описание. Таблица также Исходя из основных шкалу областей тестирования по приоритетам. показывает оценочную требований к системе Ticker Plant, мы разработали библиотеку которыми Например, еслисценариев той или иной области указан можно напротив тестирования, приоритетпроверить 1, это работоспособность такой системы. В этой области тестируемая система таблице 1 приведены области означает, что при возникновении ошибок в тестирования системы Ticker Plant и дано их краткое описание. Таблица также Ticker Plant не сможет полноценно выполнять свою основную задачу. показывает оценочную шкалу областей в этой области, система может Приоритет 3 означает, что при наличии ошибоктестирования по приоритетам. Например, если напротив той или иной области указан приоритет 1, это выполнять свою основную задачу, но с некоторыми отклонениями. означает, что при возникновении ошибок в этой области тестируемая система Табл. Области тестирования Ticker свою Ticker Plant не сможет1. полноценно выполнять Plant. основную задачу. Приоритет 3 означает, что при наличии ошибок в этой области, система может выполнять свою основную задачу, но с некоторыми отклонениями. Описание Приоритет № Область тестирования (1 - 3) Табл. 1. Области тестирования Ticker Plant. - возможности подключения к основным 1 1 Техническое каналам (primary channel); подключение к Область тестирования - подключение к запасным каналам Описание Приоритет № биржам - поток данных о котировках и (secondary channels); (1 - 3) - отказоустойчивость (fault tolerance); сделках в режиме - тестирование аварийного 1 реального времени Техническое - возможности подключения к основным 1 восстановления данных (disaster (streaming quotes - real подключение к каналам (primary channel); recovery) time) биржам - поток - подключение к запасным каналам данных(User UDP о котировках и (secondary channels); Datagram Protocol) сделках в режиме - отказоустойчивость (fault tolerance); реального времени TCP/IP - тестирование аварийного (Transmission Control (streaming quotes - real восстановления данных (disaster Protocol (TCP) и time) recovery) Internet Protocol (IP) UDP (User Datagram Protocol) HTTPS (HyperText Transfer Protocol TCP/IP Secure) (Transmission Control Protocol (TCP) и Internet Protocol (IP) HTTPS (HyperText Transfer Protocol Secure) 222 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 223. № Область тестирования Описание Приоритет (1 -3) 2 Техническое подключение к биржам - каналы восстановления данных (Replay/Recovery channels) - возможности подключения к основным каналам (primary channel); - подключение к запасным каналам (secondary channels); - отказоустойчивость (fault tolerance); - тестирование аварийного восстановления данных (disaster recovery) 1 3 Тестирование интерфейса протокола от биржи к системе Ticker Plant (real time + replay/recovery) - проверка административных сообщений, инициируемых Ticker Plant (Administrative messages: Login Request, Replay Request, Snapshot Request, Logout Request); - проверка административных сообщений, инициируемых каналом (Administrative messages): Heartbeat, Login Response, Replay Response, Snapshot Response, Snapshot Complete); - проверка сообщений приложения (Application messages: Time, System Event, Symbol Directory, Symbol Status, Add Order, Add Attributed Order, Order Deleted, Order Modified, Order Book Clear, Order Executed, Order Executed with Price/Size, Trade, Auction Trade, OffBook Trade, Trade Break, Auction Info, Statistics); - проверка обязательных полей (mandatory tags/values) и значений; - проверка необязательный полей и значений (optional tags/values); - проверка всевозможных вариантов и сочетаний значений тагов (Order Type, TIF и т.д); - проверка негативных значений (неподдерживаемые значения, отрицательные значения, специальные символы, и т.д) 1 4 Восстановление потери небольшого количества данных (Replay channel) - возможности подключения к основному каналам (primary channel); - подключение к запасным каналу (secondary channels); - проверка последовательности полученных данных; 1 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 223
- 224. № Область тестирования Описание - проверкаполученных данных на правильность; - проверка объёма буферизации данных Приоритет (1 - 3) 5 - возможности подключения к основному каналу (primary channel); - подключение к запасным каналам (secondary channels); - проверка последовательности полученных данных; - проверка полученных данных на правильность; - проверка объёма переданных данных 1 6 Проверка справочных данных (Reference Data) - возможность загрузить данные о финансовых инструментах, предоставляемых биржей; - правильность обработки данных; - использование справочных данных для подсчета различных показателей 1 7 Тестирование поведения системы Ticker Plant при отказе компонентов биржи (Failover при потоке данных с биржи) - восстановление данных после отказа основного и/или запасного каналов; - возможность переподключения; - правильная последовательность сообщений; - возможность дальнейшей обработки данных после восстановления 1 8 Тестирование при отказе компонентов системы Ticker Plant (Failover при потоке данных из системы Ticker Plant) - проверка работоспособности компонентов системы Ticker Plant при отказе основного/запасного каналов; - правильная последовательность сообщений; - возможность дальнейшей обработки данных после восстановления 2 9 224 Восстановление потери большого количества данных (Recovery channel) Тестирование полного трейдингового дня (цикла) работы системы Ticker Plant (DLC – Daily Life Cycle) - проверка правильной последовательности старта компонентов системы Ticker Plant; - проверка правильной последовательности выключения компонентов системы Ticker Plant 1 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 225. № Область тестирования Описание Приоритет (1 -3) 10 Тестирование полного трейдингового дня (цикла) на бирже (DLC – Daily Life Cycle) - правильность последовательности приходящих сообщений в течение дня; - добавление нового инструмента, изменение его параметров, удаление; - изменение статусов инструментов; - переход заявок из одной трейдинговой фазы в другую; - переход заявок из одного дня в другой 1 11 Проверка всевозможных торговых статусов рынка - проверка на присутствие данных видов статусов внутри системы Ticker Plant: например, Halt, Opening auction call, Premandatory quote period, Continuous trading, End trade reporting, Closing auction call; - проверка обрабатывания переходов из одного статуса инструментов в другое; - проверка правильности обработки сообщений при массовой смене статусов на финансовых инструментах 1 12 Измерение ширины потребляемого канала передачи данных по сети (Bandwidth) - проводятся нагрузочные тесты для измерения объёма передаваемых данных в единицу времени 1 13 Измерение пропускной способности каналов в единицу времени (Throughput) - проводятся нагрузочные тесты для подсчёта среднего количества гарантировано доставленных сообщений через каналы передачи данных 1 14 Измерение задержек (латентности (Latency) системы) - проверка компонентов системы на задержу передачи данных во времени 1 15 Проверка нагрузочной способности системы (Capacity) - нагрузка входным потоком данных - проверка на работоспособность системы Ticker Plant при большом входном потоке данных 2 16 Проверка нагрузочной способности системы (Capacity) - нагрузка - проверка на обработку системой Ticker Plant большого количества запросов 2 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 225
- 226. № Область тестирования Описание с клиентскойстороны системы Ticker Plant Приоритет (1 - 3) 17 - попытки подключения клиента (CompID) с недостаточным кличеством прав; - попытки подключения с несуществующим пользователем; - проверки максимального количества подключений; - проверки максимального количества запросов 1 18 Проверка правильности обработки системой Ticker Plant некорректных сообщений от биржи - отклик на несуществующие сообщения (messages types); - неправильное количество тагов; - неправильный порядок тагов; - неправильная контрольная сумма (checksum) 2 19 Проверка корректности работы системы в целом - от трейдингового клиента до системы Ticker Plant (E2E тестирование) - добавление заявок; - изменение заявок; - удаление заявок; - добавление агрессивных заявок (приводящих к сделке) 1 20 Сложные сценарии на функциональность самой биржи - проверка на то, как система обрабатывает очередность событий (например, многоуровневые сделки с айсберг заявками); - вычисления цены аукциона; - поведение Stop /Stop Limit ордеров в зависимости от фазы трейдингого дня; - проверка поведения GTC ордеров в течение нескольких дней 2 21 226 Проверка системы Ticker Plant при неправильных запросах клиентов и ответная реакция на них для Replay/Recovery каналов Реконсиляционное тестирование - проверка при сравнении потоков, идущих к системе и от системы (детальная проверка на то, что каждое событие, поступившее на вход системы, обработалось и отобразилось на выходном потоке) 1 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 227. № Область тестирования Описание Приоритет (1 -3) 22 Тестирование MBO (market by order) и MBP (market by price) сервисов - функциональна проверка сервисов, предоставляемых системой Ticker Plant 1 23 Проверки расчёта индексов - проверка правильности расчетов индексов в зависимости от потока сделок 2 24 Правильность расчёта статистических данных - проверка расчёта VWAP, Turnover, Trade High Low, 52 week Trade High Low и т.д. 2 25 Работа с историческими данными - сбор исторических данных; - сортировка в зависимости от типа данных; - выдача результатов согласно запросам клиентов; - возможность проигрывать записанные исторические данные 2 26 Проверка получения и передачи новостных каналов от бирж - тестирование новостей (News); - тестирование оповещений клиентов (Announcements) 3 27 Проверка действия биржевого оператора - отмена сделок; - изменение параметров сделки 2 28 Проверка сложных запросов клиента - выдача данных для деривативного инструмента (опционные цепочки option chains) на запрашиваемый базовый инструмент 2 29 Мониторинг системы - проверка приложений, с помощью которых можно наблюдать за системой или управлять её компонентами 1 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 227
- 228. 6 Методика анализапокрытия тестирования системы агрегации и распределения информации о котировках (Ticker Plant) при помощи инструментов для тестирования Для того, чтобы оценить и проанализировать, насколько полно инструметы тестирования покрывают области функциональности системы Ticker Plant, которую необходимо протестировать, нами была разработана специальная методика. Она основывается на переборе сценариев в процентном отношении к всевозможным сценариям, относящимся к той или иной области. Основываясь на опыте тестирования, полученном в компании Exactpro Systems [17], была определена приоритетность областей системы Ticker Plant, обозначенной в правой колонке таблицы 1. Следующий раздел рассказывает об опыте применения данной методики покрытия тестами для оценки полноты тестирования системы Ticker Plant, как с помощью реальных тестовых площадок, так и с помощью биржевых симуляторов. 6.1 Сравнительная характеристика оценочных данных при тестировании системы агрегации и распределения информации о котировках Ticker Plant с помощью реальной тестовой биржи и симулятора В таблице 2 приведены сравнительные характеристики, включающие в себя оценочные данные, полученные в ходе тестирования системы Ticker Plant с помощью реальной тестовой биржи и симулятора, а так же детальное объяснение полученных данных. Табл. 2. Сравнительные характеристики данных для тестовой биржи и симулятора. № 1 228 Область тестирования Техническое подключение к биржам - поток данных о котировках и торгах в режиме реального времени Покрытие функциональности при тестировании с помощью реальной тестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 100 40 Детализация оценочных данных При данной оценке мы исходим из того что симулятор биржи, по своему определению, не способен полноценно воспроизвести все технические детали Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 229. № Область тестирования (streaming quotes realtime) UDP (User Datagram Protocol); TCP/IP (Transmission Control Protocol (TCP) и Internet Protocol (IP); HTTPS (Hypertext Transfer Protocol Secure) Покрытие функциональности при тестировании с помощью реальной тестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) Детализация оценочных данных соединения с биржей. Мы оцениваем, что если есть стандартная спецификация, то эмулировать шлюз можно примерно на 40%, исходя из набора тестовых сценариев на соединение с биржей 2 Техническое подключение к биржам - каналы восстановления данных (Replay/Recovery channels) 100 40 3 Тестирование интерфейса протокола от биржи к системе Ticker Plant (real time + replay/recovery) 100 100 При данной оценке мы исходим из того, что симулятор не может воспроизвести всех технических деталей соединения с биржей. Мы оцениваем, что если есть стандартная спецификация, то эмулировать шлюз можно примерно с 40% -м покрытием сценариев. Данная функциональность (тестирование внешнего шлюза) изолирована от биржи, поэтому мы считаем, что использование симулятора и тестовой биржи обеспечивают одинаковое покрытие набора тестовых сценариев. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 229
- 230. № Область тестирования Покрытие функциональности при тестировании с помощью реальнойтестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 4 100 100 5 230 Восстановление потери небольшого количества данных (Replay channel) Восстановление потери большого количества данных (Recovery channel) 75 100 Детализация оценочных данных Данная функциональность (тестирование внешнего шлюза) изолирована от биржи, поэтому мы считаем, что использование симулятора и тестовой биржи обеспечивают одинаковое покрытие набора тестовых сценариев. Несмотря на то, что данная функциональность изолирована от биржи, ee проверка требует значительного потока кортировок с биржи. Исходя из нашего опыта, такое возможно не всегда с тестовой биржей, и есть ряд значительных ограничений. Поток данных с тестовых плошадок обычно соответствует ожиданиям, однако его практически невозможно контролировать, чего не скажешь о симуляторе, контроль над которым находится в руках Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 231. № Область тестирования Покрытие функциональности при тестировании с помощью реальнойтестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 6 Проверка справочных данных (Reference Data) 100 5 7 Тестирование поведения системы Ticker Plant при отказе компонентов биржи (Failover при потоке данных с биржи) 100 10 8 Тестирование при отказе компонентов системы Ticker Plant (Failover при потоке данных из системы Ticker 100 40 Детализация оценочных данных тестировщиков. Данное тестирование сосредоточено на верификации настроек системы, настроек финансовых инструментов и т.д. Необходимо тестировать в связке с реальными рынками. Тестирование с симулятором в данном случае возможно, но значительная часть тестов проверяет соединение между Ticker Plant и биржами. При данной оценке мы исходим из того, что симулятор не может воспроизвести всех технических деталей соединения с биржей. При наличии стандартной спецификации, эмулирование шлюза возможно с 40% -м покрытием сценариев. Возможно тестирование с симулятором, но значительная часть тестов верифицирует соединение между Ticker Plant и рынками. При Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 231
- 232. № Область тестирования Plant) Покрытие функциональности при тестировании с помощью реальнойтестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 9 40 100 10 232 Тестирование полного трейдингового дня (цикла) работы системы Ticker Plant (DLC – Daily Life Cycle) Тестирование полного трейдингового дня (цикла) на бирже (DLC – Daily Life Cycle) 100 40 Детализация оценочных данных данной оценке мы исходим из того, что симулятор априори не может воспроизвести всех технических деталей соединения с биржей. Мы оцениваем, что если есть стандартная спецификация, то эмулировать шлюз можно примерно с 40% -м покрытием. Всвязи с большими ограничениями в управлении торговым днем на тестовых площадках, симулятор предоставляет больше возможностей при воспроизведении подобных сценариев тестирования. Не смотря на то, что предыдущее обоснование применимо и в данном случае, в даном сценарии больший вес имеет понятие того, что входящие сообщения создаются при помощи тестового рынка, согласно настройкам справочных данных (Reference Data) самой биржи. При данной оценке мы Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 233. № Область тестирования Покрытие функциональности при тестировании с помощью реальнойтестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 11 Проверка всевозможных торговых статусов рынка 50 100 12 Измерение ширины потребляемого канала передачи данных по сети (Bandwidth) 75 100 13 Измерение пропускной способности каналов в единицу времени 75 100 Детализация оценочных данных исходим из того, что симулятор априори не может воспроизвести всех технических деталей соединения с полного трейдингового дня (цикла) работы системы (DLC). Поэтому оценка покрытия составляет лишь 40%. В связи с ограничениями в управлении торговым днем на тестовых площадках, симулятор предоставляет больше возможностей при воспроизведении подобных сценариев. Тестирование с симулятором возможно; для тестовых площадок имеется значительная зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет преимущество. Тестирование с симулятором возможно; для тестовых площадок имеется значительная Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 233
- 234. № Область тестирования (Throughput) Покрытие функциональности при тестировании с помощью реальнойтестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 14 75 100 15 Проверка нагрузочной способности системы (Capacity) нагрузка входным потоком данных 75 100 16 234 Измерение задержек (латентности (Latency) системы) Проверка нагрузочной способности системы (Capacity) нагрузка с клиентской стороны системы Ticker Plant 75 100 Детализация оценочных данных зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет преимущество. Тестирование с симулятором возможно; для тестовых площадок имеется значительная зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет преимущество. Тестирование с симулятором возможно; для тестовых площадок имеется значительная зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет преимущество. Тестирование с симулятором возможно; для тестовых площадок имеется значительная зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 235. № Область тестирования Покрытие функциональности при тестировании с помощью реальнойтестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 17 Проверка системы Ticker Plant при неправильных запросах клиентов и ответная реакция на них для Replay/Recovery каналов 100 100 18 Проверка правильности обработки системой Ticker Plant некорректных сообщений от биржи 25 100 19 Проверка корректности работы системы в целом - от трейдингового клиента до системы Ticker Plant (E2E тестирование) 90 85 Детализация оценочных данных преимущество. Данная функциональность (тестирование внешнего шлюза) изолирована от биржи, поэтому мы считаем, что использование симулятора и тестовой биржи обеспечивают одинаковое покрытие. В данном случае симулятор может отправлять на вход Ticker Plant достаточно гибкий набор негативных сценариев тестирования, что обеспечивает большее покрытие. Однако, с другой стороны, абсолютное число сценариев, с технической точки зрения, имея при этом только спецификацию биржи, невозможно воспроизвести. Данное тестирование представляет собой набор всех трейдинговых сценариев тестирования. Это можно обеспечить как симулятором, так и тестовой площадкой. Поэтому Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 235
- 236. № Область тестирования Покрытие функциональности при тестировании с помощью реальнойтестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) оценочная характеристика примерно одинаковая. 20 Сложные сценарии на функциональность самой биржи 50 100 21 Реконсиляционное тестирование 100 50 22 236 Детализация оценочных данных Тестирование MBO (market by order) и MBP (market by price) сервисов 100 100 Оба подхода предостовляют равные возможности при эмуляции сложных сценариев. Поскольку симулятор подконтролен тестировщикам, он дает больше возможностей при эмуляции по настоящему нетривиальных событий. В данном тесте происходит сравнение потока данных из биржи и из Ticker Plant. Тестирование с реальной тестовой площадкой предпочтитетельнее и является более правильным, поскольку она по умолчанию является независимым источником котировок. Данная функциональность (тестирование внешнего шлюза) изолирована от биржи, поэтому мы считаем, что использование Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 237. № Область тестирования Покрытие функциональности при тестировании с помощью реальнойтестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 23 Проверки расчета индексов 50 100 24 Правильность расчёта статистических данных 50 100 25 Работа с историческими данными 50 100 26 Проверка получения и передачи новостных каналов от бирж 50 100 Детализация оценочных данных симулятора и тестовой биржи обеспечивают одинаковое покрытие. Данная функциональность должна проверятся при полном контроле над рынком. Симулятор имеет явное приемущество, с чем и связана такая оценка покрытия. Данная функциональность должна проверятся при полном контроле над рынком. Симулятор имеет явное приемущество, с чем и связана такая оценка покрытия. Необходима эмуляция искуственных исторических событий. Для повторяемости тестов необходим симулятор, а не тестовая площадка, на события в которой также могут влиять и другие её пользователи. В этом тесте необходима эмуляция искуственных новостей. Для повторяемости тестов и полного Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 237
- 238. № Область тестирования Покрытие функциональности при тестировании с помощью реальнойтестовой биржей (%) Покрытие функциональности при тестировании с помощью симулятора (%) 27 Проверка действия биржевого оператора 100 30 28 Проверка сложных запросов клиента 100 100 29 Мониторинг системы 100 30 Детализация оценочных данных контроля необходим симулятор. Системы для управления рынками должны проверяться в связке с реальными системами, на которых будет впоследствии работать система. Приемущество у тестовой площадки. Данная функциональность (тестирование внешнего шлюза) изолирована от биржи, поэтому мы считаем, что использование симулятора и тестовой биржи обеспечивают одинаковое покрытие. Системы для управления рынками должны проверяться в связке с реальными системами, с которыми будет впоследствии работать система. Преимущество у тестовой площадки. Может сложится ощущение, что полное покрытие тестирования системы Ticker Plant возможно исключительно с использованием симуляторов (как видно из таблицы 2). Однако в реальности это не так. Основное препятствие состоит в том, что эмулировать торговую площадку со 100%-й точностью - невозможно. В особенности это касается непосредственного взаимодействия между Ticker 238 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 239. Plant системой иразличными рынками. Причина этого в том, что любая спецификация о протоколе соединения с биржей содержит ограниченное описание поведения при различных ситуациях, поэтому даже если симулятор воспроизведет 100% спецификации с точностью до нюансов, всё равно останутся элементы, сделанные «на усмотрение» создателей симулятора. Для наглядности приведем пример. Предположим, на бирже происходит сделка, и биржа рассылает клиентам два события: первое событие содержит обьем и цену сделки; второе событие содержит изменение HIGH, LOW параметров цены на данном финансовом инструменте. Если какой-либо алгоритм при расчете индекса использует и первое, и второе события, то вполне вероятно, что для дальнейшей работы такого алгоритма будет важно, в каком порядке описанные выше события приходят. Маловероятно, что спецификация торговой площадки будет содержать требования к порядку сообщений и событий. Более того, - раз этого требования нет в спецификации, биржа может легко поменять этот порядок. Таким образом, у нас есть пример сценария, который невозможно симулировать точно. Всвязи с этим, существенный обьем тестирования должен осуществляться на тестовой площадке, которая наиболее близко соответствует поведению реального рынка. Данное заключение так же дано, опираясь на опыт в тестировании Ticker Plant систем. Более наглядно сравнительный анализ покрытия тестами при помощи различных инструментов тестирования выглядит на рисунке 4. Рис. 4. Сравнительный анализ покрытия тестами при помощи тестовой биржи и симулятора Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 239
- 240. Анализ данных, приведенныхв таблице 2 и на рисунке 4, показывает, что тестирование с помощью симуляторов и реальных тестовых бирж (в разумный временной период) имеет свои плюсы и минусы. В целом, мы имеем приблизительно одинаковые показатели по оценочной методике. Общая формула покрытия всех функциональностей соответствующим инструментом тестирования: Summ(CovN*(1/PriorN))/Summ(1/PriorN) . (1) где Summ - сумма (Табл. 2), CovN* - относительное покрытие данной функциональности соответствующим инструментом тестирования (Табл. 2), PriorN - приоритет данной функциональности (Табл. 1). Итоговый результат: тестирование при помощи симуляторов обеспечивает 76% покрытия; тестирование при помощи тестовой площадки - 83%. 7 Заключение В данной статье приводится описание системы агрегации и распределения информации о котировках (Ticker Plant), перечислены его основные характеристики, составлена справочная библиотека скриптов для тестирования, максимально покрывающих функциональность обобщенной системы Ticker Plant. Также в статье даны определения биржевого симулятора и реальной тестовой биржи. При помощи разработанной методики оценки покрытия сценариями для тестирования системы агрегации и распределения информации о котировках (Ticker Plant) были проанализированы и обработаны два возможных пути тестирования: при помощи реальной тестовой биржи и симуляторов бирж. На основе двух сводных таблиц было выведено заключение о преимуществах тестирования как с реальной тестовой биржей, так и с биржевым симулятором. Литература 1. 2. 3. 240 Официальный сайт B2Bits epam. // [Электронный ресурс]. – Режим доступа http://www.b2bits.com/trading_solutions/market-data-solutions.html Официальный сайт FIXprotocol. // [Электронный ресурс]. – Режим доступа http://www.fixprotocol.org/ Документация о Level1 Market Data / Официальный сайт Лондонской Фондовой Биржи – London Stock Exchange // [Электронный ресурс]. – Режим доступа Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 241. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. http://www.londonstockexchange.com/products-and-services/millenniumexchange/millennium-exchange-migration/mit303.pdf P. Karlton, P.Kocher.: The Secure Sockets Layer (SSL) Protocol Version 3.0 // [Электронный ресурс]. – Режим доступа http://tools.ietf.org/html/rfc6101 Официальный сайт FTSE. // [Электронный ресурс]. – Режим доступа http://www.ftse.com/Indices/Data_Licenses/Real-time_Constituent_Data.jsp Официальный сайт B2Bits epam. // [Электронный ресурс]. – Режим доступа http://www.b2bits.com/trading_solutions/market-data-solutions.html Building the Book: A Full-Hardware Nasdaq Itch Ticker Plant on Solarflare’s AoE FPGA Board / Sherman,M., Sood,P., Wong,K., Iakovlev,A., Parashar,N. // [Электронный ресурс]. – Режим доступа http://www.cs.columbia.edu/~sedwards/classes/2013/4840/reports/Itch.pdf Официальный сайт Tokyo Stock Exchange // [Электронный ресурс]. – Режим доступа http://www.tse.or.jp/english/market/mkinfo/mains.html Day Trading. / Официальный сайт About.com // [Электронный ресурс]. – Режим доступа http://daytrading.about.com/od/daytradingmarketdata/a/MarketDataDefin.htm Customer Development Service (CDS). / Официальный сайт Лондонской Фондовой Биржи – London Stock Exchange // [Электронный ресурс]. – Режим доступа http://www.londonstockexchange.com/products-and-services/technicallibrary/customer/customerdevelopmentservice/customerdevelopmentservice.htm Trading Floor Architecture / Официальный сайт Cisco // [Электронный ресурс]. – Режим доступа http://www.cisco.com/en/US/docs/solutions/Verticals/Trading_Floor_ArchitectureE.html Официальный сайт BSE India // [Электронный ресурс]. – Режим доступа http://www.bseindia.com/markets/MarketInfo/DispNoticesNCirculars.aspx?page=20 12053122pagecont=0,31/05/2012,31/05/2012,,All,All,All,Scrip%20Name%20/%20Code Официальный сайт ММВБ // [Электронный ресурс]. – Режим доступа http://rts.micex.ru/s437 Статья К.В.Воронцов (ВЦ РАН), С.Б. Пшеничников (ММВБ): Имитационное моделирование торгов: новая технология биржевых тренажеров. / Журнал «Индикатор», №2 (42). М. 2002 год // [Электронный ресурс]. – Режим доступа http://www.forecsys.com/site/about/press/exchange_simulator/ Официальный сайт Oslo Bors Stock Exchange. // [Электронный ресурс]. – Режим доступа http://www.oslobors.no/ob_eng/Oslo-Boers/Trading/Delta/MillenniumExchange/Guide-to-Testing-Services-updated-issue Zverev,A., Bulda,A.: Exchange Simulators for SOR. Algo Testing: Advantages vs. Shortcomings. / Конференция ExTENT // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/exchsimsforsoralgotestingadvantagesvsshortcomings29102011111113011104phpapp02 Официальный сайт Exactpro Systems. // [Электронный ресурс]. – Режим доступа http://www.exactprosystems.com/ Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 241
- 242. Высокопроизводительный генератор нагрузкидля тестирования систем автоматизированной торговли Дмитрий Гурьев1, Мария Гай1, Иосиф Иткин2, Александр Терентьев3 1 ООО «Инновационные Трейдинговые Системы», Россия, 115088, г. Москва, 2-й Южнопортовый проезд, 20А/4 Dmitry.Guriev@exactpro.com, Maria.Gai@exactpro.com 2 Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA Iosif.Itkin@exactpro.com 3 Саратовский государственный технический университет имени Гагарина Ю.А., Россия, 410054, Саратов, ул. Политехническая, 77 a_a_terentyev@mail.ru Aннотация. В связи с существенным ростом числа торговых заявок, вызванным развитием высокочастотной торговли, ставится задача тестирования биржевых и брокерских систем в режимах, приближенных к реальным. Для обеспечения качества высоконагруженных трейдинговых систем высокой доступности применяются специализированные инструменты тестирования. Основные требования к таким инструментам это способность создавать высокие реалистичные нагрузки, используя ограниченную аппаратную базу. В данной статье описывается разработанный генератор нагрузки для тестирования систем автоматизированной торговли. Представлен подход, обеспечивающий высокую производительность. Ключевые слова: нагрузочное тестирование, высокочастотная торговля (HFT), инструменты для тестирования. 1 Введение Высокочастотная электронная торговля финансовыми инструментами (HFT), позволяющая минимизировать временные задержки при совершении сделок, выросла в последние годы и составляет в настоящее время около 30% от всего объёма торговли акциями в Великобритании и, возможно, более 60% от всего объёма торговли акциями в США [1]. В результате этого брокерские и биржевые системы испытывают всё большую нагрузку от потока транзакций, генерируемого системами автоматизированной торговли. Операторы трейдинговых платформ, регулирующие органы и участники торгов должны быть уверены в надёжности программного обеспечения и инфраструктуры торговых площадок [2] в условиях постоянно растущих нагрузок. В ходе разработки программного обеспечения для выявления максимальной пропускной способности, возможных узких мест и определения проблемных 242 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 243. элементов системы применяютметоды нагрузочного тестирования. Под нагрузочным тестированием понимается процесс отправки системе большого количества запросов, проверка своевременности и корректности полученных от неё откликов, а также проверка внутреннего состояния системы. В настоящее время для нагрузочного тестирования программного обеспечения широко используются различные коммерческие и свободно распространяемые генераторы нагрузки. В качестве примера можно привести следующие продукты: Apache JMeter, HP Load Runner, IBM Rational Performance Tester, Borland Silk Performer и другие [3-6]. Основной концепцией, используемой в этих продуктах, является создание множества виртуальных пользователей, эмулирующих поведение реальных пользователей для моделирования условий, при которых программа/система будет функционировать в реальности. При имитации и поддержке соединения с большим количеством пользователей и высокой нагрузке у инструментов тестирования могут возникать ограничения производительности, разобранные во второй части данной статьи. В компании Exactpro Systems LLC разработан инструмент для тестирования высоконагруженных трейдинговых систем, обладающий необходимой производительностью и использованный на практике при проверке некоторых из крупнейших биржевых технологических инфраструктур в Западной Европе [7; 8]. Разработанный инструмент поддерживает протоколы: FIX (все версии), ITCH, LSE Native, SOLA SAIL HSVF, HTTP, SOAP, а также различные бинарные протоколы трейдинговых систем. Многопротокольность является одной из архитектурных особенностей разработанного инструмента для тестирования, вследствие чего добавление новых протоколов и новых версий уже поддерживаемых протоколов представляет собой относительно малозатратную задачу. В третьей части статьи рассмотрены особенности подготовки данных для нагрузочного тестирования. В четвёртой части представлены возможности по настройке инструмента, включая задание профиля нагрузки. 2 Оптимизация процесса создания нагрузки Общее представление о процессе создания нагрузки даётся в ряде работ, в частности в [9]. Генераторы нагрузки делят на основанные на измерениях (measurement-based) и основанные на моделях (model-based) [10]. Основанные на измерениях генераторы удобны для нахождения пропускной способности тестируемой системы и построения зависимостей времён отклика от нагрузки. Генераторы нагрузки, основанные на моделях, направлены на симуляцию распределения входных данных, максимально приближенную к реальному промышленному использованию системы. В разработанном авторами высокопроизводительном генераторе нагрузки поддерживаются оба описанных варианта. Данные модели используются при создании конфигурационных файлов перед запуском генератора. Таким образом, инструмент может не Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 243
- 244. тратить ресурсы наобработку информации, относящейся к модели непосредственно во время выполнения тестов. Генераторы нагрузки подразделяются на работающие по принципам закрытого цикла (closed-cycle) и открытого цикла (open-cycle) [11]. После посылки сообщения исполняемый поток в генераторе закрытого типа дожидается ответа от системы, прежде чем приступить к посылке следующих запросов. Генератор открытого цикла продолжает посылку сообщений не дожидаясь ответа от тестируемой системы. Большинство инструментов для тестирования веб-приложений являются генераторами закрытого цикла. Это связано с использованием концепции виртуальных пользователей, каждый из которых последовательно выполняет шаги определённого сценария. Генератор закрытого цикла требует существенно большего количества потоков исполнения и переключений между ними в сравнении с генератором открытого цикла. В генераторах закрытого цикла часто обработка исходящих из системы ответов происходит в том же потоке, что и посылка входящих сообщений, дополнительно снижая производительность инструмента и иногда даже влияя на его аккуратность. Таким образом, генераторы открытого цикла требуют меньшей аппаратной базы для создания требуемого уровня нагрузки. Они также не требуют порождения лишних потоков и их синронизации для производства фиксированного уровня нагрузки. Представленный в статье инструмент работает как генератор открытого цикла. При разработке инструмента для нагрузочного тестирования рассматривался вопрос о необходимости привязки исполняемых потоков к ядрам процессора для сглаживания распределения входящих в систему сообщений по времени [12]. Авторы пришли к выводу, что миллисекундное разрешение системных таймеров, присутствующее в большинстве современных Linux-системах, достаточно для создания реалистичной трейдинговой нагрузки, а отсутствие привязки к ядрам процессора освобождает некоторое дополнительное количество аппаратных ресурсов на генераторе нагрузки, позволяя централизованно запускать оптимальное количество потоков. Разработанный инструмент использует центральный контроллер, позволяя заранее задать в конфигурации количество и состав протокольных соединений, которые будут работать в каждом потоке. Наличие центрального контроллера также позволяет выдавать команду на выполнение скоординированных действий всеми потоками. Например, одновременный старт потока сообщений или одновременное отключение установленных соединений. При тестировании трейдинговой системы генератор нагрузки заменяет большое количество систем автоматизированной торговли, использующих множество серверов. Однако аппаратная база, доступная для размещения инструментов тестирования, всегда ограничена соображениями экономии [13]. В условиях продолжающейся финансовой нестабильности даже крупнейшие финансовые институты работают в режиме максимально возможной оптимизации затрат. Требуется существенно облегчить процесс создания исходящих сообщений. Для оптимизации процесса создания нагрузки необходимо до выполнения теста заготовить шаблоны сообщений, сократив процессорное время на серверах, содержащих инструменты для тестирования. Сходные соображения заложены в генератор нагрузки, созданный 244 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 245. разработчиками крупнейшего российскогопоисковика «Яндекс». Инструмент для тестирования с открытым кодом «Яндекс.Танк» предназначен для генерации огромных объёмов сообщений по протоколу HTTP [14]. Высокая производительность «Яндекс.Танк» достигается концентрацией нагрузки в одной сессии и одном потоке, а также использованием заготовленного файла со статическими запросами. Генераторы нагрузки для трейдинговых систем не могут использовать статические данные и обладают рядом других ограничений, рассматриваемых в следующей части. 3 Особенности нагрузочного тестирования торговых систем В [15] разобраны основные требования к моделированию нагрузки для систем высокочастотной торговли. Логика работы таких систем существенно затрудняет использование статичных, ранее записанных или предопределенных данных. В этой секции рассматриваются некоторые из особенностей создания нагрузки и подготовки входных данных для тестирования трейдинговых систем. 3.1. Создание сообщений из шаблонов Вследствие того, что торговля не анонимна, для поддержания сессии сервер должен получать имена существующих пользователей, корректные порядковые номера сообщений, а также время отправки каждого сообщения. Наш анализ показал, что построение сообщений непосредственно перед отправкой с использованием словарей обходится очень дорого с точки зрения используемых системных ресурсов. Поэтому было решено использовать заготовки, в которых порядок полей и набор ключевых значений заданы до начала теста. Например, в FIX-сообщении NewOrderSingle перед моментом отправки будут изменяться всего несколько параметров, которые должны быть уникальны (например, ClOrdID(11) – номер клиентской заявки) и зависеть от текущего времени (ExpireTime(126) – время истечения срока заявки, ExpireDate(432) – день истечения срока заявки). Остальные параметры новой заявки не изменяются. Для поддержания сессии изменяются служебные параметры: BodyLength(9) – длина сообщения; SenderCompID(49) – название компании, которая отправила заявку; TargetCompID(56) – название компании, которой была отправлена заявка; MsgSeqNum(34) – уникальный номер сообщения; SendingTime(52) – текущее время; CheckSum(10) – проверочное число. В сообщения OrderCancelReplaceRequest и OrderCancelRequest подставляются все необходимые параметры, взятые из сообщения NewOrderSingle, такие как: OrderID(37) – идентификатор заявки; Price(44) – цена заявки; Quantity(53) – размер заявки; Side(54) – сторона заявки (покупка или продажа); Symbol(55) – символическое обозначение инструмента. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 245
- 246. Предположение, что всезначения параметров верны, даёт возможность существенной экономии времени на проверку значений полей и правильности их последовательности в сообщении. 3.2. Воспроизведение ранее записанных данных Отправка заранее подготовленных записанных данных приводит к искажению теста. При построении данных для тестирования необходимо придерживаться той же пропорции торговых событий, которую мы наблюдаем в реальной жизни. Анализ реальных торгов показывает, что на одну сделку может приходиться более 20 изменений заявок. Записанные данные представляют собой совокупность новых заявок, их изменения и отмены. Так как заявки отправляются из разных потоков на одну и ту же книгу заявок, они могут приходить на рынок в порядке, отличном от того, каким он был при записи. Даже если время появления заявки на рынке будет отличаться незначительно, это может привести к нежелательным последствиям. Например, к моменту получения рынком заявки, другие заявки могут располагаться в книге заявок в порядке, отличном от того, который был при записи, и они могут проторговаться в другой последовательности. Из этого следует, что последующие изменения или отмена заявки будут невозможны, так как заявка проторговалась и была удалена из книги заявок. Такая ситуация влечёт за собой сбой в последовательности сценария тестирования, и в дальнейшем будет получен сценарий, отличный от записанного. Таким образом, на рынке будут происходить события, отличные от тех, что были при записи сценария. Например, рынок будет отправлять значительно больше отказов на изменение или отмену заявок. При этом отличия от первоначального сценария могут накапливаться, и реальная пропорция торговых событий может сильно отличаться от исходной. 3.3. Использование детерминированных сценариев Другая возможность организовать тест заключается в подготовке двух групп заявок: к первой группе относятся заявки, о которых заранее известно, что они будут участвовать в сделках (активные заявки); вторая группа состоит из заявок, которые не должны торговаться (пассивные заявки). Однако в этом случае следует учитывать возможные осложнения со стороны системы мониторинга и контроля рынков (англ. Market Surveillance System). Одна из функций этого компонента заключается в том, что он должен в режиме реального времени отслеживать «договорные» заявки, т.е. как раз те заявки, которые должны проторговаться при проведении тестирования, и сообщать о таких событиях службе, следящей за манипулированием ценами на рынке. Очевидно, что такой вариант не подходит для создания сценария тестирования. В связи с этим, нашими специалистами был создан рандомизированный генератор нагрузки с использованием механизма обратной связи. Рандомизация используется для генерации новой цены при отправке изменения заявки. Для генерации используются три параметра: начальная цена, диапазон изменения цены и шаг изменения цены. 246 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 247. Начальная цена задаетсяв массиве данных для каждого инструмента и для каждой стороны (покупки или продажи). Начальные цены должны удовлетворять следующим условиям: - цена покупки должна быть меньше цены продажи; - разница начальных цен продажи и покупки должна составлять около 2-3% от цены открытия рынка. Диапазон изменения цены покупки и продажи выбирается таким образом, чтобы цены встречных предложений пересекались, обеспечивая торговлю, и чтобы цены предложений не выходили за 10%-й барьер - условие, при несоблюдении которого возможна остановка торговли на данном инструменте или на целом сегменте инструментов. Эти параметры позволяют гибко подбирать желаемое среднее соотношение количества сделок к количеству изменений, приходящихся в среднем на одну заявку. Чем меньше область пересечения цен покупки и продажи, тем меньше будет сделок, и заявка в среднем будет изменяться большее количество раз. Надо заметить, что это отношение нелинейно зависит от интервала пересечения цен. Поскольку цены задаются для каждого инструмента в отдельности, становится возможным настроить разное количество сделок на разных инструментах в одном тесте. Шаг изменения цены задаётся исходя из конфигурации инструмента. Например, одни инструменты могут торговаться с шагом цены 0,05, другие - с шагом цены 0,10. Механизм обратной связи необходим, чтобы отслеживать состояние заявки на рынке и обеспечивать возможность изменения или отмены заявки. Заявка может иметь следующие состояния: New – заявка еще не приняла участие в торговле; PartFilled – заявка выполнена частично; Filled – заявка выполнена полностью; Canceled – заявка отменена клиентом; Expired – заявка с истекшим сроком действия; Rejected – заявка отклонена биржей. Только заявки в состояниях «New» и «PartFilled» могут участвовать в торговле. Как только заявка переходит в другое состояние, она перестает быть интересной, и информация о ней тут же удаляется. 4 Пример настройки разработанного генератора нагрузки В этой части статьи подробнее остановимся на нескольких вариантах настройки разработанного авторами генератора нагрузки для тестирования трейдинговых систем на основе протокола FIX [16]. Настройка теста осуществляется посредством 4-х типов конфигурационных файлов, которые содержат: настройку параметров нагрузки; конфигурацию сессий; заготовку сообщений; распределение по сообщениям. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 247
- 248. 4.1. Формат файлапараметров нагрузки Для настройки параметров нагрузки используется файл, имеющий следующий формат: #Конфигурационный файл с настройками сессий: CONNECTIONS_CONFIG = fixConnections.cfg #Указание используемых сессий из файла с сессиями: CONNECTIONS_RANGE = 1-3, 5, 7#Файл с заготовками сообщений: MESSAGE_TEMPLATES = fixMessageTemplates.dat #Файл с распределением по сообщениям: MESSAGE_RATES = messageRates.cfg #Последовательность действий до начала теста: INIT_CONFIG = connect(100ms), logon(3s) #Конфигурация нагрузки: LOAD_CONFIG = const(1000,5m) #Задается постоянная нагрузка 1000 сообщений в секунду #на протяжении 5-и минут. #Количество повторений нагрузочного сценария, заданного #параметром LOAD_CONFIG: NUMBER_REPETITIONS = 10 #Последовательность действий после окончания теста: SHUTDOWN_CONFIG = logout(1s), disconnect(10ms) #Последовательность действий при внезапном обрыве #соединения ON_RECONNECT_CONFIG = connect(10ms), logon(3s) #Флаг на выполнение действий, указанных в #ON_RECONNECT_CONFIG при обрыве соединения: HOLD_CONNECTION = 1 #Если значение = 0, действия в ON_RECONNECT_CONFIG не #выполняются, и соединение не восстанавливается. #Время задержки между авторизацией сессий в миллисекундах LOGON_INTERVAL = 1000 Поскольку у клиентов есть возможность использовать собственные программы для торговли, существует вероятность того, что по какой-то причине, например, в случае отправки торговой системой большого объёма сообщений, клиентские программы не смогут вовремя прочитать эти данные. Это может негативным образом повлиять на поведение торговой системы. Для тестирования этой возможности в разработанном программном продукте существует специальное ограничение по количеству читаемых данных в секунду для эмуляции медленных клиентов. 4.2. Формат файла конфигурации сессий Настройки параметров соединений задаются в файле следующего формата: В секции COMMON задаются общие параметры соединений: [COMMON] HOST = 10.10.10.10 PORT = 5555 TARGET_COMP_ID = FGW В секции [FIX] задаются уникальные параметры отдельного соединения: [FIX] SENDER_COMP_ID = LOAD_1 RESET_SEQ_NUM_AFTER_LOGOUT = 0 248 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 249. PARTY_ID = LOAD_1 Секция[FIX] должна повторяться столько раз, сколько предполагается использовать соединений. При этом соединения, которым предстоит участвовать в тесте, задаются параметром CONNECTIONS_RANGE в файле с параметрами нагрузки. 4.3. Формат файла заготовок сообщений Файл содержит массив именованных сообщений-заготовок. Эти заготовки имеют правильные формат и последовательность полей в сообщениях. Некоторые поля будут заменяться корректными данными непосредственно перед отправкой сообщения. Logon 8=FIXT.1.1|9=61|35=A|34=1|49=SenderCompID|56=TargetCompID|98=0|108=3600| 554=password|1137=9|10=135|EOM NewOrderBuy 8=FIXT.1.1|9=199|35=D|34=1|49=SenderCompID|56=TargetCompID|1=CLIENT|11=C lOrdID|38=200|40=2|44=9.8|54=1|55=Symbol|59=6|60=2013072813:34:03.194|432=20130730|528=P|581=3|1138=60000|9303=I|453=1|448=PartyI D|447=D|452=76|10=047|EOM NewOrderSell 8=FIXT.1.1|9=199|35=D|34=1|49=SenderCompID|56=TargetCompID|1=CLIENT|11=C lOrdID|38=150|40=2|44=10.2|54=2|55=Symbol|59=6|60=2013072813:34:03.194|432=20130730|528=P|581=3|1138=60000|9303=I|453=1|448=PartyI D|447=D|452=76|10=047|EOM Cancel 8=FIXT.1.1|9=134|35=F|34=1|49=SenderCompID|56=TargetCompID|11=ClOrdID|41 =OrigClOrdID|54=1|55=Symbol|60=2013072813:34:03.178|9303=I|453=1|448=PartyID|447=D|452=76|10=050|EOM Replace 8=FIXT.1.1|9=179|35=G|34=1|49=SenderCompID|56=TargetCompID|1=CLIENT|11=C lOrdID|38=180|40=2|41=OrigClOrdID|54=1|55=Symbol|60=2013072813:34:03.178|432=20130730|1138=70000|9303=I|453=1|448=PartyID|447=D|452= 76|10=077|EOM Logout 8=FIXT.1.1|9=29|35=5|34=111|49=SenderCompID|56=TargetCompID|10=249|EOM 4.4. Формат файла распределения нагрузки по сообщениям Файл содержит соотношение количества сообщений, указанных в долях для каждого типа сообщения: NewOrderBuy = 15 Replace = 50 Cancel = 5 В зависимости от настройки, MESSAGE_SELECTION_ORDER = sequential или random, сообщения будут выбираться или последовательно, или случайным образом. 4.5. Упрощенная схема работы алгоритма На рисунке 1 приведена блок-схема алгоритма по выбору и отправке сообщений. На первом этапе происходит чтение входящих данных. В случае, если данные есть, происходит анализ полученных ответов и изменение Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 249
- 250. состояния заявок илиих параметров. После этого случайным методом или последовательным перебором выбирается новое сообщение. Если был выбран приказ на создание новой заявки, его параметры сохраняются в памяти для дальнейшего использования. В случае выбора сообщения для изменения или отмены заявки, выбирается заявка, для которой нет неотвеченного запроса. Её параметры подставляются в сообщение и посылаются в торговую систему. После этого вычисляется время, прошедшее с начала итерации. Оно сравнивается с расчётным средним временем на одну итерацию, и при необходимости делается пауза. Последовательность «читать-отправить-ждать» позволяет принимать во внимание все последние изменения внутри тестируемой системы и на их основе посылать корректные с функциональной точки зрения сообщения. Рис. 1. Блок-схема получения и отправки сообщения. Запуск теста с максимальной нагрузкой на Intel(R) Xeon(R) CPU X5570 @ 2.93GHz даёт на выходе с одного ядра до 70 000 сообщений в секунду и линейно масштабируется при использовании большего количества ядер. Результаты были подтверждены при распределении генерирующих потоков по 8 ядрам и использовании промышленной биржевой системы в качестве мишени. 250 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 251. Указанный объем нагрузки,создаваемой с одного сервера, превышает пропускную способность существующих систем торговли акциями. Показатель 70,000 исходящих сообщений в секунду с одного ядра соответствует максимальным показателям инструментов для тестирования веб-инфраструктур с помощью статических запросов [17]. 4.6. Настройка профиля нагрузки В этой части статьи описывается настройка профиля нагрузки. Нагрузка задается параметром: LOAD_CONFIG = фаза1 [, фаза2, … фазаN] Нагрузочная фаза может быть следующей: -const(freq, dur) – постоянная нагрузка c частотой freq и длительностью dur. Возможно также использовать сокращенный формат – freq:dur; -step(freq, delta, steps, dur) – увеличивающаяся нагрузка с начальной частотой freq, шагом изменения частоты delta, количаством шагов steps и длительностью одного шага dur; - connect(dur) – все сессии должны установить соединение с задержкой dur; - disconnect(dur) – все сессии должны оборвать соединение с задержкой dur; - logon(dur) – все сессии должны послать сообщение с авторизацией с задержкой dur; - logout(dur) – все сессии должны послать сообщение о прекращении сессии с задержкой dur; Обрыв соединения сам по себе не является критической проблемой. Например, все web-соединения, и особенно соединения в мобильных приложениях, рассчитаны на то, что они будут прерываться. Для финансовых протоколов это событие может означать потерю участником торговли контроля над его заявками, и многие системы настроены на отмену всех открытых заявок. Если клиент активно ведёт торговлю и выставляет много заявок, потеря соединения приведет к тому, что его заявки будут массово отменены системой, что вызовет повышенную нагрузку на ядро системы. Также необходимо знать, как поведёт себя система при восстановлении соединения и авторизации под нагрузкой. Очень важно иметь возможность воспроизводить внезапный обрыв и восстановление соединения под нагрузкой. Для этой цели были созданы выше описанные фазы: connect, disconnect, logon, logout. На рисунке 2. Изображены различные нагрузочные профили const, step и micro burst. Последний профиль создается при помощи фазы const с малой длительностью и высокой нагрузкой. Рис. 2. Простейшие варианты профилей нагрузки. const: LOAD_CONFIG=const(1000, 20m) Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 251
- 252. step: LOAD_CONFIG=step(500, 500,4, 4m) micro burst: LOAD_CONFIG=200:5m, 40000:10ms, 200:5m, 75000:10ms, 200:5m Из опыта авторов, нагрузка в форме ступеней (step) в наибольшей степени подходит для определения максимальной производительности системы. Нагрузка в форме микро-всплекса в наибольшей степени воспроизводит поведение современных высоконагруженных трейдинговых систем. 5 Заключение Созданный и описанный в данной статье инструмент тестирования используется при измерении пропускной способности и времён отклика крупномасштабных биржевых и брокерских платформ, обеспечивающих технологическую инфраструктуру финансовых рынков, в рамках проектов, осуществляемых при поддержке компании Exactpro Systems LLC. Достигнутые результаты подтверждают эффективность выбранных методов работы: управление исполняемыми потоками посредством центрального контроллера и использование заготовленных шаблонов при генерации потока сообщений. Планируется дальнейшее расширение списка открытых и коммерческих протоколов коммуникаций, поддерживаемых данным инструментом для тестирования. Несмотря на то, что существующая производительность генератора нагрузки позволяет создать реалистичный поток данных, используя один сервер, достаточный для перегрузки любой из существующих торговых площадок, а также для обеспечения качества трейдиговых систем, которые появятся в ближайшие годы, планируется разработка масштабируемого модуля, позволяющего контролировать нагрузку, создаваемую с нескольких серверов. Основным направлением исследовательской работы станет совершенствование механизмов обработки обратного потока данных для повышения сложности и реалистичности сценариев нагрузочного тестирования торговых платформ. При этом высокая экономичность и эффективность используемых для тестирования инструментов сохранятся. Источники 1. The Future of Computer Trading in Financial Markets. Final Project Report. / Foresight. The Government Office for Science, London. // [Электронный ресурс]. – Режим доступа http://www.bis.gov.uk/assets/foresight/docs/computer-trading/12-1086-future-of-computertrading-in-financial-markets-report.pdf 2. Commission Roundtable on Technology and Trading: Promoting Stability in Today's Markets. / U.S. Securities and Exchange, October 2, 2012 // [Электронный ресурс]. – Режим доступа http://www.sec.gov/news/otherwebcasts/2012/ttr100212-transcript.pdf 3. Apache JMeter manual // [Электронный ресурс]. – Режим доступа http://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.pdf 4. HP LoadRunner manual // [Электронный ресурс]. – Режим доступа ftp://ftp.itrc.hp.com/applications/HPSoftware/ONLINE_HELP/LoadRunner11.50_User.pdf 252 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 253. 5. Rational PerformanceTester // [Электронный ресурс]. – Режим доступа http://www03.ibm.com/software/products/ru/ru/performance/ 6. Silk Performer // [Электронный ресурс]. – Режим доступа http://www.borland.com/products/silkperformer/ 7. Penhaligan,P.: Equity Trading: Performance, Latency Throughput. / ExTENT Conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3turquoise-equitytrading2012 8. Benedetti E., Zanetti L.: London Stock Exchange - The Focus Beyond Low Latency. / ExTENT Conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent-2013-obninsk-lse-the-focus-beyond-low-latency 9. Cong, J.: Load Specification and Load Generation for Multimedia Traffic Loads in Computer Networks. // Ph.D. Dissertation, FB Informatik, Univ. Hamburg, 2006; also published at: Shaker-Verlag, Aachen 2006 10. Jing Cong, Bernd E. Wolfinger: A Unified Load Generator Based on Formal Load Specification and Load Transformation // valuetools '06: Proceedings of the 1st international conference on Performance evaluation methodolgies and tools 11. Bodík P., Fox A., Franklin M., Jordan M., Patterson D.: Characterizing, Modeling, and Generating Workload Spikes for Stateful Services // SoCC’10, June 10–11, 2010 12. David Mosberger, Tai Jin: httperf—a tool for measuring web server performance // SIGMETRICS Performance Evaluation Review , Volume 26 Issue 3, December 1998 13. Иткин И.Л.: Тестирование биржевых систем в условиях высокочастотного трейдинга // SQA Days #10: http://sqadays.com/talk.sdf/sqadays/11151/talks/12196 14. Yandex.Tank Documentation // [Электронный ресурс]. – Режим доступа https://media.readthedocs.org/pdf/yandextank/latest/yandextank.pdf 15. Itkin Iosif: Theory of High Frequency Trading systems testing // Software Development Analysis Technologies Seminar http://sdat.ispras.ru/2011/09/20-октября-моделитестирования-систем/ http://www.slideshare.net/IosifItkin/theory-of-high-frequency-tradingsystems-testing 16. Официальный сайт FIXprotocol // [Электронный ресурс]. - Режим доступа http://www.fixprotocol.org/ 17. How to Generate Millions of HTTP Requests // [Электронный ресурс]. - Режим доступа http://dak1n1.com/blog/14-http-load-generate Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 253
- 254. Использование MBT-подхода дляверификации систем мониторинга и контроля на фондовых биржах Наталья Прядкина1, Антон Крюков1 1 Костромской государственный технологический университет 156005, г. Кострома, ул. Дзержинского, 17 Natalia.Pryadkina@exactpro.com, Anton.Kryukov@exactpro.com Аннотация. Данная статья описывает проблемы тестирования систем мониторинга и контроля на фондовых биржах (СМКнФБ). На сегодняшний день такие системы представляют собой комплексные программные продукты, реализующие сложные математические алгоритмы и обрабатывающие большой объём данных. Одной из их задач является уменьшение количества ложных срабатываний, что достигается за счёт наиболее полного покрытия при тестировании. В работе определены подходы для адаптации метода тестирования на основе модели (ТнОМ, MBT) к верификации СМКнФБ. Построена структурная модель системы, дано формализованное описание метода в нотации IDEF0. Определены требования к степени абстракции функциональной модели СМКнФБ, необходимой для проведения тестирования. Ключевые слова: обеспечение качества; тестирование на основе модели; автоматическое создание тестовых сценариев; система мониторинга на фондовых биржах. 1 Введение В связи с тем, что манипуляции на фондовых биржах подрывают эффективность финансовых рынков и доверие к ним, вплоть до снижения стабильности всей экономической системы, они являются одной из серьёзных проблем для финансовых организаций и участников торгов [1, 7]. В настоящее время законодательство обязывает финансовые институты применять системы мониторинга и контроля (СМКнФБ, surveillance system) с целью выявления и пресечения незаконных действий на рынке, таких как распространение недостоверной информации, манипулирование ценами или мошенничество за счёт использования информации, недоступной широкой публике (инсайдерская информация) [1, 2]. Современные СМКнФБ являются комплексными продуктами, интегрированными в трейдинговые системы, и основываются на адаптивной логике. Они реализуют сложные математические алгоритмы, собирают статистическую информацию о ситуации на рынке и обрабатывают большие объёмы данных в режиме реального времени. Одной из их задач является уменьшение количества 254 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 255. ложных срабатываний, т.е.сокращение количества ошибок первого и второго рода [2]. Такие системы требуют особого подхода к тестированию. Существует множество методов, которые могут быть применимы для верификации работы информационной системы. Выбранный метод – в идеале - должен обеспечивать достижение ряда целей: 1. универсальная теория всего; 2. моделирование на основе тестов (test-based modeling); 3. стопроцентная автоматизация тестирования; 4. максимально полное проектирование тестов [3]. Методологии тестирования исторически развиваются так, что каждая из них делает ещё один шаг в этих направлениях. Метод тестирования на основе модели (ТнОМ, model-based testing, MBT) нашёл широкое применение в проверке качества работы информационных систем. Данный подход имеет значительный потенциал для выполнения гибкоуправляемого тестирования сложных систем, которые не могут быть протестированы в достаточной мере при помощи основных технологий с приемлемыми трудозатратами [11]. Во второй главе данной статьи будут рассмотрены особенности систем мониторинга и контроля на фондовой бирже; в третьей – основные методологии, которые могут быть применены к тестированию таких систем, а также будет сделан вывод о наиболее эффективной из них; в четвертой главе будут определены основные подходы для адаптации метода тестирования на основе модели к верификации СМКнФБ. 2 Особенности систем мониторинга и контроля на фондовой бирже СМКнФБ выполняет функцию мониторинга рынка с целью выявления нетипичных ситуаций, которые могут служить идентификаторами незаконных финансовых транзакций [8, 16]. Контролируют данный процесс такие регулирующие органы в сфере финансовых услуг, как: Департамент управления финансовыми рынками Великобритании (Financial Conduct Authority, FCA), Комиссия по ценным бумагам и биржам США (Securities and Exchange Commission, SEC) и другие [5]. В таблице 1 отображены основные требования к СМКнФБ. Табл. 1. Требования к системе мониторинга и контроля на фондовой бирже Требование Определение и предотвращение различных типов мошенничества на бирже Описание На сегодняшний день существуют десятки типов поведения на рынке, которые могут быть расценены как мошенничество. СМКнФБ должны сигнализировать о потенциально нелегитимном Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 255
- 256. Гибко настраиваемые алгоритмы распознавания образов (адаптивнаялогика) Обработка большого количества данных в режиме реального времени Минимизация ложных (ложноположительное / ложноотрицательное) срабатываний: избежание ошибок первого и второго рода Интеграция с трейдинговой системой: поддержка различных протоколов Сбор статистических данных за определенный период поведении с помощью сигнала тревоги (alert). Пусковые механизмы этих сигналов реализуются с помощью математических алгоритмов Для эффективного выявления мошенничества необходимо непрерывно адаптировать существующие алгоритмы к новым ситуациям, возникающим в ходе торгов [6] СМКнФБ непрерывно получает информацию от трейдинговых и других внешних систем, обрабатывает её и выдаёт результат анализа (сигналы о потенциально нелегитимном поведении участников торгов и статистика), информацию о состоянии рынка Основной проблемой современных систем мониторинга и контроля на фондовой бирже является разграничение нарушителей и механизмов биржи, отвечающих за ликвидность на рынке (market makers). Необходимо минимизировать ошибки первого рода (false positives) – ложная тревога – и ошибки второго рода (false negatives) – пропуск случаев манипулирования и иных нарушений на рынке Вследствие того, что трейдинговая система использует различные протоколы для обмена информацией с клиентами и внешними системами, возникает необходимость поддержки их и в СМКнФБ. Кроме этого, такая система поддерживает внутренние протоколы СМКнФБ, кроме наблюдения в режиме реального времени за чистотой и упорядоченностью биржевой торговли, должна нести в себе функцию сбора статистических данных и предоставлять возможность детального восстановления ситуации на рынке на определенный период времени. Особенности, обозначенные в таблице 1, влекут за собой повышенные требования к тестированию таких систем. В процессе верификации СМКнФБ, как и любой системы, тестировщики стремятся осуществить близкую к стопроцентной проверку работоспособности системы, что достигается за счёт большего покрытия и большего количества тестовых сценариев [14]. С другой стороны, с расширением библиотеки тестов увеличивается время, необходимое на верификацию работы СМКнФБ. Более того, незначительное изменение функциональности системы может повлечь за собой существенное преобразование библиотеки тестов. 256 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 257. Таким образом, проблемавыбора оптимального метода для построения процесса тестирования СМКнФБ является актуальной. На Рисунке 1 представлена, разработанная в рамках проектов компании Exactpro Systems, LLC, структурная модель системы мониторинга и контроля на фондовых биржах, определены главные компоненты и информационные потоки, типичные для такой системы. Рис. 1. Структурная модель системы мониторинга и контроля на фондовой бирже, разработанная в рамках проектов компании Exactpro Systems, LLC Как видно из рисунка 1, СМКнФБ может получать информацию как по сетевым протоколам TCP/IP и UDP, так и проводить анализ на основе файла. Используются базы данных Level DB для сохранения обрабатываемых сообщений; Mongo DB – для сигналов тревоги о потенциальном случае манипулирования или иного нарушения (surveillance alerts) и статистики. Поток сообщений в системе обрабатывается с помощью так называемых «акторов» (actors systems, akka) трансляции, хранения сообщений, сценариев и бизнес логики. 3 Выбор метода тестирования Верификация работы программных продуктов охватывает широкий спектр деятельности: от тестировании, выполняемого разработчиками (unit testing), до приёмо-сдаточных испытаний (acceptance testing) [3, 9]. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 257
- 258. В этой главебыла проанализирована возможность применения различных методологий к тестированию СМКнФБ. 3.1 Методы тестирования 3.1.1 Ручное тестирование (Manual Testing) Несмотря на ряд ограничений, присущих ручному тестированию, оно широко используется при верификации определенного рода программных продуктов. Тестировщик, используя тестовый план и спроектированные сценарии, воздействует на систему и считывает результат своего воздействия с её графического интерфейса. Хотя СМКнФБ и имеет свой интерфейс, с помощью которого пользователь может считывать информацию (окна приложения), для воспроизведения даже одного вида потенциальных нарушений, необходимо сделать десятки манипуляций. Более того, чем разнообразнее становится функциональность системы, тем сложнее делать повторный прогон тестов на новой версии (regression testing). К тому же, система обрабатывает огромный поток данных, за которым порой трудно уследить. 3.1.2 Тестирование на основе скриптов (Script Based Testing) Тестирование на основе скриптов нашло широкое применение в процессе верификации программных продуктов. Данный метод предполагает использование тестового инструмента, который применяется для автоматического прогона тестовых сценариев, написанных на специальном языке. Сами же тесты пишутся вручную. Пользователь СМКнФБ, применяя специальные инструменты, может отправлять данные, воздействуя на систему, а также получать ответ от системы и сопоставлять его с ожидаемым результатом. 3.1.3 Тестирование на основе модели (Model Based Testing) Коротко данный вид тестирования можно охарактеризовать как автоматизированное проектирование тестов черного ящика. Вместо того, чтобы вручную создавать тесты, основанные на документации, MBT подход подразумевает проектирование модели, отвечающей некоторым требованиям и имитирующей тестируемую систему [4]. 258 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 259. 3.2 Оценка методовтестирования систем мониторинга и контроля на фондовых биржах Метод тестирования систем мониторинга и контроля на фондовых биржах должен отвечать следующим требованиям: 1. обеспечение наиболее полного покрытия тестами [15]; 2. высокая степень автоматизации сценариев тестирования; 3. возможность повторного выполнения сценариев (regression testing); 4. минимизация ошибок первого и второго рода (ложных срабатываний); 5. выполнение прогона библиотеки тестов за приемлемое время; 6. минимизация изменений сценариев тестирования при изменении функционального поведения системы: 7. обеспечение возможности автоматизированного тестирования при недетерминированном поведении системы. MBT метод наиболее полно отвечает всем обозначенным выше требованиям. 4 Тестирование на основе модели (Model Based Testing) Методология тестирования на основе модели предполагает автоматизацию процесса проектирования сценариев тестирования и матриц покрытия (traceability matrix) [4]. Данный подход позволяет существенно снизить затраты на создание библиотеки тестовых сценариев: вместо ручного написания тестировщиком сотен и тысяч сценариев, проектировщик создает абстрактную модель системы, затем с помощью инструмента MBT автоматически генерируется множество тестовых сценариев на основе этой модели. Таким образом, общее время проектирования тестов сокращается; кроме того, при использовании других критериев отбора, может быть создан новый тестовый набор на основе существующей модели [4, 12]. Модель должна представлять собой проекцию структуры и поведения системы, причём может быть спроектирована как целая система, так и отдельные её функциональные части. 4.1 Этапы МВТ подхода Формализованное описание тестирования на основе модели дано на рисунке 2. На первом этапе происходит проектирование модели системы. Здесь необходимо выбрать оптимальную степень абстракции, удовлетворяющую заданным требованиям. На втором этапе на основе модели создаются абстрактные тестовые сценарии. Вследствие того, что количество всевозможных тестов стремится к бесконечности, нам необходимо выбрать критерии отбора, которые ограничат множество тестовых вариантов до требуемого. Выходными данными на этом этапе Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 259
- 260. служат абстрактные тесты,а также матрица покрытия, иллюстрирующая степень покрытия функциональных требований созданными тестовыми сценариями. Третий этап – преобразование абстрактных тестовых сценариев в исполняемые скрипты. Это достигается путём применения инструмента преобразования, который использует различные шаблоны и взаимосвязи для перевода каждого абстрактного теста в исполняемый скрипт. Четвертый этап – выполнение тестов. На пятом этапе тестировщиком проводится анализ полученных результатов. Рис. 2. Бизнес-процесс Тестирование на основе модели в нотации IDEF0 260 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 261. 4.2 Применение MBTк тестированию систем мониторинга и контроля на фондовых биржах Основной задачей и главной проблемой в случае применения метода является построение модели системы. В качестве инструмента преобразования может быть использован инструмент, который будет перебирать всевозможные комбинации того или иного вида нарушений. В этом случае можно предположить, что более эффективным и дешёвым способом будет моделирование не всей системы, а лишь отдельных её частей, отвечающих за мониторинг определённого вида манипулирования на рынке. Слабое место данного подхода – сложность организации взаимодействия компонентов системы между собой. Поскольку СМКнФБ являются комплексными программными продуктами, метод не будет эффективен, так как остаются так называемые «мертвые зоны» – части системы, которые не будут смоделированы и покрыты сценариями тестирования. При построении модели мы получаем подобие реальной системы, предполагающее некоторую степень абстракции. Таким образом, требуется определить оптимальный уровень абстракции, с учетом того, что часть функциональности не будет представлена в модели. В случае, если система разбита на N локальных представлений (подсистем), модель i-го представления может быть задана как функция: , где (1) – входные данные i-го локального представления системы; – погрешность моделирования локального представления; ; в случае, если модель по параметрам приближается к реальной системе. При этом, модель всей системы может быть определена как: (2) где – погрешность моделирования системы, возникающая за счёт выполнения операций объединения локальных представлений, . в случае, если : В связи с тем, что СМКнФБ обладают сложной структурой, и количество локальных представлений N велико, для достижения требуемых результатов тестирования при построении модели необходимо обеспечить минимальные значения z и Z. При построении модели требуется обеспечить максимальную приближённость к реальной системе, вплоть до разработки аналога. Чем ближе модель к реальной СМКнФБ, тем полнее покрытие тестируемой системы сценариями тестирования. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 261
- 262. Таким образом, задачамидальнейшего исследования являются: 1. Оценка степени сложности системы методами системного анализа; 2. Определение возможности тестирования системы на моделях локальных представлений (подсистем); 3. Оценка возможностей построения имитационной модели системы; 4. Определение целесообразности построения физической модели системы, с учетом используемых методов. В качестве начального исследования нами был проведен эксперимент на проектах компании Exactpro Systems, LLC. Осуществлялось тестирование системы мониторинга и контроля под названием T. В качестве контрольных методов тестирования были выбраны ручное и тестирование на основе скрипта. Так как компания Exactpro Systems, LLC начала разработку СМКнФБ под названием Д., эта создаваемая система была использована в качестве имитационной модели системы Т. при тестировании на основе метода MBT. В результате тестирования системы Т. было найдено на 9.8 % больше ошибок, по сравнению с контрольными методами тестирования. 5 Заключение Системы мониторинга и контроля биржевых систем состоят из большого количества модулей, что обусловливает необходимость большого объёма тестовых сценариев. Кроме того, цена ошибки в таких системах чрезвычайно высока. Поэтому для обеспечения быстрого и полного автоматизированного тестирования были рассмотрены и выделены наиболее подходящие подходы к верификации СМКнФБ. Показано, что тенденцией в современной теории тестирования является переход к автоматическому режиму проверки программного обеспечения, и МВТ позволяет этого достичь. Показано, что метод тестирования на основе модели позволяет автоматизировать проектирование сценариев тестирования, сокращать затраты на поддержку имеющегося набора тестов, автоматизировать создание таблицы неисправностей. Именно этого стремятся добиться инженеры по обеспечению качества при тестировании какого-либо программного продукта. В статье определены подходы для адаптации метода MBT к специфике СМКнФБ и проблемы построения модели системы, необходимой для её тестирования. Также сделан вывод о том, что лучшим инструментом для тестирования системы мониторинга и контроля на фондовой бирже является другая СМКнФБ. Литература 1. R. K. Aggarwal, G. Wu: “Stock Market Manipulations,” Journal of Business, vol. 79, no. 4, pp. 1915-1953, 2006 262 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 263. 2. Jens WirénFarhad Kimanos: A Survey Implementation of Financial Alarm Classification [Электронный ресурс] // Режим доступа – http://scila.se/wpcontent/uploads/2013/07/AIforAlertClassification-ScilaReport.pdf 3. Antonia Bertolino Software Testing Research: Achievements, Challenges, Dreams [Электронный ресурс] // Режим доступа – http://ieeexplore.ieee.org/xpl/login.jsp?tp=arnumber=4221614url=http%3A%2F%2Fieeexp lore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4221614 4. Mark Utting, Bruno Legeard: Practical Model-Based Testing a Tools Approach. Morgan Kaufmann Publishers, 2007 5. Michael J. Aitken: Strategic Surveillance in the Philippine Capital Markets and the expectations of surveillance technology [Электронный ресурс] // Режим доступа – http://www.telchar.com/pdf/surveillance.pdf 6. Иосиф Иткин, Наталья Прядкина, Антон Крюков: «Анализ данных в высоконагруженных трейдинговых системах» [Электронный ресурс] // Режим доступа – http://clubqa.ru/blogs/?p=436 7. David Diaz, Mohamed Zaki, Babis Theodoulidis, Pedro Sampaio: A Systematic Framework for the Analysis and Development of Financial Market Monitoring Systems [Электронный ресурс] // Режим доступа – http://ieeexplore.ieee.org/xpl/login.jsp?tp=arnumber=5958083url=http%3A%2F%2Fieeexp lore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5958083 8. Johan Örtenblad, Vladimir Vlassov, Torkel Erhardsson, Håkan Carlbom, Johan Norén: Market Surveillance System [Электронный ресурс] // Режим доступа – http://web.it.kth.se/~maguire/DEGREE-PROJECT-REPORTS/020606-Johan-Ortenblad.pdf 9. Noah Höjeberg: Random Tests In A Trading System Using Simulations And A Test Oracle [Электронный ресурс] // Режим доступа – http://kiosk.nada.kth.se/utbildning/grukth/exjobb/rapportlistor/2008/rapporter08/hojeberg_noah _08037.pdf 10. Wolfgang Prenninger, Alexander Pretschner: Abstractions for Model-Based Testing [Электронный ресурс] // Режим доступа – ftp://ftp.ira.uka.de/pub/ZVI/papers/tacos04.pdf 11. Victor V. Kuliamin: Model Based Testing of Large-scale Software: How Can Simple Models Help to Test Complex System [Электронный ресурс] // Режим доступа – http://panda.ispras.ru/~kuliamin/docs/ISOLA-2004-en.pdf 12.Mark Utting, Alexander Pretschner, Bruno Legeard: A Taxonomy Of Model-Based Testing [Электронный ресурс] // Режим доступа – http://www.cs.waikato.ac.nz/pubs/wp/2006/uowcs-wp-2006-04.pdf 13. Learning from Financial Trading Bugs [Электронный ресурс] // Режим доступа – http://gaynwinters.wordpress.com/2012/10/26/learning-from-financial-trading-bugs/ 14. NASA Software Safety Guidebook [Электронный ресурс] // Режим доступа – http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf 15. Phyllis Franklt Dick Hamlet Bev Littlewood Lorenzo Strigini: Choosing a Testing Method to Deliver Reliability [Электронный ресурс] // Режим доступа – http://www.computer.org/csdl/proceedings/icse/1997/2162/00/21620068-abs.html 16. Afroditi Katika, Babis Theodoulidis, David Diaz: Investigating Financial Fraud In High Frequency Trading: Context And Drivers [Электронный ресурс] // Режим доступа – http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1974911 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 263
- 264. Тестирование графического интерфейса трейдинговыхтерминалов в условиях высокочастотной торговли Иван Бобров1, Алексей Зверев 2 1 ООО «Инновационные Трейдинговые Системы», Россия, 156013, г. Кострома, ул. Ленина, 20 Ivan.Bobrov@exactpro.com 2 Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA Alexey.Zverev@exactpro.com Aннотация. При работе систем высокочастотного трейдинга в состоянии максимальной нагрузки количество изменений котировок может достигать нескольких тысяч в секунду. Для слежения за рынком на экранах терминалов применяются специальные графические средства, реализованные в виде программного обеспечения. Тестирование такого программного обеспечения представляет собой специфическую задачу. В статье рассматривается метод проверки функциональности графического интерфейса трейдинговых систем. Для тестирования предлагается сохранять графическое представление областей интерфейса в момент их перерисовки операционной системой. Полученные таким образом данные в оцифрованном виде сравниваются с данными, полученными из независимого источника котировок. В статье описывается реализация предложенного метода и анализируются результаты с точки зрения применимости в условиях реальной торговли. 1 Введение В последние годы высокочастотная торговля занимает большую часть торгов на соответствующих электронных площадках. По данным РТС в 2010 году на долю торговых роботов в обороте на срочном рынке РТС FORBS приходилось примерно 50%, а их доля в общем количестве заявок в определенные моменты достигала 90% [1]. Системы, ориентированные на высокочастотную торговлю, многокомпоненты и строятся из расчёта максимальной отдачи и надежности. Основными компонентами, напрямую используемыми пользователями, являются торговые терминалы и шлюзы, находящиеся под управлением специализированных протоколов, таких как FIX, NATIVE [2]. За информацию, на базе которой эти компоненты формируют представление о рынке, отвечает компонент, являющийся важной составляющей любой торговой платформы и 264 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 265. отвечающий за поставкукотировок [3]. Поставщик котировок предоставляет котировки и другую финансовую информацию в режиме реального времени, что позволяет получателям обрабатывать и представлять её конечному пользователю в том или ином виде. 2 Торговый терминал и шлюз Торговый терминал – это программное обеспечение, позволяющее трейдеру в режиме реального времени получать всю необходимую информацию о ходе торгов на мировых биржевых и внебиржевых рынках, а также анализировать полученные данные посредством встроенных в торговый терминал инструментов и делать выводы, на основе которых совершать торговые сделки. [4]. Основным отличием торгового терминала является графическая оболочка, посредством которой происходит отображение данных на экран. В случае с подключением через шлюз, все данные, как правило, передаются в формате протокола, по которому совершено подключение (см. рисунок 1). В итоге сам торговый терминал может быть подключен непосредственно через подобный протокол к рынку. И шлюз и терминал, получают данные, основанные на потоке, распространяемом компонентом поставщика котировок. В случае со шлюзом пользователь самостоятельно производит расшифровку полученного пакета данных, а в терминале вся информация представляется в удобочитаемом виде. На сегодняшний день количество заявок, обрабатываемых биржей, в течение торговой сессии исчисляется миллионами. Особенностью же HFT логики является высокоскоростной обмен сообщениями с рынком в зависимости от модели торгового робота. В ходе эволюции средств связи и коммуникации скорость обработки запросов значительно возросла, а время ответа системы на запрос стало исчисляться в микросекундах [5]. Таким образом, в момент максимальной нагрузки рынка торговый терминал получает информацию со скоростью, с которой вывод на экран сделает невозможным попытки визуально отследить все изменения, происходящие в окне клиента, вследствие чего пользователь не сможет дать адекватную оценку корректности отображаемой информации. При приёме данных через шлюз весь поток информации будет сохранен в виде сообщений, полученных в рамках установленной сессии и доступных для анализа, что позволяет выполнить их проверку на соответствие спецификации без каких-либо серьёзных потерь и в любой удобный для этого момент времени. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 265
- 266. Рис. 1. Примерграфического интерфейса трейдингового терминала. 3 Симуляция нагрузки Для тестирования системы в состоянии высокочастотного трейдинга в первую очередь необходимо создать условия, совпадающие с представлениями о высокой нагрузке. Для создания подобных условий может быть использован инструмент «Генератор нагрузки» (англ. LoadInjector), разработанный компанией Exactpro Systems LLC. Инструмент позволяет согласно сконфигурированному сценарию создавать и поддерживать продолжительную отправку и приём большого количества сообщений, доводя таким образом торговую систему до необходимого уровня нагрузки. Объектом тестирования выступает графическая оболочка торгового клиента, из которой необходимо получить поток данных для анализа. В качестве эталона для сравнения в ходе анализа может быть использован шлюз, подписка через который на мониторинг отправки котировок позволит получить достаточно надёжную картину происходящего на протяжении всего периода теста. Для этого организуется подключение по протоколу шлюза с последующей подпиской на необходимые обновления, которые будут сохранены в виде набора сообщений в формате используемого протокола обмена данными. Тесты проводились при помощи симуляции исторической маркет даты, доступной для общего доступа на сайте histdata.com, воспроизводимой с различной скоростью. 4 Запись данных из графического интерфейса Требуется сохранить аналогичный поток изменений в окне торгового терминала. Для осуществления этого есть несколько возможных способов. Первый способ - запись области экрана в видеофайл посредством специальных утилит, таких как CamStudio [6], c последующей обработкой и 266 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 267. конвертацией в наборизображений, отражающих блок, относящийся к содержимому книги заявок. В этом случае потребуется дополнительно декодировать данные из полученных изображений, представив их в виде буквенно-числового представления содержимого каждой стороны книги заявок для возможности сравнения. Также ввиду ограничений скорости работы подобных программ и записи видео с конечной картинки экрана есть риск потери достаточно большого количества изменений. Программа снимает изображение непосредственно с экранной картинки, в то время как драйвер видеоустройства может послать гораздо большее количество кадров, которые в ходе наложения могут перекрыть изменения, произошедшие в предыдущем кадре. Таким образом, при записи видео со скоростью 200 кадров в секунду весь выход за пределы такой скорости со стороны видеодрайвера ведёт к потере потенциально пригодных для анализа данных. Второй способ – это прямой доступ к объектам формы терминала. Для этого средствами операционной системы потребуется установить, какие объекты расположены в окне, как они упорядочены, какой имеют тип и какие параметры этих объектов позволят прочитать их текущее состояние и содержимое. Так с установленным интервалом можно будет считывать состояние нужных компонентов, а также сохранять состояния книги. Существенным минусом данного способа будет высокая нагрузка на процессор компьютера, на котором будет расположена такая программа и терминал, в результате чего снизится производительность самого терминала, что делает тест отдаленным от реальных условий. Третьим способом является перехват всех попыток изменить внешнее представление окна терминала самой операционной системой. Таким образом мы сможем гарантировать, что все попытки перерисовки будут сохранены, а на выходе будет массив изображений, доступный для анализа и конвертирования в читаемый набор данных. Суммируя все вышесказанное, мы видим, что первый способ наименее интересен ввиду присутствия риска потери данных, что не позволит сделать объективными результаты анализа. Второй способ весьма специфичен и может быть использован лишь в ограниченном наборе графических интерфейсов, и в виду того, что каждый из них может быть реализован по-разному и на разных платформах, возникает необходимость индивидуального подхода и индивидуального алгоритма. Также риск сокращения производительности самого приложения торгового терминала ввиду параллельной работы достаточно сложной реализации по считыванию изменяемых данных, делает недопустимым использование такого метода в текущем исследовании. Наиболее эффективным остается метод с перехватом действий перерисовки, так как он практически исключает потери и будет работать по менее воздействующему на терминал алгоритму. Однако это, в свою очередь, потребует максимально быстродействующего накопителя, так как в ходе теста все изменения должны быть записаны в графические файлы типа BITMAP. Сжатие исключается с целью снизить затраты центрального процессора и минимизировать потери ресурсов. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 267
- 268. На данном этапеалгоритм применим для большинства торговых клиентов, содержимое книжки которых отражается на экране терминала. Однако стоит учитывать, что реализация отображения не одинакова в разных клиентах. Объект тестирования и реализованный алгоритм узко специализированны относительно объекта тестирования и для применения алгоритма против другого клиента он потребует переработки в зависимости от того как будет представлена информация на экране терминала. Таким образом основных изменений потребует часть преобразования снятой графической информации. 5 Microsoft Detours В качестве инструмента для реализации выбранного метода, используется библиотека Microsoft Detours [7]. Данная библиотека позволяет устанавливать перехватчики стандартных событий системы и использовать собственную процедуру, предваряющую дальнейшее выполнение (Рисунок 2.). В случае с торговым терминалом, перехватчик устанавливается на событие перерисовки любого графического элемента экранной формы торгового терминала. Процедура сохраняет графическое представление переданной области, которая будет изменена, в виде файла, в имени которого сохраняется идентификатор окна, штамп даты и времени, а также координаты, по которым происходит перерисовка. На основании полученного набора файлов делается выборка по зонам, в которых отображается информация. Особенностью различных графических интерфейсов трейдинговых терминалов является их способность одновременно показывать ситуацию сразу по нескольким торговым инструментам в отдельно открытых окнах или наоборот - показывать лишь один инструмент строго в одном окне интерфейса. Для записи в таком случае может быть использовано как одно окно одного инструмента, так и весь набор окон с привязанными к ним инструментами. Следующим шагом является преобразование графического представления в читаемый массив значений. На основании полученных значений, а также значений из подписки к шлюзу, строятся два набора книжек [8] с определенным шагом времени (t). Во внимание принимается максимальное количество заявок, отображаемых в торговом терминале. 268 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 269. Рис. 2. Схемаработы перехватчика из библиотеки Microsoft Detours. 6 Сравнение данных Полученные наборы состояний сравниваются между собой и оценивается разница между ними. Набор данных от шлюза: GW() = GW(t1),GW(t2),GW(t3),...,GW(tN) (1) Набор данных от графического интерфейса: SC() = SC(t1),SC(t2),SC(t3),...,SC(tN) (2) Необходимо учесть, что количество данных на единицу времени со стороны шлюза допустимо больше, чем со стороны графического интерфейса, ввиду того, что графический адаптер не способен отразить все изменения книжки, если они превышают его характеристики по записи в видеопамять в момент времени t. Сравнение происходит по двум признакам: полное попадание и полное непопадание. Для каждого случая производится подсчёт разницы во времени между найденными соответствиями. Нарушение порядка даже заявок на книжке принимается как полное несоответствие книжек. Таким образом, на выходе получаем график, подобный представленному на рисунке 3. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 269
- 270. Рис. 3. Примерграфика совпадений книжек на одной минуте теста. График позволяет оценить динамику временной разницы между соответствиями книжек от эталонного источника и графического интерфейса, а также оценить потери и корректность отображаемой информации. На основании такой оценки при детальном рассмотрении конкретных приложений можно модифицировать алгоритмы нагрузочного сценария, что даст возможность усилить обнаруженные негативные эффекты, будь то несовпадение книжек или серьёзная разница во времени между соответствиями. Принимается во внимание, что основная фаза тестирования происходит на основании предзаписанного сценария нагрузки, который может быть заменен сконфигурированным тестом, в котором будут учтены типы сообщений и их частота на проблемных участках анализа. На графике отражена зависимость отставания книжки, отраженной в трейдинговом терминале, от информации, полученной через предоставляющий информацию о котировках (market data) шлюз. По оси абсцисс откладывается время наблюдения в секунду, а по оси ординат - задержка в миллисекундах между временем котировки и временем получения соответствующей книжки в трейдинговом терминале. При помощи искусственных точек с задержкой 1000 мс, мы отметили на этом графике точки полного непопадания. По кривой с попаданием мы можем анализировать задержки между получением событий через электронные интерфейсы и отрисовкой их в пользовательском интерфейсе. Эта важная информация позволяет конечным пользователям оценивать актуальность и своевременность информации, отражаемой на экране. График с непопаданием показывают, насколько часто графический интерфейс отражает книжку, полностью не соответствующую реальности. Анализ этих графиков лучше проводить, рассматривая плотность точек на графике непопадания. Например, если непопадания встречаются редко и длительность непопадания ограничена, это означает, что, если сразу после непопадания имеется попадание, то, с точки зрения конечного пользователя, искаженная книжка будет незаметна, поскольку в течение 270 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 271. короткого интервала онабудет перерисована другой, правильной, книжкой. Однако, с другой стороны, если плотность непопаданий велика, то возрастает вероятность того, что пользователь увидит некорректную книжку, и такое поведение следует считать существенным дефектом пользовательского интерфейса. На основе предложенного подхода (Рисунок 4) был разработан инструмент, позволяющий перехватывать все изменения графического интерфейса, а также дополнительные инструменты для распознавания графических данных, построения книг заявок и сравнения двух наборов книг между собой [9]. Рис. 4. Графическая схема метода, разработанного на базе библиотеки Microsoft Detours 7 Заключение В данной статье мы показали, что имеется техническая возможность валидации активного потока котировок, демонстрируемого пользователю через элементы графического интерфейса. Мы разработали инструменты, реализующие представленную методику снятия данных. В результате построенный набор инструментов позволяет эффективно анализировать графическую выдачу и сравнивать её с независимым цифровым потоком, а также вычислять задержки и потенциальные несовпадения двух потоков. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 271
- 272. Источники 1. Slon.ru -Деловые новости и блоги // [Электронный ресурс]. – Режим доступа http://slon.ru/economics/lyudi_luchshe_robotov-970172.xhtml 2. Официальный сайт FIXprotocol // [Электронный ресурс] - Режим доступа http://www.fixprotocol.org/ 3. Wikipedia // [Электронный ресурс]. - Режим доступа http://en.wikipedia.org/wiki/Market_data 4. Форекс журнал для трейдеров // [Электронный ресурс]. - http://fortrader.ru/forex-terminals/ 5. Leo King.: London Stock Exchange smashes world record treade speed with Linux. / Coputerworld UK // [Электронный ресурс]. http://www.computerworlduk.com/news/networking/3244936/london-stock-exchangesmashes-world-record-trade-speed-with-linux/ 6. Официальный сайт CamStudio // [Электронный ресурс]. - Режим доступа http://camstudio.org 7. Dejan Lukan.: API Hooking with Microsoft Detours / INFOSEC Institute Resources // [Электронный ресурс]. - Режим доступа http://resources.infosecinstitute.com/api-hooking-detours/ 8. Wikipedia // [Электронный ресурс]. - Режим доступа http://en.wikipedia.org/wiki/Order_book_%28trading%29 9. Zverev,A., Bobrov,I, Pryadkina,N..: Testing of HFT GUI. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3-exactpro-testingofhftgui-12944204 272 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 273. Динамический поиск гонокв Java-программах на основе синхронизационных контрактов Дмитрий Цителов (tsitelov@acm.org), Devexperts LLC Виталий Трифанов (vitaly.trifanov@gmail.com), СПбГУ Аннотация. Состояние гонки (data race) возникает в многопоточной программе, когда несколько потоков одновременно обращаются к одному и тому же разделяемому участку памяти, где хотя бы одно обращение – запись. Состояния гонки слабо локализованы и их сложно обнаружить вручную, поэтому исследования в области автоматического поиска гонок ведутся уже более 20 лет. В данной статье рассматриваются вопросы производительности и точности динамического поиска гонок в Javaпрограммах и предлагается идея снижения накладных расходов обнаружения с помощью синхронизационных контрактов. Последние опираются на описания пар вызовов методов, обеспечивающих синхронизацию потоков, и помогают исключать из анализа части целевого приложения, не интересные с точки зрения поиска гонок – например, сторонние библиотеки. Приводится схема языка спецификации контрактов и некоторые технические детали реализации, рассматриваются преимущества и ограничения подхода. Ключевые слова: многопоточность, состояние гонки, динамический анализ, автоматическое обнаружение ошибок. 1 Введение С развитием многоядерных и многопроцессорных систем все большее количество программ создаются многопоточными. Использование нескольких потоков выполнения может приводить к дополнительным ошибкам, связанным с некорректной организацией взаимодействия этих потоков. Такие ошибки сложно искать вручную, поскольку чередование операций в потоках обладает высокой степенью неопределённости, и программисту нужно полностью просчитать все возможные ситуации. Одной из типичных ошибок многопоточных программ является наличие в них состояний гонки (data races). Они возникают, когда несколько потоков без должной синхронизации обращаются к одному и тому же разделяемому участку памяти, где хотя бы одно обращение – запись [14]. Дополнительная трудность с обнаружением гонок состоит в том, что они, как правило, не приводят к немедленному сбою и отказу программы. Напротив, приложение продолжает работать с Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 273
- 274. повреждёнными глобальными структурамиданных, что приводит к труднообъяснимым эффектам впоследствии. За несколько последних десятков лет было разработано несколько статических и динамических подходов к обнаружению гонок. Статические детекторы ([7,11,13]) анализируют все пути исполнения программы, не требуют её запуска, но обладают низкой точностью. Динамические ([3,4,6,8,15,16,17,18]) анализируют программу во время её работы, но ограничены лишь фактическим путём выполнения программы. Хотя динамические алгоритмы и обладают полной информацией о конкретном пути выполнения программы, на практике их точность ограничена накладными расходами, которые они вносят. Проблема достижения высокой точности обнаружения гонок и отсутствия ложных срабатываний (false positives) при сохранении приемлемого уровня потребления аппаратных ресурсов является краеугольной технической проблемой динамического анализа. Данная работа предлагает способ понижения накладных расходов на динамическое обнаружение гонок в Java-программах без потери точности. Основная идея заключается в сокращении области программы, где отслеживаются все операции синхронизации. Чтобы это не привело к потере информации о синхронизации между потоками и, как следствие, к ложным срабатываниям, вводится понятие синхронизационного контракта, которое позволяет в достаточной степени описать поведение исключённого кода в многопоточной среде. Далее во время работы детектор распознает эти контракты и встретив методы, соответствующие им, обрабатывает эти методы как высокоуровневые синхронизационные события. Такой подход позволяет восполнить неотслеженные операции синхронизации и обеспечить высокую точность поиска. Дальнейшая часть статьи организована следующим образом. Во второй главе описывается отношение happens-before и приводится формальное определение понятия гонки в терминах спецификации Java, после чего описывается точный алгоритм поиска гонок, основанный на отслеживании этого отношения. Третья глава акцентируется на проблеме обеспечения одновременно точности динамического поиска гонок и приемлемого уровня накладных расходов. В четвертой главе излагается концепция синхронизационных контрактов, в пятой главе – её реализация в разработанном нами динамическом детекторе гонок jDRD. Шестая глава посвящена преимуществам и недостаткам подхода и содержит некоторые экспериментальные результаты. В заключении мы подводим итог и указываем дальнейшие возможные направления работы. В приложении описан язык описания контрактов, используемый в jDRD. 2 Happens-before алгоритм поиска гонок Отношение happens-before было предложено Лесли Лампортом в работе [10] для установления частичного порядка на множестве всех событий распределенной системы, в которой единственный способ взаимодействия 274 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 275. между участниками –это обмен сообщениями. Данный подход хорошо переносится на многопоточные системы, если рассматривать каждый поток как отдельного участника системы, а операции синхронизации – как передачу сообщений. Язык программирования Java был одним из первых языков с собственной архитектурно-независимой моделью памяти, определяющей семантику взаимодействия потоков через отношение happens-before, и распространяющей это отношение на все операции в программе. Для этого в спецификации Java [9] сначала вводится отношение синхронизированности (synchronized-with) – полное отношение порядка на множестве всех операций синхронизации в программе. Так, освобождение монитора синхронизировано с его последующими захватами; запись volatile-переменной синхронизирована с ее последующими чтениями; запуск потока синхронизирован с первым действием в потоке; последнее действие в потоке T1 синхронизировано с любым действием в другом потоке, случившемся после того, как тот обнаружил, что T1 завершился; прерывание потока T1 синхронизировано с любым действием в другом потоке, которое обнаружит, что T1 получил сигнал прерывания. События слева (например, захват монитора) будем называть отправкой, а справа (отпускание монитора) – приёмом синхронизационного сообщения. Обратим внимание, что во всех случаях с синхронизационным сообщением естественным образом ассоциирован уникальный объект – монитор, volatileпеременная или объект потока. Поэтому далее будем считать, что с каждой парой синхронизированных событий связан некий уникальный синхронизационный объект. Объединение отношения синхронизированности с естественным темпоральным отношением порядка в рамках операций одного потока даёт частичное отношение порядка – отношение предшествования (happens-before), определённое уже на множестве всех операций в программе. Факт «событие х произошло перед событием y» записывается как hb(x,y). Само отношение определяется следующим образом: если x и y – операции в одном потоке, и x произошло раньше y, то hb(x,y); завершение конструктора объекта предшествует запуску его финализатора; если события x и y синхронизированы, то hb(x,y); транзитивность: если hb(x,y) и hb(y,z), то hb(x,z). Отслеживание отношения happens-before позволяет определить, получил ли некоторый поток информацию о действиях другого потока – например, изменения в разделяемой памяти, новые значения переменных и т.д. Наконец, спецификация Java формально определяет понятие гонки: два обращения x и y к разделяемой переменной из различных потоков, хотя бы одно из которых – запись, образуют гонку, если ни одно из них не предшествует другому: Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 275
- 276. DR(x,y) !hb(x,y) ˄!hb(y,x). Таким образом, для точного обнаружения гонок в программе достаточно отслеживать конфликтующие обращения различных потоков к разделяемым переменным, не упорядоченные отношением happens-before. Для этого традиционно используются векторные часы (vector clock)1, предложенные в работе [12]. Векторные часы представляют собой динамический массив неотрицательных чисел, равный по размеру количеству потоков в программе. Над векторными часами определена операция слияния: merge(V1, V2): for each i ∈ [1..n] V1[i] := max(V1[i], V2[i]) Каждый поток хранит свои векторные часы, отражающие его знания о системе: i-я компонента его часов равна последней компоненте i-го потока, которые он наблюдал2. Компонента, соответствующая ему самому, называется собственной компонентой. Изначально собственная компонента часов потока проинициализирована единицей, а остальные – нулями. Перед каждой операцией синхронизации x в потоке T1, собственная компонента часов потока T1 увеличивается на единицу, а часы загружаются в часы соответствующего синхронизационного объекта. Когда в другом потоке T2 происходит событие y, такое что x синхронизированно с y, в часы потока T 2 загружаются часы синхронизационного объекта. Это позволяет отследить отношение synchronizedwith. Для отслеживания отношения happens-before нужно проассоциировать векторные часы с каждой разделяемой переменной в программе. Когда поток T 1 обращается к такой переменной, он покомпонентно сравнивает свои часы с часами переменной. Если есть компонента часов потока, которая не превосходит соответствующей компоненты часов переменной, обнаружена гонка. Далее поток загружает свои часы в часы переменной. Если в программе N потоков, то хранение одних векторных часов требует O(N) памяти, и основные операции над ними также имеют сложность O(N). В работе [8] показано, что для отслеживания отношения happens-before вместо полных часов переменной достаточно хранить номер и собственную компоненту потока, который последним обращался к этой переменной. Таким образом, значительная часть операций будет требовать O(1) и снизится количество потребляемой памяти, что позволило алгоритму happens-before достичь уровня производительности менее точных динамических алгоритмов. 3 Точность поиска и накладные расходы К сожалению, точечные оптимизации алгоритма, хотя и производят безусловный положительный эффект (что подтверждает множество исследований), не могут обеспечить приемлемый уровень накладных расходов 1 2 276 Эквивалентное название – логические часы (logical clocks). Не умаляя общности, предполагается, что все потоки пронумерованы от 1 до n. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 277. на приложениях, состоящиххотя бы из нескольких тысяч классов и использующих 10-20 потоков.3 Подавляющее большинство исследовательских работ останавливается на прототипе детектора и модельном тестировании. Подробный обзор состояния предметной области можно найти в работах [1,2]. Нам удалось обнаружить лишь два готовых к использованию детектора (IBM MSDK[16] и TSan[18]), но попытки использовать их на крупных приложениях приводили либо к немедленному отказу, либо к переполнению памяти. О схожих проблемах сообщают также авторы работы [15]. Для обеспечения точности поиска нужно отслеживать все операции обращения к разделяемым данным и все операции синхронизации. Первые можно ограничить путём отсечения областей кода, в которых нас не интересуют гонки – например, сторонние библиотеки или стандартные Java-классы. Для большинства разрабатываемых программных систем решения об использовании сторонних компонент принимаются на стадии проектирования, когда уже известны требования по надежности и безотказности системы, поэтому есть смысл считать, что сторонние компоненты обладают достаточной степенью надежности и концентрироваться на обнаружении ошибок в непосредственно разрабатываемом программном коде и проверке корректности использования сторонних компонент. Однако исключить таким же образом операции синхронизации нельзя, поскольку их пропуск приведет к неполучению информации о передаче отношения happens-before и, как следствие, к ложным срабатываниям, – детектор будет сигнализировать о гонках, которых в действительности не произошло. Количество этих операций велико и экспоненциально растёт с увеличением количества потоков в программе, что в совокупности с необходимостью отслеживать операции обращения к разделяемым данным в итоге и приводит к описанным эффектам. 4 Синхронизационные контракты Принцип инкапсуляции в объектно-ориентированном подходе к программированию, которому следует Java, предполагает, что использование объекта осуществляется посредством вызова его публичных методов. Поэтому, в идеале, достаточно иметь возможность описать правила использования методов исключённых классов в многопоточной среде. Возможны следующие варианты: метод не потокобезопасен, то есть его одновременное использование несколькими потоками не предусмотрено и требует внешней синхронизации; метод потокобезопасен; он может быть вызван (и в некотором смысле предназначен для этого) несколькими потоками одновременно без внешней синхронизации. 3 Обратим внимание, что характеристики многих промышленных программных систем могут в десятки и тысячи раз превосходить указанные. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 277
- 278. Вызовы методов первоготипа необходимо отслеживать и обрабатывать по алгоритму happens-before как обращения к объекту-владельцу метода на чтение, если метод немодифицирующий, или на запись в противном случае. Разработанный нами детектор jDRD трактует по умолчанию все обращения как модифицирующие и предоставляет возможность на уровне конфигурации указать, что некоторые конкретные методы являются немодифицирующими. С вызовами методов второго типа немного сложней. Вообще говоря, их можно игнорировать, поскольку они предназначены для многопоточного использования. Однако именно в эту группу методов попадают те, которые обеспечивают синхронизацию между потоками. Как правило, такие методы содержатся в классах, созданных как средство обеспечения корректного взаимодействия потоков, что чётко декларировано в их описании. Так, начиная с версии 1.5 в Java появились высокоуровневые средства синхронизации, отличные от захватов/блокировок мониторов и volatile-переменных. В основном они содержатся в пакете java.util.concurrent и его подпакетах. Например, там есть потокобезопасная хеш-таблица ConcurrentHashMap, которая гарантирует, что вызов метода put по некоторому ключу предшествует последующему вызову метода get на том же объекте по тому же ключу [5]. Более формально, это означает, что между событиями вызова метода put в первом потоке и метода get во втором потоке есть цепочка событий, через которые передается отношение happens-before. Если детектор отслеживает все операции синхронизации, то он обнаружит эту цепочку и вычислит, что эти два вызова методов также упорядочены отношением happens-before. Теперь предположим, что мы хотим исключить класс ConcurrentHashMap из области анализа – то есть, не отслеживать в нем операции синхронизации. В этом случае детектор не получит информации о том, что вызов put предшествует вызову get. Таким образом, ему её нужно явно сообщить. Отметим, что для этого не подходят аннотации, поскольку в случае библиотечных классов нет возможности модифицировать исходный код. Нами был разработан метод конфигурирования на базе языка xml. Рассмотрим два метода: метод f(P 11, … P1n) объекта O1 и метод g(P21, …, P2m) объекта O2, где n,m ≥ 0. Объект O1 будем называть объектом-владельцем метода f, а O2 – объектом-владельцем метода g. Между этими методами может быть примитивная явная связь одного из трёх типов: 1. связь «владелец-владелец»: O1 == O2, то есть методы принадлежат одному объекту; 2. связь «владелец-параметр»: n 0, ∃i ∈ [1..n]: O2 == P1i или m 0,∃j ∈ [1..m]: O1 == P2j, то есть параметр одного метода является объектом-владельцем другого метода; 3. связь «параметр-параметр»: n,m 0, ∃i ∈ [1..n], j ∈ [1..m]: P1i == P2j, то есть i-й параметр метода f и j-й параметр метода g являются одним и тем же объектом. Будем называть явной связью комбинацию любого количества примитивных связей. 278 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 279. Будем называть синхронизационнымконтрактом описание пары явно связанных методов, которые, будучи вызванными в определённом порядке, гарантируют синхронизацию потоков. Рассмотрим пример с классом ConcurrentHashMap. Синхронизационный контракт на методы put и get – это явная связь, образованная из связей первого (речь идёт о методах одной и той же map) и третьего (должен быть один и тот же ключ – первый параметр каждого метода) типа. Описание этого контракта на языке конфигурирования jDRD представлено ниже. Подробное описание языка см. в приложении. Sync Links Link send=owner receive=owner/ Link send=param send-number=0 receive=param receivenumber=0/ /Links Send MethodCall owner=java.util.concurrent.ConcurrentMap name=put descriptor=(Ljava/lang/Object;Ljava/lang/Object;) Ljava/lang/Object;/ /Send Receive MethodCall owner=java.util.concurrent.ConcurrentMap name=get descriptor=(Ljava/lang/Object;)Ljava/lang/Object;/ /Receive /Sync Рис. 1. Пример синхронизационного контракта. В качестве примера примитивной связи второго типа можно привести контракт метода execute класса Executor, обеспечивающий асинхронное выполнение задачи. Он принимает в качестве параметра объект типа Runnable и впоследствии вызывает его метод run в другом потоке. Спецификация метода execute гарантирует, что его вызов предшествует последующему вызову метода run объекта, переданного в метод execute в качестве параметра. В следующем разделе мы представим наш детектор jDRD и реализацию синхронизационных контрактов в нём. 5 Реализация Для отслеживания различных операций в программе необходимо внедриться в ход её выполнения и перехватывать обращения к методам, переменным и т.д. В Java это традиционно реализуется на уровне байт-кода. Это удобно, поскольку он хорошо структурирован и вместе с тем достаточно просто организован. Кроме того, в отличие от исходного кода, байт-код классов доступен всегда. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 279
- 280. JVM (виртуальная машинаJava) позволяет подключить к ней компоненту, реализующую особый интерфейс java-aгента, который будет получать управление перед загрузкой очередного нового класса. Агенту передаётся массив байт, содержащий байт-код загружаемого класса, который агент может трансформировать. В jDRD реализован этот интерфейс в отдельной компоненте. jDRD-агент анализирует байт-код загружаемых классов с помощью библиотеки ASM, находит интересующие инструкции (захват/освобождение монитора, обращение к разделяемой переменной, запуск потока и т.д.) и вставляет после них соответствующие внутренние вызовы детектора. Таким образом jDRD получает информацию об операциях синхронизации и обращениях к разделяемым данным в программе. Далее он обрабатывает их по алгоритму happens-before. Остановимся подробней на обработке операций синхронизации. Когда jDRD встречает событие отправки синхронизационного сообщения, он должен увеличить собственную компоненту часов потока на единицу. После этого ему нужно сохранить свои часы так, чтобы они были доступны другому потоку, в котором произойдет соответствующее событие приёма синхронизационного сообщения. Как отмечалось выше, с каждым синхронизационным событием можно связать уникальный синхронизационный объект. jDRD пользуется этим фактом, и сохраняет часы потоков в хеш-таблице, ключами в которой являются те самые синхронизационные объекты. Для события освобождения монитора таким ключом будет ссылка на объект-владелец монитора, а для volatileпеременной – пара (название переменной, объект-владелец переменной). 4 Перейдем к отслеживанию синхронизационных контрактов. Их нужно трактовать как высокоуровневые операции синхронизации и ассоциировать с этими операциями искусственный синхронизационный объект. Поскольку описание контрактов содержится в отдельном xml-файле, они читаются и анализируются после запуска детектора. Далее для каждого контракта динамически генерируется класс, сущности которого впоследствии будут использоваться как синхронизационные объекты для данного контракта. Например, для контракта с рис. 1 будет создан следующий класс: class CompositeKey1 { Object o1; //для примитивной связи владелец-владелец Object o2; //для примитивной связи параметр-параметр } Когда jDRD встретит вызов метода ConcurrentMap.put, он обнаружит, что этот метод является частью синхронизационного контракта. В этот контракт входят две примитивные связи, каждая из которых опирается на Object. jDRD отыщет соответствующий класс-ключ (в данном случае это класс CompositeKey1) и 4 280 Для предотвращения утечек памяти в хеш-таблице используются не обычные (сильные, strong reference) ссылки на ключи, а слабые (weak reference). Ключевое свойство последних заключается в том, что если на объект остаются только слабые ссылки, то он может быть удалён сборщиком мусора. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 281. создаст новый объектэтого типа, который и будет синхронизационным объектом для данного исполнения контракта. Далее часы потока будут увеличены на единицу и записаны в хеш-таблицу. После этого jDRD перестаёт отслеживать операции синхронизации до того момента, когда метод put завершится. Чтобы распространить информацию о том, что отслеживание операций синхронизации в данном потоке стоит приостановить, в векторных часах потока есть переменная-флаг, которая выставляется в true, когда поток входит внутрь контрактного метода и сбрасывается обратно в false при выходе из него. Если контрактный метод вызывается с уже установленным флагом, то флаг оставляется без изменений. Таким образом, сохраняется возможность корректной работы с контрактами различного уровня, часть из которых может быть использована при реализации других. При перехвате любой операции синхронизации jDRD в первую очередь проверяет состояние флага, и если оно равно true, он просто игнорирует эту операцию. 6 Преимущества и ограничения подхода Алгоритм обнаружения гонок, применяемый в jDRD, базируется на учёте всех отношений happens-before для выяснения корректности производимой операции доступа к данным. Поскольку отношения happens-before при выполнении операций синхронизации, заданные моделью памяти Java, «тотальны» (устанавливают отношение со всеми операциями, предшествующими точке синхронизации), любое событие синхронизации в коде программы имеет неограниченное воздействие на все отслеживаемые переменные и взаимодействующие потоки. Задача детектора в идеальном случае – проверить корректность исполняемого кода только с учётом явно обозначенных контрактов используемых библиотек. Построение отношения happens-before с учётом всех произошедших операций синхронизации для кода, контракт которого не задаёт явных условий синхронизации, может привести к тому, что код, который с формальной точки зрения недостаточно синхронизирован, будет считаться корректным при рассмотрении всех промежуточных операций. Например, вызов стандартного java-метода System.out.err.print (используется вывода сообщения об ошибке) содержит внутри себя критическую секцию. Если два потока вызывают этото метод поочередно, они синхронизируются между собой, но это является деталью реализации этого метода, побочным эффектом, а не декларированным свойством. Подобные синхронизационные события не только не представляют интереса, но и создают дополнительный «шум», затрудняющий обнаружение гонок. Таким образом, производимые на основе описанных контрактов изъятия промежуточных синхронизационных событий позволяют не только уменьшить общий объём работы анализатора, но и увеличить вероятность обнаружения гонок в некорректно синхронизированном коде, т.е. повышают точность метода. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 281
- 282. Это подтверждается нашимилабораторными экспериментами, которые проводились на трёх приложениях: JTT – пользовательское клиентское приложение к системе отслеживания ошибок – порядка 400 классов, 10 потоков; QDTest – нагрузочный тест системы распространения котировок – 700 классов, 15 потоков; MARS – крупная многоцелевая мониторинговая система – 2000 классов, 30 потоков. Мы запускали детектор jDRD на нескольких приложениях в двух режимах: базовый режим – отслеживание операций синхронизации во всём коде программы без использования каких-либо синхронизационных контрактов; juc-режим – описаны контракты для всех классов пакета java.util.concurrent и для класса sun.misc.Unsafe. Краткие результаты этих запусков представлены в таблице 1, из которой видно, что использование контрактов снизило количество хранимых векторных часов и количество обрабатываемых операций синхронизации. Это, в свою очередь, снизило нагрузку на приложение и позволило обнаружить больше гонок. Все гонки, обнаруженные в базовом режиме, были также обнаружены и в jucрежиме, что свидетельствует о повышении точности поиска гонок. Режим Синхр. оп-ий/сек Кол-во часов JTT juc базовый 115К 28К 13К 7К QDTest базовый juc 7400К 4300К 85К 72К MARS базовый juc 1650K 800K 15K 14K Найдено гонок 8 1 3 10 5 7 Таблица 1. Количество обрабатываемых синхронизационных операций в секунду и количество хранимых векторных часов в различных режимах работы jDRD. C другой стороны, подход обладает рядом ограничений. Во-первых, с помощью предложенных синхронизационных контрактов возможно описание лишь явно связанных методов. Можно представить себе и неявную связь, но это скорее исключение, чем правило. В пакете java.util.concurrent есть несколько таких методов, например метод newCondition объекта типа Lock. Этот метод возвращает объект типа Condition, внутренне связанный с исходным объектом типа Lock. В этом случае детектор просто «шагнет» внутрь этих классов и будет продолжать анализ. Во-вторых, jDRD трактует методы, являющиеся частью синхронизационных контрактов, как атомарные, в то время как они таковыми не являются. Операция в программе, которая непосредственно обеспечивает синхронизацию потоков, обычно находится где-то внутри метода и может быть существенно отделена по времени от точек входа и выхода из него. Следовательно, на момент завершения 282 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 283. работы метода информацияможет быть устаревшей, что может привести к ложным срабатываниям. 7 Заключение Одной из принципиальных проблем динамического анализа программ является обеспечение сочетания точности и глубины анализа и приемлемого уровня накладных расходов. В задаче автоматического поиска гонок эта проблема особенно актуальна, поскольку количество операций синхронизации и обращений к разделяемым данным очень велико. Если область программы, в которой необходимо отслеживать обращения к разделяемым переменным является скорее вопросом конфигурации и выделения наиболее «интересных» и опасных участков кода, то операции синхронизации нужно отслеживать во всем коде программы, чтобы не пропустить информацию о синхронизации потоков. В данной работе мы предлагаем концепцию синхронизационных контрактов, в основе которой лежит идея отслеживания не всех операций синхронизации, происходящих в программе, а лишь явно декларированных. Мы вводим понятие синхронизационного контракта как пары явно связанных методов и предлагаем язык для их описания, основанный на xml-нотации. Поддержка и корректная обработка описанных таким образом контрактов была реализована нами в детекторе jDRD, который посредством трансформирования байт-кода внедряется в java-программу, отслеживает в ней важные события (в том числе и методы, описанные в контрактах) и обрабатывает их по алгоритму happensbefore. Лабораторное тестирование показывает эффективность использования контрактов – сокращается как количество обрабатываемых операций синхронизации, так и количество векторных часов, которые необходимо хранить для отслеживания отношения happens-before. Подход обладает рядом ограничений, над устранением которых мы планируем продолжить работу. Также мы проводим внедрение jDRD в процесс разработки ПО и промышленную апробацию, результаты которой надеемся опубликовать в дальнейшем. Список литературы 1. Трифанов В.Ю., Цителов Д.И. Динамические средства обнаружения гонок в параллельных программах. Компьютерные инструменты в образовании, №5, 2011. С. 3-15. 2. Трифанов В.Ю., Цителов Д.И. Статические и post-mortem средства обнаружения гонок в параллельных программах. Компьютерные инструменты в образовании, №6, 2011. С. 3-13. 3. Choi J., Lee K., Loginov A., O’Callahan R., Sarkar V., Sridharan M. Efficient and precise datarace detection for multithreaded object-oriented programs. In Proceedings of the ACM SIGPLAN 2002 Conference on Programming language design and implementation, 2002. P. 258–269. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 283
- 284. 4. Christiaens M.,Brosschere K. TRaDe: A topological approach to on-the-fly race detection in Java programs. In Proceedings of the 2001 Symposium on Java Virtual Machine Research and Technology Symposium, Vol. 1, 2001. P. 105–116. of java.util.concurrent package, 5. Documentation http://download.oracle.com/javase/6/docs/api/java/util/concurrent/package-summary.html 6. Elmas T., Qadeer S., Tasiran S. Goldilocks: A Race and Transaction-Aware Java Runtime. In Proceedings of The 2007 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI'07), 2007. P. 245–255. 7. Engler D., Ashcraft K. RacerX: Effective, Static Detection of Race Conditions and Deadlocks. In Proceedings of The Nineteenth ACM Symposium on Operating Systems Principles, 2003. P. 237–252. 8. Flanagan C., Freund S. FastTrack: Efficient and Precise Dynamic Race Detection. In ACM Conference on Programming Language Design and Implementation, 2009. P. 121–133. 9. Java Language Specification, Third Edition. Threads and Locks. Happens-before Order. http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.5 10. Lamport L. Time, Clocks and the Ordering of Events in a Distributed System. Communications of the ACM, Vol. 21, Issue 7, 1978. P. 558–565. 11. Leino K., Nelson G., Saxe J. ESC/Java user’s manual. SRC Technical Note 2000–002, 2001. 12. Mattern, F. Virtual Time and Global States of Distributed Systems. In Cosnard, M., Proc. Workshop on Parallel and Distributed Algorithms, Chateau de Bonas, France: Elsevier, pp. 215–226, 1988. 13. Naik M., Aiken A., Whaley J. Effective Static Race Detection for Java. In Proceedings of The 2006 ACM SIGPLAN Conference on Programming Language Design and Implementation, 2006. P. 308–319. 14. Netzer R., Miller B. What Are Race Conditions? Some Issues and Formalizations. In ACM Letters On Programming Languages and Systems, 1(1), 1992. P. 74–88. 15. Pozniansky E., Schuster A. Efficient On-the-fly Data Race Detection in Multithreaded C++ Programs. In Proceedings of The Ninth ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, 2003. P. 179–190. 16. Qi Y., Das R., Luo Z., Trotter M. MulticoreSDK: a practical and efficient data race detector for real-world applications. In Proceedings Software Testing, Verification and Validation (ICST), IEEE, 21-25 March 2011. P. 309–318. 17. Savage S., Burrows M., Nelson G., Sobalvarro P., Anderson T. Eraser: A Dynamic Data Race Detector for Multithreaded Programs. In ACM Transactions on Computer Systems, Vol. 15, Issue 4. , 1997. P. 391–411. 18. ThreadSanitizer for Java: a run-time detector of data raceshttp://code.google.com/p/javathread-sanitizer/ Приложение. Язык описания синхронизационных контрактов. Для описания happens-before контрактов пар методов различных классов предназначен тег Syncs, содержащий несколько тегов Sync, - по одному на каждый контракт. В описании контракта указываются все примитивные связи, образующие связь между методами (тег Links, содержит по одному тегу на каждую примитивную связь), и описание вызовов методов, являющихся 284 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 285. отправкой и приёмкойотношения happens-before (теги Send и Receive, соответственно). !ELEMENT !ELEMENT !ELEMENT !ELEMENT !ELEMENT Syncs ( Sync+ ) Sync ( Links, Send, Receive ) Receive ( MethodCall ) Send ( MethodCall ) Links ( Link+ ) Вызов метода описывается в теге MethodCall: указывается класс-владелец метода, название метода и его дескриптор во внутренней нотации виртуальной Java-машины (JVM). Примитивная связь описывается тегом Link: !ELEMENT Link EMPTY !ATTLIST Link receive (owner|param) #REQUIRED receive-number CDATA #IMPLIED send (owner|param) #REQUIRED send-number CDATA #IMPLIED Атрибуты send и send-number соответствуют левой части примитивной связи, а receive и receive-number – правой. Обе они могут быть либо типа «владелец», либо типа «параметр». Если правая часть типа «владелец», то receive имеет значение «owner», а receive-number не указывается. В другом случае receive имеет значение «param», а receive-number содержит номер параметра в сигнатуре метода (нумерация начинается с нуля). Аналогично для атрибутов send и send-number. Пример такого контракта приведён выше на рис.1. Если нужно описать контракты нескольких пар методов одного и того же класса, это можно сделать с помощью тега Multiple-Syncs, состоящего из нескольких тегов Multiple-Sync, каждый из которых соответствует одному классу. Полное имя класса указывается в атрибуте owner, а связь между вызовами методов описывается в теге Multiple-Links: !ATTLIST !ELEMENT !ELEMENT !ELEMENT Multiple-Sync owner ID #REQUIRED Multiple-Syncs ( Multiple-Sync+ ) Multiple-Sync ( Multiple-Links, Call+ ) Multiple-Links ( Multiple-Link+ ) Пример такого контракта приведён на рис. 2. Multiple-Sync owner=java.util.concurrent.atomic.AtomicBoolean Multiple-Links Multiple-Link type=owner/ /Multiple-Links Call type=receive name=get descriptor=()Z/ Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 285
- 286. Обнаружение дефектов работыс указателями в программах на языках C и C++ с использованием статического анализа и логического вывода Татьяна Верт1 , Татьяна Крикун1 и Михаил Глухих2 1 Санкт-Петербургский государственный политехнический университет, Россия, werttanya@mail.ru, krikuntatiana@mail.ru, 2 Технический университет Клаусталя, Германия, mikhail.glukhikh@gmail.com Аннотация В статье рассматривается один из способов повышения точности обнаружения дефектов при помощи статического анализа, а именно дополнение классических алгоритмов анализом зависимостей. Предлагается в процессе абстрактной интерпретации извлекать информацию как об известных статически значениях переменных, так и о зависимостях между неизвестными значениями, представляемых предикатами логики первого порядка. Это позволяет при проверке условий наличия дефектов, а также при анализе ветвлений, использовать готовые средства логического вывода для доказательства истинности или ложности соответствующих условий. Основной упор сделан на логику анализа указателей и на правила обнаружения дефектов работы с указателями. Приведены результаты исследования программного прототипа, использующего Microsoft Z3 Solver в качестве средства вывода. Показано значительное повышение точности анализа, предложены пути снижения ресурсоёмкости данного метода. Keywords: обнаружение дефектов работы с указателями, статический анализ, логический вывод 1 Введение Проблема обеспечения надёжности программного обеспечения является одной из ключевых в современном мире. Известно [6], что даже в хорошо отлаженных программах содержится до 0.7 ошибок на 1000 строк исходного кода. Одним из наиболее распространённых классов ошибок являются ошибки работы с указателями. Основным методом проверки качества программного обеспечения попрежнему является тестирование. Не умаляя достоинств данного метода, следует отметить, что тестирование не дает гарантий обнаружения всех 286 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 287. имеющихся в программеошибок и поэтому в ряде случаев не может являться единственным методом проверки качества. Подобную гарантию могут предоставить только статические методы, одним из которых является статический анализ кода [23][20]. Ключевыми характеристиками методов обнаружения ошибок в программном коде являются полнота, точность и ресурсоёмкость. Полнота анализа вычисляется как доля обнаруженных истинных ошибок среди всех имеющихся ошибок в программе, а точность —как доля обнаруженных истинных ошибок среди всех обнаруженных. Как правило, три данные характеристики находятся в противоречии друг с другом, и в средствах обнаружения ошибок приходится выбирать разумный компромисс. В частности, промышленные средства статического анализа [11] обычно ориентированы на высокую точность и низкую ресурсоёмкость, но не гарантируют полноту. Исследовательские средства анализа часто стремятся к обнаружению всех имеющихся ошибок определенного класса, что приводит к понижению точности и росту ресурсоёмкости; во многих случаях подобные характеристики препятствуют широкому распространению средств статического анализа [20]. Распространённым алгоритмом статического анализа является абстрактная интерпретация [13]. Данный алгоритм подобен обычной интерпретации. Однако, абстрактная интерпретация осуществляет анализ всех путей программы, обеспечивая таким образом полноту анализа. При этом для хранения возможных значений переменных используются так называемые абстрактные семантические домены — в частности, множество целочисленных интервалов, множество указателей и т.д. Абстрактная интерпретация допускает как раздельный анализ путей программы, имеющий высокую точность и очень высокую ресурсоёмкость, так и совместный анализ путей, имеющий приемлемую ресурсоёмкость, но низкую точность за счёт объединения возможных значений переменных при слиянии путей. Одним из способов повышения точности при совместном анализе путей является дополнение классических алгоритмов анализом зависимостей [19]. Зависимостью здесь называется произвольная связь между значениями двух и более переменных программы; математически, зависимость может быть представлена в виде предиката [22]. Анализ зависимостей позволяет полностью или частично компенсировать погрешность, вызванную слиянием путей в ходе статического анализа. Для реализации анализа зависимостей могут быть использованы готовые методы и средства логического вывода, такие, как аппарат дизъюнктов Хорна и средства логического программирования [18], логика первого и высших порядков [22], SMT-решатели [3]. Подобная возможность позволяет, в числе прочего, упростить другие используемые алгоритмы, в частности, использовать анализ точных значений вместо интервального анализа. В [15] Патрик Кузо рассматривает одну из возможных математических моделей объединения абстрактной интерпретации и логического вывода. Насколько известно авторам статьи, на данный Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 287
- 288. момент эта модельне реализована в рамках существующих средств статического анализа. Ключевой идеей данной работы является использование сочетания методов статического анализа и логического вывода для обнаружения ошибок в исходном коде. В качестве основной группы ошибок была выбрана некорректная работа с указателями, однако предлагаемый подход может быть расширен и на другие группы ошибок. В разделе 2 приведён обзор существующих работ по рассматриваемой тематике. В разделе 3 рассматривается предлагаемый подход. Раздел 4 посвящен практической реализации подхода и проведённым экспериментальным исследованиям. Раздел 5 подводит итоги и намечает направления дальнейшего развития подхода. 2 Обзор существующих работ В настоящее время, известно ряд как коммерческих, так и исследовательских средств статического анализа [9]. Ведущим коммерческим средством обнаружения дефектов методом статического анализа де-факто является платформа Coverity SAVE [8]. Концептуально данное средство ориентировано на анализ программ произвольного размера и обеспечение высокой точности — от 80% до 90% по данным авторов. Средство не гарантирует полноты анализа, но тем не менее обнаруживает довольно большое количество серьёзных ошибок — порядка 7 ошибок на 10000 строк кода — в реальных программных проектах [11,6]. Подход средства Coverity SAVE основан на извлечении из исходного кода правил использования различных его объектов [17], при этом извлекаются как точные правила вида «указатель P не NULL», так и статистические правила вида «mutex M, возможно, защищает переменную V». В дальнейшем эти правила проверяются на непротиворечивость с целью обнаружения ошибок в программе. Исследовательское средство Astree [7] разработано под руководством Патрика Кузо. Средство ориентировано на поиск ошибок времени исполнения в программах на языке C и было использовано для анализа ряда промышленных программных проектов среднего размера (порядка 100000 строк кода). Согласно [14], средство использует как общеизвестные абстрактные семантические домены (целочисленные интервалы, множества указателей), так и ряд доменов, позволяющих отследить зависимости между переменными (в частности, домен октагонов, домен линейных выражений). После разбора исходного кода Astree вначале выполняет ряд простых видов анализа, позволяющих упростить основную задачу (в частности, выявление мёртвых ветвей и переменных), после чего выполняет основной анализ сверху вниз, начиная с точки входа в программу и кончая наиболее простыми функциями. Исследовательское средство Saturn [4] построено на анализе программ снизу вверх [10]. Информация, полученная при анализе конкретных функций, используется в точках их вызова и анализ функций не повторяется. Тот же принцип может быть использован при анализе циклов. При ана- 288 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 289. лизе отдельных операторовиспользуется вывод ограничений в различных точках исполнения программы с последующим запуском SAT-решателя для определения логической разрешимости. Для описания правил анализа используется язык логического программирования Calypso. Средство может быть использовано для анализа больших программных систем, однако, как следует из [16], имеет довольно низкую точность. Средство PREfix также анализирует программы снизу вверх [21]. Используются традиционные алгоритмы анализа потока данных, сопоставления с образцом и некоторые другие. В частности, используется идея хранения состояния программы в виде множества точных значений, дополненных множеством предикатов [12]. Продукты PC-Lint (для MS Windows) и FlexeLint (для Unix, Linux, Mac OS X, Solaris) компании Gimpel Software [5] предназначены для обнаружения дефектов в программах на языках C/C++. Система производит синтаксический анализ исходного кода, анализ потока данных и управления, осуществляет межпроцедурный анализ. Используются специальные средства проверки, в том числе: анализ значений, дополнительная строгая проверка типов, определяемая пользователем семантическая проверка аргументов функции и возвращаемых значений. Исследовательское средство Aegis [1] анализирует программы сверху вниз. Средство использует анализ указателей, интервальный анализ, ресурсный анализ; для повышения точности используется также простой анализ зависимостей [19]. 3 Описание разработанного подхода Предлагаемый подход ориентирован на использование средств верификации и логического вывода для доказательства различных утверждений в ходе статического анализа, в частности, утверждений о наличии либо отсутствии дефектов в отдельных операторах программы. 3.1 Архитектура Первым этапом выполнения статического анализа является построение модели по исходному коду программы. Наиболее удобной моделью для выполнения статического анализа является граф потока управления (ГПУ), в нем присутствуют только узлы, соответствующие исполнимым операторам программы. На следующем этапе происходит применение собственно алгоритмов статического анализа с целью определить состояния программы во всех точках её исполнения. Алгоритмы, используя известную информацию о семантике языка, вычисляют возможные значения всех переменных программы. На последнем этапе (выполняемым параллельно с предыдущим) рассчитанные состояния используются алгоритмами обнаружения дефектов для выявления и локализации имеющихся в программе ошибок. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 289
- 290. Для того, чтобыиспользовать средства логического вывода в ходе абстрактной интерпретации, необходимо предоставить им входные данные в подходящей для них форме. Один из вариантов подобного представления — хранение состояния программы в виде множества предикатов, с последующим использованием данного множества для формирования выводов. Общая схема анализатора, отражающая структуру предлагаемого подхода, представлена на рис.1. Рис. 1. Структура предлагаемого подхода Данный способ предполагает, что для некоторых переменных хранятся их точные на данный момент значения. Если значение данной переменной вычислить статически невозможно, для неё могут храниться различные условия, связывающие её значение со значениями других переменных. Таким образом, происходит дополнение точных значений зависимостями между переменными. Средство логического вывода отвечает за взаимодействие с внешним доказателем. Предполагается решение двух задач — доказательства истинности определенных предикатов и упрощения множества предикатов для сокращения его объёма. Анализатор, оперируя состоянием программы и результатами вывода, осуществляет поиск дефектов в конкретных операторах. 3.2 Извлечение предикатов В ходе анализа отдельных операторов программы происходит извлечение информации о значениях переменных и связях между ними, представляемых в виде логических утверждений — предикатов [22][18]. В наиболее простом случае интерпретация одного оператора приводит к формированию одного предиката, в точности описывающего семантическое преобразо- 290 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 291. вание, выполняемое даннымоператором (например, интерпретация операторов присваивания). Предикат в нашем случае представляется в виде формулы p(v1 , v2 , ..., vn ), где p — функциональный символ, а vi , i = 1...n — предикатные переменные. Значение предикатной переменной в большинстве случае соответствует значению одной из переменных программы; примерами подобных предикатов являются: – арифметические: сумма sum(a, b, c) (a = b+c), разность dif f (a, b, c) (a = b − c); – предикаты сравнения: равенство equals(a, b) (a = b), больше greater(a, b) (a b), меньше или равно less_equals(a, b) (a ≤ b); Допускаются также более сложные предикаты, переменными которых являются другие предикаты, в частности, oneof (p1 , p2 ) (истинен хотя бы один из двух предикатов p1 , p2 ), oppos(p) (предикат p ложен) и equiv(p1 , p2 ) (предикаты p1 и p2 одновременно истинны или одновременно ложны). Данные сложные предикаты также могут быть описаны в терминах логики первого порядка (без использования предикатов в качестве аргументов), поэтому их введение не увеличивает порядок используемой логики. Определение предикатов, представленное выше, выбрано для простоты реализации. Одной переменной программы могут соответствовать несколько предикатных переменных, описывающих её значение в разные моменты выполнения. Это требование является важным, поскольку логика первого порядка не предполагает изменение значения задействованных переменных. Поэтому было принято решение о представлении переменных на базе статического однократного присваивания. Таким образом, при каждом прямом присваивании переменная программы, стоящая в левой части, употребляется в новом контексте, и поэтому для нее создается новая предикатная переменная. Например, после интерпретации цепочки операторов вида a=b+c; d=a; a+=e образуется набор предикатов sum(a1 , b1 , c1 ), equals(d1 , a1 ), sum(a2 , a1 , e1 ). Описание логических операций специфично для языка C, поскольку, согласно семантике данного языка, логические выражения представляются в виде целых чисел. При этом нуль соответствует лжи, а не нуль — истине. Отсюда вытекают такие предикаты, как zero(v) и nonzero(v) (нуль/ложь, не нуль/истина). Предикаты conj(a, b, c) (a = b c), disj(a, b, c) (a = b || c) описывают логические операции C, а предикат equiv(p1 , p2 ) может быть использован для связи логических переменных с арифметическими. Например, после интерпретации цепочки g = (a0); h = (b=a); f = g h образуется набор предикатов equiv(nonzero(g1 ), greater(a1 , 0)), equiv(nonzero(h1 ), greater_equals(b1 , a1 )), conj(f1 , g1 , h1 ). При интерпретации операторов ветвления if(cond), где cond — выражение, из входного состояния образуется два. Если cond не имеет точного значения, то используется средство логического вывода, которое на основании имеющихся предикатов позволит проверить истинность и/или ложность условия. Если какая-то ветвь оказалась мертвой (условие для нее никогда не выполняется), то дальнейший анализ для этой ветви не производится. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 291
- 292. После проверки условияв состояние истинной ветви добавляется предикат, соответствующий истинности условия cond, а в состояние ложной ветви — предикат, соответствующий ложности условия cond. В частности, если cond является переменной, используются предикаты nonzero(cond) и zero(cond) соответственно. Для снижения количества анализируемых путей применяется объединение состояний программы в точках слияния путей (так называемых фифункциях) с последующим совместным анализом объединённых путей. В отличие от других операторов оператор фи-функции имеет два и более входных операторов и соответственно два или более предикатных состояния на входе. Основные правила слияния состояний: • если одна и та же предикатная переменная vi имеет разные значения во входных состояниях, то её возможные значения xj объединяются по ИЛИ путём добавления предиката oneof (equals(vi , x1 ), equals(vi , x2 )); • если некоторой переменной программы v соответствуют разные предикатные переменные v1 и v2 во входных состояниях, то для неё создается новая предикатная переменная v3 , при этом в выходное состояние добавляется предикат oneof (equals(v3 , v1 ), equals(v3 , v2 )); • все предикаты, входящие во входные состояния, необходимо добавить в выходное состояние. Для описания логики работы с составными переменными языка C (структурами, массивами) и с указателями на них, используется дополнительный набор предикатов: • элемент сложного объекта arr(a, v, s) — массив (структура) a содержит значение v по смещению s байт — a[s]=v в случае байтового массива; • размер сложного объекта sizeof (a, s) — массив (структура) a имеет размер s байт, или sizeof(a)=s; • указатель на объект ptr(a, p, s) — указатель p указывает на массив (структуру, переменную) a со смещением s байт, или p=(void*)(a)+s; • разадресация указателя deref (p, v) — значение переменной v равно значению по адресу p, или v=*p; • корректность указателя correct_ptr(p), incorrect_ptr(p) — указатель p имеет корректное (указывающее на реально существующую переменную) или некорректное (равное нулю, указывающее на несуществующую переменную) значение. При слиянии ветвей в некоторых ситуациях важной является связь между значением указателей и выражением из условия. В общем случае, если некоторая переменная имеет разные значения в разных ветвях условного оператора, предикат, описывающий её значение, следует связать с условием оператора if для повышения точности. Рассмотрим пример: 1 2 3 4 292 if(size 0) q = malloc(size); else q = 0; Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 293. После интерпретации даннойконструкции состояние в истинной ветви содержит предикаты: greater(size1 , 0), sizeof (dyn, size1 ), ptr(dyn, q1 , 0), где dyn — созданный динамически массив. В состоянии ложной ветви имеются следующие предикаты: less_equals(size1 , 0), equals(q2 , 0). При слиянии двух указанных состояний важна зависимость между значением переменной size, значением указателя q и существованием динамического массива. В дальнейшем при анализе оператора освобождения памяти необходимо знать, что динамический массив существует тогда и только тогда, когда size 0, или когда q не является нулевым указателем. Поэтому в выходном состоянии следует учесть эту зависимость. Таким образом, в момент слияния состояний в разных ветвях оператора условия указателю q соответствуют разные предикатные переменные q1 , q2 . Согласно правилам слияния состояний создается новая переменная q3 и для неё добавляется предикат oneof (equals(q3 , q1 ), equals(q3 , q2 )). Чтобы учесть зависимость между переменными size и q, в состояние нужно добавить также предикат equiv(less_equals(size1 , 0), equals(q3 , 0)). 3.3 Правила анализа указателей Логический вывод осуществляется при помощи некоторого набора аксиом, на основе которых делаются все логические заключения. В основе всех средств логического вывода лежит базовый набор аксиом для распространённых теорий, таких как теория целых чисел. Так как теория указателей не является стандартной для средств логического вывода, появляется необходимость в расширении базового набора аксиом. Таким образом, для осуществления анализа указателей средствами логического вывода необходимо ввести следующие правила: • правило корректности указателя: ptr(t, p, s), sizeof (t, v), greater_equals(s, 0), less(s, v) (1) correct_ptr(p) указатель p корректен, когда смещение s, с которым он указывает на цель t, не отрицательно и меньше размера v цели t; • правила разадресации указателя: 1)Указатель на простую переменную: ptr(t, p, 0), deref (p, v) equals(t, v) (2) если p указывает на t со смещением 0, то значение v по адресу p равно t; 2)Указатель на элемент составного объекта (массива или структуры): ptr(a, p, s), arr(a, t, s), deref (p, v) equals(t, v) (3) если p указывает на a со смещением s, и t находится в a по смещению s, то значение v по адресу p равно значению t. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 293
- 294. • правило сложенияуказателя с целочисленной константой: ptr(a, p, s), sum(t, s, b), sum(q, p, b) ptr(a, q, t) (4) если указатель p указывает на a со смещением s, t равно сумме s и b, а указатель q равен сумме p и b, то q указывает на a со смещением t. Эти правила применяются для обнаружения программных дефектов, связанных с использованием указателей. 3.4 Правила обнаружения дефектов В данной работе особое внимание уделено следующим типам дефектов: • некорректное использование указателей; • переполнение буферов и выходы за границы массивов. Некорректное использование указателей — группа дефектов, связанная с разадресацией некорректного или нулевого указателя. Некорректный указатель — это указатель, в результате разадресации которого возникает ошибка. Примером некорректного указателя может служить указатель на освобождённую память. Процедура обнаружения дефектов при интерпретации операторов косвенной записи или косвенного чтения зависит от значения указателя. Если разадресуемый указатель имеет точное значение: нулевой указатель или некорректное значение, то дефект считается обнаруженным. Если указатель не имеет точного значения, то присутствие дефекта в операторе подтверждается путём доказательства разрешимости определённых предикатов относительно множества уже существующих предикатов. Такими предикатами являются: • нулевой указатель: equals(ptr, 0); • некорректный указатель: oppos(correct_ptr(ptr)). Чтобы показать отсутствие дефекта, необходимо доказать неразрешимость противоположных предикатов: • ненулевой указатель: not_equals(ptr, 0); • корректный указатель: correct_ptr(ptr). Обнаружение выхода за границу объекта производится при выполнении операции разадресации *ptr и операции обращения по индексу ptr[i]. Для каждого значения указателя (obj, shift) следует проверить, что смещение shif t ≥ 0 и shif t sizeof (obj). Если это условие доказуемо, то дефект отсутствует, в противном случае дефект считается обнаруженным. 294 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 295. 4 Экспериментальные исследования Для проведенияэкспериментальных исследований описанного подхода было разработано средство-прототип. Для получения графа потока управления из исходного кода программы был использован плагин к компилятору gcc, в качестве ядра прототипа была использована библиотека статического анализатора Aegis [1]. В качестве средства логического вывода был выбран SMT-решатель Z3 [3]. Z3 —это свободно распространяемый SMT решатель с открытым исходным кодом, разрабатываемый в Microsoft Research и имеющий API доступа для множества языков программирования. В настоящее время Z3 считается самым мощным средством работы с SMT-предикатами по данным соревнования SMT-COMP [2]. Исследование проводилось на различных тестовых программах (всего порядка 30 программ, объем каждой программы 30-50 строк), содержащих и не содержащих дефекты. Данные программы также были протестированы с помощью средства FlexeLint компании Gimpel Software и базовым анализатором Aegis, не использующим механизм зависимостей. Сводные результаты анализа приведены в таблице 1. Таблица 1. Результаты анализа Средство анализа Прототип FlexeLint Aegis Точность 95% 60% 68% Полнота 95% 45% 75% Среднее время анализа 53 сек 4 сек 5 сек Приведенные результаты наглядно демонстрируют значительный выигрыш в точности анализа в результате ввода правил анализа зависимостей. Недостатком разработанного прототипа являются временные затраты на анализ, которые в зависимости от сложности программы составляли от одной секунды до десяти минут. Наиболее ресурсоемким является анализ циклических участков программ из-за большого количества создаваемых предикатов на каждой итерации цикла. Для снижения ресурсоемкости анализа можно предложить несколько решений. Одним из таких решений является применение алгоритмов сборки мусора. Этот подход подразумевает удаление из состояния программы предикатов, значения которых не используются при проведении дальнейшего анализа. Другим возможным решением является применение алгоритмов упрощения состояния программы на основе правил трансформации предикатов. Применение данного подхода позволит снизить количество вызовов внешнего решателя. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 295
- 296. 5 Заключение В статье былрассмотрен подход к статическому анализу, основанный на комбинировании анализа точных значений и анализа предикатов с использованием средств логического вывода. Приведены правила извлечения предикатов из различных операторов анализируемой программы. Разработаны логические правила вывода для анализа указателей и обнаружения дефектов работы с указателями. Приведённые алгоритмы анализа реализованы в исследовательском прототипе на базе анализатора Aegis и SMT-решателя Microsoft Z3. Показано значительное повышение точности по сравнению с базовым анализатором. Направления дальнейшего развития данной работы в основном относятся к проработке и реализации методов снижения ресурсоёмкости анализа, что сделает возможным применение подхода для анализа промышленных программ. Список литературы 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 296 Aegis static analysis framework. http://www.digiteklabs.ru/en/aegis/platform. Smt-comp 2012. http://smtcomp.sourceforge.net/2012/. Z3 SMT solver. http://z3.codeplex.com/. The saturn program analysis system. http://saturn.stanford.edu, 2006. PC-lint and Flexelint static analysis tools. http://www.gimpel.com/html/products.htm, 2011. Coverity scan: 2012 open-source report. http://scan.coverity.com, 2012. The astree static analyzer. http://www.astree.ens.fr, 2013. Coverity save. http://www.coverity.com/products/coverity-save.html, 2013. Static analysis tools for c code. http://spinroot.com/static, 2013. A. Aiken, S. Burgara, I. Dillig, T. Dillig, B. Hackett, and P. Hawkins. An overview of the saturn project. In Workshop on Program Analysis for Software Tools and Engineering, pages 43–48. ACM, 2007. A. Bessey, K. Block, B. Chelf, A. Chou, B. Fulton, S. Hallem, C. Henri-Gros, A. Kamsky, S. McPeak, and D. Engler. A fex billion lines of code later: Using static analysis to find bugs in the real world. Communications of the ACM, 53(2):66–75, 2010. W. Bush, J. Pincus, and D. Sielaff. A static analyzer for finding dynamic programming errors. Software: Practice and Experience, 30:775–802, 2000. P. Cousot. Abstract interpretation. ACM Computing Surveys, 28(2):324–328, 1996. P. Cousot, R. Cousot, J. Feret, L. Mauborgne, A. Mine, D. Monniax, and X. Rival. Combination of abstractions in astree static analyzer. In Proceedings of the 11th Annual Asian Computing Science Conference (ASIAN’06), pages 272–300, Berlin, 2008. P. Cousot, R. Cousot, and L. Mauborgne. Theories, solvers and static analysis by abstract interpretation. Journal of the ACM, 59(6), 2012. I. Dillig, T. Dillig, and A. Aiken. Sound, complete and scalable path-sensitive analysis. ACM SIGPLAN notices, 43:270–280, 2008. D. Engler, D. Chen, S. Hallem, A. Chou, and B. Chelf. Bugs as deviant behavior: A general approach to inferring errors in system code. In Symposium on Operating System Principles, pages 57–72. ACM, 2001. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 297. 18. Jean H.Gallier. Logic for Computer Science. Foundation of Automatic Theorem Proving. Philadelphia, PA, USA, 2003. 19. M. Glukhikh, V. Itsykson, and V. Tsesko. Using dependencies to improve precision of code analysis. Automatic Control and Computer Science, 46(7):338–344, 2012. 20. B. Johnson, Y. Song, E. Murphy-Hill, and R. Bowdidge. Why don’t software developers use static analysis tools to find bugs? In Proceedings of the 2013 International Conference on Software Engineering, pages 672–681, 2013. 21. N. Nagappan and T. Ball. Static analysis tools as early indicators of pre-release defect density. In Proceedings of the 27th international conference of Software Engineering, pages 580–586. ACM, 2005. 22. W. Rautenberg. A Concise Introduction to Mathematical Logic. New York, NY, USA, 2010. 23. В. Ицыксон и М. Глухих. Программная инженерия. Обеспечение качества программных средств методами статического анализа. Изд-во Политехн. ун-та, СПб., 2011. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 297
- 298. Автоматизированный синтез тестовдля Java-программ на основе анализа программ и учета контрактов Алефтина Андрианова, Владимир Ицыксон Санкт-Петербургский государственный политехнический университет aleftina.andrianova@gmail.com, vlad@ftk.spbstu.ru Аннотация. Обеспечение качества создаваемого программного обеспечения является одной из основных проблем программной инженерии. Одним из путей, используемых для повышения качества программ, является автоматизируемый синтез тестов. В статье предлагается технология автоматизированного создания модульных тестов, комбинирующая подходы белого и черного ящика. При этом для обеспечения покрытия тестами путей программы используется информация, извлекаемая из исходного программы, а для формирования тестовых оракулов и распределения параметров тестов по области определения используются частичные спецификации, заданные в форме контрактов. Разработанный подход реализован в виде инструментального средства, анализирующего программы на языке Java, и формирующего тест-кейсы для методов классов в формате JUnit, используя COFOJA для задания контрактов. Тестирование разработанного средства на ряде тестовых примеров показало работоспособность подхода. Ключевые слова: Автоматизированное тестирование программ, синтез тестов, контрактное программирование, анализ кода, SMT-solver 1 Введение 1.1 Автоматизация тестирования программного обеспечения Проблема качества программного обеспечения является одной из самых острых в компьютерной индустрии. Огромные ресурсы вкладываются в различные мероприятия, направленные на повышение качества выпускаемых программных систем, так как потенциальный ущерб от сбоев программного обеспечения может быть очень велик. Одним из самых распространенных и легко реализуемых методов повышения качества является тестирование. Различные технологии тестирования активно используются практически во всех компаниях, занимающихся разработкой про- 298 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 1
- 299. граммного обеспечения. Однако,эффективность проведения тестирования определяется не только количеством разработанных тестов, но и их качеством. Зачастую качество тестов зависит только от профессиональных навыков тестировщика, в то время как требуется, чтобы качество создаваемых тестов больше зависело от разработанного программного обеспечения и спецификации требований. Поэтому в последнее время активно развивается направление программной инженерии, связанное с автоматизацией синтеза тестов на основе различных проектных артефактов. В качестве таких артефактов в разных исследованиях используются спецификации требований, аннотации, контракты, исходный код программного обеспечения и т.п. При формировании тестов перед разработчиками встают следующие основные задачи: обеспечение максимального покрытия тестами программы, при этом обычно рассматривается один следующих критериев покрытия: покрытие операторов, покрытие ветвлений или покрытие путей; формирование тестов, покрывающих максимально возможный диапазон входных значений функций и методов; проверка максимально возможного числа требований, предъявляемых к программе. В данной статье описывается разработанный авторами подход, целями которого было решение перечисленных выше задач. Подход основан на интеграции двух методов тестирования: структурного, базирующегося на анализе исходного кода программы, и функционального, использующего спецификации. Разработаны методы автоматизации создания тестов, учитывающие как внутреннее устройство программы, так и функциональные требования к ней. Для построения модели программы и извлечения трасс выполнения используются методы статического анализа. В качестве спецификаций требований используются контракты, позволяющие описывать требования, предъявляемые к отдельным методам и классам. Совместный анализ извлеченных трасс и контрактов позволяет синтезировать комплекты тестов, обеспечивающих покрытие путей программы. Подход реализован в виде инструментального средства генерации тестов на основе анализа Java-программ и системы контрактов CoFoJa[1]. 1.2 Результаты В данной работе получены следующие теоретические и практические результаты: разработаны принципы генерации тестов, форсирующих прохождения выбранной трассы программы; разработаны методы комплексирования синтеза функционального и структурного тестирования, основанные на объединении анализа кода и контрактов; Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 2 299
- 300. предложены методыформирования множественных тестов для обеспечения покрытия всей области определения; разработано инструментальное средство генерации тестов для Java-программ. 1.3 Структура статьи Оставшаяся часть работы организована следующим образом. Второй раздел содержит описание разработанного авторами подхода к генерации тестов. Подробно рассматривается построение модели программы, извлечение трасс исполнения и формирование системы утверждений для SMT-солверов, а также генерация множественных тестов. Третий раздел посвящен описанию созданного прототипа генератора тестов. В четвертом разделе приводится информация об апробации подхода. Пятый раздел содержит обзор текущего состояния дел в области автоматизированного синтеза тестов на основе анализа программы и учета контрактов. В заключении подводится итог проведенной работы, формулируются направления дальнейших исследований. 2 Предлагаемый подход В данной работе предлагается подход к автоматизации создания модульных тестов, обеспечивающий покрытие путей программы. Далее в этой работе не умаляя общности мы будем рассматривать создание тестов для одного метода какого-либо класса. Для обеспечения покрытия путей метода необходимо для каждой возможной трассы исполнения программы сгенерировать такой набор значений аргументов метода, который форсирует прохождение программой этой трассы. То есть необходимо так подобрать значения аргументов, чтобы при каждом возможном ветвлении выбиралась требуемая ветвь программы. Построение для заданных значений аргументов соответствующих трасс исполнения является прямой задачей. Вычисление же требуемых значений аргументов метода для удовлетворения заданной трассы это обратная задача. В общем случае обратная задача - сложная научная NP-полная проблема, требующая решения сложных систем уравнений. В данной статье описывается способ решения этой задачи с определенными ограничениями, позволяющий вычислить требуемые значения аргументов за приемлемое время. Если ограничиться формированием модульных тестов только на основе критерия покрытия, то полученные тесты никак не будут учитывать требования, предъявляемые ко всей программе вообще или к конкретному методу в частности. Чтобы использовать информацию о требованиях, описанный способ формирования тестов на основе анализа программы может быть расширен с помощью учета спецификаций. Спецификация (или частичная спецификация) может быть задана с помощью контрактов [2]. Анализ предусловий метода и инвариантов класса может сузить множество возможных 300 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 3
- 301. значений параметров тестов,исключив из них не соответствующие контракту. Постусловия могут использоваться для формирования заготовки тестовых оракулов, упрощая тем самым работу разработчиков тестов. Предлагаемый авторами подход подразумевает выполнение следующих шагов: 1. формирование модели программы; 2. формирование списка путей выполнения метода; 3. преобразование каждого пути в цепочку утверждений, верных для этого пути; 4. дополнение цепочки утверждений составляющими контрактов: предусловиями метода и инвариантами класса; 5. разрешение системы утверждений относительно аргументов метода; 6. формирование экземпляра/экземпляров теста на основе решения системы утверждений; 7. формирование тестового оракула на основе постусловий метода и инвариантов класса. Рассмотрим перечисленные шаги подробнее. 2.1 Модель анализируемой программы Для извлечения отдельных путей выполнения программы необходимо использовать такую модель, которая с одной стороны содержит все необходимые данные для построения трасс, а с другой стороны является довольно компактной. Так как требуется извлекать информацию о динамике программы, то в качестве модели не могут использоваться структурные модели, (например, абстрактное синтаксическое дерево), не содержащие информации о последовательности выполнения операторов, использование же гибридных моделей (например, абстрактный семантический граф) неоправданно, так как такие модели слишком избыточны. Среди поведенческих моделей программ для решения задачи извлечения путей наиболее подходят модели, основанные на потоке управления, такие как граф потока управления (Control Flow Graph, CFG) или модель статического однократного присваивания (Single Static Assignment, SSA). В данной работе на фазе построения мы ограничиваемся построением классического графа потока управления, элементы же однократного статического присваивания используются позже на этапе преобразования путей в цепочки утверждений. 2.2 Извлечение трасс исполнения Извлечение трасс исполнения осуществляется с помощью анализа графа потока управления. Для этого применяется рекурсивный алгоритм поиска, выявляющий все возможные уникальные пути от начальной точки к конечной. При этом по- Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 4 301
- 302. разному обрабатываются узлы,соответствующие вычислительным операторам и операторам ветвления. Для вычислительных узлов в список элементов пути добавляются операторы, соответствующие этим узлам. Для узлов ветвления вида if (condition) ... в список добавляется условие condition или ~condition в зависимости от выбранной при обходе графа ветви условного условного оператора. Таким образом, для каждого пути графа будет собран список операторов и условий, которые должны выполниться для того, чтобы данный путь был пройден. 2.3 Формирование системы утверждений Для того, чтобы по построенному пути вычислить подходящие значения аргументов, форсирующих выполнение этого пути, необходимо решить обратную задачу. Для этого требуется преобразовать полученный путь в систему уравнений и разрешить ее относительно аргументов метода. Для этого необходимо для каждого накопленного пути проделать следующие операции: преобразовать путь в форму однократного статического присваивания (SSA); все присваивания преобразовать в утверждения равенства; все условия преобразовать в соответствующие утверждения. Для того, чтобы построить такую систему уравнений необходимо каждой конструкции сохраненной трассы поставить в соответствие алгебраическое уравнение. Для этого все присваивания преобразуются в алгебраические равенства, а сохраненные условия веток ветвления в логические утверждения. Кроме того, необходимо перейти от переменных языка программирования, утверждения над которыми истинны только в определенном контексте выполнения, к алгебраическим переменным, истинность утверждений над которыми не меняется во времени. Пример простой программы: x = 10; y = 20; if (z 5) { x = x + y; } Соответствующая система утверждений для пути, проходящего через ветку “then”: 1: 2: 3: 4: 302 x=10 y=20 z5 x=x+y Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 5
- 303. Очевидно, что такаясистема утверждений неразрешима, так как с одной стороны x=10 (строка 1), а с другой стороны x=30 (строка 4). Такая коллизия обусловлена кардинальными семантическими отличиями переменных императивных языков программирования от переменных, используемых в логиках. Для разрешения этой коллизии используется известный подход, применяемый при построении модели SSA, основанный на введении дополнительных алгебраических переменных, отражающих состояния переменных языка программирования после выполнения присваивания. Такие переменные называются версиями исходной переменной, а сама операция - введением версионирования. Таким образом, после введения версионирования каждой верисонированной переменной в системе уравнений значение будет присвоено только один раз. Для приведенного примера система уравнений будет следующей: 1: 2: 3: 4: x1=10 y1=20 z15 x2=x1+y1 Полученная таким образом система становится алгебраически разрешимой. Она относится к классу Satisfiability Modulo Theories (SMT) [3]. Как следствие, она может быть разрешена с помощью какого-либо SMT-солвера. Для этого необходимо: преобразовать систему утверждений в формат, являющийся входным для SMTсолвера; запустить SMT-солвер для решения системы уравнений; проинтерпретировать результаты работы солвера. В случае успеха из результатов извлекаются значения аргументов метода, форсирующие выполнение указанного пути. Если солвер не смог разрешить систему уравнений, то это свидетельствует либо о наличии в программе “мертвого” кода, либо о некорректности допущений, сделанных при построении модели программы, либо о недостаточной мощности математического аппарата логики первого порядка, либо о недостаточной мощности самого солвера. Во всех случаях будет принято решение о невозможности создания теста для покрытия данного пути. 2.4 Расширение системы утверждений с помощью контрактов Построенные тесты обеспечивают прохождение программой соответствующих трасс исполнения, при этом значения аргументов методов расположены в области допустимых значений произвольно, в соответствии с правилами вывода решений выбранного SMT-солвера [3]. То есть сгененрированные значения аргументов могут нарушать контракты методов, определяющиеся с помощью предусловий, постусло- Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 6 303
- 304. вий и инвариантов[2]. Конкретно в данном случае могут нарушаться предусловия методов или инварианты классов. Решение этой проблемы заключается в расширении построенной системы утверждений с помощью инвариантов классов и предусловий методов. Так как контракты уже задаются в форме утверждений логики первого порядка, то преобразование их в утверждения для SMT-солвера не представляет никакого труда. В результате после решения расширенной системы утверждений будут находиться аргументы метода, удовлетворяющие контракту анализируемого метода. 2.5 Генерация тестовых оракулов Для генерации полноценной системы тестов кроме значений аргументов методов необходимо также формировать тестовые оракулы, проверяющие корректность выполнения тестов. Постусловия, используемые в контрактном программировании, являются частью спецификаций методов и задают свойства, гарантируемые методом после его завершения в случае выполнения предусловий. В данной работе мы предлагаем генерировать основу тестовых оракулов на базе постусловий методов и инвариантов классов, как это сделано в работе [4]. Заданные в форме логических утверждений постусловия и инварианты транслируются в эквивалентные конструкции на целевом языке программирования и интегрируются в созданные тесты. При этом у тестировщика остается возможность расширить сгенерированные автоматически оракулы дополнительными проверками. 2.6 Формирование множественных тестов Представленная технология формирования тестов обеспечивает генерацию по одному набору тестов для каждого класса эквивалентности. Этого достаточно для того, чтобы по одному разу протестировать все пути в графе потока управления. Однако на практике часто имеет смысл иметь несколько тестов для каждого класса эквивалентности, так как необходимо проверить не только сам факт прохождения программы по заданной трассе, но и другие свойства. Например, часто требуется проверять корректность работы программы на граничных значениях интервалов, правильность отработки начала и конца цикла и т.п. Для этого необходимо для каждого класса эквивалентности генерировать множество тестов, обеспечивающих определенное покрытие области допустимых значений аргументов в соответствии с выбранной эвристикой. В данной работе реализован метод формирования множественных тестов, основанный на последовательной генерации новых тестов для классов эквивалентности за счет вычисления области допустимых значений для аргументов метода. Исходя из количества тестов, которые должны быть сгененированы для каждого класса 304 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 7
- 305. эквивалентности (задано пользователем),строится равномерное покрытие nмерного пространства аргументов функции, на основе ограничений области допустимых значений, заданных в контрактах. Для каждого набора параметров генерируется свой модульный тест в результирующем тестовом наборе. Алгоритм формирования равномерного покрытия пространства аргументов с ограничениями имеет итеративный характер, а его подробное описание выходит за рамки настоящей статьи. В дальнейшем авторы предполагают использовать более сложные эвристики для формирования тестовых наборов, более чувствительных к стандартным ошибкам, встречающихся в программах. 3 Описание созданного прототипа Разработанный подход был реализован в виде инструментального средства генерации тестов для языка Java. В качестве системы задания контрактов используется CoFoJa[1]. В качестве SMT-солвера применяется солвер Z3 [3], разработанный Microsoft Research, тесты генерируются в формате JUnit. Общая архитектура системы вместе с артефактами изображена на рис.1. Блоками белого цвета изображены модули, разработанные авторами, серым цветом отмечены сторонние компоненты. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 8 305
- 306. Рис. 1. Общаясхема системы генерации тестов На вход системе передается файл, содержащий исходные коды исследуемой программы на языке Java. Построитель AST формирует абстрактное синтаксическое дерево, которое является входом для построителя графа потока управления (CFG Builder). Абстрактное синтаксическое дерево анализируется и на основе семантики языка Java строится граф потока управления. Извлечение трасс исполнения (Path Extractor) осуществляется с помощью анализа графа потока управления. Полученные пути преобразуются к форме однократного статического присваивания построителем SSA (SSA Builder). Приведение пути в форму SSA с версионированием позволяет рассматривать его как систему алгебраических уравнений. Полученная система утверждений в совокупности с инвариантами класса и предусловиями метода преобразуется к формату SMT-LIB для внешнего SMT-солвера Z3 и передается ему для решения. Генерация тестов осуществляется модулем Test Generator, который использует результаты работы солвера, при этом генерация тестовых оракулов, проверяющих корректность выполнения тестов, осуществляется на основе анализа постусловий метода и инвариантов класса. Результатом работы системы являются синтезированные модульные тесты, обеспечивающие определенный заданный уровень покрытия исходного кода. 4 Экспериментальные исследования Было проведено тестирование разработанного инструментального средства на тестовом наборе программ. Набор состоял из искусственных тестов и нескольких реальных программ, содержащих различные конструкции языка Java: составные выражения, простые и сложные ветвления, циклы и т.п. Искусственные тесты были призваны проверить корректность функционирования разных возможностей, заложенных в разработанном анализаторе. Реальные Java-программы использовались для проверки анализатора в реальных условиях функционирования. На всех искусственных и реальных примерах были получены результаты, соответствующие ожидаемым, а сгенерированные тесты действительно обеспечивали проверку всех путей исследуемых программ. Эксперименты с генерацией множественных тестов также показали работоспособность подхода. 5 Обзор существующих подходов в области синтеза тестов Различные аспекты автоматизации тестирования программного обеспечения и подходы к организации статического и динамического анализа являются популярными направлениями исследований. Существует целый ряд коммерческих и свободно распространяемых средств автоматизации тестирования, фреймворков для органи- 306 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 307. зации разработки, системдля синтеза тестов. Многие из них используют в качестве основы подход синтетического структурного тестирования. В этом случае после первого случайно выбранного теста остальные тесты генерируются автоматически так, чтобы обеспечить покрытие еще не покрытых ранее элементов кода. Для выбора подходящих тестовых данных используются решатели, учитывающие символическую информацию об ограничениях на данные, отделяющие прошедшие тесты от еще не покрытого кода, а для построения нужных последовательностей воздействий — случайная генерация, направляемая как этой же символической информацией, так и некоторыми эвристическими абстракциями, уменьшающими пространство состояний проверяемой системы. В рамках этого подхода интегрируются статический анализ кода, символическое исполнение, структурное тестирование и дедуктивный анализ, выполняемый решателями. Одними из представителей этого класса являются Microsoft Pex and Moles, два исследовательских проекта, направленных на повышение производительности тестировщиков и качества кода. Microsoft Pex [5,6] – набор инструментов, выполняющих анализ тестируемого кода и подбирающий параметры, которые позволяют покрыть максимально возможный объем кода. Microsoft Pex работает в петле обратной связи: код выполняется несколько раз, и производится анализ поведения программы на уровне промежуточного языка .NET CIL (Common Intermediate Language) с помощью мониторинга потока управления и потока данных. После каждого запуска Pex выбирает ветвь, которая не была покрыта ранее, создает систему ограничений, которая описывает, как достичь этой ветви, использует решатель Z3 для определения новых значений входных данных, которые удовлетворяют ограничениям, если таковые существуют. Код выполняется снова с новым набором входных значений, и процесс повторяется. В результате работы создается отчет, который можно проанализировать вручную, и набор unit-тестов для дальнейшего использования. Microsoft Moles [6,7] – фреймворк, также разработанный в лаборатории Microsoft Research и позволяющий разработчикам создавать тестовые заглушки и избегать непосредственного вызовов методов в .NET. Moles расширяет Pex за счет формирования тестового окружения и гибкого манипулирования драйверами и заглушками. Существует ряд ограничений при использовании указанных инструментов. Во-первых, невозможно обнаруживать ошибки, которые вносятся при параллельном выполнении задач, во-вторых, указанные средства не могут справиться с недетерминизмом. Это приводит к разным результатам при каждом запуске Pex. В-третьих, Pex и Moles не могут быть использованы для анализа кода, который не работает под управлением .NET. Множество поддерживаемых языков ограничено только языком C#. Возможность использования внешнего солвера, отличного от Z3, также не предусмотрена. Еще один подход к автоматизации модульного тестирования был предложен C. Engel и R Hähnle. В работе [8] рассматривается метод автоматической генерации тестов для JAVA CARD, базирующийся на формальной проверке выполнения тестируемого кода. В его основе лежат два подхода к тестированию: по методу “бело- Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 10 307
- 308. го” и “черного”ящика. Автономные модульные тесты в формате JUnit генерируются автоматически. VBT (verification-based test generation) использует полную информацию, содержащуюся в формальной спецификации и лежащую в основе реализацию тестируемого кода (implementation under test, IUT). В качестве языка описания спецификации используется Java Modeling Language (JML). При этом полная функциональная спецификация тестируемого кода не требуется, поскольку генерация тестов реализуется на основе символического исполнения, а заданные в пред- и постусловиях ограничения требуются только для синтеза тестовых оракулов. Система Kiasan [9,13] представляет собой механизм символического исполнения для последовательных Java программ, основанный на фреймворке Bogor, использующем технологию проверки модели (model checking). Предложенный подход был позднее расширен в фреймворке KUnit [9], который автоматически генерирует тесты для контрактно-аннотированых методов и отображает множество объектов (heap objects), получаемых и возвращаемых методами, что может быть использовано разработчиками для анализа сложных методов и диагностики причин ошибок в программе. Фреймворк KUnit использует тестирование по методу “черного ящика” с помощью генерации входных значений на основе символического исполнения, постусловия используются в качестве тестовых оракулов. При наличии формальной спецификации подход, используемый в KUnit, может реализовывать такие техники тестирования, как: разделение на классы эквивалентности, анализ граничных значений. В общем случае традиционное тестирование обычно не основывается на формальной спецификации, в то время, как KUnit требует формального описания требований. Инструмент Unit Meister [10], разработанный компанией Microsoft, использует символическое исполнение для анализа трасс программы. Подход во многом схож с Kiasan, однако существует ряд отличий. Unit Meister включает функциональные символы для композиционной проверки, в то время, как Kisan допускает только исходные символы, а композиционная проверка осуществляется с помощью спецификаций. В то время как Kiasan является полностью автоматическим, Unit Meister, зависимый от решателя системы ограничений, требует от пользователя указания области определения параметров. Symstra [11,12] – еще одно средство символического исполнения для создания минимальной последовательности вызовов публичных методов для проверки класса. Symstra использует примитивные символические значения, конкретные структуры множеств и предполагаемые состояния для генерации неизоморфных конечных состояний. Для генерации подмножества возможных предварительных состояний в Symstra применяются последовательности вызовов публичных методов. В разработанном прототипе предварительные состояния задаются предусловиями и инвариантами. Пользователь может изменять предусловия и инварианты, более точно определяя их значения. 308 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 11
- 309. Одним из инструментов,ориентированных на использование контрактных спецификаций в процессе создания тестов, является AutoTest framework [4]. Он автоматизирует процесс тестирования программного обеспечения, опираясь на программы, содержащие инструменты их собственной проверки, в форме контрактов для классов и отдельных методов. Предусловия и инварианты позволяют ограничить множество входных данных для тестирования, постусловия преобразуются в тестовые оракулы. Основная особенность AutoTest заключается в способе генерации тестов. Тестовые последовательность формируются случайно, опираясь только на предсуловия методов и инварианты классов. Успешность прохождения тестов анализируется в тестовых оракулах. Отдельно стоит отметить механизм Test Extraction, который автоматически создает тесты по результатам отказов программы. Основными ограничениями подхода являются отсутствие гарантий покрытия путей (из-за сугубо случайной генерации тестов), а также поддержка только языка Eiffel и среды EiffelStudio. Все рассмотренные подходы подтверждают эффективность интеграции различных методологий процесса тестирования на практике. Тем не менее, несмотря на достигнутые успехи, каждый из имеющихся подходов использует лишь часть имеющегося потенциала, ограничен анализом программ, написанных на каком-то определенном языке программирования, и не предоставляет единой интеграционной платформы для всего многообразия различных техник верификации ПО. Кроме того, большинство из рассмотренных подходов являются академическими и неприменимы для анализа сложных программных систем. [14,15]. 6 Заключение В результате проведенного исследования разработан подход к синтезу тестов для языка Java, обеспечивающих покрытие трасс исполнения методов. Разработанные методы с помощью применения SMT-солвера генерируют параметры модульных тестов, форсирующие реализацию заданных трасс исполнения. Учет контрактов методов позволяет с одной стороны с помощью постусловий частично автоматизировать синтез тестовых оракулов, а с другой с помощью предусловий ограничивать генерацию параметров тестов. Применение разработанного на основе подхода прототипа на наборе тестовых примеров показало полную работоспособность предложенных методов. Основными направлениями развития теоретических и практических исследований являются: разработка новых алгоритмов генерации множественных тестов, более эффективно распределяющих значения переменных по области определения; совершенствование анализатора (прототипа) с целью обеспечения анализа более широкого класса Java-программ; Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 12 309
- 310. расширение функциональныхвозможностей и реализация подхода генерации модульных тестов для программ, написанных на других языках программирования. Литература 1. Contracts for Java. https://code.google.com/p/cofoja/ 2. Meyer, B.: Design by Contract, in Advances in Object-Oriented Software Engineering, eds. D. Mandrioli and B. Meyer, Prentice Hall, 1991, pp. 1–50 3. Z3 An Efficient SMT Solver. http://z3.codeplex.com/ 4. B. Meyer, I. Ciupa, A. Leitner, A. Fiva, Yi Wei, E. Stapf: Programs that Test Themselves, IEEE Computer, vol. 42, no. 9, pages 46-55, September 2009 5. Nikolai Tillmann and Jonathan De Halleux. Pex: white box test generation for .net. In Proceedings of the 2nd international conference on Tests and proofs, TAP’08, pages 134–153, Berlin, Heidelberg, 2008. Springer-Verlag 6. Pex and Moles. http://research.microsoft.com/en-us/projects/pex/ 7. Unit Testing with Microsoft Moles. http://research.microsoft.com/enus/projects/pex/molestutorial.pdf 8. Engel, C., Hähnle, R.: Generating unit tests from formal proofs. In: Gurevich, Y. (ed.) Proceedings, Testing and Proofs, Zürich, Switzerland. LNCS, Springer,Heidelberg, 2007 9. Deng, X., Robby, Hatcliff, J.: Kiasan/KUnit: Automatic Test Case Generation and Analysis Feedback for Open Object-oriented Systems. In: Proceedings of the Testing: Academic and Industrial Conference Practice and Research Techniques, Washington, 2007 10. Nikolai Tillmann, and Wolfram Schulte. Parameterized unit tests with unit meister. ESEC/SIGSOFT FSE, page 241-244. ACM, 2005 11. T. Xie, D. Marinov, W. Schulte, and D. Notkin. Symstra: A framework for generating objectoriented unit tests using symbolic execution. In TACAS ’05: 11th International Conference on Tools and Algorithms for the Construction and Analysis of Systems, volume 3440 of LNCS, pages 365–381. Springer-Verlag, Apr. 2005 12. Symstra: A Framework for Generating Object-Oriented Unit Tests using Symbolic Execution. http://people.engr.ncsu.edu/txie/publications/tacas05.pdf 13. Robby: Bogor/Kiasan: Combining symbolic execution, model checking, and theorem proving. Presentation at European Science Foundation Exploratory Workshop on Challenges in Program Verification, University of Nijmegen (October 2006) 14. J. Henkel and A. Diwan. Discovering algebraic specifications from Java classes. In ECOOP ’03: European Conference on Object-Oriented Programming, pages 431–456, 2003 15. T. Robschink and G. Snelting. Efficient path conditions in dependence graphs. In ICSE ’02: Proceedings of the 24th International Conference on Software Engineering, pages 478–488, New York, NY, USA, 2002. ACM Press 310 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 13
- 311. ДИАГРАММЫ КЛАССОВ ООП: ФОРМАЛИЗАЦИЯИ АНАЛИЗ Дмитрий Буй1 , Сергей Компан2 Киевский национальный университет имени Тараса Шевченка, Украина 1 buy@unicyb.kiev.ua, 2 robin_2005@mail.ru Аннотация В статье приводится короткий сравнительный анализ работ, посвящённых формальным моделям объектно-ориентированного программирования (ООП). Предмет исследования – модель диаграммы классов (соответствующее частично упорядоченное множество). Модель класса (спецификация класса) —- пара бинарных функциональных отношений, одна компонента уточняет атрибуты, вторая — методы. Наследование уточняется как включение графиков функций. Над классами вводятся две операции –– пересечение и сочленение. Формальные результаты: структура частично упорядоченного множества классов, свойства операции наложения, в терминах которой вводится операция сочленения: идемпотентность, ассоциативность, критерий коммутативности. Модель диаграммы классов можно использовать для анализа структуры классов, который может помочь для выделения подсистем клонов и оптимизации самой диаграммы. Ключевые слова: формальные модели ООП, диаграммы классов, спецификация класса, операции над классами, клон 1. Вступление Основы объектно-ориентированного подхода (ООП) были заложены в конце 60-х годов. В основе ООП лежит объектная модель данных (ОМД). Появление ОМД связано с появлением абстрактных типов данных. В 1971 году Парнас (D. L. Parnas) в работе [1] предложил идею инкапсуляции (сокрытия информации). В 80-х годах ХХ столетия Г. Буч (G. Booch) в своей книге [2] предложил использовать идеи ООП для разработки программных продуктов промышленного уровня. Благодаря ООП появилась потенциальная возможность выхода из кризиса, связанного с проектированием и реализацией сложных программных систем (ПС). Таким образом, ООП стало очередной ступенью к созданию методов разработки надежных ПС. В результате ускорился процесс создания программных комплексов, в основе которого лежат принципы ООП, а так же качественно снизился уровень сложности разработки ПС. Согласно ООП предметная область (ПрО) представляется как множество объектов со свойствами, которые необходимы для определения и идентификации объектов, а также описаниями их поведения в рамках выбранной системы понятий на зафиксированном уровне абстракции. Предметная область, Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 311
- 312. которая моделируется объектами,сама является объектом и поэтому может быть отдельным объектом в составе другой ПрО. При моделировании объект ПрО получает хотя бы одно свойство, необходимое для его идентификации в множестве объектов ПрО [3]. В основе ООП лежат: абстракция, инкапсуляция, наследование, полиморфизм. Язык программирования, в котором реализованы эти понятия, является объектно-ориентированным и именно они придают языку гибкость при программной реализации сущностей ПрО. 2. Краткий анализ современного состояния ООП Сразу необходимо заметить, что в связи с популярностью ООП как средства проектирования и разработки ПС существует достаточное количество соответствующей литературы [2–11]. Следует отметить ряд работ заведующей отделом Института программных систем НАН Украины, профессора Лаврищевой Е.М. [3,10,12], в которых уделяется большое внимание проектированию и программированию систем, в основе которых лежит ООП. Автор предлагает выделять четыре уровня абстрактного представления объектной модели (ОМ): обобщающий, структурно-упорядоченный, характеристический и поведенческий. На каждом из этих уровней применяется свой математический аппарат [10]. Отметим, что существует группа OMG (Object Management Group), в основе деятельности которой лежит пропагандирование и стандартизация ООП. Эта группа описала набор стандартов OMA (Object Management Architecture). Самым известным и широко применяемым на сегодняшний день является CORBA (Common Object Request Broker Architecture) —- спецификация взаимодействия разнотипных объектов в распределенной системе [13]. В данной модели для описания понятий применяется декларативный язык определения интерфейсов IDL (Interface Definition Language). Для полной уверенности в том, что информационная система, построенная на основе ООП, будет удовлетворять исходным спецификациям и стабильно работать (будет гарантоустойчивой по терминологии [14]), необходимо выделить компоненты системы, формально их описать и верифицировать. В результате возникла необходимость формального определения понятий объекта, класса, операций над объектами и т.д. Для ООП построены формальные модели. Например, в работе [15] формально даётся определение основных понятий ООП: класса, объекта, наследования, инкапсуляции, полиморфизма с использованием математического аппарата теории множеств, функций, абстрактных автоматов (в этой же работе приводится обширная библиография по ООП). В работе [16] авторы строят формальную модель для объектных баз данных (БД), в основе которой лежит теория категорий. В [17, 18] даны формальное определение основных понятий ООП, в основе определения которых лежит композиционное программирование, созданное академиком НАН Украины В. Н. Редько [19–21]. Особое внимание следует уделить вопросу построения объектной модели для объектных БД, так как в основе более-менее сложной информационной 312 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 313. системы лежит именноБД. Широкое распространение ООП резко обозначило проблему семантического разрыва между моделью языка программирования и моделью представления данных в БД. Объектная модель позволяет оперировать сложными структурами данных. В результате системы управления базами данных (СУБД) стали развиваться в трех направлениях. Первое — это построение отображения объектов в традиционную реляционную модель данных. Второе — включение понятий ООП в реляционные СУБД путем расширения типов данных, используемых в БД. Третье направление -— создание принципиально новых, объектно-ориентированных СУБД, которые в своей работе следуют стандарту ODMG [22]. В [23] авторы формально строят модель данных, в которую входят: конечное множество основных типов D, счетное множество объектных идентификаторов O, множество имен атрибутов A, множество имен методов M , множество имен классов C. Так как объект может содержать в себе данные, то различают примитивные значения (atomic values) и сложные значения (structured values). После этого авторы приводят синтаксическое описание класса (неформальное). Даётся формальное определение метода, который является функцией, отображающей сигнатуру в тело функции. Сигнатура формально описывается следующим образом — c : m(τ1 , τ2 , . . . , τn ) → τr , где c -– имя класса, которому принадлежит метод, m —- имя метода, τ1 , τ2 , . . . , τn — список типов параметров и τr — тип возвращаемого значения. Также в статье упоминается простое наследование, которое формально не определено. Приводится формальное определение объекта, который задаётся тройкой (o, ν, c), где o ∈ O —- идентификатор объекта,v — значение объекта, c ∈ C — класс, которому принадлежит объект. Также приводится формальное определение объектной БД. БД содержит схему (Schema) и экземпляры схемы (Instances). Схема описывается тройкой (C, σ, G), где C — как и ранее множество имен классов БД, σ — функция, которая сопоставляет именам классов собственно классы, G — множество глобальных переменных классов. Множества C и G выступают в качестве точки входа в БД. Экземпляры схемы БД содержат конечное множество объектов и четыре функции: πd — назначает объектам уникальные объектные идентификаторы (oid), π -— функция, которая по объекту определяет идентификатор oid, присвоенный объекту функцией πd , υ — функция, которая сопоставляет объектным идентификаторам значения всех находящихся в БД объектов, γ -— функция, которая присваивает значения глобальным переменным объектов. Вкратце обсудим построение объектной алгебры. По аналогии с реляционной моделью данных, в основе которой лежит реляционная алгебра Кодда, для ООП также рассматривают так называемую объектную алгебру, носителем которой является множество объектов [23–25]. Различаются эти алгебры только сигнатурными операциями над объектами. В [26] авторы вводят операции пересечения и сочленения (в работе она называлась объединением) над классами. В результате предлагается рассматривать вместо объектной алгебры алгебраическую систему. Формально ее можно описать как O, K; Ωobj ; Ωspec , ≤, где O -— множество объектов классов, K -— Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 313
- 314. множество классов (спецификацийклассов), Ωobj — множество операций над объектами, Ωspec -— множество операций над классами, а отношение ≤⊆ K × K —- отношение частичного порядка, которое уточняет отношение наследования классов. 3. Постановка задачи Рис. 1. Диаграмма классов ПрО “Школа” Построение новой сложной системы, как правило, сопряжено с нетривиальными усилиями. В результате для построения сложной системы можно пойти двумя путями. Первый предполагает реализацию системы с нуля. При таком подходе одним из критериев успешного выполнения проекта является время реализации. Как правило, ограничение авторского коллектива во времени приводит к тому, что для проверки правильности программ коллектив выбирает тестирование вместо построения формальной модели и доказательства правильности работы такой формальной модели. Второй путь предполагает изучение уже реализованных подобных систем, с целью переноса работоспособной части функционала в новую систему. При таком подходе, если он целесообразный, мы можем эффективно использовать уже работающие компоненты других систем, при этом мы можем столкнуться с ситуацией, 314 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 315. Рис. 2. Диаграммаклассов ПрО “ВУЗ” при которой в новую систему могут попасть “одинаковые” (в том или ином смысле) части кода (атрибуты и методы) — т.н. клоны. Для уменьшения избыточности кода (устранения клонов) в программе авторы статьи предлагают выносить общие части программы (атрибуты и методы) в новые классы, совокупность которых будет выступать аналогом FrameWork. При моделировании ПрО авторы не берут смелость утверждать, что ПрО смоделирована в полной мере. Главная цель данного моделирования — показать идею использования операций над классами. Пусть необходимо написать программу “Учебное заведение”, которая может использоваться как в школе, так и в ВУЗе. К примеру, пусть проведённый анализ созданного ПО по данной ПрО показал, что существуют готовые решения для школы (рис. 1) и для ВУЗа (рис. 2), но которые реализовывают только часть нашей ПрО. Для реализации нашей задачи можно объединить (сочленить) функциональные части исходных программ в одну. В результа- Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 315
- 316. те получим новуюдиаграмму классов (рис. 3), относительно которой сделаем несколько замечаний. Как указывается в обзоре [27] клоны могут быть удале- Рис. 3. Диаграмма классов ПрО “Школа и ВУЗ” ны с использованием операций “выделение метода” (Extract Method) и “Подъем метода” (Pull Up Method), изложенных в монографии [28]. Выделение метода (в русскоязычной литературе называемое процедурной абстракцией) заключается в выделении общего кода в новую функцию (или метод класса, если речь об ООП). Подъем метода заключается в перемещении общего мето- 316 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 317. да двух классовв их базовый класс. Если два класса не являются потомками одного базового класса, то перед операцией Подъема метода можно создать новый базовый класс при помощи операции выделения родительского класса (Extract Superclass) [29]. В нашем подходе могут быть также выделены и общие атрибуты. Фактически своими преобразованиями над спецификациями классов мы изменяем внутреннюю структуру программ, не затрагивая их поведения и в какой-то степени улучшаем понимание кода. Целью работы является разработка теории ООП при минимальных предположениях о этой ПрО. Мы разделяем атрибуты и методы и рассматриваем функции, которые присваивают атрибутам и методам семантику (пока не уточняя какую именно семантику; это будет сделано при последующей конкретизации). Мы надеемся, что формальные результаты, представленные в следующем разделе, обосновывают право на существование выбранного нами уровня абстракции. По сути, в работе реализован принцип “разделяй и властвуй”. 4. Математические результаты Приведем формальное уточнение класса (синоним — спецификации класса). Под классом будем понимать пару s, µ , где s —- функциональное бинарное отношение, которое атрибуту ставит в соответствие его тип (множество значений из универсального домена D), а µ —- функциональное бинарное отношение (функция), которое сигнатуре метода ставит в соответствие его реализацию (семантику, логику). Можно рассматривать µ как функциональное бинарное отношение, которое сигнатуре метода ставит в соответствие его тип; в этом случае получим определение интерфейса.1 Отношение наследования ≤ между классами уточняется так: s, µ ≤ s′ , µ′ , если s ⊆ s′ и µ ⊆ µ′ . Приведем несколько определений, которые понадобятся в дальнейшем при изложении материала. Определение 1. Пусть α,β — функциональные бинарные отношения, тогда операция наложения определяется так: α▽β = β α | (domα domβ), где domα и domβ области определения соответственно функций α и β, а 2 γ | X — ограничение функции γ по множеству X, т.е. γ | X = γ (X ×π2 γ) 2 (π2 γ — проекция отношения γ по второй компоненте). Наложение иллюстрируется на рис. 4. Уточним бинарную операцию сочленения и пересечения ∩ классов. Обозначим K — множество классов, K ∈ K — класс. Операция сочленения является операцией вида: : K × K → K, где s1 , µ1 s2 , µ2 = = s1 ▽s2 , µ1 ▽µ2 . 1 Несмотря на то, что тип метода входит в сигнатуру, нам для построения функционального бинарного отношения необходимо разделять (считать разными) методы, сигнатура которых отличается только типом возвращаемого значения. Такой подход необходим для исследования интерфейсов. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 317
- 318. dom dom Рис. 4. Графическаяинтерпретация операции наложения α▽β (β имеет приоритет Операция сочленения классов уточняет множественное наследование классов. При сочленении классов K1 и K2 получим новый класс K3 , для которого классы K1 и K2 будут базовыми (родительскими) классами, а класс K3 будет играть роль производного. В производном классе K3 классы K1 и K2 являются дополнением (расширением) одного к другому. Рассмотрим важнейшие частные случаи: 1) doms1 doms2 = ∅ и domµ1 domµ2 = ∅ — т.е. в классах-аргументах нет одинаковых атрибутов и методов. Тогда получим производный класс вида K3 = s1 s2 , µ1 µ2 ; 2) doms1 doms2 �= ∅ или (и) domµ1 domµ2 �= ∅. Тогда возникает конфликт имен и нужно определить по определённому критерию (правилу), какой именно атрибут (метод) необходимо добавлять в производный класс; конфликт разрешается с помощью операции наложения. Операция пересечения классов является операцией вида: ∩ : K × K → K, где s1 , µ1 ∩ s2 , µ2 = s1 s2 , µ1 µ2 , здесь — обычное теоретико-множественное пересечение. При пересечении классов K1 и K2 получим новый класс K3 , для которого классы K1 и K2 будут производными, а класс K3 будет играть роль базового (суперкласса). Классы K1 и K2 являются дополнением (расширением) суперкласса. Сделаем несколько замечаний по поводу введенного определения класса. Если первая компонента класса s, µ пуста (т.е. s = ε — пустое бинарное отношение), то получим определение библиотеки. Если же проекция по 2 второй компоненте отношения µ (т.е. π2 µ) является множеством множеств, которые интерпретируется как области значений функций-семантик методов, то получим определение интерфейса. Определение 2. Бинарное отношение совместности ≈ в классе функциональных бинарных отношений вводится так: α ≈ β ⇔ α | X = β | X, где X = domα domβ. Содержательная интерпретация: функциональные отношения совместны, если они ведут себя одинаково на общих аргументах. 318 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 319. При доказательстве свойствопераций над классами и установлении структуры семейства классов будут использоваться следующие абстрактные свойства ограничения [30]. Ниже U1 , U2 , . . . — произвольные бинарные отношения, X, X1 , . . . — произвольные множества, α, β, . . . — как и ранее, произвольные бинарные функциональные отношения. Параметрический оператор U �→ U | X обозначен через ↑ X, ◦ — традиционная композиция бинарных 2 отношений, πi α — проекция бинарного отношения по i-той компоненте. Предложение 1 (свойства ограничения). Ограничение имеет свойства: 1) U1 ⊆ U2 ∧ X1 ⊆ X2 ⇒ U1 | X1 ⊆ U2 | X2 (монотонность ограничения, монотонность оператора ↑ X); 2 2 2) π1 (U | X) = π1 U X (проекция ограничения); 2 3) U | X = ε ⇔ π1 U X = ∅ (критерий пустоты ограничения); в частности, ε | X = U | ∅ = ε (сохранение ограничением пустого отношения и пустого множества); 2 2 4) U | X = U | (X π1 U ), U = U | π1 U ; в частности, 2 π1 U ⊆ X ⇒ U | X = U ; 5) (U | X) | Y = U | (X Y ), в операторном виде ↑ Y ◦ ↑ X =↑ (X Y ) (композиция ограничений); в частности, ↑ X◦ ↑ X =↑ X (идемпотентность оператора ↑ X); 6) U | X ⊆ U (оператор ↑ X убывающий); 7) оператор ↑ X является оператором замыкания (т.е. монотонным, убывающим и идемпотентным оператором) относительно теоретикомножественного включения ⊆; 8) ( Ui ) | X = (Ui | X), U | Xi = (U | Xi ) (дистрибутивность i i i i ограничения относительно объединений); 9) ( Ui ) | X = (Ui | X), U | Xi = (U | Xi ) (дистрибутивность i i i i ограничения относительно пересечений); 10) α ⊆ β ∧ X ⊆ domα ⇒ α | X = β | X; в частности, α ⊆ β ⇒ α = β | domα, α ⊆ β ∧ domα = domβ ⇒ α = β; Очевидно, что операция наложения, вообще говоря, некоммутативная. Таким образом, возникает вопрос о поиске соответствующего критерия. Ответ приведен в следующем утверждении. Предложение 2 (критерий коммутативности операции наложения). Для произвольных функциональных бинарных отношений α и β выполняется эквивалентность α ≈ β ⇔ α▽β = β▽α. � Следствие 1. Пусть α, β –– функциональные бинарные отношения. Тогда имеют место следующие эквивалентности: α▽β = β▽α ⇔ α▽β = α β α▽β = β▽α ⇔ β▽α = β α. � Следствие 2 (критерий совместности функций). Пусть α, β —- функциональные бинарные отношения. Тогда следующие утверждения эквивалентны: Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 319
- 320. 1) 2) 3) 4) 5) α ∪ β— функциональное бинарное отношение; α▽β = β▽α; α▽β = α ∪ β; α ≈ β; β▽α = β ∪ α. � Доказательство. Доказательство проводится с использованием свойства отношения совместности ≈ [31]: α ≈ β ⇔ α β функциональное бинарное отношение. Для проведения доказательств последующих утверждений важна следующая лемма. Лемма 1. Пусть α, β —- функциональные бинарные отношения. Тогда α β = (α β) | (domα domβ). � Следствие 3. Для функциональных бинарных отношений α, β выполняются две эквивалентности α ≈ β ⇔ dom(α β) = domα domβ, α �≈ β ⇔ dom(α β) ⊂ domα domβ. � Следствие 4. Для функциональных бинарных отношений α, β выполняются две эквивалентности α ≈ β ⇔ α β = α | (domα domβ), α ≈ β ⇔ α β = β | (domα domβ). � Следующее следствие дополняет cледствие 2. Следствие 5 (критерий совместности функций). Пусть α, β —- функциональные бинарные отношения. Тогда следующие утверждения эквивалентны: 1) 2) 3) 4) α ≈ β; dom(α β) = domα domβ; α β = α | (domα domβ); α β = β | (domα domβ). �; Что касается самой операции наложения, то ее свойства приведены в следующем утверждении. Предложение 3 (свойства наложения). Пусть α, β —- функциональные бинарные отношения. Тогда имеют место следующие утверждения: 1) 2) 3) 4) 320 α▽α = α (идемпотентность); α▽β �= β▽α, вообще говоря; α▽β = β▽α ⇔ α ≈ β (критерий коммутативности); (α▽β)▽γ = α▽(β▽γ) (ассоциативность). � Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 321. Доказательство. Докажем только4 пункт. Будем использовать очевидное равенство dom(α▽β) = domα domβ. Используя определение наложения и свойства ограничения (предложение 1) имеем цепочку равенств: (α▽β)▽γ = (β ∪ α | (domα domβ))▽γ = = γ ∪ (β ∪ α | (domα domβ)) | (domα ∪ domβ) domγ = = γ ∪ (β ∪ α | (domα domβ)) | ((domα domγ) ∪ (domβ domγ)) = = γ ∪ β | (domα domγ) ∪ β | (domβ domγ) ∪ α | (domα domβ) | | (domα domγ) ∪ (α | (domα domβ)) | (domβ domγ) = = γ ∪ β | (domα domγ) ∪ β | (domβ domγ) ∪ α | | (domα domβ) ∩ (domα domγ) ∪ α | (domα domβ) ∩ (domβ domγ) = = γ ∪ β | (domα domγ) ∪ β | (domβ domγ) ∪ α | | domα (domβ ∪ domγ) ∪ ε = γ ∪ β | (domβ domγ) ∪ α | | (domα (domβ ∪ domγ)) ∪ β | (domα domγ) = = γ ∪ β | (domβ domγ) ∪ α | (domα (domβ ∪ domγ)). (1) Прокомментируем неочевидные переходы. Переход от первого выражения ко второму и от второго к третьему сделали по определению наложения; при переходе от третьего к четвертому выражению воспользовались стандартным теоретико-множественным свойством (A ∪ B) C = A C ∪ B C; при переходе от четвертого к пятому выражению — дистрибутивностью ограничения относительно объединений (предложение 1); при переходе от пятого к шестому — свойством ограничения (α | A) | B = α | (A ∩ B) (предложение 1); при переходе от шестого к седьмому — теоретико-множественным равенством (A B) ∩ (A C) = A (B ∪ C) и свойством ограничения α | ((domα domβ) ∩ (domβ domγ)) = α | ∅ = ε (предложение 1); при переходе от восьмого к девятому — свойствами ограничения (предложение 1) α | B = α | (domα ∩ B), A⊆B⇒α|A⊆α|B и β | domα domγ = β | domβ ∩ (domα domγ) ⊆ β | domβ domγ. Перейдем к правой части равенства: α▽(β▽γ) = α▽(γ ∪ β | (domβ domγ)) = = γ ∪ β | (domβ domγ) ∪ α | (domα (domβ ∪ domγ)). Из (1), (2) и вытекает доказываемое равенство. (2) � Пусть F — класс всех функциональных бинарных отношений (на некотором зафиксированном универсуме D). Очевидно, что F, ⊆ — частично упорядоченное множество (ч. у. м.). Перейдем к установлению его структуры. Здесь имеют место два следующих утверждения (для ч. у. м. используем терминологию [32]). Предложение 4. Ч. у. м. F, ⊆ есть нижняя полурешетка, причем inf {f, g} = f ∩ g. � Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 321
- 322. Доказательство. Доказательство следуетиз того, что F, ∩ есть коммутативная идемпотентная полугруппа, и хорошо известной связи между такими полугруппами и нижними полурешетками,(см., например, [32]). Таким образом, в терминах классов наибольшая общая часть двух классов существует всегда, но она может быть пустой. Более полную информацию о ч. у. м. F, ⊆ даёт следующее утверждение. Предложение 5 (структура ч. у. м. F, ⊆). Выполняются следующие утверждения: 1) Всюду неопределённая функция f∅ — наименьший элемент (“дно”) ч. у. м. F, ⊆. 2) Наибольший элемент в ч. у. м. F, ⊆ существует тогда и только тогда, когда универсум D — не больше чем одноэлементный. 3) Точная нижняя грань (инфимум) существует для любого непустого множества F , причем inf F = ∩f ∈F f . 4) Точная верхняя грань множества F (супремум) существует тогда и только тогда, когда множество F ограничено сверху, при этом sup F = ∪f ∈F f . 5) Элемент f является атомом тогда и только тогда, когда график f — одноэлементный, т.е. f есть функцией вида f : {x} → {y}. 6) Ч. у. м. F, ⊆ является условно полным ч. у. м. и полной (верхней) полурешеткой (complete semilattice). Так как отношение наследования ≤ на классах вводится покомпонентно (эквивалентно: операцией прямого произведения порядков), то свойства ч. у. м. F, ⊆ переносятся на ч. у. м. K, ≤: например, f∅ , f∅ — наименьший элемент и т.д. Приведем соответствующий классический результат (см., например, [33]). Пусть D1 , ≤1 , D2 , ≤2 — два ч. у. м. Их прямое произведение определяется стандартно: D1 × D2 , �, где d1 , d2 � d′ , d′ ⇔ d1 ≤1 1 2 d′ ∧ d2 ≤2 d′ . Для точных граней имеют место формулы: 1 2 2 2 sup L ≃ sup π1 L, sup π2 L , D1 ×D2 D1 2 2 inf L ≃ inf π1 L, inf π2 L , D1 ×D2 D1 (3) D2 (4) D2 L ⊆ D1 × D2 . Здесь ≃ обобщенное равенство (сильное равенство Клини). Формулы (3) и (4) и позволяют переносить свойства ч. у. м. F, ⊆ на ч. у. м. K, ≤. Приведённые формальные результаты могут иметь практическое значение при анализе диаграмм классов. Это во-первых, выделение компонент связности в соответствующем графе (по терминологии [32] речь идет о разложении ч. у. м. в кардинальную сумму). Выделение компонент соответствует декомпозиции системы на подсистемы. Во-вторых, в диаграмме классов можно 322 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 323. проводить поиск клоновдля их элиминации (по этой проблематике см. [29]). Наконец, в-третьих, диаграмму классов можно подвергнуть модификации с помощью операций сочленения и пересечения с целью оптимизации по соответствующему критерию. 5. Результаты, выводы В работе приведен короткий анализ доступной библиографии по ООП, уточняются классы ООП в виде пар функциональных бинарных отношений. Бинарное отношение, являющееся первой компонентой, атрибутам приписывает их типы (значения); отношение, являющееся второй компонентой, сигнатурам методов приписывает их семантику (тип значений функции — семантики для интерфейса). Над классами рассматриваются операции пересечения и сочленения. Пересечение классов вводится на основе стандартного теоретико-множественного пересечения бинарных отношений, а сочленение — на основе специальной операции наложения, которая позволяет разрешить конфликт имен. Указанные операции над классами могут быть использованы при рефакторинге (refactoring) программ. Наследование классов уточняется в виде стандартного теоретико-множественного включения между соответствующими компонентами классов. В работе получены следующие основные математические результаты: – установлены основные свойства наложения (идемпотентность, ассоциативность, критерий коммутативности в терминах отношения совместности); – структура ч. у. м. множества всех функциональных бинарных отношений, упорядоченного по включению (это ч. у. м. является нижней полурешеткой; всюду неопределённая функция является наименьшим элементом; инфимумы непустых подмножеств существуют всегда, супремумы подмножеств существуют тогда и только тогда, когда подмножества ограничены с верху; для точных граней приведены формулы их нахождения). Предложенная формальная модель может использоваться для анализа и модификации диаграмм классов: – нахождения компонент связности, что соответствует декомпозиции системы на подсистемы; – поиска клонов; – модификации диаграмм с помощью введенных операций пересечений и сочленения. Что касается дальнейших математических исследований, имеющих содержательную интерпретацию, то это, например, установление взаимной дистрибутивности рассматриваемых операций. Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 323
- 324. Список литературы 1. Parnas,D. On the Criteria to Be Used in Decomposing Systems into Modules, in Classics in Software Engineering. Magazine Communications of the ACM, Volume 15, Issue 12, Dec. 1972, p. 1053–1058 (1972) 2. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. : Пер. с англ. Москва: ООО “И.Д. Вильямс”, 2008. —- 720 с. (2008) 3. Лаврищева Е. М. Методы программирования: теория, инженерия, практика. Киев: Наукова думка, 2006. —- 451 с. (2006) 4. Wirfs-Brock R. Designing Object-Oriented Software. Prentice Hall, New Jersey, 1990. —- 341 p. (1990) 5. Шлеер С. Объектно-ориентированный анализ: моделирование мира в состояниях. Киев: Диалектика, 1993. —- 238 с. (1993) 6. Бадд Т. Объектно-ориентированное программирование в действии. Питер, 1997. — 464 с. (1997) 7. Гамма Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб: Питер, 2001. —- 368 с. (2001) 8. Мухортов В. В. Объектно-ориентированное программирование, анализ и дизайн. Методическое пособие. Новосибирск, 2002. — 108 с. (2002) 9. Грэхем И. Объектно-ориентированные методы. Принципы и практика. 3-е издание. Москва: ООО “И.Д. Вильямс”, 2004. —- 880 с. (2004) 10. Лаврищева Е. М. Сборочное программирование. Основы индустрии программных продуктов. Киев: Наукова думка, 2009. — 371 с. (2009) 11. Фридман А. Л. Основы объектно-ориентированной разработки программных систем. Москва: “Финансы и статистика”, 2000. — 192 с. (2000) 12. Лаврищева Е. М. Интерфейс в программировании. Киев: Проблеми програмування, №2, 2007. С. 126–139 (2007) 13. The Common Object Request Broker: Architecture and Specification -– OMG, www.omg.org/spec/CORBA/3.3/ 14. Безопасность критических инфраструктур: математические и инженерные методы анализа и обеспечения / под ред. Харченко В. С. – Министерство образования и науки Украины, Национальный аэрокосмический университет им. Н. Е. Жуковского “ХАИ”, 2011. — 641 с. (2011) 15. Пискунов А. Г. Формализация парадигмы объектно-ориентированного программирования, www.realcoding.net/dn/docs/machine.pdf 16. Richta, Karel,Toth, David. Formal Models of Object-Oriented Databases. In Objekty ˇ ˇ ˇ 2008. Zilina: Zilinsk´ univerzita v Ziline, Fakulta riadenia a informatiky, 2008, a p. 204-217, www.ksi.mff.cuni.cz/ richta/publications/richta-toth-Objekty2008.pdf 17. Buy, Dmitriy, Kompan, Sergiy. The Concepts of Object, Class, Inheritance, Life Cycle: Formalization. First International Workshop “Critical infrastructure safety and security” (CrlSS-Dessert’11), Kirovograd, Ukraine, May 11-13, 2011, p. 236244 (2011) 18. Буй Д. Б., Компан С. В. Уточнення множинного успадкування у виглядi операцiї накладання. Вiсник Київського нацiонального унiверситету iменi Тараса Шевченка, Серiя: Фiзико-математичнi науки, випуск №4, 2012, c. 111-119 (2012) (на украинском языке) 19. Редько В. Н. Композиции программ и композиционное программирование. Программирование. — 1978. — № 5. С. 3-24 (1978) 324 Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 325. 20. Редько В.Н. Основания композиционного программирования. Программирование. — 1979. — № 3. С. 3-13. (1979) 21. Редько В. Н. Экзистенциальные основания композиционной парадигмы. Кибернетика и системный анализ. — 2008. — № 2. С. 3-12 (2008) 22. Object Data Management Group. http://www.odbms.org/odmg/ 23. Sarkar, Manojit, Reiss, Steven P. A Data Model and A Query Language for Object-Oriented Database. Island, Department of Computer Science Brown University Providence, Rhode, December 1992, citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.4531rep=rep1type=pdf (1992) 24. Shaw Gail M., Zdonik Stanley B. A Query Algebra for Object-Oriented Databases. Island, Department of Computer Science. Brown University Providence, Rhode, March 1989, trac.common-lisp.net/elephant/rawattachment/wiki/RelationalAlgebra/shaw89query.2.pdf 25. Suri, Pushpa R., Rani, Sudesh. Database Algebras. Journal of Theoretical and Applied Information Technology, 2005, p. 595-602, www.jatit.org/volumes/researchpapers/Vol4No7/7.pdf 26. Буй Д. Б., Компан С. В. Операции объединения и пересечения спецификаций классов в многосортной алгебраической системе для объектно-ориентированного программирования. Сборник научных трудов SWorld. Материалы международной научно-практической конференции “Современные проблемы и пути их решения в науке, транспорте, производстве и образовании’2012”. — Выпуск 4. Том 3. — Одесса: КУПРИЕНКО, 2012. —- ЦИТ: 412-1264, c. 45-49 (2012) 27. Roy C. K. A survey on software clone detection research // SCHOOL OF COMPUTING TR 2007-541, QUEEN’S UNIVERSITY. 2007. — Vol. –115. (2007) 28. Фаулер М. Рефакторинг. Улучшение существующего кода. — Символ-Плюс, 2008. (2008) 29. Булычев П. Е. Алгоритмы вычислений подобия в задачах верификации и реструктуризации программ. Диссертация на соискание ученой степени кандидата физико-математических наук: спец. 05.13.11 “Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей” — Москва: 2010. — 169 с. (2010) 30. Буй Д. Б., Кахута Н. Д. Властивостi теоретико-множинних конструкцiй повного образу та обмеження. — Вiсник Київського унiверситету iм. Т. Шевченка. Сер. “Фiз.-мат. науки”, 2005. — Вип. 2. С. 157-170 (2005) (на украинском языке) 31. Буй Д. Б. Властивостi вiдношення конфiнальностi та устрiй множини часткових функцiй. / Д. Б. Буй, Н. Д. Кахута // Вiсник Київського унiверситету iм. Т. Шевченка. Сер. “Фiз.-мат. науки”, 2006. — Вип. 2. С. 125-135 (2006) (на украинском языке) 32. Скорняков Л. А. Элементы теории структур. — Москва: “Наука”, 1982. — 158 с. (1982) 33. Burbaki. N. Elements de Mathematique. Premiere Partie. Les Structures Fondamentals de L’Analise. Livre 1. Theorie Des Ensembles. Chapter III, section 1. 1958 (1958) Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 325
- 326. 326 Международная научно-практическая конференция:ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
- 327. Партнеры TMPA-2013 Международная научно-практическаяконференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ 327
- 330. ISTQB. Наша миссия. • Мы пропагандируем значимость тестирования программного обеспечения как профессии среди частных лиц и организаций. • Мы помогаем тестировщикам программного обеспечения быть более эффективными и результативными в своей работе за счет обучения и сертификации компетенций. • Мы предоставляем тестировщикам возможность карьерного роста за счет многоуровневой сертификации, которая дает навыки и знания, необходимые для выполнения возрастающих обязанностей, а также возможность достижения высшего профессионализма. • Мы постоянно улучшаем Свод знаний по тестированию, опираясь на наилучшие практики в отрасли и самые инновационные исследования, и мы делаем эти знания свободно доступными для всех. • Мы устанавливаем критерии аккредитации образовательных учреждений для обеспечения полноценного предоставления Свода знаний во всем мире. • Мы регулируем содержание и охват экзаменационных вопросов, процесс сдачи экзаменов и выдачу сертификатов официальными органами сертификации. • Мы являемся открытым международным сообществом, стремимся к обмену знаниями, идеями и инновациями в тестировании программного обеспечения. • Мы поддерживаем отношения с научными кругами, правительствами, СМИ, профессиональными объединениями и другими заинтересованными сторонами.
- 331. ISTQB ® можетрассчитывать на 45 коллегий-членов, представляющие 69 стран, которые обеспечивают более 90% всемирного ВВП Российская Коллегия по Квалификации Тестировщиков Программного Обеспечения (RSTQB) www.rstqb.org info@rstqb.org www.fb.com/rstqb
- 334. В связи сразвитием промышленного и жилищного строительства транспортные потоки через город Кострому в последние годы резко увеличились. Город расположен на обоих берегах реки Волги, которые связывает единственный автопешеходный 4-х полосный мост, построенный еще в 70-е годы прошлого столетия. Ближайшие мосты через реку Волга находятся в соседних субъектах Российской Федерации - городе Ярославле и городе Кинешме Ивановской области. Мост в Костроме имеет не только общегородское и региональное, но и федеральное значение, так как связывает крупнейшие города Центра России с Уралом и Сибирью по маршруту Москва – Ярославль – Кострома – Киров – Пермь – Екатеринбург и далее. Ежедневно через мост проходит свыше 43 000 единиц транспорта. В часы пик пробки на въезде на мост создают угрозу транспортного коллапса. Кроме того, ограниченность пропускной способности моста, являющегося главной городской транспортной артерией, тормозит развитие жилищного и промышленного строительства в городе Костроме. В связи с ежегодно увеличивающейся нагрузкой и несвоевременным проведением ремонтов состояние моста в настоящее время близко к критическому. На проведение капитального ремонта, по оценкам специалистов, необходимо от 500 до 700 млн. рублей. Данные денежные средства в городском и областном бюджетах отсутствуют. Вместе с тем проведение капитального ремонта моста не решит вопрос увеличения его пропускной способности. Решением данной транспортной проблемы может стать строительство в городе Костроме в дополнение к существующему второго 6-полосного автопешеходного моста через реку Волга с возможностью организации движения троллейбусов. Новый мост позволит перераспределить транспортные потоки, направив весь транзитный и грузовой транспорт на объездную автодорогу. Кроме того, наличие надежного транспортного сообщения будет способствовать экономическому развитию региона, откроет благоприятные перспективы для расширения инфраструктуры, сделает город удобным для граждан и привлекательным для бизнеса. Строительство нового моста предусмотрено генеральным планом развития города Костромы, с учетом его возведения проектируется улично-дорожная сеть города. В то же время без выделения денежных средств из федерального бюджета строительство нового моста невозможно. Практический результат Строительство нового автопешеходного моста через реку Волга в городе Костроме позволит создать условия для бесперебойного свободного движения транспорта по трассе федерального значения Москва – Киров – Екатеринбург, а также будет способствовать развитию экономики Костромской области и города Костромы.
- 340. Друзья! Поддержим этихЧеловеков! Они — больничные клоуны. Они приходят к тяжелобольным детям и проводят с ними время: играют, показывают фокусы, отвлекают, насколько это возможно, от ежедневной боли, которую они испытывают. Когда дети смеются, им проще пережить больничную атмосферу. Друзья! Они очень нуждаются в информационной поддержке своего проекта! Простой перепост новостей поможет