ТЕМА 5
ПРИКЛАДНІ Й ТЕОРЕТИЧНІ МЕТОДИ ПРОГРАМУВАННЯ

 

Ядро SWEBOK містить у собі два близьких за змістом розділи, які пов’язані з побудовою ПЗ: проектування ПЗ і конструювання ПЗ. Розділ, що стосується програмування, в цьому ядрі відсутній, проте він є необхідний, оскільки в сучасній практиці проектування і розробка ПП широко використовуються багато різних парадигм програмування (модульне, об’єктно-орієнтоване, компонентне, аспектне тощо), які мають бути певним чином систематизовані.

Кожна парадигма програмування характеризується наявністю в ній метода і зв’язком з моделлю ЖЦ. Головне, що об’єднує різні парадигми програмування, – це загальні положення з проектування ПП. Користувач може вибирати ту або іншу парадигму програмування з позицій зручності застосування для задач у ПрО і виготовлення конкретного ПП.

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

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

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

 

5.1. Прикладне (систематичне) програмування

До методів систематичного програмування відносять такі методи:

– структурний;

– об’єктно-орієнтований;

– UML-метод;

– компонентний;

– аспектно-орієнтований;

– генерувальний;

– сервісний;

– агентний й ін.

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

 

5.1.1 Структурне програмування

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

Основу структурного програмування становлять:

– розподіл системи на множину незалежних задач, доступних для розуміння і розв’язання;

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

До головних принципів належать:

– абстрагування, тобто відокремлення істотних аспектів системи й нехтування несуттєвими;

– формалізація, тобто загальне методологічне вирішення проблеми;

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

– утворення ієрархічної структури даних.

При структурному аналізі застосовуються три найпоширеніші моделі структурного проектування ПС:

SADT (Structured Analysis and Design Technique) – метод структурного аналізу й техніка проектування моделі системи за допомогою функціональних діаграм [1];

SSADM (Structured Systems Analysis and Design Method) – метод структурного аналізу й проектування систем [2];

IDEF (Integrated Definition Functions) – метод визначення функціональної моделі, IDEF1 – інформаційної моделі, IDEF2 – динамічної моделі й ін. [3].

Розглянемо ці методи детальніше.

Метод функціонального моделювання SADT. Цей метод запропоновано Д. Россом і покладено в основу методології IDEF0 (Icam DEFinition), що є головною частиною програми ICAM (Інтеграція комп’ютерних і промислових технологій), проведеної з ініціативи ВПС США.

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

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

Метод SADT базується на наступних концепціях:

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

 

Рис. 5.1. Структура моделі

 

– блоків може бути від 3 до 6 на кожному рівні декомпозиції;

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

– унікальність позначок і найменувань;

– незалежність функціональної моделі від організаційної структури колективу розробників.

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

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

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

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

Загальна діаграма системи згідно з цим методом має ієрархічну структуру і містить у собі: список компонентів модельованого об’єкта; ідентифіковані групи вибраних і повторюваних компонентів; послідовність використовуваних компонентів.

Таке програмування передбачає наявність моделі ЖЦ із послідовними процесами розробка програмного проекту, починаючи з аналізу і формування вимог для ПрО (рис. 5.2).

До процесів ЖЦ належать:

– стратегічне проектування та вивчення можливості виконання проекту;

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

– логічне проектування та специфікація компонентів системи;

– фізичне проектування структур даних відповідно до вибраної структури БД (реляційної, об’єктно-орієнтованої й ін.) та конструювання окремих компонентів, їх тестування і тестування системи в цілому;

– виготовлення продукту і документації з нього для замовника.

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

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

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

Фізичне проектування – це визначення типу СКБД і подання даних у ній з урахуванням специфікації логічної моделі даних, обмежень на пам’ять і час обробки, а також визначення механізмів доступу, розміру логічної БД, зв’язків між елементами системи.

Фізична специфікація містить у собі:

– специфікацію функцій і схеми реалізації компонентів функцій;

– опис процедурних і непроцедурних компонентів й інтерфейсів;

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

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

Процеси, які виконуються у SSADM, пов’язані з роботами, що керують потоками інформації трьох типів: потік робіт; санкціоновані потоки за контролем або керуванням; звіти про хід розробки.

Конструювання – це побудова конструкцій і елементів системи, їхнє тестування на наборах даних, які підбираються на ранніх процесах ЖЦ розробки системи.

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

 

Рис. 5.2. Життєвий цикл SSADM

 

Згідно з методом SADM створюється структурна модель системи і модель потоків даних. У діаграмах структурної моделі впорядкування процесів наведено зліва направо і віддзеркалює розвиток у часі, а не інтервали часу.

Модель потоків даних (Data Flow Model – DFM) використовується для опису процесів обробки даних у системі й містить у собі:

– ієрархічний набір діаграм потоків даних (Data Flow Diagram – DFD);

– опис елементарних процесів, потоків даних, сховищ даних і зовнішніх сутностей.

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

До об’єктів моделювання системи в SSADM належать:

1. Функції, які створюються на основі DFM і моделювання взаємозв’язків подій і сутностей для дослідження обробки даних у системі;

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

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

Найпоширеніші засоби моделювання даних – діаграми «сутність-зв’язок» (ER-діаграми), запропоновані Баркером, як застосування класичної ER-моделі Чена. В ER-діаграмах визначаються сутності (множини однотипних об’єктів) ПрО, їхні властивості (атрибути) і залежності (зв’язки). Сутність (Entity) – реальний або уявлюваний об’єкт, що має істотне значення для області. Кожна сутність й її екземпляр мають унікальні імена. Сутність має такі властивості:

– один або кілька атрибутів, які або належать сутності, або успадковуються через зв’язок (Relationship);

– довільну кількість зв’язків з іншими сутностями моделі.

Зв’язок – це асоціація між двома сутностями ПрО. У загальному випадку кожен екземпляр сутності-батька асоційований з довільною кількістю екземплярів успадкованої сутності (нащадка), а кожен екземпляр сутності-нащадка асоційований з одним екземпляром сутності-батька. Таким чином, екземпляр сутності-нащадка може існувати тільки при наявності сутності-батька. Для зв’язків можуть встановлюватися обмеження на кількість екземплярів сутності, що беруть участь у зв’язку. Наприклад, одному екземпляру однієї сутності може відповідати не більше ніж один екземпляр іншої.

Метод IDEF1 базується на концепції ER-моделювання і призначений для побудови інформаційної моделі подібно до реляційної моделі. Даний метод постійно розвивається й удосконалюється (наприклад, методологія IDEF1X- проектування, орієнтована на автоматизацію – ERwin, Design/IDEF). Основна особливість полягає в тому, що кожен екземпляр сутності може бути однозначно ідентифікований без визначення відношення з іншими сутностями. Якщо ідентифікація екземпляра сутності залежить від його відношення до іншої сутності, то сутність є залежною. Кожній сутності присвоюється унікальне ім’я і номер, які розділяють косою рискою «/» і розміщують над блоком, який позначає сутність. Обмеження на множинність зв’язку можуть означати, що для кожного екземпляра сутності-батька існує:

– нуль, один або більше пов’язаних з ним екземплярів сутності-нащадка;

– не менше ніж один або не більше ніж один пов’язаний з ним екземпляр сутності-нащадка;

– зв’язок з деяким фіксованим числом екземплярів сутності-нащадка.

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

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

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

– інформації й структури потоків, що властиві діяльності підприємства;

– правил і законів руху інформаційних потоків і принципів керування ними;

– взаємозв’язків між існуючими інформаційними потоками на підприємстві;

