- •В.М.Лачинов а.О.Поляков
- •Інформодинаміка
- •Шлях до Світу відкритих систем
- •Анотація
- •Авторська передмова до другого видання. Від «не термодинамічної» кібернетики до інформодинаміки
- •Vivorum censura difficilis Судження про живих утруднене (лат.)
- •Інтелектуальність складних систем
- •Розділ 1. Інтелектуальні системи і управління
- •1.1. Інтелектуальні системи і інтелектуальне управління
- •1.2. Від строгості математичної символіки до свободи семантики
- •Розділ 2. Основна термінологія
- •2.1. Інженерне поняття інтелекту
- •2.2. Системи і управління
- •2.3. Подання знань і робота з ним
- •2.4. Інформаційна база
- •Розділ 3. Мови і мовні моделі для управління
- •3.1. Мови природні і штучні
- •3.2. Мови управління
- •3.3. Мови контекстно – залежного управління
- •3.4. Формальна система і теорія, що формалізується
- •3.5. Моделювання і реалізація мовних об’єктів
- •3.6. Числення предикатів
- •3.7. Подання проблемної галузі на основі мови предикатів
- •За фон Берталанфі розділ 4. Складність відкритих систем
- •4.1. Необхідність загальної теорії
- •4.2. Дві загальні теорії систем
- •4.3. Ієрархія систем
- •4.4. Нова парадигма управління
- •4.5. Гомеокінетичне плато інтелектуальної системи
- •4.6. Узагальнена функціональна структура ісу
- •4.7. Мови систем і мови управління
- •4.8. Тріаграма систем
- •Інженерія інтелектуальних систем
- •Розділ 5. Реалізація контекстно-залежного управління
- •5.1. Неформальні вимоги
- •5.2. Інженерні проблеми проектування складних систем
- •5.3. Комп’ютер фон Нойманівської архітектури в системах високих рівнів складності
- •5.4. Частотна оцінка
- •5.5. Інформаційна стійкість
- •Розділ 6. Нова архітектура машин
- •6.1. Машини баз знань
- •6.2. Паралельні обчислення з управлінням від потоку даних
- •Розділ 7. Про технологію управління
- •7.1. Врахування динаміки інформаційних потоків
- •7.2. Вбудовування системи автоматизації в структуру об’єкта
- •7.3. Об’єкт в інформаційному середовищі
- •7.4. Проблема декомпозиції об’єкта як складної системи
- •Розділ 8. Інженерія систем “інтелектуальної спрямованості”
- •8.1. Три основні підходи
- •8.2. Перший підхід. Ідеологія операційної системи
- •8.3. Другий підхід. Ідеологія інструментальної системи
- •8.3.2. Ієрархії і процеси.
- •8.3.3. Концепція відкритої субд.
- •8.3.4. Реалізація розкриваності.
- •8.3.5. Уніфіковане подання об’єкта.
- •8.3.6. Інструментальна концепція – технологія qWord
- •8.3.7. Куди поділася семантика?
- •8.3.8. Проблеми баз, що саморозвиваються.
- •8.3.9. Чому “в Cache’-технології”?
- •8.4. Третій підхід. Спеціалізована виробнича операційна система
- •8.5. Самовдосконалення ісу
- •Розділ 9. Проміжні підсумки
- •9.1. Інформація і інформатика. Шлях до феноменології і інформодинаміки
- •9.2. Про реалізованість інформаційної машини відкритого Світу
- •Частина третя узгоджений світ інформодинаміки
- •Розділ 10. Аксіоми відкритого світу
- •10.1. Феномен інформації як предмет науки про відкриті системи
- •10.2. Аксіоми умовчання
- •10.3. Співвідношення невизначеності - 2
- •10.4. Гармонійні шкали
- •10.5. Обговорення гармонійних побудов
- •10.6. Самоорганізація і структурний резонанс
- •10.7. До організації експериментів із виявлення структурного резонансу
- •10.8. Про механізм структурної взаємодії
- •10.9. Від структурної взаємодії до структурного поля
- •10.10. Про аксіоми або ефективні способи обдурити самого себе
- •10.11. Ще раз про аксіоми умовчання
- •10.12. Деякі висновки
- •Розділ 11. Власна структура інформації
- •11.1. Проблеми розробки інструментарію
- •11.2. Топологія вкладених багатовимірних конусів
- •11.3. Закон рекурсії структур, метаструктур і процесів
- •11.4. До питання про елементарну комірку
- •11.5. Деякі кількісні оцінки елементної бази
- •Розділ 12. Теорія структурної узгодженості
- •12.1. Структурна взаємодія і узагальнений принцип комплементарності
- •12.2. Про правила самоорганізації відкритих систем
- •12.3. Деякі наслідки і перспективи
- •12.4. Про деструкцію систем
- •12.5. Правила тсу – похідні
- •12.6. Попереднє обговорення результатів
- •12.7. Про методологію пізнання з позицій тсу
- •12.8. Обговорення тсу
- •Розділ 13. Інформодинаміка
- •13.1. Дещо про аналогії
- •13.2. Від абстрактної машини до самоорганізації потоків
- •13.3. Деякі властивості інформаційної машини
- •13.4. Умови узгодження потоків. Резонатор динамічного структурного поля
- •13.5. Вільне інформаційне поле. Гіпотеза про дві половини Всесвіту
- •13.6. Інформодинаміка – поки без формалізму
- •13.7. Тсу як інструментарій інформодинаміки
- •13.8. Ще раз про аксіоматику
- •Частина четверта
- •Архітектура
- •Відкритих
- •Попередження: обережно, відкриті системи
- •Розділ 14. Вертикальна машина
- •14.1. Концепція вертикальної машини
- •14.2. Структура команд
- •14.3. Програмування і запуск
- •14.4. “Перед прочитанням знищити…”
- •14.5. Що з нею робити?
- •14.6. Імітація вертикальної машини в адресному середовищі
- •Розділ 15. Про фізику відкритого світу
- •15.1. Без “Великого вибуху”
- •15.2. Доповнюваність моделей. Дві половини цілого
- •15.3. Світ як єдина система
- •15.4. Модифікація перетворення Лоренца
- •15.5. Випадок “малих” об’єктів
- •15.6. Структурно-узгоджена космологія
- •15.7. Узгодження структур об’єкта і теорії
- •15.8. Замітки про реалії нової фізики
- •Експерименти в галузі інформодинаміки
- •Можливий варіант генератора поздовжніх електромагнітних хвиль
- •Реконструкція принципу дії нігнітрона
- •Проблема seti
- •Розділ 16. Відповідальність створюючого
- •16.1. Короткий самовчитель не створення тоталітарного суспільства
- •16.2. Неминучість краху і свобода повтору
- •16.3. Роль Віри
- •16.4. Ментагенез
- •16.5. Відповідальність людини
- •Додаток 1 Короткий огляд способів самодеструкції програмних систем або Загальна Демонологія
- •Додаток 2 Про “інфонауки”
- •Про Ейнштейна, релятивізм і інформацію
- •Додаток 3 Повернення до лекції XVII
- •Література
8.3. Другий підхід. Ідеологія інструментальної системи
Не менш цікавою і з практичної, і з теоретичної точки зору представляється інструментальна система qWord {101. Автор і генеральний розробник – О.М. Долженков, організація СП АРМ [30].} як реалізація технології відкритих систем управління даними. Одне з головних положень qWord-технології – повна інтеграція інструментальної і прикладної систем в єдине ціле. При цьому модель проблемної галузі зовсім щезає із програмної реалізації як цілісний логічний об’єкт, залишається зовні, в проблемній галузі, тобто там, де вона і була спочатку.
Поточна реалізація відображення моделі (чи сукупності таких), яка присутня в прикладній системі за умовчанням, вважається не більше ніж одномоментною реалізацією того стану об’єкта (проблемної галузі), який на цей момент доступний і актуальний для користувача. Тобто стає в точності тим, чим вона (ця реалізація) і є насправді, і ніяк не більше того.
З іншого боку, завдяки повній інтеграції інструментальних засобів і властивості “самоопису” системи, з’являється реальна можливість використання скільки завгодно складних апріорі невизначуваних “об’єктів”, кількість яких у принципі конструктивно нескінченна.
Запропонований виклад qWord технології і, якщо дивитися ширше, взагалі нової технології створення СУБД, СУБЗ, “сховищ знань” і тому подібного, носить тут значною мірою узагальнювальний, методологічний характер відповідно до основної мети написання цього розділу. Детальніший опис просто приховав би украй важливі як теоретичні, так і чисто практичні аспекти в множини часткових подробиць.
Украй цікавою при розгляді qWord представляється відповідь на питання:
чому ця технологія і власне продукт qWord виникли саме усередині того середовища, яке зараз знайшло свою єдність і назву Cache’-технології?
як виник інструмент, доповнюючий перший підхід практично у всіх напрямах, які фактично не можуть бути забезпечені коробочним продуктом, але які абсолютно необхідні, щоби цей коробочний продукт проявився у всіх своїх можливостях?
що і як взагалі відбувається із семантикою проблемної підмножини природної мови в адекватно влаштованій інформаційній системі?
Почнемо з розгляду змісту поняття “Адекватно влаштованої” системи.
8.3.1. Основна об’єктна тріада і об’єкт, що динамічно розкривається.
Для початку нагадаємо інтуїтивне поняття об’єкта в тому вигляді, в якому воно стало більш менш загальноприйнятим в об’єктному підході до подання інформаційних систем, наприклад, в точно тому ж сенсі, що і об’єкти Cache’.
Об’єкт (проблемний, програмний чи абстрактний) це те, що деяким “природним чином ділиться на декларативну і процедурну (“процесну”) частини і, таким чином, може бути адекватно відображено у відповідні структури даних і програми в комп’ютерній системі (КС), маючи на увазі під КС не апаратний комплекс, а деяку інформаційну, розрахункову, взагалі будь-яку систему, реалізовану в комп’ютерному середовищі.
Звернемо увагу на те, що тут фактично йдеться про три суттєво різні об’єкти. У загальному випадку ми не маємо права вважати їх різними реалізаціями одного і того ж об’єкта, оскільки це (їх єдність) лише мета створення системи, а не факт, що відбувся. Зазвичай і в теоретичних публікаціях, і в програмній документації все зрозуміло з контексту і плутанини не виникає, але тут нам важливо нагадати, що об’єкти проблемного середовища, реалізації об’єктів в абстрактній моделі даних і програмні реалізації об’єктів різні за своєю суттю.
Створення КС зазвичай розуміється як створення моделі даних, декомпозиція проблемного середовища на “природні об’єкти” і відображення їх в “об’єкти КС”. Звернемо увагу на те, що кожний з об’єктів КС у свою чергу повинен містити два компоненти: подання об’єкта і відображення цього подання на адресний простір.
Фактично конструюється не одна модель даних, але відразу і паралельно всі вищезазначені три моделі, а саме: модель проблемного середовища і її відображення в КС, яке, у свою чергу, автоматично декомпозується в дві моделі – абстрактна модель даних, та, що відображається на екрані навігатора моделі даних (наприклад, ТБМД в Cache’) і внутрішню, приховану від користувача реалізацію абстрактної моделі, що відображається.
Частково підміна відбувається через те, що модель проблемного середовища є суттєво зовнішньою, перебуває цілком зовні КС, проте це зовсім не означає, що “її немає зовсім”, це якраз та система умовчань, яка складається в сприйнятті користувача, те саме, що підказує користувачеві, як розуміти абстрактну модель що відображається навігатором.
Механічні зведення всього процесу до однієї лише абстрактної моделі даних призводить до того, що втрачається і саме розуміння цього процесу, а саме розуміння того, що незалежно від бажання користувача абстрактна модель “самостійно” розкривається і всередину і назовні. При цьому втрачається і властивість, і сам процес динамічної розкриваності подання. Очевидно, що конструювання будь-якої КС повинно виконуватися так, щоб не відбулася втрата цієї властивості динамічної розкриваності, щоб реалізація подання (об’єкта) не перешкоджала можливості здійснення чергового кроку розкриття у будь-який момент існування КС. Але це лише одна “площина”, в якій виявляється властивість розкриваності подання.
Тут ми розглядатимемо підмножину КС – інформаційні системи, підрозуміваючи під цим, там де це не викличе різночитань, всю сукупність таких від традиційних СУБД до “систем знань” тощо. Ми повинні констатувати, що розкриваність подання може виявлятися в найширшій сукупності аспектів, оскільки розкриваність не запроваджена нами, а є атрибутивною властивістю будь-якого подання.
Це досить рядова ситуація. Колізії, що виникають при розширенні реляційних таблиць, – це втрата адекватної розкриваності реляційного подання (абстрактною, реалізованою всередині КС, моделі даних), що вимагає поповнення або реорганізації каталогів. Необхідність реорганізації диска, коли вже не допомагає навігатор у каталогах – це ситуація, коли втрачається розкриваність зовнішньої моделі, подання, лежачого зовні КС.
Нарешті, досить поширена ситуація, коли програміст порушує балансування В*-дерев, що призводить до катастрофічної неефективності роботи бази даних. Сказаним ми хочемо нагадати просту, але завжди корисну істину – якщо списати прояви якоїсь проблеми, властивості природного явища на дії деякого часткового механізму, часткової моделі, то сама проблема від цього нікуди не зникне, зате неприємності гарантовані, аж до повної втрати розуміння суті самого явища.
Отже, ми зобов’язані вважати, що мінімальною структурою, адекватною задачі створення інформаційної системи, є сукупність взаємозв’язаних динамічних об’єктів: проблемне середовище (ПС)–інформаційна система (ІС)–користувач (К). Назвемо цю сукупність основною об’єктною тріадою (ООТ).
ПС і ІС є сукупностями взаємозв’язаних об’єктів. Але такою ж сукупністю об’єктів є і користувач, якщо врахувати, що ми зобов’язані розглядати не окремий його запит чи сукупність запитів, а всю історію його роботи, тобто всю сукупність завдань {102. Ми зобов’язані включити сюди і всі помилки користувача, і всі некоректні ситуації, викликані невірним трактуванням ним ПС чи змісту і можливостей ІС.}, що вирішуються користувачем із допомогою ІС.
Представляється очевидним співпідпорядкованість, ієрархія об’єктів і зовсім не очевидним запропоноване розширене трактування задачі. Дійсно, здавалося б, досить розширити стандартне трактування об’єкта до його “розширення назовні” і “розкриття всередину” {103. Термінологія так званої “концепції об’єкта, що розширюється”.}, тобто розглядати лише одну “узагальнену модель даних”, як це до цих пір і прийнято. Але це можливо і справедливо лише до моменту реструктуризації даних в ІС, а саме це і цікаво, якщо ми збираємося говорити про випадки нетривіальні, тим більше – про “самоструктуризацію” або “інтелектуальність”.
У простому випадку поодинокого поповнення чи запиту, що призводить до реструктурування, ієрархія процесів перевертається, головним джерелом активності стають структури даних в ІС. Якщо ж необхідність реструктуризації спричинена послідовністю поповнень і запитів, то необхідне породження цілих ієрархій процесів, тобто комплексний “відкат” непрогнозованої глибини.
Важливо те, що при початку акту реструктурування ієрархія процесів перевертається, активність виходить від структур, що реалізують абстрактну модель даних, потім користувач за допомогою навігатора абстрактної моделі даних з’ясовує суть незбіжності поточної реалізації цієї моделі і об’єкта проблемного середовища. Лише після цього користувач приймає рішення і задає конкретний вид реалізації моделі, тобто проводить власне реструктуризацію. Процес має саме такий вигляд навіть у разі найпростішої СУБД. Таким твердженням ми нічого не “відкриваємо” і не “винаходимо” – просто чесно констатуємо реальну ситуацію.
Сказане означає, що адекватне розкриття об’єкта як “назовні”, так і “всередину” в реальності досягається тільки в динамічному процесі взаємодії об’єктів і процесів, складових ООТ.
Інакше кажучи, об’єкт, що моделює ІС чи її частину (мається на увазі програмна реалізація об’єкта), є адекватним поданням програмного забезпечення (ПЗ), якщо за умовчанням має властивість динамічної розкриваності. Успіх будь-якої ІС полягає в тому, наскільки ефективно це вдалося реалізувати {104. Інтуїтивно майже очевидно, вся історія ІС до цього і йшла. Питання лише в тому, як це покласти в реалізацію, в коди.}.