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

Страницы:
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 

у інтерфейси з унікальними ідентифікаторами (GUID);

© управління часом (рос.-временем) життя об'єкту;

О механізм однозначної ідентифікації компонентів і інтерфейсів СОМ

по унікальним ідентифікаторам (GUID). Компоненти СОМ реалізуються у вигляді бібліотек DLL, елементів ActiveX, кнопок и команд графічних інтерфейсів додатків (Word, Fotoshop та ін.), елементів форм і таке інше. Специфікація на рівні структур даних дозволяє зв'язувати компоненти, написані для різних платформ (Microsoft® Windows®, Microsoft Windows NT™, Apple® Macintosh®, UNIX® і деяких інших) Стандарт є відкритим, що дозволяє створювати власні компоненти і використовувати

Поточним часом COM є однією з найбільш поширено розповсюджених у світі програм­ною компонентною моделлю. По даним Інтернет у 2000 р. COM компоненти використовувалися на більш ніж 150-и мільйонах систем по усьому світу. Однією тільки фірмою ESRI (Environment System Research Institute) (США) на кінець 2002 року було розроблено більш за 1200-т компонентів під загальною назвою ArcObjects для потреб геоінформаційних  систем (ГІС)

(рис.4.26).

Подальшим продовженням моделі СОМ є модель DCOM, тобто   розподілена   СОМ, яка розширює границі взаємодії компонентів у мережному просторі (рис. 4.27).

При виклику одним компонентом іншого, згідно моделі DCOM (див. рис.4.27) діється наступне.

1. Компонент програми на клієнтському ПК здійснює виклик, який звертається до віддаленого серверного компонента, такому, наприклад, як система авторизації кредитних карток. При цьому він звертається до операційної системи Windows.

2. DCOM встановлює з'єднання через мережу поміж двома компонентами, використовуючи механізм віддаленого виклику процедур (RPC).

3. Клієнтський компонент може взаємодіяти з серверним компонентом так, як коли б вони розміщувалися на однієї і тієї же машині.

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

Паралельно з DCOM розвивається подібна архітектура мережних обчислень під назвою Common Object Request Broker Architecture (CORBA), яку підтримують такі крупні компанії, як IBM, Sun Microsystems і ряд інших

компоненти, які створені іншими фірмами.

Рис. 4.26. Уявлення невеликої частини компонентів ArcObjects з їхніми інтерфейсамивиробників. Сьогодні вона застосовується багатьма великими організаціями для розгортання розподілених обчислень у масштабах підприємства на базі ипіх-серверів і мейнфреймів.

Архітектура розподілених інтероперабельних інформаційних систем

CORBA (див. підрозділ 6.4), базується на концепції проміжного шару (рос.-промежуточного слоя) (middleware), що містить служби і засоби підтримки глобального простіру об'єктів, їх життєвого циклу та інтероперабільністі. Цей

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

Головними компонентами архітектури проміжного шару, який розвивається консорціумом OMG (див. підрозділ 7.2), є:

О Загальна Архітектура Брокера Об'єктних Запитів - Common Object Request Broker Architecture, тобто - CORBA;

Рис. 4.27. Принцип взаємодії компонентів за допомогою моделі DCOMв Брокер Об'єктних Запитів (Object Request Broker - ORB), який грає вирішальну роль "загальної шини (рос.-общей шины) " у глобальному просторі об'єктів, за допомогою якої об'єкти цього простору можуть взаємодіяти один з одним, маючи широку підтримку цілим рядом продуктів, які розповсюджуються знаними виробниками: Digital, IBM, SunSoft, IONA Technologies та деякими іншими для різних типів платформ. Загальна система Об'єктних Служб и Загальних Об'єктних Засобів (CORBA) організує нижній шар архітектури проміжного шару, який забезпечує технологічну платформу інтероперабельності (властивість до взаємодії).

Важливим компонентом CORBA є мова визначення інтерфейсів (IDL -Interface Definition Language). У версії стандарту CORBA 2.0 ця мова почала називатися OMG IDL. Таким чином, OMG IDL є засобом, за допомогою якого потенційним клієнтам об'єкта-сервера повідомляється, які операції доступні на його інтерфейсі і як їх потрібно викликати.

IDL - є мовою однорідної специфікації інтерфейсів різноманітних інформаційних ресурсів, інкапсульованих засобами технологій CORBA. Ця мова є чисто описова. Визначення (рос.-определения) на мові IDL можуть бути відображені стандартним засобом у конкретні мови програмування, такі як С, С++, Smalltalk. Репозіторій Інтерфейсів, що містить визначення інтерфейсів на мові IDL, дозволяє бачити інтерфейси доступних інтерфейсів у мережі і програмувати їх використання у програмах-клієнтах з урахуванням можливостей Брокера. Специфікації, що містяться у репозіторії, можуть бути також використані у період виконання клієнта. Ролі "клієнта" і "серверу" слід розглядати як відносні: клієнт (сервер) у архітектурі CORBA може бути сервером (клієнтом) по відношенню до інших клієнтів (серверів).

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

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

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

