Технології програмування

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

“Якщо розміру великої програми поставити у відповідність час, який необхідний для її реалізації, та кількість зайнятих у ній програмістів, то виявиться, що все відбувається так, наче кожен програміст створює 5 команд за день, а решта часу пише команди, які потім визнаються не потрібними або неправильними” [1].

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

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

Процедурна мовавказує, як виконується дія. Непроцедурна мовавказує, яка дія виконується, але без деталізації– як це робиться. Отже, мови типу PL/1, FORTRAN, Pascal, Cє процедурними.

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

За останнє десятиліття сформувався новий напрям у програмуванні – CASE(Computer-Aided Software System Engineering – автоматизоване проектування програмного забезпечення) та системи RAD-программирования (Rapid Application Development – швидка розробка додатків). Дуже грубо, CASE–технологія являє сукупність методологій аналізу, проектування, розробки та супроводу складних систем програмного забезпечення, яка підтримується комплексом взаємопов’язаних засобів автоматизації. CASE – це інструментарій для системних аналітиків, розробників та програмістів для автоматизації процесу проектування та розробки всіх етапів ПЗ.

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

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

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

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

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

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

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