2.1.7. Перевірка програми

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

Нарешті всі знайдені помилки виправлені і програму можна прогнати на простому прикладі (такому, котрий може бути перевірений вручну). Що ж далі?

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

Як же вибрати вхідні дані для тестування? На це питання неможливо дати однозначної відповіді. Для будь-якого алгоритму відповідь залежить від складності програми і наявного ресурсу часу. Звичайно множина можливих вхідних даних величезна, і для повна перевірки немає можливості. Тому нам необхідно вибрати таку сукупність вхідних даних, що дозволить перевірити кожну ділянку програми. Обов'язково треба перевірити досить точно випадки, що з великою ймовірністю зустрінуться в практиці. Майже ніколи не можна гарантувати повну правильність програми, але ми завжди можемо і зобов'язані провести відповідну перевірку, щоб бути досить упевненими в цьому.

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

2.1.8. Документація

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

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

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

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

І, нарешті, дозвольте дати вам пораду: виберіть свій чіткий і зрозумілий стиль написання програм і користайтеся тільки ним. Оформляйте все так, щоб вам було приємно читати це.

2.2. Типи задач

Явище, процес, предмет, об'єкт (далі будемо говорити об'єкт), з яким людині приходиться зіштовхуватися у своїй життєдіяльності, має різні властивості, параметрами в характеристиками. Далеко не завжди ці властивості відомі чи явно виражені, що не дозволяє використовувати об'єкт у практичних цілях. Крім того, у різних предметних областях той самий об'єкт розглядається з різних позицій, що вимагає виявлення специфічних, характерних тільки для цієї області параметрів і властивостей. У книзі "Введение в кибернетику" У. Росс Ейбі відзначав, що "реальний маятник має не тільки довжину і положення, але має також масу, температуру, електропровідність, кристалічну структуру, хімічні домішки, деяку радіоактивність, швидкість, відбиваючу здатність, міцність на розрив, плівку вологи на поверхні, зараженість бактеріями, оптичне поглинання, пружність, контур, питому вагу і т.д. Вимога вивчити "усі" ці факти нездійсненна. Нам необхідно вибрати і вивчити факти, що представляють для нас інтерес з погляду визначеної, заздалегідь зазначеної "мети".

Це важливе методологічне зауваження, що стосується широкого спектра діяльності людини. Його можна (і потрібно) віднести до всього процесу підготовки і розв'язання задач із застосуванням ЕОМ. Ці задачі відрізняються тим, що інформація про об'єкти, що породжують подібні задачі, представляється кількісними параметрами, властивостями, характеристиками і якісними ознаками, між якими є цілком виражені взаємозв'язки і відносини, хоча вони, що цілком природно, можуть бути і невідомими. Розв'язання задачі спрямовано на виявлення параметрів, властивостей об'єкта відносин, що робить цей об'єкт корисним, дозволяє використовувати його на практиці.

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

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

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

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

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