– проблем, що виникають при неякісному інформаційному менеджменті і потребують усунення.

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

Інструментальна підтримка SSADM. Головний інструмент структурного проектування відповідно до процесів ЖЦ – комплекс програмних, методичних й організаційних засобів системи SSADM. Ця система прийнята державними органами Великобританії як основний системний засіб і використовується багатьма державними організаціями і в межах, і за межами країни. SSADM містить у собі п’ять головних модулів підтримки, як процесів ЖЦ з проектування ПП [2]:

1) вивчення можливості виконання проекту (Feasibility Study Module);

2) аналіз вимог (Requirements Analysis Module);

3) специфікація вимог (Requirements Specification Module);

4) логічна специфікація системи (Logical System Specification Module);

5) фізичне проектування (Physical Design Module).

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

– забезпечення вимог користувача до якості системи;

– керування розробкою проекту.

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

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

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

Проблема якості стосується двох основних аспектів:

1) сукупності функцій, що повинні задовольняти задані вимоги до функцій, надійності й продуктивності;

2) способу реалізації системи.

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

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

Ідеологія структурного проектування втілена в ряді CASE-засобів (SilverRun, Oracle Disigner, ErWin й ін.), що активно використовується на практиці.

 

5.1.2. Об’єктно-орієнтоване програмування

У темі 4 були розглянуті основні методи об’єктно-орієнтованого аналізу і проектування, а саме, поняття об’єкта, об’єктної та інших моделей (наприклад, інформаційної моделі, моделі станів тощо), які були запропоновані різними авторами в період бурхливого розвитку об’єктно-орієнтованої парадигми. Далі розглядаються аспекти об’єктно-орієнтованого програмування систем, а саме, операції над об’єктами та процеси ЖЦ для побудови прикладних об’єктно- орієнтованих ПС [4, 5].

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

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

Операції над об’єктами. Це такі операції:

– введення, збереження, видалення об’єктів тощо, тобто це операції життєвого циклу об’єктів;

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

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

Кожна операція має ім’я, список вхідних параметрів і вихідних результатів, якщо вони є.

Загальна форма опису операції має вигляд:

 

operation_name (param1,..., paramn)

returns (res1,..., resm)

parami :: = parameter_name : parameter_type

resi :: = result_name : result_type

 

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

 

w: (x1:s1, x2:s2,..., xn:sn) (y1:r1, y2:r2,..., ym:rm),

де w – ім’я операції;

x1, x2,..., xn – вхідні параметри, а x1 – керуючий оператор;

s1, s2,..., sn – типи вхідних параметрів;

y1, y2,..., ym – вихідні параметри;

r1, r2,..., rm – типи вихідних параметрів.

 

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

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

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

Об’єктно-орієнтована модель програмної системи створюється на таких процесах ЖЦ (рис. 5.3):

 

Рис. 5.3. ЖЦ розробки моделі системи у середовищі ООП

 

Етапам відповідають такі процеси:

– аналіз – створення ОМ ПрО, у якій об’єкти відбивають її реальні сутності і операції над ними;

– проектування – уточнення ОМ з урахуванням опису вимог для реалізації конкретних задач системи;

– програмування – реалізація ОМ засобами мов програмування С++, Java та ін.;

– супроводження – використання й розвиток системи шляхом внесення змін у об’єкти або в методи;

– модифікація ПС в процесі її супроводження шляхом додавання нових функціональних можливостей, інтерфейсів і операцій.

Наведені процеси можуть виконуватися ітераційно один за одним і з поверненням до попереднього процесу. На кожному процесі може застосовуватися та сама система нотацій.

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

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

Існує два типи моделей системної архітектури:

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

динамічна модель для опису динамічної структури системи і взаємодії між об’єктами (але не класами об’єктів) під час роботи системи.

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

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

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

 

5.1.3. UML-метод моделювання

Загальна характеристика UML (Unified Modeling Language), як підход до проектування різних систем, була дана у п. 4.2.1. Тут UML розглядається детальніше, як мова візуального моделювання систем, шляхом подання у вигляді діаграм їхніх статичних і динамічних моделей на всіх процесах ЖЦ [6, 7].

В основу методу покладено парадигму об’єктного підходу, при якій концептуальне моделювання проблеми полягає у побудові:

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

– моделі поведінки, яка задає можливі стани об’єктів, інцидентів, що ініціюють переходи з одного стану до іншого, а також повідомлення, якими обмінюються об’єкти;

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

Проектування в UML починається з побудови сукупності діаграм, які візуалізують основні елементи структури системи.

Мова моделювання UML підтримує статичні і динамічні моделі, зокрема модель послідовностей – одну з найкорисніших і наочних моделей, в кожному вузлі якої є взаємодіючі об’єкти. Всі моделі зображаються діаграмами, коротка характеристика яких дається нижче.

Діаграма класів (Class diagram) відображає онтологію домену, за змістом еквівалентна структурі інформаційної моделі методу С.Шлєєра і С.Мелора, визначає склад класів об’єктів і їх зв’язків. Діаграма задається зображенням, на якому класи позначаються поділеними на три частини прямокутниками, а зв’язки − лініями, що з’єднують прямокутники. Це відповідає візуальному зображенню понять і зв’язків між ними. Верхня частина прямокутника − обов’язкова, в ній записується ім’я класу. Друга і третя частини прямокутника визначають відповідно список операцій і атрибутів класу, що можуть мати такі специфікатори доступу:

– рublic (загальний) позначає операцію або атрибут, доступ до яких здійснюється з будь-якої частини програми будь-яким об’єктом системи;

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

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

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

Класи можна перебудувати в наступних відношеннях або зв’язках.

Асоціація – взаємна залежність між об’єктами різних класів, кожний з яких це рівноправний її член. Вона може позначати кількість екземплярів об’єктів кожного класу, які беруть участь у зв’язку (0 – якщо жодного, 1 – якщо один, N – якщо багато).

Залежність – відношення між класами, при якому клас-клієнт може використовувати певну операцію або сервіс іншого класу; класи можуть бути зв’язані відношеннями трасування, якщо один клас трансформується в іншій внаслідок виконання певного процесу ЖЦ.

Екземпляризація – залежність між параметризованим абстрактним класом- шаблоном (template) і реальним класом, який ініціює параметри шаблону (наприклад, контейнерні класи мови С++).

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

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

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

Діаграма діяльності задає поведінку системи у вигляді певних робіт, які може виконувати система або актор і ці роботи можуть залежати або від заданих умов, або від обмежень. Ця діаграма відображає функціональну структуру системи і принципи поведінки її окремих елементів під час виконання відповідної діяльності. Приклад використання діаграми діяльності UML наведено у структурі програми «Сплата послуг» (рис. 5.4).

 

Рис. 5.4. Діаграма програми розрахунку і оплати послуг

 

У діаграмі виконано ряд послідовних дій з розрахунку вартості послуг. Залежно від наявності боргу відбувається перехід у кінцевий стан або розділення потоків на два паралельних. У лівій гілці виконується дія «послати повідомлення про сплату» і «отримати сплату», а в правій – лише «отримати сплату».

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

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

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

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

Побудова ПС методом UML здійснюється у наступні етапи ЖЦ (рис 5. 5.).

 

Рис. 5.5. Схема моделювання і проектування ПС в UML

 

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

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

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

 

5.1.4. Компонентне програмування

За оцінками експертів в інформаційному світі 75 % напрацювань із програмування дублюються (наприклад, програми складського обліку, нарахування зарплати, розрахунку витрат на виробництво продукції і т.п.). Більшість з цих програм типові, але кожного разу знаходяться особливості ПрО, що призводять до їх повторної розробки.

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

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

