«Реінженерія програмного забезпечення авіаційних тренажерів»



Скачати 184.21 Kb.
Сторінка1/2
Дата конвертації04.06.2018
Розмір184.21 Kb.
ТипРеферат
  1   2

МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ

НАЦІОНАЛЬНИЙ АВІАЦІОННИЙ УНІВЕРСИТЕТ



«Реінженерія програмного забезпечення авіаційних тренажерів»

СИДОРОВ Євген Миколайович - кандидат технічних наук, доцент кафедри комп’ютерних інформаційних технологій. 

 

 

 



 

 

 



 

 

 



реферат

 Київ – 2011

Розглянуто зворотну інженерію програмного забезпечення, як важливу складову реінженерії, зроблено аналіз існуючих методів та засобів зворотної інженерії, визначено взаємозв’язок між зворотною та прямою інженеріями в контексті реінженерії, наведено характеристику технічно-програмного комплексу авіаційного тренажеру, на прикладі якого виконувалась перевірка працездатності запропонованого методу.

Виконання процесів супроводження програмного забезпечення призвело до необхідності реконструювання програм та розробки відповідного розділу інженерії програмного забезпечення, який називається зворотною (backward) або реверсивною (reverse) інженерією. Підхід, який забезпечує процеси розробки програмного забезпечення називається прямою (forward) інженерією. Задача зворотної інженерії протилежна задачі прямої інженерії та полягає в забезпеченні процесів отримання з низькорівневого представлення програмного забезпечення (похідного коду), його високорівневого представлення, наприклад, проектної інформації, або специфікацій вимог. Тому, основна мета зворотної інженерії – відновлення інформації про програмне забезпечення, а підставою для формулювання цієї мети є необхідність розуміння успадкованого програмного забезпечення. Так як, програмне забезпечення майже завжди представлено похідним кодом, то усі відомі методи та засоби відновлення інформації про програмне забезпечення орієнтовані саме на похідний код.

Реінженерія (reengineering) програмного забезпечення – це підхід, що забезпечує переробку програмного забезпечення, ґрунтуючись на досвіді відповідного домену, та будується шляхом взаємозв’язку зворотної та прямої інженерій («кругообіг» програмного забезпечення) (рис. 1).

Рис. 1. «Кругообіг» програмного забезпечення

Сьогодні відомі роботи, в яких пропонуються методи вирішення задачі реінженерії, але в окремих доменах (D.Garlan), або для деяких типів програмного забезпечення (S.Rugaber, T.Mens). Засоби зворотної інженерії, як правило, будуються на основі відомої схеми (E.Chikofsky, J.Сross). Застосування загальних методів, наприклад, відомого методу відновлення проектної інформації (design recovery, T.Biggerstaff) потребують врахування особливостей виконання процесів реінженерії, які залежать від домену. Тому, досвід показує, що кожен новий домен, як правило, вимагає відповідних досліджень та доробки існуючих методів реінженерії, або розробки нового методу.

На прикладі програмно-технічного комплексу авіаційного тренажеру, наведено характеристики домену в якому було застосовано розроблений метод. Запропонований метод керованої об’єктом реінженерії програмного забезпечення.

Програмне забезпечення, яке досліджується та підлягає реінженерії, є частиною реального світу, функціонує на цифрових обчислювальних комплексах, та значна кількість його компонентів пов'язана з обробкою інформації, циркулюючої в імітаційній моделі. До складу таких комплексів входять аналого-цифрові та цифро-аналогові перетворювачі, датчики реального об'єкту або його моделі, інше обладнання. Особливості домену та місця тренажеру в ньому визначають те, що реінженерія успадкованого програмного забезпечення цього типу окрім вирішення традиційних завдань, пов'язаних з відновленням проектної інформації, вимагає відновлення інформації про реальний об'єкт та особливого підходу до рішення задачі обґрунтування адекватності функціонування побудованого в результаті реінженерії програмного забезпечення поведінці реального об'єкту. Інформація про реальний об'єкт, відновлювана в процесі реверсивної інженерії, – це алгоритми, моделі, характеристики вхідних параметрів, датчиків, приладів та виконавчих пристроїв або моделі реального об'єкту. При відновлюванні, окрім шляху для отримання інформації – аналізу успадкованого коду та документації – слід використовувати експериментальне дослідження поведінки моделі.

Обґрунтування адекватності функціонування побудованого програмного забезпечення не може здійснюватися відомими методами – порівнянням результатів виконання успадкованого та нового програмного забезпечення або порівнянням результатів реверсивної інженерії з поведінкою відповідної моделі домену. Перший метод не можна використовувати за відсутністю, внаслідок заміни обчислювального обладнання, на якому можна виконати успадковане програмне забезпечення, а другий, – оскільки модель домену, представлена в документації, як правило, містить помилки. Окрім цього, особливе положення програмного забезпечення в домені указує на те, що основна увага при обґрунтуванні адекватності повинна приділятися детальному аналізу його функціонування в реальних умовах. Все це свідчить про те, що вирішальну роль в обґрунтуванні адекватності функціонування розробленого в результаті реінженерії програмного забезпечення, функціонуванню реального об'єкта повинні грати характеристики та властивості реального об'єкту. Це складає сутність запропонованого методу керованої об’єктом реінженерії програмного забезпечення (рис. 2.).



