Навігація
Головна
 
Головна arrow Інформатика arrow Інформаційні технології
< Попередня   ЗМІСТ   Наступна >

Приклад компоновки функціонального профілю

Розробка та застосування профілів є невід'ємною частиною процесів проектування, розробки, впровадження та супроводу ІС. Профілі характеризують кожну конкретну ІС на всіх стадіях її життєвого циклу, задаючи гармонійний набір базових стандартів, яким повинна відповідати ІС та її компоненти. Профіль такої системи не є статичним, він розвивається і конкретизується у процесі встановлення та специфицирования вимог, відображення їх в ТЗ, проектування ІС і оформляється у складі документації проекту системи. При формуванні та застосуванні профілів конкретних ІС можна використовувати міжнародні, національні стандарти відомчі нормативні документи, а також стандарти "де-факто" за умови доступності відповідних їм специфікацій ("загальнодоступні специфікації"). Для коректного застосування опис профілю обов'язково повинно містити [15]:

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

На стадіях реалізації життєвого циклу ІС вибираються, компонуються і застосовуються такі основні функціональні профілі: середовища розподіленої ІС, прикладного програмного забезпечення, захисту інформації в ІС, інструментальних засобів, вбудованих в ІС (рис. 7.7).

Прикладне програмне забезпечення конкретної ІС практично завжди є проблемно-орієнтованим і визначає основні функції системи. Функціональні профілі ІС повинні включати в себе гармонізовані базові стандарти.

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

Структура реалізації відкритих систем з використанням стандартних профілів

Рис. 7.7. Структура реалізації відкритих систем з використанням стандартних профілів [1]

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

Найбільш опукло проблеми формування функціональних профілів можна показати на прикладі відкритої розподіленої інформаційної системи з архітектурою "клієнт-сервер". Розглянемо загальні підходи до побудови профілів таких систем [15].

Профіль середовища розподіленої ІС повинен визначати її архітектуру відповідно до обраної моделлю розподіленої обробки даних, наприклад, Distributed Computing Environment (DCE) або Common Object Request Broker Architecture (CORBA).

У першому випадку модель визначається стандартами консорціуму OSF, зокрема, використовується механізм віддаленого виклику процедур (Remote Procedure Call - RPC) з урахуванням стандартів "де-факто", які специфікують приємним монітори транзакцій (наприклад, монітор транзакцій Tuxedo) [14].

У другому випадку модель визначається стандартами консорціуму OMG, зокрема специфікацією брокера об'єктних запитів (Object Request Broker - ORB). Стандарти інтерфейсів API додатків з середовищем ІС повинні бути визначені по функціональних областях профілів ІС. Декомпозиція структури середовища функціонування ІС на складові частини, виконувана на стадії ескізного проектування, дозволяє деталізувати профіль середовища ІС по функціональних областях еталонної моделі OSE / RM:

  • • графічного інтерфейсу користувача (MOTIF консорціуму OSF або стандарт X Window IEEE);
  • • реляційних або об'єктно-орієнтованих СУБД (наприклад, стандарт мови SQL-92 і специфікації доступу до різних баз даних);
  • • операційних систем з урахуванням мережевих функцій, виконуваних на рівні операційної системи (наприклад, набору стандартів POSIX - ISO і IEEE);
  • • телекомунікаційного середовища в частині послуг і сервісів прикладного рівня: електронної пошти (за рекомендаціями ITU-T Х.400, Х.500), доступу до віддалених баз даних RDA (за стандартом ISO 9594-1.2), передачі файлів, доступу до файлів і управління файлами (за стандартом ISO 10607 - 1, 2, 3, 4, 5, 6).

Профіль середовища розподіленої ІС повинен включати в себе:

  • • стандарти протоколів транспортного рівня (за ISO / IEC OSI або стандарт "де-факто" протоколу TCP / IP);
  • • стандарти локальних мереж (наприклад, стандарт Ethernet IEEE 802.3 або стандарт Fast Ethernet IEEE 802.3 u);
  • • стандарти засобів сполучення проектованої ІС з мережами передачі даних загального призначення (наприклад, за рекомендаціями ITU-T: Х.25, Х.З, Х.29 та ін.).

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

ИС містить стандарти, що визначають параметри технічних засобів і способи їх вимірювання (наприклад, стандартні тести вимірювання продуктивності).