Об’єкти розглядаються на логічному рівні проектування ПС, а компоненти – це безпосередня фізична, тобто програмна реалізація об’єктів. Співвідношення між об’єктами і компонентами неоднозначне. Один компонент може бути реалізацією декількох об’єктів або навіть деякої частини системи, отриманої при проектуванні. Зворотне співвідношення, тобто компонент – об’єкт, як правило, не виконується [8–13].

Перехід до компонентів відбувався еволюційно (табл.5.1.): від підпрограм, модулів і функцій.

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

Компоненти конструюються самостійно, як деяка абстракція, що містить у собі інформаційну частину й артефакт (специфікація, код, каркас і ін.).

В інформаційній частині задаються відомості: призначення, дата виготовлення, умови застосування (ОС, середовище, платформа і т.п.).

Артефакт – це реалізація (implementation), інтерфейс (interface) і схема розгортання (deployment) компонента.

Реалізація – це код, що буде виконуватися при зверненні до операцій, визначених в інтерфейсах компонента. Компонент може мати кілька реалізацій залежно від операційного середовища, моделі даних, СКБД і ін.

Для опису компонентів, як правило, застосовуються мови об’єктно- орієнтованого програмування, зокрем Java, у якій поняття інтерфейсу і класу – базові, використовуються в моделях Javabeans і Enterprise Javabeans і в об’єктній моделі CORBA [14].

 

Таблиця 5.1. Схема еволюції повторних елементів компонентного типу

Елемент композиції

Опис елемента

Схема взаємодії

Форма збереження

Результат композиції

Процедура, підпрограма, функція

Ідентифікатор

Безпосереднє звертання, оператор виклику

Бібліотки підпрограм і функцій

Програма на мові програмуваннч

Модуль

Паспорт модуля, зв’язки

Виклик модулів, інтеграція модулів

Банк, бібліотеки модулів

Програма з модульною структурою

Об’єкт

Опис класу

Створення екземплярів класів, методів

Бібліотеки класів

Об’єктно-орієнтована програма

Компонент

Опис логіки, інтерфейсів (API, IDL), схеми розгортки

Віддалений виклик в компонентних моделях (COM, CORBA, OSF, JAVA, …)

Репозиторій компонентів, сервери, контейнери компонентів

Розподілена компонентно-орієнтована програмна система

Сервіс

Опис логіки та інтерфейсів (XML, WSDL,…)

Віддалений виклик (RPC, HTTP, SOAP,…)

Індексація і каталогізація сервісів (XML, UDDI,…)

Розподілений сервісно-орієнтований застосунок

 

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

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

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

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

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

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

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

Каркас типу «біла скринька» містить у собі абстрактні класи для зображення об’єктів і їх інтерфейсів. При реалізації ці класи трансформуються в конкретні класи з указівкою відповідних методів реалізації. Використання такого типу каркаса є характерним для OOП.

Для каркаса типу «чорна скринька» у його видиму частину виносять точки, що дозволяють змінювати входи і виходи.

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

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

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

Перший тип інтерфейсу − домашній (Home interface) забезпечує керування екземплярами компонента з обов’язковими реалізаціями методів пошуку, створення і видалення окремих екземплярів.

До другого типу належать функціональні інтерфейси (fuction interface), що забезпечують доступ до реалізації компонента. Фактично з кожним екземпляром зв’язаний свій функціональний інтерфейс.

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

Архітектура компонентного середовища може складатися з наступних типів об’єктів:

– сервери компонентів;

– контейнери компонентів;

– реалізації функцій, подані як екземпляри усередині контейнерів;

– реалізація компонентних моделей, об’єктів, що задовольняють установку і конфігурування окремих компонентів для деякої комп’ютерної платформи;

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

– компонентне застосування, як сукупність компонентів.

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

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

Композиція (інтеграція) компонентів і розгортання не залежать від ЖЦ розробки компонентів, заміна будь-якого компонента на новий компонент не повинна призвести до перекомпіляції або перенастроювання зв’язків у ПС.

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

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

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

Структури з компонентів. Композиція компонентів може бути таких типів: компонент з компонентом зв’язані через інтерфейс на рівні застосування; каркас з компонентом зв’язані через інтерфейси на системному рівні; компонент з каркасом взаємодіють через інтерфейси на сервісному рівні; каркас з каркасом взаємодіють через інтерфейси на мережному рівні.

Компоненти запам’ятовуються в репозитарії компонентів, а їхні інтерфейси – в репозитарії інтерфейсів. Компоненти і їхні композиції, як правило, запам’ятовуються в репозитарії компонентів, а їхні інтерфейси також в репозитарії інтерфейсів.

Повторне використання в компонентному програмуванні – це застосування готових порцій формалізованих знань, здобутих під час попередніх реалізацій ПС, у нових розробках систем [13-15].

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

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

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

Пошук готових компонентів ґрунтується на методах класифікації і каталогізації. Методи класифікації призначені для подання інформації про компоненти з метою швидкого пошуку і добору. Методи каталогізації – для їхнього фізичного розміщення в репозитаріях із забезпеченням доступу до них у процесі інтеграції в компонентну систему.

Методологія компонентної розробки ПС. Створення компонентної системи починається з аналізу ПрО і побудови концептуальної моделі, на основі якої створюється компонентна модель (рис. 5.6).

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

Готові компоненти беруться, наприклад, з репозитаріїв у Інтернеті і використовуються при створенні програмних систем, технологія побудови яких описується наступними етапами ЖЦ.

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

2. Розробка вимог (Requirements) до ПС – це формування й опис функціональних, нефункціональних і інших властивостей ПС.

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

 

Рис. 5.6. Схема побудови ПС із компонентів, взятих з Інтернету

 

4. Специфікація інтерфейсів і взаємодій компонентів (Interface and Interaction Specification) віддзеркалює розподіл ролей компонентів, інтерфейсів, їхню ідентифікацію і взаємодію компонентів через потоки дій або робіт (workflow).

5. Інтеграція набору компонентів і КПВ (Application Assembly and Component Reuse) у єдине середовище ґрунтується на підборі й адаптації КПВ, визначенні сукупності правил, умов інтеграції і побудові конфігурації каркаса системи.

6. Тестування компонентів і середовища (Component Testing) ґрунтується на методах верифікації і тестування для перевірки правильності як окремих компонентів і КПВ, так і інтегрованої з компонентів програмної системи.

7. Розгортання (System Deployment) містить у собі оптимізацію плану компонентної конфігурації з урахуванням середовища, розгортання окремих компонентів і створення цільової компонентної конфігурації для функціонування ПС.

8. Супровід ПС (System Support and Maintenance) складається з аналізу помилок і відмов при функціонуванні ПС, пошуку і виправлення помилок, повторного її тестування й адаптації нових компонентів до вимог і умов інтегрованого середовища.

Таким чином, компонентне програмування є основою економії витрат на програмування нових програм за рахунок використання готових КПВ, які можуть зберігатися у різних сховищах (бібліотеках, репозитаріях, базах знань тощо).

 

5.1.5. Аспектно-орієнтоване програмування

Аспектно-орієнтоване програмування (АОП) [15-17] – це парадигма побудови гнучких до змін ПС шляхом додавання нових аспектів (функцій), що забезпечують, наприклад, безпеку, взаємодію компонентів з іншим середовищем, а також синхронізацію одночасного доступу частин ПС до даних і виклик нових компонентів із загальносистемних середовищ.

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

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

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

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

