
- •Перелік термінів та позначень
- •Передмова
- •Частина 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.7. Сервісно-орієнтоване програмування
Ця парадигма програмування з'явилася як наслідок розгляду програмних компонентів як можуть використовуватися як готових сервіси. Для них визначені інтерфейси взаємодії з різними програмами і розподіленими системами (CORBA, DCOM і EJB, MS.Net, IBM тощо) та з веб-сервісіами Інтернету. Нові архітектур систем отримали назву сервісно-орієнтованих архітектур – SOA (Service-Oriented Architecture) і зараз активно розвиваються разом із відповідними засобами їхньої підтримки й опису (XML, SOAP, WSDL і ін.) та механізмами взаємодії звичайних сервісів розподілених застосувань і веб-сервісів Інтернету [18].
2.7.1 Базові понятті сервісу Інтернет
У мережному середовищі поняття компонента обслуговування інших розвинуто до поняття сервісу. Сервіс визначається, з одного боку як відкритий компонент, що може бути елементом швидкої та дешевої композиції у прикладні застосування. З іншого боку, сервіси пропонуються як готовий ресурс, який реалізує деякі додаткові можливості, необхідні усім різнорідним програмам для технічної або комерційної підтримки, потребної потенційним користувачам. Як правило, описи сервісів мистять у собі інформацію про їхні можливості, інтерфейси, поведінку та характеристики. Завдяки такому опису користувач може знайти сервіси, вибрати потрібні йому що і інтегрувати їх у свою композиційну структуру як готовий ресурс. Наведемо й інше визначення сервісу.
Сервіс (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 створюється за допомогою сервісів безвідносно до конкретних технологій, за які можна брати готові застосування типу «чорна скринька». Інтеграція компонентів і сервісів в архітектуру 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.
Як видно з рисунку до головних компонентів належать:
– провайдер сервісу, що здійснює реалізацію сервісу у вигляді веб-сервісу, прийом і виконання запитів користувачів сервісу, а також публікацію сервісу, відзначеного в реєстрі сервісів;
– реєстр сервісів, якій містить у собі бібліотеку сервісів для користувачів сервісу і засоби пошуку і виклику необхідного сервісу за запитами, що надійшли від провайдерів сервісів на надання сервісів;
користувач сервісу (застосування, програмний модуль або сервіс), який здійснює пошук і виклик необхідного сервісу з реєстру сервісів за його описом, а також використовує сервіс, наданий провайдером відповідно до його інтерфейсу.
Рис. 2.11. Компоненти веб-сервісів і взаємодія з різними системами
Зв'язок між діючими системами, наведений на рисунку, здійснюється через ХМL-повідомлення мережного середовища, що використовують інтерфейси веб-сервісів. Посередником між загальносистемними службами розподілених систем і застосувань є провайдер, що звертається до них за сервісом, а інтегратор SOA, що створюються із сервісів і веб-сервісів, називається брокером.
Операції SOA. Для отримання сервісу в архітектурі SOA виконуються наступні операції:
1. Публікація сервісу WSDL з метою забезпечення доступності (через виклик) користувачеві сервісу і його інтерфейсу;
2. Пошук за протоколом SOAP здійснює користувач сервісу в реєстрі сервісів за заданими критеріями;
3. Зв'язування UDDI через опис користувачем необхідного сервісу, який може надаватися в таких моделях як COM, CORBA, DBMS, .JNET тощо.
При цьому передбачається, що в реєстрі архітектури SOA міститься опис сервісу з форматом запитів користувача до провайдера, який містить у собі перелік описів сервісів, що можуть бути викликані відповідно до опублікованого інтерфейсу сервісу.