ГИПЕРТЕКСТ C ВЫЧИСЛЯЕМЫМИ ССЫЛКАМИ
И ДРУГИЕ “ИЗЮМИНКИ” СИСТЕМЫ АСТРОЛОГОС

(Статья из Журнала д-ра Добба , № 4-5 (9-10) 1995 г.)

В программном пакете АстроЛогос, впервые появившемся на выставке COMTEK’95, реализованы некоторые идеи, которые являются несомненным успехом разработчиков и достижением, ставящим этот пакет в ряд разработок мирового класса. К их числу относится, в первую очередь, организация связи достаточно сложных (в данном случае, астрологических) расчётов с текстами интерпретаций. К достижениям следует отнести технологию генерации гипертекстовой базы по заданному пользователю профилю с её автоматическим подключением по окончании генерации к имеющемуся набору баз интерпретаций. Наконец, находкой является организация работы демонстратора, работающего по сценарию над живыми, получаемыми на месте в результате расчётов данными.

Несомненно заслуживает также внимания организация текстового материала для его выдачи на экран, основанная на использовании элементов издательских систем. Поскольку, однако, при этом были заимствованы идеи издательской системы TeX, авторы не относят их реализацию к числу своих достижений.

Данная статья призвана раскрыть идеи, впервые реализованные в системе АстроЛогос, которые могут быть использованы разработчиками других программ и вне всякого сомнения повысят уровень их архитектурных решений.

Гипертекст с вычисляемыми ссылками™.

Когда возникает потребность в гипертексте с вычисляемыми ссылками?

Хорошо известная программистам и пользователям концепция гипертекста идеально подходит для организации работы информационно-справочных систем, учебных материалов, других баз данных и систем, имеющих “статический” характер. В этом случае все ссылки заранее определены, а связи между элементами баз могут удовлетворяться на этапе компиляции (сборки) системы.

Однако традиционная схема организации гипертекстовых баз не является достаточно гибкой в двух, как правило, связанных случаях. Оба они возникают в контексте сосуществования и совместной работы двух взаимосвязанных подсистем — вычислительной и интерпретирующей. Очевидно, что гипертекст с вычисляемыми ссылками является расширением традиционного, статического гипертекста, а традиционный гипертекст, в свою очередь, является частным, предельным случаем гипертекста с вычисляемыми ссылками; традиционные гипертекстовые базы могут быть построены средствами гипертекста с вычисляемыми ссылками при пустой, тривиальной вычислительной подсистеме комплекса.

Таким образом, гипертекст с вычисляемыми ссылками необходим, во-первых, когда, требуется управлять выдачей фрагментов (элементов) текста, используя для управления результаты работы расчётной части комплекса, и во-вторых, когда адреса ссылок не могут быть вычислены статически, так как они зависят от результатов работы вычислительной подсистемы.

Внутренний специализированный язык — основа построения гипертекста с вычисляемыми ссылками

Авторами системы АстроЛогос реализован подход к гипертексту, основанный на создании и реализации “языка-прослойки”. Этот язык содержит конструкции, позволяющие вырабатывать значения логических выражений, построенных на предикатах, несущих в данной предметной области и данном контексте очевидную смысловую нагрузку, а также операторные конструкции, позволяющие управлять режимами работы как интерпретатора, так и комплекса в целом.

Чтобы пояснить, о каких конструкциях идёт речь, приведём “живые” фрагменты баз интерпретаций системы АстроЛогос, рассчитывая, что читатель без труда сможет абстрагироваться от специфики предмета (астрологии в данном случае) и адаптировать идеи применительно к свои задачам.

Пример 1. Фрагмент базы, содержащей управляющую конструкцию и вычисляемую ссылку.

