CC BY
48
УДК 004.422.83
Федасюк Д. В.1, Чопей Р.С.2
1Д-р техн. наук, професор, проректор Национального унверситету «Львеська полтехнка», Льве, Украна 2Аспрант кафедри програмного забезпечення Нацонального унеерситету «Львiвська полтехнка», Льве, Украна
АЛГОРИТМ ПОБУДОВИ ГРАФУ ПОТОКУ КЕРУВАННЯ _ЗА ТЕКСТОМ ПРОГРАМИ МОВОЮ С_
Актуальтсть. Робота присвячена проблемi автоматизовано! побудови графу потоку керування за текстом програми мовою С, що е важливим етапом структурного тестування вбудованих систем.
Мета роботи - створення алгоритму побудови графу потоку керування за текстом програми, що мае високу швидгасть роботи та дозволяе подальше застосування юнуючими засобами автоматизованого тестування.
Метод. Запропоновано алгоритм побудови графу потоку керування за текстом програми мовою С, який здшснюе попередню обробку видного тексту програми шляхом видалення коментарiв та порожшх рядгав, визначае кшьгасть вершин та ребер графу потоку керування на основi синтаксичного аналiзу тексту програм, а також формуе, заповнюе та збершае матрицю шцидентност в окремому текстовому файл^ що дозволяе подальше використання засобами тестування, яга у якост видних даних приймають граф потоку керування, о^м того, текстовий файл може використовуватись засобами для графiчного представлення графу потоку керування.
Результати. Розроблено програмний модуль, що реалiзуе запропонований алгоритм, який використано при проведенш експерименпв з дослщження залежност часу побудови графу потоку керування вщ галькост рядгав тексту програми.
Висновки. Проведет експерименти пiдтвердили працездатнiсть запропонованого алгоритму та розробленого на його основi програмного модуля, довели придатшсть результата роботи алгоритму, що дозволяе рекомендувати його для подальшого застосування засобами автоматизованого тестування для зменшення часових витрат на тестування вбудованого програмного забезпечення.
Ключовi слова: граф потоку керування, автоматизоване тестування, Keil uVision, ARM, вбудоваш системи.
НОМЕНКЛАТУРА
ПЗ - програмне забезпечення;
ARM - покращена RISC машина;
N - кшьюсть вщповщних iдентифiкаторiв case та default;
edgeC - лiчильник вершин;
CSV - значення, роздiленi комою;
I(\V\r\E\) - матриця iнцидентностi;
V - кiлькiсть рядкiв у матрицi шцидентноста, i, вщпов-iдно, вершин у графi керування;
E - кшьюсть стовпцiв у матрицi iнциденгностi, i, ввдпо-вiдно, ребер у графi керування;
M - мова програмування С;
fi (') - функщя програми;
n - кiлькiсть функцiй;
G - граф потоку керування;
Оеп - обчислювальна складнiсть n-го етапу роботи алгоритму.
Овк - обчислювальна складшсть процедури видалення коментарiв;
Омп - обчислювальна складшсть процедури моди-фжацп тексту програми;
Офл - обчислювальна складшсть процедури фор-мування спискiв ознак;
Озам - обчислювальна складнiсть процедури запов-нення матрицi;
ОзбМ - обчислювальна складшсть процедури збере-ження матрицi. ВСТУП
Графи потоку керування (Control flow graph, CFG) e загальноприйнятим засобом вiзуального представлення множини вшх можливих шляхiв виконання програми.
© Федасюк Д. В., Чопей Р. С., 2018
DOI 10.15588/1607-3274-2018-2-17 154
Кожен оператор представлений вузлом в граф^ ребра вщображають потж управлення мiж ними. Графи потоку керування застосовуються при аналiзi потоку керування та оптишзацп коду компiлятором [1-3], для визна-чення та оцiнки метрик програмного коду, зокрема склад-ностi програми [4-7], а також для структурного тестування програмного забезпечення (ПЗ), що викори-стовуе граф потоку керування для генерування тестових випадкiв [8-11], та визначення тестового покриття [12].
Об'ектом дослiдження e процес побудови графу потоку керування.
Наявшсть графу потоку керування, сформованого у вигляд^ зручному для опрацювання комп'ютером (зокрема, матрицею шцидентноста), дозволить використати ^нукта засоби [8-12] для обчислення метрик розроб-люваного вбудованого ПЗ, а програмна реалiзацiя алгоритму побудови графу потоку керування може бути оформлена у окремий модуль засобiв автоматизованого тестування вбудованого ПЗ, що дозволить ютотно змен-шити витрати часу та зусиль команди тестувальниюв, а також уникнути помилок через неуважшсть, що зазви-чай супроводжуе монотонну рутинну роботу.
Огляд штегрованих середовищ розроблення коду для мiкроконтролерiв ARM показав, що вс вони будують граф потоку керування автоматично, однак, жоден з них не дае можливост! видобути граф потоку керування та зберегти його у вигляд^ придатному для застосування в якост! вхiдних даних засобiв автоматизованого тестування ПЗ.
Предмет дослщження становлять алгоритми побудо-ви графу потоку керування за текстом програми.
Метою роботи е розроблення алгоритму автоматизовано! побудови графу потоку керування за текстом програми, написаним мовою С, а також дослщження ефективност його роботи та можливост застосування його Юнуючими засобами тестування ПЗ.
1 ПОСТАНОВКА ЗАДАЧ1
Нехай задано текст программ мовою програмування С, представлений набором функцш у вигляд1
T =< C,F > , де F = {{ (•),i = 1,2,...и).
Тод1 задача побудови графу потоку керування, пред-ставленого у вигляд1 метрищ шцидентност
G = I (|V х ) , полягатиме в синтаксичному анал1з1 тексту програми для визначення кшькост вершин i ребер графу та взаемозв'язюв мiж ними.
Для оцiнювання якостi одержаних результатiв може бути використано порiвняння графу потоку керування, побудованого за одержаною матрицею iнцидентностi, та графом потоку керування, вручну створеного фахiвцем з забезпечення якостi ПЗ зпдно з iснуючими правилами.
2 ОГЛЯД Л1ТЕРАГУРИ
У [13] запропоновано алгоритм перетворення тексту програми у граф-схему, що може застосовуватися для структурного проектування складних шформацшно-ви-мiрювальних системи. Наведено приклад застосування алгоритму перетворення, реалiзованого у виглядi окре-мого програмного модуля для тексту програми мовою Object Pascal.
У [14] розглянуто проблему побудови графу потоку керування класичними алгоритмами для коду плануваль-ника операцшно! системи. Представлено алгоритм пе-ретворення асемблерного коду планувальника у граф потоку керування, що не виключае гшки з затримками. Проведет експерименти для систем на базi архiтектури TMS320C6200 вiд компанп Texas Instruments показали, що побудоваш за представленим алгоритмом графи е бшьш достсдарними у порiвняннi з графами, побудова-ними за класичними алгоритмами. А вщтак, оптимiзацiя обсягу вихщного коду та часу виконання програми стае бшьш ефективною.
У [15] представлено архитектуру засобу для тестуван-ня програмного забезпечення вбудованих систем. Зап-ропонований зашб використовуе машинний код, отри-маний у процесi комтлювання ПЗ, написаного мовою Java, та формальну специфiкацiю. Окрiм архiтектури засобу, представлено алгоритм побудови графу потоку керування з машинного коду та алгоритм замши викли-ку функцп, представленого вершиною графу, його графом потоку керування.
Головним недолiком наявних алгоритшв побудови графу потоку керування [13-15] е вщсутшсть можли-востi 1х застосування для ПЗ, написаного мовою С, яка на сьогодш утримуе лiдерство з-помiж мов для розроб-лення вбудованого ПЗ.
3 МАТЕР1АЛИ ТА МЕТОДИ
Для формалiзацil алгоритму використаемо наступш поняття:
Обчислювальна операщя - найменша автономна ча-сина мови програмування. Для будь-яко1 мови програмування видшяють три рiзновиди обчислювальних опе-рацiй - сл^вання, галуження, та цикли:
- ^дування - виклики функцiй, та проста операцп (iнкремент/декремент та шш^;
- галуження - оператори галуження для мови С (if, else if, else, switch);
- цикли - оператори циктв для мови С ("for", "while", "do").
Граф потоку керування - орiентований граф, що представлений у формi матищ, та метить один вхщний та один вих^ний вузол. Вершинами графу представлен сим-вольш оператори чи функцп, а ребрами - зв'язок мiж ними.
Матриця iнцидентностi (Incidence matrix) - одна з форм представлення графа, в якш вказуеться зв'язок мiж шци-дентними елементами графа (ребро i вершина). Стовпщ матрицi вiдповiдають ребрам, рядки - вершинам.
Заповнення матрищ вiдбуваеться зпдно з наступни-ми правилами:
- комiрка матрищ набувае значення «1», якщо ребро виходить з вершини;
- комiрка матрицi набувае значення «-1», якщо ребро входить у вершину;
- комiрка матрицi набувае значення «0», якщо ребро не пов'язане з вершиною.
Алгоритм побудови графу потоку керування базуеть-ся на об'еднанш декшькох складових: попередня оброб-ка тексту програми, визначення кшькост вершин графу, визначення кшькост ребер графу, заповнення матрищ на осжда визначених взаемозв'язкiв мiж вершинами графу Процесу побудови графу потоку керування зобра-жено на рис. 1.
Побудова графу потоку керування передбачае чоти-ри етапи роботи:
Етап 1. Попередня обробка тексту програми
На цьому етат роботи алгоритму з тексту програми видаляються коментар^ порожш рядки, а також проводиться модифшащя тексту програми, якщо виклик функцп або умову галуження записано у декшька рядкiв.
Етап 2. Визначення кшькост вершин графу
На цьому етат роботи алгоритму виконуеться автоматична нумеращя рядюв тексту програми за винятком наступних випадкiв:
- рядок тексту програми, що метить лише спещаль-ний символ "{" або "}", не збiльшуе лiчильник рядкiв;
Рисунок 1 - Схема процесу побудови графу потоку керування за текстом програми, мовою С
- рядок тексту програми, що мiстить iдентифiкатор: case, default, break, return, else, else if, не збшьшуе лiчиль-ник рядюв;
- рядок тексту програми, що метить iнiцiалiзацiю 3MÎHHOÏ чи екземпляра структури, не збшьшуе лiчильник рядюв;
- лiчильник рядкiв програмного коду збшьшуеться на одиницю тсля останнього рядка тексту програми;
Етап 3. Визначення кiлькостi ребер графу
На цьому етапi роботи алгоритму виконуеться нуме-рацiя ребер, шляхом збшьшення лiчильника ребер, на основi синтаксичного аналiзу тексту програми, а саме пошуку у ньому iдентифiкаторiв галуження (if, switch, else, else if), щентифжатс^в циклу (for, do, while) та щен-тифiкаторiв сл^вання (рис. 2).
Визначення кiлькостi ребер вщбуваеться згiдно з правилами:
- лiчильник ребер збiльшуеться на одиницю, якщо рядок тексту програми вщповщае обчислювальному процесу - слiдування;
- лiчильник ребер збiльшуеться на одиницю, якщо рядок тексту програми метить щентифжатори if, для яких е вщповщний iдентифiкатор else;
- лiчильник ребер збiльшуеться на одиницю, якщо рядок тексту програми метить щентифжатор else або else if;
рядка код у
""бстан н ¡и "--^га к -^рядок?^--^
так ^ч!роцес\. н\
Рисунок 2 - Блок-схема етапу визначення юлькосп ребер у гра(ф
- лiчильник ребер збiльшуеться на два, якщо рядок тексту програми метить щентифшатори if, для яких вщсутш вiдповiднi iдентифiкатори else та else if;
- лiчильник ребер збшьшуеться на два, якщо рядок тексту програми метить щентифжатор циклу - for або while;
- лiчильник ребер збшьшуеться на N, якщо рядок тексту програми метить щентифжатор галуження - switch.
Етап 4. Формування матрицi iнцидентностi
На цьому етат роботи алгоритму створю еться мат-риця з розмiрами, що були визначеш на попереднiх ета-пах, та виконуеться ïï заповнення. Цей етап роботи е найбшьш трудомютким, адже передбачае визначення взаемозв'язкiв у програмному кодi. Для цього створюеть-ся чотири списки:
Listl - мiстить номер вершини, якiй вiдповiдае рядок тексту програми.
List2 - метить номер вершини, яка е наступною пiсля iдентифiкатора галуження або щентифжатора циклу.
List3 - метить маску, що вiдповiдае типу рядка, та може набувати таких значень:
- functionName - рядок, що метить iм'я функцiï;
- returnLine - рядок, що метить iдентифiкатор return;
- followLine - рядок, що метить виклик iншоï функцiï або присвоення значення у змшну;
- lastLinelnsidelF - останнш рядок вихщного коду тд конструкщею if;
- lastLinelnsideCycle - останнш рядок вихщного коду тд конструкщею for або while;
- lastLinelnsideCase - останнiй рядок вихщного коду пiд конструкщею case;
List4 - мютить номер вершини вденгифякатора if, switch, for або while, тд якою знаходиться рядок тексту програми.
Наступним кроком пiсля створення спискiв е запов-нення цих спискiв та створення змiнноi - edgeC, що буде використано при оновлент iнформацii у матрицi. Онов-лення матрицi вiдбуваеться згiдно з правилами:
- якщо елемент Listl метить 0 i елемент List3 мiстить маску functionName, встановлюемо у комiрцi [0,0] зна-чення «1», що вщповщае виходу ребра з вершини 0.
- якщо елемент List3 метить маску followLine, встановлюемо значення «-1» у комiрцi [List1[n], edgeC], збiльшуемо лiчильник вершин на одиницю та встановлюемо значення «1» у комiрцi [List1[n], edgeC];
- якщо елемент List3 мiстить маску lastLinelnsidelF встановлюемо значення «-1», у комiрцi [List1[n], edgeC], збiльшуемо лiчильник вершин на 1 та встановлюемо значення «1», у комiрцi [List1[n], edgeC]. У комiрцi [List2[n], edgeC] встановлюемо значення «-1» та встановлюемо значення «1», у комiрцi [List4[n], edgeC];
- якщо елемент List3 метить маску lastLinelnsideCycle встановлюемо значення «-1», у комiрцi [List1[n], edgeC], збiльшуемо лiчильник вершин на 1 та встановлюемо значення «1» у комiрцi [List1[n], edgeC], встановлюемо значення «-1» у комiрцi [List4[n], edgeC] i збшьшуемо лiчильник вершин на 1, встановлюемо значення «1» у комiрцi [List4[n], edgeC];
- якщо елемент List3 метить маску lastLinelnsideCase встановлюемо значення «-1» у комiрцi [List1[n], edgeC], збiльшуемо лiчильник вершин на 1 та встановлюемо значення «1» у комiрцi [List1[n], edgeC]. У комiрцi [List2[n], edgeC] встановлюемо значення «-1», а також встановлюемо значення «1» у комiрцi [List4[n], edgeC];
- якщо елемент List3 метить маску returnLine встановлюемо значення «-1» у комiрцi [List1[n], edgeC];
Останнiм кроком роботи цього алгоритму е збере-ження матрицi у окремому текстовому файлi з форматом даних CSV.
4ЕКСПЕРИМЕНТИ
Розглянемо застосування розробленого алгоритму для функцп читання значення температури, що мiстить основнi iдентифiкатори мови С (дод. А).
У ввдповвдност до представленого алгоритму виконуе-мо процедуру попереднього опрацювання тексту програми, а також визначаемо кшьюсть вершин та ребер. Текст програми тсля процедури попереднього опрацювання та визначення юлькост вершин наведений у дод. Б.
На осжда аналiзу тексту програми виявлено:
- 14 рядюв, що вiдповiдають обчислювальному про-цесу слiдування - 14 ребер;
- 2 рядки, що мютять щентифжатор циклу for та while, для кожного з яких необхщно 2 ребра - 4 ребра для обох;
- 3 рядки, що мютять щентифжатор галуження if, else if та else, - 3 ребра;
- 1 рядок, що метить щентифжатор галуження switch, для якого е два iдентифiкатори case та один щентифжа-тор default - 3 ребра;
- загальна кшьюсть ребер - 24.
- загальна кшьюсть вершин - 19.
Створюемо матрицю шцидентносп I(|19| х |24|) та чотири списки для 19 вершин, яю будуть заповненi згiдно з наведеними вище правилами. Результати аналiзу взае-мозв'язюв у текстi програми наведенi у табл. 1.
Таблиця 1 - Списки ознак для функци ReadTemperature
List1 List2 List3 List4
0 - functionName -
1 6 followLine -
2 6 followLine 1
3 6 followLine 1
4 6 followLine 1
5 6 lastLinelnsideCycle 1
6 9 followLine -
7 9 followLine 6
8 9 lastLinelnsideCycle 6
9 - followLine -
10 14 followLine -
11 14 lastLinelnsidelF 10
12 14 lastLinelnsidelF 10
13 14 lastLinelnsidelF 10
14 18 followLine -
15 18 lastLinelnsideCase 14
16 18 lastLinelnsideCase 14
17 18 lastLinelnsideCase 14
18 18 returnLine -
Матриця, заповнена в результатi роботи алгоритму, мае вигляд:
(1)
Отримана матриця буде збереженою для подальшо-го використання. Також граф потоку керування, представлений у виглядi матриц шцидентноста, можемо пред-ставити графiчно з допомогою Iнтернет-сервiсу [16]. Побудований за матрицею (1) граф наведений на рис. 3.
5 РЕЗУЛЬТАТИ
Враховуючи модульну структуру розробленого алгоритму обчислювальна складшсть алгоритму е сумою склад-носта для кожного етапу роботи. Перший етап передбачае видалення коментарiв та модифiкацiю виидного коду при необидносп, складнiсть якого визначаеться зпдно (2):
Oei = Овк (1) + ОМП (N ). (2)
Другий етап роботи алгоритму передбачае визначення юлькост вершин у графт Обчислювальна складшсть цього етапу роботи залежить лише вщ юлькост рядкiв тексту програми, що рiвна Oe 2( N ).
Третш етап роботи алгоритму передбачае визначення юлькост ребер у графт Складнiсть цього етапу роботи збшьшуеться за умови наявност у програмному кодi операторiв галуження "if' та "switch". Тому вважаемо, що складшсть цього етапу Оез(Nл 2).
Етап генерування матрищ е найбшьш трудомютким. Складшсть цього етапу рiвна (3):
Oe 4 = Офл ( Nл 2) + Озам ( N ) + ОЗШ (1). (3)
Загальна складнiсть алгоритму побудови графу потоку керування визначаеться: Oe1 + Oje 2 + ОЕЗ + OE4 = Овк (1) + Омп (N) + OE2(N) + + Оез ( N л 2) + Офл ( N л 2) + Озам ( N ) + Озбм (1) = 0( N л 2).(4)
Згiдно з проведеним розрахунком складностi алгоритму визначаемо час побудови графу потоку керування, для тексту програми обсягом 50, 100 та 120 тис. рядюв. Розрахунок буде виконаний за умови, що комп 'ютер ви-конуе 1 млрд. операцш в секунду. Результата розрахунку наведеш у табл. 2.
Таблиця 2 - Час побудови графу потоку керування для р1зного обсягу вхщних даних
Загальна к-ть рядюв тексту програми, тис. К-ть рядюв коду шсля попередньо1 обробки, тис. Час побудови, с
50 49 2,5
100 98 10
120 118 14,4
Отримаш теоретичш результати розрахунку часу роботи алгоритму, св^ать про придатшсть результатiв та доцiльнiсть реалiзацiï алгоритму для проведення експе-риментальних дослiджень.
Реалiзацiя алгоритму здiйснювалась у вигляд окремого програмного модуля, з використанням мови програмуван-ня С#. Окр1м того, для проведення експериментiв з великим обсягом вх^дних даних реалiзовано програмний модуль, який почергово передае текст функцш, з проектiв розроблених у середовищi програмування Keil uVision. Експериментальнi дослiдження проведенi на персональному комп'ютерi Lenovo W520, з процесором Intel Core i5, що працюе з частотою 2,2 ГГц та обсягом оперативна пам'ятi 8 ГБайт. У якостi вх^дних даних використано три комерщйш продукти, що мютять 56, 90, та 150 тисяч рядюв тексту програми. Результати експерименту наведет у табл. 3.
На осжда отриманих теоретичних та експерименталь-них даних побудовано графж залежностi часу побудови вщ кiлькостi рядкiв тексту програми (рис. 4).
Як видно з рис. 4, теоретичш результати розрахунку та експериментальш даш дещо вiдрiзняються, що зумов-лено витратами часу на послщовне виконання алгоритму для кожно' функцiï комерцiйного проекту.
Вщзначимо, що для зменшення часу побудови графу потоку керування можливе паралельне виконання другого та третього еташв. 6 ОБГОВОРЕННЯ
Запропонований алгоритм побудови графу потоку керування порiвняно з алгоритмом побудови на основi асемблерного коду [14] забезпечуе бшьшу наочшсть перетворення, адже граф потоку керування будуеться напряму з тексту програми мовою С, в той час як граф потоку керування, побудований за асемблерним кодом, може дещо вiдрiзнятись, що зумовлено процесом пере-творення тексту програми у асемблерний код. Також запропонований алгоритм потребуе бшьших часових витрат на побудову графу, шж алгоритм побудови графу потоку керування за асемблерним кодом [14].
Таблиця 3 - Час побудови граф1в потоку керування для комерцшних продукта
Загальна к-ть рядюв тексту програми, тис. К-ть рядюв коду шсля попередньо!' обробки Час побудови, с
56 54 390 23
90 87 690 30
150 147 300 50,2
Рисунок 3 - Граф потоку керування функци "ReadTemperature"
60
- 20
10
0
50000
60000
70000
80000
90000
100000
110000
120000
К-ть рядюв текту програми
—■—Теоретичний розрахунок —*—Експериментальж дан1 Рисунок 4 - Залежшсть часу побудови вщ юлькосп рядюв тексту програми
Недолжом запропонованого алгоритму е його залежшсть вщ обчислювальних ресурав, що збiльшуюгься з кiлькiсгю рядюв тексту програми.
Зменшення часу побудови графу потоку керування за раху-нок паралельного виконання другого та третього етапу виконан-ня, зростатиме з збiльшенням юлькосп рядюв тексту програми. ВИСНОВКИ
У робота виршено актуальну задачу автоматизоважи побудови графу потоку керування за текстом програми мовою С.
Наукова новизна роботи полягае в тому, що запропоновано алгоритм, який автоматично будуе граф потоку керування з тексту програми мовою С, характеризуется невисокою обчислю-вальною складнiсгю, що, у свою чергу дозволяе знизити вимоги до обчислювальних ресурсгв i пам'ягi персонального комп'юте-ра, на якому вiн виконуеться.
Практична щншсть отриманих результата полягае в тому, що розроблено програмний модуль, який реалiзуе запропоно-ваний алгоритм та дозволяе виконувати побудову графу потоку керування, представленого у виглядi матриц шциденшосп.
Перспективи подальших дослiджень полягають у застосу-ваннi запропонованого алгоритму до формування вхiдних да-них для алгоритму генерування тестових випадюв, що штег-рований у засобi автоматизованого тестування найбiльш три-валого часу виконання програми. ПОДЯКИ
Роботу виконано в рамках госпдоговiрноi науково-дослвд-жи роботи кафедри програмного забезпечення Нащонально-го унiверсигегу «Львiвська полiгехнiка» на тему «Автомати-зоване генерування тестових сценарш для забезпечення якосгi апаратного та мжропрограмного забезпечення, для Гталшсь-коi компанii Dinamica Generale S.p.A., що е лiдером в галуи розробки вбудованих систем для агропромисловосл.
СПИСОК Л1ТЕРАТУРИ
1. Compilers: Principles, techniques, and tools / [eds.: A. V. Aho, M. S. Lam, R. Sethi, J. D. Ullman]. - Amsterdam: Addison Wesley, 2007. - 1038 p. ISBN: 0321486811
2. Graph-theoretic constructs for program control flow analysis : Research Report : RC-3923 / F. Allen, J. Cocke. - IBM Thomas J. Watson Research Center - IBM, 1972. - 130 p.
3. Ferrante J. The program dependence graph and its use in optimization / J. Ferrante, K. J. Ottenstein, J. D. Warren // ACM
Transactions on Programming Languages and Systems. - 1987. -№ 9. - P. 319-349. DOI: 10.1145/24039.24041
4. Gold R. On cyclomatic complexity and decision graphs / Robert Gold // Proceedings of the 10th International Conference of Numerical Analysis and Applied Mathematics (ICNAAM '12), 2007. - Vol. 1479. - P. 2170-2173. DOI: 10.1063/1.4756622
5. Henderson-Sellers B. The theoretical extension of two versions of cyclomatic complexity to multiple entry/exit modules / B. Henderson-Sellers, D. Tegarden // Software Quality Journal. -1994. - Vol. 3. - P. 253-269. DOI: 10.1007/BF00403560
6. Jalote P. An integrated approach to software engineering / P. Jalote. - New York : Springer, 2005. - 566 p. ISBN: 978-0387-28132-2
7. Sommerville I. Software Engineering / I. Sommerville. - Pearson : Addison Wesley, 2004. - 750 p. ISBN: 0321210263
8. Frankl P. G. Provable improvements on branch testing / P. G. Frankl, E. J. Weyuker. // IEEE Transactions on Software Engineering. - 1993. - Vol. 19. - P. 962-975. DOI: 10.1109/ 32.245738
9. Gold R. Control flow graphs and code coverage / R. Gold. // International Journal of Applied Mathematics & Computer Science. - 2010. - Vol. 20. - P. 739-749. DOI: 10.2478/v10006-010-0056-9
10. Zhu H. Software unit test coverage and adequacy / H. Zhu, P. A. Hall, J. H. May. // ACM Computing Surveys. - 1997. -Vol. 29. - P. 366-427. DOI: 10.1145/267580.267590
11. Fedasyuk D. Architecture of a tool for automated testing the worst-case execution time of real-time embedded systems' firmware / D. Fedasyuk, R. Chopey, B. Knysh. // 14th International conference, The experience of designing and application of cad systems in microelectronics. - 2017. - P. 278-282. DOI: 10.1109/ CADSM.2017.7916134
12. Hossain M. I. Integration testing approach using usage patterns of global variables [Electronic resource] / M. I. Hossain, W. J. Lee, S. Youngsul. - Researchgate, 2012. Access mode: https:/ /www.researchgate.net/publication/ 255 17343 1_Integration_Testing_Approach_ using_Usage_Patterns_of_Global_Variables.
13. Муха Ю. П. Алгоритм для преобразования программного кода на языке высокого уровня в граф-схему / Ю. П. Муха, В. А. Секачев // Известия волгоградского государственного технического университета. - 2009. - № 3. - С. 58-63.
14. Cooper K. D. Building a control-flow graph from scheduled assembly code [Electronic resource] / K. D. Cooper, T. J. Harvey, T. Waterman. - Researchgate, 2013. Access mode: https:// www.researchgate.net/publication/2572750.
15. Amine A. Generating control flow graph from Java card byte 16. Graph Online [Electronic resource]: Creating graph from code / A. Amine, B. Mohammed, L. Jean-Louis // Information incidence matrix. Access mode: http://graphonline.ru/en/
Science and Technology (CIST). - 2014. - P. 206-212. Стаття надшшла до редакци 14.08.2017.
DOI: 10.1109/CIST.2014.7016620 Шсля доробки 25.09.2017.
Федасюк Д. В.1, Чопей Р. С.2
'Д-р. техн. наук, профессор, проректор Национального университета «Львовская политехника», Львов, Украина 2Аспирант кафедры программного обеспечения Национального университета «Львовская политехника», Львов, Украина АЛГОРИТМ ПОСТРОЕНИЯ ГРАФА ПОТОКА УПРАВЛЕНИЯ ПО ТЕКСТУ ПРОГРАММЫ НА ЯЗЫКЕ С Актуальность. Работа посвящена проблеме автоматизированного построения графа потока управления по тексту программы на языке С, что является важным этапом структурного тестирования встроенных систем.
Цель работы — создание алгоритма построения графа потока управления по тексту программы, что имеет высокую скорость работы и позволяет дальнейшее применение существующими средствами автоматизированного тестирования.
Метод. Предложен алгоритм построения графа потока управления по тексту программы на языке С, который осуществляет предварительную обработку исходного текста программы путем удаления комментариев и пустых строк, определяет количество вершин и ребер графа потока управления на основе синтаксического анализа текста программ, а также формирует, заполняет и сохраняет матрицу инцидентности в отдельном текстовом файле, что позволяет дальнейшее использование средствами тестирования, которые в качестве входных данных принимают граф потока управления, кроме того, текстовый файл может использоваться средствами для графического представления графа потока управления.
Результаты. Разработан программный модуль, реализующий предложенный алгоритм, который используется при проведении экспериментов по исследованию зависимости времени построения графа потока управления от количества строк текста программы.
Выводы. Проведенные эксперименты подтвердили работоспособность предложенного алгоритма и разработанного на его основе программного модуля и доказали пригодность результатов работы алгоритма, что позволяет рекомендовать его для дальнейшего применения средствами автоматизированного тестирования для уменьшения временных затрат на тестирование встроенного программного обеспечения.
Ключевые слова: граф потока управления, автоматизированное тестирование, Keil uVision, ARM, встраиваемые системы. Fedasyuk D. V.1, Chopey R. S.2
"Dr. Sc., Professor, Vice-Rector of Lviv Polytechnic National University, Lviv, Ukraine
2Post-graduate student of the Department of Software, Lviv Polytechnic National University, Lviv, Ukraine THE ALGORITHM OF CONSTRUCTING CONTROL FLOW GRAPH BASED ON A PROGRAM WRITTEN IN C Actuality. The work considers the problem of automated construction of the control flow graph using the text of a program written in C. The graph construction is an important step in the structural testing of embedded systems.
Objective. The work is aimed at creation of a fast algorithm for constructing the control flow graph from a source code. Such an automatically generated graph can be used by existing tools for automated testing.
Method. We propose an algorithm for constructing the control flow graph from the program written in C language, which preprocesses the source code of the program by removing comments and blank lines, determines the number of vertices and edges of the control flow graph by means of program text syntactic analysis, and then formats, fills and stores the incidence matrix in a separate text file. This file can be passed as input data for some existing automated testing tools. Moreover, the content of the text file can be visualized by existing tools for graphic representation of graphs.
Results. We've developed a software module that implements the proposed algorithm. The module can be used for experiments aimed at studying the dependence of the control flow graph's time construction on the amount of lines in a source code.
Conclusions. The conducted experiments confirmed the operability of the proposed algorithm and the software module developed on its basis. The results have proved the applicability of the algorithm, thus it can be recommended for further use together with automated testing tools to reduce the time required for testing of embedded software.
Keywords: control flow graph, automated testing, Keil uVision, ARM, embedded systems.
REFERENCES Vol. 20, pp. 739-749. DOI: 10.2478/v10006-010-0056-9
1. Aho A. V, Lam M. S., Sethi R., Ullman J. D. : eds. Compilers:
10. Zhu H., Hall P. A., May J. H. Software unit test coverage and adequacy, ACM Computing Surveys, 1997, Vol. 29, pp. 366-427.
Principles, techniques, and tools. Amsterdam, Addison Wesley, DOI' 1o'1145/267580 267590
2007, 1038 p. ISBN: 0321486811 2. Allen F., Cocke J. Graph-theoretic constructs for program control flow analysis : Research Report : RC-3923, IBM Thomas J. Watson Research Center - IBM, 1972, 130 p.
11.Fedasyuk D., Chopey R., Knysh B. Architecture of a tool for automated testing the worst-case execution time of real-time embedded systems' firmware, 14th International conference, The experience of designing and application of cad systems in
3. Ferrante J., Ottenstein K. J., Warren J. D. The program dependence , ^m-, -,-,0 ^o-, t^^t m i mm
, . . ... microelectronics, 2017, pp. 278-282. DOI: 10.1109/
graph and its use in optimization, ACM Transactions on CADSM 2017 7916134
Programming Languages and Systems, 1987, No. 9, pp. 319- .„ TT . . _ T . .
° „ , 12. Hossain M. I., Lee W. J., Youngsul S. Integration testing approach
349. DOI: 10.1145/24039.24041 6 6 6
4. Gold R. On cyclomatic complexity and decision graphs, Proceedings of the 10th International Conference of Numerical Analysis and
using usage patterns of global variables [Electronic resource],
Researchgate, 2012. Access mode: https://www.researchgate.net/
„ , , publication/255173431 Integration Testing Approach using
Applied Mathematics (ICNAAM '12), 2007, w ■ u. " "
, „ , Usage Patterns ot Global Variables.
Vol. 1479, pp. 2170-2173. DOI: 10.1063/1.4756622 nmu T t> cTi~u- ,7 . a. ji- u
, . 13.Muha Ju. P., Sekachjov V. A. Algoritm dlja preobrazovanija
5. Henderson-Sellers B., Tegarden D. The theoretical extension ot
programmnogo koda na jazyke vysokogo urovnja v graf-shemu,
modules, Software Quality Journal, 1994, Vol. 3, pp. 253-269. IZVeSj Г^Г^У ^^ tehnichesk°g°
„ universiteta, 2009, No. 3, pp. 58-63.
in 1 ПП-7/ОТ7ПП ЛП1 Ç /СП ' ' ' ^^
two versions of cyclomatic complexity to multiple entry/exit
DOI: 10.1007/BF00403560
6. Jalote P. An integrated approach to software engineering. New York, Springer, 2005, 566 p. ISBN: 978-0-387-28132-2
7. Sommerville I. Software Engineering. Pearson, Addison Wesley,
14. Cooper K. D., Harvey T. J., Waterman T. Building a control-flow graph from scheduled assembly code [Electronic resource], Researchgate, 2013. Access mode: https://www.researchgate.net/
2004, 750 p. ISBN: 0321210263 1 5 AublicationM/25h72750d
' . 15. Amine A., Mohammed B., Jean-Louis L. Generating control flow
8. Frankl P. G., Weyuker E. J. Provable improvements on branch .„ T * o >
J r,r graph from Java card byte code, Information Science and
testing, IEEE Transactions on Software Engineering, 1993, Technology (CIST), 2014, pp. 206-212. DOI: 10.1109/
Vol. 19, pp. 962-975. DOI: 10.1109/32.245738 CIST 2014 7016620
9. Gold R. Control flow graphs and code coverage, International . , _ r^i ^ i r-. i c-
16. Graph Online [Electronic resource]: Creating graph from Journal of Applied Mathematics & Computer Science, 2010, ., ■ . , , ,, .. , ,. . .
incidence matrix. Access mode: http://graphonline.ru/en/
flOflATOK A
short ReadTemperature (void) {
unsigned Counter, elems,TemperatureType;
float TemperatureBuffer[10];
float Tmp = 0.0;
float summ = 0.0;
float average = 0.0;
/* the TemperatureBuffer used
for average temperature value */
for (Counter = 0; Counter < 10; Counter++) {
StartConversionOfInternalADC_1(); osDelay(10);
TemperatureBuffer[Counter] =
ReadTemperatureADC_1();
elems++; }
/* calculate average temperature */
while(elems > 0) {
summ+= TemperatureBuffer[elems];
elems—; }
average = summ/10;
/* defina th temperature type */
if (average > 40) {
TemperatureType = 1; }
else if ((average < 40) &&
(average > 10)) {
TemperatureType = 2; }
else {
TemperatureType = 3; }
switch(TemperatureType) /* show message on
display */ {
case 1: {
printf("Temperature type - Hot, Temperature =
%f\n", average); }
break;
case 2: {
printf("Temperature type - Normal, Temperature
= %f\n", average); }
break;
default: {
printf("Temperature type - Cold, Temperature
= %f\n", average); }
break; }
return ((short)average);/*return temperature
value*/ }
flOflATOK E
(0) short ReadTemperature (void) {
unsigned Counter, elems,TemperatureType; float TemperatureBuffer[10]; float Tmp = 0.0; float summ = 0.0; float average = 0.0; (1) for (Counter = 0; Counter < 10;
Counter++) {
(2)
StartConversionOfInternalADC_1();
(3)osDelay(10);
(4) TemperatureBuffer [ Counter] = ReadTemperatureADC_1();
(5)elems++; }
(6) while(elems > 0) {
(7)summ+= TemperatureBuffer[elems];
(8)elems—; }
(9)average = summ/10;
(10) if (average > 40) {
(11)TemperatureType = 1; }
else if ((average < 40) && (average > 10)) {
(12)TemperatureType = 2; }
else {
(13)TemperatureType = 3; }
(14)switch(TemperatureType) {
case 1: {
(15) printf ("Temperature type - Hot,
Temperature = %f\n", average); }
break;
case 2: {
(16)printf("Temperature type - Normal,
Temperature = %f\n", average); }
break;
default: {
(17) printf("Temperature type - Cold,
Temperature = %f\n", average); }
break; }
(18) return ((short)average); }