Рівень реальної взаємодії Концептуальна модель

Інтерфейс - це ділянка (середовище), де зустрічаються і взаємодіють дві незалежні системи

Рівень інформаційної взаємодії:

обмін інформацією (даними), сумісність даних; передача/прийом повідомлень генерація даних /декодування даних відповідна реакція (формування

Івідповідей/декодуванння відповідей)

Информаційна структура даних:

Елемент 1 (Компонент 1)

-знакова, текстова, графічна, звукова.

Користувач

Інтерфейс поміж елементний

Елемент 2 (Компонент 2)

Інтерфейс елемента 1

Інтерфейс елемента 2

Комп'ютер

Реалізації

Поміж системний інтерфейс:

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

Інтерфейс користувач-дані:

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

Апаратний інтерфейс:

слоти, роз'єднувачі, штекери/гнізда і т.і.

[Електронний інтерфейс:

рівні сигналів, послідовності сигналів, імпеданси и т.д.

Програмний інтерфейс:

параметри (формальні, факимчні), сігнатури, покажчики (рос.-указатели), методи і т.і._

Физична реалізація елементів:

системи; фізичні об'єкти;

компоненти систем, обчислювальних мереж;

фрагменти кодів (програми);

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

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

Абстрактний рівень:

Архітектурнтй (мережовий) рівень:

модель клієнт/сервер

Концептуальні абстракції:

—наслідування, інкапсуляція і т.і.

Модельний рівень (взаємодії):

Інтерфейс - набір операцій, які описують послуги) (сервіс), що даються класом або компонентом

Логічна абстракція даних

Клас - опис сукупності об'єктів з загальними атрібутами, операціями, відношеннями, семантикой. Реалізує один або декілько інтерфейсів.

Логічна абстракция взаемодії

-угоди (рос.-соглашения) про зв'язки, протоколи, специфікації, логічні номера і імена пристроів і т.і.

Програмні (мовні) абстракции:

-класи (абстрактні типі даних), повідомлення (рос.-сообщения), методи і т.і.

Технологічні абстракції:

Сутності, які являються головними елементами моделі

Фізична абстракція:

Компонент - фізична упаковка логічних елементів, таких як класи, інтерфейси і кооперації.

Рис. 4.28. Багаторівнева модель структури уявлень інтерфейсу

95

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

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

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

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

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

2. Далі йде етап аналізу і проектування, тобто уявлення і моделювання компонентів, які приймають участь у взаємодії, реалізація якої розробляється. На даному рівні застосовуються абстракції даного етапу, як правило, при підтримці засобів мови UML.

3. При виборі засобів реалізації в рамках моделей інтерфейсів і мов реалізації застосовуються логічні абстракції.

