Б С Бусигін - Прикладна інформатика - страница 16

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65  66  67  68  69  70  71  72  73  74  75  76  77  78  79  80  81  82  83 

Рис. б.8. Загальний вигляд візуального середовища програмування Delphi б. На задньому плані форма, попереду - вікно з кодом. У лівому нижньому куту - список властивостей форми.

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

Головним елементом практично аби якого додатку є так звана форма (тобто вікно довільної (рос.-произвольной) форми), на котрій розміщуються усі інщі візуальні компоненти, а також меню, кнопки і відповідні команди, функціональність котрих забезпечує програміст (рис. б.9).

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

Рис. 6.9. Форма з компонентами, меню, кнопками і командами, які розроблені у IDE RAD Delphi для вирішення конкретної задачі (на передньому плані повна форма, на задньому - фрагмент)

Спрощення розробки додатків таким чином досягається уніфікацією взаємодії компонентів поміж собою і забезпечується на рівні уніфікованих інтерфейсів СОМ-компонентів (рис. 6.10).

Як правило, аби яка задача, що вирішується на комп'ютері, реалізується у Delphi у вигляді додатку. Додаток створюється з різних частин. Кожна частина розміщується у окремому файлі і виконує строго визначені функції. Набір файлів, які необхідні для створення додатку, зветься проектом. Тому, головною одиницею розробки додатку є проект, який зберігається у файлі з розширенням DPR (скороч. від Delphi PRoject). Він уявляє собою головний програмний файл на мові Object Pascal, котрий підключає за допомогою операторів uses всі файли модулів, що входять до проекту. Кожній формі, що проектується у RAD, відповідає свій програмний модуль (unit), який містить усі відносні до форми об'яви і методи подій, що пишуться програмістом на мові Object Pascal. Кожній формі відповідає свій двоічний файл з розширенням DFM, який містить її опис. Програмні модулі розміщуються в окремих файлах з розширенням PAS. Окрім них існує ще ряд додаткових файлів.

Рис. 6.10. Образне уявлення взаємодії компонентів (і відповідних модулів) на рівні інтерфейсів

Файл ресурсів з розширенням RES (скороч. від RESource). У ньому, доречи, зберігається піктограма додатка, котра буде видна на Панелі Задач Windows. У підключених у вигляді модулів об'єктних файлах (мають розширення OBJ), розміщуються компоненти, написані на інших мовах програмування (наприклад, на С++). Файл опцій з розширенням DOF (скороч. від Delphi Option Files), містить параметри компіляції і компоновки проекту, які задає програміст. Існує щє цілий ряд файлів, які виконують службові функції, котрі у цьому посібнику не обговорюються.

У цілому, схематично процес створення додатка у RAD Delphi можна уявити як набір послідовних кроків по створенню проекту (див. рис. 6.11). Для цього на відкриту у вікні RAD Delphi форму наносяться потрібні візуальні компоненти і пишеться відповідний код. В подальшому, завантажений у пам'ять комп'ютера у вигляді двоічного файла EXE або DLL додаток виконується як програмний модуль. Ідеологічно, таким же чином працюють багато інших середовищ візуального програмування для мов C++, Java, C# і деяких інших.

Рис. 6.11. Створення додатка в IDE RAD Delphi

Дещо відрізняється уявлення взаємодії програмних компонентів у IDE MS Visual Studio.Net, де найбільшою програмною одиницею є рішення (рос.-решение) (solution). У продовж роботи з IDE цей термін асоціюється з уявленням робочий простір (рос.-рабочее пространство), так як буквальний переклад — рішення — не завжди однозначний. Концепція рішення допомогаєоб'єднати проекти та інші інформаційні елементи у одному робочому просторі. Множина файлів різного типу, у рамках одного рішення складають додаток (рос.-приложение) (application) Visual Studio.Net 7.0. Робочій простір може містити декілька проектів, бути пустим або містити файли, котрі мають сенс і поза контекстом рішення. У аби якому випадку, користувач повинен починать роботу у студії з відкриття існуючого або створенняя нового робочого простіру. Проект як частина рішення складається з окремих компонентів, наприклад файлів, які описують форму вікна або шаблон діалогу (re-файл), файлів з початковими (рос.-исходньїми) кодами програмних модулів (.срр, .cs) і/або файлів, які уявляють собою опис запитів (рос.-запросов) до бази даних (database script).