В АОП при виробленні проектних рішень використовується механізм фільтрації вхідних повідомлень, за допомогою яких проводиться зміна параметрів і імен текстів аспектів у конкретно заданому компоненті системи. Код компонента стає «нечистим», коли його перетиняють аспекти, іпри композиці. з іншими компонентами загальні засоби (виклик процедур, RPC, RMI, IDL і ін.) стають недостатніми. Оскільки аспекти вимагають декларативного зчеплення описів, особливо коли їх фрагменти беруться з одних об’єктів для інших.

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

В ОО-системах можуть використовуватися методи, призначені для виконання деяких розрахунків при звертання до інших зовнішніх методів. У [17] сформулювано закон, відповідно до якого не повинні створюватися довгі послідовності дрібних методів, тому що в вихідному коді з’являться операції, які не пов’язані з іменами класів компонентів.

З погляду моделювання, аспекти можна розглядати як каркаси декомпозиції системи, в яких окремі аспекти перетинають КПВ, як схематично показано на рисунку 5.1 для програм Р1, Р2 і Р3, тобто в певних точках різних КПВ може бути звернення до одного аспекту.

На наведеному рисунку, наприклад, програма Р1 містить у собі аспект, що здійснює звертання до деякої точки програми Р2, яка після отримання інформації записує її у захищену БД, а потім аспект програми Р2 забезпечує взаємодію з програмою Р3 для передавання відомостей про запис необхідної інформації у БД.

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

 

Рис. 5.7. Приклад розташування аспектів у програмах Р1, Р2 і Р3

 

Через аспектні механізми встановлюються зв’язки з іншими предметними областями в сімействі програм або систем ПрО. Мова АОП дозволяє описувати аспекти для різних систем сімейства. Після компіляції описів перетинних аспектів, вони генеруються [16], поєднуються, оптимізуються і орієнтуються на виконання в динаміці. При цьому кожний аспект може стати модулем-посередником, що реалізує шаблон взаємодії окремих програм або систем.

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

Аналіз ПрО закінчується побудовою характеристичної моделі та встановленням статичних або динамічних зв’язків з додатковими аспектами моделі. Різним аспектам ПС, як правило, відповідають різні парадигми програмування, які вимагають їхнього вдосконалення й узагальнення при розробленні ПЗ для нової ПрО.

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

Технологія розробки ПС методами АОП містить у собі ряд загальних процесів (рис. 5.8), описаних далі.

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

2. Аналіз мов специфікації аспектів для опису виділених аспектів й інших задач ПрО.

3. Визначення точок вбудовування аспектів у компоненти й формування посилань і зв’язків з іншими елементами ПрО.

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

 

Рис. 5.8. Технологічна схема проектування ПС засобами АОП

 

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

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

7. Компіляція, спільне налагодження модулів і аспектів, після чого композиція їх у готовий програмний продукт.

Для ефективної реалізації аспектів розроблені системи Aspect, ІР1-бібліотека розширень, активні бібліотеки, а також проведене розширення МП Smalltalk засобами опису аспектів (Aspect++, Aspect, AspectC#, JAC).

Систему Aspect розробив дослідницький центр Xerox PARC в цілях підтримки АОП на базі мови Java [15, 16].

Мова цієї системи є розширенням мови Java засобами АОП, тобто будь-яка програма на Java буде виконуватися в системі Aspect. Система має компілятор, налагоджувач і генератор документації.

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

– точка під’єднання JoinPoint у програмі, асоційована з контекстом виконання (виклик методу, конструктора, доступ до поля класу й ін.);

– набір точок зрізу Pointcut для точок JoinPoint, що задовольняє певні умови;

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

– завдання аспекту Introduction для змінювання структури Java-класу шляхом додавання нових полів, методів і ієрархії.

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

Загальними принципами розробки ПС із використанням засобів АОП системи Aspect є:

– побудова моделі ПС за компонентами і аспектами;

– виділення в окремі модулі наскрізної функціональності шляхом аспектної декомпозиції;

– реалізація кожної вимоги окремо;

– інтеграція аспектів у програмний код.

Інтеграція аспектів відбувається в момент компіляції. Модель побудови готової ПС із компонентів, аспектів та фрагментів готового коду подано на рисунку 5.9 [15].

 

Рис. 5.9. Інтеграція аспектів і компонентів

 

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

Існують інші реалізації АОП: AspectC++, AspectC, AspectC#, розширення мов С++, С, С# аспектами; JAC система, написана мовою Java, для створення розподілених ПС; Weave.NET – проект реалізації механізму підтримки АОП без прив’язки до конкретної МП усередині компонентної моделі.NET Framework і ін.

У процесі створення ПС із застосуванням аспектів можуть використовуватися: ІP-бібліотека розширень, що містить у собі їх коди, а також активні бібліотеки, мова програмування SmallTalk, розширені засоби опису аспектів [17].

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

Використання таких бібліотек у розширених середовищах програмування називають родовим програмуванням, а вирішення проблем економії, перебудови компіляторів під кожне нове мовне розширення, використання шаблонів і результатів попередньої обробки відносять до області ментального програмування [17]. Бібліотека IP містить у собі: окремі функції компіляторів, засоби оптимізації, редагування, відображення понять, перебудови окремих компонентів компіляторів під нове мовне розширення, а також засоби програмування на основі шаблонів і т.п. Бібліотеки з такими можливостями одержали назву бібліотек генерації.

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

 

5.1.6. Генерувальне (порождувальне) програмування

Генерувальне програмування (generative programming) – це методи і засоби генерації сімейств систем і застосувань з окремих компонентів, аспектів, КПВ, каркасів і ін. Базис цього програмування – ООП, доповнене механізмами генерації багаторазових елементів і КПВ, а також властивостями їхньої змінюваності, взаємодії й ін. [17]. Це програмування є новим видом програмування, в ньому використовуються різні методи інженерії складних ПрО для розробки сімейств ПС із різних виготовлених раніше програмних продуктів, згенерованих програмних застосувань і систем, сімейств систем, члени яких задовольняють певні показники якості.

Головний продукт інженерії ПрО – це сімейство ПС, яке генерується на основі загальної генерувальної моделі домену GDM (Generative Domain Model), що містить у собі засоби визначення окремих членів (представників) сімейства, до яких відносять предметно-орієнтовану мову DSL (Domain Specific Language), методи генерації окремих членів і їх збирання у сімейство, а також базу конфігурації для розгортання сімейства або його членів у середовищі.

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

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

Задачі простору проблем предметної області або окремих членів сімейства, як правило, визначаються різними предметно-орієнтованими мовами. В даному випадку термін «мова» використовується в загальному розумінні. Тобто така мова може бути подана як засіб опису специфічних понять ПрО, різних аспектів функціонування задач за допомогою операції взаємодії членів сімейств або їх складових і т.п. Поняття ПрО можуть бути поданні також процедурами, функціями, методами, як в ООП. Вони, як відомо, зберігаються в бібліотеках або вбудовуються в універсальну мову програмування (наприклад у С++, С# тощо). Коли в таку мову додаються різного типу абстракції опису різних задач ПрО, її називають модульною предметно-орієнтованою мовою.

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

До предметно-орієнтованих мов відносять такі:

– мова опису специфіки домену;

– мова опису функціональних задач домену;

– мова опису аспектів взаємодії, синхронізації компонентів у середовищі;

– мова опису захисту даних та безпеки виконання сімейства систем;

– мова опису інтерфейсів (PDL, IDL тощо).

Предметно-орієнтована мова – DSL. Вона вналежить до класу мов опису специфіки ПрО або домену, властивої саме цьому домену. Опис кожного члена сімейства може містить мову опису специфіки задач домену і генеруючої моделі домену GDM (Generative Domain Model), яка відображає склад домену із членів сімейства, специфікованих також у предметно-орієнтованих мовах.

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

Відомо, що будь-яка мова має визначену область застосування, проте мова DSL є більш спеціалізованою, ніж інші мови програмування (Паскаль, Кобол), що створювалися для розв’язання конкретних типів задач (обчислювальних, економічних). Порівняно з ними, DSL близька до описових мов, таких, як HTML, XML. Вона має специфічні особливості порівняно з мовами загального призначення, а саме:

– абстракції DSL забезпечують визначення концепцій і абстрактних понять у предметній області;

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

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

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

– інструменти підтримки DSL потребують відповідного оточення, наприклад, середовища, редактора, контролера версій тощо.

Специфікована в DSL модель ПрО є загальною моделлю GDM (рис. 5.10).

 

Рис. 5.10. Структура генерувальної моделі GDM

 

Модель відображає:

– поняття, характеристики ПрО і членів сімейства в просторі проблем; – набір членів сімейства і їхніх специфікацій у мовах типу DSL, RAISE (Rigorous Approach to Industrial Software Engineering), RSL (RAISE Specification Language) і ін.;

– задачі ПрО в просторі задач для їхньої реалізації компонентами і з наступним їхнім збиранням в конфігурацію визначених членів сімейства;

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

– модель характеристик (feature models) відображає загальні, змінювані і незмінні характеристики членів сімейства і правила конструювання систем сімейства з урахуванням їхньої залежності один від одного і від компонентів типу КПВ;

– архітектуру (каркас) сімейства систем;

– реалізацію компонентів архітектури у мовах програмування.

Генерувальне програмування чітко поділяється на дві частини дослідження і проектування продукту ПрО – формування опису простору проблеми і простору розв’язків задач ПрО [5]. Перша частина призначена для проведення аналізу ПрО, виявлення її задач, які потрібно реалізувати, а друга – для розробки засобів реалізації цих задач. Ці частини об’єднує конфігураційна і трансформаційна база знань про конфігурацію, тим самим утворюючи структуру моделі генерації у ПрО (або GDM) розроблюваних ПС.

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

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

Простір рішень (solution space) – це компоненти, каркаси, шаблони проектування ПрО, а також засоби їхнього з’єднання або вбудування в ПС і оцінки повноти. Елементи цього простору реалізують розв’язання задач ПрО. Каркас системи або сімейства систем оснащений механізмом зміни параметрів, що вимагають фрагментації множини дрібних методів і класів. Він забезпечує створення багаторазових і використовуваних розв’язків у різних типах ПС, а також використання аспектів синхронізації, взаємодії і захисту даних за допомогою технології JavaBeans та нових механізмів композиції і генерації у деякому середовищі, наприклад, Eclipsе.

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

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

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

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

У генерувальному програмуванні головним об’єктом є КПВ. Він використовується при створенні членів сімейства за двома інженерними напрямами [11-14]:

1) прикладна інженерія (Application Engineering) – процес розробки конкретних систем, так званих одиночних програм, із КПВ, а також із застосуванням раніше створених незалежних ПС у різних середовищах;

2) інженерія ПрО (Domain Engineering) – побудова архітектури членів сімейства або самого сімейства систем шляхом використання КПВ, які зафіксовані у сховищах, а також частин і членів сімейства систем конкретної ПрО, отриманих за моделлю GDM (більш докладно див. тему 9).

