Однією з головних особливостей є орієнтація ППП не на окреме завдання, а на деякий клас завдань, що включає і специфічні завдання наочної області. Звідси слідує необхідність, модульної організації ППП як основного технологічного принципу його конструювання. Суть цього принципу полягає в оформленні загальних фрагментів використовуваних алгоритмів у вигляді самостійних модулів. Рішення сформульованої користувачем задачі здійснюється деяким "ланцюжком" таких модулів.
Іншою особливістю ППП є наявність в його складі спеціалізованих мовних засобів, що забезпечують зручну роботу користувача з пакетом. Як правило, розвинений пакет володіє декількома вхідними мовами, орієнтованими на виконання різних функцій і різні типи користувачів. Мова може призначатися для формулювання початкового завдання, опису алгоритму рішення і початкових даних, організації доступу і підтримки бази даних або інформаційної бази ППП, розробки програмних модулів, опису моделі наочної області, управління процесом рішення в діалоговому режимі і інших цілей.
Ще одна особливість ППП полягає в наявності спеціальних системних засобів, що забезпечували прийняту в наочній області дисципліну роботи. До їх числа відносяться спеціалізовані банки даних, засобу інформаційного забезпечення, засобу взаємодії пакету з операційною системою і т.п.
Нарешті, інтегрованою програмною системою назвемо комплекс програм, елементами якого є різні пакети і бібліотеки програм. Прикладом служать системи автоматизованого проектування, що мають в своєму складі декілька ППП різного призначення. Часто в подібній системі розв'язуються завдання, що відносяться до різних класів або навіть до різних наочних областей.
Слід вказати на відсутність чітких і однозначних меж між перерахованими формами прикладного програмного забезпечення. Так, окрема прикладна програма, орієнтована на рішення класу завдань і оформлена у вигляді сукупності модулів може розглядатися як бібліотека або навіть пакет програм не дивлячись на відсутність спеціалізованих мовних і системних засобів.
Перехід від створення бібліотек програм до розробки ППП був викликаний цілим рядом причин. До їх числа перш за все відноситься різке збільшення можливостей ЕОМ. Це привело до значного ускладнення системного забезпечення обчислювальних машин. Відбулися істотні зміни в більшості областей застосування ЕОМ.
2.2 СТРУКТУРА І ОСНОВНІ КОМПОНЕНТИ ППП
Не дивлячись на велику різноманітність конкретних пакетних розробок, можна виділити наступні основні компоненти ППП:
- вхідні мови;
- наочне забезпечення;
- системне забезпечення.
Важливо відзначити, що таке розбиття на складові елементи відображає в першу чергу функції, що виконуються програмами ППП, а не структуру самих програм, яка залежить від індивідуальних особливостей конкретного пакету. У різних пакетах вказані компоненти можуть бути розвинені в різному ступені або зовсім бути відсутнім. Проте найбільш розвинені ППП, як правило, володіють всіма цими компонентами, кожний з яких може мати досить складну структуру.
У численних роботах, присвячених пакетній проблематиці, із-за не сталої термінології нерідко використовуються інші назви складових елементів ППП. Наприклад, вхідну мову називають також мовою завдань або мовою управління. Для позначення наочного забезпечення застосовуються терміни "функціональне наповнення", "функціональна підсистема" або "тіло пакету". Системне забезпечення часто називають системним наповненням, організуючою або такою, що управляє програмою, а також процесором пакету.
Розглянемо функції кожного з компонентів ППП.
Вхідні мови є засобом спілкування користувача з пакетом. Як наголошувалося в п. 3.1, розвинений пакет може володіти декількома вхідними мовами, призначеними для виконання різних функцій і орієнтованими на різні типи користувачів. Можна виділити наступні основні типи користувачів ППП:
Розробник ППП, що здійснює його модифікацію і розвиток з урахуванням зміни круга користувачів, класу вирішуваних задач (поява нових типів завдань, розвиток чисельних методів, модифікація форм проведення робіт і т. д.), а також складу апаратного і програмного забезпечення ЕОМ:
Відповідальний за супровід, у функції якого входить підтримка пакету в працездатному стані в умовах конкретної обчислювальної системи (забезпечення збереження програм і масивів даних, своєчасне дублювання інформаційних файлів, виявлення помилок в програмах пакету).
Адміністратор, що відповідає за організацію доступу користувачів до пакету, вміст бази даних, захист інформації від несанкціонованого доступу;
Кінцевий користувач, що застосовує пакет для вирішення конкретних прикладних завдань.
Вхідні мови відображають об'єм і якість засобів, що надаються пакетом, а також зручність їх використання. Таким чином, з погляду кінцевого користувача саме вхідна мова є основним показником можливостей ППП.
Як вхідні мови можуть використовуватися як універсальні, так і спеціалізовані мови програмування. Наприклад, як вхідна мова розробника ППП для написання прикладних і системних програм пакету звичайно використовується та або інша універсальна мова програмування (Фортран, Паскаль). В той же час вхідна мова кінцевого користувача в розвиненому пакеті, як правило, є мовою якісно вищого рівня в порівнянні з універсальними мовами. Образотворчі засоби такої мови враховують особливості завдань наочної області і специфіку користувачів. Подібні мови називають проблемно-орієнтованими, або наочно-орієнтованими.
Перейдемо тепер до розгляду інших компонентів ППП, конкретна прикладна діяльність характеризується двома чинниками:
1) класом вирішуваних задач і використовуваних для цих цілей методів
2) дисципліною роботи, тобто сукупністю правил, угод і технологічних прийомів, прийнятих при розробці, відладці, експлуатації програм.
Наочне забезпечення є компонентом пакету, що відображає особливості першого з цих чинників, тобто особливості конкретної наочної області. Наочне забезпечення включає:
- програмні модулі, що реалізовують алгоритми (або їх окремі фрагменти) рішення прикладних задач;
- засоби збірки програм з окремих модулів
Визначення складу бібліотеки модулів і форм їх взаємодії між собою є одним з найбільш трудомістких завдань при побудові ППП. Її рішення припускає проведення ретельного і кваліфікованого модульного аналізу використовуваних алгоритмів. Вдало проведений модульний аналіз в значній мірі впливає на повноту обхвату наочної області, а також на можливість розширення класу вирішуваних задач. Таким чином, виділення модулів істотно залежить від специфіки завдань і використовуваних алгоритмів і, по суті справи, відображає прийнятий в пакет спосіб збірки програм.
Найбільш поширено в даний час оформлення кожного модуля у вигляді програмної одиниці на тій або іншій мові програмування (наприклад, у вигляді підпрограми або підпрограми-функції на мові Фортран). Такий модуль забезпечує рішення деякої самостійної задачі і пов'язаний з іншими модулями лише вхідною і вихідною інформацією. Організація наочного забезпечення у вигляді бібліотеки програм характерна для більшості тих, що існують ППП.
Крім розглянутого підходу до оформлення модулів як програмних одиниць використовуються і інші способи.
Системне забезпечення є сукупністю системних засобів (програми, файли, таблиці і т. д.), що забезпечують певну дисципліну роботи користувача при рішенні прикладних задач. По своїй ролі у складі ППП і виконуваних функцій системне забезпечення по суті є спеціалізованою операційною системою, що визначає операційне оточення пакету. Не дивлячись на різноманіття способів реалізації системного забезпечення в рамках конкретних пакетних розробок, можна виділити його наступні основні компоненти:
- монітор, що управляє процесом рішення і взаємодією всіх компонентів ППП;
- транслятори з вхідних мов;
- засоби роботи з даними;
- засоби інформаційного забезпечення, що реалізовують видачу різноманітної довідкової інформації як по запитах користувачів (про структуру і можливості ППП, про допущені помилки і т.д.), так і по запитах різних компонентів пакету (наприклад, відомості про властивості модулів наочного забезпечення, необхідні планувальнику обчислень);
- різні службові програми, зокрема що реалізовують взаємодію пакету з операційною системою (робота із зовнішньою пам'яттю, засоби введення/висновку, драйвери спеціалізованих, зовнішніх пристроїв і ін.).
У конкретному ППП, як правило, відсутнє чітке структурне розділення програм на наочне і системне забезпечення. Наприклад, програма планування обчислень може одночасно виконувати ті або інші службові функції { інформаційне забезпечення, зв'язок з операційною системою і т. п.) і тим самим носитися як до наочного, так і до системного забезпечення. Крім того, одні і ті ж програми в одному пакеті можуть відноситися до наочного забезпечення, а в другом - до системного. Так, програми виведення графіків в рамках спеціалізованого пакету машинної графіки природно віднести до наочного забезпечення. Проте ті ж програми слід вважати службовими і такими, що відносяться до системного забезпечення, наприклад, в пакеті рішення обчислювальних задач).
2.3 ЕТАПИ РОЗВИТКУ ППЗ
Пакетна проблематика як самостійне науково напрями склалася в основному за останні 15-20 років. Перші ППЗ були простими тематичними підбірками програм для вирішення окремих завдань в тій або іншій прикладній області. Сучасний пакет є складною програмною системою, що включає спеціалізовані системні і мовні засоби. У щодо короткої історії розвитку обчислювальних ППЗ можна виділити 4 основних покоління (класу) пакетів. Кожний з цих: класів характеризується певними особливостями тих, що входять склад ППЗ компонентів - вхідних мов, наочного і системного забезпечення.
Як вхідні мови ППЗ першого покоління використовувалися універсальні мови програмування (Фортран, Алгол-60 і т. п.) або мови управління завданнями відповідних операційних систем Проблемна орієнтація вхідних мов досягалася за рахунок відповідної мнемоніки в іменах змінних, функцій процедур, а також в текстових константах. Складання завдань на такій мові практично не відрізнялося від написання програм на алгоритмічній мові.
Наочне забезпечення перших ППЗ, як правило, було організоване у формі бібліотек програм, тобто у вигляді наборів (пакетів) незалежних програм на деякій базовій мові програмування (звідси вперше виник і сам термін "пакет"). Такі ППЗ іноді називають пакетами бібліотечного типа, або пакетами простої структури.
Як системне забезпечення пакетів першого покоління звичайно використовувалися штатні компоненти програмного забезпечення ЕОМ: компілятори з алгоритмічних мов, редактори текстів, засоби організації бібліотек програм, архівні системи і т. д. Ці пакети не вимагали скільки-небудь розвиненої системної підтримки, і для їх функціонування цілком вистачало вказаних системних засобів загального призначення. В більшості випадків розробниками таких пакетів були прикладні програмісти, які намагалися пристосувати універсальні мови програмування до своїх потреб.
Розробка ППЗ другого покоління здійснювалася вже за участю системних програмістів. Це привело до появи спеціалізованих вхідних мов (їх називають вбудованими мовами) на базі універсальних мов програмування. Проблемна орієнтація таких мов досягалася не тільки за рахунок використання певної мнемоніки, але також застосуванням відповідних мовних конструкцій, які спрощували формулювання завдання і робили його наочнішим. Транслятор з такої мови був препроцесором (найчастіше макропроцесор) до транслятора відповідної алгоритмічної мови.
Як модулі в пакетах цього класу стали використовуватися не тільки програмні одиниці (тобто закінчені програми на тій або іншій мові програмування), але і такі об'єкти, послідовність операторів мови програмування, сукупність даних, схема рахунку і ін.
Істотні зміни зазнали також принципи організації системного забезпечення ППЗ. У достатньо розвинених пакетах другого покоління вже можна виділити елементи системного забезпечення, характерні для сучасних пакетів: монітор, транслятори з вхідних мов, спеціалізовані банки даних, засобу опису моделі наочної області і планування обчислень і ін.
Третій етап розвитку ППЗ характеризується появою самостійнихвхідних мов, орієнтованих на користувачів-непрограмістів. Особлива увага в таких ППЗ приділяється системним компонентам що забезпечує простоту і зручність. Це досягається головним чином за рахунок такої спеціалізації вхідних мов і включення до складу пакету засобів автоматизованого планування обчислень.
Нарешті, четвертий етап характеризується створенням ППЗ, експлуатованих в діалоговому режимі роботи. Основною перевагою діалогової взаємодії з ЕОМ є можливість активного зворотного зв'язку з користувачем в процесі постановки завдання, її рішення і аналізу отриманих результатів. Поява і інтенсивний розвиток різних форм діалогового спілкування обумовлена перш за все прогресом у області технічних засобів забезпечення діалогу. Сюди відноситься створення різноманітної дисплейної техніки (растрові дисплеї, засоби реалізації графічних, колірних і звукових можливостей, різні технічні пристрої для ведення діалогу і т. д.), а також надійних і швидкісних ліній зв'язку. Розвиток апаратного забезпечення спричинив за собою створення різноманітних програмних засобів підтримки діалогового режиму роботи (діалогові операційні системи, діалогові пакети програм різного призначення і т. д.). У багатьох додатках діалог вже повністю замінив пакетну обробку, а відрядковий режим діалогу поступається місцем по екранному режиму і багато віконному графічному способу спілкування.
Прикладна система складається з діалогового монітора-набору універсальних програм, що забезпечують ведення діалогу і обмін даними, і бази знань про область. Інформація про структуру, цілях і форма діалогу задає сценарій, відповідно до який монітор управляє ходом діалогу. Носіями процедурних знань про наочну область є прикладні модулі, що реалізовують функції власної системи. Таким чином, створення прикладної системи зводиться до настройки діалогового монітора на конкретний діалог, шляхом заповнення бази знань. При цьому програмувати в традиційному сенсі цього слова доводиться лише прикладні модулі, знання про діалог вводяться в систему за допомогою набору відповідних засобів - редактора сценаріїв. Логічно вимагати, щоб редактор сценаріїв також був діалоговою програмою, що відповідала розглянутим вище вимогам. Завдяки готовому універсальному монітору програміст може зосередитися на рішенні чисто прикладних завдань, виділення ж знань про діалог в сценарій забезпечує в значній мірі необхідна гнучкість програмного продукту.
Велика увага в даний час приділяється проблемі створення "інтелектуальних" ППЗ. Такий пакет дозволяє кінцевому користувачу лише сформулювати своє завдання в змістовних термінах, не указуючи алгоритму її рішення. Синтез рішення і збірка цільової програми проводяться автоматично. При цьому деталі обчислень приховані від користувача, і комп'ютер стає інтелектуальним партнером людини, здатним розуміти його завдання. Наочне забезпечення подібного ППЗ є деякою базою знань, що містить як, процедурні, так і описові знання. Такий спосіб рішення іноді називають концептуальним програмуванням, характерними особливостями якого є програмування в термінах наочної області використання ЕОМ вже на етапі постановки завдань, автоматичний синтез програм рішення задачі, накопичення знань про вирішувані задачі в базі знань.
На закінчення даного розділу розглянемо ще одну сучасну тенденцію розробки ППЗ. Вона полягає в застосуванні спеціалізованих інструментальних засобів і систем, що дозволяють прискорити і спростити процес створення пакету, а також понизити вартість розробки. При цьому особлива увага приділяється створенню системних засобів, що дозволяють використовувати як наочне забезпечення ППЗ написані раніше прикладні програми. Крім того, інструментальні системи звичайно реалізуються таким чином, що їх можна використовувати як базу (готових компонентів) для системного забезпечення пакетів, що розробляються (тому їх іноді називають базові інструментальними системами). Створення інструментальних засобів, що спрощують розробку ППЗ в різних наочних областях, є одним з актуальних напрямів системного програмування в пакетній проблематиці.
При виборі методу реалізації того або іншого ППЗ слід враховувати особливості конкретної ситуації, зокрема, людські і матеріальні ресурси, що є в наявності. Так пакет бібліотечного типа, не будучи розвиненою системою з погляду розглянутих вимог, володіє, проте, тією перевагою, що вхідна мова і системне забезпечення такого пакету можуть бути достатньо легко реалізовані силами прикладного програміста. Тому у разі, коли подібний пакет задовольняє конкретних користувачів, його розробка є цілком виправданою.
3. ВИСНОВОК