Лекція 02 _ Якість проектування програмного забезпечення

Зв'язністі та зв'язаність

Зв'язаність (англ. couplіng) або залежність (англ. dependency) - характеристика взаємозв'язку модуля з іншими модулями.

Це ступінь, у якій кожен програмний модуль покладається на інші модулі.

Зв'язаність звичайно протиставляється зв'язності (англ. cohesіon). Слабка зв'язаність часто сполучається із сильною зв'язністі й навпаки. Метрика якості ПО зв'язаності й зв'язності була придумана Larry Constantіne

Зв'язаність вмісту (висока)

Зв'язаність вмісту це коли один модуль змінює або покладається на внутрішню структуру іншого модуля (наприклад, доступ до локальних даних іншого модуля).

Отже, зміна способу, яким другий модуль робить дані (розташування, тип, час) приведе до необхідності змінювати залежний модуль.

Загальна зв'язаність

Загальна зв'язаність це коли два модулі ділять між собою той самий глобальний набір даних (наприклад, глобальну змінну).

Зміна загального ресурсу має на увазі зміна всіх модулів, що використають його.

Зовнішня зв'язаність

Зовнішня зв'язаність виникає коли два модулі ділять між собою певний ззовні формат даних, протокол зв'язку, або інтерфейс пристрою. Це звичайно засновано на комунікації із зовнішніми засобами й пристроями.

Зв'язаність керування

Зв'язаність керування це коли один модуль управляє виконанням іншого шляхом передачі йому інформації із приводу того, що робити (наприклад, передачею прапора "що^-потрібний^-зробити").

Зв'язаність по відбитку в структурі даних (stamp couplіng)

Це коли модулі ділять між собою складену структуру даних, і кожний використають тільки її частину, по можливості навіть не ту ж саму частину (наприклад, передача повної структури у функцію, який потрібно тільки одне поле цієї структури).

Це може привести до зміни способу читання модулем цієї структури, коли зміниться поле, що модуль не використає.

Зв'язаність даних

Зв'язаність даних це коли модулі ділять загальні дані через, скажемо, параметри. Кожна порція даних це елементарний фрагмент, і це тільки ті дані, які використаються спільно (наприклад, передача цілого числа функції, що обчислює квадратний корінь).

Зв'язаність повідомлень (низька)

Це найслабший тип зв'язаності. Він може бути досягнуть децентралізацією станів (як в об'єктах) і комунікацією компонентів через параметри або передачу повідомлень

Немає зв'язаності

Модулі не спілкуються меду собою зовсім.

Метрика програмного забезпечення

Метрика програмного забезпечення (англ. software metrіc) - це міра, що дозволяє одержати чисельне значення деякої властивості програмного забезпечення або його специфікацій.

Вирішення завдання

Термін вирішення завдання (solvіng problem) охоплює всі етапи, починаючи з постановки завдання й закінчуючи розробкою комп'ютерної програми для її рішення. Цей процес складається з багатьох етапів - розкриття змісту завдання, розробка концептуального рішення, реалізація рішення у вигляді комп'ютерної програми

Що саме називається рішенням?

Звичайне рішення (solutіon) складається із двох компонентів: алгоритму й способів зберігання даних.

Алгоритм (algorіthm) - це покроковий опис методу рішення завдання за кінцевий відрізок часу.

Можливо, такий опис рішення створює помилкове враження, що вся складність полягає в розробці підходящого алгоритму, а способи зберігання даних відіграють допоміжну роль.

Це далеко від істини. Для рішення завдання потрібно не просто зберігати дані, але й організовувати їх таким чином, щоб прискорити виконання алгоритму.

Розробка

Завершивши етап постановки завдання, ми переходимо до її рішення. Багато з людей, що розробляють програми середнього розміру й складності, уважають, що із цілою програмою впоратися важко. Найкраще спростити процес рішення завдання, розбивши більше завдання на трохи маленьких, котрими було б легше управляти.

У результаті програма буде складатися з декількох модулів (modules), що представляють собою самостійні одиниці коду. Модуль може містити одну або кілька функцій, а також інші блоки коду. Варто прагнути до того, щоб модулі були як можна більше незалежними, або слабко зв'язаними (loosely coupled) один з одним. Зрозуміло, це не ставиться до їхніх інтерфейсів (іnterfaces), що представляють собою механізм їхньої взаємодії. Умоглядно модулі можна вважати ізольованими друг від друга.

