Середовище розробки

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

Компілятор мови є складовою частиною СП. Сама програма разом з конструкціями передбаченими стандартом як правило використовує бібліотечні функції і класи, які надає СП. Наприклад, інтегроване середовище розробки VisualStudio.NET містить бібліотеку класів MFC (Microsoft Foundation Classes), використання якої значно спрощує процес розробки застосувань з розвиненим віконним інтерфейсом. Вона дозволяє створювати та компілювати застосування на мовах C++, C#, Visual Basic и VisualJ.

1.7. Тестування і верифікація програм

Всі знають, що в програмах бувають помилки (bugs). Існують спеціальні теорії, присвячені тому, як краще їх знаходити і виправляти (debugging дослівно означає <<виведення клопів>>). Найчастіше знаходження помилки - дуже нетривіальне завдання, так як її наслідки можуть позначатися зовсім в іншому місці програми і бути досить несподіваними.

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

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

Задача 1.2. Задача про банку з зернятами кофе. У банці знаходяться декілька чорних і білих зернят кофе. Повторіть наступні дії поки це буде можливо:

· Випадково виберіть із банки два зернята і

o Якщо вони одного кольору, відкиньте їх, але положіть у банку нове чорне зернятко (зернят поза банкою достатньо);

o Якщо вони різного кольору, поверніть у банку взяте біле зернятко і відкиньте чорне;

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

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

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

Інваріант циклу - це предикат, що володіє деякими спеціальними властивостями.

Запропонуйте розв’язок цієї задачі.

Тепер розглянемо питання про те, наскільки складно протестувати вже написану програму. Будемо припускати для простоти, що для лінійної програми (без розгалужень) достатньо всього одного теста, для програми з одним оператором if - двох (щоб протестувати правильність кожної з його гілок) і так далі.

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

Та все ж, повернемося до нашої моделі. Якщо в програмі 10 операторів if, то потрібно виконати тестів, а якщо їх 20, то вже ! Чи можна сподіватися на те, що в процесі тестування реальної великої програми вдасться перевірити всі можливі варіанти її роботи? Ні, звичайно. Саме тому так важливо не робити помилок, тому що потім їх швидше за все просто не знайти.

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

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

Таблиця 7.1: Ймовірність правильної роботи програми, яка містить розгалужень
N
P	0.904	0.366	0.00004

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

Лекція 2.

АЛГОРИТМИ І ОБЧИСЛЕННЯ