Профіль захисту інформації в ІС повинен забезпечувати реалізацію політики інформаційної безпеки, що розробляється відповідно до необхідної категорією безпеки і критеріями безпеки, заданими в технічному завданні на систему [7]. Побудова профілю захисту інформації в розподілених системах "клієнт-сервер" методично пов'язано з точним визначенням компонентів системи, відповідальних за ті чи інші функції, сервіси та послуги, і засобів захисту інформації, вбудованих в ці компоненти. В області захисту інформації повинні виконуватися наступні функції;

  • • захист, реалізована операційною системою;
  • • захист від несанкціонованого доступу на рівні програмного забезпечення проміжного шару;
  • • управління даними, реалізоване СУБД;
  • • захист програмних засобів, у тому числі засоби захисту від вірусів;
  • • захист інформації при обміні даними в розподілених системах, включаючи криптографічні функції;
  • • адміністрування засобів безпеки.

Основоположним документом у галузі захисту інформації в розподілених системах є рекомендації Х.800, прийняті МККТТ (зараз ITU-T) в 1991 р Підмножина зазначених рекомендацій має становити профіль захисту інформації в ІС з урахуванням розподілу функцій захисту інформації за рівнями концептуальної моделі ІС і взаємозв'язку функцій і застосовуваних механізмів захисту інформації. При використанні профілю захисту інформації в ході проектування, розробки та супроводу ІС доцільно враховувати методичні рекомендації, викладені в інтерпретації "Помаранчевої книги" національного центру комп'ютерної безпеки США для мережевих конфігурацій. Профіль захисту інформації повинен включати в себе вказівки на методи і засоби виявлення в застосовуваних апаратних і програмних засобах декларованих можливостей ("закладок" і вірусів). Профіль повинен також містити вказівки на методи і засоби резервного копіювання інформації і відновлення інформації при відмовах і збоях апаратури системи.

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

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

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

Пояснимо сказане раніше на конкретному прикладі [18]. Потрібно побудувати профілі основних функціональних компонент корпоративної ІТ компанії, яка хотіла б забезпечити переносимість розроблюваних нею SQL-додатків (як серверної, так і клієнтських частин), написаних з використанням мов C + + і SQL. Мережева інфраструктура даної організації заснована на використанні локальної мережі FDDI (рис. 7.8).

Приклад корпоративної інформаційної технології

Рис. 7.8. Приклад корпоративної інформаційної технології

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

Позначимо для визначеності профіль клієнтської сторони системи (Client Side of System) як <PC>. Він буде включати в себе специфікації як мінімум двох класів інтерфейсів, а саме інтерфейсу API, визначального взаємодія клієнтської системи з прикладної програмою (Application Program), а також комунікаційного інтерфейсу, визначального складу протоколів мережевого взаємодії між клієнтськими і серверними системами.

Комунікаційний інтерфейс можна формувати, починаючи з потужного протоколу прикладного рівня RDA (ISO 9579), використовуваного, зокрема, для реалізації розподілених SQL-додатків з архітектурою "клієнт-сервер" над стеком протоколів моделі RM OSI. Для більшої гнучкості рішення розіб'ємо стекпротоколів моделі RM OSI на дві групи протоколів: протоколи верхніх трьох рівнів, які позначимо OSI Stack (7-5), і протоколи транспортної системи, що забезпечують транспортні послуги OSI в режимі з з'єднанням.

Якщо звернутися до довідника міжнародних стандартизованих профілів, то можна виявити, що вже існує профіль, що описує набір протоколів для реалізації передачі даних по транспортному протоколу OSI через локальну мережу FDDI. Даний профіль має найменування <ТС54>. Він включає в себе посилання на стандарт транспортного протоколу OSI, стандарт протоколу мережевого рівня (Х.25) разом з доповненнями, пристосовують цей протокол для використання в локальних мережах, а також посилання на стандарти протоколів нижніх рівнів, що визначають функціонування мережі FDDI. Профіль <ТС54> є типовим прикладом OSI-профілю, так як встановлює тільки функції мережевої взаємодії, визначені стандартними протоколами, розробленими відповідно до моделі RM OSI.

Таким чином, опис комунікаційного інтерфейсу в профілі <РС> буде містити посилання на такі специфікації: стандарт протоколу DRA, стандарти протоколів верхніх рівнів моделі RM OSI (OSI Stack (7-5)), профіль <ТС54>.