У цих напрямах інженерії моделювання архітектури здійснюється за модельно-орієнтованим підходом і завершується побудовою архітектури MDA (Model Driven Architecture). Моделювання MDA-архітектури відбувається на двох рівнях – платформо незалежному (за допомогою моделі PIM, Platform Independent Model) і платформо залежному (за допомогою моделей PSM, Platform Specific Models). Таке моделювання підтримує концепцію відображення простору у простір задач. Тобто в моделі сімейства ПС члени сімейства можуть мати спільні функції, але вони розрізняються платформами реалізації.

Вибір альтернативних платформ – є «точкою варіантності» у сімействі. Ця точка знаходиться над моделлю ПС, тобто вона невидима на її рівні. Керування «точкою варіантності» платформ відбувається через трансформацію PIM → PSM без участі розробника.

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

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

– розробка ПрО й одиночних програм;

– повторне використання ресурсів;

– менеджмент домену.

Розробка ПрО з КПВ є конвеєрною. Для ПрО плануються базові ресурси, якими можуть бути КПВ, програми, генератори, DSL-описи, моделі аналізу, документація й ін. Проектування в ПрО одиночних програм у прикладній інженерії базується на програмуванні з повторним використанням, де конкретні програми містять у собі різні готові ресурси (assets), які можуть бути і КПВ. Розробка ПрО є більш складним виробничим процесом, який містить у собі загальні етапи: аналіз, проектування і впровадження.

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

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

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

Таким чином, інженерія ПрО охоплює:

– аналіз ПрО і виявлення об’єктів і відношень між ними;

– визначення області дій об’єктів ПрО;

– визначення загальних функціональних і змінюваних характеристик, побудова моделі характеристик;

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

– підбір і підготовка компонентів багаторазового застосування для задач ПрО;

– генерація окремих членів сімейства або домену в цілому.

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

Як готові ресурси в інженерії ПрО можуть використовуватися відомі горизонтальні і вертикальні типи компонентів загального призначення, що реалізовані зокрема в моделі CORBA [14]. Горизонтальні типи компонентів – це загальні системні засоби, що потрібні різним членам сімейства, а саме, графічні інтерфейси користувача, СКБД, бібліотеки розрахунку матриць, контейнери, каркаси і т.п.

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

Приклад системи підтримки інженерії ПрО і застосування горизонтальних методів – система DEMRAL [14, 17], призначена для розробки бібліотек: чисельного аналізу, графових обчислень і т.д. Основні види елементів цієї бібліотеки – абстрактні типи даних (abstract data types) і алгоритми. DEMRAL підтримує інженерію домену за допомогою бібліотек чисельного аналізу, обробки зображень тощо. Крім цього, ця система дозволяє моделювати характеристики ПрО і зображати їх у характеристичній моделі, а також в предметно-орієнтованих мовах опису членів ПС конфігурації.

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

 

5.1.7. Сервісно-орієнтоване програмування

Ця парадигма програмування з’явилася як наслідок розгляду програмних компонентів як готових сервісів, визначення для них інтерфейсів взаємодії в рамках нових архітектур ПЗ, зв’язаних із сервісами, у середовищі розподілених систем (CORBA, DCOM і EJB) і веб-сервісів у середовищі Інтернету. Такі архітектури отримали назву сервісно-орієнтованих архітектур – SOA (Service-Oriented Architecture) і зараз активно розвиваються разом із відповідними засобами їхньої підтримки й опису (XML, SOAP, WSDL і ін.) та механізмами взаємодії звичайних сервісів розподілених застосувань і веб-сервісів Інтернету [18].

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

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

Архітектура SOA має форму піраміди, що складається з кількох шарів [18].

1. Підґрунтям піраміди є базові сервіси і базові операції, а саме, публікація, виявлення, вибір і зв’язування, які націлені на створення і використання описів сервісів.

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

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