4. На рівні програмної реалізації моделей, які розроблені (класів, об'єктів і їх багаторівневої взаємодії) застосовуються засоби конкретної мови програмування: C++, Object Pascal, Visual C++, Java, C# і інші (програмні абстракції).

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

6. Фізичні абстракції дозволяють виділяти набори компонентів у логічно зв'язані комплекси, які уявляють собою елементи з більш високим рівнем організації.

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

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

Таблиця 4.1

Взаємодіючі сутності, об'єкти, системи, компоненти, елементи і їхні _інтерфейси_

№ пп.

Взаємодіючі сутності, об'єкти і т.д.

Вид (тип) інтер­фейсу

Спосіб і засоби підтримки

Реалізація

1

Людина -реальний об'єкт

Системни й

Комп'ютерний, мови програмування, мова ЦМЬ,

СЛБЕ-засоби, фізичні пристрої(мікропроцесори)

Логічна,

програмна,

фізична

2

Людина -комп'ютер (ПК)

Систем­ний

Командний (текстова стрічка, сполучення клавіш клавіатури, клацання клавішами миші); графічний (графічні об'єкти, кнопки, меню); мови програмування; ЯЛБ-засоби, фізичні пристрої

Логічна,

програмна,

фізична

3

Людина -пристрій ПК

Систем­ний

Логічні імена у ПК, мови програмування, ЯЛБ-засоби, кнопки пристроїв

Програмна Фізична

4

Людина -

програма

(додаток)

Систем­ний

Командний (текстова стрічка, сполучення клавіш клавіатури, клацання клавішами миші); графічний (графічні, кнопки, меню); мови програмування; ЯЛО-засоби

Програмна

5

Комп'ютер -комп'ютер

Системни й

Мережний, пристрої комунікації, програми, мови програмування

Програмна, фізична

6

Програма -програма

Програм­ний

Програмний, імена, мови програмування

Програмна

7

Об'єкт

(програми) -об'єкт

Програм­ний

Програмний, імена, ОЦТО, ЦІЛО, СЬБГО, мови програмування

Програмна

8

Програма -пристрій

Програм­ний

Програмний, імена, мови програмування, пристрої комунікації, протоколи

Програмна, фізична

9

Пристрій -програма

Програм­ний

Програмний, імена, мови програмування, пристрої комунікації, протоколи

Програмна, фізична

10

Пристрій -пристрій

Фізичний

Пристрої комунікації, протоколи, угоди

Фізична, програмна

З прониканням комп'ютерів у все більшу кількість галузей поміж системний інтерфейс продовжує зоставатися "гарячою" точкою концентраціїзусиль розробників апаратних і програмних засобів, але саме головне -продовжують удосконалюватися інформаційні моделі і технології їх реалізації. В останній час з'явилися візуальні засоби програмування (Delphi, Visual C++, Visual Basic та ін.), у яких закладені об'єктно-орієнтовані концепції програмування і інструменти реалізації відповідних моделей (COM, DCOM, OLE Automation, ActiveX і т.д.). Швидко розвиваються компонентні моделі і технології, які базуються на специфікаціях і архітектурах .NET і Java, що реалізують широкі функціональні можливості обробки інформації в Інтернеті і

WWW.

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

Запитання.

1. Чому уявлення "інтерфейс" має декілька значень?

2. Наведіть приклади інтерфейсів різних систем?

3. Чим відрізняється аналогове уявлення процесу від цифрового?

4. Що таке дані?

5. Що таке інформація?

6. Які   концептуальні   складові   повінні   бути   присутніми для забезпечення процесу взаємодії користувача з комп'ютером?

7. Які   екранні   об'єкти,   що   забезпечують   графічний інтерфейс користувача є пасивними, а які активними?

8. Які концепції лягли у основу розробки WIMP-інтерфейсів?

9. Наведіть приклади метафор, які використовуються для створення графічного інтерфейсу користувача?

10. Які задачі виконують у комп'ютері розширення імен файлів?

11. Чим відрізняються апаратні інтерфейси від програмних?

12. Які головні елементи входять до моделі інтерфейсу клієнт-сервер?

У корні невірною є ідея, що існує тільки один правильний спосіб або мова, щоб вирішити аби яку проблему для аби якого користувача.

Б'єрн Страуструп, автор мови С++.

(з інтерв'ю 21.02.2001)

5. ЕВОЛЮЦІЯ МОВ ПРОГРАМУВАННЯ 5.1. Початок розвитку мов програмування

Творці перших мов програмування високого рівня для комп'ютерів прагнули зробити їх у меншій мірі подібними на середовище спілкування поміж людиною і комп'ютером і у більшій - на упорядкований набір знаків і символів. Споконвічно (рос.-изначально) держати курс на традиційну і вже улаштовану (рос.-устоявшуюся) математичну символіку запропонував Х. Рутисхаузер (у 1952 р.), який став родоначальником ідеї мов програмування і одним з авторів мови Алгол-60. Поширене розповсюдження і застосування його ідеї отримали і були втілені у життя лише у 1957 р., після того, як корпорація ІВМ опублікувала опис мови Фортран і реалізувала для нього компілятор, який транслював програми у машинний код. По суті, з цього моменту і почалася епоха мов програмування (рис. 5.1).

1 с

2 С

3 С

21

22

I

29

**************************************************

Programming by. CHOI YONG SOK : 199500689 special type  [ using subroutine ] Upgrade version !!!

********* X X *************** X X ************ *

INTEGER M, N INTEGER TRACE PARAMETER(M = 3, N = 3) INTEGER MATRIX(M,N) INTEGER MATRIX_T(M,N) INTEGER ROW, COL INTEGER A(9) INTEGER I, SIZE

TRACE = 0 SIZE = M*N

PRINT *, 'Please input matrix component (unit $ row DO 10 ROW = 1, M, 1

READ *,   (MATRIX(R0W,C0L), COL = 1, N, 1) 10 CONTINUE

PRINT *, PRINT *,

Your input matrix

DO 20 ROW = 1, M, 1

PRINT *, (MATRIX(R0W,C0L), COL 20 CONTINUE

1, N, 1)

// The main Program begin

Страницы:
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 


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

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