До складу специфікацій API необхідно включити стандарти мов <С + +> і <SQL> (Std "C ++" і Std "SQL" відповідно), а також інтерфейс RDA, який реалізує сервіс протоколу RDA для клієнтських систем. Отже, опис інтерфейсу API в профілі <РС> містить посилання на такі специфікації: Std "C ++", Std "SQL", інтерфейс RDA-клієнта.

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

Профіль серверної частини (Server Side of System) позначимо як <PS>. Він міститиме ідентичний з профілем <РС> комунікаційний інтерфейс (інакше клієнтські і серверні системи не змогли б взаємодіяти). Інтерфейс API профілю <PS> буде майже ідентичним відповідному інтерфейсу профілю <РС>, за винятком деяких відмінностей в програмних інтерфейсах для сервісу RDA в клієнтській і сервісних системах.

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

Відповідно до введених визначеннями, побудовані в прикладі профілі <РС> і <PS> ставляться до OSE-профілів. З метою наочного уявлення випадків застосування і функціональності профілів використовуються спеціальні схеми (сценарії), на яких, як правило, визначаються основні функціональні компоненти описуваної даними профілем технології, їх взаємозв'язку, інтерфейси, розподіл основних функцій у системі та ін. Для профілів <РС> і <PS> таким сценарієм може служити схема, показана на рис. 7.9.

Приклад схеми (сценарію) для наочного подання випадків застосування і функціональності профілів

Рис. 7.9. Приклад схеми (сценарію) для наочного подання випадків застосування і функціональності профілів

Якщо ж комунікаційна структура компанії була б побудована на базі Intranet, то в цьому випадку слід перепроектувати профіль, замінивши <Т54>, наприклад, на профіль <Ti>, заснований на використанні наступних стандартів:

  • • RFC +1006 (IETF STD 35). ISO Transport Service on top the TCP;
  • • RFC 793 (IETF STD 7). Transmission Control Protocol (TCP);
  • • RFC 791 (IETF STD 5). Internet Protocol (IP);
  • • RFC +1390 (IETF STD 36). Transmission of IP and ARP over FDDI Networks;
  • • ISO 9314 FDDI LAN.

Основна ідея побудови нової транспортної системи <Ti> полягає у використанні протоколу TS (RFC 1006), емулює інтерфейс протоколу TP OSI над стеком протоколів TCP / IP, а також протоколу (RFC 1390), що забезпечує передачу IP-пакетів через мережу FDDI. Протокольна структура транспортної системи <Ti> представлена на рис. 7.10.

Стек протоколів кінцевої системи, що реалізує транспортний сервіс ТР OSI над стеком протоколів TCP / IP і FDD I

Рис. 7.10. Стек протоколів кінцевої системи, що реалізує транспортний сервіс ТР OSI над стеком протоколів TCP / IP і FDD I

Слід зауважити, що профіль <Ti> відноситься до класу комунікаційних профілів. Однак за визначенням він не є OSI-профілем, оскільки містить посилання на стандарти, що не входять до складу стандартів моделі OSI. Проте із цим застереженням цей профіль можна успішно застосовувати при компонуванні основного профілю.

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

На основі профілю повинні проводитися тестування і сертифікація додатків на відповідність вимогам відкритості. Основу більшості вживаних в даний час профілів складають стандарти серії POSIX. Загальний їх перелік складається з більше 45 найменувань, перелік російських стандартів у галузі реалізації відкритих систем в даний час містить близько сотні найменувань [4, 26].

  • [1] Див .: Олейников, А. Я. Проектування профілю iнформацiйних, обчислювальних та телекомунікаційних ресурсів галузі / А. Я. Олейников, Е. Е. Журавльов. [Електронний ресурс] Режим доступу: cplire.ru/rus/casr/ os / 3_12 / 10/15 / text.htm.
 
Якщо Ви помітили помилку в тексті позначте слово та натисніть Shift + Enter
< Попередня   ЗМІСТ   Наступна >
 
Дисципліни
Агропромисловість
Аудит та Бухоблік
Банківська справа
БЖД
Географія
Документознавство
Екологія
Економіка
Етика та Естетика
Журналістика
Інвестування
Інформатика
Історія
Культурологія
Література
Логіка
Логістика
Маркетинг
Медицина
Нерухомість
Менеджмент
Педагогіка
Політологія
Політекономія
Право
Природознавство
Психологія
Релігієзнавство
Риторика
Соціологія
Статистика
Техніка
Страхова справа
Товарознавство
Туризм
Філософія
Фінанси
Пошук