Переважна форма реалізації сервісів – це веб-сервіси, які зберігаються та ідентифікуються за URL-адресами і взаємодіють між собою за допомогою мережі Інтернетту шляхом віддалених викликів (Remote Procedure Call). Стрімке поширення Інтернету призвело до того, що традиційне єдине інтегроване підприємство минулих поколінь все частіше заміняється мережею бізнесів, які спільно виконують певні функції при тому, що і власність, і менеджмент розподілені між партнерами. Саме інформаційні потреби розподілених бізнесів викликали до життя веб-сервіси як адекватну форму компонентів типа КПВ.

Веб-сервіс має URL-адресу, інтерфейс і механізм взаємодії з іншим сервісом через протоколи Інтернету або зв’язки з іншими програмами, БД і діловими бізнес- операціями. Обмін даними між веб-сервісом і програмою здійснюється за допомогою XML-документів, оформлених у вигляді повідомлень. Веб-сервіси забезпечують розв’язання задачі інтеграції застосувань різної природи, будучи інструментом побудови розподілених систем. Веб-сервіс надається провайдером мережі Інтернету, який має стандартний спосіб взаємодії з розподіленими (.NET, J2EE, CORBA і ін.) і прикладними системами з отримання деякої послуги.

Основні засоби опису веб-сервісів:

– мова XML для опису і побудови SOA-архітектури;

– мова WSDL (Web Services Description Language) для опису веб-сервісів і їхніх інтерфейсів на XML, що стосується типів даних і повідомлень, а також моделей взаємодії і протоколів зв’язування сервісів між собою;

– SOAP (Simple Object Access Protocol) для визначення форматів запитів до веб-сервісів;

– UDDI (Universal Description, Discovery and Integration) для універсального опису, виявлення й інтеграції сервісів, забезпечення їхнього збереження, упорядкування ділової сервісної інформації в спеціальному реєстрі з покажчиками на конкретні інтерфейси веб-сервісів.

Сервісно-орієнтована архітектура – це сукупність взаємодіючих між собою сервісів і веб-сервісів і їхніх інтерфейсів. Будь-який з компонентів SOA створюється за допомогою сервісів безвідносно до конкретних технологій, за які можна брати готові застосування типу «чорна скринька». Інтеграція компонентів і сервісів в архітектуру SOA містить у собі наступні види:

користувальницьку інтеграцію (user integration) для взаємодії інформаційної системи з конкретним користувачем;

зв’язування застосувань (application connectivity) для забезпечення їхньої взаємодії;

інтеграцію процесів (process integration) для об’єднання бізнес-процесів;

інформаційну інтеграцію (information integration) для забезпечення доступу до інтегрованої інформації і даних.

При цьому до створюваної архітектури SOA висуваються наступні вимоги:

– наявність існуючих інформаційних систем і поява нових;

– поетапне впровадження нових і міграція існуючих інформаційних систем;

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

– використання різних моделей і систем (портали, grid-системи й ін.).

Якщо об’єктом сервісно-орієнтованої архітектури є веб-сервіс, то застосовується дві технології, що забезпечує функціональність (Functions) і якість сервісів (Quality of service). Ці технології винесені на рівень IT-стандартів комітету W3C і мають наступні рівні.

Технологія забезпечення функціональності веб-сервісів має:

– транспортний рівень (transport layer) для обміну даними;

– комунікаційний рівень (service communication layer) для визначення протоколів;

– рівень опису сервісу (service description layer) і зв’язаних з ним інтерфейсів;

– рівень бізнес-процесів (business process layer) для реалізації бізнес-процесів і потоків робіт через механізми веб-сервісів;

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

Технологія забезпечення якості веб-сервісів має наступні рівні:

– політики (policy layer) для опису правил і умов застосування веб-сервісів;

– безпеки (security layer) для опису питань безпеки веб-сервісів і функціонування (авторизація, аутентифікація і розподіл доступу);

– транзакцій (transaction layer) для встановлення параметрів звертання до веб- сервісів і забезпечення надійності їхнього функціонування;

– керування (management layer) веб-сервісами.

Технологічний фундамент веб-сервісів становлять: XML, SOAP, UDDI, WSDL. З їхньою допомогою здійснюється реалізація базових властивостей веб- сервісу і механізму взаємодії між собою веб-сервісів у середовищі SOA, що вміщують компоненти, наведені на рисунку 5.11.

 

Рис. 5.11. Компоненти веб-сервісів і взаємодія з різними системами

 

Як видно з рисунку до головних компонентів належать:

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

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

користувач сервісу (застосування, програмний модуль або сервіс), який здійснює пошук і виклик необхідного сервісу з реєстру сервісів за його описом, а також використовує сервіс, наданий провайдером відповідно до його інтерфейсу. Зв’язок між діючими системами, наведений на рисунку, здійснюється через ХМL-повідомлення мережного середовища, що використовують інтерфейси веб-сервісів. Посередником між загальносистемними службами розподілених систем і застосувань є провайдер, що звертається до них за сервісом, а інтегратор SOA, що створюються із сервісів і веб-сервісів, називається брокером.

Для отримання сервісу в архітектурі SOA виконуються наступні операції:

1. Публікація сервісу WSDL з метою забезпечення доступності (через виклик) користувачеві сервісу і його інтерфейсу;

2. Пошук за протоколом SOAP здійснює користувач сервісу в реєстрі сервісів за заданими критеріями;

3. Зв’язування UDDI через опис користувачем необхідного сервісу, який може надаватися в таких моделях як COM, CORBA, DBMS,.JNET тощо.

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

 

5.1.8. Агентне програмування

Поняття інтелектуального і програмного агента з’явилося понад 20 років тому, їхня роль у програмній інженерії увесь час зростає [19-23]. Так, Джекобсон [23] зазначив перспективу використання агентів як менеджерів проектів, розробників архітектури за діаграмами use case і ін.

Основний теоретичний базис даного програмування – темпоральна, модальна і мультимодельна логіки, дедуктивні методи доведення правильності властивостей агентів і ін.

З погляду програмної інженерії агент − це самодостатня програма, здатна керувати своїми діями в інформаційному середовищі функціонування для одержання результатів виконання поставленої задачі і зміни поточного стану середовища [19]. Агент має такі властивості:

– автономність – це здатність діяти без зовнішнього впливу;

– реактивність – це здатність реагувати на зміни даних, середовища і сприймати їх;

– активність – це здатність ставити мету і виконувати задані дії для досягнення цієї мети;

– здатність до взаємодії з іншими агентами (або людьми).

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

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

 

Рис. 5.12. Приклад взаємодії агентів у різних середовищах

 

Характер взаємодії між агентами залежить від сумісності цілей, компетентності і т.п. [21].

Основою агентного програмування є:

– формальна мова опису ментального стану агентів;

– мова специфікації інформаційних, часових, мотиваційних і функціональних дій агента в середовищі функціонування;

– засоби інтерпретації специфікацій агента;

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

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

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

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

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

– компетенцією – знаннями умов середовища функціонування і ступенем їхнього використання.

Головний засіб комунікації агентів – транспортний протокол ТСР/IP або протокол агентів ACL (Agent Communication Languages). Керування агентами (Agent Management) виконується за допомогою сервісів: передача повідомлень між агентами, доступ агента до сервера і т.п. Комунікація агентів – це взаємодія між різними агентами через подання загальних протоколів Інтернету, а також опис повідомлень мовою HTML і декларативними або процедурними (Java, Telescript, ACL і т.п.) мовами. Кооперація агентів – це спільне виконання деяких завдань користувачів.

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

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

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

 

Рис. 5.13. Схема обробки запитів агентами у середовищі Інтернету

 

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

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

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

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

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

