М. Сидоров - ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
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.2.1. Методи оберненої програмної інженеріїМісце методів, використовуваних у рамках оберненої інженерії в життєвому циклі, показано на рис. 5.6.
Рис. 5.6. Методи оберненої інженерії
До цих методів належать такі;
- відновлення проектної інформації;
- реструктуризація;
- редокументування;
- реінженерія.
Поняття реверсивної інженерії стосовно технічних систем використовується для визначення процесів розробки специфікацій системи шляхом дослідження її задля створення безлічі подібних систем.
Стосовно програмного забезпечення основні цілі оберненої Інженерії полягають не в створенні дубліката системи, а в отриманні інформації для кращого розуміння системи, щоб підвищити ефективність супроводу, переробити систему або виділити з неї певні компоненти, що відповідають заданим вимогам.
Відновлення проектної інформації (design recovery) - це метод оберненої інженерії, у якому разом з початковим кодом під час відновлення проектної інформації використовуються всі доступні відомості про систему: проектна документація, досвід розробників і експлуатаційників, знання про домен. Головна мета відновлення проектної інформації - розроблення структур, які допоможуть інженерові програмного забезпечення зрозуміти програму або програмну систему. Отже, кінцевою метою е не специфікація вимог, яка відповідає аналізованому початковому коду, а проектна інформація.
Реструктуризація (restructuring) - це метод трансформації програмного забезпечення на одному рівні його уявлення шляхом використання інформації, котру отримали в процесі виконання реверсивної інженерії. Трансформація не приводить до зміни первинних вимог до програмного забезпечення (наприклад, реструктуризація - це перетворення неструктурної форми коду в структурну).
Редокументування (redocumentaiion) - це метод створення або перегляду семантично еквівалентних уявлень програмного забезпечення в рамках одного і того ж рівня. Прикладом може слугувати створення діаграм управління, описи структури програмного забезпечення у формі зручної для сприйняття людиною. Ключова роль цього методу полягає в тому, щоб забезпечити візуалізацію відношень, що мають місце між програмними компонентами для того, щоб розпізнати їх і управляти ними,
Реінженерія (reengineering) - це метол зміни програмного забезпечення шляхом використання методів прямої інженерії на основі відновленої (за допомогою оберненої інженерії) проектної інформації. До того ж, реінженерія веде до зміни системних і функціональних вимог програмного забезпечення і є методом ного переробки.
5.2.2. Інструменти оберненої інженеріїУсі інструменти оберненої інженерії утворюють інтегроване середовище - Computer Aided Reverse Software Environment (CARSE). Загальну архітектуру середовища зображено на рис. 5.7.
Рис. 5.7. Архітектура інструментів оберненої інженерії
5.3. Емпірична інженерія програмного забезпечення
Емпіричні методи досліджень відіграють «впливову» роль в інженерії програмного забезпечення і їх застосування складають одну з інженерій - емпіричну інженерію програмного забезпечення.
На відміну від прямої та оберненої інженерії мста емпіричної інженерії - не розробка або переробка програмного забезпечення, а здобуття знань про програмне забезпечення. Тому її основу складають два кола методів та засобів. Перше пов'язане із збиранням інформації щодо властивостей програмного забезпечення. Переважно це робиться шляхом застосування вимірювань. Друге складають методи та засоби обробки нагромадженої інформації і здобуття знань стосовно програмного забезпечення, що досліджується.
5.3.1. Методи емпіричної інженерії програмного забезпеченняГоловним методом досліджень програмного забезпечення є вимірювання. Для контролю процесів, продуктів та ресурсі в життєвого циклу програмного забезпечення слід використовувати величини характеризуючи їх властивості, що називаються метриками.
Величина - це певна властивість предмета, з якою можна зіставити значення. Для синтезу величини варто визначити властивість (семантику величини), систему значень (шкалу) та спосіб зіставлення значень з величиною.
У теорії вимірювання виділяють три основні шкали вимірювань - номінальну, порядкову і кількісну. Номінальна (класифікаційна) шкала включає значення, що проявляє себе лише у відношенні еквівалентності або може бути зіставлена з властивістю предмета (не упорядкованих один стосовно іншого). Наприклад, можна зіставити з вихідним текстом програми величину «мова програмування», значенням якої може бути назва однієї з мов (наприклад, «С», «С++», «Pascal», «Java» тощо). Такий же тип має шкала класифікування призначення модулів програмного забезпечення (наприклад, «Бази даних», «Математичні пакети», «Операційні системи» тощо). До номінальних величин застосовується тільки операція перевірки на еквівалентність. Порядкова (ординальна) шкала спостерігає за упорядкуванням одного значення стосовно іншого, до яких належать операції порівняння. Порядкову пікапу можна задати для більшості експертних оцінок, наприклад, оцінювання читабельності тексту програм - «незадовільно», «задовільно», «добре», «відмінно» або для оцінювання рівня інкапсуляції програмних компонентів - «лексичний», «операторний», «процедурний», «класний», «модульний». Кількісна шкала включає в себе значення, що проявили себе стосовно еквівалентності, порядку і адекватності. Такі величини дають змогу виковувати адекватні і мультиплікативні операції над значеннями (віднімання, множення, ділення). До них належать, наприклад, такі кількість рядків коду, складання коментарю, оцінювання трудозатрат на створення коду.
