- •Перелік термінів та позначень
- •Передмова
- •Частина 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.1.1. Моделі взаємодії компонентів у пс
- •Частина 4. Методи індустрії виробицтва програм і систем
- •4.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.5. Компонентна алгебра
Алгебра включає зовнішню та внутрішню. Остання містить операції щодо трансформації вихідного коду компоненту: рефакторингом для змінювання внутрішній структури КПВ, інтерфейсу зі збереженням його поведінки; реінженерії, як апарату еволюції КПВ шляхом внесення деяких змін в КПВ у зв’язку з уточненням деякої функції КПВ для їх змінювання в ПС; реверсної інженерії шляхом встановлення первісної структури КПВ у МП і реконструювання її (перепрограмування) до умов нового середовища. Трансформація може торкатися зміни функціональності та поведінки компонентів у інтерфейсах і реалізаціях, а також зміни не функціональних змін (тобто вимог до захисту, безпеки, характеристик якості тощо).
Внутрішня компонентна алгебра має вигляд:
j = {CSet, CESet, W2},
де W2 = {Оrefac, OReing , ORever } – сукупність операцій еволюції компонентів:
Оrefac = {AddOIm, AddNIm, ReplIm, AddIn} – рефакторінгу,
Oreing= {rewrite, restruc, adop, supp, conver } – реінженерії,
ORever= {visual, metric, restruc, design, rewrite} – реверсної інженерії.
Внутрішня алгебра рефакторінгу компонентів
rf = (CSet, Refac),
де CSet = {Cn} – множина компонентів, модель кожного з яких наведена виразом (3),
Refac = {AddOIm, AddNIm, ReplIm, AddIn} – сукупність операцій рефакторінгу:
– операція AddOIm є додаванням нової реалізації для існуючого інтерфейсу:
NewC = AddOIm(OldC, NewCIms, NewCInOs) і має семантику: NewCIn = OldCInÈNewCInOs (додаються нові вихідні інтерфейси для нової реалізації), NewCIm = OldCImÈ{NewCIms} (додається нова реалізація), $OldCInt Î OldCInI [Pr(OldCInt) Í NewCIms] (для реалізації, що додається, існує вхідний інтерфейс з відповідною функціональністю). Операція є асоціативною та комутативною. Умова цілісності компонента (3) зберігається.
– операція AddNIm є додаванням нової реалізації, вхідний інтерфейс для якої не входить до складу множини інтерфейсів компонента:
NewC = AddNIm(OldC,NewCIms,NewCInOs) і має семантику: NewCIn = OldCInÈNewCInOs (додаються нові вихідні інтерфейси для нової реалізації), NewCIm = OldCIm È {NewCIms} (додається нова реалізація). Операція є асоціативною та комутативною. Умова цілісності компонента зберігається.
– операція ReplIm як заміщення існуючої реалізації новою без зміни вхідного інтерфейсу: NewC=ReplIm(OldC, NewCIms, NewCInOs, OldCImr, OldCInOr) і має семантику: NewCIn=OldCInÈ {NewCInOs}\{OldCInOr}, тобто додаються вихідні інтерфейси для нової реалізації і видаляються вихідні інтерфейси старої реалізації), NewIm = OldIml È {NewCIms}\{OldCImr} – додається нова реалізація і видаляється стара. Умовою виконання операції є незмінність функціональності усіх інтерфейсів, що пов’язані зі старою реалізацією, після заміщення її новою
" OldCIntÎOldCInI [(Pr(OldCInt)ÍOldCImr)=> (Pr(OldCInt)ÍNewCIms)]
$ OldCImjÎ(OldCIm\{OldCImr})[Pr(OldCInt) ÍOldCImj].
Лема 1. Операція заміщення існуючої реалізації новою з визначеними вище умовою та семантикою зберігає цілісність компонента.
Операція AddIn є додаванням нового вхідного інтерфейсу для існуючої реалізації:
NewC = AddIn(OldC, NewCInIq)і має семантику: NewCIn = OldCIn È {NewCInIq} (додається новий вхідний інтерфейс), $OldCImsÎ OldCIm [Pr(NewCInIq)ÍOldCIms] (для нового інтерфейсу існує реалізація з відповідною функціональністю).
Лема 2. Операція додавання нового вхідного інтерфейсу для існуючої реалізації з визначеними вище умовою та семантикою зберігає цілісність компонента.
Наведені операції є базовими для більш складних ПС. Наприклад, додавання реалізації разом з вхідним інтерфейсом визначаються наступною суперпозицією:
NewC = AddIn(AddNIm(OldC, NewCIms, NewCInOs), NewCInIq).
Сформульовано та доведено наступну теорему.
Теорема 10. Алгебра рефакторінгу компонентів rf = (CSet, Refac) є повна та незаперечна.
Поповнення компонентної алгебри. Компонентна алгебра рефакторінгу поповнено моделями реінжинірингу та реверсної інженерії, у зв’язку з тим, що змінювання компонентів може бути трансформаційним способом.
Модель реінжинірингу компонентів МRe = (CSet, Re),
де Re (Reeng) – операція ре інженерії, яка будується лише за умови порушення цілісності подання компонентів. Ця операція видаляє з компонента існуючий інтерфейс або змінюють його сигнатуру. Це порушує умову цілісності, бо інші компоненти, які звертаються до нього, не зможуть мати доступу до необхідної функціональності. При зміні сигнатури вхідного інтерфейсу необхідна одночасна зміна інших компонентів, в яких існують звернення до методів цього інтерфейсу.
Модель реверсної інженерії МRev = (CSet, Rev),
де Rev (Revers ) – операція реверсної інженерії і Re Rev. Особливість множини Rev є – необмеженість кількості операцій та їх класифікацією. Наприклад, зміни якісних характеристик компонентів можуть виконуватись довільним способом і відповідні операції складають сукупність операцій для зміни певного показника якості (за класифікаційною ознакою в множини Rev).
Таким чином, алгебра rf та моделі МRe і МRev складають формальний апарат внутрішній алгебри щодо моделей і методів еволюції компонентів.
Модель ПС в межах компонентного середовища подамо виразом
CP = (CE, Cont, CO),
де CE – компонентне середовище,
Cont – множина контрактів для компонентів, що входять до складу CE,
CO – підмножина компонентів з CE, що включають реалізації і звертаються до інших компонентів за допомогою своїх вихідних інтерфейсів. Ці компоненти є початковими для CP, наприклад, до їх складу входять компоненти, що безпосередньо взаємодіють з кінцевим користувачем і звертаються до основної функціональності програми з метою виконання певних запитів.
Умова цілісності СР полягає в існуванні для кожного компонента C1 з CE, що має вихідний інтерфейс CInO1i, компонента C2 з відповідним вхідним інтерфейсом CInI2m і контракт Cont12im = (CInO1i, CInI2m, IMap12im) входить до складу множини Cont.
Для певної компонентної моделі компонентна конфігурація складається з двох компонентів і для другого з них може додаватися реалізація і вхідний інтерфейс за наступним виразом:
CE = C1Å AddIn(AddNIm(C2, NewCIms, NewCInOs), NewCInIq) Å FW.
