- Перший етап – “ стихійне ” програмування.
- Другий етап – структурний підхід до програмування (60 – 70 роки ХХ ст.).
- Третій етап – об’єктний підхід до програмування (з середини 80-х до кінця 90-х років ХХ ст.).
- Четвертий етап – компонентний підхід і CASE-технології (з середини 90-х років ХХ ст. до нашого часу).
Програмне забезпечення
 Скачать 1.46 Mb.
|
|
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ
Щоб розібратись в сучасних технологіях програмування і визначити основні тенденції їх розвитку, доцільно розглядати ці технології в історичному контексті, виділяючи основні етапи розвитку програмування як науки. Перший етап – “стихійне” програмування. Цей етап охоплює період від моменту появи перших обчислювальних машин до середини 60-их років ХХ ст. В цей період практично були відсутні сформульовані технології і програмування фактично було мистецтвом. Перші програми мали просту структуру. Вони складалися власне із програми на машинній мові та даних що нею оброблялися (рис 1.1). Складність програм в машинних кодах обмежувалась здатністю програміста одночасно відслідковувати послідовність виконуваних операцій та місцезнаходження даних при програмуванні.  Рис. 1.1. Структура перших програм Поява асемблерів дозволило замість двійкових чи 16-их кодів використовувати символьні імена даних і мнемоніки кодів операцій. В результаті програми стали більш “читабельні”. Створення мов програмування високого рівня, таких як FORTRAN і ALGOL, суттєво спростило програмування обчислень, знизивши рівень деталізації операцій. Це, в свою чергу, дозволило збільшити складність програм. Революційною була поява в мовах засобів, що дозволяють оперувати підпрограмами. (Ідея написання підпрограм з’явилася значно раніше, але відсутність засобів підтримки в перших мовних засобах суттєво знижувала ефективність їх використання). Підпрограми можна було зберігати і використовувати в інших програмах. В результаті були створені величезні бібліотеки розрахункових та службових програм, які по мірі необхідності викликались з програми що розробляється. Типова програма того часу складалася із основної програми, області глобальних даних і набору підпрограм (в основному бібліотечних), які виконували обробку всіх даних або частини їх (рис. 1.2).  Рис. 1.2. Архітектура програми з глобальною областю даних Слабим місцем такої архітектури було те, що при збільшенні кількості підпрограм виростала ймовірність спотворення частини глобальних даних якоюсь підпрограмою. Наприклад, підпрограма пошуку коренів рівняння на заданому відрізку методом поділу відрізка пополам змінює величину інтервалу. Якщо при виході з підпрограми не передбачити відновлення початкового інтервалу, то в глобальній області виявиться неправильне значення інтервалу. Щоб скоротити число таких помилок в підпрограмах , було запропоновано розміщувати локальні дані (рис. 1.3).  Рис. 1.3. Архітектура програми, яка використовує підпрограми з локальними даними Складність програмного забезпечення з використанням підпрограм з локальними даними обмежувалась здатністю програміста відслідковувати процеси обробки даних, але вже на новому рівні. Однак, поява засобів підтримки підпрограм дозволило виконувати розробку програмного забезпечення декільком програмістам паралельно. На початку 60-их років ХХ ст. розпочалась “криза програмування”. Вона виражалася в тому, що фірми, які взялися за розробку складного програмного забезпечення, такого як операційні системи, зривали всі строки завершення проектів. Проект застарівав раніше, ніж був готовий до впровадження, збільшувалась його вартість, і в результаті багато проектів так і не були завершені. Об’єктивно все це було викликано недосконалістю технології програмування. Насамперед стихійно використовувалась розробка “знизу–вверх” – підхід, при якому спочатку проектували і реалізовували порівняно прості підпрограми, з яких потім пробували скласти складну програму. При відсутності чітких моделей описання підпрограм і методів їх проектування створення кожної підпрограми перетворювалось в непросту задачу, інтерфейси підпрограм були складними, і при зборці програмного продукту виявлялась велика кількість помилок узгоджуваності. Виправлення таких помилок, як правило, вимагало серйозної зміни вже розроблених підпрограм, що ще більше ускладнювало ситуацію, так як при цьому часто вносили нові помилки, які також потрібно було виправляти. Таким чмном процес тестування і відладки програм займав більше 80 % часу розробки, якщо, звичайно, взагалі закінчувався. Найважливішим було питання розробки технології створення складних програмних продуктів, яка знижує ймовірність помилок проектування. Аналіз причин виникнення більшості помилок дозволив сформулювати новий підхід до програмування, який був названий “структурним”. Другий етап – структурний підхід до програмування (60 – 70 роки ХХ ст.). Структурний підхід до програмування представляє собою сукупність технологічних прийомів, що охоплюють виконання всіх етапів розробки програмного забезпечення. В основі структурного підходу лежить декомпозиція (розбиття на частини) складних систем з ціллю наступної реалізації у вигляді окремих невеликих (ло 40–50 операторів) підпрограм. З появою інших принципів декомпозиції (об’єктного, логічного і т.д.) даний спосіб отримав назву процедурної декомпозиції. На відміну від раніше використовуваного процедурного підходу до декомпозиції, структурний підхід вимагав представлення задачі у вигляді ієрархії підзадач простої структури. Проектування таким чином відбувалось “зверху–вниз” і мало на увазі реалізацію загальної ідеї, забезпечуючи проробку інтерфейсів підпрограм. Одночасно вводились обмеження на конструкції алгоритмів, рекомендувались формальні моделі їх описання, а також спеціальний метод проектування алгоритмів – метод покрокової деталізації. Підтримка принципів структурного програмування була закладена в основу так званих процедурних мов програмування. Як правило вони включали основні “структурні” оператори передачі керування, підтримували вкладання підпрограм, локалізацію і обмеження області “видимості” даних. Серед найбільш відомих мов цієї групи варто назвати PL/1, ALGOL-68, Pascal, C. Одночасно зі структурним програмуванням з’явилась велика кількість мов, що базуються на інших концепціях, але більшість із них не витримали конкуренції. Деякі мови були просто забуті, ідеї інших були в майбутньому використані в наступних версіях мов які розвиваються. Подальше збільшення складності і розмірів програмного забезпечення вимагало розвитку структурування даних. В наслідок цього в мовах з’являється можливість визначення користувацьких типів даних. Одночасно збільшилось бажання розмежувати доступ до глобальних даних програми, щоб зменшити кількість помилок, що виникають при роботі з глобальними даними. В результаті появилась і почала розвиватись технологія модульного програмування. Модульне програмування пропонує виділення груп підпрограм, що використовують одні і ті ж глобальні дані в окремі модулі (бібліотеки підпрограм), наприклад модуль графічних ресурсів, модуль підпрограм виводу на принтер (рис. 1.4). Зв’язки між модулями при використанні даної технології виконуються через спеціальний інтерфейс, в той час як доступ до реалізації модуля (до тіл підпрограм і деяким “внутрішнім” змінним) заборонений. Цю технологію підтримують сучасні версії мов Pascal і C(C++), мови Ада і Modula.  Модулі з локальними даними і підпрограмами Рис. 1.4. Архітектура програми яка складається з модулів Використання модульного програмування суттєво спростило розробку програмного забезпечення декількома програмістами. Тепер кожен із них міг розробляти свої модулі незалежно, забезпечуючи взаємодію модулів через спеціально домовлені міжмодульні інтерфейси. Крім того, модулі в майбутньому без змін можна використовувати в інших розробках, що підвищило продуктивність праці програміста. Практика показала, що структурний підхід разом із модульним програмуванням дозволяє отримувати достатньо надійні програми, розмір котрих не перевищує 100000 операторів. Вузьким місцем модульного програмування є те, що помилка в інтерфейсі при виклиці підпрограми виявляється тільки при виконанні програми (із-за роздільної компіляції модулів знайти помилки раніше неможливо). При збільшенні розміру програми звичайно виростає складність модульних інтерфейсів, і з певного моменту передбачити взаємодію окремих частин програми стає практично неможливо. Для розробки програмного забезпечення великого об’єму було запропоновано використовувати об’єктний підхід. Третій етап – об’єктний підхід до програмування (з середини 80-х до кінця 90-х років ХХ ст.). Об’єктно-орієнтоване програмування визначається як технологія створення складного програмного забезпечення, основана на представленні програми у вигляді сукупності об’єктів, кожен із яких є екземпляром визначеного типу (класу), а класи утворюють ієрархію з унаслідуванням властивостей. Взаємодія програмних об’єктів в такій системі відбувається шляхом передачі повідомлень (рис. 1.5).  Рис. 1.5. Архітектура програми при об’єктно-орієнтованому підході Об’єктна структура програми вперше була використана у мові імітаційного моделювання складних систем Simula, яка виникла ще в 60-х роках ХХ ст. Такий спосіб представлення програми отримав розвиток у спеціалізованій мові моделювання Smalltalk (70-ті роки ХХ ст.), а потім був використаний в нових версіях універсальних мов програмування, таких як Pascal, C++, Modula, Java. Основною перевагою об’єктно-орієнтованого програмування порівняно з модульним програмуванням є “більш натуральна” декомпозиція програмного забезпечення, яка суттєво полегшує розробку. Це призводить до більш повної локалізації даних та інтегрування їх з програмами обробки, що дозволяє вести практично незалежну розробку окремих частин (об’єктів) програми. Крім того, об’єктний підхід пропонує нові способи організації програм, основані на механізмах наслідування, поліформізма, композиції, наповнення. Ці механізми дозволяють конструювати складні об’єкти з порівняно простих. В результаті чуттєво збільшується показник повторного використання кодів і з’являється можливість створення бібліотек класів для різних застосувань. Бурний розвиток технологій програмування, в основі яких лежить об’єктний підхід, дозволив розв’язати багато проблем. Так, були створені середовища, які підтримують візуальне програмування, наприклад Delphi, C++ Builder, Visual C++ і т.д. При використанні візуального середовища у програміста з’являється можливість проектувати деяку частину, наприклад інтерфейси майбутнього продукту, з використанням візуальних засобів додавання і налаштування спеціальних бібліотечних компонентів. Результатом візуального проектування є заготовка майбутньої програми, в яку вже внесені відповідні коди. Використання об’єктного підходу має багато переваг, однак його конкретна реалізація в об’єктно-орієнтованих мовах програмування, таких як Pascal і C++, має суттєві недоліки: 1) фактично відсутні стандарти компоновки двійкових результатів компіляції об’єктів в єдине ціле, навіть в межах однієї мови програмування. Компоновка об’єктів отриманих різними компіляторами C++, у кращому випадку проблематична, що призводить до необхідності розробки програмного забезпечення з використанням засобів і можливостей однієї мови програмування високого рівня і одного компілятора, а отже, вимагає наявності вихідних кодів бібліотек класів, що використовуються; 2) зміна реалізації одного з програмних об’єктів, як мінімум, пов’язане з перекомпіляцією відповідного модуля і пере компоновкою всього програмного забезпечення, яке використовує даний об’єкт. Таким чином, при використанні цих мов програмування зберігається залежність модулів програмного забезпечення від адресів експортуючих полів та методів, а також структур і форматів даних. Ця залежність об’єктивна, так як модулі повинні взаємодіяти між собою, звертаючись до ресурсів один одного. Зв’язки модулів неможливо розірвати, але можна попробувати стандартизувати їх взаємодію, на цьому і оснований компонентний підхід до програмування. Четвертий етап – компонентний підхід і CASE-технології (з середини 90-х років ХХ ст. до нашого часу). Компонентний підхід пропонує побудову програмного забезпечення з окремих компонентів фізично окремо існуючих частин програмного забезпечення, які взаємодіють між собою через стандартизовані двійкові інтерфейси. На відміну від звичайних об’єктів об’єкти-компоненти можна збирати в динамічні бібліотеки або файли які виконуються, розповсюджувати в двійковому коді (без початкових текстів) і використовувати в будь-якій мові програмування, що підтримує відповідну технологію. На сьогоднішній день ринок об’єктів став реальністю, так, в Інтернеті існують вузли, які представляють велику кількість компонентів, реклами компонентів в журналах. Це дозволяє програмістам створювати продукти, які хоча б частково складаються з повторно використаних частин, тобто використати технологію, яка добре зарекомендувала себе в області проектування апаратури. Компонентний підхід лежить в основі технологій, розроблених на базі COM (Component Object Model – компонентна модель об’єктів), і технології створення розподілених додатків CORBA (Common Object Request Broker Architecture – загальна архітектура з посередником обробки запитів об’єктів). Ці технології використовують схожі принципи і розрізняються лише особливостями їх реалізації. Технологія COM фірми Microsoft є розвитком технології OLE (Object Linking and Embedding – зв’язування та внедрение об’єктів), яка використовувалась в ранніх версіях Windows для створення складових документів. Технологія COM визначає загальну парадигму взаємодії програм довільних типів: бібліотек, додатків, операційної системи, тобто дозволяє одній частині програмного забезпечення використовувати функції (служби), що надаються іншою, незалежно від того чи функціонують ці частини в межах одного процесу, в різних процесах на одному комп’ютері чи на різних комп’ютерах (рис. 1.6). Модифікація COM, забезпечує передачу викликів між комп’ютерами, називається DCOM (Distributed COM – розподілена COM).  Рис. 1.6. Взаємодія програмних компонентів різних типів По технології COM додаток надає свої служби, використовуючи спеціальні об’єкти – об’єкти COM, які є екземплярами класів COM. Об’єкт COM так як і звичайний об’єкт має поля і методи, але на відміну від звичайних об’єктів кожний об’єкт COM може реалізовувати декілька інтерфейсів, що забезпечують доступ до його полів і функцій. Це досягається за рахунок організації окремої таблиці адресів методів для кожного інтерфейсу (по типу таблиць віртуальних методів). При цьому інтерфейс звичайно об’єднує декілька однотипних функцій. Крім того, класи COM підтримують унаслідування інтерфейсів, але не підтримують наслідування реалізації, тобто не наслідують код методів, хоча при необхідності об’єкт дочірнього класу може викликати метод батьківського. Кожен інтерфейс має своє ім’я, яке починається з літери “I”, і глобальний унікальний ідентифікатор IDD (Interface IDentifier). Будь-який об’єкт COM обов’язково реалізує інтерфейс IUnknown (на схемах цей інтерфейс завжди розміщують зверху). Використання цього інтерфейсу дозволяє отримати доступ до інших інтерфейсів об’єкта. Об’єкт завжди функціонує у складі сервера – динамічної бібліотеки або виконуваного файлу, які забезпечують функціонування об’єкта. Розрізняють три типи серверів: 1) внутрішній сервер; реалізується динамічними бібліотеками, які підключаються до додатка-кліента і працюють в спільному адресному просторі, найбільш ефективний сервер, крім того він не вимагає спеціальних ресурсів; 2) локальний сервер; створюється окремим процесом (модулем, ехе), який працює на одному комп’ютері з клієнтом; 3) віддалений сервер; створюється процесом, який працює на іншому комп’ютері. Наприклад, Microsoft Word є локальним сервером. Він включає багато об’єктів, які можуть використовуватись іншими додатками. Для звернення до служб клієнт повинен отримати вказівник на відповідний інтерфейс. Перед першим зверненням до об’єкта клієнт посилає запит до бібліотеки COM, що містить інформацію про всі зареєстровані в системі класи COM об’єктів, і передає їй ім’я класу, ідентифікатор інтерфейсу і тип сервера. Бібліотека запускає необхідний сервер, створює необхідні об’єкти і повертає вказівники на об’єкти та інтерфейси. Отримавши вказівники, клієнт може викликати необхідні функції об’єкта. Взаємодія клієнта і сервера забезпечується базовими механізмами COM або DCOM, тому клієнту неважливе місцезнаходження об’єкта. При використанні локальних і віддалених серверів в адресному просторі клієнта створюється proxy-об’єкт замісник об’єкта COM, а в адресному просторі сервера COM – заглушка, відповідна клієнту. Отримавши завдання від клієнта, замісник упаковує його параметри і, використовуючи служби операційної системи, передає виклик заглушці. Заглушка розпаковує завдання і передає його об’єкту COM. Результат повертається клієнту у зворотному порядку. На базі технології COM та її розподіленої версії DCOM були розроблені компонентні технології, які розв’язують різні задачі розробки програмного забезпечення. OLE-automation або просто Automation (автоматизація) – технологія створення додатків, які програмуються, та забезпечує програмуючий доступ до внутрішніх служб цих додатків. Вводить поняття диспінтерфейсу (dispinterface) – спеціального інтерфейсу, який полегшує виклик функцій об’єкта. Цю технологію підтримує, наприклад Microsoft Excel, надаючи іншим додаткам свої служби. ActiveX – технологія, побудована на базі OLE-automation, призначена для створення програмного забезпечення, як зосередженого на одному комп’ютері, так і розподіленого в мережі. Передбачає використання візуального програмування для створення компонентів – елементів управління ActiveX. Отримані таким чином елементи управління можна встановлювати на комп’ютер дистанційно з віддаленого сервера, причому код залежить від операційної системи що використовується. Це дозволяє використовувати елементи управління ActiveX в клієнтських частинах додатків Інтернету. Основними перевагами технології ActiveX, які забезпечують їй широке використання, є: 1) швидке написання програмного коду, оскільки всі дії, пов’язані з організацією взаємодії сервера та клієнта, беруться на програмне забезпечення COM, програмування мережевих додатків стає схожим на програмування для окремого комп’ютера; 2) відкритість та мобільність – специфікації технології недавно були передані в Open Group як основа відкритого стандарту; 3) можливість написання додатків з використанням знайомих засобів розробки, наприклад Visual Basic, Visual C++, Borland Delphi, Borland C++ та будь-яких засобів розробки на Java; 4) велика кількість уже існуючих безкоштовних програмних елементів ActiveX (до того ж практично будь-який програмний компонент OLE сумісний з технологіями ActiveX і може використовуватись без модифікацій в мережевих додатках); 5) стандартність – технологія ActiveX основана на стандартах Інтернет (TCP/IP, HTML, Java), з одного боку, і стандартах введених в свій час Microsoft і необхідних для збереження сумісності (COM, OLE). MTS (Microsoft Transaction Server – сервер управління трансакціями) – технологія, що забезпечує безпеку і стабільну роботу розподілених додатків при великих об’ємах даних які передаються. MIDAS (Multitier Distributed Application Server – сервер багатоланкових розподілених додатків) – технологія, яка організовує доступ до даних різних комп’ютерів з врахуванням балансування навантаження мережі. Всі вказані технології реалізують компонентний підхід, закладений в COM. Так, з точки зору COM елемент управління ActiveX – “чорний ящик”, який володіє властивостями, методами та подіями, який можна використовувати як будівельний блок при створенні додатків. Технологія CORBA, розроблена групою компаній OMC (Object Management Group – група впровадження об’єктної технології програмування), реалізують підхід, аналогічний COM, на базі об’єктів та інтерфейсів CORBA. Програмне ядро CORBA реалізовано для всіх апаратних і програмних платформ, і тому цю технологію можливо використовувати для створення розподіленого програмного забезпечення в гетерогенному (різнорідному) обчислювальному середовищі. Організація взаємодії між об’єктами клієнта і сервера в CORBA здійснюється за допомогою спеціального посередника названого VisiBroker, та іншого спеціалізованого програмного забезпечення. Особливістю сучасного етапу розвитку технології програмування, крім зміни підходу, є створення та супроводження програмного забезпечення, які були названі CASE-технології (Computer-Aided Software/System Engineering – розробка програмного забезпечення програмних систем з використанням комп’ютерної підтримки). Без засобів автоматизації розробка достатньо складного програмного забезпечення на сучасний момент стає тяжко реалізованою задачею: пам’ять людини вже не в стані фіксувати всі деталі, які необхідно враховувати при розробці програмного забезпечення. На сьогодні існують CASE-технології, які підтримують як структурний, так і об’єктний (у тому числі і компонентний) підходи до програмування. Поява нового підходу не означає, що все програмне забезпечення буде створюватись з програмних компонентів, але аналіз існуючих проблем розробки складного програмного забезпечення показує, що він буде використовуватись досить широко. |