8.3.6. Інструментальна концепція – технологія qWord

Отже, інструментарій qWord дозволяє нам будувати СУБД на концепції відкритості, концепції динамічно розкриваного об’єкта, причому виконати це на базі єдиного формалізму W-граматик. Більше того, і сама БД і все оточення (управління БД) реалізовані в єдиному програмному середовищі і на базі єдиного подання В*-моделей.

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

Вирішальним тут є те, що цей комплект фактично не доповнення, не окрема підсистема, а невід’ємна складова ядра qWord, доступна для використання із будь-якої точка будь-якого процесу {109. Наскільки логічно і просто це звучить, настільки ж важким був процес осмислення інструментальної концепції, особливо “природність” його реалізації.}. Що ж до подробиць реалізації – то достатньо багато корисного матеріалу міститься все в тій же документації по qWord. Відзначимо тільки, що це не компілятор, qWord породив систему і постійно супроводить їй – підтримує процес її існування. Взагалі CRR підхід вимагає наявність інтерпретатора, інакше вийде все той же об’єктний підхід, неминуче витікаючий із компіляції. qWord фактично є віртуальною машиною

Тепер звернемо увагу – повністю міняється підхід до створення ІС.

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

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

• навчити користувача початковому обсягу інструментарію і технології;

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

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

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

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