
- •Перелік термінів та позначень
- •Передмова
- •Частина 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.4.2. Концепторна мова специфікації
Для постановки складних математичних задач (підсумовування нескінченних рядів, теоретико–множинних операцій з нескінченними множинами тощо) і задач штучного інтелекту (ігри, розпізнавання образів тощо) з метою їх формального опису запропонована загально математична процедурна мова, а саме, концепторна мова (КМ) [16]. У цій мові процес опису складного завдання проводиться шляхом обґрунтування рішення задачі з математичної точки зору, потім формального опису постановок задач і, нарешті, перехід до алгоритмічного опису.
Специфікація складних завдань. Концепторна мова містить декларативні й імперативні засоби теорії множин Цермело–Френкеля. Ядро цієї мови містить набір елементів (типи, вирази, оператори) і засоби визначення нових типів, виразів і операторів.
Декларативні засоби КМ – це типізована логіко-математична мова для опису виразів і структуризації множин значень (денотат). Вирази складаються з термів і формул, терми позначають об'єкти ПрО, а формули – твердження про об'єкти і відношення між ними.
Базові елементи мови – конструктори складених типів і формул, а саме функтори, предикати, конектори і субнектори.
Функтор – це конструктор, що перетворює терми в терми.
Предикати перетворюють терми на формули.
Конекторы включають логічні зв'язки і квантори для перетворення однієї формули в іншу.
Субнектор (дескриптор) – це конструктор побудови термів з виразів і формул.
Імперативні засоби КМ – це оператори і процедури для опису об'єктів ПрО за допомогою концепторів. Опис процедури має такий загальний вигляд.
концептор К ( список параметрів )
список імпортних параметрів>
визначення констант, типів, предикатів
опис глобальних змінних
визначення процедури
початок К
тіло концептора>
кінець К.
Денотаційний підхід полягає у
визначенні семантики шляхом
підстановки кожному виразу опису
відповідного елемента з множини денотатів
функції
інтерпретації символів сигнатури мови.
Кожній константі
,
функціональному символу
і предикативному символу
зіставляється об'єкт з множини денотат.
Цей спосіб інтерпретації семантики
виразів і операторів мови аналогічний
денотаційній семантиці мов програмування.
Аксіоматичний опис КМ – це аксіоми і твердження щодо концепторного опису і проведення дедуктивного доведення і верифікації цього опису.
Логіко–алгебраїчні специфікації КМ призначені для специфікації ПрО, що задаються у вигляді алгебраїчної системи, за допомогою відповідних носіїв, сигнатури і трьох принципів. Перший принцип – логіко–алгебраїчна специфікація ПрО і уточнення понять ПрО, другий принцип – опис властивостей ПрО у вигляді аксіом, які формулюються мовою предикатів першого порядку і хорновських атомарних формул, і, нарешті, третій принцип – це визначення термальних моделей з основних термів специфікації.
Засоби КМ використовуються при формальній специфікації поведінки дискретних систем. Для опису властивостей апаратно–програмних засобів динамічних систем застосовуються логіко–алгебраїчні специфікації. Техніка опису таких систем включає два етапи.
На першому етапі дискретна система S розглядається як чорний ящик з кінцевим набором входів, виходів і станів. Області значень входів і виходів – довільні, а функціонування системи S – це набір часткових відображень і операцій алгебраїчної системи. Вони утворюють часткову алгебру, формальний опис якої виконується за допомогою алгебраїчних специфікацій, і воно є програмою моделювання станів дискретної системи.
На другому етапі система S деталізується у вигляді сукупності взаємозалежних підсистем S1,..., Sn, кожна з яких описується алгебраїчною специфікацією. В результаті одержують специфікацію системи S із функцій переходів і виходів, для яких необхідно доводити коректність. Процес деталізації виконується на рівні елементної бази або елементарних програм і супроводжується доведенням їх коректності. Зрештою виходить, система S еквівалентна початковій абстрактній специфікації.
Приклади доказу. Нехай треба побудувати специфікацію натуральних чисел з множини цих чисел і сигнатури операцій = (+, , ). При побудові використовується число 0 і функція проходження s: N N’. Специфікація складається з таких аксіом:
х+0 = х
х+s(у) = s (х+у)
х 0 = 0
х+s(у) = s (х у) +х
0 х
х в s (х) s (у)
s (х) s (у) х в
Алгебраїчні специфікації називають мовами логіко–алгебраїчних специфікацій, їх операційна семантика заснована на переписуванні термів, а створювана алгебраїчна специфікація одержує логічну семантику, використовувану при доведенні теорем.
Звичайна мова специфікації Spec#
Сучасна мова специфікація Spec# є розширенням об’єктно–орієнтованої мови С# засобами, що забезпечують верифікацію програм для платформи .Net [12]. Ці засоби подаються до програми в С# невеликими додатковими описами, а саме:
– ненульових посилань щодо параметрів викликів CALL;
– контрактів між викликами і реалізаціями;
– обробки виникаючих виключних ситуацій програми для інформування розробника;
– змінювання полів даних об’єктів тощо.
Ненульові типи даних помічаються типом Т! і відповідають деяким змінним програми, які можуть використовуватися при специфікації полів даних, формальних параметрів і з зворотно цього типу значень, локальних змінних програми. Цей тип не відноситься до елементів масиву. Головне призначення ненульових типів – забезпечити посилання до інших елементів, опис патернів, перевірку умов виходу з виразів і циклів, обумовлених контрактом.
Контракт ставиться між тим, хто робить виклик і хто реалізацію. В передумові додається опис стану параметрів при виклику, в постумові визначається умова отримання результату об’єкта, що викликався, і передачу цього результату зворотно. Spec# додає підтримку більш дисциплінованому використанню виключення, щоб забезпечити ясність і підтримку життєздатності програми. В програмі можуть бути відмови і помилки. В даному випадку метод звертається до аналізу заборонної умови, коли передумова була не задоволена. Більшість відмов у програмі, коли порушена умова контракту. Наприклад, отримання виходу з циклу при перевищенні значення параметру циклу, що не було визначено у передумові.
Обробка виключних ситуацій виконується при роботі з масивами, коли елемент не відповідає типу. Коли в передумові специфікується індекс, що знаходиться всередині границь масиву, а при виконанні цього не відбувається, то компілятор відповідає клієнту про невиконання передумови в реальному часу.
Змінювання полів даних задається фреймовими умовами, котрі включаються у контракт і починаються modifies, за яким слідкує оператор частини програми метода реалізації, дозволяючого зміну. Приклад.
Class C{
Int x, y;
Void M () modifies x: {…}.
Тут метод М дозволяє зміну х при умові, що значення у на виході з цього методу має те ж саме значення, що на вході. У випадку масиву такий оператор змінює на елементи масиву, а посилання – на сам масив.
Фреймові умови для сервера використовується в час виконання програми. При чому modifies перевіряє на вході усі перед - і постумови виконання операторів програми в С#, на які спираються описи специфікацій в spec# і розраховуються коректними.
Успадкування специфікацій. Контрактний метод успадковується звичайним методом, котрий в час виконання звертається до нього. Специфікація в Spec# подає код виконання в більш наглядній формі і зручній для перевірки заданих постумов. Метод може додавати к опису додаткові постумови , а також різні реакції на виключні ситуації. Метод має об’яву у інтерфейсі, подібно тому, як метод має об’яву в класі. Коли клас виконує метод інтерфейсу, то його опис містить фреймові умови, котрі є суперкласом виконаному методу. Для виконання фреймових умов використовується оператор expose. Він, як правило, визначає об’єкт, інваріантний модифікації. Специфікація в Spec# представляє блок операторів. котрий явно вказує на то, коли об’єктний інваріант може явно використовувати оператори, що вказані після expose. При цьому можуть модифікуватися усі поля в структурі об’єкта.
Підхід до реалізації специфікації. Опис специфікації в Spec# є самостійною програмою, яка містить перед – і постумови, а також різні дії над фреймовими структурами стосовно програми, що перевіряється на мові С#. Ця специфікація подається в мово-незалежному форматі і перебудовується в мову С# за допомогою спеціального транслятора, що працює на платформі .Net. Цей транслятор має аналізатор і версифікатор для перевірки правильності опису специфікації. Транслятор виконує переклад в вигляді частини програми, для якої створювалася специфікація. Верифікація специфікації є статичною, вона орієнтована на перевірку правильності опису, а саме границь масивів, явних значень змінних тощо. Прувер транслятора виконує перевірку деяких умов і операторів, а також значень змінних. Специфікації в Spec# накопичується у репозитарії, а застосування звертаються до Base Class Library, де накопичуються об’єкти, їх інваріанти та контракти.
Контракти і аналогічні механізми верифікації програм в мові програмування реалізовані також в системах Java, Eiffel і Spark. В Java контракти включаються в опис програми як стилізовані коментарі. Середовище Java має такі засоби: перевірку контрактів в динаміці, виконання, виклики та об’єктні інваріанти. В об’єктно–орієнтованій системі Eiffel є бібліотека констрейнів, котрі вставляються у опис об’єкта і виконують верифікацію в динаміці виконання. Однак механізми модифікації не дозволяють для callbacks об’єктних інваріантів і тому вони не включаються як модульні об’єкти. Система Spark забезпечує підмножину мови Ада для вставки теорем для прувера, помічених як коментарії, але компілятор цієї мови їх не використовує. Засоби верифікації в Spark орієнтовані на окремий опис умов виконання Ада–програм для верифікації, аналогічно методології Spec#. Вони окремо транслюються в вихідної код Ада-програми і виконуються разом з нею в режимі верифікації.