ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ - М. Сидоров

Computer Aided Software Environment (CASE) - це інструментарій, призначений для автоматизації виконання процесів життєвого циклу програмного забезпечення. CASE відіграє, таку ж роль у програмно­му забезпеченні, як CAD/САМ в інженерії фізичних систем. Функці­онування CASE ґрунтується на моделі процесів життєвого циклу (рис. 5.2).

Рис. 5.2. Зв'язок CASE моделі процесів ;життєвого циклу

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

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

Рис. 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.6.

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

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

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

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

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

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

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

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

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

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

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

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

Усі інструменти оберненої інженерії утворюють інтегроване се­редовище - Computer Aided Reverse Software Environment (CARSE). Загальну архітектуру середовища зображено на рис. 5.7.

Рис. 5.7. Архітектура інструментів оберненої інженерії

5.3. Емпірична інженерія програмного забезпечення

Емпіричні методи досліджень відіграють «впливову» роль в ін­женерії програмного забезпечення і їх застосування складають од­ну з інженерій - емпіричну інженерію програмного забезпечення.

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

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

Величина - це певна властивість предмета, з якою можна зіста­вити значення. Для синтезу величини варто визначити властивість (семантику величини), систему значень (шкалу) та спосіб зістав­лення значень з величиною.

У теорії вимірювання виділяють три основні шкали вимірювань - номінальну, порядкову і кількісну. Номінальна (класифікаційна) шкала включає значення, що проявляє себе лише у відношенні еквівалентності або може бути зіставлена з властивістю предмета (не упорядкованих один стосовно іншого). Наприклад, можна зістави­ти з вихідним текстом програми величину «мова програмування», значенням якої може бути назва однієї з мов (наприклад, «С», «С++», «Pascal», «Java» тощо). Такий же тип має шкала класифі­кування призначення модулів програмного забезпечення (наприк­лад, «Бази даних», «Математичні пакети», «Операційні системи» тощо). До номінальних величин застосовується тільки операція пе­ревірки на еквівалентність. Порядкова (ординальна) шкала спосте­рігає за упорядкуванням одного значення стосовно іншого, до яких належать операції порівняння. Порядкову пікапу можна задати для більшості експертних оцінок, наприклад, оцінювання читабельнос­ті тексту програм - «незадовільно», «задовільно», «добре», «від­мінно» або для оцінювання рівня інкапсуляції програмних компо­нентів - «лексичний», «операторний», «процедурний», «класний», «модульний». Кількісна шкала включає в себе значення, що про­явили себе стосовно еквівалентності, порядку і адекватності. Такі величини дають змогу виковувати адекватні і мультиплікативні операції над значеннями (віднімання, множення, ділення). До них належать, наприклад, такі кількість рядків коду, складання коментарю, оцінювання трудозатрат на створення коду.