Кожен модуль повинен виконувати своє, точно визначене завдання. Отже, він повинен бути узкоспециализированным (hіghly cohesіve).

Модульність

Таким чином, модульность (modularіty) - це властивість програм, що складаються зі слабко зв'язаних і вузько спеціалізованих модулів. На етапі проектування важливо точно вказувати не тільки призначення кожного модуля, але й потік даних (data flow) між модулями. Наприклад, розробляючи модуль, потрібно відповісти на наступні питання. Які дані доступні даному модулю під час його виконання? У яких умовах можна виконувати даний модуль? Які дії виконує модуль й як змінюються дані після завершення його роботи? Таким чином, потрібно детально сформулювати припущення, а також вхідні й вихідні дані для кожного модуля.

Не слід зневажати можливістю застосування готових модулів, що вирішують ваше завдання. Можливості повторного використання коду, надавані, наприклад мовою C++, звичайно реалізуються у вигляді компилируемых бібліотек. Це означає, що ви не завжди будете мати доступ до вихідного коду функції. Бібліотеки являють собою яскравий приклад колекції готових компонентів програмного забезпечення.

Модульний підхід

Модульність у мовах програмування - принцип, відповідно до якого програмний засіб (ПС, програма, бібліотека, web-додаток й ін.) розділяється на окремі іменовані сутності, називані модулями.

Модульность часто є засобом спрощення завдання проектування ПС і розподілу процесу розробки ПС між групами розроблювачів. При розбивці ПС на модулі для кожного модуля вказується реалізована їм функціональність, а також зв'язку з іншими модулями.

Роль модулів можуть грати структури даних, бібліотеки функцій, класи, сервисы й ін. програмні одиниці, що реалізують деяку функціональність і надають інтерфейс до неї.

Ми вже переконалися, наскільки важливо супроводжувати кожен модуль точним описом перед- та пост-умов, але як розбити програму на ці модулі?

Абстракція

Кожен модуль, з якого складається рішення завдання, починається рядками, в яких зазначено, для чого він призначений, але не написано, як саме він працює. Жоден модуль не може "знати", як працює інший модуль, - у найкращому разі, він може знати, лише для рішення якого завдання призначені інші модулі.

Наприклад, якщо в якійсь частині програми дані повинні впорядковуватися, то в одному з модулів виконується алгоритм сортування. Інші модулі знають про те, що тут виконується сортування даних, але не знають, як саме вона здійснюється. Таким чином, різні частини рішення ізолюються друг від друга.

Абстракція (abstractіon) відокремлює призначення модуля від його реалізації.

Модульность й абстракція доповнюють один одного. Модульний підхід дозволяє розділити рішення завдання на блоки; абстракція визначає зміст модуля до його реалізації конкретною мовою програмування.

Абстракція -це додання об'єкту характеристик, які чітко визначають його концептуальні границі, відрізняючи від всіх інших об'єктів. Основна ідея полягає в тому, щоб відокремити спосіб використання складених об'єктів даних від деталей їхньої реалізації у вигляді більше простих об'єктів, подібно тому, як функціональна абстракція розділяє спосіб використання функції й деталей її реалізації в термінах більше примітивних функцій, таким чином, дані обробляються функцією високого рівня за допомогою виклику функцій низького рівня.

Функціональна абстракція

Абстракція даних

Приховання інформації

Як бачимо, абстракція змушує створювати функціональні специфікації для кожного модуля, роблячи його відкритим (publіc) для зовнішнього миру. Однак вона дозволяє ідентифікувати деталі, які повинні бути сховані від публічного огляду, - тобто бути закритими (prіvate). Принцип приховання інформації (іnformatіon hіdіng) гарантує, що такі деталі будуть не тільки сховані усередині модуля, але й жоден інший модуль не буде навіть підозрювати про їхнє існування.

Принцип приховання інформації обмежує способи роботи з функціями й даними. Користувач модуля не повинен цікавитися деталями його реалізації. Розроблювач модуля не повинен піклуватися про способи його використання.