В этом крохотном фрагменте в фигурных скобках находится конструкция {если <>, то}, а в уголковых — логическое выражение, в данном случае, оператор сравнения, вырабатывающий логическое значение 0 или 1. Текст вместе со ссылкой “талант изобретателя и рационализатора (=>NASPECTH.HDB|в конфигурации Меркурия с Ураном|Гармоничные Аспекты планеты 0 2.<=),” до оператора {всегда} будет выдаваться лишь при выполнении условия, содержащегося в уголковых скобках, в данном случае, как следует из семантики правила, если число гармоничных аспектов планеты Меркурий больше нуля (второй аргумент правила определяет способ упорядочения релевантных (имеющих отношение к делу — в данном случае, удовлетворяющих условию) аспектов — по весам или в порядке следования в таблице, и в данном случае значения не имеет. Текст “талант к иностранным языкам.” будет появляться всегда. Таким образом, в любом случае в качестве текста интерпретации будет выдана та или иная осмысленная и правильно построенная фраза русского языка.

В системе АстроЛогос используется более 500 конструкций (правил и операторов) внутреннего специализированного языка, ориентированного на построение интерпретаций. Большинство конструкций заимствовано просто из классических текстов по астрологии и подвергнуто системной обработке с тем, чтобы избежать дублирования, придать конструкциям достаточно общую значимость, ввести модификаторы режимов и средства задания дополнительных параметров; при этом разработчики стремились, по возможности, сохранить семантическую нагрузку конструкций и естественность их использования. В результате базы интерпретаций вместе с расставленными управляющими конструкциями представляют собой в общем весьма очевидный текст (на русском языке), в части управляющих конструкций быть может несколько суховатый и формализованный, но всё же понятный.

В связи с разработкой внутреннего языка предметной области возникают два вопроса:

• Кто его должен разрабатывать? Какова методика его разработки? Где этому можно научиться?
• Кто превращает “заготовки” интерпретаций (существующие на бумаге традиционные тексты) в гипертекстовые базы интерпретаций?

Ответы на эти вопросы выводят нас на обсуждение вопросов технологии программирования и организации работы над проектом. При работе над системой АстроЛогос вся работа была распределена по следующим уровням:

• разработка концепции (конструкций, способов использования и других вопросов) внутреннего предметно-ориентированного языка интерпретаций, а также архитектуры системы в целом — концептуальное проектирование системы;
• разработка механизмов работы системы — логическое проектирование системы;
• реализация правил внутреннего языка — физическое проектирование и реализация системы;
• разработка интерфейса;
• разработка средств ведения и поддержки проекта: специализированых средств отладки, сборки и обновления версий системы, подключения новых правил, новых баз и других элементов расширения системы;
• наполнение баз интерпретаций;
• содержательное и комплексное тестирование системы.

Соответственно программный проект (будем ещё его называть программный комплекс, когда речь идет именно о программной реализации проекта) может участвовать в нескольких циклах отладки.

Циклы разработки и отладки комплекса:

• внешний — цикл уточнения и отладки интерпретаций, а также устранения ошибок реализации. В этом цикле группа поддержки проекта совместно с группой тестирования добивается безошибочной работы системы в соответствии со спецификацией данной версии системы. Как правило, внесение исправлений и изменений на этом цикле не требует полной перетрансляции и сборки новой версии системы. Это цикл локальных модификаций, уточнений, исправлений опечаток и ошибок реализации;
• промежуточный — цикл расширения числа правил или баз интерпретаций. На этом цикле требуется перетрансляция всей системы и всех баз, так как может измениться семантика правил внутреннего языка или изменяются ссылки между базами. Внесение изменений в этом цикле означает смену модификации системы. Она сопряжена с прохождением полного цикла внешнего тестирования системы;
• внутренний, связанный с внедрением в систему новых механизмов, быть может, частичным изменением её архитектуры. Это самый “болезненный” цикл изменений, приводящий, по существу, к выпуску новой версии системы. Он влечёт за собой необходимость не только полной сборки системы, но также прохождение полных циклов отладки как на промежуточном, так и на внешнем цикле.

Работа над проектом велась одновременно на нескольких планах.

Для разработки концепции внутреннего языка требуется определённый опыт концептуального проектирования и системного анализа. Он может быть приобретён как в форме знаний, даваемых в учебных курсах, так и в результате практической деятельности. Основные мысли, которые могут направлять работу такого плана, являются следующие. Работа программиста лишь в последнюю очередь касается написания программы. Главное — разработать структуру вычислительного процесса, выделив нескольких планов (уровней) прохождения задачи и обработки данных, построить “виртуальные машины” и организовать интерфейс между ними. Попытка написать программный пакет в виде одной большой программы обречена на провал по многим разным причинам. Поэтому вопросы архитектуры программного комплекса, построения его концептуальной модели, на наш взгляд, в программировании являются первейшими. От их проработки зависят сроки реализации проекта, его гибкость, от их удачного или неудачного решения зависят перспективы дальнейшего развития системы и возможности её совершенствования. Поэтому к работе на этапе концептуального проектирования должны быть привлечены специалисты, имеющие достаточно высокий уровень квалификации и опыт проектирования программных систем.

Второй вопрос — о технологии создания гипертекстовых баз интерпретации — решается проще после того, как приняты ключевые решения относительно архитектуры программного комплекса. На этом уровне работы над проектом в ней должен принять участие специалист, знакомый как с содержательной областью, так и с программированием. Назовём такого специалиста “экспертом в предметной области”. В его задачу входит решение вопроса, какими именно конструкциями внутреннего языка и какими доступными средствами может быть выражен тот смысл, который лишь подразумевается в исходном тексте. Ориентироваться он должен исключительно на своё понимание оригинального текста и на знание имеющихся в его распоряжении средств (правил внутреннего языка и его конструкций, возможностей системы в целом). На определённых этапах работы ему может потребоваться “содержательная” отладка построенной формализации, когда он по своей инициативе подбирает достаточно представительную выборку контрольных заданий, позволяющую убедиться, что экспертная система дискриминирует случаи и классифицирует их именно так, как, по его мнению, подразумевал автор исходных текстов.

Эта, на первый взгляд, достаточно рутинная работа становится захватывающей, когда выясняется, что кажущиеся осмысленные исходные тексты на самом деле никак не поддаются формализации и “не хотят” превращаться в базы интерпретаций экспертной системы. Ему может казаться, что под рукой недостаёт изобразительных средств, и тогда эксперт в предметной области выходит на системных программистов или архитекторов системы с инициативой обсуждения складывающейся ситуации. В результате “мозговой атаки” возможно одно из двух: либо системный программист и архитектор системы подскажут, какие дополнительные средства и в каком сочетании эксперт в предметной области может использовать, либо они в результате обсуждения получают задание реализовать недостающие средства на среднем, если удастся, или на внутреннем цикле разработки проекта. Но после того, как недостающие средства (правила или конструкции языка, дополнительные механизмы системы) реализованы, вся ответственность за формализацию исходных текстов вновь перелагается на эксперта в предметной области. На нём же лежит ответственность за общий итог работы, так как именно от него в конечном счёте зависит общее впечатление от системы и её соответствие назначению.

Пример 2. Приведём пример не слишком сложного правила, демонстрирующего гибкость, способность выявлять тонкие эффекты и дискриминировать достаточно редкие случаи.

{если <Зод Центр тяжести = 5 6 8 9 и \
(Зод число экстремумов в строке 5 > 4 или \
Зод Число экстремумов в строке 6 > 4 или \
Зод Число экстремумов в строке 8 > 4 или \
Зод Число экстремумов в строке 9 > 4 или \
Зод Строки с максимальной построчной суммой = 5 6 8 9 или \
Зод Строки с минимальной построчной суммой = 5 6 8 9 или \
Зод Число эксактов в строке 5 >= 4 или \
Зод Число эксактов в строке 6 >= 4 или \
Зод Число эксактов в строке 8 >= 4 или \
Зод Число эксактов в строке 9 >= 4)>, то}

=>синий|У владельца гороскопа определённо есть шансы на выигрыш и удачу в предсказании и угадывании|0.10.|PRINCIPI.HDB.3.3.4.<=

Пример 3. В качестве ещё одного примера приведём фрагмент базы, задающей таблицу, состоящую на 90% из вычисляемых ссылок. Правила определяют лишь первую строку таблицы, но этого вполне достаточно, чтобы составить представление о возможностях Гипертекста с вычисляемыми ссылками™.

rem

{таблица 3x1; толщина 1 точекx1 точек; цвет чёрный; ширины 1:1:1}
{по центру}{описатель параграфа клетка-таблицы}\
НАТАЛЬНЫЕ АСПЕКТЫ{конец клетки таблицы}
{по центру}{описатель параграфа клетка-таблицы}\
ТРАНЗИТНЫЕ АСПЕКТЫ{конец клетки таблицы}
{по центру}{описатель параграфа клетка-таблицы}\
АКТУАЛЬНЫЕ АСПЕКТЫ{конец клетки таблицы}
{таблица 9x20; толщина 1 точекx1 точек; цвет чёрный; ширины 2см:2см:4:2см:2см:4:2см:2см:4}
{по центру}{описатель параграфа клетка-таблицы}\
Макси-\перенос мальный\перенос вес{конец клетки таблицы}\
{по центру}{описатель параграфа клетка-таблицы}\
Чис\-ло\перенос аспек\-тов{конец клетки таблицы}\
{по центру}{описатель параграфа клетка-таблицы}\
Аспек\-ты,\перенос упо\-ря\-до\-чен\-ные\перенос по ве\-сам{конец клетки таблицы}
{по центру}{описатель параграфа клетка-таблицы}\
Макси-\перенос мальный\перенос вес{конец клетки таблицы}
{по центру}{описатель параграфа клетка-таблицы}\
Чис\-ло\перенос аспек\-тов{конец клетки таблицы}
{по центру}{описатель параграфа клетка-таблицы}\ Аспек\-ты,\перенос
упо\-ря\-до\-чен\-ные\перенос по ве\-сам{конец клетки таблицы}
{по центру}{описатель параграфа клетка-таблицы}\
Макси-\перенос мальный\перенос вес{конец клетки таблицы}
{по центру}{описатель параграфа клетка-таблицы}\
Чис\-ло\перенос аспек\-тов{конец клетки таблицы}
{по центру}{описатель параграфа клетка-таблицы}\ Аспек\-ты,\перенос
упо\-ря\-до\-чен\-ные\перенос по ве\-сам{конец клетки таблицы}
<Установить режим расчётов 1>\
{по центру}{описатель параграфа клетка-таблицы}\
<Параметры аспекта планет 1>{конец клетки таблицы}\
{по центру}{описатель параграфа клетка-таблицы}\
<Число Нат планеты в аспекте 1 1>{конец клетки таблицы}\
{слева}{описатель параграфа клетка-таблицы}\
{если <Число Нат планеты в аспекте 1 1 = 0>, то}Соединение\
{если <Число Нат планеты в аспекте 1 1 = 1>, то}\
=>NASPECTH.HDB|Соединение|1.Нат Планеты в аспекте 1 2.|Установить режим расчётов 1<= \
{если <Число Нат планеты в аспекте 1 1 > 1>, то}\
=>NASPECTH.HDB|Соединения|1.Нат Планеты в аспекте 1 2.|Установить режим расчётов 1<= \
{конец клетки таблицы}\
<Установить режим расчётов 3>\
{по центру}{описатель параграфа клетка-таблицы}\
<Параметры аспекта планет 1>{конец клетки таблицы}\
{по центру}{описатель параграфа клетка-таблицы}\
<Число Тран планеты в аспекте 1 1>{конец клетки таблицы}\
{слева}{описатель параграфа клетка-таблицы}\
{если <Число Тран планеты в аспекте 1 1 = 0>, то}Соединение\
{если <Число Тран планеты в аспекте 1 1 = 1>, то}\
=>TASPECTH.HDB|Соединение|1.Тран Планеты в аспекте 1 2.|Установить режим расчётов 3<= \
{если <Число Тран планеты в аспекте 1 1 > 1>, то}\
=>TASPECTH.HDB|Соединения|1.Тран Планеты в аспекте 1 2.|Установить режим расчётов 3<= \
{конец клетки таблицы}\
<Установить режим расчётов 2>\
{по центру}{описатель параграфа клетка-таблицы}\
<Параметры аспекта планет 1>{конец клетки таблицы}\
{по центру}{описатель параграфа клетка-таблицы}\
<Число Акт планеты в аспекте 1 1>{конец клетки таблицы}\
{слева}{описатель параграфа клетка-таблицы}\
{если <Число Акт планеты в аспекте 1 1 = 0>, то}Соединение\
{если <Число Акт планеты в аспекте 1 1 = 1>, то}\
=>AASPECTH.HDB|Соединение|1.Акт Планеты в аспекте 1 2.|Установить режим расчётов 2<= \
{если <Число Акт планеты в аспекте 1 1 > 1>, то}\
=>AASPECTH.HDB|Соединения|1.Акт Планеты в аспекте 1 2.|Установить режим расчётов 2<= \
{конец клетки таблицы}\

А вот как выглядит рассмотренный фрагмент таблицы на экране:

(Рис. 1)

Генерация гипертекстовой базы с последующим её подключением.

Реализация концепции Гипертекста с вычисляемыми ссылками™ открыло разработчикам возможности, которые просто нельзя было не использовать, особенно если учесть, что на содержательном уровне их использование позволяло реализовать дополнительные функции системы. В самом деле, предоставляя пользователю возможность поработать с экспертной системой, выносящей суждения по интересующим его вопросам на основании основных (статических) баз знаний (баз интерпретаций), естественно предоставить ему дополнительную возможность задать вопрос, определив его профиль, и получить на него ответ в некотором дополнительном измерении. В нашем случае речь идёт о том, что пользователя может интересовать не только собственный астрологический портрет или портрет интересующего его лица, но и прогноз на будущее, динамика событий, которые ожидают его или это лицо. Совершенно естественно, что эта динамика событий может быть вычислена только на основании данных об интересующем лице. Заложить ее в статические базы заранее невозможно. Но можно в параллельном программном разделе провести предрасчёты, сгенерировать гипертекстовую базу, содержащую подобранную информацию о предстоящих событиях и точки входа (ссылки) на их интерпретацию, а по окончании предрасчётов подключить эту базу к числу постоянных (статических). При переходе на интерпретацию сгенерированной базы пользователь получает возможность обратить внимание на выделенные системой события и пойти по ссылке на статьи интерпретаций из статических баз.

Пример 4. Экран данных предрасчётов и результат движения по ссылке.

(Рис. 2)

(Рис. 3)

Организация работы демонстратора

Объяснять необходимость включения демонстратора в программный комплекс едва ли необходимо. Демонстраторы давно стали неотъемлемой составной частью серьёзных программных продуктов; они являются основой руководств пользователя, систем поддержки пользователя в процессе работы (функции HELP), систем презентации, и во многих других случаях.

В нашем программном продукте неизбежность включения демонстратора в состав пакета была осознана, к сожалению, достаточно поздно, и его подключение потребовало значительных изменений в архитектуре комплекса. Однако включить демонстратор составной частью системы АстроЛогос стало настоятельной необходимостью, так как новый продукт, каким является АстроЛогос, требует новых приёмов работы и без такой дружественной поддержки был бы обречён на мучительный и долгий путь к потребителю. Едва ли кто-либо в наше время будет внимательно читать руководство по методам работы с системой — на это, как правило, у пользователя просто нет времени. Другое дело — просмотреть сюжет, в котором в автоматическом режиме ему излагаются не только интересные факты, но и демонстрируются приёмы работы с системой. Таким образом, задуманный и позже реализованный демонстратор заменил собой объёмные книжные руководства по методам работы с системой АстроЛогос, с одной стороны, позволил предусмотреть режим автоматической работы системы (в частности, презентатор), с другой, и (отчасти неожиданно для самих разработчиков), ввести режим автоматизации исследований для астрологов-профессионалов.

По исходным требованиям технического задания к демонстратору он должен выполнять всё, что выполняет пользователь, следующий данному сценарию, и на экране должно появляться всё, что видит пользователь, осуществляющий те же действия, однако эти действия должны выполняться в автоматическом режиме. К тому же в заданные моменты должны появляться поясняющие ход работы сообщения. У пользователя должны быть средства, позволяющие приостановить на некоторое время процесс демонстрации, изменить его темп, задать детальность и глубину рассмотрения материала, продолжить демонстрацию или сбросить режим демонстратора. Дополнительным требованием технического задания было задание режима циклической прокрутки выбранных сценариев до момента отмены этого режима (режим презентации программного пакета).

Самое простое архитектурное решение, приходящее в голову первым — использование SCRIPT-файла — применительно к системе АстроЛогос не проходило по следующим причинам:

• в системе АстроЛогос требуется привязка не к позиции курсора на экране, а к элементу текста; сам текст форматируется под окно, и его расположение на экране от запуска к запуску (и просто при изменении размеров окна) меняется. Поэтому система привязок должна быть более сложной, учитывающей привязки курсора к элементам текста;

(Рис. 4)

• при работе с системой появляются окна и возникает необходимость сделать выбор элемента из формируемого списка. Таким списком является, к примеру, список лиц, известных системе. Опять же необходимо осуществить привязку не к позиции в списке (этот список от раза к разу может пополняться), а к содержательной информации;
• при использовании скролл-бара, управляющего прокруткой текста до нужного места, определить, появился ли нужный фрагмент текста на экране или следует продолжать нажатие на кнопку перемещения текста, значительно сложнее, чем это можно определить в SCRIPT-файле;

(Рис. 5)

• наконец, при работе с системой могут появляться окна с информационными сообщениями, появление которых однозначно предсказать нельзя. Требуется организовать более сложную, чем в SCRIPT-файле связь с текстом, появляющимся на экране, и использовать более сложную логику работы сценария. К этому же классу проблем относится подстройка алгоритма работы демонстратора к экрану с разрешением 640х480 или 800х600, так как некоторые экраны ввода данных автоматически разбиваются на два в случае использования монитора низкого разрешения, и требуется дополнительное нажатие на кнопку ДА (или “Продолжить”), чтобы появилась вторая часть экрана.

(Рис. 6.1)

(Рис. 6.2)

(Рис. 6.3)

Всё это привело к тому, что демонстратор сам по себе стал достаточно интеллектуальным, а язык сценариев, хотя и чрезвычайно простой по своим конструкциям и наглядности, весьма изощрённым в реализации.

В результате появился демонстратор, который полностью подменяет пользователя при выполнении сценария и действительно позволяет продемонстрировать все режимы работы системы

АстроЛогос. Достигнуто это ценой одновременной синхронной работы двух, а при выполнении предрасчётов — трёх задач одновременно с передачей данных между ними. Здесь разработчики системы вплотную подошли к границам возможностей операционной среды WINDOWS, которая не является в полном смысле многозадачной, наделённой механизмами управления задачами. Однако даже средствами WINDOWS эта задача была решена. Естественно, что при использовании более развитой операционной среды все идеи, заложенные в демонстратор, могут быть воплощены более изящно и ценой меньших усилий.

Таким образом, система АстроЛогос, являющаяся оригинальной разработкой российских программистов, содержит несколько “находок”, которые с успехом могут быть реализованы в других программных пакетах.