Принципово відрізняються від додатків з візуальних RAD середовищ ті програми (підпрограми, фрагменти кодів і т.д.), які реалізовані на скриптових мовах і які уявляють собою звичайні набори текстових стрічок. До найбільш популярних скриптових мов, без сумніву, можна віднести мову Visual Basic for Applications (VBA), яка вбудована в усі без виключення офісні додатки Microsoft Office а, в останній час, і у геоінформаційну систему ESRI ArcGIS. При зовнішньої подібності інтерфейсу VBA (рис. 6.12) до звичайних IDE, коди процедур-підпрограм і процедур-функцій не компілюються у двоїчні файли з розширенням EXE і DLL, а також не завантажуються для виконання у оперативну пам'ять комп'ютера.

Рис. 6.12. Інтерфейс IDE Visual Basic for Applications

Виконання інструкцій скриптового коду, що уведені в тіло модуля, а потім викликаються у вікно проекту, провадиться шляхом їх інтерпретації і негайного виконання додатком-контейнером (наприклад, на рис. б. 12. MS Excel), котрий в цей час знаходиться у оперативній пам'яті комп'ютера.

По такому ж принципу працюють і інші додатки-контейнери і, у тому числі, MS Internet Explorer (IE). Знаходячись у оперативній пам'яті, IE приймає на вході стрічки з тегами (кодами) мови HTML і відображає закодовані таким чином елементи сторінки у відповідності з заданими параметрами розмітки, а якщо зустрічає фрагменти програм (кодів) на скриптових мовах, з котрих найбільш популярні JavaScript і VBScript, інтерпретує їх і безпосередньо виконує (рис.б.13).

<SCR1PT LANGUAGE3" JavaScript">

// Присвоение переменной 'а' значения "Привет!". а = "Привет Г';

</SCRIPT>

Рис. б.13. Приклад коду на мові JavaScript, що розміщено на HTML-

сторінці

З деякими, доречи кажучи невеликими різницями, працюють і багато інших IDE і RAD для створення програмних кодів на різних мовах програмування. Не удаючись у подробиці тонкостей їх роботи, приведемо думку (рос.-мнение) одного з авторитетних спеціалістів з програмування на Visual Basic, Андрія Колесова, автора багаточисельних програмних розробок і статей у журналах "Комп'ютерПресс", PCWeek/RE і на сервері "Советы VBA Форуму". Його думка така7.

" Ще однією ілюзією є дуже поширене зараз уявлення про те, що кваліфікація програміста визначається тим, яким інструментом він володіє. Більш конкретно, C- програміст — це сильно, Basic — не дуже... Така думка не просто невірна: вона формує неправильне уявлення про дійсність. Насправді, кваліфікація розробника визначається його рівнем загально методичної підготовки і глибиною знань інструмента (мови). Короче кажучи, є більш і менш кваліфіковані спеціалісти. Тобто, відповідно, є слабкі C-програмісти і сильні VB-програмісти, і навпаки. При зміні інструменту, скоріш за все, слабкий розробник зостанеться слабким, а сильний — сильним.

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

7 http://visual.2000.ru/develop/talks/talks1_1. htmзнання додаткового інструмента може різко підвищити ефективність застосування головного. Плюсом від вивчення другої мови (як синоніма засобу розробки) є також більш повне розуміння можливостей першого. Для Fortran-користувачів (и, напевно, для С теж) є дуже корисними вміння створення інтерфейсу користувача за допомогою одного з RAD-інструментів. Delphi є у значній мірі самодостатнім інструментом, але навряд чи його користувач зможе обійтися без застосування VB або Java. VB-розробнику знання основ Java також зовсім не зашкодить (рос.-повредит). Усім їм також потрібне уявлення про HTML, а найближчим часом — і про XML".

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

І взагалі, у той час, як ми довго спорилися: "Програмування — це наука або мистецтво?, американці вже давно прийшли до висновку, що це — технологія".

6.4. У якому середовищі працюють програми і додатки?

Розробка    програм нерозривно пов'язана з архітектурою

обчислювальних середовищ, для котрих вони і створюються. Тут під архітектурою розуміється методологія об'єднання і взаємодії елементів складної обчислювальної структури на логічному (л.р.), фізичному (ф.р.) і програмному (п.р.) рівнях. Наприклад, для мережі LAN (див. Додаток 4), що складається з 5-ти комп'ютерів архітектура визначає, яка

використовується схема поєднання ПК (л.р.), які компоненти апаратури з'єднані (ф.р.) і який набір програмних продуктів забезпечує роботу цієї системи: ОС, сервери і т.д. (п.р.). Тому розробнику слід чітко уявляти у яких " вимірюваннях (рос.-измерениях)" буде функціонувати кінцевий програмний коді що робити: управляти апаратурою, реалізувати математичний метод або клієнт-серверний Web-додаток, СОМ-сервер, сервлет, аплет і т.д..

