
- •1. Основи програмної інженерії.
- •1.1. Програмна інженерія в історичному аспекті.
- •1.2. Програмна інженерія як дисципліна.
- •1.3. Swebok: Керівництво до зводу знань з програмної інженерії.
- •1.4. Структура і зміст swebok.
- •1.4.1. Інженерія вимог
- •1.4.2. Проектування програмного забезпечення
- •1.4.3. Конструювання програмного забезпечення
- •1.4.4. Тестування програмного забезпечення
- •1.4.5. Супровід програмного забезпечення
- •1.4.6. Керування конфігурацією
- •1.4.7. Керування інженерією програмного забезпечення
- •1.4.8. Процес інженерії
- •1.4.9. Методи і інструменти інженерії
- •1.4.10. Якість програмного забезпечення
- •Контрольні питання і завдання
- •2. Характеристика життєвого циклу стандарта iso/iec 12207.
- •Контрольні питання і завдання
- •3. Формування прикладних моделей життєвого циклу
- •Контрольні питання і завдання
- •4. Вимоги до програмних систем.
- •4.1. Загальні підходи до визначення вимог
- •Контрольні питання і завдання
- •5. Методи програмування.
- •5.1. Прикладне (систематичне) програмування
- •5.1.1 Структурне програмування
- •5.1.2. Об'єкт но-орієнтоване програмування
- •5.1.4. Компонентне програмування
- •5.1.5. Аспектно-орієнтоване програмування
- •5.1.6. Генерувальне (порождувальне) програмування
- •5.1.7. Сервісно-орієнтоване програмування
- •5.1.8. Агенте програмування
- •5.2. Теоретичне програмування
- •5.3. Контрольні питання і завдання
- •6. Оптимізація програм
- •6.1 Основні поняття.
- •6.2. Призначення і цілі оптимізації
- •6.3. Проміжна мова
- •6.4. Елементи топології програми
- •6.4.1. Блок (лінійна ділянка)
- •6.4.2. Сильно зв'язана область
- •6.5. Способи оптимізації
- •6.5.1. Розвантаження ділянок повторюваності
- •6.5.2. Скорочення глибини операції
- •6.5.3. Спрощення дій
- •6.5.3.1. Видалення індуктивних змінних і виразів
- •6.5.3.2. Заміна складних операцій на більш прості
- •6.5.3.3 Виключення надлишкових виразів
- •6.5.3.4 Інші перетворення
- •6.5.4. Реалізація дій
- •6.5.5. Підстановка (згортання)
- •6.5.6. Чищення програми
- •6.5.6.1. Усунення ідентичних операторів
- •6.5.6.2. Заміна змінних в операторах умовного переходу і усунення невикористовуваних визначень.
- •6.5.6.3. Усунення марних операторів і змінних
- •6.5.7. Економія пам'яті
- •6.5.8. Скорочення програми
- •6.5.9. Вставка псевдоблоку
- •7. Навчально-методичні рекомендації до вивчення дисцілини «Основи програмної інженерії.»
- •7.1. Анотація навчальної дісциплини. Галузь знань – 0501 «Інформатика та обчислювальна техника» Напрям підготовки - 6.050103 «Програмна інженерія»
- •7.2. Необхідність та задачі навчальної дісциплини. Ії місце в учбовому процесі.
- •7.3. Тематичний план курсу.
- •7.4. Тематичний план лекцій.
- •7.5. Тематичний план лабораторних робіт.
- •7.6. Тематичний план практичних робіт.
- •7.7. Тематичний план самостійної роботи студентів.
- •7.8. Питання для підсумкового контролю.
- •7.9. Структура залікового кредиту навчальної дисципліни
- •7.3. Структура модулів дисципліни
- •7.10. Система критеріїв оцінювання знань відповідно до кожного модуля дисципліни
- •Література
- •Список літератури до розділу 2
- •Додаток 1. Термінологічний словник
- •Додаток 2. Перелік стандартів програмної інженерії
5.1.7. Сервісно-орієнтоване програмування
Ця парадигма програмування з'явилася як наслідок розі ляду програмних компонентів як готових сервісів, визначення для них інтерфейсів взаємодії в рамках нової архітектури ПЗ, зв'язаних із сервісами, у середовищі розподілених систем (CORBA, DCOM і EJB) і web - сервісів у середовищі Інтернету. Такі архітектури отримали назву сервісно-орієнтованої архітектури - SOA (Service-Oriented Architecture) і зараз активно розвиваються разом із відповідними засобами їхньої підтримки й опису (XML, SOAP, WSDL і ін.) та механізмами взаємодії звичайних сервісів розподілених застосувань і web - сервісів Інтернету [18].
Тобто у мережному середовищі поняття компонента було розвинуто до форми сервісу. Сервіс визначається як відкритий компонент, що може бути елементом швидкої та дешевої композиції у прикладні застосування. Сервіси пропонуються так званими провайдерами (постачальниками) - організаціями, які реалізують сервіси, надають їхні описи та іншу технічну або комерційну підтримку, якої потребують потенційні користувачі. Описи сервісів містять у собі інформацію про їхні можливості, інтерфейси, поведінку та якісні характеристики. Завдяки такому опису користувач може знайти сервіси, вибрати потрібні йому що і інтегрувати їх у свою композиційну структуру як готовий ресурс. Наведемо й інше визначення сервісу.
Сервіс (service) - це ресурс, що реалізує деяку функцію (у тому числі бізнес-функцію), є повторно використовуваним компонентом і містить у собі технологічно незалежний інтерфейс з іншими ресурсами. Наприклад, сервіси транзакцій, іменування, безпеки в моделі CORBA. Вони утворюють службу сервісів для створення ПС.
Архітектура SOA мас форму піраміди, що складається з кількох шарів [18].
1. Підґрунтям піраміди є базові сервіси і базові операції, а саме, публікація, виявлення, вибір і зв'язування, які націлені на створення і використання описів сервісів.
2. Шар композиції - це консолідація багатьох функціональних сервісів у єдиний складений сервіс, а саме, контроль виконання сервісів і керування потоками даних між ними; публікація подій вищого рівня шляхом фільтрації, підсумовування, кореляції подій компонентів; забезпечення цілісності сервісу та накладання обмежень на його компоненти; досягнення якості композиції сервісів, включаючи показники виконання, секретності, контролю доступу тощо.
3. Шар менеджменту сервісу, а саме, керування платформою сервісу, розгортання, ведення статистики виконання, підвищення ефективності, забезпечення прозорості ходу виконання транзакцій, відетеження стану ходу виконання тощо.
Переважна форма реалізації сервісів - це web - сервіси, які зберігаються та ідентифікуються за URL - адресами і взаємодіють між собою за допомогою мережі Інтернету шляхом віддалених викликів (Remote Procedure Call). Стрімке поширення Інтернету призвело до того, що традиційне єдине інтегроване підприємство минулих поколінь все частіше заміняється мережею бізнесів, які спільно виконують певні функції при тому, що і власність, і менеджмент розподілені між партнерами. Саме інформаційні потреби розподілених бізнесів викликали до життя web - сервіси як адекватну форму компонентів типа КПВ.
Web - сервіс має URL - адресу, інтерфейс і механізм взаємодії з іншим сервісом через протоколи Інтернету або зв'язки з іншими програмами, БД і діловими бізнес-операціями. Обмін даними між web - сервісом і програмою здійснюється за допомогою XML - документів, оформлених у вигляді повідомлень. Web - сервіси забезпечують розв'язання задачі інтеграції застосувань різної природи, будучи інструментом побудови розподілених систем. Web - сервіс надається провайдером мережі Інтернету, який має стандартний спосіб взаємодії з розподіленими (.NET, J2EE, CORBA і ін.) і прикладними системами з отримання деякої послуги.
Основні засоби опису Web - сервісів:
- мова XML для опису і побудови SOA - архітектури;
- мова WSDL (Web Services Description Language) для опису web - сервісів і їхніх інтерфейсів на XML, що стосується типів даних і повідомлень, а також моделей взаємодії і протоколів зв'язування сервісів між собою;
- SOAP (Simple Object Access Protocol) для визначення форматів запитів до web - сервісів;
- UDDI (Universal Description, Discovery and Integration) для універсального опису, виявлення й інтеграції сервісів, забезпечення їхнього збереження, упорядкування ділової сервісної інформації в спеціальному реєстрі з покажчиками на конкретні інтерфейси web - сервісів.
Сервісно-орієнтована архітектура - це сукупність взаємодіючих між собою сервісів і web - сервісів і їхніх інтерфейсів. Будь-який з компонентів SOA створюється за допомогою сервісів безвідносно до конкретних технологій, за які можна брати готові застосування типу «чорна скринька». Інтеграція компонентів і сервісів в архітектуру SOA містить у собі наступні види:
- користувальницьку інтеграцію (user intégration) для взаємодії інформаційної системи з конкретним користувачем;
- зв'язування застосувань (application Connectivity) для забезпечення їхньої взаємодії;
- інтеграцію процесів (process intégration) для об'єднання бізнес-процесів;
- інформаційну інтеграцію (information intégration) для забезпечення доступу до інтегрованої інформації і даних.
При цьому до створюваної архітектури SOA висуваються наступні вимоги:
- наявність існуючих інформаційних систем і поява нових;
- поетапне впровадження нових і міграція існуючих інформаційних систем;
- стандартизація технології і реалізація інструментів для підтримки сервісних архітектур з повторним використанням застосувань і компонентів;
- використання різних моделей і систем (портали, grid - системи й ін.).
Якщо об'єктом сервісно-орієнтованої архітектури є web - сервіс, то застосовується дві технології, що забезпечує функціональність (Functions) і якість сервісів (Quality of service). Ці технології винесені на рівень IT - стандартів комітету W3C і мають наступні рівні.
Технологія забезпечення функціональності web - сервісів має:
- транспортний рівень (transport layer) для обміну даними;
- комунікаційний рівень (service communication layer) для визначення протоколів;
- рівень опису сервісу (service description layer) і зв'язаних з ним інтерфейсів;
- рівень бізнес-процесів (business process layer) для реалізації бізнес-процесів і потоків робіт через механізми web - сервісів;
- рівень реєстру сервісів (service registry layer), який забезпечує організацію бібліотек web - сервісів для їхньої публікації, пошуку і виклику за їхніми WSDL-описами інтерфейсів.
Технологія забезпечення якості web - сервісів має наступні рівні:
- політики (policy layer) для опису правил і умов застосування web - сервісів;
- безпеки (security layer) для опису питань безпеки веб-сервісів і функціонування (авторизація, аутентифікація і розподіл доступу);
- транзакцій (transaction layer) для встановлення параметрів звертання до веб-сервісів і забезпечення надійності їхнього функціонування;
- керування (management layer) для керування web - сервісами.
Технологічний фундамент web - сервісів становлять: XML, SOAP, UDDI, WSDL. З їхньою допомогою здійснюється реалізація базових властивостей web – сервісу і механізму взаємодії між собою web – сервісів у середовищі SOA, що вміщують компоненти, наведені на рис. 5.11.
Рис. 5.11. Компоненти web - сервісів і взаємодія з різними системами
Як видно з рисунку до головних компонентів належать:
- провайдер сервісу, що здійснює реалізацію сервісу у вигляді web - сервісу, прийом і виконання запитів користувачів сервісу, а також публікацію сервісу, відзначеного в реєстрі сервісів;
- реєстр сервісів, якій містить у собі бібліотеку сервісів для користувачів сервісу і засоби пошуку і виклику необхідного сервісу за запитами, що надійшли від провайдерів сервісів на надання сервісів;
- користувач сервісу (застосування, програмний модуль або сервіс), який здійснює пошук і виклик необхідного сервісу з реєстру сервісів за його описом, а також використовує сервіс, наданий провайдером відповідно до його інтерфейсу.
Зв'язок між діючими системами, наведений на рисунку, здійснюється через XML-повідомлення мережного середовища, що використовують інтерфейси web- сервісів. Посередником між загальносистемними службами розподілених систем і застосувань є провайдер, що звертається до них за сервісом, а інтегратор SOA, що створюються із сервісів і web- сервісів, називається брокером.
Для отримання сервісу в архітектурі SOA виконуються наступні операції:
1. Публікація сервісу WSDL з метою забезпечення доступності (через виклик) користувачеві сервісу і його інтерфейсу;
2. Пошук за протоколом SOAP здійснює користувач сервісу в реєстрі сервісів за заданими критеріями;
3. Зв'язування UDDI через опис користувачем необхідного сервісу, який може надаватися в таких моделях як COM, CORBA, DBMS, .JNET тощо.
При цьому передбачається, що в реєстрі архітектури SOA міститься опис сервісу з форматом запитів користувача до провайдера, який містить у собі перелік описів сервісів, що можуть бути викликані відповідно до опублікованого інтерфейсу сервісу.