![](/user_photo/2706_HbeT2.jpg)
- •Лекція 0. Вступ. Цілі, завдання і місце курсу
- •1. Мета викладання курсу
- •2. Завдання вивчення курсу
- •3. Дисципліни, засвоєння яких необхідне при вивченні курсу
- •4. Характеристика курсу
- •5.1. Література
- •5.2. Інформаційні ресурси мережі Інтернет
- •Лекція 1. Введення у технологію програмування
- •1. Термінологія індустрії ПЗ
- •1.1. Програмування
- •1.2. IT-проекти
- •1.3. Програми і програмне забезпечення (програмні продукти)
- •2. Бізнес і IT-проекти. Ринок ПЗ.
- •3. Про предмет
- •5. Виникнення Технології розробки ПЗ
- •5.1. Коротка історія програмування
- •5.2. Терміни “Технологія”, “Методологія” і “Програмна інженерія”
- •5.3. Стратегії розробки ПЗ
- •6. Огляд технологій програмування
- •6.1. Структурне програмування
- •6.2. Модульне програмування
- •6.4. Компонентне програмування
- •6.5. Висновки з лекції
- •Лекція 2. Елементи програмної інженерії
- •1. Програмна інженерія, основні поняття
- •1.1. Інженери і програмні інженери
- •1.2. Програмна інженерія як інженерна дисципліна
- •1.3. Область дії програмної інженерії
- •2. Цілі програмних інженерів
- •2.1. Поняття “якості” програмного продукту
- •2.2. Створення ПЗ повинно вкладатися до бюджету
- •2.3. Створення ПЗ повинно вкладатися в терміни
- •3. Забезпечення надійності розробки ПЗ
- •3.1. Забезпечення точності інтерпретації
- •3.2. Подолання бар'єру між користувачем і розробником
- •3.3. Контроль ухвалюваних рішень
- •3.4. Програмні інженери і наукове середовище
- •4. Складність програмної системи
- •4.1. Методи боротьби зі складністю
- •5. Моделі якості процесів розроблення ПЗ
- •Лекція 3. Організація технологічного процесу розробки ПЗ
- •1. Процес створення програмного забезпечення
- •1.1. Основні стадії типового процесу створення ПП
- •2. Життєвий цикл та моделі процесу розробки ПЗ
- •2.1. Каскадна модель (Waterfall model)
- •2.2. Макетування (прототипіювання)
- •2.3. Інкрементна модель
- •2.4. Модель Швидкої Розробки (RAD)
- •2.5. Спіральна модель
- •3. “Важкі” і “полегшені” процеси
- •4. ХР-процесс
- •Лекція 4. Оцінка програмного проекту по СОСОМО
- •1. Процес управління проектом
- •1.1. Початок проекту
- •1.2. Оцінювання, заходи і метрики
- •1.3. Процес оцінки
- •1.4. Аналіз ризиків
- •1.5. Планування
- •1.6. Трасування і контроль
- •2. Планування проектних завдань
- •3. Розмірно-орієнтовані метрики
- •4. Функціонально-орієнтовані метрики
- •5. Оцінка проекту на основі LOC- і FP-метрик
- •Лекція 5. Проектування програмних систем
- •1. Особливості процесу синтезу програмних систем
- •2. Особливості етапу проектування
- •3. Структуризація системи
- •4. Моделювання управління
- •5. Декомпозиція підсистем на модулі
- •6. Модульність
- •7. Інформаційна закритість
- •8. Зв'язність модуля
- •8.1. Функціональна зв'язність
- •8.2. Інформаційна зв'язність
- •8.3. Комунікативна зв'язність
- •8.4. Процедурна зв'язність
- •8.5. Часова зв'язність
- •8.7. Випадкова Зв'язність
- •8.8. Визначення зв'язності модуля
- •9. Зчеплення модулів
- •10. Складність програмної системи
- •11. Характеристики ієрархічної структури програмної системи
- •Лекція 6. ПОБУДОВА АРХІТЕКТУРИ ПП
- •1. Поняття архітектури програмного засобу.
- •2. Основні принципи проектування архітектури
- •3. Основні питання архітектора ПП
- •4. Архітектурні стилі (шаблони) ПП
- •5. Поєднання архітектурних стилів
- •6. Основні класи архітектур ПП
- •6.1. Цілісна програма
- •6.2. Архітектура ППП
- •6.3. Архітектура, заснована на шині повідомлень
- •6.4. Архітектура клієнт/сервер
- •6.6. Багатошарова архітектура
- •6.8. Компонентна архітектура
- •6.10. Сервісно-орієнтована архітектура
- •7. 4. Контроль архітектури ПП
- •Лекція 7. Розробка Програм, Модульне Програмування
- •1. Поняття модульного програмування
- •1.1. Основні характеристики програмного модуля.
- •1.2. Методи розробки структури програми.
- •1.3. Контроль структури програми.
- •2. Розроблення програмних модулів
- •2.1. Порядок розробки програмного модуля
- •2.2. Структурне програмування модуля
- •2.3. Покрокова деталізація і поняття про псевдокод.
- •Лекція 8. Тестування і відлагодження ПЗ
- •1. Основні поняття тестування і відлагодження
- •2. Основні підходи і принципи відлагодження.
- •2.1. Заповіді відлагодження.
- •2.2. Автономна відладка модулів
- •2.3. Проміжна відладка програмного засобу
- •2.4. Комплексна відладка програмного засобу.
- •3. Організація процесу тестування ПЗ
- •3.1. Тестування елементів
- •3.2. Інтегральне Тестування ПП
- •3.3. Низхідне тестування інтеграції
- •3.4. Висхідне тестування інтеграції
- •3.5. Порівняння низхідного і висхідного тестування інтеграції
- •4. Види Тестування
- •4.1. Тестування правильності
- •4.2. Системне тестування
- •4.3. Тестування відновлення
- •4.4. Тестування безпеки
- •4.5. Стресове тестування
- •4.6. Тестування продуктивності
![](/html/2706/1080/html_synSuhlfNM.Gy5Z/htmlconvd-ZGBc2T47x1.jpg)
Лекція 5. Основи проектування програмних систем.
Мал. 5.9. Широкомовна модель
Мал. 5.10. Модель, керована перериваннями
У моделі, керованій перериваннями (мал. 5.10), всі переривання розбиті на групи — типи, які утворюють вектор переривань. Для кожного типу переривання є свій обробник. Кожен обробник реагує на свій тип переривання і запускає свій процес.
5. Декомпозиція підсистем на модулі
Відомо два типи моделей модульної декомпозиції:
•модель потоку даних;
•модель об'єктів.
Уоснові моделі потоку даних лежить розбиття по функціях.
Модель об'єктів заснована на слабо зчепленій суті, що має власні набори даних, стани і набори операцій.
Очевидно, що вибір типу декомпозиції повинен визначатися складністю розбиваної підсистеми.
6. Модульність
Модуль — фрагмент програмного тексту, що є будівельним блоком для фізичної структури системи. Як правило, модуль складається з інтерфейсної частини і частини-реалізації.
Модульність — властивість системи, яка може піддаватися декомпозиції на ряд внутрішньо зв'язаних і слабо залежних один від одного модулів.
За визначенням Р. Майерса, модульність — властивість ПЗ, що забезпечує інтелектуальну можливість створення скільки завгодно складної програми. Проілюструємо цю точку зору.
Хай З(х) — функція складності вирішення проблеми х, Т(х) — функція витрат часу на вирішення проблеми х. Для двох проблем р1 і р2 із співвідношення З(р1)> З(р2) витікає, що
T(pl) >T(p2). |
(5.1) |
Цей вивід інтуїтивно ясний: вирішення складної проблеми вимагає більшого часу. |
|
Далі. З практики вирішення проблем людиною виходить: |
|
З(р1+ р2) >З(р1)+ З(р2). |
|
Звідси з урахуванням співвідношення (4.1) запишемо: |
|
T(pl+p2) >T(pl)+ T(p2). |
(5.2) |
Співвідношення (5.2) — це обгрунтування модульності. Воно приводить до висновку «розділяй і володарюй» — складну проблему легко вирішити, розділивши її на керовані частини. Результат, виражений нерівністю (5.2), має важливе значення для модульності і ПО. Фактично, це аргумент на користь модульності.
47
![](/html/2706/1080/html_synSuhlfNM.Gy5Z/htmlconvd-ZGBc2T48x1.jpg)
Лекція 5. Основи проектування програмних систем.
Проте тут відбита лише частина реальності, адже тут не враховуються витрати на міжмодульний інтерфейс. Як показано на мал. 4.11, із збільшенням кількості модулів (і зменшенням їх розміру) ці витрати також ростуть.
Мал. 5.11. Витрати на модульність
Таким чином, існує оптимальна кількість модулів Opt, яке приводить до мінімальної вартості розробки. На жаль, у нас немає необхідного досвіду для гарантованого прогнозу Opt. Втім, розробники знають, що оптимальний модуль повинен задовольняти двом критеріям:
зовні він простіший, ніж усередині; його простіше використовувати, чим побудувати.
7. Інформаційна закритість
Принцип інформаційної закритості (автор — Д. Парнас, 1972) затверджує: зміст модулів повинен бути приховане один від одного [60]. Як показано на мал. 4.12, модуль повинен визначатися і проектуватися так, щоб його вміст (процедури і дані) був недоступний тим модулям, які не потребують такої інформації (клієнтам).
Мал. 5.12. Інформаційна закритість модуля
Інформаційна закритість означає наступне:
1)всі модулі незалежні, обмінюються тільки інформацією, необхідною для роботи;
2)доступ до операцій і структур даних модуля обмежений.
Переваги інформаційної закритості:
•забезпечується можливість розробки модулів різними, незалежними колективами;
•забезпечується легка модифікація системи (вірогідність розповсюдження помилок дуже мала, оскільки більшість даних і процедур приховано від інших частин системи).
Ідеальний модуль грає роль «чорного ящика», вміст якого немабуть клієнтам. Він простий у використанні — кількість «ручок і органів управління» їм невелика (аналогія з експлуатацією телевізора). Його легко розвивати і коректувати в процесі супроводу програмної системи. Для забезпечення таких можливостей система внутрішніх і зовнішніх зв'язків модуля повинна відповідати особливим вимогам. Обговоримо характеристики внутрішніх і зовнішніх зв'язків модуля.
48