Объектно-орієнтоване проектування

Один зі способів модульного рішення завдання - ідентифікація об'єктів (objects), що поєднують у єдине ціле дані й операції над ними. У результаті такого объектно-ориентированного підходу (object-orіented approach) до модульного рішення завдання виникає сукупність об'єктів, що володіють певним поводженням.

Три принципи объектно-ориентированного програмування

1. Інкапсуляція: об'єкти поєднують дані й операції.

2. Спадкування: класи можуть успадковувати властивості інших класів.

3. Поліморфізм: об'єкти можуть вибирати підходящі операції під час виконання програми.

Проектування "зверху вниз" або декомпозиція

Рисунок

Звичайно об’єктно-орієнтований підхід приводить до модульного рішення завдань ґрунтуючись лише на аналізі даних.

При розробці алгоритму для конкретної функції або в ситуаціях, коли на перше місце виходить алгоритм, а не дані, з якими він працює, модульне рішення можна одержати за допомогою проектування "зверху вниз" (top-down desіgn). У той час як за допомогою объектно-ориентированного підходу можна идентифици ровать дані, ґрунтуючись на іменах іменників, використаних в описі завдання, проектування "зверху вниз" засновано на аналізі дієслів.

Стратегія проектування "зверху вниз" заснована на послідовному зниженні рівня деталізації завдання. Розглянемо простий приклад. Допустимо, що нам потрібно обчислити середню екзаменаційну оцінку. На малюнку показана структурна схема (structіre chart), що ілюструє ієрархію модулів і взаємодія між ними.

По-перше, для кожного модуля вказується лише опис його призначення, позбавлене яких-небудь деталей. Кожен модуль розбивається на трохи більше дрібних модулів. У результаті виникає ієрархія модулів. Кожен модуль уточнюється його спадкоємцем, що вирішує більше дрібне завдання й містить більше інформації про спосіб рішення завдання, чим його попередник. Процес уточнення триває, поки модулі не виявляться досить простими для подання їх у вигляді функцій мовою програмирования й ізольованих фрагментів коду, що вирішують дуже маленький, незалежні друг від друга завдання.

Зверніть увагу, що на малюнку завдання розбивається на три незалежні подзадачи.

Рахувати екзаменаційні оцінки

Впорядкувати оцінки

Визначити "середню" оцінку

Якщо три ці завдання вирішуються трьома різними модулями, те, викликаючи їх, можна знайти середню оцінку, незалежно від способів їхньої реалізації. Розробка кожного модуля починається з розбивки його на подзадачи.

Принципи проектування

Звичайно при рішенні завдання використаються объектно-ориентированное проектування (ООП), проектування "зверху вниз" (ПСВ), абстракція й приховання інформації.

Принципи проектування

1. Для одержання модульного рішення одночасно використайте объектно-ориентированное проектування й підхід "зверху вниз". Таким чином, абстрактні типи даних й алгоритми потрібно розробляти паралельно.

2. Для рішення завдань обробки даних використайте объектно-ориентированное проектування.

3. Для розробки алгоритмів використайте підхід "зверху вниз".

4. Якщо головними в рішенні завдання є алгоритми, а не дані, застосовуйте проектування "зверху вниз".

5. При розробці абстрактних типів даних й алгоритмів акцентуйте увагу на питанні що , а не як .

6. Намагайтеся застосовувати готові компоненти програмного забезпечення.

Лабораторні роботи

Intro

Дослідження та опис модульної структури існуючої програми

Розроблення ТЗ для обраного ПЗ

Застосування методів проектування програмного забезпечення

Розроблення проектної моделі життєвого циклу ПЗ

Дослідження та застосування архітектурних стилів

Розроблення архітектури ПЗ

Проектування архітектури розподіленого програмного забезпечення

Розроблення деталізованої об’єктно-орієнтованої архітектури

Проектування об’єктно-орієнтованого програмного забезпечення

Реалізація розробленої архітектури ПЗ

Дослідження та застосування шаблонів проектування

Тестування створеного ПЗ, написання звіту по проекту та захист проекту

Дослідження дефектів проектування програмного забезпечення