- •Лекція 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. Тестування продуктивності
Лекція 5. Основи проектування програмних систем.
8. Зв'язність модуля
Зв'язність модуля (Cohesion) — це міра взаємної залежності його частин. Зв'язність — внутрішня характеристика модуля. Чим вище зв'язність модуля, тим кращим є результат проектування, тобто тим «чорнішим» є його ящик, тим менше «ручок управління» знаходиться на ньому, і тим простішими є ці «ручки».
Для вимірювання зв'язності використовують поняття сили зв'язності (СС). Існує 7 типів зв'язності:
1.Зв'язність по збігу (Сс=0). У модулі відсутні явно виражені внутрішні зв'язки.
2.Логічна зв'язність (Сс=1). Частини модуля об'єднані за принципом функціональної
подібності. Наприклад, модуль складається з різних підпрограм обробки помилок. При використанні такого модуля клієнт вибирає тільки одну з підпрограм.
Недоліки:
o складне сполучення;
oвелика вірогідність внесення помилок при зміні сполучення ради однієї з функцій.
3.Часова зв'язність (Сс=3). Частини модуля не зв'язані, але необхідні в один і той же період роботи системи.
Недолік: сильний взаємний зв'язок з іншими модулями, звідси — сильна чутливість внесенню змін.
4.Процедурна зв'язність (Сс=5). Частини модуля зв'язані порядком виконуваних ними дій, що реалізовують деякий сценарій поведінки.
5.Комунікативна зв'язність (Сс=7). Частини модуля зв'язані по даним (працюють з однією і
тією ж структурою даних).
6.Інформаційна (послідовна) зв'язність (Сс=9). Вихідні дані однієї частини використовуються як вхідні дані в іншій частині модуля.
7.Функціональна зв'язність (Сс=10). Частини модуля разом реалізують одну функцію.
Відзначимо, що типи зв'язності 1,2,3 — результат неправильного планування архітектури, а тип зв'язності 4 — результат недбалого планування архітектури застосування.
Загальна характеристика типів зв'язності представлена в табл. 4.1.
Таблиця 5.1. Характеристика зв'язності модуля
Тип зв'язності |
Супроводжуваність |
Роль модуля |
Функціональна |
|
«Чорний ящик» |
Інформаційна |
Краща |
Не зовсім «чорний ящик» |
Комунікативна |
|
«Сірий ящик» |
Процедурна |
Гірша |
«Білий» або такий, що «просвічує ящик» |
Часова |
«Білий ящик» |
|
Логічна |
|
|
По збігу |
|
|
8.1.Функціональна зв'язність
Функціонально зв'язний модуль містить елементи, що беруть участь у виконанні одній і лише одного проблемного завдання. Приклади функціонально зв'язних модулів:
Обчислювати синус кута; Перевіряти орфографію; Читати запис файлу; Обчислювати координати мети;
Обчислювати зарплату співробітника; Визначати місце пасажира.
Кожен з цих модулів має одиничне призначення. Коли клієнт викликає модуль, виконується тільки одна робота, без залучення зовнішніх обробників. Наприклад, модуль Визначати місце пасажира повинен робити тільки це; він не повинен роздруковувати заголовки сторінки.
Деякі з функціонально зв'язних модулів дуже прості (наприклад, Обчислювати синус кута або Читати запис файлу), інші складні (наприклад, Обчислювати координати мети). Модуль
49
Лекція 5. Основи проектування програмних систем.
Обчислювати синус кута, очевидно, реалізує одиничну функцію, але як може модуль Обчислювати зарплату співробітника виконувати тільки одне дію? Адже кожен знає, що доводиться визначати нараховану суму, вирахування по розстрочках, прибутковий податок, соціальний податок, аліменти і т. д.! Річ у тому, що, не дивлячись на складність модуля і на те, що його обов'язок виконують декілька підфункцій, якщо його дії можна представити як єдину проблемну функцію (з погляду клієнта), тоді вважають, що модуль функціонально зв'язний.
Застосування, побудовані з функціонально зв'язних модулів, найлегше супроводжувати. Спокусливо думати, що будь-який модуль можна розглядати як однофункциональный, але не треба помилятися. Існує багато різновидів модулів, які виконують для клієнтів перелік різних робіт, і цей перелік не можна розглядати як єдину проблемну функцію. Критерій при визначенні рівня зв'язності цих нефункціональних модулів — як зв'язані один з одним різні дії, які вони виконують.
8.2.Інформаційна зв'язність
При інформаційній (послідовною) зв'язності елементи-обробники модуля утворюють конвеєр для обробки даних — результати одного обробника використовуються як початкові дані для наступного обробника.
Приведемо приклад:
Модуль Прийом і перевірка запису
прочитати запис з файлу перевірити контрольні дані в записі видалити контрольні поля в записі повернути оброблений запис
Кінець модуля
У цьому модулі 3 ел ементи. Результати першого елементу (прочитати запис з файлу) використовуються як вхідні дані для другого елементу (перевірити контрольні дані в записі) і так далі Супроводжувати модулі з інформаційною зв'язністю майже так само легко, як і функціонально зв'язні модулі. Правда, можливості повторного використання тут нижче, ніж у разі функціональної зв'язності. Причина — сумісне застосування дій модуля з інформаційною зв'язністю корисно далеко
не завжди.
8.3.Комунікативна зв'язність
При комунікативній зв'язності елементи-обробники модуля використовують одні і ті ж дані, наприклад зовнішні дані.
Приклад комунікативно зв'язного модуля:
Модуль Звіт і середня зарплата
використовується Таблиця зарплати службовців згенерувати Звіт по зарплаті обчислити параметр Середня зарплата
повернути Звіт по зарплаті. Середня зарплата
Кінець модуля
Тут всі елементи модуля працюють із структурою Таблиця зарплати службовців.
З погляду клієнта проблема застосування комунікативно зв'язного модуля полягає в надмірності отримуваних результатів. Наприклад, клієнтові потрібний тільки звіт по зарплаті, він не потребує значення середньої зарплати. Такий клієнт буде вимушений виконувати надмірну роботу — виділення в отриманих даних матеріалу звіту. Майже завжди розбиття комунікативне зв'язного модуля на окремих функціонально зв'язні модулі покращує сопровождаемость системи.
Спробуємо провести аналогію між інформаційною і комунікативною зв'язністю.
Модулі з комунікативною і інформаційною зв'язністю подібні в тому, що містять елементи, зв'язані по даним. Їх зручно використовувати, тому що лише небагато елементів в цих модулях пов'язано із зовнішнім середовищем. Головна відмінність між ними — інформаційно зв'язний модуль
50
Лекція 5. Основи проектування програмних систем.
працює подібно до складальної лінії; його обробники діють в певному порядку; у комунікативно зв'язному модулі порядок виконання дій байдужий. У нашому прикладі не має значення, коли генерується звіт (до, після або одночасно з обчисленням середньої зарплати).
8.4.Процедурна зв'язність
Досягши процедурної зв'язності ми потрапляємо в прикордонну область між хорошою сопровождаемостью (для модулів з вищими рівнями зв'язності) і поганий сопровождаемостью (для модулів з нижчими рівнями зв'язності). Процедурно зв'язний модуль складається з елементів, що реалізовують незалежні дії, для яких заданий порядок роботи, тобто порядок передачі управління. Залежності по даним між елементами немає.
Наприклад:
Модуль Обчислення середніх значень
використовується ТАБЛИЦЯ-А. ТАБЛІЦА-В обчислити середнє по ТАБЛИЦЯ-А обчислити середнє по ТАБЛИЦЯ-В повернути среднееТабл-А. среднееТабл-В
Кінець модуля
Цей модуль обчислює середні значення для двох повністю незв'язаних таблиць ТАБЛИЦЯ-А і ТАБЛИЦЯ-В, кожна з яких має по 300 елементів.
Тепер уявимо собі програміста, якому доручили реалізувати даний модуль. Спокусившись можливістю мінімізації коди (використовувати один цикл на користь двох обробників, адже вони знаходяться усередині єдиного модуля!), програміст пише:
Модуль Обчислення середніх значень використовується ТАБЛИЦЯ-А. ТАБЛИЦЯ-В суммаТабл-А := 0 суммаТабл-В := 0
для i := 1 до 300
суммаТабл-А := суммаТабл-А + ТАБЛИЦЯ-А(i) суммаТабл-В :- суммаТабл-В + ТАБЛИЦЯ-В(i) кінець для среднееТабл-А := суммаТабл-А / 300
среднееТабл-В := суммаТабл-В / 300 повернути среднееТабл-А, среднееТабл-В Кінець модуля
Для процедурної зв'язності цей випадок типовий — незалежний (на рівні проблеми) код став залежним (на рівні реалізації). Пройшли роки, продукт здали замовникові. І раптом виникло завдання супроводу — модифікувати модуль під зменшення розміру таблиці В. Оціните, наскільки зручно її вирішувати.
8.5.Часова зв'язність
При зв'язності за часом елементи-обробники модуля прив'язані до конкретного періоду часу (з життя програмної системи).
Класичним прикладом тимчасової зв'язності є модуль ініціалізації: Модуль Ініціалізувати Систему перемотати магнітну стрічку 1 Лічильник магнітної стрічки 1 := 0 перемотати магнітну стрічку 2 Лічильник магнітної стрічки 2 := 0
Таблиця поточних записів : = пропуск..пропуск Таблиця кількості записів := 0..0 Перемикач 1 : = выкл Перемикач 2 := вкл
51
Лекція 5. Основи проектування програмних систем.
Кінець модуля Елементи даного модуля майже не зв'язані один з одним (за винятком того, що повинні
виконуватися в певний час). Вони всі — частина програми запуску системи. Зате елементи тісніше взаємодіють з іншими модулями, що приводить до складних зовнішніх зв'язків.
Модуль із зв'язністю за часом зазнає ті ж труднощі, що і процедурне зв'язний модуль. Програміст спокушається можливістю сумісного використання коди (діями, які зв'язані тільки за часом), модуль стає важко використовувати повторно.
Так, за бажання ініціалізувати магнітну стрічку 2 в інший час ви зіткнетеся з незручностями. Щоб не скидати всю систему, доведеться або ввести прапорці, вказуючі ініціалізовану частину, або написати інший код для роботи із стрічкою 2. Обидва рішення погіршують сопровождаемость.
Процедурно зв'язні модулі і модулі з тимчасовою зв'язністю дуже схожі. Ступінь їх непрозорості змінюється від темного сірого до світло-сірого кольору, оскільки важко оголосити функцію такого модуля без перерахування її внутрішніх деталей. Відмінність між ними подібно до відмінності між інформаційною і комунікативною зв'язністю. Порядок виконання дій важливіший в процедурно зв'язних модулях. Крім того, процедурні модулі мають тенденцію до сумісного використання циклів і галужень, а модулі з тимчасовою зв'язністю частіше містять лінійніший код.
8.6.Логічна зв'язність
Елементи логічно зв'язного модуля належать до дій однієї категорії, і з цієї категорії клієнт вибирає виконувану дію.
Розглянемо наступний приклад:
Модуль Пересилка повідомлення
переслати по електронній пошті переслати факсом послати в телеконференцію переслати по ftp-протоколу
Кінець модуля
Як видно, логічно зв'язний модуль — набір доступних дій. Дії вимушені спільно використовувати один і той же інтерфейс модуля. У рядку виклику мод уля значення кожного параметра залежить від використовуваної дії. При виклику окремих дій деякі параметри повинні мати значення пропуску, нульові значення і так далі (хоча клієнт все ж таки повинен використовувати їх і знати їх типи).
Дії в логічно зв'язному модулі потрапляють в одну категорію, хоча мають не тільки схожість, але і відмінності. На жаль, це примушує програміста «зав'язувати код дій у вузол», орієнтуючись на те, що дії спільно використовують загальні рядки коди. Тому логічно зв'язний модуль має:
oпотворний зовнішній вигляд з різними параметрами, що забезпечують, наприклад, чотири види доступу;
oзаплутану внутрішню структуру з безліччю переходів, схожу на чарівний лабіринт.
Урезультаті модуль стає складним як для розуміння, так і для супроводу.
8.7.Випадкова Зв'язність
Елементи модуля, з випадковою зв'язністю взагалі не мають ніяких відношень один з одним:
Модуль Різні функції (якісь параметри)
привітати з Новим роком (...) перевірити справність апаратури (...) заповнити анкету героя (...) зміряти температуру (...)
вивести собаку на прогулянку (...) запастися продуктами (...) придбати «ягуар» (...)
Кінець модуля
52