Рис. 2. Схема методу реінженерії

Успадковане програмне забезпечення (рис. 3.) характеризує дискретний процес моделювання, а необхідна швидкодія досягалася за рахунок наступного: спрощенням математичних моделей динаміки польоту та систем літака; заміною аналітичного опису реальних (динамічних) процесів залежностями у вигляді таблиць рішень; використанням простих, але швидких методів інтерполяції функцій; використанням простих методів інтегрування диференційних рівнянь.

На рис. 4 показана загальна схема виконаної міграції програмно-технічного забезпечення тренажера. Оскільки, побудоване програмне забезпечення не можна було перевірити на правильність функціонування шляхом виконання успадкованого програмного забезпечення (обчислювач було замінено), то реверсивна інженерія, окрім традиційних процесів, включала процес додаткової взаємної перевірки успадкованого коду та моделі.



Рис. 3. Склад успадкованого програмного забезпечення

Більш всього помилок було в коефіцієнтах рівнянь моделі, що описує динаміку польоту. Тому для їх уточнення використовувався успадкований код, в якому визначалися частини, що здійснюють обчислення коефіцієнтів. Інтерпретація цих частин «за столом» дозволила визначити значення помилкових коефіцієнтів.

Рис. 4. Міграція технічного та програмного забезпечення тренажера

Реінженерія успадкованого програмного забезпечення після перевірки моделей здійснювалася в два етапи: реверсивна інженерія – побудова моделі та алгоритмічного уявлення; пряма інженерія – по отриманих моделях та алгоритмах, будувався код нового програмного забезпечення в мові С. Для виконання реверсивної інженерії за відомою схемою був побудований спеціальний інструмент, який містить екстрактор та абстрактор. Робота інструмента та результат прямій інженерії на фрагменті коду показаний на рис. 5 (розглядується модель параметра – ознаки перебування двигуна в режимі розкручування ротора стартером).

2.4

Рис. 5. Результат реінженерії (фрагмент)

Дослідження процесів реінженерії програмного забезпечення, вперше дозволило виявити декілька схем їх виконання за наступним сценарієм: S : L N, де S – позначення схеми реінженерії; L – успадковане програмне забезпечення; N – нове програмне забезпечення; С – множина умов, від яких залежить застосування схеми. Було встановлено чотири наступні базові схеми реінженерії програмного забезпечення: «код-код», «код-алгоритм-код», «код-модель-алгоритм-код», «код-модель-технічний опис-алгоритм-код». Схему «код-модель-технічний опис-алгоритм-код» наведено на рис.6, в якості прикладу. Умовою (С) для застосування цієї схеми є наступне: успадкований код (L) реалізує невідому модель, створену розробником, з якої зрозуміти алгоритми неможливо; опис змісту фізичного процесу, що моделюється, є в технічній документації реального об’єкту. Сполучення моделі та технічного опису дозволяє побудувати алгоритм та створити нове програмне забезпечення (N).

Рис. 6. Схема реінженерії

По цій схемі була проведена реінженерія більшості програм для моделювання параметрів імітаторів «силова установка» та «динаміка польоту», а також декількох параметрів імітатору «навігаційна система». Наприклад, моделюється логічний параметр імітатору «навігаційна система» (параметр забезпечує сигналізацію при прольоті одного з маршрутних маяків). Фрагмент коду, в якому моделюється параметр показано на рис. 7.

23440 00020646 MARK LDA HI

23441 040577 KAR 1

23442 00041650 SPA HMX

23443 00020646 LDA HI

23444 00041651 SPA HMZ

23445 00020332 LDA LG13

23446 00030115 UND MASK+S

23447 101040 UAS

23450 00011457 SUN AD1

23451 00021650 LDA HMX

23452 040577 KAR 1

23453 00041650 SPA HMX

23454 00021651 LDA HMZ

23455 040577 KAR 1

23456 00041651 SPA HMZ

23525 00120100 AD2 ZUN AA1

23526 00011530 SUN *+2

23527 00011532 SUN AD4

23530 00120000 ZUN 0

23531 00011463 SUN AD1+4

23532 0002 0337 AD4 LDA LG23

23533 041675 KZL 3

23534 140100 VZP

23535 040675 KZP 3

23536 00040337 SPA LG23

Рис.7. Фрагмент коду, що моделює.

Математична модель, отримана в результаті аналізу приведеного вище коду має вигляд: , де ХТ – подовжна координата літака; ZT – бокова координата літака; XMJ – подовжна координата маркера; ZMJ – бокова координата маркера; HMX – дорівнює половині висоти польоту; HMZ – дорівнює висоті польоту. З урахуванням отриманої математичної моделі параметра та успадкованого коду був побудований алгоритм (рис.8).



Рис. 8. Алгоритм моделювання параметру.

В мові С алгоритм показано на рис. 9.

HMX = 0.5 * HI;

HMZ = HI;

if (fCM == 1)

