8.3. Другий підхід. Ідеологія інструментальної системи

Не менш цікавою і з практичної, і з теоретичної точки зору представляється інструментальна система qWord {101. Автор і генеральний розробник – О.М. Долженков, організація СП АРМ [30].} як реалізація технології відкритих систем управління даними. Одне з головних положень qWord-технології – повна інтеграція інструментальної і прикладної систем в єдине ціле. При цьому модель проблемної галузі зовсім щезає із програмної реалізації як цілісний логічний об’єкт, залишається зовні, в проблемній галузі, тобто там, де вона і була спочатку.

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

З іншого боку, завдяки повній інтеграції інструментальних засобів і властивості “самоопису” системи, з’являється реальна можливість використання скільки завгодно складних апріорі невизначуваних “об’єктів”, кількість яких у принципі конструктивно нескінченна.

Запропонований виклад qWord технології і, якщо дивитися ширше, взагалі нової технології створення СУБД, СУБЗ, “сховищ знань” і тому подібного, носить тут значною мірою узагальнювальний, методологічний характер відповідно до основної мети написання цього розділу. Детальніший опис просто приховав би украй важливі як теоретичні, так і чисто практичні аспекти в множини часткових подробиць.

Украй цікавою при розгляді qWord представляється відповідь на питання:

• чому ця технологія і власне продукт qWord виникли саме усередині того середовища, яке зараз знайшло свою єдність і назву Cache’-технології?

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

• що і як взагалі відбувається із семантикою проблемної підмножини природної мови в адекватно влаштованій інформаційній системі?

Почнемо з розгляду змісту поняття “Адекватно влаштованої” системи.

8.3.1. Основна об’єктна тріада і об’єкт, що динамічно розкривається.

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

Об’єкт (проблемний, програмний чи абстрактний) це те, що деяким “природним чином ділиться на декларативну і процедурну (“процесну”) частини і, таким чином, може бути адекватно відображено у відповідні структури даних і програми в комп’ютерній системі (КС), маючи на увазі під КС не апаратний комплекс, а деяку інформаційну, розрахункову, взагалі будь-яку систему, реалізовану в комп’ютерному середовищі.

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

Створення КС зазвичай розуміється як створення моделі даних, декомпозиція проблемного середовища на “природні об’єкти” і відображення їх в “об’єкти КС”. Звернемо увагу на те, що кожний з об’єктів КС у свою чергу повинен містити два компоненти: подання об’єкта і відображення цього подання на адресний простір.

Фактично конструюється не одна модель даних, але відразу і паралельно всі вищезазначені три моделі, а саме: модель проблемного середовища і її відображення в КС, яке, у свою чергу, автоматично декомпозується в дві моделі – абстрактна модель даних, та, що відображається на екрані навігатора моделі даних (наприклад, ТБМД в Cache’) і внутрішню, приховану від користувача реалізацію абстрактної моделі, що відображається.

Частково підміна відбувається через те, що модель проблемного середовища є суттєво зовнішньою, перебуває цілком зовні КС, проте це зовсім не означає, що “її немає зовсім”, це якраз та система умовчань, яка складається в сприйнятті користувача, те саме, що підказує користувачеві, як розуміти абстрактну модель що відображається навігатором.

Механічні зведення всього процесу до однієї лише абстрактної моделі даних призводить до того, що втрачається і саме розуміння цього процесу, а саме розуміння того, що незалежно від бажання користувача абстрактна модель “самостійно” розкривається і всередину і назовні. При цьому втрачається і властивість, і сам процес динамічної розкриваності подання. Очевидно, що конструювання будь-якої КС повинно виконуватися так, щоб не відбулася втрата цієї властивості динамічної розкриваності, щоб реалізація подання (об’єкта) не перешкоджала можливості здійснення чергового кроку розкриття у будь-який момент існування КС. Але це лише одна “площина”, в якій виявляється властивість розкриваності подання.

Тут ми розглядатимемо підмножину КС – інформаційні системи, підрозуміваючи під цим, там де це не викличе різночитань, всю сукупність таких від традиційних СУБД до “систем знань” тощо. Ми повинні констатувати, що розкриваність подання може виявлятися в найширшій сукупності аспектів, оскільки розкриваність не запроваджена нами, а є атрибутивною властивістю будь-якого подання.

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

Нарешті, досить поширена ситуація, коли програміст порушує балансування В*-дерев, що призводить до катастрофічної неефективності роботи бази даних. Сказаним ми хочемо нагадати просту, але завжди корисну істину – якщо списати прояви якоїсь проблеми, властивості природного явища на дії деякого часткового механізму, часткової моделі, то сама проблема від цього нікуди не зникне, зате неприємності гарантовані, аж до повної втрати розуміння суті самого явища.

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

ПС і ІС є сукупностями взаємозв’язаних об’єктів. Але такою ж сукупністю об’єктів є і користувач, якщо врахувати, що ми зобов’язані розглядати не окремий його запит чи сукупність запитів, а всю історію його роботи, тобто всю сукупність завдань {102. Ми зобов’язані включити сюди і всі помилки користувача, і всі некоректні ситуації, викликані невірним трактуванням ним ПС чи змісту і можливостей ІС.}, що вирішуються користувачем із допомогою ІС.

Представляється очевидним співпідпорядкованість, ієрархія об’єктів і зовсім не очевидним запропоноване розширене трактування задачі. Дійсно, здавалося б, досить розширити стандартне трактування об’єкта до його “розширення назовні” і “розкриття всередину” {103. Термінологія так званої “концепції об’єкта, що розширюється”.}, тобто розглядати лише одну “узагальнену модель даних”, як це до цих пір і прийнято. Але це можливо і справедливо лише до моменту реструктуризації даних в ІС, а саме це і цікаво, якщо ми збираємося говорити про випадки нетривіальні, тим більше – про “самоструктуризацію” або “інтелектуальність”.

У простому випадку поодинокого поповнення чи запиту, що призводить до реструктурування, ієрархія процесів перевертається, головним джерелом активності стають структури даних в ІС. Якщо ж необхідність реструктуризації спричинена послідовністю поповнень і запитів, то необхідне породження цілих ієрархій процесів, тобто комплексний “відкат” непрогнозованої глибини.

Важливо те, що при початку акту реструктурування ієрархія процесів перевертається, активність виходить від структур, що реалізують абстрактну модель даних, потім користувач за допомогою навігатора абстрактної моделі даних з’ясовує суть незбіжності поточної реалізації цієї моделі і об’єкта проблемного середовища. Лише після цього користувач приймає рішення і задає конкретний вид реалізації моделі, тобто проводить власне реструктуризацію. Процес має саме такий вигляд навіть у разі найпростішої СУБД. Таким твердженням ми нічого не “відкриваємо” і не “винаходимо” – просто чесно констатуємо реальну ситуацію.

Сказане означає, що адекватне розкриття об’єкта як “назовні”, так і “всередину” в реальності досягається тільки в динамічному процесі взаємодії об’єктів і процесів, складових ООТ.

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