комп'ютера

Слід окремо відмітити, що з точки зору архітектурної побудови за Фон Нейманом власне сам комп'ютер складається з 5-ти наступних головних вузлів (рис.6.14):

О арифметико-логічного пристрою (АЛП); Ф центрального пристрою управління (ЦПУ);

Ф оперативної пам'яті (ОП, ОЗП- оперативного запам'ятовуючого пристрою);

Ф пристроїв уводу; Ф пристроїв виводу.

У даному випадку, під архітектурою розуміється опис обчислювальної системи на деякому загальному рівні, який включає опис користувальницьких можливостей програмування, системи команд і засобів інтерфейсу користувача, організації пам'яті і системи адресації, операцій уводу/уводу, управління і т.д. І якщо прості, однокомп'ютерні (тобто ті, які працюють з одним мікропроцесором) додатки достатньо просто інтегруються у структуру обчислювального середовища, то вихід у мережу, де починають взаємодіяти багатопроцесорні і багатогомережові структури, як правило, істотно ускладнює задачу і приводить до необхідності використання моделі клієнт/сервер або компонентної моделі Web-сервісів.

Термін клієнт/сервер (або клієнт-сервер) уперше було застосовано у 80-х роках, по відношенню до процесу використання і взаємодії персональних комп'ютерів у мережах LAN (local area network). Сучасна клієнт/серверна модель виявила себе у кінці 80-х. Ця архітектура є гнучкою і заснованою на обміні повідомленнями (рос.-сообщениями) у модульній інфраструктурі, яка призначена для підвищення практичності (usability), гнучкості (flexibility), інтероперабельності (interoperability) і масштабованості (scalability) програмних додатків і єлементів комп'ютерних систем. Клієнт є ініціатором запитань (рос.-запросов) на виконання деяких послуг (services), а сервер - дає необхідні послуги (services) клієнту, які були потрібні і запитані клієнтом.

Отже, розглянемо послідовно найважливіші обчислювальні архітектури. Архітектурі клієнт/сервер передували дві архітектури, які існують і до наших часів у зв'язку з достатньо великою кількістю успадкованих систем (рос.-наследуемьх систем), які продовжують використовуватися у повсякденних роботах у багатьох великих організаціях різних країн світу.

Архітектура мейнфреймів (mainframe architecture) (рис. 6.15). Характеризується зосередженням (рос.-сосредоточением) усіх вбудованих обчислювальних засобів на центральному хост-комп'ютері. Користувачі взаємодіють з хостом за допомогою уводу ключових командних стрічок через термінали. Хости не підтримують графічний інтерфейс користувача (GUI), але можуть взаємодіяти з ПК і робочими UNIX-станціями (рис.6.15). Останнім часом у зв'язку з постійним зростанням навантаження і об'єму інформації на серверах WWW, мейнфрейми почали активно використовуватися і у розподілених клієнт/серверних архітектурах. Самі ж сучасні мейнфрейми будуються на кластерах багаточисельних процесорів великої потужності.

У минулому, мейнфрейми звалися універсальними електронно-обчислювальними машинами (ЕОМ) і системи програмного забезпечення, що писалися до них були часто монолітні. У них інтерфейс користувача, ділова (бізнес) логіка і функціональні можливості доступу до даних зберігалися у одному великому додатку. Це було пов'язано з тим, що термінали увода-виводу, які використовувалися для звернень до універсальних ЕОМ не робили ніякихоперацій по обрабці даних - всі ці операції виконувалися у мейнфреймі безпосередньо. Таким чином створювалася монолітна архітектура додатків.

^    ПК і робочі UNIX-станції

Ме йнфрейм та його компоненти:

- Операційна система

- Системи програмування

- Додатки

- Дані

Термінали

Рис. 6.15. Архітектура мейнфреймів

Типова монолітна архіте-ктура додатка

Подальший  розвиток  архітектури додатків

Термінал

Рис. 6.16. Монолітна архітектура додатків мейнфреймів

илюструється на рисунку 6.16.

був пов'язаний з розвитком персональних комп'ютерів, мережних технологій і технологій WWW та Internet (див. далі підрозділ 6.6).

Файл-орієнтована архітектура (file     sharing architecture)

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

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

