Теоретичні відомості

Наприкінці 60-х - початку 70-х років минулого століття відбулася подія, що увійшла в історію як перша криза програмування. Подія полягало в тому, що вартість програмного забезпечення стала наближатися до вартості апаратури («заліза»), а динаміка зростання цих вартостей дозволяла прогнозувати, що до середини 90-х років все людство буде займатися розробкою програм для комп'ютерів. Тоді й заговорили про програмної інженерії (або технології програмування, як це називалося в Росії) як про певну дисципліну, метою якої є скорочення вартості програм.

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

2.1. Повторне використання коду (модульне програмування)

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

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

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

Для її рішення розробляються спеціальні форми (структури) подання моду-лий та організації їх інтерфейсів.

2.2. Зростання складності програм (структурне програмування)

Проблема. Наступний етап зростання вартості ПО був пов'язаний з переходом від розробки відносно простих програм до розробки складних програмних комплексів. До числа таких складних програм будь-яка система управління космічними об'єктами, управління оборонним комплексом, автоматизації великого фінансового установи і т.д. Складність таких комплексів оцінювалася наступними показниками:

1. Великий об'єм коду (мільйони рядків)

2. Велика кількість зв'язків між елементами коду

3. Велика кількість розробників (сотні осіб)

4. Велика кількість користувачів (сотні і тисячі)

5. Тривалий час використання

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

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

1. Спадний функціональне проектування, при якому в системі виділяються основні функціональні підсистеми, які потім розбиваються на підсистеми і т.д. (Принцип «розділяй і володарюй»)

2. Застосування спеціальних мов проектування і засобів автоматизації використання цих мов

3. Дисципліна проектування та розробки: планування та документування проекту, підтримка відповідність коду проектної документації

4. Структурний кодування без goto