{

HMX = HMX * 0.5;



HMZ = HMZ * 0.5;

}

for(marker = 2; marker < 5; ++marker)



{

XT = 16 *(XT – XMJm);

ZT = 16 * (ZT –ZMJm);

if (XT < HMX)

if (ZT < HMZ)

{

fMRT = 1;



break;

}

else



fMRT = 0;

else


fMRT=0;

}

Рис. 9. Код алгоритму моделювання параметру в мові С.



Для аналізу похідного коду (мова програмування SYPS платформи Robotron), та побудови його високорівневого алгоритмічного уявлення на платформі Microsoft.Net версії 3.5 та мові програмування C# було побудовано інструмент зворотної інженерії (за архітектурою «екстрактор – абстрактор», E.Сhicofsky). Він має графічний інтерфейс користувача, який є Web-застосуванням. Послідовність функцій, яку виконує інструмент наступна: завантаження похідного коду для виконання аналізу; читання коду; перевірка помилок; аналіз похідного коду (екстрактор); трансляція в мову DOT (екстрактор); запис в .dot файл; завантаження файлу; виклик графічного модуля (абстрактора).

Розглянуто архітектуру засобів, які розроблялись для виготовлення тієї частини програмного забезпечення, що створюється заново, внаслідок повної заміни обчислювального комплексу,програмне забезпечення обмину, імітатору шуму та пульту інструктора. Для реалізації програмного забезпечення обмину запропоновано архітектуру програмного шаблону (рис. 10). Вона включає два рівні драйверів, які забезпечують функції передачі/прийому параметрів, конфігуратор, що забезпечує конфігурування пристроїв вводу/виводу, вхідних та вихідних параметрів, і програмне забезпечення обміну даними, що реалізує взаємодію з іншими обчислювальними вузлами тренажера.



Рис. 10. Архітектура шаблону програмного забезпечення

В архітектурі передбачається набір інструментів, які дозволяють отримувати інформацію про об'єкт в процесі зворотної інженерії, яке необхідне для перевірки правильності моделі. Сховище конфігурацій має ієрархічну структуру на основі XML, яку можна редагувати, переглядати та використовувати стандартними засобами роботи з XML. Для використання XML визначено спеціальну мову. Приклад опису конфігурації одного з пристроїв введення параметра показаний на рис. 11.

Рис. 11. Приклад опису конфігурації пристрою введення параметра

Для відновлення пульта інструктора тренажера пропонується підхід на основі ролей. Вводиться поняття авіаційної ролі AR = ‹R, I›, де R – множина ролевих видів; I = – множина, яка містить елементи користувацького інтерфейсу, кожен має дві складових T – опис типу інформації та F – опис форми її представлення (індикатор, шкала-стрілка, транспарант, візир, цифрове табло, тумблер). Між R та I існують відповідні ієрархічні залежності. AR є основою для побудови об’єктно-оріентованого середовища програмування користувацького інтерфейсу (рис. 12).

Для реалізації запропонованого підходу розроблена архітектура засобів, які дозволяють створення та виконання сценаріїв польоту, створення видів та обмін даними пульта з іншими компонентами тренажера (рис. 13).

Сховища конфігурацій видів та сценаріїв польотів забезпечують зберігання даних про задані елементи пульта в XML-форматі. Розглянуто обґрунтування адекватності переробленого програмного забезпечення.

Рис. 12. Фрагмент середовища програмування інтерфейсу

Для перевірки адекватності функціонування переробленого програмного забезпечення реальному об'єкту використовувалися кількісні та якісні оцінки.Кількісна оцінка здійснювалася такими шляхами:


  • точковим – порівняння по методиці розробника тренажера значень обчислених експлуатаційних параметрів, з точками реперів, що наведені в технічному описі тренажера;

  • інтервальним – порівняння розрахованих характеристик з характеристиками, що наведені в документах реального літака (керівництво по льотній експлуатації, керівництво по технічній експлуатації, технічний опис двигуна та його систем, технічний опис авіаційного та радіоелектронного устаткування літака, дані бортової системи реєстрації польотної інформації).

Рис. 13. Архітектура засобів для реалізації пульта інструктора

Якісна оцінка поведінки тренажера на різних режимах та етапах польоту здійснювалась шляхом експертного оцінювання лінійними пілотами-експертами.

Результати застосування точкової оцінки наведені в таблиці, а результати інтервальної оцінки – на рис. 14, 15.



Таблиця


Каталог: sites -> default -> files
files -> Додаток до наказу від
files -> Робоча програма навчальної дисципліни екологія біологічних систем
files -> Зміст 2 Коран та його переклади в контексті історії 5
files -> Робоча програма навчальної дисципліни
files -> Програма навчальної дисципліни фізична реабілітація в педіатрії
files -> Кабінет міністрів україни
files -> Робоча програма навчальної дисципліни проектування технологічних процесів
files -> Реферат 2016 Реферат циклу наукових праць на здобуття щорічної премії Президента України для молодих вчених на тему


Поділіться з Вашими друзьями:
  1   2


База даних захищена авторським правом ©referatu.in.ua 2017
звернутися до адміністрації

    Головна сторінка