Клієнтісерверна архітектура (client/server architecture) виникла як результат розвитку файл-орієнтованої архітектури, яка має деякі обмеження по продуктивності (рос.-производительности) і масштабованості. У нової архітектурі потужний комп'ютер, який використовується як сервер баз даних, замінив файл-сервер. Застосування систем управління базами даних СУБД (relational DataBase Management System, DBMS) дозволило суттєво прискорити і спростити зв'язки користувача з даними. Клієнт/серверна архітектура різко знизила мережовий трафік, а також забезпечила багатокористувальницький доступ до редагування одних і тих же записів даних у базах даних, які сумісно використовуються. Головним способом взаємодії клієнтів і серверів стали віддаленні (рос.-удалённые) виклики процедур (Remote Procedure Calls, RPCs) або речення (рос.-предложения) на стандартній мові запитань (рос.-запросов) (Standard Query Language, SQL) (рис.б.17 ).

Рис. б.17. Модель клієнт/серверної архітектури з сервером баз даних

Рис. б. 1S. Класична дворівнева архітектура клієнт-сервер

У двоярусній архітектурі (two tier architectures) системний інтерфейс користувача як правило розташовано у середовищі настільного комп'ютера користувача, а служби управління базами даних - на більш потужнім комп'ютері сервері, котрий забезпечує зберігання додатків, а також процедур і тригерів баз даних (рис.б.^). На відміну від дуже коштовних мейнфреймів ця архітектура є добрим рішенням для розподілених обчислень у робочих групах до 1GG користувачів, які працюють в LAN відділів і організацій одночасно.

Компоненти додатків у

клієнт/серверних обчисленнях як правило розподілені так, щоб база даних постійно знаходилася на сервері (UNIX або мейнфреймі), інтерфейс користувача на ПК - клієнті, а ділова (бізнес) логіка знаходиться на обох компонентах.

Триярусна архітектура (three tier architectures), відома також як багатоярусна (multi-tier architecture), розроблялась для знімання обмежень, які існували у двоярусній. У ній середній ярус був доданий поміж системним інтерфейсом середовища клієнта і середовищем сервера, яка управляє базою даних. Існує достатньо багато реалізацій цього середнього рівня, до яких можна віднести монітори обробки транзакцій (transaction processing monitors), сервери повідомлень (message servers) і сервери додатків (application servers). Триярусна архітектура дозволяє одночасно працювати групам, які об'єднують декілька тисяч користувачів. Гнучкість у настроюванні потрібної конфігурації тут досягається простим застосуванням технології "drag and drop" для фрагментів кодів, які використовують додатки на різних комп'ютерах аби якого ярусу з трьох існуючих. Обмеження триярусної архітектури пов'язані з тим, що використання середовищ розробки додатків тут значно складніша, ніж візуально-орієнтована розробка у двоярусній архітектурі. Останнім часом, у триярусній архітектурі у якості серверів починають активно застосовуватися мейнфрейми.

Триярусна архітектура з технологіями монітора обробки транзакцій (three tier architecture with transaction processing monitor technology) є однією з найбільш розповсюджених і включає на середньому ярусі монітор обробки транзакцій (Transaction Processing, TP). У його задачі входить організація черг (рос.-очередей) запитань (рос.-запросов), розподіл транзакцій і пріоритетів виконання задач. Окрім того, він забезпечує:

О можливість оновлення багаточисельних різних СУБД шляхом одноразово виконаної транзакції;

© з'єднання і обробку багаточисельних джерел даних, і у тому числі двовимірні (рос.-двумерные) файли (flat files), не реляційні або об'єктно-орієнтовані БД, а також і мейнфрейми;

© можливість присвоювання різних пріоритетів транзакціям;

О забезпечення робастної (стійкої (рос.-устойчивой)) безпеки. Триярусна архітектура з сервером повідомлень (рос.-сообщений) (three tier with message server) уявляє реалізацію процесу асинхронного обміну повідомленнями (messaging) з різними пріоритетами. Повідомлення, як правило, містять заголовки, які складаються з даних про рівень пріоритету, а також адреси і ідентифікаційного номера повідомлення. Якщо у даній архітектурі інтелектуальність, що програмується, зосереджена у повідомленнях, то у середовищі моніторів транзакцій безпосередньо у моніторі, який обробляє транзакції у вигляді не інтерпретованих пакетів даних. Триярусна архітектура з сервером повідомлень є кращім рішенням для безпровідних інфраструктур.

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65  66  67  68  69  70  71  72  73  74  75  76  77  78  79  80  81  82  83 


Похожие статьи

Б С Бусигін - Прикладна інформатика