ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Рис. 5.3. Процеси, що автоматизують CASE

Крім моделі процесів розробки програмного забезпечення CASE повинна включати інструменти розробки і модель програмного продукту (рис. 5.4).

Рис. 5.4. Модель основи CASE

Очевидно, що CASE належать до інструментів горизонтального типу. Прикладами CASE є IBM Rational, Doors (Telelogic).

5.2. Обернена інженерія

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

Завдання оберненої інженерії протилежне прямій і полягає в за­безпеченні процесів низькорівневого представлення програмного забезпечення (частіше початкового і рідше об'єктного коду), високо рівневого його уявлення, наприклад, проектної інформації або специфікацій вимог

Загалом, обернена інженерія забезпечує два такі процеси:

- ідентифікацію системних компонентів і відношень між ними;

- створення високорівневих представлень компонентів і програмного продукту в цілому.

- Тому в оберненій інженерії доводиться вирішувати два завдання;

- вибір відповідного рівня представлення абстракцій, стандартів і уявлень дня інформації про програмну інженерію;

- створення інструментів, що полегшують розпізнавання відповідної інформації в існуючому початковому коді.

Досвід показує, що тієї інформації, яка є в низькорівневому пред­ставленні програмного забезпечення, як правило, недостатньо для по­будови високорівневого опису, тому процеси оберненої інженерії складні і потребують значного інформаційного і інструментального забезпечення,

На рис. 5.5 показано принципову відмінність процесів прямої і оберненої інженерії. Якщо для процесів прямої інженерії в разі створення програмного забезпечення характерне цілеспрямоване звуження області ухвалюваних рішень, то для процесів оберненої інженерії характерне розширення області рішень, що виводяться, яку постійно доводиться звужувати для того, щоб вийти на такс високорівневе уявлення програмного забезпечення.

Рис. 5.5. Відмінність прямої та оберненої інженерії

Потреба в оберненій інженерії натепер виникає в трьох випадках:

- у разі створення компонентів з існуючого програмного забезпечення;

- під час відновлення програмного забезпечення, наприклад, у процесі супроводу;

- у процесі переробки програмного забезпечення, наприклад, під час міграції.

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

5.2.1. Методи оберненої програмної інженерії

Місце методів, використовуваних у рамках оберненої інженерії в життєвому циклі, показано на рис. 5.6.

Рис. 5.6. Методи оберненої інженерії

До цих методів належать такі;

- відновлення проектної інформації;

- реструктуризація;

- редокументування;

- реінженерія.

Поняття реверсивної інженерії стосовно технічних систем викори­стовується для визначення процесів розробки специфікацій системи шляхом дослідження її задля створення безлічі подібних систем.

Стосовно програмного забезпечення основні цілі оберненої Ін­женерії полягають не в створенні дубліката системи, а в отриманні інформації для кращого розуміння системи, щоб підвищити ефек­тивність супроводу, переробити систему або виділити з неї певні компоненти, що відповідають заданим вимогам.

Відновлення проектної інформації (design recovery) - це метод оберненої інженерії, у якому разом з початковим кодом під час від­новлення проектної інформації використовуються всі доступні ві­домості про систему: проектна документація, досвід розробників і експлуатаційників, знання про домен. Головна мета відновлення проектної інформації - розроблення структур, які допоможуть ін­женерові програмного забезпечення зрозуміти програму або прог­рамну систему. Отже, кінцевою метою е не специфікація вимог, яка відповідає аналізованому початковому коду, а проектна інфор­мація.

Реструктуризація (restructuring) - це метод трансформації прог­рамного забезпечення на одному рівні його уявлення шляхом вико­ристання інформації, котру отримали в процесі виконання реверси­вної інженерії. Трансформація не приводить до зміни первинних вимог до програмного забезпечення (наприклад, реструктуризація - це перетворення неструктурної форми коду в структурну).