Однією із систем побудови агентів, заснованою на обміні повідомленнями, є система JATLite, що за допомогою Java-класів створює нових агентів, які обчислюють визначені функції в розподіленому середовищі. Система Agent Builder – це система конструювання програмних агентів, які описуються мовою Java і можуть взаємодіяти між собою, мовою KQML (Knowledge Query and Manipulation Language) [19-23].

Побудовані агенти виконують функції: менеджера проекту й онтологій, візуалізації, налагодження й ін. Реалізацію механізмів взаємодій агентів забезпечує система JAFMAS, ряд інших мультиагентних систем [19].

 

5.2. Теоретичне програмування

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

Авторами української теоретичної школи програмування, створеної В.М. Глушковим, запропоновані нові парадигми, а саме:

– алгебраїчне та інсерційне програмування (А.А.Летичевський і ін.) [24-26];

– експлікативне та номінативне програмування (В.Н.Редько, М.С.Нікітченко), які використовують логічний і математичний апарат для абстрактного конструювання програм [27-29];

– алгебро-алгоритмічне програмування (Г.О. Цейтлін), що поєднує алгебраїчний апарат і теорію алгоритмів [30-31]. Розглянемо ці напрями детальніше.

 

5.2.1 Алгебраїчне та інсерційне програмування

Парадигма алгебраїчного програмування – АП [24, 25] ґрунтується на теорії переписування термів. У цій парадигмі терми представляють дані, а системи переписуючих правил, що подаються за допомогою системи рівностей, – алгоритми обчислень. Елементарний крок обчислення містить у собі включає зіставлення із зразком, перевірку умов і підстановку. Порядок вибору переписуючих правил і підтермів даного терму для зіставлення з лівими частинами рівності визначається стратегією переписування. По суті, стратегія визначає результат обчислень – терм з точністю до еквівалентності початковому терму. Власне стратегія переписування може бути описана в парадигмі більш низького рівня, наприклад, процедурній або функціональній, що зумовлює інтеграцію парадигм. На теперішній час ідея інтеграції парадигм (процедурної, функціональної, алгебраїчної і логічної) знайшла втілення в системі алгебраїчного програмування (APS) [25], в якій використовуються спеціалізовані структури даних – графові терми – для представлення даних і знань про предметні області.

Основою АП є математична модель, що вміщує такі поняття:

– агент як транзитивна система, наділена поведінкою;

– поведінка агентів задається мовою АL (Action Language) за допомогою операцій, констант, граничних умов і рекурсій;

– середовище, яке складається з множини агентів і функцій занурення в нього, що позначається env і має параметром стан середовища й агентні вирази;

– правила розгортання функціональних виразів у прості агентні вирази;

– транзитивна система, як композиція середовища й системи взаємодіючих агентів, занурених у це середовище.

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

Розширення поняття транзитивної системи – це множина заключних станів, що відповідають успішному завершенню функціонування системи і відсутності невизначених станів. Головний інваріант стану транзитивної системи – поведінка системи, що задається виразами алгебри поведінки F(A) на множині операцій алгебри дій – префікси a∙u, недетермінований вибір u + v з u і v поведінкою та властивостями асоціативності й комутативності. Скінченна поведінка системи задається константами , 0, які позначають відповідно: стан успішного завершення, невизначеного й тупикового. Алгебра поведінки містить у собі відношення ≤, елемент  як найменший, і операції поведінки, які монотонні. Усяка транзитивна система має історію функціонування, яка зберігає зокрема один з таких станів: успішне завершення обчислень у середовищі транзитивної системи; «тупиковий» стан, коли кожна з паралельно виконаних частин системи перебуває у стані очікування; та невизначений стан, що виникає при виконанні алгоритму з нескінченними циклами.

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

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

Термін «інерційне програмування» походить від англійського insert – вставляти, поміщати, занурювати. Програма в цій парадигмі розглядається як агент, наділений поведінкою, що, занурюючись в середовище, змінює його (середовища) поведінку і має зовнішнього спостерігача, а також інших агентів, що занурюються у це середовище надалі. Написати інсерційну програму – означає визначити функцію занурення (закон функціонування середовища із зануреними в нього агентами), а також початковий стан середовища і агента, зануреного в це середовище. Як базова система програмування для подання станів агентів і середовищ у вигляді структур даних, а також для програмування функції занурення використовується система алгебраїчного програмування АPS. Інерційна програма записується мовою AL за наступними рівнями [26]:

1) опис поведінки ініціалізованого багаторівневого середовища із зануреними в нього агентами;

2) задання функції, яка визначає відношення переходів агентів;

3) опис ядра функції занурення (функції розгортання занурень).

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

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

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

 

Рис. 5.14. Технологічна схема в АП

 

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

Множина всіх переходів, заключних і «тупикових» станів – перелічувана, навіть якщо функція розгортання має нескінченну множину нетривіальних ітерацій.

Станом транзитивної системи є обмежені вирази, обумовлені операцією вибору +, співвідношенням x + 0 = a і відношенням переходу з одного стану в інший за правилом u → U(u).

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

Більш докладна інформація про інсерційне програмування й засоби його автоматизації міститься в [25].

 

5.2.2. Експлікативне, номінативне програмування

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

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

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

Експлікативне програмування містить у собі теорію дескриптивних і декларативних програмних формалізмів для розробки моделей структур даних, функцій і засобів конструювання з них програм [27-29]. Для цих структур вирішені проблеми існування, зєднання і ефективності. Теоретичну основу ЕП становлять логіка, конструктивна математика, інформатика, композиційне програмування і класична теорії алгоритмів. Для зображення алгоритмів програм використовуються алгоритмічні мови і методи програмування: функціональне, логічне, структурне, денотаційне і ін.

Принципами експлікативного програмування є:

– розвиток поняття програми в абстрактному розумінні і поступова його конкретизація за допомогою експлікацій;

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

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

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

Процес розвитку програми здійснюється у вигляді ланцюжка понять: дані – функція –ім’я функції – композиція – дескрипція. Тріада «дані – функція – композиція» задає семантичний аспект програми, а «дані − ім’я функції – дескрипція» – синтаксичний аспект. В експлікативному програмуванні головними є семантичний аспект, система композицій і номінативність, що орієнтована на системний опис номінативних відношень при побудові даних, функцій, композицій і дескрипцій [28].

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

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

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

Клас номінативних даних забезпечує побудову іменованих даних, багатозначних номінативних даних або мультиіменованих даних, що задаються рекурсивно. У рамках даного програмування розроблені нові засоби для визначення систем даних, функцій і композицій номінативного типу, імена аргументів яких належать деякій множині імен Z. Композиція визначається на Z- номінативних наборах іменних функцій [29].

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

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

 

5.2.3. Алгоритмічні алгебри

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

Дослідження і побудова алгебри алгоритмів або алгоритмічної алгебри почалося з проектування логічних структур ЕОМ під керівництвом академіка В.М.Глушкова. Як результат була створена теорія систем алгоритмічних алгебр (САА), що потім Г.О.Цейтліним була покладена в основу узагальненої теорії структурованих схем алгоритмів і програм, названою ним алгоритмікою [30].

Алгоритміка програм призначена для побудови послідовних і паралельних програм зі структурних схем з використанням апарату формальних алгебраїчних перетворень і канонічних форм опису логічних і операторних виразів. Її основу становлять САА, розширені формалізмами для зображення логічних умов виконання паралельних програм, а також методами символьної мультиобробки [30, 31].

Основними поняттями алгебри алгоритмів є:

– операції над множинами, булеві операції, предикати, функції й оператори;

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

