Архітектура інтегрованої міжвідомчої інформаційної системи як композиція відомчих інформаційних систем
Розглядається архітектура інтегрованої міжвідомчої інформаційної системи, яка враховує можливі варіанти схем взаємодії в межах
 системи її структурних компонентів – відомчих інформаційних систем – та підхід до її побудови, на заданій платформі програмно-
 апаратних засобів за допомог...
Збережено в:
| Дата: | 2004 |
|---|---|
| Автори: | , |
| Формат: | Стаття |
| Мова: | Українська |
| Опубліковано: |
Інститут програмних систем НАН України
2004
|
| Теми: | |
| Онлайн доступ: | https://nasplib.isofts.kiev.ua/handle/123456789/2295 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Цитувати: | Архітектура інтегрованої міжвідомчої інформаційної системи як композиція відомчих інформаційних систем / В.А. Алексєєв, В.С. Терещенко // Проблеми програмування. — 2004. — N 2,3. — С. 397-408. — Бібліогр.: 5 назв. — укр. |
Репозитарії
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1860241461342109696 |
|---|---|
| author | Алексєєв, В.А. Терещенко, В.С. |
| author_facet | Алексєєв, В.А. Терещенко, В.С. |
| citation_txt | Архітектура інтегрованої міжвідомчої інформаційної системи як композиція відомчих інформаційних систем / В.А. Алексєєв, В.С. Терещенко // Проблеми програмування. — 2004. — N 2,3. — С. 397-408. — Бібліогр.: 5 назв. — укр. |
| collection | DSpace DC |
| description | Розглядається архітектура інтегрованої міжвідомчої інформаційної системи, яка враховує можливі варіанти схем взаємодії в межах
системи її структурних компонентів – відомчих інформаційних систем – та підхід до її побудови, на заданій платформі програмно-
апаратних засобів за допомогою методів формального аналізу функцій її компонентів.
The architecture of the integrated interdepartmental information system is considered which takes into account possible variants of the
schemes of interaction within the framework of the system it of structural components - departmental information systems – and approach to
it to construction, on the given platform of hardware-software tools with the help of methods of the formal analysis of functions it of making
components.
|
| first_indexed | 2025-12-07T18:30:05Z |
| format | Article |
| fulltext |
D:\Проблемы программирования\Конф-04\2004-2-3\D7.DOC Дата печати 08.07.2008 18:11:00
1
АРХІТЕКТУРА ІНТЕГРОВАНОЇ МІЖВІДОМЧОЇ ІНФОРМАЦІЙНОЇ
СИСТЕМИ ЯК КОМПОЗИЦІЯ ВІДОМЧИХ ІНФОРМАЦІЙНИХ
СИСТЕМ Алексєєв В. А., Терещенко В. С.
Інститут програмних систем НАН України, 03187 м. Київ, просп. Академіка Глушкова, 40, тел./факс.2664228,
E-mail: alecseev@d19.isofts.kiev.ua
Розглядається архітектура інтегрованої міжвідомчої інформаційної системи, яка враховує можливі варіанти схем взаємодії в межах
системи її структурних компонентів – відомчих інформаційних систем – та підхід до її побудови, на заданій платформі програмно-
апаратних засобів за допомогою методів формального аналізу функцій її компонентів.
The architecture of the integrated interdepartmental information system is considered which takes into account possible variants of the
schemes of interaction within the framework of the system it of structural components - departmental information systems – and approach to
it to construction, on the given platform of hardware-software tools with the help of methods of the formal analysis of functions it of making
components.
Вступ
При виникненні задач загальнодержавного масштабу, що потребують зусиль декількох відомств, постає
проблема у створенні міжвідомчої інформаційної системи, яка б інтегрувала інформаційні ресурси систем тих
відомств, що задіяні до вирішення таких задач. При об’єднанні відомчих інформаційних систем (ВІС) в
інтегровану міжвідомчу інформаційну систему (ІМІС), а це об’єднання носить не тільки організаційний
характер, тобто агрегацію ВІС у ІМІС, а й програмно-технічний, виникає потреба задіяти весь комплекс робіт,
пов’язаний з життєвим циклом розробки програмного продукту. Цей цикл складається з п’яти стадій розробки:
аналізу вимог, проектування, реалізації, тестування готової системи та її дослідної експлуатації [1,2]. При
цьому, під час проектування архітектури такої системи, виникає багато питань з інформаційної взаємодії ВІС,
обміном інформацією між ними, у складі ІМІС. До того ж, в ІМІС окрім операцій, характерних для кожної ВІС,
додаються ще операції з обробки запитів ВІС, пошуку відомчої бази даних (ВБД), де є інформація, що може
задовольнити цей запит, адресацію запита, маршрутизацію та передачу його до необхідної ВБД, отримання
потрібної інформації, обробка її (надання форми впорядкованого структурованого файла) та транспортування в
зворотному напрямку до клієнта. Перелік та послідовність цих операцій може бути дещо іншим: це, перш за
все, залежить від архітектури ІМІС, її бази даних, а може й від архітектур відомчих інформаційних систем та їх
баз даних. Саме схемам (технологіям) інформаційної взаємодії ВІС та побудові загальної архітектурної схеми
ІМІС і присвячена ця робота.
1. Схеми взаємодії відомчих інформаційних систем в інтегрованій міжвідомчій
інформаційній системі
При вирішені задач пошуку інформації, яка відсутня у базі даних відомчої інформаційної системи,
оскільки не є профільною для даного відомства, виникають проблеми, пов'язані зі звертанням до ВІС інших
відомств, де така інформація може бути. Не будемо розглядати все коло проблем, зупинимось лише на одній
його частині, а саме на програмно-технічному аспекті, а точніше – на архітектурі інтегрованої міжвідомчої
інформаційної системи, що дозволяє реалізувати пошук необхідної інформації у відомчих базах даних, оскільки
вона інтегрована з ними і працює в інтересах відомств (так би мовити, членів-засновників цієї ІМІС), що
підключені до неї.
Відомо, що основною частиною будь-якої інформаційної системи є база даних. Її архітектура накладає
відбиток на проектні рішення щодо архітектури всієї автоматизованої інформаційної системи (ІС), взаємодії
окремих її компонентів. Для ІМІС ця залежність особливо характерна.
При проектуванні БД ІМІС і визначенні її архітектури, на наш погляд, можуть бути застосовані п'ять
основних варіантів створення інтегрованих міжвідомчих інформаційних систем, які враховують можливі схеми
взаємодії між ВІС в рамках ІМІС і базуються на [3]:
- "віртуальній" міжвідомчій базі даних (МБД);
- "віртуальній" міжвідомчій базі даних з центром обробки запитів;
- окремій спеціально створеній міжвідомчій базі даних;
- територіально розподіленій, інтегрованій у відомчі БД міжвідомчій базі даних з центром обробки
запитів;
- інтегрованій з БД ВІС міжвідомчій базі даних.
Кожний з варіантів має свої позитивні сторони, але має й вади. Тому при побудові конкретної
інформаційної системи треба дуже ретельно проаналізувати позитивні й негативні сторони цих підходів.
1.1. Схема взаємодії ВІС на "віртуальній" міжвідомчій базі даних. Перший варіант (ІМІС на
"віртуальній" міжвідомчій базі даних) виходить з того, що саму міжвідомчу базу даних будувати не треба.
Достатньо тільки організаційних домовленостей та технічних двосторонніх узгоджень між зацікавленими
відомствами з інформаційної взаємодії між відомчими інформаційними системами. Навіть програмних засобів
не треба розробляти. Для передачі запитів від ВІС-кореспондента одного відомства до БД ВІС-абонента іншого
D:\Проблемы программирования\Конф-04\2004-2-3\D7.DOC Дата печати 08.07.2008 18:11:00
2
та відповідей від БД ВІС-абонента до ВІС-кореспондента достатньо лише певних каналів зв'язку: виділених,
комутованих або мережі передачі даних (МПД) з телекомунікаційними центрами. Але при цьому у кожній ВІС,
що працює в режимі кореспондента, необхідно мати фахівців, які б при формуванні інформаційного запиту
(наприклад, у SQL-форматі) до БД ВІС-абонента іншого відомства добре орієнтувались у структурі тієї БД,
куди цей запит адресовано, і мали відповідний доступ до неї.
Тут і починаються труднощі. По-перше, ніхто з володарів БД не хоче пускати "сусіда у свій город", не
кажучи вже про різного роду системи захисту відомчої інформації та про грифи доступу до неї. І це не тільки
“психологічний фактор”. Багаторічний досвід свідчить, що доступ до структури бази даних можна дозволяти
тільки проектувальникам та її розробникам. Для користувачів залишається базова інформація тільки в режимі
читання при санкціонованому доступі. По-друге, БД є програмний продукт, а кожний програмний продукт
підлягає загальновизнаному закону програмної інженерії – закону еволюції, котрий формулюється таким
чином: кожна діюча програмна система з часом потребує змін або перестає використовуватись [4]. Тому
практично на кожній базі даних весь час ведуться доопрацювання (з метою модернізації і удосконалення
існуючої БД або для вилучення похибок, що виявились у процесі її експлуатації), що так чи інакше впливають
на структуру БД, а це вимагає весь час інформувати фахівців взаємодіючих ВІС зацікавлених відомств про
зміни в БД. Тут вже “втручається” людський фактор, який часто приводить до збоїв у взаємодії ВІС і, як
результат, при достатньо великій кількості взаємодіючих ВІС таку ІМІС буде весь час лихоманити. І навпаки,
якщо взаємодіє невелика кількість ВІС і потік запитів невеликий, то цей варіант може бути найліпшим, бо не
потребує великих фінансових витрат і реалізувати його можна у найкоротший термін.
Блок-схема такої ІМІС з “віртуальною” базою даних у вигляді взаємодіючих ("кожний з кожним")
через мережу виділених каналів ВІС представлена на рис.1.
Рис. 1 Схема взаємодії ВІС через мережу виділених каналів зв’язку для ІМІС з “віртуальною” МБД
У цьому варіанті, як і в інших, кожна ВІС може виступати і як клієнт по відношенню до своєї БД та БД
інших ВІС (в архітектурі “клієнт – сервер”), і як сервер БД по відношенню до своєї ВІС та ВІС інших членів –
засновників МІС.
На рис.2 представлена блок-схема такої ж самої ІМІС, але взаємодія між ВІС здійснюється через мережу
передачі даних. І хоча схема радикально змінила вигляд і принципи її технічної реалізації, це не вплинуло на
суть взаємодії (“кожний з кожним”). Кореспондент формує і направляє свій запит конкретному абонентові, а
через канал чи через МПД – це вже функціонально не суттєво для вибраного варіанту.
Рис.2. Схема взаємодії відомчих БД через МПД для ІМІС з “віртуальною” МБД
1.2. Схема взаємодії ВІС на "віртуальній" міжвідомчій БД з центром обробки запитів. При другому
варіанті проектування міжвідомчої інформаційної системи (МІС на "віртуальній" міжвідомчій базі даних з
центром обробки запитів) теж не треба будувати окрему МБД, як і у першому випадку, але треба організувати
ВІС N ВІС 1
ВІС …
ВІС j ВІС i
ВІС …
ВІС N ВІС 1
ВІС …
ВІС j
ВІС i
ВІС …
МПД
D:\Проблемы программирования\Конф-04\2004-2-3\D7.DOC Дата печати 08.07.2008 18:11:00
3
центр обробки запитів (ЦОЗ). Кожна ВІС повинна створити “віртуальні” таблиці, де буде задано параметри
даних, які власники ВІС можуть надати для загального користування. У ЦОЗ будуть знаходитися дані про
структуру цих “віртуальних” таблиць кожної ВІС. Запити від i-тої ВІС до j-тої ВІС будуть формуватися у
встановленому форматі ЦОЗ, надходити до ЦОЗ, автоматично перетворюватися у формат, властивий СКБД j-
тої ВІС (залежно від структури “віртуальної таблиці”) і направлятися до ВІС, де є інформація для відповіді на
цей запит. Відповідь на запит надходить у форматі, властивому j-й ВІС, перетворюється засобами ЦОЗ на
формат ЦОЗ і направляється до i-ї ВІС. Тобто при цьому і клієнтська частина функціонує у два етапи.
Необхідний зовнішній інтерфейс між ЦОЗ та сервером БД підтримується засобами моніторингу колективного
користування в програмній системі ЦОЗ. При цьому зникає потреба в наявності фахівців, що повинні знати
структуру баз даних "сусідів", тож і кількість можливих збоїв у взаємодії між ВІС теж значно зменшиться. Інші
недоліки першого варіанту залишаються.
Рис.3. Схема взаємодії ВІС через центр обробки запитів
1.3. Схема взаємодії ВІС на окремій спеціально створеній міжвідомчій базі даних. При третьому
варіанті проектування міжвідомчої інформаційної системи (ІМІС на окремій спеціально створеній МБД),
розробляється окрема база даних, інформація в якій постійно оновлюється в заздалегідь обумовлені строки і
обумовлених обсягах з відомчих баз даних. Кожна БД ВІС буде мати і підтримувати своєрідний локальний кеш
в програмно-технічних засобах МБД. Така ІМІС повинна мати потужний програмний інтерфейс зі всіма
взаємодіючими ВІС і відповідні технічні засоби (сервери, канали зв'язку, системи захисту інформації тощо).
Згідно з територіально-розподіленою структурою такої ІМІС необхідно забезпечити доступ з АРМ ВІС-
кореспондентів (клієнт) до ресурсів МБД-абонента (сервер). Комутація каналів та запитів у процесі теледоступу
здійснюється за допомогою стандартних програмних засобів телекомунікації (протоколів мережі), які
регламентують структуру представлення і керування обробкою інформації в мережі. При експлуатації такої
МБД не треба фахівців, що орієнтуються в структурах БД всіх ВІС. Такі фахівці вже є на кожній БД і для
формування інформаційного запиту їм треба знати лише структуру МБД (крім, зрозуміло, структури своєї БД).
При цьому значно зменшується ймовірність збоїв у взаємодії між ВБД і МБД. Обмін інформацією йде
відповідно до заздалегідь узгоджених умов, бази даних відокремлені одна від одної. Але й тут є негатив: треба
весь час підпрацьовувати програмний інтерфейс залежно від змін у відомчих БД і для цього треба мати
фахівців-програмістів певної кваліфікації.
При третьому варіанті проектування ІМІС, блок-схема взаємодії відомчих інформаційних систем з
МБД на рис.4.
ВІС N ВІС 1
ВІС …
ВІС j
ВІС i
ВІС …
ЦОЗ
D:\Проблемы программирования\Конф-04\2004-2-3\D7.DOC Дата печати 08.07.2008 18:11:00
4
Рис.4. Схема взаємодії відомчих БД через міжвідомчу базу даних
1.4. Схема взаємодії ВІС на територіально розподіленій інтегрованій у БД ВІС міжвідомчій БД з ЦОЗ.
При четвертому варіанті проектування міжвідомчої інформаційної системи (ІМІС на територіально
розподіленій інтегрованій у БД ВІС міжвідомчій БД з ЦОЗ) необхідно на кожній БД встановити спеціальні
програмно-технічні засоби (сервер з відповідним програмним забезпеченням) для зберігання та підтримки
дублікату певної, заздалегідь обумовленої, частини відомчої бази даних (своєрідного кешу). Такий дублікат і
буде відомчою підсистемою міжвідомчої бази даних (ПМБД), інформація в якій весь час оновлюватиметься,
причому відповідальність за підтримку інтерфейсу між БД ВІС та ПМБД повинна лежати на фахівцях ВІС, а
структура ПМБД визначатися розробниками МБД та узгоджуватися між фахівцями ІМІС та всіх взаємодіючих
ВІС. В такому разі не буде ніякого доступу ззовні до БД ВІС і структура її залишиться прерогативою тільки
фахівців цієї ВІС і не треба розповсюджувати інформацію про неї серед фахівців інших БД, як, наприклад, у
першому підході до проектування ІМІС. Формування запитів до МБД з боку користувачів ВІС, як і в третьому
випадку, не становитиме жодних труднощів. Сукупність всіх ПМБД разом з центром обробки запитів і складає
територіально розподілену інтегровану МБД. Більше того, кожна з цих ПМБД одночасно є й підсистемою ВІС
і, таким чином, у адміністративному, інформаційному, технічному плані пов’язана з ВІС і належить до неї, а у
організаційному і функціональному плані - з ІМІС. Відповідно до територіально-розподіленої структури такої
ІМІС, як і в попередньому випадку, необхідно забезпечити теледоступ з АРМ ВІС-кореспондентов до ресурсів
ПМБД-абонента. Необхідна комутація каналів та запитів у процесі теледоступу здійснюється за допомогою
протоколів мережі. Автоматичну маршрутизацію запитів згідно регламенту протоколів мережі забезпечує
мережевий каталог. В цьому каталозі містяться довідкові відомості про інформаційні та програмно-технічні
засоби ПМБД всіх взаємодіючих ВІС, про повноваження та пріоритети АРМ різних ВІС, про правила та
обмеження на теледоступ до ресурсів БД ВІС. По суті, мережевий каталог узагальнює локальні словники-
довідники СКБД кожної ПМБД і забезпечує ефективний інтерфейс між ними та ЦОЗ. Ця схема найбільш
прийнятна при нечастих запитах, але при постійному і частому оновленні інформації у ПМБД.
Рис.5. Схема взаємодії ВІС через територіально розподілену інтегровану міжвідомчу базу даних та її центр
обробки запитів
1.5. Схема взаємодії ВІС на інтегрованій з БД ВІС міжвідомчій базі даних. При п'ятому варіанті
проектування міжвідомчої інформаційної системи (ІМІС на інтегрованій з БД ВІС міжвідомчій БД) інтегрована
МБД не є територіально розподіленою, як це пропонувалось при четвертому варіанті. Всі ПМБД (разом зі
ВІС N ВІС 1
ВІС …
ВІС j
ВІС i
ВІС …
МБД
ВІС N ВІС 1
ВІС …
ВІС j
ВІС i
ВІС ...
ЦОЗ
ПМБД N
ПМБД …
ПМБД 1
ПМБД ...
ПМБД j ПМБД i
D:\Проблемы программирования\Конф-04\2004-2-3\D7.DOC Дата печати 08.07.2008 18:11:00
5
своїми серверами) територіально розміщуються не на площах ВБД, як у попередньому випадку, а
зосереджуються на площі центру обробки запитів. Всі інші особливості схеми взаємодії співпадають з
особливостями схеми при четвертому варіанті. Ця схема (рис.6) найбільш прийнятна при великій кількості
запитів і відносно нечастому оновленні інформації у ПМБД.
Рис.6. Схема взаємодії ВІС через інтегровану міжвідомчу базу даних та її центр обробки запитів
1.6. Порівняльний аналіз схем взаємодії ВІС у складі ІМІС. Поділ технології створення міжвідомчої
інформаційної системи на варіанти дуже умовний. Він потрібен тільки для проведення порівняльного аналізу і
визначення найкращого з них в залежності від умов ситуації.
Перший варіант схем взаємодії ВІС у межах ІМІС відрізняється від інших своєю простотою реалізації.
Для створення системи в цьому варіанті не треба розробляти спеціальні програмні засоби і не треба
спеціального обладнання. Достатньо лише мережі передачі даних. Обмін інформацією в режимі “кожний з
кожним” відбувається за допомогою транспортних файлів або файлів виду “запит – відповідь”.
Другий варіант відрізняється від першого додатковим обладнанням – центром обробки запитів і
відповідним програмним забезпеченням для обробки запитів та їх маршрутизації.
За третім варіантом на відміну від перших двох спеціально створюється окрема база даних, інформація
в якій постійно оновлюється в заздалегідь обумовлені строки і в обумовлених обсягах з відомчих баз даних.
ІМІС, що реалізована у такому варіанті, повинна мати потужний програмний інтерфейс зі всіма взаємодіючими
ВІС і відповідні технічні засоби.
Четвертий варіант відрізняється від третього наявністю на кожній БД ВІС спеціальних програмно-
технічних засобів (серверів з відповідним програмним забезпеченням) для зберігання та підтримки дублікату
певної, заздалегідь обумовленої, частини відомчої бази даних (своєрідного кешу). Саме цей кеш і взаємодіє з
центром обробки запитів.
У п’ятому варіанті на відміну від четвертого сервери з кешами розміщуються не разом з БД ВІС, а
разом з центром обробки запитів.
Одним з найважливіших питань при обміні даними між ВІС є узгодження використовуваних ними
класифікаторів. Для першого варіанту реалізації ІМІС це буде означати наявність на кожній ВІС програмних
засобів узгодження класифікаторів, що використовуються при обміні інформацією. Тобто на кожній ВІС
необхідно узгодити N “комплектів” класифікаторів. При цьому після оновлення класифікатора одним з
учасників ВІС їх необхідно оновити та узгодити на інших вузлах ІМІС, що організаційно досить важко. При
побудові ІМІС на “віртуальній” міжвідомчій БД з центром обробки запитів (другий варіант) функція
узгодження класифікаторів переміщується на ЦОЗ. Тут знаходяться таблиці відповідностей класифікаторів, що
використовуються кожним з відомств. Таким чином, при зміні в одному з класифікаторів і-ї ВІС операцію
узгодження необхідно виконати тільки в одному ЦОЗ. Цю функцію можна покласти на адміністратора ІМІС. Те
саме можна віднести до четвертого і п’ятого варіантів. Для третього варіанту (ІМІС на спеціально створеній
міжвідомчій БД) класифікатори і-ї ВІС потрібно узгоджувати з загальними класифікаторами, що
використовуються у міжвідомчих БД.
Не можна сказати, який з варіантів схем взаємодії ВІС у межах ІМІС кращий. Кожний з них має і
позитивні і негативні властивості. Тому вибір якогось з них залежить від кожного конкретного випадку.
2. Визначення загальної архітектури ІМІС
2.1. Визначення складу основних компонентів ІМІС. ІМІС не створюється на порожньому місці. Вона,
так чи інакше, складається з ВІС (якщо не повністю, то хоча б з їх окремих, спеціально розроблених,
компонентів) тих відомств, що вирішили її створити. А між ними, в багатьох випадках, вже є якісь
напрацьовані зв’язки, якась інформаційна взаємодія. Деякі з них можна розглянути на прикладах.
Приклад 1: з і-тої ВІС до j-тої ВІС постійно, у обумовлені строки, пересилається, через виділений канал
і/або через файловий та шлюзовий сервер, якась обмежена, заздалегідь обумовлена по приналежності домену
предметної галузі, класу, підкласу, структурі, об’єму і терміну передачі, інформація, що необхідна для
експлуатації функціональних задач j-тої ВІС. Тут навмисно не згадується про режим квитирування, щоб: по-
перше – не ускладнювати приклад, а по-друге – ще й тому, що цей режим, перш за все, пов’язаний з
ВІС N
ВІС 1
ВІС …
ВІС j ВІС i
ВІС …
ЦОЗ
ПМБД N
ПМБД …
ПМБД 1
ПМБД …
ПМБД j ПМБД i
D:\Проблемы программирования\Конф-04\2004-2-3\D7.DOC Дата печати 08.07.2008 18:11:00
6
організацією обміну інформації, а не з самим обміном нею. Зрозуміло, що такий спосіб обміну інформацією
може в той же час існувати й між j-тою та і-тою ВІС у зворотному напрямку. У такому разі, коли транспортні
файли передаються з обох боків (не обов’язково одночасно), між цими ВІС існує обмін інформацією у повному
розумінні цього терміну.
Приклад 2: з і-тої ВІС є змога звертатися з запитом (скажімо, в SQL-форматі) до бази даних j-тої ВІС і
отримувати інформацію, що необхідна для експлуатації функціональних задач і-тої ВІС. Таким чином, j-та
ВІС надає свої інформаційні та програмно-апаратні ресурси (якщо не в повному обсязі, то – частково,
компонентно) для користування ними іншій, у даному разі, і-тій ВІС. Як і в першому випадку, тут також
можливий такий же самий обмін інформацією у зворотному напрямку, коли j-та ВІС звертається з запитом до
і-тої ВІС.
З цих прикладів видно, що нову систему треба будувати так, щоб і старі зв’язки були органічно включені
в структуру нової ІМІС, і нові, що створюються у відповідності до прийнятих проектних рішень та вимог
замовника, додавали б можливостей для ефективного вирішення проблем інформаційної взаємодії. Це може
статись, як вже говорилось, при використанні не тільки БД ВІС, а й міжвідомчої БД – центрального сховища
даних (ЦСД) ІМІС, та при широкому застосуванні повторного використання компонент – програмних засобів та
фрагментів знань про минулий досвід, отриманих при розробці ВІС, які можна адаптувати при створенні
системи. При цьому як компоненти повторного використання, так і нові розробки повинні відрізнятись такою
властивістю, як переносність, що забезпечить пристосованість програмних засобів до переносу з одного
середовища функціонування (ВІС) в інші в межах ІМІС для здешевлення та скорочення терміну розробки.
2.2. Визначення моделі архітектури ІМІС. На практиці, може статись, що при побудові реальної ІМІС
буде доцільно використати одночасно кілька з наведених вище схем інформаційної взаємодії, тим більш, якщо
якась схема взаємодії вже реалізована в одній з частин загальної системи.
Наприклад, кілька відомств (членів-засновників ІМІС) прийняло рішення про створення міжвідомчої БД
для інформаційного обслуговування їх ВІС. Історично так склалося, що деякі з ВІС членів-засновників вже
взаємодіють між собою, передаючи певну обмежену, заздалегідь обумовлену (у зв’язку з вирішенням якихось
інших проблем) інформацію, використовуючи для цього існуючі канали зв’язку та файлові сервери. Інші ВІС, з
кола членів – засновників, взаємодіють між собою через сервери обробки запитів. При подальшому
дослідженні виявилось, що для вирішення проблем, які виникли перед членами – засновниками міжвідомчої
МІС, необхідно побудувати окрему єдину міжвідомчу БД. Це не інформаційне, а тим більш не фізичне
об’єднання всіх ВБД, а лише їх переріз (проекція), і тільки по тій інформації, що необхідна для взаємодії
відомств і вирішення посталих нових проблем. І на цьому полі вже існуючих (реалізованих) організаційних,
програмно-технічних та інформаційних (ОПТІ) рішень треба побудувати систему, що зможе органічно вмістити
в собі ці вже існуючі ОПТІ-рішення і застосувати інші нові для реалізації всієї гами цільових функцій в рамках
задач, поставлених перед системою.
Навіть поверхневе знайомство з умовами поставленої задачі підштовхує до прийняття концепції
побудови системи, що враховувала б три групи вже згаданих вище ОПТІ-рішень. Дві групи вже існуючих
ОПТІ-рішень (може, з деякою їх модернізацією), а одна група зовсім нових рішень. Висновок напрошується сам
собою: треба застосувати сучасну архітектуру трирівневої моделі “клієнт – сервер” з розмежуванням зон
відповідальності по кожному архітектурному шару: клієнтський додаток, сервер додатків, сервер баз даних [5].
2.3. Визначення складу програмно-технічних засобів підтримки інформаційної взаємодії. Реалізацією
трирівневої моделі “клієнт – сервер” у полі визначених ОПТІ-рішень стане застосування наступного набору
програмно-технічних засобів підтримки інформаційної взаємодії:
- центрального файлового серверу – для підтримки першої групи вже існуючих ОПТІ-рішень;
- центрального серверу обробки запитів – для підтримки другої групи вже існуючих ОПТІ-рішень;
- центрального сховища даних – для реалізації нових проектних ОПТІ рішень, необхідних для розв’язання
поставлених перед системою задач.
При прийнятті такої концепції побудови системи бачимо, що тут можуть бути застосовані якщо не всі
п’ять, то принаймні чотири з вищеописаних варіантів схем реалізації взаємодії ВБД у рамках МІС: перший,
другий, третій і п’ятий. Тільки за такої архітектури можливе застосування одразу декількох з можливих
технологій обміну інформацією між ВІС у межах функціонування ІМІС. А які технології взаємодії в такій
ситуації взагалі можливі? Розглянемо, так званий, функціонально повний набір таких технологій. Тут під
функціональною повнотою технологій взаємодії будемо розуміти атрибут, який показує ступінь достатності
основних функцій для розв’язання спеціальних задач відповідно до призначення програмного забезпечення, що
підтримує такі технології [4]. Для цього побудуємо поле (у вигляді таблиці, табл.1) можливих технологій
взаємодії компонентів ІМІС – ВІС та ЦСД ІМІС – при застосуванні, скажімо, двох функціонально
навантажених програмно-технічних засобів підтримки інформаційної взаємодії між ВІС та/або ЦСД:
центрального серверу обробки запитів (ЦСОЗ) та центрального файлового серверу (ЦФС). Центральними ці
засоби звуться через те, що вони є об’єднуючими елементами декількох (більше двох) ВІС, і є, так би мовити,
спільним обладнанням цих ВІС і, скоріше за все, встановлюватимуться на площі головної (центральної) ВІС,
що є ведучою серед інших в створюваній ІМІС.
D:\Проблемы программирования\Конф-04\2004-2-3\D7.DOC Дата печати 08.07.2008 18:11:00
7
2.4. Визначення функцій основних компонентів і програмно-технічних засобів ІМІС. Відомчі інформаційні
системи (ВІС 1, … , ВІС і, ВІС j, … , ВІС М) з точки зору централізованої міжвідомчої інформаційної взаємодії
реалізують наступні функції:
• отримання і-тою ВІС через ЦФС від j-тої ВІС ( i ≠ j ) або ЦСД транспортних файлів;
• завантаження інформації транспортних файлів до БД і-тої ВІС і відправлення до j-тої ВІС квитанцій
про підтвердження отримання транспортного файлу та про відповідність його синтаксичної форми;
• формування та відправлення транспортних файлів, які містять інформацію БД і-тих ВІС-абонентів, для
передачі до j-тої ВІС через ЦФС та отримання від нього квитанції про підтвердження цього,
В той же час відомчі інформаційні системи (ВІС 1, … , ВІС і, ВІС j, … , ВІС М) з точки зору централізованої
міжвідомчої обробки запитів реалізують наступні функції:
• отримання і-тою ВІС файлів-запитів через ЦСОЗ;
• формування та відправлення з і-тої ВІС файлів-відповідей до ЦСОЗ на його запити;
• формування та відправка з і-тої ВІС визначених (з заздалегідь обумовленого списку) запитів до ЦСОЗ,
• отримання та відображення на і-тій ВІС відповідей від ЦСОЗ.
Майже такі ж самі функції і у ЦСД (центрального серверу (сховища) даних ІМІС):
• отримання транспортних файлів з ЦФС;
• формування та відправлення транспортних файлів до ЦФС;
• завантаження до БД ЦСД інформації транспортних файлів, які отримані від ВІС за допомогою ЦФС;
• накопичення, збереження та ведення інтегрованої інформації міжвідомчого користування у БД ЦСД;
• отримання файлів-запитів від ЦСОЗ;
• формування та відправлення файлів-відповідей до ЦСОЗ на його запити.
Функції ЦФС (центрального файлового серверу ІМІС):
• обмін інформацією у вигляді транспортних файлів з будь-якою і-тою ВІС та ЦСД;
• збереження на визначений термін та відстрочену розсилку транспортних файлів.
Функції ЦСОЗ (центрального серверу обробки запитів ІМІС):
• обмін інформацією “запит-відповідь” з БД ВІС та ЦСД;
• ведення БД відповідності критеріїв пошуку та реквізитів БД ВІС;
• обробка та збереження на визначений термін запитів від ВІС;
• формування запитів до БД ВІС та ЦСД;
• обробка та збереження на визначений термін відповідей від ВІС на запити;
• інформування ВІС про наявність відповідей на їх запити.
3. Побудова схеми архітектури ІМІС
3.1. Визначення складу формально можливих технологій інформаційної взаємодії. З позицій формально-
аналітичного підходу, тобто з точки зору формальної логіки, декомпозиція функцій цих засобів, а вірніше
декомпозиція можливостей ВІС та можливостей ЦСД, що з’явились (або значно зросли) завдяки застосуванню
цих засобів, допоможе побудувати поле можливих технологій взаємодії ВІС та/або ЦСД в рамках ІМІС, що
використовує ЦСОЗ та ЦФС. При цьому, зрозуміло, і можливості всієї ІМІС також значно зросли. Згадане поле
можна побудувати застосувавши графічні засоби перерізу множин формальних можливостей двох ВІС або ВІС
і ЦСД (щоб весь час не повторювати цю словосполуку, назвемо ВІС та ЦСД базовими об’єктами (БО)), для
забезпечення інформаційної взаємодії яких використано ЦСОЗ та ЦФС (для кожного випадку окремо). Інакше
кажучи, побудувавши на цих множинах матрицеподібну графічну структуру, де підполя можливостей
інформаційної взаємодії БО через ЦСОЗ розміщені вертикально, підполя можливостей інформаційної взаємодії
БО через ЦФС розміщені горизонтально. На перетині цих підполів і з’являться чарунки з формально
можливими технологіями інформаційної взаємодії на вибраній платформі програмно-технічних засобів.
Розглянемо детальніше такі технології дослідивши окремо реалізацію стосунків БО з БО через
посередництво ЦФС та стосунки БО з БО через посередництво ЦСОЗ (див. рис.1.а). Інакше кажучи, технології
інформаційної взаємодії двох видів: 1-й вид – за допомогою транспортних файлів, 2-й вид – за допомогою
файлів типу “запит-відповідь”. На цьому рисунку повинно було б навести три таблиці – для різних відносних
сполучень базових об’єктів:
• для першої таблиці – сполучення БО ВІС↔ЦСОЗ↔ВІС для вертикальних підполів та сполучення БО
ВІС↔ЦФС↔ВІС для горизонтальних підполів (сполучення 1);
• для другої таблиці – сполучення БО ВІС↔ЦСОЗ↔ЦСД для вертикальних підполів та сполучення БО
ВІС↔ЦФС↔ЦСД для горизонтальних підполів (сполучення 2);
• для третьої таблиці – сполучення БО ЦСД↔ЦСОЗ↔ВІС для вертикальних підполів та сполучення БО
ЦСД↔ЦФС↔ВІС для горизонтальних підполів (сполучення 3).
Тіло ж самих таблиць залишиться незмінним. Тому обмежимось однією таблицею, маючи на увазі, що можуть
бути різні варіанти сполучень базових об’єктів.
З позицій описаного формально-аналітичного підходу обмін інформацією (взаємодія 1-го виду –
транспортними файлами) між базовими об’єктами через ЦФС може мати 4 стани (список 1):
• базовий об’єкт тільки формує і відправляє через ЦФС транспортні файли,
D:\Проблемы программирования\Конф-04\2004-2-3\D7.DOC Дата печати 08.07.2008 18:11:00
8
• базовий об’єкт формує, відправляє і отримує транспортні файли через ЦФС,
• базовий об’єкт тільки отримує транспортні файли через ЦФС,
• базовий об’єкт не підключено до ЦФС (тобто немає ніяких стосунків).
Для іншого випадку, обмін інформацією (взаємодія 2-го виду – файлами типу “запит-відповідь”) між
базовими об’єктами через ЦСОЗ теж можуть мати 4 стани (список 2):
• базовий об’єкт не підключено до ЦСОЗ (тобто немає ніяких стосунків),
• базовий об’єкт задає через ЦСОЗ тільки запити, не отримуючи відповідей (це вироджений стан),
• базовий об’єкт задає запити і отримує відповіді через ЦСОЗ,
• базовий об’єкт отримує відповіді через ЦСОЗ, не задаючи при цьому ніяких запитів (це також вироджений
стан).
Саме ці стани стосунків між базовими об’єктами через ЦСОЗ та між базовими об’єктами через ЦФС і
визначають поле можливих технологій взаємодії базових об’єктів один з одним в рамках ІМІС (табл.1).
Таблиця поля можливих технологій взаємодії БО у рамках ІМІС Табл.1
БО ↔ ЦСОЗ ↔ БО
Переріз множин можливостей ВІС
на вибраній платформі Нема
взаємодії
Запит Запит,
відповідь
Відповідь
Відправлення
транспортного файлу
ФМТІВ-1
ФМТІВ-2
ФМТІВ-3
ФМТІВ-4
Відправлення, отримання
транспортного файлу
ФМТІВ-5
ФМТІВ-6
ФМТІВ-7
ФМТІВ-8
Отримання
транспортного файлу
ФМТІВ-9
ФМТІВ-10
ФМТІВ-11
ФМТІВ-12
Б
О
↔
Ц
Ф
С
↔
Б
О
Нема взаємодії
ФМТІВ-13
ФМТІВ-14
ФМТІВ-15
ФМТІВ-16
Розглянемо наведені у табл.1 формально можливі технології інформаційної взаємодії (ФМТІВ), з точки
зору формальної логіки, з загальної їх множини на полі можливих технологій (їх 16 видів) інформаційної
взаємодії базових об’єктів:
• ФМТІВ-1 – періодичне, в заздалегідь визначені терміни, формування і відправлення транспортних
файлів (взаємодія 1-го виду) структурованої інформації за узгодженим списком з одного БО через ЦФС до
іншого БО (ця технологія нагадує вище наведений прикл. 1);
• ФМТІВ-2 – додатково до ФМТІВ-1 додаються можливості періодичного задавання запитів без
можливості отримання на них відповідей;
• ФМТІВ-3 – додатково до ФМТІВ-1 додаються можливості періодичного задавання запитів та отримання
на них відповідей (взаємодія двох видів);
• ФМТІВ-4 – додатково до ФМТІВ-1 додаються можливості періодичного отримання відповідей на
незадані запити;
• ФМТІВ-5 – періодичне, в заздалегідь визначені терміни, формування, відправлення і отримання
транспортних файлів (взаємодія 1-го виду) структурованої інформації за узгодженим списком з одного БО
через ЦФС до іншого БО (ця технологія теж нагадує вище наведений прикл. 1);
• ФМТІВ-6 – додатково до ФМТІВ-5 додаються можливості періодичного задавання запитів без
можливості отримання на них відповідей;
• ФМТІВ-7 – додатково до ФМТІВ-5 додаються можливості періодичного задавання запитів та отримання
на них відповідей (взаємодія двох видів);
• ФМТІВ-8 – додатково до ФМТІВ-5 додаються можливості періодичного отримання відповідей на
незадані запити;
• ФМТІВ-9 – періодичне, в заздалегідь визначені терміни, отримання транспортних файлів (взаємодія 1-го
виду) структурованої інформації за узгодженим списком через ЦФС від іншого БО (ця технологія теж
нагадує вище наведений прикл. 1);
• ФМТІВ-10 – додатково до ФМТІВ-9 додаються можливості періодичного задавання запитів без
можливості отримання на них відповідей;
• ФМТІВ-11 – додатково до ФМТІВ-9 додаються можливості періодичного задавання запитів та отримання
на них відповідей (взаємодія двох видів);
• ФМТІВ-12 – додатково до ФМТІВ-9 додаються можливості періодичного отримання відповідей на
незадані запити;
• ФМТІВ-13 – БО не можуть обмінюватись інформацією через відсутність з’єднань з ЦСОЗ та ЦФС;
• ФМТІВ-14 – періодичне задавання запитів від одного БО до іншого БО без отримання на них відповідей;
• ФМТІВ-15 – періодичне задавання запитів від одного БО до іншого БО та отримання на них відповідей
(взаємодія 2-го виду);
• ФМТІВ-16 – періодичне отримання одним з БО відповідей від іншого БО на незадані запити.
D:\Проблемы программирования\Конф-04\2004-2-3\D7.DOC Дата печати 08.07.2008 18:11:00
9
3.2. Реально можливі технології взаємодії. Деякі з технологій взаємодії, що наведені у списку не
можуть бути реалізовані у повному обсязі (реалізація взаємодії двох видів), вони є виродженими. Вироджений
стан це такий стан, який, з точки зору формальної логіки, можливий зі всієї множини станів, але суперечить
здоровому глузду, наприклад, навіщо задавати запити, якщо не отримуєш відповідей, або звідки візьмуться
відповіді, якщо не було запитів.
При проведенні аналізу наведеного переліку технологій для першого сполучення базових об’єктів
(ВІС↔ЦСОЗ↔ВІС для вертикальних підполів та ВІС↔ЦФС↔ВІС для горизонтальних підполів),
застосовуючи попереднє твердження, на можливість чи не можливість їх реалізації на даний час можна зробити
висновок, що технології:
ФМТІВ-3, 7, 11 – реалізують обидва види взаємодії,
ФМТІВ-1, 2, 4, 5, 6, 8, 9, 10, 12 – реалізують перший вид взаємодії,
ФМТІВ-15 – реалізують другий вид взаємодії,
ФМТІВ-13, 14, 16 – не реалізують ніякої взаємодії.
При проведенні аналізу переліку технологій для другого сполучення базових об’єктів
(ВІС↔ЦСОЗ↔ЦСД для вертикальних підполів та ВІС↔ЦФС↔ЦСД для горизонтальних підполів) витікає той
же результат, що й у попередньому випадку.
При проведенні аналізу переліку технологій для третього сполучення базових об’єктів
(ЦСД↔ЦСОЗ↔ВІС для вертикальних підполів та ЦСД↔ЦФС↔ВІС для горизонтальних підполів) можна
зробити висновок, що для даного випадку жодна з технологій не може бути реалізована.
Підсумовуючи проведені вище операції, можна стверджувати, що на даний час реально можливі до
реалізації тільки шість комплексних технологій інформаційної взаємодії (реалізують обидва види взаємодії)
ВІС між собою та з ЦСД у межах ІМІС, що використовує в якості складових програмно-апаратної платформи
ЦФС та ЦСОЗ. Три з цих технологій інформаційної взаємодії використовуються для обміну інформацією між
ВІС і ВІС, а три – між ВІС і ЦСД (Табл.2).
Таблиця відповідності РМТІВ, ФМТІВ та елементів матриці ( Табл.2 )
П.п. РМТІВ ФМТІВ
1 РМТІВ-1 ФМТІВ-3 (сполучення БО 1)
2 РМТІВ-2 ФМТІВ-7 (сполучення БО 1)
3 РМТІВ-3 ФМТІВ-11 (сполучення БО 1)
4 РМТІВ-4 ФМТІВ-3 (сполучення БО 2)
5 РМТІВ-5 ФМТІВ-7 (сполучення БО 2)
6 РМТІВ-6 ФМТІВ-11 (сполучення БО 2)
Таким чином, при наявності всіх, перелічених у таблиці, технологій РМТІВ у спроектованій
архітектурі ІМІС можна бути впевненим, що всі можливі види інформаційних взаємодій між ВІС в ній
передбачені.
3.3. Визначення схемних архітектурних рішень. З перелічених у таблиці реально можливих
комплексних технологій інформаційної взаємодії, між ВІС як між собою, так і з ЦСД, для ІМІС, в якій
використовуються для обміну інформацією обидва засоби програмно-апаратної платформи: ЦФС та ЦСОЗ,
випливають схемні комунікаційні рішення. Для їх дослідження треба записати схемні рішення у вигляді
трьохланкових ланцюжків, в яких у крайніх ланках записано абревіатури базових об’єктів, а посередині або
ЦФС, або ЦСОЗ для кожної РМТІВ.
РМТІВ-1: ТФ - ВІС → ЦФС → ВІС, (Л1)
З - ВІС → ЦСОЗ → ВІС, В - ВІС ← ЦСОЗ ← ВІС, (Л2)
РМТІВ-2: ТФ - ВІС → ЦФС → ВІС, (Л3)
ТФ - ВІС ← ЦФС ← ВІС, (Л4)
З - ВІС → ЦСОЗ → ВІС, В - ВІС ← ЦСОЗ ← ВІС, (Л5)
РМТІВ-3: ТФ - ВІС ← ЦФС ← ВІС, (Л6)
З - ВІС → ЦСОЗ → ВІС, В - ВІС ← ЦСОЗ ← ВІС, (Л7)
РМТІВ-4: ТФ - ВІС → ЦФС → ЦСД, (Л8)
З - ВІС → ЦСОЗ → ЦСД, В - ВІС ← ЦСОЗ ← ЦСД, (Л9)
РМТІВ-5: ТФ - ВІС → ЦФС → ЦСД, (Л10)
ТФ - ВІС ← ЦФС ← ЦСД, (Л11)
З - ВІС → ЦСОЗ → ЦСД, В - ВІС ← ЦСОЗ ← ЦСД, (Л12)
РМТІВ-6: ТФ - ВІС ← ЦФС ← ЦСД, (Л13)
З - ВІС → ЦСОЗ → ЦСД, В - ВІС ← ЦСОЗ ← ЦСД. (Л14)
Якщо зібрати до купи співпадаючі ланцюжки і записати їх у вигляді смужок, то ці смужки будуть
відповідати окремим схемним рішенням:
Схемне рішення 1- Л1, Л3, Л4, Л6
Схемне рішення 2- Л2, Л5, Л7
Схемне рішення 3- Л8, Л10
Схемне рішення 4- Л9, Л12, Л14
D:\Проблемы программирования\Конф-04\2004-2-3\D7.DOC Дата печати 08.07.2008 18:11:00
10
Схемне рішення 5- Л11, Л13
Таким чином, із всього вище сказаного можна зробити висновок, що одержані в попередніх викладках
реально можливі технології інформаційної взаємодії можна реалізувати за допомогою п’яти схемних
комунікаційних рішень (СКР) в архітектурі інтегральної міжвідомчої інформаційної системи. Ось вони –
СКР 1 - ВІС через ЦФС взаємодіє з ВІС (перший вид взаємодії)
СКР 2 - ВІС через ЦСОЗ взаємодіє з ВІС (другий вид взаємодії)
СКР 3 - ВІС через ЦФС взаємодіє з ЦСД (перший вид взаємодії)
СКР 4 - ВІС через ЦСОЗ взаємодіє з ЦСД (другий вид взаємодії)
СКР 5 - ЦСД через ЦФС взаємодіє з ВІС (перший вид взаємодії)
3.4. Побудова концептуальної схеми архітектури ІМІС. Маючи набір схемних комунікаційних
рішень, що були одержані аналітичним шляхом (за допомогою формальних перетворень), неважко синтезувати
на них концептуальну схему архітектури ІМІС. Така ІМІС складається, з ВІС і ЦСД – це базові об’єкти
(територіально-розподілені БД) системи та засоби програмно-апаратної платформи – ЦФС і ЦСОЗ. Кожному з
цих СКР можна поставити у відповідність фрагмент концептуальної схеми, яка виконує ту ж функцію, що й
схемне рішення (рис.7) та побудувати синтезовану із СКР концептуальну схему архітектури ІМІС (рис. 8).
Рис. 7. Графічне зображення схемних комунікаційних рішень: a) СКР 1 (ВІС з ВІС через ЦФС),b)СКР2 (ВІС з
ВІС через ЦСОЗ), c) СКР 3 (ВІС з ЦСД через ЦФС), d) СКР 4 (ВІС з ЦСД через ЦСОЗ), e) СКР 5 (ЦСД з ВІС
черезЦФС)
D:\Проблемы программирования\Конф-04\2004-2-3\D7.DOC Дата печати 08.07.2008 18:11:00
11
Рис.8. Концептуальна схема архітектури ІМІС, що побудована на наборі СКР.
На попередніх рисунках (рис.7, рис.8) застосовані наступні умовні скорочення найменувань
інформаційних потоків:
ТФ-1,2,3 - транспортні файли відповідно: першого типу (з і-тої ВІС до ВБД якоїсь іншої ВІС через ЦФС),
другого типу (з і-тої ВІС до ЦСД через ЦФС), третього типу (з ЦСД до якоїсь ВІС через ЦФС) з потоку
транспортних файлів,
З-1,2 - запити відповідно: першого типу (з і-тої ВІС до ВБД якоїсь іншої ВІС через ЦСОЗ), другого типу (з і-
тої ВІС до ЦСД через ЦСОЗ) з потоку запитів,
В-1,2 - відповідь на запит відповідно: першого типу (з ВБД і-тої ВІС до якоїсь іншої ВІС через ЦСОЗ),
другого типу (з ЦСД до якоїсь ВІС через ЦСОЗ) з потоку відповідей.
На концептуальній схемі (рис.8), для її структурної завершеності, застосовано ще два нових програмно-
технічних засоби: основний та резервний центральний шлюзовий сервер (ЦШС). Але вони функціонально не
впливають на характер стосунків між відомчими інформаційними системами та ЦСД тому що ЦШС призначено
виключно для моніторингу та аудиту операцій по обміну інформацією і не несе функціонального навантаження.
Транспортні файли на схемі розбиті по типах в залежності від функціонального (з точки зору забезпечення
обміну інформацією між базовими об'єктами системи) навантаження на кожного з них. Те ж саме можна
сказати й про файли-запити та про файли-відповіді.
З урахуванням всього вище викладеного та урахуванням функцій відомчих інформаційних систем та
інших складових компонентів інтегральної міжвідомчої інформаційної системи: центрального сховища
(серверу) даних, центрального файлового серверу, центрального серверу обробки запитів і центрального
шлюзового серверу можна зробити висновок, що для такої архітектури достатньо п’яти схемних
комунікаційних рішень інформаційної взаємодії компонет. Вони відповідають функціонально-повному набору
можливих технологій взаємодії складових ІМІС. Кожне з цих рішень відповідає певній технології обміну
інформацією (ТОІ), що повинна бути реалізованою в реальній архітектурній схемі ІМІС. Нижче наведено
перелік таких ТОІ:
� періодична, в заздалегідь визначені строки, передача з однієї ВІС через ЦФС до іншої ВІС
структурованої інформації за узгодженим списком – ТОІ-1;
� ініційована спорадичними (за потребою) запитами передача з однієї ВІС через ЦСОЗ до іншої
(ініціюючої запит) ВІС структурованої і вибраної у відповідності до запиту інформації – ТОІ-2;
� періодична, в заздалегідь визначені строки, передача зі всіх ВІС через ЦФС до ЦСД структурованої
інформації за узгодженими списками – ТОІ-3;
� ініційована спорадичними (за потребою) запитами передача з ЦСД через ЦСОЗ до ініціюючої запит
ВІС структурованої і вибраної у відповідності до запиту інформації – ТОІ-4;
� періодична, в заздалегідь визначені строки, передача з ЦСД через ЦФС до кожної ВІС окремо
спеціально вибраної і структурованої інформації за узгодженими списками – ТОІ-5.
3.5. Аналіз архітектури ІМІС на функціональну повноту технологій взаємодії. Маючи набір схемних
комунікаційних рішень, що були одержані аналітичним шляхом, можна не тільки синтезувати з них
концептуальну схему архітектури інтегральної міжвідомчої інформаційної системи, але й перевірити вже
спроектовану або, навіть, діючу систему на функціональну повноту технологій взаємодії, що в ній передбачені.
Визначити – чи оптимальна вибрана схема архітектури системи, чи забезпечить така схема можливість
реалізації всіх реально можливих технологій взаємодії, чи використовуються всі можливості застосованих
програмно-технічних засобів вибраної платформи системи. Такі питання можна вирішити шляхом
порівняльного аналізу набору схемних комунікаційних рішень та схемних рішень у порівнюваній системі.
Зрозуміло, для цього потрібно провести весь аналітичний процес заново. Відправною точкою для нього буде
визначена або вибрана для системи програмно-апаратна платформа та набори функцій складових компонентів
системи.
Для вибраної програмно-апаратної платформи складових компонентів системи та їх функцій в таблиці
(табл.3) наведені всі схемні комунікаційні рішення та інформаційні потоки зі схеми (рис.8), що відповідають
цим схемним рішенням.
Таблиця відповідності СКР та інформаційних потоків на схемі ( Табл.3)
П.п. СКР Інформаційні потоки
1 СКР-1 ТФ-1
2 СКР-2 З-1, В-1
3 СКР-3 ТФ-2
4 СКР-4 З-2, В-2
5 СКР-5 ТФ-3
Як бачимо з цієї таблиці, всім схемним комунікаційним рішенням є відповідні інформаційні потоки на схемі
(рис. 2). Таким чином, можна з впевненістю заявляти, що наведена схема містить весь функціонально-повний
набір можливих технологій інформаційної взаємодії і ніяких прикростей при створенні спроектованої
архітектури ІМІС не може виникнути.
D:\Проблемы программирования\Конф-04\2004-2-3\D7.DOC Дата печати 08.07.2008 18:11:00
12
Висновки
Виходячи з порівняльного аналізу характеристик можливих варіантів схем взаємодії ВІС в рамках
інтегрованої міжвідомчої інформаційної системи визначається набір основних компонентів, програмно-
технічних засобів ІМІС, а також модель її архітектури. На цій базі запропоновано підхід до побудови
концептуальної схеми архітектури ІМІС, який дозволяє за допомогою методів формального аналізу функцій її
складових компонентів – відомчих інформаційних систем та програмно-технічних засобів, що задані на
вибраній програмно-апаратній платформі, визначити набір схемних комунікативних рішень для побудови
схеми архітектури системи. Процес побудови ґрунтується на визначенні функціонально-повного набору
формально можливих технологій інформаційної взаємодії відомчих інформаційних систем і сховища даних за
допомогою файлового серверу та серверу обробки запитів (програмно-технічних засобів вибраної платформи).
Проаналізувавши такий функціонально-повний набір та здійснивши його мінімізацію, отримуємо набір реально
можливих технологій взаємодії складових системи. Наступний крок – декомпозиція кожної з цих технологій на
види взаємодії. Виключивши з отриманого списку видів взаємодії подібні і трансформувавши їх у схемні
рішення, одержуємо набір схемних комунікативних рішень з обміну інформацією між складовими системи.
Такий набір схемних комунікативних рішень дозволяє побудувати концептуальну схему архітектури ІМІС або
перевірити схему вже існуючої системи на оптимальність її побудови.
Література:
1. ДСТУ 3918-1999 (ISO/IEC 12207:1995) Державний стандарт України. Інформаційні технології. Процеси життєвого циклу програмного
забезпечення. – К.: Держстандарт України, 2000.
2. Алексєєв В.А., Терещенко В.С. Розвиток спіральної моделі життєвого циклу програмних систем // Проблемы программирования. –
2003. – №4.
3. Алексєєв В.А., Ільїн С.А., Мягкова Л.А., Терещенко В.С. Організація схем взаємодії в інтегрованій міжвідомчій інформаційній
системі // Проблемы программирования. – 2003. – №3. – С. 71 – 83.
4. Бабенко Л.П., Лавріщева К.М. Основи програмної інженерії: Навч. посіб. – К.: Знання, 2001. – 209 с.
5. Алексеев В.А., Богданцев Е.Н., Шумков Е.А. Концепция создания единой автоматизированной системы документов проектной базы
ядерных установок // Проблемы программирования. – 2001. - №1-2. – С. 109-113
|
| id | nasplib_isofts_kiev_ua-123456789-2295 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 1727-4907 |
| language | Ukrainian |
| last_indexed | 2025-12-07T18:30:05Z |
| publishDate | 2004 |
| publisher | Інститут програмних систем НАН України |
| record_format | dspace |
| spelling | Алексєєв, В.А. Терещенко, В.С. 2008-09-17T12:22:34Z 2008-09-17T12:22:34Z 2004 Архітектура інтегрованої міжвідомчої інформаційної системи як композиція відомчих інформаційних систем / В.А. Алексєєв, В.С. Терещенко // Проблеми програмування. — 2004. — N 2,3. — С. 397-408. — Бібліогр.: 5 назв. — укр. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/2295 681.3 Розглядається архітектура інтегрованої міжвідомчої інформаційної системи, яка враховує можливі варіанти схем взаємодії в межах
 системи її структурних компонентів – відомчих інформаційних систем – та підхід до її побудови, на заданій платформі програмно-
 апаратних засобів за допомогою методів формального аналізу функцій її компонентів. The architecture of the integrated interdepartmental information system is considered which takes into account possible variants of the
 schemes of interaction within the framework of the system it of structural components - departmental information systems – and approach to
 it to construction, on the given platform of hardware-software tools with the help of methods of the formal analysis of functions it of making
 components. uk Інститут програмних систем НАН України Информационные системы Архітектура інтегрованої міжвідомчої інформаційної системи як композиція відомчих інформаційних систем Article published earlier |
| spellingShingle | Архітектура інтегрованої міжвідомчої інформаційної системи як композиція відомчих інформаційних систем Алексєєв, В.А. Терещенко, В.С. Информационные системы |
| title | Архітектура інтегрованої міжвідомчої інформаційної системи як композиція відомчих інформаційних систем |
| title_full | Архітектура інтегрованої міжвідомчої інформаційної системи як композиція відомчих інформаційних систем |
| title_fullStr | Архітектура інтегрованої міжвідомчої інформаційної системи як композиція відомчих інформаційних систем |
| title_full_unstemmed | Архітектура інтегрованої міжвідомчої інформаційної системи як композиція відомчих інформаційних систем |
| title_short | Архітектура інтегрованої міжвідомчої інформаційної системи як композиція відомчих інформаційних систем |
| title_sort | архітектура інтегрованої міжвідомчої інформаційної системи як композиція відомчих інформаційних систем |
| topic | Информационные системы |
| topic_facet | Информационные системы |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/2295 |
| work_keys_str_mv | AT aleksêêvva arhítekturaíntegrovanoímížvídomčoíínformacíinoísistemiâkkompozicíâvídomčihínformacíinihsistem AT tereŝenkovs arhítekturaíntegrovanoímížvídomčoíínformacíinoísistemiâkkompozicíâvídomčihínformacíinihsistem |