
- •Перелік термінів та позначень
- •Передмова
- •Частина 1. Початок програмування в срср. Витоки розвитку
- •1.1. Поява і розвиток технології програмування (1952–2012)
- •1.2. Формування технологічних напрямів (1965–1975)
- •1.3. Становленья технології програмування (1975–1982)
- •1.4. Розвиток інтерфейсу в технології програмування (1976–1992)
- •1.5. Розвиток об’єктної технології програмування (1992–2002)
- •1.6. Індустріальні основи технології програмування (2002–2012)
- •1.7. Навчання тп у кну Тараса Шевченко (1965–2012) та філії мфті (2000–2012)
- •Контрольні питання і завдання до частини 1
- •Список літератури до частини 1
- •Частина 2. Парадигми технології програмування
- •2.1. Модульне програмування та збиральний підхід
- •2.1.1. Інтерфейс в програмуванні
- •2.1.2. Зборка модулів по а.П.Єршову
- •2.1.3. Метод зборки готових програмних елементів
- •2.1.4. Формальне подання методу збирання різномовних модулів
- •2.2. Парадигма об’єктно-орієнтованого програмування
- •2.2.1. Базові концепції ооп
- •2.2.2. Чотирьох рівневе проектування ом
- •2.2.3. Концепції об’єктного аналізу
- •2.2.4. Функції, алгебра та операції об’єктного аналізу
- •2.2.5. Моделювання моделі ПрО
- •2.2.6. Опис параметрів інтерфейсу ом
- •2.3. Парадигма uml-метода моделювання
- •2.3.1 Основні діаграми методу
- •2.3.2. Моделювання поведінки системи
- •2.3.3. Побудова пс засобами uml
- •2.4. Парадигма компонентного програмування
- •2.4.1. Теоретичні аспекти компонентного програмування
- •2.4.2. Моделі компонентного програмування
- •2.4.3. Графове подання компонентної моделі ПрО
- •2.4.4. Об’єднання компонентів. Модель середовища
- •2.4.5. Компонентна алгебра
- •2.4.6. Іінструментальні засоби кп
- •2.4.7. Технологія компонентної розробки пс
- •2.4.8. Типізація і класифікація програмних компонентів
- •2.4.9. Жц проектування пс із типових компонентів та кпв
- •Розробка вимог до пс – це формування та опис функціональних, технологічних, організаційних та ін. Властивостей програмної системи, які необхідні чи бажані з точки зору кінцевого користувача.
- •Розгортання рпс. У випадку, коли рпс створюється для конкретного замовника, який є і користувачем, то деякі завдання розгортання виконуються на попередніх етапах. До них, зокрема, відносяться:
- •Супровід рпс компонентній пс характеризується наступними особливостями.
- •2.5. Парадигма аспектно-орієнтованого програмування
- •2.5.1.Основні елементи парадигми аоп
- •2.5.2. Засоби аоп
- •2.5.3. Підтримка аоп впродовж життєвого циклу пс
- •2.5.5. Методичні аспекти аоп
- •2.6. Парадигма генерувального програмування
- •2.6.1 Предметно-орієнтована мова – dsl
- •2.6.2. Простір проблем і рішень ПрО
- •2.6.3. Інженерія ПрО і кпв
- •2.7. Сервісно-орієнтоване програмування
- •2.7.1 Базові понятті сервісу Інтернет
- •2.7.2. Сервіси wcf мs.Net з контрактами
- •2.8. Парадигми теоретичного програмування
- •2.8.1 Алгебраїчне та інсерційне програмування
- •2.8.2. Реалізація агентних програм
- •2.8.3. Експлікативне, номінативне програмування
- •2.8.4. Алгоритмічні алгебри
- •Контрольні питання і завдання до частини 2
- •Список літератури до частини 2
- •Частина 3. Моделі і засоби проектування предметних областей
- •3.1. Моделі проектування ПрО предметних областей
- •3.1.1. Концептуальні моделі пс, спс за компонентами
- •3.1.2. Моделі взаємозв’язку об’єктів
- •3.1.3. Модель інтеграції (зборка) компонентів
- •3.1.4. Тестування прикладних і інтерфейсних об'єктів
- •3.1.5. Моделі взаємодії і варіабельності пс для організації обчислень
- •3.1.6. Підхід до виконання пс в сучасних розподілених середовищах
- •3.2. Онтологічний підхід до подання знань про проблемні області
- •3.2.1. Онтологічне моделювання проблемної області
- •3.2.2. Мовний опис онтології домену чи спс
- •3.2.3. Підхід до реалізація онтології ПрО
- •3.3. Типи даних та засоби їх генерації для використання в збиральному прогрмуванні
- •3.3.1. Проблема забезпечення сумісності типів даних при зборки кпв
- •3.3.2. Аксіоматика простих типів даних
- •3.3.3. Аксіоматика структурних і складних типів даних. Структурні типи даних.
- •3.3.4. Семантичні аспекти взаємодії різнорідних програм
- •3.3.5. Характеристика типів даних для зборки програм
- •3.3.6. Фундаментальні і загальні типи даних
- •3.3.6. Баові поняття стандарту з типів даних
- •3.3.7. Перебудова загальних типів даних до фундаментальних для мп
- •3.4. Підходи і методи доказу програм
- •3.4.1. Мови специфікації програм –vdm, raise, Concept
- •3.4.2. Концепторна мова специфікації
- •3.4.3. Методи доведення правильності програм
- •3.4.4. Модель доказу програми за твердженнями
- •З.5. Проектування пс засобами жц з реалізації доменів
- •3.4.1. За загальна характеристика стандарту жц iso/iec 12207:2002
- •3.4.2. Формування конкретних моделей життєвого циклу
- •3.4.3. Підходи до моделювання ПрО мовними засобами dsl
- •3.6. Модель якості пс
- •3.6.1. Структура моделі якості
- •3.6.2. Модель витрат сосомо Боєма
- •3.6.3. Інтегрована модель витрат на спс
- •Контрольні питання і завдання до частини 3
- •Список літератури до частини 3
- •Частина 4. Методи індустрії виробицтва програм і систем
- •4.1. Загальні основи методології виробництва пс і спс
- •4.1.1. Моделі взаємодії компонентів у пс
- •4.1.2 Методологічні аспекти виробництва спс з готових ресурсів
- •4.2. Мова опису моделей взаємодії на основі xml
- •4.2.1 Подання та обмін даними в компонентних моделях
- •4.2.3 Модель конфігурації компонентів на основі xml
- •4.3. Графове подання пс і спс
- •4.3.1 Графове визначення моделі взаємодії об'єктів
- •4.3.2 Типи зв’язків об’єктів у графової моделі ПрО
- •4.4. Розробка методів побудови проблемно-орієнтованих технологій
- •4.4.1. Аналіз динаміки розвитку фабрик програм
- •4.3.2. Базисні ресурси фабрики програм
- •4.5. Загальні лінії виробництва програм з кпв
- •4.4.1. М етодологія побудови тл
- •4.4.2. Нові дисципліни індустрії наукового совтвера
- •4.4.3. Новітні засоби Grid і Cloud для обчислення задач e–sciences
- •4.4.4. Сучасні системи побудови рпс з сервісних ресурсів
- •4.4.5. Методологія розроблення тл
- •4.4.6. Принципи проектування іс
- •4.5. Методи при оцінюванні економічних характеристик проектів
- •4.5.2. Формальний апарат експертно-аналітичного оцінювання об’єктів і процесів у спс
- •4.5.3. Методи оцінки розміру
- •4.6. Створення Windows застосувань
- •4.6.1. Створення нової програми.
- •4.6.2. Властивості і дизайн програм
- •4.6.3. Компіляція програм
- •2.5. Запуск застосунка
- •4.6.4. Розширення функціональності програм
- •4.7. Інженерії тестування програмних систем
- •4.7.1. Основні поняття інженерії тестування
- •4.7.2 Становлення інженерії тестування
- •4.7.3. Методи тестування. Метрики і критерії
- •4.7.4. Інструменти тестування та оцінювання
- •4.7.5. Тестування веб-застосувань
- •Контрольні питання і завдання до частини 4
- •Список літератури до частини 4
- •5.2. Фабрика програм в кну
- •5.2.3. Створення фабрики студентів
- •5.2.4. Лінії продуктів фабрики на головної сторінки
- •5.2.5. Принципи роботи з репозиторієм програм і артефактів
- •5.2.6. Навчання дисципліні “Програмна інженерія” на фабрики
- •5.3. Репозиторій кпв
- •5.3.1. Загальний опис репозиторію
- •5.3.2. Технологія обслуговування репозиторію кпв
- •5.4. Розробка кпв
- •5.4.1. Опис моделей кпв, інтерфейсу і операцій розробки кпв
- •5.4.2. Реалізація побудови компонентної системи
- •5.4.3. Процеси технології оброблення кпв
- •5.4.4. Зборка різномовних програм у середовищі Visual Studio
- •5.5. Конфігурація кпв
- •5.5.1. Конфігурування кпв з урахуванням варіабельності
- •5.5.2. Опис прикладу використання конфігуратору програм
- •5.6. Генерація систем мовою dsl
- •5.6.1. Лінія опису та генерації доменів dsl
- •5.6.2. Опис життєвого циклу пз та його реалізації на мові dsl
- •2.7. Онтологія – обчислювальна геометрія
- •5.7.1. Онтологія домену – Обчислювальна геометрія
- •5.7.3. Опис моделі онтології ПрО «Обчислювальна геометрія»
- •5.7.4. Опис програми домену «Обчислювальна геометрія» мовою owl
- •5.8. Оцінка якості пс
- •5.8.2. Оцінка витрат на продукт
- •5.8.3. Опис модуля прогнозування трудовитрат на розробку пс
- •5.8.4. Приклад оцінювання затрат на розробку пс ас
- •5.9.1. Опис веб-технології Java ee
- •5.9.3. Приклад взаємодії Java і ms.Net через веб-сервіси
- •5.9.4. Інструкція по використанню графічного інтерфейсу прикладу
- •5.10. Генерація тд
- •5.10.1. Відображення типів даних у середовищі ітк
- •5.10.2. Система генерації загальних типів даних до фундаментальних
- •5.11. Інструментальні засоби сайта ітк
- •5. 12. Розділ сайта «Технологія навчання»
- •Контрольні питання і завдання до частини 5
- •Список літератури до частини 5
- •Післямова
- •Додаток 1. Парадигма структурного програмування
- •Додаток 2. Приклад створення служб wcf у ms Visual Studio 2010
- •Додаток 3. Онтологічний підхід з подання тестування кпв та пс
- •Додаток 4. Оцінка застосування метода сосомо на конкретних даних
- •Додаток 5. Програма курсу «Технологія програмування іс»
3.1.1. Концептуальні моделі пс, спс за компонентами
Компонентні системи різного призначення будуються з використанням деяких формальних моделей: графових, онтологічних, семантичних, об’єктно-орієнтованих, системних моделей – GDM, SOA, MDD, MDM, моделей і метамоделей даних і др. В роботі розглядається низка формальних моделей, які пропонуються для подання різних предметних областей, ПС і СПС. Ці моделі сформувались і вдосконалювалися в межах фундаментальних проектів щодо об’єктного і компонентного програмування в ІПС НАНУ (2000–2012) [4, 5]. Моделі ПС і зокрема СПС з компонентів і КПВ програмно реалізовані в інструментально-технологічному комплексі (ІТК) [6] і на фабрики програм КНУ ім.. Тараса Шевченко [7].
Модель предметної області (ПрО)
ПрО – це сукупність точних визначень понять, концептів об’єктів реального простору предметної області з їхніми характеристиками, а також множина синонімів і класифікаційних логічних взаємозв’язків між цими поняттями. Об’єкти як абстракції реального світу і поняттєва структура відображають функції об’єктів і відношення між ними. Виділені в ПрО об’єкти структурно впорядковуються за допомогою теоретико множинних операцій (селекції, композиції, перетину тощо) та об’єднуються за загальними ознаками у класи й суперкласи. Модель ПрО подамо у вигляді
MПрО = {Mo, Мсх, МПС, P, D},
де Mo – множина об’єктів і відношень між ними та свідомістей о змісті функцій і даних об’єктів, с якими вони функціонують.
Мсх – множина загальних характеристик пов’язаних об’єктів через загальні дані та характеристик внутрішнього типа, що притаманні кожному об’єкту і входять до схеми обчислень композицій об’єктів задач ПрО;
МПС – модель програмної системи чи МСПС, які реалізують завдання та функції предметної області ПрО,
Р – множина предикатів з порядку і умов виконання об’єктів за їх функціональними і не функціональними характеристиками моделі властивостей об’єктів Mo, методи яких забезпечують їх програмну реалізацію в ПС,
D – множина даних предметної області, які необхідні для виконання ПС і які можуть зберігатися у базах даних.
Модель програмної системи – МПС
Програмна система – сукупність окремих компонентів для реалізації взаємопов’язаних функцій деякої ПрО у заданому середовищі. Програмний компонент – це самостійний продукт, що підтримує об'єктну парадигму, реалізує частину або усю окрему предметну область і уміє взаємодіяти з іншими компонентами системи через інтерфейси.
Модель програмної системи – ПС дамо у такому визначенні:
МПС = {L, Mf, Ms, Mi, Md},
де L = {L1, L2, …, Lk) – мовні засоби опису функцій чи задач предметної області, одна з мов включає набір операцій (actions) алгебри, щодо дій з реалізації і виконання відповідних програмних компонентів;
Mf – множина функцій моделі ПрО, яка є по сутності моделлю об’єктів ПрО, тобто Mf = {O1, O2,…, Or} цієї ПрО, кожний об’єкт якої трансформується до компонентного коду цієї функції відповідної ПС ПрО;
Ms = {Msin, Msout, …,Msinou} – множина сервісів , що включає моделі передачі вхідних даних Msin, вихідних даних Msout та серверних даних Msinout ПС на сервері Application, базованих на системних сервісах (Common Facility Services) операційного середовища з механізмами компонентів – брокера, монітора, сервісного контракту IContract WСF тощо;
Mi – множина інтерфейсів в мові IDL з описом вхідних (in) і вихідних параметрів (out) та (inout) КПВ об’єднаного типу для пари зв’язних компонентів в структурі ПС. З практичної точки зору усі загальні типи даних специфікуються як зовнішні дані в паспорті моделі ПрО;
Md – множина даних та метаданих предметної області ПС, які специфіковані в КПВ, як примітивні чи складні фундаментальні типи даних, що є в кожної мові програмування. ПС в МП, а також в модулі посереднику (stub, skeleton) в мові IDL.
Множини Ms та Mi мають перетин по даним in, out, inout, які входять до складу зовнішніх типів даних, які передаються по мережі від одного компонентного об’єкту до іншого, що розташованій на сервері Application, після їх обчислень результати повертаються компоненту, що звернувся з запитом чи протоколом..
Модель сімейства програм (СПС)
Сімейство програмних систем (СПС) – це сукупність ПС, які визначаються спільною множиною понять та множиною спеціальних понять і характеристик, що притаманні кожному члену цього сімейства з реалізації деякої ПрО.
Поняття сімейства програм ввів Дейкстра (1970) і основується на тому, що програми мають спільну родинну мету, з якої можуть породжуватися різні варіанти інших програм, що потребують необхідні коректування чи заміни некоректних або недостатньо визначених функцій у зв’язку з уточненням загальної постановки задач сімейства у цілому.
Модель СПС задамо у вигляді:
МСПС = {{МПС1, МПС2, …, МПСk }, {Mgf, Msf ={Msf1, Msf2, …, Msfk}, Mi, Мd},
де МПС1, МПС2 , …, МПСk – множина членів сімейства ПС;
Mgf – множина зовнішніх характеристик предметної області чи властивості загального типу, що визначають загальну термінологію та властивості усіх ПС сімейства;
Msf ={Msf1, Msf2, …, Msfr} – множина внутрішніх характеристик кожного окремого члена cімейства, поданого моделлю ПС (МПСi ) тобто Msf1 для МПС1 ,…, Msfr для МПСk;
Mi – множина загальних інтерфейсів СПС, що подаються мовою IDL;
Мd = {Мd1, Мd2, …, Мdk} – множина даних відповідно для кожного члена ПС.
Монітор чи брокер запитів керує функціями ПрО, відправляє за протоколами типа RPC, RMI, Icontract дані, що специфіковані у інтерфейсному посереднику (stub, skeleton) у IDL чи API моделі клієнт-сервер.
Компонентна модель ПС – CМ
Під компонентним програмуванням розуміється метод створення ПС, заснований на застосуванні концепцій композиції (збирання) на всіх етапах ЖЦ, де базовим елементом композиції є компонент. Компоненти поділені на такі групи:
– прості компоненти, що реалізують деяку функцію ПрО;
– готові компоненти (наприклад, beans–компоненти у мові Lava);
– складні компоненти (каркас, патерни тощо) для групування компонентів;
– інтерфейс з описом параметрів для встановлення зв’язку між різними компонентами між собою;
– сервіси, що підтримують різні системні дії з організації передачі параметрів і даних, представлених в інтерфейсі чи контракті;
– засоби розгортання компонентів в деякому гетерогенному середовищі.
Тобто компонентне програмування є самостійним стилем програмування зі своєю концептуальною базою, теорією, методологією та інструментальними засобами. Він доповнює і розширює існуючі методи програмування засобами збирання готових КПВ, що значно спрощує процеси розробки і супроводу систем за рахунок:
– формалізації та впорядкованості процесу розробки окремих компонентів та систем з КПВ зі зменшенням часу розробки і збільшення якості та надійності складних систем;
– механізмів опису інтерфейсів компонентів для їх виконання у інтегрованому середовищі з використанням загальносистемних сервісів та ін.;
– спрощення процесів побудови ПС за моделлю з компонентів та методів їх конфігурування чи збирання у різні складні структури для їх виконання.
Компонентна модель ПС – це таке абстрактне уявлення ПС, що конструюється з компонентів, які є елементами уявлень і їм зіставлені реальні функції чи методи об’єктів ПрО, що забезпечують реалізацію функціональності та виконання інших не функціональних вимог щодо ПрО. Для однієї і тієї ж ПС може існувати безліч її компонентних моделей в залежності від концепцій проектування і використовуваного компонентного підходу. Моделі компонентної моделі (Component Model – СМ) відповідає цілком і повністю структура моделей МПС чи МПС з тою різницією, що тут використовуються програмні компоненти і КПВ, якяк готові ресурси різного призначення. Вони стали капіталоємкими продуктами і є об’єктами комерційного програмування, (наприклад, компоненти загальної бібліотеки математичних задач MatLab), що застосовуються при глобальних обчисленнях у середовищах Grid i Cloud Computing.
На загальному рівні подання моделі СМ ставиться завдання щодо представлення її функціональності згідно вимог у вигляді сукупності компонентів і їх інтерфейсів або контрактів для забезпечення взаємодії між собою окремих програмних компонентів, з яких модель складатиметься.
N
Нехай Ai – множина інтерфейсів за контрактами компонентів чи програм, що
i=1
визначають її визначають її функціональність. Кожному Ai який описує контракт як клієнт-серверну взаємодію з відповідними методами і структурами даних. Кожний інтерфейс має опис інтерфейсних даних –In, Out і Inout, які будемо називати відповідно визначальним поданням інтерфейсу (поняття – вхідний, вихідний та проміжний інтерфейс). Ini визначає умови і мету контракту з боку клієнта, Outi задає реалізацію компоненту з боку сервера, а Inout – властивості інтерфейсів Ini і Outi
Визначені інтерфейсів Ai для компонентів моделі СМ можуть групуватися у різні поєднання з урахуванням семантики характеристик загального і внутрішнього типів, що визначені для моделі системи і компонентів і входять до складу компонентної моделі.
Довільна сукупність інтерфейсів Ini, Outj, Inoutij, де i J, може не входять в кожну таку сукупність і одночасно визначати пари програмних компонентів приїх збиранні в складну структуру.
Для кожної отриманої сукупності пар Ci Iv = {Ci, Iv, OutJ, Inoutij} створюється модель компонента або шаблон, який містить деяку множину параметрів, які визначають і реалізують уявлення інтерфейсів. За цими уявленнями надалі здійснюється зіставлення шаблонів і інтерфейсів реальних компонентів.
В результаті операцій групування виходить множина пар Ci Iv { яке і буде зватися контрактом компонентної моделі ПС. Для однієї і тієї ж програми існує множина таких моделей, які визначаються множинами контрактів (або інтерфейсів) зі способами розбиття на шаблони компонентів для послідовного їх виконання.
Загальне визначення алгебри компонентів
Нехай Х – множина об'єктів x, де xi X – довільний об'єкт деякої ПрО, якій завдає функцію ПрО і пов'язаний з іншими об’єктами відношенням зв’язку. Цієї множині відповідає множина програмних компонентів C (C X.). Кожен компонент реалізує функцію і характеризується деякими притаманними йому властивостями (наприклад, варіантність, змінюваність тощо), які завдаються в їх інтерфейсах.
Властивості чи характеристики компонентів завдаються загальними і особистими типами та їх предикатами P1, , P2, , ..., Pk з умовами виконання компонентів з множини xi. X можливі деякі операції, результати виконання яких також є елементи множини X. Тривіальними прикладами таких операцій можуть бути – об'єднання кількох об'єктів в один або декомпозиція деякого програмного компоненту на окремі частини
Нехай R i – множина операцій над об'єктами з X. Кожна операція має власну арність в залежності від її семантики. В цілому існують операції, які задаються на подмножествах з X, а також можна створювати підмножину операцій (наприклад, попередні операції об'єднання та декомпозиції).
Серед множини операцій розглядаються ті, які зберігають властивості компонентів і їх результатів. Ці операції R1, R2 ,..., Rm виконуються над будь-якими компонентами c1 , , c2 ,..., сm C з урахуванням арності операції Ri та результату таких двох видів:
c1 , , c2 ,..., сm C).
Множина C та операції R1, R2.,.., Rm визначатимуть алгебру компонентів. Прикладами реальних операцій над компонентами можуть бути операції розширення інтерфейсів і факторингу для сукупності нових компонентів за іншими інтерфейсами, але з такою ж функціональністю. В розділі 2.4 подано компонентні алгебри (внутрішня і зовнішня). Для кожної алгебри відповідає властивостям компонентів Pі та операцій Rі, формально визначених для множини компонентів і які застосовуються в конкретної теорії компонентного програмування щодо конструювання програм і систем з готових КПВ.
Визначення загальної множини компонентів
Множина компонентів C, розглянуте вище, є математичною абстракцією. У реальному випадку мається на увазі деяка множина реальних компонентів з сі C. Застосувавши до цієї множини операції R1, R2.,.., Rm, можна отримати множину, яку будемо називати замиканням множини С’. Цей термін обраний для того, щоб підкреслити, що С’ є максимально можливою множиною компонентів, які можна отримати на основі вибраних компонентів з множини C, відповідно до сі C. У реальних процесах конструювання програм розглядається множина компонентів C (або C’), але при цьому враховується, що для нього справедливі всі положення відповідної компонентної алгебри при конкретної побудови компонентних. ПС, виконаної практично в ІТК [ ].