
- •Питання
- •Проектування пз – проектування, цілі проектування, вимоги до пз
- •Життєвий цикл пз
- •Моделі життєвого циклу
- •Цілісність даних та надійність
- •Шаблони проектування
- •Класифікація архітектур пз
- •Обробка помилок, виключень та небажаних умов
- •Діаграми подій
- •Зв’язність та зв’язаність (coupling and cohesion)
- •Повторне використання коду
- •11. Ітеративне й інкрементне проектування
- •12.Функціональна методика потоків даних
- •13. Структурна схема розроблюваного пз
- •14. Проектування програмного забезпечення при структурному підході
- •15. Типи компонентних структур та основі означення
- •16. Методологія компонентної розробки пз
- •17. Приклади компонентних середовищ
- •18. Планування архітектури
- •1. Архітектура впливає на структуру компанії-розроблювача.
- •2. Архітектура здатна впливати на завдання розроблювача.
- •3. Архітектура може впливати на вимоги, висунуті замовником щодо наступної системи (якщо вона заснована на тій же архітектурі, що й попередня).
- •4. Процес конструювання систем поповнює досвід архітектора.
- •5. Окремі «віхові» системи.
- •19. Програмний процес та архітектурно-економічний цикл
- •20. Архітектурні зразки, еталонні моделі та еталонні варіанти архітектури
- •Архітектурні структури і подання
Класифікація архітектур пз
Архітектури потоків даних.
Послідовні пакети.
Канали й фільтри.
Незалежні компоненти.
Паралельні взаємодіючі процеси.
Клієнт-серверні системи.
Системи, керовані подіями.
Віртуальні машини
Інтерпретатори
Системи, засновані на правилах
Репозиторні архітектури
Бази даних
Гіпертекстові системи
Дошки оголошень
Рівневі архітектури
Обробка помилок, виключень та небажаних умов
Обробка помилок
Логічні помилки - виявляються на етапі тестування та відладки
Коректно працюючі програми не містять помилок
Для попередження та виправлення помилок використовується програмна логіка
Підтримується нормальний хід виконання програми
Обробка виключень
Описує непередбачені умови під час виконання
Коректно написані програми можуть потрапляти у виключні ситуації
Для відновлення працездатності програми після виникнення виключних ситуацій використовуються методи обробки виключень
Нормальний хід виконання програми порушується
Обробка небажаних умов
Описує небажані умови, які цілком імовірні під час виконання
Коректно написані програми можуть потрапляти в небажані ситуації
Для виправлення небажаних умов використовується програмна логіка
Робиться спроба підтримати нормальний хід виконання прграми
Для створення стійкого до відмов ПЗ необхідно побудувати компоненти обробки помилок та обробки виключень, аби потім їх можна було поєднати з іншими компонентами, що складають паралельні додатки.
Відновлення та корекція працездатності додатків
запит користувачу повторного вводу даних, повторна обробка файлів, повернення із бази даних, зміна мережевого маршруту, повторна ініціалізація приладів, перезавантаження підсистеми ПЗ тощо.
Діаграми подій
Обробку виключних ситуацій необхідно використовувати як «останню лінію оборони», оскільки її механізм суттєво змінює природну передачу управління в програмі. Для полегшення ідентифікації компонентів системи, які критичні для коректного завершення роботи ПЗ використовують діаграми подій.
Діаграми подій дозволяють зрозуміти які компоненти потенційно не небезпечні, а які можуть призвести до відмови системи. В багатьох ситуаціях відмова одного із компонентів не обов’язково призводить до відмови всієї системи. Для забезпечення безвідмовної роботи системи вцілому, методи обробки виключень можна використовувати в поєднанні із методами обробки помилок.
Система складається із семи задач (літера + перемикач). Якщо перемикачі закриті - компонент функціонує, якщо ні - то не функціонує. Для успішного завершення програми необхідно знайти шлях через діючі компоненти.
Якщо буде відмова в задачах А чи С, то програма згенерує виключення. І аналогічно по іншим гілкам. Проте видно, що завершення програми буде успішним, якщо буде успішним виконання хоча б однієї з гілок. Тому слід проектувати обробник виключень таким чином, аби він виконував один зі альтернативних наборів компонентів.
Зв’язність та зв’язаність (coupling and cohesion)
Зв'язаність (англ. couplіng) або залежність (англ. dependency) - характеристика взаємозв'язку модуля з іншими модулями.
Це ступінь, у якій кожен програмний модуль покладається на інші модулі.
Зв'язаність звичайно протиставляється зв'язності (англ. cohesіon). Слабка зв'язаність часто сполучається із сильною зв'язністі й навпаки. Метрика якості ПО зв'язаності й зв'язності була придумана Larry Constantіne
Зв'язаність вмісту (висока)
Зв'язаність вмісту це коли один модуль змінює або покладається на внутрішню структуру іншого модуля (наприклад, доступ до локальних даних іншого модуля).
Загальна зв'язаність це коли два модулі ділять між собою той самий глобальний набір даних (наприклад, глобальну змінну).
Зовнішня зв'язаність виникає коли два модулі ділять між собою певний ззовні формат даних, протокол зв'язку, або інтерфейс пристрою. Це звичайно засновано на комунікації із зовнішніми засобами й пристроями.
Зв'язаність керування це коли один модуль управляє виконанням іншого шляхом передачі йому інформації із приводу того, що робити (наприклад, передачею прапора "що^-потрібний^-зробити").
Зв'язаність по відбитку в структурі даних (stamp couplіng)
Це коли модулі ділять між собою складену структуру даних, і кожний використають тільки її частину, по можливості навіть не ту ж саму частину (наприклад, передача повної структури у функцію, який потрібно тільки одне поле цієї структури).
Зв'язаність даних це коли модулі ділять загальні дані через, скажемо, параметри. Кожна порція даних це елементарний фрагмент, і це тільки ті дані, які використаються спільно (наприклад, передача цілого числа функції, що обчислює квадратний корінь).
Зв'язаність повідомлень (низька)
Це найслабший тип зв'язаності. Він може бути досягнуть децентралізацією станів (як в об'єктах) і комунікацією компонентів через параметри або передачу повідомлень
Немає зв'язаності
Модулі не спілкуються меду собою зовсім.