Лекція 1.

НАДІЙНИЙ ПРОГРАМНИЙ ЗАСІБ ЯК ПРОДУКТ ТЕХНОЛОГІЇ ПРОГРАМУВАННЯ. ІСТОРИЧНИЙ І СОЦІАЛЬНИЙ КОНТЕКСТ ПРОГРАМУВАННЯ

План

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

2. Неконструктивність поняття правильної програми.

3. Надійність програмного засобу.

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

5. Технологія програмування і інформатизація суспільства.

6. Перші мови програмування.

7. Області застосування мов програмування.

8. Парадигми програмування.

9. Стандартизація мов програмування.

10. Середовище проектування.

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

Метою програмування є опис процесів обробки даних (надалі  просто процесів). Згідно IFIP [1.1]: дані (data)  це представлення фактів і ідей у формалізованому вигляді, придатному для передачі і переробки в якомусь процесі, а інформація (information) – це зміст, який додається до даних при їх представленні. Обробка даних (data processing) – це виконання систематичної послідовності дій з даними. Дані представляються і зберігаються на т.з. носіях даних. Сукупність носіїв даних, використовуваних при якій-небудь обробці даних, називатимемо інформаційним середовищем (data medium). Набір даних, що містяться в якийсь момент в інформаційному середовищі, називатимемо станом цього інформаційного середовища. Процес можна визначити як послідовність станів деякого інформаційного середовища, що змінюють один одного.

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

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

2. Неконструктивність поняття правильної програми.

Таким чином, можна вважати, що продуктом технології програмування є ПЗ, що містить програми, що виконують необхідні функції. Тут під «програмою» часто розуміють правильну програму, тобто програму, що не містить помилок. Проте, поняття помилки в програмі трактується в середовищі програмістів неоднозначно. Згідно Майерсу [1.2, стор. 10-13] рахуватимемо, що в програмі є помилка, якщо вона не виконує того, що розумно чекати від неї користувачеві. «Розумне очікування» користувача формується на підставі документації по застосуванню цієї програми. Отже, поняття помилки в програмі є істотно не формальним. У ПЗ програми і документації взаємно пов'язані, утворюють деяку цілісність. Тому правильніше говорити про помилку не в програмі, а в ПЗ в цілому: вважатимемо, що в ПЗ є помилка (software error), якщо воно не виконує того, що розумно чекати від нього користувачеві. Зокрема, різновидом помилки в ПЗ є неузгодженість між програмами ПЗ і документацією по їх застосуванню. У роботі [1.3] виділяється в окреме поняття окремий випадок помилки в ПЗ, коли програма не відповідає своїй функціональній специфікації (опису, що розробляється на етапі, попередньому безпосередньому програмуванню). Така помилка у вказаній роботі називається дефектом програми. Проте виділення такого різновиду помилки в окреме поняття навряд чи виправдано, оскільки причиною помилки може виявитися сама функціональна специфікація, а не програма.

Оскільки завдання на ПЗ зазвичай формулюється не формально, а також через те, що поняття помилки в ПЗ не формалізовано, то не можна довести формальними методами (математично) правильність ПЗ. Не можна показати правильність ПЗ і тестуванням: як вказав Дейкстра [1.4], тестування може лише продемонструвати наявність в ПЗ помилки. Тому поняття правильного ПЗ неконструктивно в тому сенсі, що після закінчення роботи над створенням ПЗ ми не зможемо переконатися, що досягли мети.