Анотація: Збройні базисними концепціями класу, об'єкта, параметризації ви можете тепер створювати програмні модулі, що реалізують можливо параметризрвані типи структур даних. Мої вітання! Зроблено важливий крок у битві за кращу програмну архітектуру. Але розглянутих методів явно недостатньо для реалізації всеосяжного бачення якості, введеного на початку книги. Фактори якості, на яких було сконцентровано нашу увагу, - повторне використання, розширюваність, сумісність - не повинні досягатися ціною надійності (коректність і стійкість). Хоча концепція надійності проглядалася по ходу обговорення, ми добиваємося більшого.
Базисні механізми надійності
Необхідність приділити більше уваги семантичним властивостям класів стає особливо очевидною, якщо пригадати що клас - це реалізація АТД. Розглянуті досі класи складалися з атрибутів і програм, що реалізують функції специфікації АТД. Але АТД це не просто список операцій. згадайте роль семантичних властивостей, які висловлюються аксіомами і передумов. Вони є основою, що проясняє природу примірників даного типу. У класах ми - тимчасово - втратили цей семантичний аспект концепції АТД. Необхідно повернутися назад, щоб наше ПО було не тільки гнучким і повторно використовуваних, але і коректним і стійким.
Твердження і пов'язані з ними концепції, прояснює в цій лекції, частково дають відповіді. Не будучи повним доказом, представлені нижче механізми постачають програміста основними засобами для формулювання і перевірки аргументів коректності. Ключовий концепцією буде Проектування за контрактом (Design by Contract) - встановлення відносин між класом і його клієнтами у вигляді формальної угоди, недвозначно встановлює права і обов'язки сторін. Тільки через точне визначення для кожного модуля вимог і відповідальності можна сподіватися на досягнення істотному ступені довіри до великих програмних систем.
При огляді концепцій ми вперше зіткнемося з ключовою проблемою програмної інженерії - як впоратися з помилками періоду виконання, що виникають при порушенні контракту. Цій темі - обробці виняткових ситуацій присвячена наступна лекція. Розподіл ролей між двома главами приблизно відображає різницю між двома компонентами надійності: коректністю і стійкістю. Коректність - це можливість ПО виконувати свої завдання у відповідності зі специфікаціями, стійкість - здатність належним чином реагувати на ситуації, що виходять за межі специфікації. Твердження (ця лекція), як правило, покривають коректність. а виключення (наступна лекція) - стійкість.
Деякі важливі розширення основних ідей проектування за контрактом повинні очікувати введення спадкування, поліморфізму і динамічного зв'язування, що дозволить нам перейти від контрактів до видачі субпідрядів.
Технічні прийоми, введені в попередніх лекціях, були спрямовані на створення надійного ПО. Дамо їх короткий огляд - було б марно розглядати більш просунуті концепції до приведення в порядок основних механізмів надійності. Першим і визначальним властивістю об'єктної технології є майже нав'язувана структура програмної системи - проста, модульна, що розширюється, - простіше гарантує надійність. ніж в разі "кривих" структур, що виникають при застосуванні ранніх методів розробки. Зокрема, зусилля щодо обмеження межмодульного взаємодії, зведення його до мінімуму, були в центрі дискусії про модульности. Результатом стала заборона загальних ризиків. знижують надійність. - відмова від глобальних змінних, механізм обмеженого взаємодії модулів, відносини спадкування та вкладеності. Загальний нагляд: найбільший ворог надійності (і якості ПО в цілому) - це складність. Створюючи наші структури настільки простими, наскільки це можливо, ми досягаємо необхідного, але не достатньої умови, що гарантує надійність. Колишнє обговорення служить лише вірною відправною точкою в подальших систематичних зусиллях.
Зауважте, необхідний, але також недостатній, постійний акцент на створення елегантного і читабельною ПО. Програмні тексти не тільки пишуться, вони ще читаються і переписуються по багато разів. Ясність і простота нотації мовних конструкцій - основа будь-якого витонченого підходу до надійності.
Ще одна необхідна зброя - автоматичне керування пам'яттю. особливо прибирання сміття. У лекції, присвяченій цій темі, в деталях пояснено, чому для будь-якої системи, що оперує динамічними структурами даних. настільки небезпечно спиратися на управління цим процесом вручну. Прибирання сміття не розкіш - це ключовий компонент ГО-середовища, що забезпечує надійність.
Теж можна сказати про ще один, що поєднується з параметризацією механізмі, - статичної типізації. Без правил суворої статичної типізації довелося б лише сподіватися на поблажливість численних помилок, що виникають в період виконання.
Всі ці механізми дають необхідну основу для більш повного погляду на те, що слід зробити для забезпечення стійкості і коректності ПЗ.
Про коректності ПЗ
Задамося питанням, що означає твердження - програмний елемент коректний? Спостереження і міркування, що відповідають на це питання, можуть здатися тривіальними. Але, як зауважив один відомий вчений, такі всі наукові результати, - вони починаються з звичайних спостережень і тривають шляхом простих міркувань, але все це потрібно робити завзято і наполегливо.
Припустимо, хтось прийшов до вас з програмою з 300 000 строк на С і питає, коректна вона? Якщо ви консультант, то вибачайте високу плату і дайте відповідь - "ні". Ви, ймовірно, виявитеся праві.
Для того щоб можна було дати розумну відповідь на подібне питання, однієї програми недостатньо, необхідна ще і її специфікація, точно описує, що повинна робити програма. оператор
сам по собі не є ні коректним, ні некоректно. Ці поняття набувають сенс лише по відношенню до очікуваного ефекту присвоювання. Наприклад, присвоювання коректно по відношенню до твердження: "Змінні x і y мають різні значення". Але не гарантується його коректність по відношенню до вислову: "змінна x негативна", оскільки результат привласнення залежить від значення y. яке може бути позитивним.
Ці приклади ілюструють властивість, що служить відправною точкою в обговоренні проблеми коректності: програмна система або її елемент самі по собі ні коректні, ні не коректні. Коректність мається на увазі лише по відношенню до деякої специфікації. Строго кажучи, ми і не будемо обговорювати проблему коректності програмних елементів, а лише їх узгодженість (consistent) із заданою специфікацією. У наших обговореннях ми будемо продовжувати використовувати добре розуміється термін "коректність", але завжди при цьому пам'ятати, що цей термін можна застосувати до програмного елементу, він має сенс лише для пари - "програмний елемент і його специфікація".
Властивість коректності ПЗ
Коректність - поняття відносне.
У цій лекції ми навчимося виражати специфікації через затвердження (assertions). що допоможе оцінити коректність розробленого програмного забезпечення. Але підемо далі і перевернемо проблему, - розробка специфікації є першим, найважливішим кроком на шляху, що гарантує, що ПЗ дійсно відповідає специфікації. Істотну вигоду можна отримати, коли специфікації пишуться одночасно з написанням програми, а краще, до її написання. Серед наслідків такого підходу можна відзначити наступне.
- Розробка ПО коректного з самого початку, що проектується так, щоб бути коректним. Один з творців структурного програмування Харлан Д. Міллс в сімдесяті роки написав статтю зі знаменною назвою "Як писати коректні програми і знати це". Слово "знати" в даному контексті означає забезпечувати програму в момент її написання аргументами, котрі характеризують коректність.
- Значно краще розуміння проблеми і досягнення її рішення.
- Спрощення завдання створення програмної документації. Як буде пізніше показано, затвердження гратимуть важливу роль в ОО-підході до документації.
- Забезпечення основ для систематичного тестування і налагодження.
Частина, що залишилася лекції присвячена дослідженню цих питань. Одне попередження: мови програмування С, С ++ і інші мають оператор затвердження assert. динамічно перевіряючий істинність заданого затвердження в момент виконання програми і зупиняє обчислення. якщо твердження є хибним. Ця концепція, хоча і має відношення до предмету обговорення, але є лише малою частиною використання тверджень в ОО-методі. Тому, якщо подібно до багатьох розробникам ви знайомі з цим оператором, що не узагальнюйте ваше знання на всю картину, майже всі концепції цієї лекції, можливо, будуть новими.