– операції сигнатури САА, аксіоми і правила визначення властивостей програм на основі стратегії згортання, розгортання і їх комбінацій;

– методи синтаксичного аналізу структурних програм і символьна обробка.

Об’єкти алгоритміки – моделі алгоритмів і програм, що подаються у вигляді схем. Алгоритміка базується на комп’ютерній алгебрі, логіці і використовується для формального опису алгоритмів в МП. Схема реалізації програм засобами алгоритміки наведено на рисунку 5.15.

 

Рис. 5.15. Схема проектування програм в алгебрі алгоритміки

 

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

Алгебра алгоритмів. Алгебра алгоритмів АА = {A, }, як і будь-яка алгебра, − це основа А і сигнатура  операцій з елементами цієї основи. За допомогою операції сигнатури можна додати довільний елемент q  AА. Це називається системою утворювальної алгебри.

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

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

В алгебрі алгоритмів використовується алгебра множин, тобто елементи множини й операції над ними (об’єднання, перетину, доповнення і ін.). Вводиться також поняття універсуму – множини операцій постановки і розв’язання деякої задачі [30].

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

Послідовне виконання операторів А і В записується у вигляді композиції А*У; альтернативне виконання операторів А и В (u(А,У)) означає, якщо u – істинне, то виконується А, інакше В; цикл (u(А,У)) виконується, поки не стане істинною умова u (u – логічна змінна).

За допомогою цих елементарних конструкцій будується більш складна схема П алгоритму:

 

П::= {[u1] А1},

А1::= {[u2] А2 * D},

А2::= А3 * C,

А3::= {[u] А, B},

u::= u2 ˄ u1.

 

Здійснивши суперпозицію шляхом згортання даної схеми алгоритму П, одержуємо таку схему:

 

П::= {[ u1]{ [u2] ([u2 ˄ u1] А, У) * З }* D}.

 

Важливим показником можливостей алгоритміки є проведений порівняльний аналіз алгебри алгоритміки з відомими алгебрами. Дамо короткі пояснення алгебри Дейкстри, Янова та ін.

Алгебра Дейкстри АД = {АСС, L(2), СИГН} – двохосновна алгебра, елементами якої є множина САА операторів, зображених структурними блок- схемами, множина L(2) булевих функцій у сигнатурі СИГН, в яку входять операції диз’юнкції, кон’юнкції і суперечності, що набувають значення з L(2). За допомогою спеціально розроблених механізмів перетворення АД на алгебру алгоритміки встановлено зв’язок між альтернативою і циклом за формулою {[u] А} = ([u] Е, А * {[u] А}), що входить у СИГН. В АД використовуються похідні операції, які можуть бути отримані в наслідок суперпозиції основних операцій і констант.

Операція фільтрації Ф(u) = {[u] Е, N} у АД зображена суперпозицією тотожного Е для невизначених N операторів і альтернативи в алгебрі алгоритміки, де N – фільтр дозволу виконання операцій обчислень.

Оператор циклу while do також представлений суперпозицією операцій композиції і циклу в алгебрі алгоритміки.

Алгебра схем Янова АЯ = <{AHC, L(2)}; CИГН>, де АНС – сукупність неструктурних схем, L(2) – сукупність різних булевих функцій, СИГН – сигнатура з композиції А*В і операція неструктурного переходу П(uF), а також операції диз’юнкції, кон’юнкції і суперечності. АЯ містить у собі операції побудови неструктурних логічних схем програм.

Схема Янова складається з предикатних символів множини P(p1, p2,…,), операторних символів множини A{a1, a2,…} і графа переходів. Оператор у даній алгебрі – це пари A{p}, що складається із символів множини А и предикатних символів p. Граф переходу – це орієнтований граф, у вершинах якого розміщуються перетворювачі, розпізнавачі й один оператор зупинки. Дуги графа задаються стрілками і позначаються знаками + і –. Дуги, що виходять з розпізнавача, розрізняються і називаються відповідно плюс-стрілка і мінус–стрілка. Перетворювач має одного нащадка, розпізнавач – двох. Одна вершина в графі переходу зветься вхідною і помічається вхідною стрілкою. Також є вершина зупинення, яка не має нащадків. Кожен розпізнавач містить у собі умови виконання схеми. Перетворювач обробляє оператори, що вміщають логічні змінні, що належать множині (p1, p2,…) [31].

Кожна схема АЯ відзначається великою складністю, вимагає серйозного перетворення при переході до задання програми послідовністю дій, умов переходу і безумовного переходу. У праці [30] розроблена теорія інтерпретації схем Янова і доведено еквівалентність цих схем і операторних схем алгебри алгоритміки.

Для зображення схеми Янова апаратом алгебри алгоритміки сигнатура операцій АЯ вводяться композиції А*В і операція умовного переходу, що залежно від умови u виконує перехід до наступних операторів або до оператора, позначеного міткою (типу goto). Умовний перехід трактується як бінарна операція П(uF), що залежить від умови u і розміток схеми F. Крім того, виконується заміна альтернативи і циклу типу while do. Внаслідок виконання бінарних операцій отримується нова схема F’, у якій встановлені бінарні операції П(u) замість мітки і булевих операцій кон’юнкції і суперечності. Еквівалентність операцій перетворення доводить правильність переходу до неструктурного подання програм.

Система алгебр Глушкова АГ = {ОП, УМ, СИГН}, де ОП – множина операторів, що входять у сигнатуру СИГН, і УМ – множина логічних умов, визначених на інформаційній множині ІМ.

Сигнатура СИГН = {СИГНад  Прогн.}, де СИГНад – сигнатура операцій Дейкстри, Прогн. – операція прогнозування. Сигнатура САА містить у собі операції алгебри АД, узагальнену тризначну булеву операцію і операцію прогнозування (ліве множення умови на оператор u = (А* u’) з породженням предиката u = УС такого, що u(m) = u’(м’), м’ = А(m), А  ОП). ИМ – множина оброблюваних даних за операціями з множин ОП і УС. Сутність операції прогнозування полягає в перевірці умови u у стані m оператора А і визначення умови u’, обчисленої в стані м’ після виконання оператора А. Дана алгебра орієнтована на аналітичну форму подання алгоритмів і оптимізацію алгоритмів за вибраними критеріями.

Алгебра алгоритміки і прикладні підалгебри. Алгебру алгоритміки розширено Г.О. Цейтліним дворівневою алгебраїчною системою і механізмами абстрактного опису даних (класами алгоритмів). Під багатоосновною алгоритмічною системою (БАС) розуміють систему S ={{Di | i  I}; СИГН0, СИГНn}, де Di – основи або сорти, СИГН0, СИГНn – сукупності операцій і предикатів, визначених на Di. Якщо вони порожні, то визначаються багатоосновні моделі – алгебри. Якщо сорти інтерпретуються як множина оброблюваних даних, то БАС є концепцію АТД у вигляді підалгебри, що широко використовується в об’єктному програмуванні. Тим самим установлено зв’язок із сучасними тенденціями розвитку програмування.

Таким чином, можна зробити висновок, що проведене зіставлення механізмів алгебри Дейкстри, алгебри схем Янова та логічних операторів Глушкова проведено засобами алгоритміки Цейтліна. Це вказує на їх однакову алгоритмічну потужність при різних засобах подання алгоритмів програм. Практичним результатом досліджень алгебри алгоритміки є побудова оригінальних інструментальних систем проектування програм на основі сучасних засобів підтримки ООП (Rational Rose). Докладніше дана тема розглядається в [32].

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