
- •Перелік термінів та позначень
- •Передмова
- •Частина 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. Програма курсу «Технологія програмування іс»
2.4.3. Графове подання компонентної моделі ПрО
Результатом моделювання компонентної моделі є граф G ={C, R}, визначений на множині компонентів С та зв'язків R (relations) за такими вимогами (рис. 2.3):
– множина вершин С подає взаємо однозначність відображення множини компонентів ПрО;
– для кожної вершини повинен існувати хоча б один зв'язок, що належить множині відношень-зв'язків R;
– існує хоча б одна вершина, що має статус множина–компонент і відображає ПрО в цілому.
Зв'язки можуть бути один до одного, один до багатьох, багато до багатьох
Побудований граф G ={С, R} може доповнюватися інтерфейсними компонентами, потім структурно упорядковуватися (нагору) з проведенням контролю повноти і надмірності елементів графа з метою усунення дублюючих елементів.
В графі Gі множина компонентів ПрО, що відрізняються друг від друга по статусу (елемент, множина або множина елементів) і взаємному порядку утворять компонентну модель (СМ). Тобто компоненти СМ подаються загальними й індивідуальними властивостями, а також зовнішніми і внутрішніми характеристиками.
В компонентної моделі ПрО присутні функціональні та інтерфейсні компоненти. Перевірка властивостей компонентів проводиться шляхом попарного порівняння властивостей внутрішніх характеристик компонента з множиною властивостей зовнішніх характеристик компонента за допомогою операцій екземпляризації, класифікації, спеціалізації, агрегації та ін. Властивості рахуються перевіреними, якщо виконується умова, що кожній внутрішній властивості множини компонента відповідає еквівалентна йому зовнішня властивість компонента-елемента. Якщо ця умова не виконується, то такий елемент віддалиться зі списку елементів множини і з графа відповідно.
На змістовному рівні множина С – це набір методів реалізації віддалених компонентів ПрО і для кожного з них існує інтерфейсний елемент множини I (типу stub, skeleton). Метод реалізації компоненту відповідає вершині графу, перехід до якої потребує перетворення даних, що ініціюються повідомленнями. Елементи графу розташовують реалізації компонентів по різним вузлам з множини компонентів, а їх інтерфейсні компоненти можуть бути локальними чи біля реалізації компоненту.
Компонентний граф відображається у еквівалентну модель ПС, елементи якої мають встановлені при моделюванні властивості і характеристики, які необхідні при завданні функцій інтерфейсу [2].
2.4.4. Об’єднання компонентів. Модель середовища
Для визначення семантики об’єднання компонентів за графом G, використовуються мова IDL для опису параметрів типу In, Out і Inout операцій приналежності:
– множина
вхідних (In) інтерфейсних компонентів;
– множина
вихідних (Out) інтерфейсних компонентів.
Результатом об’єднання двох компонентів буде компонент, у якого множина вхідних інтерфейсів співпадає з множиною вхідних інтерфейсів компонента-приймальника, а множина вихідних інтерфейсів – з множиною вихідних інтерфейсів компонента-передавача:
,
,
.
Аксіома.
Композиція
компонентів
є коректною, якщо компонент-передавач
Ck
повністю
забезпечує сервіс, необхідний
компоненту-приймальнику Ci,
тобто
.
Компонентні ПС можуть мати декілька
інтерфейсів і успадковувати інтерфейси
інших компонентів (
),
тоді останні надають сервіс всієї
множини вихідних інтерфейсів:
.
У випадку, коли компонент успадковує інший компонент, у якого множина вихідних інтерфейсів містить всі його інтерфейси, а множина вхідних інтерфейсів містить тільки інтерфейси, необхідні для надання сервісу, то маємо
Успадкований компонент делегує усі інтерфейси і має властивості:
транзитивності
;
симетричності
.
Ці властивості компонентів ідентичні компонентам моделі ПС. Для їх розміщення у деякому середовищі необхідно виконати такі дії:
– визначити критерії й умови розташування компонентів у вузлах середовища з урахуванням зв'язків між ними відповідно компонентного графу;
– визначити засоби передачі повідомлень від одного компонента до іншого;
– об'єднати програмні компоненти і їхні інтерфейси у структуру ПС з КПВ .
Таким чином, виходячи з запропонованої моделі СМ, моделі взаємодії [17] та семантики її виконання, компоненти цієї моделі ПС, можуть бути розподілені по вузлах мережі і взаємодіяти між собою через механізми інтерфейсів і повідомлень.
Модель компонентного середовища. Ця модель має наступний вигляд:
CE = (CNa, InRep, ImRep, CSe, CSeIm), (7)
де CNa = {CNam} – множина імен компонентів, які входять до складу середовища, InRep = {InRepi} – репозитарій інтерфейсів компонентів середовища, ImRep = {ImRepj} – репозитарій реалізацій, CSe = {CSer} – інтерфейс системних сервісів, CSeIm = {CSeImr} – множина реалізацій для системних сервісів.
Кожен елемент з InRep описується двійкою (CIni, CNam), де CIni – інтерфейс компонента, який описується виразом (4), а CNam – ім’я компонента, що реалізує інтерфейс. Аналогічно кожен елемент з ImRep описується (CImj, CNam), де CImj – реалізація, яка описується виразом (5), а CNam – ім’я компонента, до якого належить ця реалізація.
Компонентне середовище розглядається як множина серверів застосувань, де розгортаються компоненти-контейнери, екземпляри яких забезпечують реалізацію функціональності компонента. Взаємозв’язок контейнера з сервером забезпечується через стандартизовані інтерфейси (CFa). Зв’язок між компонентами, які розгорнуті у різних серверах забезпечується реалізаціями інтерфейсу.
Означення 1. Каркасом компонентного середовища називається середовище, для якого CNa, InRep, ImRep – суть порожні множини, тобто
FW = (Æ, Æ, Æ, CSe, CSeIm). (7)
Нехай FW1= (Æ, Æ, Æ, CSe1, CSeIm1) і FW2 = (Æ, Æ, Æ, CSe2, CSeIm2) – два каркаси.
Означення 2. Каркас FW1 сумісний з каркасом FW2, якщо існує відображення SMap: CSe1 –> CSe2 таке, що SMap(CSe1) Í CSe2.
Компонентна алгебра включає зовнішню алгебру на верхньому рівні моделі щодо ПС і внутрішню алгебру щодо внутрішній структури КПВ.
å = {Y Çj } = {CSet, CESet, W1} Ç {CSet, CESet, W2}, (8)
де Y – зовнішня алгебра, j – внутрішня алгебра.
Зовнішня компонентна алгебра визначає множину операцій над множинами компонентів компонентних середовищ і описується наступним виразом
= { CSet, CESet, W1},
де CSet – множина компонентів C, , кожен з яких описується виразом (3),
CESet – множина компонентних середовищ, кожне з яких описується виразом (7),
W1= {CE1, CE2, CE3, CE4} – операції зовнішній алгебри, а саме такі:
CE1 – операція оброблення компонентів,
CE2 = C Å CE1 – операція інсталяції,
CE3 = CE1 Ç CE2 – операція зборки (об’єднання) середовищ,
CE4 = CE1 \ C.– операція видалення компонента С з середовища,
C2 – CE2 = C2 Å (CE1 \ C1) – операція заміщення.
Для операцій зовнішній алгебри доведені наступні теореми.
Теорема 2. Кожне компонентне середовище CE є результатом виконання послідовності операцій розгортання компонентів, які входять до його складу, у певному компонентному каркасі: CE = C1 Å C2 Å . . . Å Cn Å FW.
Теорема 3. Побудова компонентного середовища не залежить від порядку інсталяції компонентів, які входять до складу цього середовища, тобто:
C1 Å (C2 Å CE) = C2 Å (C1 Å CE).
Теорема 4. Операція об'єднання компонентних середовищ асоціативна:
(CE1 È CE2) È CE3 = CE1 È (CE2 È CE3).
Теорема 5. Операція об'єднання компонентних середовищ комутативна:
CE1 È CE2 = CE2 È CE1.
Теорема 6. Для будь-якого компонентного середовища
CE È FW = FW È CE = CE.
Теорема 7. Для довільних компонентних середовищ CE1 і CE2 та компонента C завжди виконується:
C Å (CE1 È CE2) = (C Å CE1) È CE2 = (C Å CE2) È CE1.
Теорема 8.. Для будь-якого компонента C та компонентного середовища CE завжди виконується: (C Å CE) \ C = CE.