У сучасній технології програмної інженерії використовуються категорії ПВК, кожна з яких є типовим поєднанням наведених вище аспектів розгляду ПВК, а саме:

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

- механізмів спеціалізації або настроювання родових знань на конкретні вимоги стосовно створюваних або цільових програмних систем;

- механізмів інтеграції ПВК у цільові системи;

- механізмів вибору серед готових конкуруючих ПВК, тих, що від-повідають вимогам цільової розробки і забезпечують мінімізацію когнітивної відстані для певних фаз життєвого циклу розробки. Експертне дослідження сучасного стану повторного використання дозволило виділити типові категорії ПВК, які значно поширені в сучасній практиці програмних систем. Їхні особливості обговорюються в п. 7.3.1-7.3.8.

7.3.1 Мови програмування високого рівня

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

Конструкції мов програмування високого рівня - це специфікації, котрі мають реалізацію в асемблері.

Постійна частина абстракції відповідає семантичному опису конструкцій мови на рівні метасимволів, змінна частина подана термінальними символами конструкцій.

Прихована частина абстракції містить подробиці реалізації конструкції в асемблері, наприклад, проміжні дані тощо.

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

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

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

Інтеграція окремих конструкцій кількох мов у нову мову програмування здійснюється як результат неформалізованої інтелектуальної діяльності автора-експерта. Прикладом може бути інтеграція конструкцій мов Алгол-60, Фортран, Кобол у мови PL/1, Алгол-68, Паскаль та ін.

7.3.2 Компоненти вихідного коду

Цим терміном назвемо фрагменти коду вихідною мовою програмування, які створювалися і запам'ятовувалися спеціально для повторного використання.

До цієї категорії належить абсолютна більшість ПВК, котрі на сьогодні масово використовуються. Бібліотеки функцій та класів для багатьох мов програмування налічують тисячі компонент.

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

Головна проблема у створенні бібліотеки ПВК - знайти точні специфікації абстракції для компонент. Без цього користувачу для вибору ПВК буде важко зрозуміти призначення компоненти, а іноді для такого розуміння навіть доведеться вдатися до аналізу власне коду компоненти, що зведе нанівець переваги повторного використання.

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

Спеціалізація компонент може відбуватися кількома способами. Найдавніший з них і досі має застосування - це пряме редагування вихідного коду, для чого доводиться доходити до подробиць низького рівня. У цьому разі ефективність застосування ПВК досить мала.

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

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

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

Для інтеграції ПВК більшість компіляторів з мов програмування мають автоматичні засоби складання модулів та вирішення можливої колізії імен.

7.3.3 Класи об'єктів та абстрактні класи

Згідно з парадигмою об'єктного підходу, наведеною в п. 3.3.1, програмна система розглядається як спільнота взаємодіючих об'єктів, істотними ознаками яких є:

- стан, поданий сукупністю атрибутів;

- поведінка;

- спроможність вступати у відношення з іншими об'єктами;

- спроможність посилати одне одному повідомлення.

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

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

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

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

Прикладами абстрактних класів служать так звані контейнерні класи - структури зберігання даних, для кожного з яких визначено правила запам'ятовування або видачі чергового елементу контейнерного класу, однак при цьому реалізація цих операцій залежить від типів елементів, що заповнюють "контейнери". Поширеними прикладами контейнерів можуть бути списки, черги, стеки, матриці, таблиці. Механізм контейнерів реалізовано в C++ у формі так званих шаблонів (templates), створено спеціальні бібліотеки ПВК такого типу.

7.3.4 Абстрактні архітектури програмних систем

Всяка архітектура визначається складом частин, з яких будується ціле, і способом їхньої композиції в ціле. Архітектура програмної системи (programming system architecture) визначається в термінах компонент, які виконують обчислення, та інтерфейсів між ними. Архітектура - це відображення правил декомпозиції складності проблеми.

Спектр задач проблемної галузі, що допускають схожі способи розв'язання їх, називають доменом предметної галузі. Абстрактна архітектура (abstract architecture) - це декомпозиція спільного вирішення для виділеного спектра завдань домену на підсистеми або ієрархію підсистем, на кожному рівні якої фіксуються можливі варіанти виділених параметрів та обмежень, котрим відповідають варіації складу виділених компонент.

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

Абстрактні архітектури звичайно будуються для вузьких проблемних галузей, що дозволяє досягти високої спільності підходів до вирішення властивих галузі завдань і, відповідно, високого рівня абстракції ПВК.

Прикладами ПВК абстрактних архітектур є:

- системи управління базами даних;

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

- архітектура експертної системи, основаної на правилах, тощо.

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

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

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

7.3.5 Генератори прикладних застосувань

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

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

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

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

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

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

Спеціалізація. Розробник програмної системи спеціалізує генератор, задаючи її специфікації.

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

Інтеграція. Як правило, генератор прикладних застосувань виробляє на виході завершену, готову для виконання систему, тому питання інтеграції для неї не ставиться. В тому разі, коли генератор генерує окремі компоненти систем, правила їхньої композиції визначаються в термінах абстракції високого рівня.

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

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

