НОУ ІНТУІТ, Лекція, Якість ПЗ

Стійкість (Robustness)

Стійкість - це здатність ПЗ відповідним чином реагувати на аварійні ситуації.

Стійкість доповнює коректність. Коректність відноситься до поведінки системи у випадках, визначених специфікацією; стійкість характеризує те, що відбувається поза цією специфікацією.

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

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

Термін "нормальний" у цьому сенсі не означає "бажаний", а просто "запланований у проекті ПЗ". Хоча на перший погляд може здатися парадоксальним, що помилкове введення може називатися нормальним випадком, будь-який інший підхід спирається на суб'єктивні критерії і, таким чином, марний.

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

Розширюваність (Extendibility)

Розширюваність - це легкість адаптації до змін специфікації.

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

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

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

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

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

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

Повторне використання (Reusability)

Визначення: повторне використання

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

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

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

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

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

Сумісність (Compatibility)

Сумісність - це легкість поєднання одних елементів з іншими.

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

Ключ до сумісності знаходиться в однорідності побудови та стандартних угодах на комунікації між програмами. Ці підходи включають:

Стандартні формати файлів, як у системі Unix, де кожен текстовий файл - це послідовність символів.
Стандартні структури даних, як у системі Lisp, де всі дані, і навіть програми, представлені бінарними деревами (названими списками).
Стандартні інтерфейси користувача, як у різних версіях Windows, OS/2 і MacOS, де всі інструменти спираються на єдину парадигму для комунікації з користувачем, засновану на стандартних компонентах, таких як вікна, значки, меню і т.д.

Велика спільність досягається щодо стандартних протоколів доступу всім важливим елементам, керованим програмами. Такою є ідея, що лежить в основі абстрактних типів даних та ГО-підходу, а також так званого сполучногопрограмного забезпечення ( middleware ), наприклад CORBA та Microsoft's OLE-COM (ActiveX).