а) управління даними - базується на одній моделі даних; наприклад, на реляційній або ієрархічній;

б) генератори форм документів - базуються на асоціативному пошуку даних (так звані генератори звітів);

в) графічні генератори звітів - аналогічні текстуальним, але на виході дозволяють отримувати графічне подання результатів (даних) у формі графіків, діаграм тощо.

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

Генератори експертних систем. Експертні системи - це системи, які включають і застосовують для розв'язку задач домену експертні знання.

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

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

7.3.6 Абстрактні домени

Розвитком ідеї абстрактної архітектури є каталогізація доменів масового вжитку й узагальнення їхніх властивостей як поняття “абстрактний домен” [2]. Виконуючи аналіз подібності та розбіжностей сукупності доменів, експерти можуть помітити аналогії для таких, на перший погляд, відмінних речей, як продаж театральних квитків, резервування місць на рейси літаків або розподіл деталей на оброблення для верстатів заводського конвеєра. Помітивши аналогії в структурі знань різних із синтаксичного погляду доменів, експерти можуть ввести абстракції об'єктів, котрі можна конкретизувати у відповідні об'єкти аналогічних доменів. Вимоги до систем, що належать до цих доменів, може бути подано в термінах відповідного абстрактного домену.

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

Простір моделей систем об'єктів становлять 13 базових ієрархій. Верхній рівень моделі системи об'єктів кожної ієрархії визначається з використанням базових: поведінки, складу об'єктів, агентів, структури домену для одного класу проблем. Спеціалізація кожної із цих моделей (у формі систематичного додавання різних типів знань — станів, мети, подій) генерує простір до 200 листів-вузлів моделі систем об'єктів. Кожний вузол-лист визначається з використанням станів, переходів у стани, подій, об'єктів, агентів, структури домену, абстрактних відношень між об'єктами й агентами, передумов переходів у стани, властивостей та атрибутів об'єктів. Перелічимо 13 моделей верхнього рівня:

а) повернення ресурсів - — двоспрямоване передавання ключових об'єктів від структури, що зберігає, до клієнтської і навпаки, наприклад, бібліотеки;

б) забезпечення ресурсами - односпрямоване передавання ресурсів від структури, що зберігає, до клієнтської та контроль за необхідністю поповнення ресурсами структури, що зберігає, наприклад, складів;

в) використання ресурсів - односпрямоване передавання від структури, що зберігає, до клієнтської для оброблення;

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

д) декомпозиція на елементи;

е) розміщення ресурсу - моделює зміни стану ресурсу щодо інших транзакцій, наприклад, стани квиткових кас;

ж) логістика - комплексна діяльність з планування, наприклад, маршрутів парку машин;

и) спостереження за об'єктами - відстеження руху об'єкта в просторі чи у фізичній структурі, наприклад, радарне;

к) побудова сполучення між об'єктами - пов'язування об'єктів, які володіють інформацією, в топологію зв'язків;

л) управління агента об'єктом - подання команд та керуючих компонент, до яких агенти посилають повідомлення, що викликають зміни в поведінці об'єктів, наприклад, контроль суден у порту;

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

н) оброблення ділянок — діалогові зміни стану ділянки, наприклад, обробка слів або креслень;

п) перегляд об'єкта - домени, в яких об'єкти не змінюють стану, але переглядаються агентами - людьми або комп'ютерами.

Перелік абстрактних доменів, безперечно, може бути поповнено, якщо певна спільнота професіоналів може узагальнити сукупність розв'язаних нею проблем у формі абстрактного домену. Прикладом домену масового використання, досвід роботи з яким дозволяє побудувати його абстракцію, є задачі так званої аналітичного оброблення даних, чи не наймасовіші у сфері економічних завдань, зокрема АСУ, здавна відомі під назвою отримання розрізів даних [3, 4].

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

7.3.7 Патерни

Тип ПВК, який позначається терміном “патерн”, є принципово відмінним від тих, котрі розглянуто дотепер і котрі, певною мірою, належали до програмних модулів чи їх узагальнень.

Патерни є абстракцією спілкування (взаємодії) певної сукупності об'єктів у кооперативній діяльності, для якої визначено абстрактних учасників, їхні ролі, взаємовідносини та розподіл відповідальності.

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

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

Патерни мають певний контекст застосування; зазвичай можна визначити і мотиви доцільності застосування патерну, й аргументи, що суперечать їм. І кожне з рішень має певну вартість, а опис патерну має визначати цю вартість.

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

Спеціалізація патернів відбувається шляхом конкретизації (довизначення) об'єктів, котрі беруть участь у взаємодії.

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

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

Відомо кілька таких зібрань, окремі з яких вже широко застосовуються в процесі розроблення програмних систем, і не лише як певні готові рішення, які можна використати повторно, а і як засоби обговорення прийнятих рішень та визначення їх [5].

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

Креативні патерни (від англ. create - створювати) відображають процеси створення екземплярів об'єктів. Нижче наведено приклади таких патернів: